Creating a new file while sidebar is hidden could be improved

Steps to Reproduce:

Open file
Hide sidebar (Cmd+B)
Command Palette > New file
Sidebar appears with new file added next to the current file

It would be great if running File: New File from the command palette would show you a picker with the path pre-populated, allowing you to traverse through folder and also preserving the users' view. Here's a quick mockup:

cc @stevencl

@misolori this makes sense to me. Would you be willing to provide a PR for this? Should be pretty straight forward. If yes, let me know and I can provide code pointers and guidance.
Also what would happen if the sidebar is open, but another viewlet is shown, not the explorer, for example debug? I think than the explorer should get opened and we keep the current experience.
Also what would you expect if a user enters an invalid file / folder name? Currently we show the error inline, and unfortunetly we do not have this support in quick pick.
Overall I think this change makes sense however I am not 100% convinced we need it. Can you elaborate where is the motivation coming from?
For example creating a new folder, I think the most common scenario is that you want to do something with it and that opening the explorer is useful. For file I see that you do not really need the explorer.

@isidorn I wouldn't mind taking a first stab it, code pointers would be great.
I think my proposed changes should only happen when the sidebar is collapsed. For the quickpick validation, I know I've seen this in other views (@chrmarti correct me if I'm wrong).
The main motivation is for the example I showed above where I'm trying to work from a "minimal" mode and am hiding the explorer intentionally but need to create a single file. While not absolutely necessary to this workflow, it's one of those "delights" where you hope the editor is smart enough to persist your view.

(We have validation for the input box, but not QuickPick. We could surface it for QuickPick too since much of the implementation is shared between the two.)

@misolori agree, only when the sidebar is collapsed.
It would be great if you create a PR and than we can take it from there
Though please create the PR from this branch, since it changes the whole explorer. Or alternativly wait for a week for us to merge in that branch to master.
Here's the code pointer
https://github.com/Microsoft/vscode/blob/e899bc638919ad4b11f2cd0e5915e1a79012fbf2/src/vs/workbench/parts/files/electron-browser/fileActions.ts#L1150
Basically that code path is only used for new file and new folder actions. Exactly what you need. You should use the partService to check if the sidebar is visible, if not do your thing vie quickOpenService and fileService.
Once we get that initial stuff working we can include @chrmarti to surface us validation for the QuickPick so you also adopt that.

Would love it if someone could create a PR for this, see code pointer above.


Crash caused by ValueError

Hi, I'm receiving the following when I try to run Watson on my Windows 10 pc:
Traceback (most recent call last):
  File "c:\users\ettienne.pitts\appdata\local\programs\python\python39\lib\runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "c:\users\ettienne.pitts\appdata\local\programs\python\python39\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "C:\Users\ettienne.pitts\AppData\Local\Programs\Python\Python39\Scripts\watson.exe\__main__.py", line 4, in <module>
  File "c:\users\ettienne.pitts\appdata\local\programs\python\python39\lib\site-packages\watson\__main__.py", line 1, in <module>
    from watson import cli
  File "c:\users\ettienne.pitts\appdata\local\programs\python\python39\lib\site-packages\watson\cli.py", line 529, in <module>
    def report(watson, current, from_, to, projects, tags, ignore_projects,
  File "c:\users\ettienne.pitts\appdata\local\programs\python\python39\lib\site-packages\click\decorators.py", line 247, in decorator
    _param_memo(f, OptionClass(param_decls, **option_attrs))
  File "c:\users\ettienne.pitts\appdata\local\programs\python\python39\lib\site-packages\watson\cli.py", line 46, in __init__
    super(MutuallyExclusiveOption, self).__init__(*args, **kwargs)
  File "c:\users\ettienne.pitts\appdata\local\programs\python\python39\lib\site-packages\click\core.py", line 2467, in __init__
    super().__init__(param_decls, type=type, multiple=multiple, **attrs)
  File "c:\users\ettienne.pitts\appdata\local\programs\python\python39\lib\site-packages\click\core.py", line 2106, in __init__
    raise ValueError(
ValueError: 'default' must be a list when 'multiple' is true.

Got the same issue on Ubuntu 20.04LTS. Looks like it happened after python version update(Python 3.8.5) or some other updates in system.
As a temporary solution I've reinstalled tool on Python 3.6 and it works for me now.

Looks like a Click release incompatibility. Which version of Watson are you running? Have you tried to uninstall/reinstall it?

I did a pip install earlier today, so I assume the latest version? How can I confirm?

watson --version

@jmaupetit I only get the error shown above

Of course :sweat_smile: Can you point the pip release you are using and also the Click release?
# Get pip release
$ pip --version

# Get click release
$ pip freeze | grep click

pip version
pip 21.1.1

click
click==8.0.0

Hmm, seems that Watson is not compatible with the latest Click major release (from yesterday)... I propose the following as a temporary fix:
$ pip uninstall click && pip install click==7.1.2

Nice, working with the temp fix, thanks @jmaupetit!

Thanks for providing the workaround!
I'm running on Ubuntu 20.04.  In case it is helpful, here's how I set up my workaround env:
I already have a fork of the repo. I obtained it via the following:
git clone git@github.com:veganjay/Watson.git Watson-veganjay
cd Watson-veganjay

Update requirements.txt to specific click version:
click==7.1.2

Install via pipx:
pipx install .

Hi! I just came across this problem too after doing a system upgrade. I tried to fix it with the following before I found this thread (changes to default argument). Do you think the click compatibility issue likely to be deeper than changing the default argument? Is it safer for me to downgrade click?
--- a/watson/cli.py
+++ b/watson/cli.py
@@ -522,3 +522,3 @@ _SHORTCUT_OPTIONS_VALUES = {
               flag_value='plain', mutually_exclusive=['json', 'csv'],
-              multiple=True, default=True, hidden=True,
+              multiple=True, default=['plain'], hidden=True,
               help="Format output in plain text (default)")
@@ -777,3 +777,3 @@ def report(watson, current, from_, to, projects, tags, ignore_projects,
               flag_value='plain', mutually_exclusive=['json', 'csv'],
-              multiple=True, default=True, hidden=True,
+              multiple=True, default=['plain'], hidden=True,
               help="Format output in plain text (default)")
@@ -953,3 +953,3 @@ def aggregate(ctx, watson, current, from_, to, projects, tags, output_format,
               flag_value='plain', mutually_exclusive=['json', 'csv'],
-              multiple=True, default=True, hidden=True,
+              multiple=True, default=['plain'], hidden=True,
               help="Format output in plain text (default)")

I suspect that there are additional changes that are needed to be
compatible with the new click.
I did not see any obvious click migration guide, and at the moment I'm a
total click beginner.
With the changes you mentioned, did you try the unit tests, and if so, did
they pass?
Jason
On Sun, May 16, 2021 at 2:25 AM Dan Lewis @.***> wrote:

Hi! I just came across this problem too after doing a system upgrade. I
tried to fix it with the following before I found this thread (changes to
default argument). Do you think the click compatibility issue likely to be
deeper than changing the default argument? Is it safer for me to downgrade
click?
--- a/watson/cli.py
+++ b/watson/cli.py
@@ -522,3 +522,3 @@ _SHORTCUT_OPTIONS_VALUES = {
flag_value='plain', mutually_exclusive=['json', 'csv'],

         multiple=True, default=True, hidden=True,

         multiple=True, default=['plain'], hidden=True,
         help="Format output in plain text (default)")

@@ -777,3 +777,3 @@ def report(watson, current, from_, to, projects, tags, ignore_projects,
flag_value='plain', mutually_exclusive=['json', 'csv'],

         multiple=True, default=True, hidden=True,

         multiple=True, default=['plain'], hidden=True,
         help="Format output in plain text (default)")

@@ -953,3 +953,3 @@ def aggregate(ctx, watson, current, from_, to, projects, tags, output_format,
flag_value='plain', mutually_exclusive=['json', 'csv'],

         multiple=True, default=True, hidden=True,

         multiple=True, default=['plain'], hidden=True,
         help="Format output in plain text (default)")

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/TailorDev/Watson/issues/430#issuecomment-841775800,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIV5OY6ULYGU2YVZBWEOEDTN5QMFANCNFSM44YNUTHQ
.

Pinning to the latest Click 7 release does the trick, but we need to migrate to click 8 asap!

Thanks for the fix :+1:
While working on Click 8 migration, could you release a new version so the fix is live? @veganjay's solution works but is far from ideal (issue & solution discoverability, a latest & stable release is broken).

I had the same problem after updating to fedora 35, and then replicated it in an alpine virtual environment. Unfortunately, the new version of click is installed by the fedora package manager, but installing the older version of click with pip works for now, even without specifying the version in the watson build.

Should be fixed now! https://github.com/TailorDev/Watson/releases/tag/2.1.0


Google Chrome 43. Keypress: `¬¦ resulted in 223 huh? Let me know what browser and key this was.

Browser: Google Chrome 43.0.2357.132 (Official Build) m (32-bit)
Operating System: Windows 8.1
Keyboard: English (UK) QWERTY Keyboard.
The key pressed appears at the top left of keyboard under the Esc key, that what pressed prints characters: `, (shift) ¬, (alt gr) ¦.

Going to close this issue, as I think this is fixed now for keycode 223.
https://github.com/wesbos/keycodes/blob/gh-pages/scripts.js#L159
Please re-open if you think otherwise.


add method to StorageEngineV2 for get All date region ids.

when Data Node shrink，will move all data regions  belongs to the Data Node to others. so

need add a method to get all data regionIds.
public List<DataReionId> getAllDataReionIds()
because StorageEngineV2 just manage data region,  it's member variable dateRegionMap map key should be DataReionId not ConsensusGroupId:
private final ConcurrentHashMap<ConsensusGroupId, DataRegion> dataRegionMap =   new ConcurrentHashMap<>();
-->
private final ConcurrentHashMap<DataReionId, DataRegion> dataRegionMap =   new ConcurrentHashMap<>();

the issue is fixed


Can windows be used?

Can windows be used?

If TON can be built on windows - there should be much trouble to adjust build.rs, but we don't support and test window builds

OK, thanks.


Improved Seed file management

When a seed file is uploaded, it's name should be displayed in the interface.
Clicking on this name should bring up a list of the urls in the file.
There may be some additional capabilities that should go along with this. Let's discuss before working on it.

When you upload a file, you will need to perform a lot of error cheking on the back end for the validity of the file.
It is better to have a text box where the user can paste the list and we can parse validate on the client side before sending it to the server.


macOS 10.14.4: Discard State Popup Works Half The Time

Description
The discard state up only appears about half the time.
Steps

File > Open

WORKING: https://youtu.be/KBKrbg6QpCs
NOT WORKING: https://youtu.be/-LaVY-nhy5A
Prerequisites
[ X] Put an X between the brackets on this line if you have done all of the following:
Reproduced the problem in Safe Mode: Yes
Followed all applicable steps in the debugging guide: Yes
Checked the FAQs on the message board for common solutions: Yes
Checked that your issue isn't already filed: No.
Versions
atom --version:
Atom : 1.36.0
Electron: 2.0.18
Chrome : 61.0.3163.100
Node : 8.9.3
apm --version:
apm 2.1.3
npm 6.2.0
node 8.9.3 x64
atom 1.36.0
python 2.7.10
git 2.20.1

Thanks for opening a new issue @thekodester - I think this is related to some of the issues reported in 1.36.0.  I had 1.35.1 installed and couldn't reproduce by enabling Show Welcome Guide When Opening Atom and then:

atom --safe
close all open windows
open a new window Cmd+Shift+N
Open some project with Cmd+O

(though your videos were useful, exact step-by-step instructions to reproduce are super helpful for us)
At this point with 1.35.1, I'm prompted to discard or recover project state.  After updating to 1.36.0, I'm no longer prompted with these steps.
I believe a hotfix will be released to address some of the 1.36.0 issues, lets see if this behavior is resolved too when that comes out.

1.36.1 is out and I just tried my steps above and see in 1.36.1, I'm prompted to discard or recover project state again.
Can you confirm @thekodester?

Same. Now works as expected. :-)


[api] Improves DJL URL error message

Description
Brief description of what this PR is about

If this change is a backward incompatible change, why must this change be made?
Interesting edge cases to note here

Codecov Report
Patch coverage: 71.51% and project coverage change: +1.48 :tada:

Comparison is base (bb5073f) 72.08% compared to head (a1e9804) 73.57%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@             Coverage Diff              @@
##             master    #2678      +/-   ##
============================================
+ Coverage     72.08%   73.57%   +1.48%
- Complexity     5126     6975    +1849
============================================
  Files           473      685     +212
  Lines         21970    30459    +8489
  Branches       2351     3157     +806
============================================
+ Hits          15838    22409    +6571
- Misses         4925     6520    +1595
- Partials       1207     1530     +323

Impacted Files
Coverage Δ

api/src/main/java/ai/djl/modality/cv/Image.java
69.23% <ø> (-4.11%)
:arrow_down:

...rc/main/java/ai/djl/modality/cv/MultiBoxPrior.java
76.00% <ø> (ø)

.../main/java/ai/djl/modality/cv/output/Landmark.java
100.00% <ø> (ø)

...djl/modality/cv/transform/RandomFlipLeftRight.java
25.00% <0.00%> (-25.00%)
:arrow_down:

...djl/modality/cv/transform/RandomFlipTopBottom.java
25.00% <0.00%> (-25.00%)
:arrow_down:

...i/djl/modality/cv/translator/BigGANTranslator.java
21.42% <0.00%> (-5.24%)
:arrow_down:

.../modality/cv/translator/ImageFeatureExtractor.java
0.00% <0.00%> (ø)

.../ai/djl/modality/cv/translator/YoloTranslator.java
27.77% <0.00%> (+18.95%)
:arrow_up:

...ain/java/ai/djl/modality/cv/util/NDImageUtils.java
67.10% <0.00%> (+7.89%)
:arrow_up:

api/src/main/java/ai/djl/modality/nlp/Decoder.java
63.63% <ø> (ø)

... and 227 more

... and 355 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

This will definitely help me out.


Support additional env args

If attribute node['node']['additional_env_settings'] exists, it is
expected to be an array of strings, which will then be appended
to rabbit-env.conf. This allows users the flexibility to specify
ENV settings that don't have explicit attributes. (E.g. Some
settings may be new to rabbitmq but won't require a recipe update
before people can take advantage of them.)
I also cleaned up a couple of rubocop issues in default_spec.rb

:+1:


Training Fairseq model using pre-trained embeddings

❓ Questions and Help
I'm using a big model from fairseq. And I'm experimenting using pre-trained embedding  with fairseq. But when i start training with embeddings parameters in the encoder side  on fp16, this error generated (FloatingPointError: Minimum loss scale reached (0.0001). Your loss is probably exploding. Try lowering the learning rate, using gradient clipping or increasing the batch size).
Code
I used this command to train a fasttext model using custom data:
training fasttext command (skipgram -input data.en -output fasttext.en -lr 0.025 -dim 768 -ws 5 -epoch 10 -minCount 5 -neg 5 -loss ns -bucket 2000000   -minn 3 -maxn 6 -thread 16 -t 1e-4 -lrUpdateRate 100)
part of my training fairseq command that related to embeddings is (  --encoder-embed-path  fasttext.en.vec ---encoder-embed-dim 768 --decoder-embed-dim 768)
What have you tried?
As well i tried solutions such as:

decreasing the learning rate.
increase the batch size.
add these parameters ( --fp16-scale-tolerance, --min-loss-scale, --update-freq).

But none of them can solve the problem. The only thing that worked was switching to FP32 training, but that is not an option since the training will be slower.
What's your environment?

fairseq Version (e.g., 1.0 or master): 1.0.0
PyTorch Version (e.g., 1.0): 1.6.0
OS (e.g., Linux): Linux
How you installed fairseq (pip, source): pip
Build command you used (if compiling from source):
Python version: Python 3.6.9
CUDA/cuDNN version:10.2
GPU models and configuration:
Any other relevant information:

What is your question?
How to solve this? and what is the proper way to use pre-trained embedding?

Have you found out any solution for this? I'm facing the same issue


stemmer for words in  sentences

hi,
  first, i would like to appreciate you for your wonderful work and good effort. I tried executing it for sentences.

i/p: தங்களது குழந்தைகளுக்கு எந்த வகையான கல்வியை அளிக்க வேண்டும் என்பது பற்றிய உரிமை பெற்றோர்களுக்கு இருக்கிறது.
o/p: தங்களது குழந்தைகளுக்கு எந்த வகையான கல்வியை அளிக்க வேண்டும் என்பது பற்றிய உரிமை பெற்றோர்களுக்கு இர்
how do i get it for each word in a sentences. how to give file which contain sentences and get the corresponding stemmed words. Any suggestion would be appreciated.

The stemmer program expects one word per line. There are couple of options here:
$ cat | tr ' ' '\n'  | ./stemwords -l ta (have not tried it out, but most probably works.)
Or you could use the libstemmer library to write your own program. There is a PyStemmer python library but it seems to be stale and not have Tamil support. There is also python-nltk library which has snowball support, but it also doesnt have Tamil support.
`

from nltk.stem.snowball import SnowballStemmer
SnowballStemmer.languages
('danish', 'dutch', 'finnish', 'french', 'german', 'hungarian', 'italian', 'norwegian', 'portuguese', 'romanian', 'russian', 'spanish', 'swedish')
`
So I think you have to use either the C library or do something like stemmer-ui.py, where it opens a pipe to stemmer program.

Thanks for trying it out and be warned that it is a very naive stemmer :)

@sanjanasri - see open-tamil and examples for tamil sentence/word/char working tools
$ pip install tamil

thank you so much (rdhamodharan, muthiah annamalai) . I will check it out
sir.
On Sat, Apr 22, 2017 at 11:29 PM, Muthiah Annamalai <
<EMAIL_ADDRESS>wrote:

@sanjanasri https://github.com/sanjanasri - see open-tamil and examples
for tamil sentence/word/char working tools
$ pip install tamil
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rdamodharan/tamil-stemmer/issues/2#issuecomment-296390595,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMmkNgqT57gKye_pMQIAOvMK0nuwb6e5ks5ryj__gaJpZM4NCvhK
.

--
Thanks and regards,
Sanjanasri J.P


Create a variable to show other servers player counters inside a Bungeecord server

I would like to get this feature added to the plugin, it's really useful and could make my scoreboard look cooler. it's also useful to show that on a certain server there are tons of people having fun :3
Thanks in advice.

This could be used for a bungee server.

https://github.com/PlaceholderAPI/PlaceholderAPI/wiki/Placeholders#bungeecord


[DOCS] Add missing binary scala version in engine jar name

Why are the changes needed?

Minor doc fix.
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

Codecov Report

Merging #3191 (6a9c6dc) into master (3618002) will decrease coverage by 0.05%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #3191      +/-   ##
============================================
- Coverage     51.39%   51.33%   -0.06%
  Complexity        6        6
============================================
  Files           456      456
  Lines         25422    25422
  Branches       3540     3540
============================================
- Hits          13065    13050      -15
- Misses        11096    11111      +15
  Partials       1261     1261

Impacted Files
Coverage Δ

...client/exception/RetryableKyuubiRestException.java
0.00% <0.00%> (-100.00%)
:arrow_down:

.../org/apache/kyuubi/client/RetryableRestClient.java
48.78% <0.00%> (-24.40%)
:arrow_down:

...main/java/org/apache/kyuubi/client/RestClient.java
82.75% <0.00%> (-3.45%)
:arrow_down:

...ache/kyuubi/operation/KyuubiOperationManager.scala
80.82% <0.00%> (-1.37%)
:arrow_down:

...ain/scala/org/apache/kyuubi/engine/EngineRef.scala
75.23% <0.00%> (-0.96%)
:arrow_down:

...he/kyuubi/ha/client/etcd/EtcdDiscoveryClient.scala
67.50% <0.00%> (-0.63%)
:arrow_down:

...g/apache/kyuubi/operation/BatchJobSubmission.scala
74.40% <0.00%> (ø)

...yuubi/server/metadata/jdbc/JDBCMetadataStore.scala
89.96% <0.00%> (+0.69%)
:arrow_up:

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

Thanks, merging to master


Possibility to add custom error pages

It could be nice if there was a way to add custom html error page when service is not available.

Please implement

I'd say custom error page for each error code you want: 404, 503...

+1

This would be great

You're welcome to submit a PR if we don't already created one.
Remember the gentle way to participate:

add a "reaction" on the first message of the issue.
add more useful and detailed information on the subject.
solve the issue by making a PR.

A more concrete proposal exists with #1634.


Missing ) in SQL query using count() + top_n()

To reproduce:
library(dplyr)
library(sparklyr)

sc <- spark_connect("local")

mtcars_tbl <- copy_to(sc, mtcars)

mtcars_tbl %>%
  count(mpg) %>%
  top_n(5)
## Error: org.apache.spark.sql.AnalysisException: line 2:59 missing ) at ',' near ')' in subquery source
##   line 3:0 cannot recognize input near 'AS' 'zzz2' 'FROM' in subquery source;

Actually, there seem to be several problems with variations on this code.
For example, passing n as the weight argument fails, presumably because it thinks the column n is actually the dplyr function n().
mtcars_tbl %>%
  count(mpg) %>%
  top_n(5, wt = n)
## Error: Unknown input type: function

This uncovers a problem with renaming columns.
mtcars_tbl %>%
  count(mpg) %>%
  rename(nn = n)
## Source:     lazy query [?? x 2]
## Database:   spark_connection
## Error: `x` must be a vector

It isn't clear to me if these are separate issues, or one issue with the SQL count statement that is generated.

Oh, sorry, the minimal reproducible example is actually even simpler.
mtcars_tbl %>%
  top_n(5)
## Error: org.apache.spark.sql.AnalysisException: line 2:117 missing ) at ',' near ')' in subquery source
##   line 3:0 cannot recognize input near 'AS' 'zzz23' 'FROM' in subquery source;

@richierocks I can't reproduce -- could you try updating/reloading dplyr and dbplyr?

Further investigation reveals that the problems occur with Spark 1.6.2, but not Spark 2.0.2.

Here's the generated query with Spark 1.6.2:
> sql_render(query)
<SQL> SELECT `mpg`, `cyl`, `disp`, `hp`, `drat`, `wt`, `qsec`, `vs`, `am`, `gear`, `carb`
FROM (SELECT `mpg`, `cyl`, `disp`, `hp`, `drat`, `wt`, `qsec`, `vs`, `am`, `gear`, `carb`, rank() OVER (ORDER BY (4.0, 4.0, 1.0, 1.0, 2.0, 1.0, 4.0, 2.0, 2.0, 4.0, 4.0, 3.0, 3.0, 3.0, 4.0, 4.0, 4.0, 1.0, 2.0, 1.0, 1.0, 2.0, 2.0, 4.0, 2.0, 1.0, 2.0, 2.0, 4.0, 6.0, 8.0, 2.0) DESC) AS `zzz6`
FROM `mtcars`) `ofukbymqme`
WHERE (`zzz6` <= 5.0)

The query looks fine and is unchanged with Spark 2.1.0, so I assume this is a bug in Spark 1.6.2.

@kevinushey  @richierocks  @javierluraschi @kevinykuo , I tried reproducing this issue, and I got no errors. It worked fine.
So, I doubt that it is a bug in Spark 1.6.2
My session information is as follows;
> sessionInfo()
R version 3.3.3 (2017-03-06)
Platform: i386-w64-mingw32/i386 (32-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1

locale:
[1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] DBI_0.7            sparklyr_0.5.6     magrittr_1.5       dplyr_0.7.0        nycflights13_0.2.2

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.11     rstudioapi_0.6   hms_0.3          rappdirs_0.3.1   xtable_1.8-2
 [6] R6_2.2.2         rlang_0.1.1      httr_1.2.1       tools_3.3.3      parallel_3.3.3
[11] config_0.2       dbplyr_1.0.0     withr_1.0.2      htmltools_0.3.6  yaml_2.1.14
[16] assertthat_0.2.0 rprojroot_1.2    digest_0.6.12    tibble_1.3.3     shiny_1.0.3
[21] readr_1.1.1      base64enc_0.1-3  glue_1.1.1       mime_0.5         backports_1.1.0
[26] jsonlite_1.5     httpuv_1.3.3

load libraries
>library(sparklyr)
>library(dplyr)

Copy data to spark local instance
>copy_to(sc, mtcars)
check data tables in spark local cluster
>src_tbls(sc)
[1] "mtcars"

print the spark version
>spark_version(sc)
[1] ‘1.6.2’

execute dplyr commands
> mtcars %>%
+   count(mpg)%>%
+   top_n(5)
Selecting by  n
# A tibble: 7 x 2
    mpg     n
  <dbl> <int>
1  10.4     2
2  15.2     2
3  19.2     2
4  21.0     2
5  21.4     2
6  22.8     2
7  30.4     2

> mtcars %>%
+   count(mpg)%>%
+   top_n(5, wt=n)
# A tibble: 7 x 2
    mpg     n
  <dbl> <int>
1  10.4     2
2  15.2     2
3  19.2     2
4  21.0     2
5  21.4     2
6  22.8     2
7  30.4     2

> mtcars %>%
+   count(mpg)%>%
+   rename(nn=n)
# A tibble: 25 x 2
     mpg    nn
   <dbl> <int>
 1  10.4     2
 2  13.3     1
 3  14.3     1
 4  14.7     1
 5  15.0     1
 6  15.2     2
 7  15.5     1
 8  15.8     1
 9  16.4     1
10  17.3     1
# ... with 15 more rows

Right, this one I remember was a dplyr regression which is fixed now in dplyr 0.7. Closing.


chore: relax dependency versions

This PR introduces less constraints for some of the dependencies used in this library so consumers can benefit from widen ranges.

:tada: This PR is included in version 4.12.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Possible to use containers?

Would it be possible to use docker/kubernetes/etc.. containers with these clones?

See the following
Solving the dev DB problem with Docker and dbaclone - Alex Yates,Sander Stad
https://www.youtube.com/watch?v=masJxBmgfqo
https://github.com/sanderstad/dockerdeepdive/tree/main/Demos/Code


[Quickdraw] I am here to learn how to open and close issues on Github! 🤠

I am here to learn how to open and close issues on Github! 🤠
I will close it in 10 seconds 🤞

want to learn


Indicate the number of selected items in query-grid (#28)

Adds an indication on the query-grid of how many items are selected

Thank you for your contribution and for taking the time to submit this pull request. After reviewing the proposed changes and considering the broader context of our design and the varied use cases, we've concluded that the implementation doesn't cover all scenarios.


Fix uninitialized variable problem on TritonMP

Change from DBL_MIN to -DBL_MAX for uninitialized variables.
This will solve the uninitialized macro_placement problem when all weighted wire length(WWL) is zero.
Confirmed with Minsoo that this patch worked well on GF14

I think its really confusing to set the init value to -MAX. It would be better to redefine the MIN macro if the min value is wrong.


Change path to dest to support older ansible

This change updates our ELK playbooks so that they're deployment
agnostic. This should ensure the keys are distributed in a functional
way cast proper variables.
Signed-off-by: Kevin Carter<EMAIL_ADDRESS>

recheck_cit_artifact

recheck_cit_xenial_swift_deploy - failed fetching base image

Updated PR to address the review from @prometheanfire .

merged, +2 from both @major and @prometheanfire


Entropy functionality depends on pyqtgraph

So checking for pyqtgraph before parsing the file will save some wasted time.

Binwalk only attempts to load pyqtgraph if it is trying to generate a visual graph. This way, even if you can't, or don't want to, install pyqtgraph, you can still get useful textual information from binwalk's output regarding file entropy.
Specifying --nplot explicitly tells binwalk not to do the graphing, so this will suppress any loading errors.

Yep, but it would be nice for it to fail to load pyqtgraph (if it's going to) before parsing the file. Then someone can explicitly pass --nplot the first time round instead of the second. Admittedly only a small thing, but also only a small change.
Happy to send a PR tomorrow - I've raised this ticket only because I wanted something to refer back to.

Added explicit check for pyqtgraph at the beginning of entropy scans. Prints a warning and assumes --nplot if the pyqtgraph import fails.


Add allocation test for adding multiple handlers

Motivation:
I believe there is at least 1 avoidable allocation in this area.
Even if there isn't, making sure we don't increase allocations is good.
Modifications:
Add a test of allocations when adding multiple handlers.
Set limits for docker images.
Result:
Allocations when adding multiple handlers are now checked.

Went in as part of #1710


Restore support for Rails 4

This commit restores support for Rails 4 by only including the optional: true value of the belongs_to : bootsy_resource association when Rails 5+ is being used.
Please note I couldn't find any references for this type of situation so while my approach works there may be a better way to get it done. Thanks! 😄

Thanks for the PR but as I said in #251, Bootsy is no longer compatible with Rails 4 by design. Rails 4.x series is no longer supported by the Rails team since yesterday, by the way.

@volmer that's a shame. As far as I could tell this PR fixed the only Rails 5+ specific code. Any reason why Rails isn't listed in the gemspec?
Also according to the Maintenance Policy for Ruby on Rails documentation 4.2.x is still receiving bug and security fixes.

Any reason why Rails isn't listed in the gemspec?

No reason I can think of. We could have the version requirement in there, yes.

Also according to the Maintenance Policy for Ruby on Rails documentation 4.2.x is still receiving bug and security fixes.

They didn't publish it yet but that page was already updated: https://github.com/rails/rails/blob/master/guides/source/maintenance_policy.md


Include http method in req and resp metrics

So that metrics can be grouped by method where possible.
The method would be an uppercased string, which I think is appropriate for the use case.

Thanks @cloud8421! :tada:

Yay! I've been meaning to carve out some time to add this for a while now. 🚀


improve team display

I was browsing the site and realized how poor the team display is on the home page.
This PR aims to make it more bearable (also tall display support!)
OLD

notice how the text doesn't line up and the logos cover the text
NEW (with tall display support)

fixed height logos, tall display utilizes stacked display
Various resizing stuff

Thank you so much Justin for your PR! I believe I made an issue for this somewhere so if I remember I will reference and close that issue.
Can you make the badges just a bit smaller before you merge? Overall it looks amazing!

What badges? The team logos? I didn't change their size on Desktop version. If you mean on the tall display version then yeah, let me know by what % they should shrink by.
The idea for the tall display stacked version is that the logo is approximately the same size as the text to sell the effect a bit better.
Please pull my branch locally and experiment with a better size for the logos.

I apologize I meant the logos. The reason for the overflow was because I updated the assets with no padding. Before when there was padding, the logos looked a bit smaller.
You might have to change the width now or just add padding to the img tag.

I apologize I meant the logos. The reason for the overflow was because I updated the assets with no padding. Before when there was padding, the logos looked a bit smaller.
You might have to change the width now or just add padding to the img tag.

Honestly, out of scope of my PR. Create an issue (or revive an old issue) and create a new PR after this one is merged.
It's meaningless to discuss how many pixels the logos should be smaller by then I go and do it and update my PR only to be off by a few pixels of what is desired.
I was mainly concerned with text alignment and tall display styles.

Sounds good! That's why I approved this PR in the first place. I will take that advice and apply it.
Feel free to merge!


fix: invalid name for preview file in (30 seconds) preview

I have fixed it with a commit, thanks for pointing it out!


Create reverse bridges : RSS to social sites

My internet sites provide RSS feeds. I wish to be able to publish them on various Facebook, Twitter, Instagram and Discord accounts pages, stories or chans.
rss-bridge provide social-sites to RSS bridges.
Please provide reverse bridges : an API or a service that reads an RSS feeds and publishes items on facebook, twitter, instagram, discords and other pages, stories or chans.
I've sometime used platforms as ifttt to do so, but its not opensource, not very good in rendering quality and poor on parametering.

Sorry, but this is not going to be implemented


Why not segment.add()?

Is your feature request related to a problem? Please describe.
 Looks like I need to recreate the functionality of Group.add which automatically finds the right container to add to if I don't know the class a priori.
Describe the solution you'd like
I'd like to be able to call segment.add(object_of_unknown_class) like I can with a Group. Is there a reason this isn't currently supported? Why isn't add defined at the Container level instead of Group?
Describe alternatives you've considered
Copying and pasting Group's code. This is my workaround
def add_to_neo_segment(
    segment: neo.core.Segment, *objects: neo.core.dataobject.DataObject
):
    """Taken from neo.core.group.Group."""
    container_lookup = {
        cls_name: getattr(segment, container_name)
        for cls_name, container_name in zip(
            segment._child_objects, segment._child_containers
        )
    }

    for obj in objects:
        cls = obj.__class__
        if hasattr(cls, "proxy_for"):
            cls = cls.proxy_for
        container = container_lookup[cls.__name__]
        container.append(obj)

Hi @kjohnsen This sound like a very good idea to me. Feel free to open a PR to add the new utility functionality.

Implemented in #1307


Port to Fabric 1.19.4

thanks for going through the effort of updating this
however, i won't merge because multiple versions in your PR are not latest and because of the many automatic code style changes (i want everything to be in a uniform code style)
also, some unrelated changes are made without any notes as to why they exist


Client never recovers/disconnects lost connection from server restart

If a client is continuously sending messages on a properly established DTLS connection, if the server dies and restarts, the client never detects the server is down or attempt to reestablish the connection.
Here's an example of a client:
package main

import (
    "log"
    "net"
    "time"

    "github.com/pion/dtls"
)

func main() {
    addr := &net.UDPAddr{IP: net.ParseIP("<IP_ADDRESS>"), Port: 6553}
    certificate, privateKey, err := dtls.GenerateSelfSigned()
    if err != nil {
        log.Fatal(err)
        return
    }

    config := &dtls.Config{
        Certificate:          certificate,
        PrivateKey:           privateKey,
        ExtendedMasterSecret: dtls.RequireExtendedMasterSecret,
        ConnectTimeout:       dtls.ConnectTimeoutOption(30 * time.Second),
        InsecureSkipVerify:   true,
    }

    for {
        conn, err := dtls.Dial("udp", addr, config)
        if err != nil {
            log.Fatal(err)
            return
        }
        defer conn.Close()
        log.Println("Established connection...")

        for {
            message := []byte("Sup youngin...")
            amt, err := conn.Write(message)
            if err != nil {
                log.Println(err)
                break
            }
            log.Printf("Successfully wrote %d bytes", amt)

            time.Sleep(3 * time.Second)
        }
    }
}

Here's an example of a server receiving the message:
package main

import (
    "log"
    "net"
    "time"

    "github.com/pion/dtls"
)

func main() {
    addr := &net.UDPAddr{IP: net.ParseIP("<IP_ADDRESS>"), Port: 6553}
    certificate, privateKey, err := dtls.GenerateSelfSigned()
    if err != nil {
        log.Fatal(err)
        return
    }

    config := &dtls.Config{
        Certificate:          certificate,
        PrivateKey:           privateKey,
        ExtendedMasterSecret: dtls.RequireExtendedMasterSecret,
        ConnectTimeout:       dtls.ConnectTimeoutOption(30 * time.Second),
        InsecureSkipVerify:   true,
        ClientAuth:           dtls.RequireAnyClientCert,
    }

    listener, err := dtls.Listen("udp", addr, config)
    if err != nil {
        log.Fatal(err)
        return
    }
    defer func() {
        listener.Close(5 * time.Second)
    }()

    for {
        conn, err := listener.Accept()
        if err != nil {
            log.Fatal(err)
            continue
        }

        go communicateData(conn)
    }
}

func communicateData(conn net.Conn) {
    buffer := make([]byte, 1024)
    for {
        defer conn.Close()
        amt, err := conn.Read(buffer)
        if err != nil {
            break
        }
        log.Printf("%s\n", string(buffer[:amt]))
    }
}

Would expect some way for the client to realize that it has to resend a message because the previous DTLS session is broken, but currently reading and writing on the session is still successful.
Your environment.

Version: Latest GIT tag

UDP doesn't really have connections, so we'd basically have to have a mechanism client side that's configured with a value for a timeout, after which we consider the server to be gone and attempt to re-establish a DTLS session. I'm not sure this needs to be part of the DTLS library, this is a reality of using UDP that you need to handle yourself, as what we consider to be a broken "connection" in UDP is highly application specific.
You need to do something like this in your client:
deadline := time.Now().Add(*timeout)
conn.SetReadDeadline(deadline)

nRead, addr, err := conn.ReadFrom(buffer)
if err != nil {
    ...
}

This only works if your client expects to always get a reply though, which is not necessarily the case with UDP.

I would imagine that if the server restarts you'd be getting errors though, as the TLS session is no longer valid. So it sounds like that's at least something to look at in your code, because you should be able to catch that case. If the server just dies, as in goes away but never comes back, you'd have to use to a timeout on the conn.

Turns out I'm wrong on being able to detect a restart. DTLS implementations silently ignore invalid records, so there's no way to detect that.

Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
invalid formatting, length, MAC, etc.).  In general, invalid records
SHOULD be silently discarded, thus preserving the association;
however, an error MAY be logged for diagnostic purposes.
Implementations which choose to generate an alert instead, MUST
generate fatal level alerts to avoid attacks where the attacker
repeatedly probes the implementation to see how it responds to
various types of error.  Note that if DTLS is run over UDP, then any
implementation which does this will be extremely susceptible to
denial-of-service (DoS) attacks because UDP forgery is so easy.
Thus, this practice is NOT RECOMMENDED for such transports.

Basically, DTLS only introduced reliability for the purpose of being able to complete a (modified) TLS handshake over a datagram transport. After that, it's back to being as reliable as the transport itself, so in the case of UDP not at all.
You'll need an application level mechanism, i.e a request-response cycle that you expect to complete within a certain window of time, to detect an issue like a server having gone away or having restarted and lost the session.

Got it,  makes sense.  Thanks for analysis.   Agreed that it seems that this should be more handled by the application side as per the nature of DTLS/UDP.  However, do you think the library should expose more protocol details to aid in that?  For instance should the sequence numbers on the DTLS packets be exposed in order for the application to detect gaps or maybe provide callbacks for a library gap detection?  It seems like the sequence number was designed to aid in these scenarios.

@daenney Also, do you think alerting (generating and receiving), should be exposed at all?

Hey @hjames9
We can expose statistics if that is helpful! I think that would be a great contribution, I am not sure what that would look exactly like yet though.
Maybe we can start with basics like bytes transmitted/received.
One thing you could do right now is set a custom logger and look at all the log messages we emit. You can pass in the constructor your own Logger instance and then process every message we generate (and react to them)

@daenney Understood your explanation on alerting i.e. should only be diagnostic and should be fatal for the session if used, but in general is not a best practice.
@Sean-Der Keeping live statistics might be helpful in this situation.   I'll educate myself on how crypto/tls handles it and see if anything useful can be replicated.
Thanks!

@Sean-Der Can you point me to where an API like this exists in crypto/tls?  I can try and replicate something similar here.

ref: https://www.cs.ru.nl/bachelors-theses/2018/Niels_Drueten___4496604___Security_analysis_of_DTLS_1_2_implementations.pdf
page 14:
"Closing a DTLS connection the implementation should send a close notify alert. This way, the peer knows the connection is ending"

Hey @tigersean
We close when we get a Close Alert
We also send a Close Alert when the user closes the connection.


HAWQ-227. Data locality downgrade by wrong insert host.

when we determin the insert host of a block, we should ignore the file contains only one block. because in this case, we cannot know which is the right insert host.  when hosts with same occur times exists we cannot know which is the right insert host either.

+1

+1, LGTM.


require consumes or produces?

Without requiring to state what is consumed or produced by a server, it's really up to the client to guess what format to send/receive, and up to the server to handle all the types it doesn't support with proper, known error responses.  A simple work around would be to require that consumes is required whenever a parameter of type body or formData are supplied, and produces is required whenever a schema is attached to a response code or the default response.

schema doesn't mean model anymore, it could also be a primitive. We can say it's mandatory of the type is object.
We could definitely not validate it using basic json schema as the values propagate.

If the response has a schema property, this means the content is in the body of the HTTP response, right? So if there is a response, there should be a produces property.

@ePaul - really? we should force people to define text/plain if they return a numeric value?

If the numeric value is in the body, it needs some media type (i.e. Content-Type header of the HTTP response). This could be text/plain, of course, or application/x.single-number-in-ascii, or even some JSON type (because a single number is also a valid JSON value in RFC 7159).

But is RFC 7159 accepted? It looks like it's a proposal. http://json.org/ suggest that only objects and arrays are valid JSON, while RFC 7159 suggests the change that JSON values are also valid JSON text.
It looks like IANA refers application/json to be  RFC 4627 which suggests that simple types are not officially supported for the mime type.
And let's face it, when was the last time you saw an API use application/x.single-number-in-ascii? :)

I don't really want to discuss which media-type is appropriate here, but just mention that one should be used. (I also think an API returning a single number/string/boolean is not a good idea.)
RFC 7231 says that each response with body should have a Content-Type header, except if the server has no idea what it is. I would guess in the case of an API described by an OpenAPI description you can't really say "I have no idea what this is".

Well, you can, and you do. You don't necessarily describe all the responses for example (in many cases it doesn't make sense). We can say that we're not going into the discussion of which mime-type is appropriate here, but if we end up saying produces and consumes are required in some cases, we need to address this as we will get support questions about it, or people would end up doing crazy things and the tools will suffer.

any news on this?

@whaley too bad GitHub's reactions don't have the one that I want.


crypto/init.c: use destructor_key even as guard in OPENSSL_thread_stop.

Problem was that Windows threads that were terminating before libcrypto
was initialized were referencing uninitialized or possibly even
unrelated thread local storage index.
Request covers even couple of other issues related to dllmain. This is alternative to #6627 and #6711.
1.0.2 and 1.1.0 labels are speculative in sense that not everything should be back-ported and those commits that should be won't necessarily cherry-pick.

Feedback is addressed.

I've spotted typo in commentary, MSCVRT vs. MSVCRT, which fixed in first post-approval commit. Since it's commentary-only change I claim that it doesn't invalidate approval status (unless somebody claims otherwise). But on top of that I did ossl_char -> variant_char rename, which certainly invalidates approval status. However! I leave lack of re-approval as option. In sense that request is not re-approved with variant_char, then I intend to merge commits up to this last one.

I don't really care how you name that type, so consider this +1.
But I wonder why you call it "variant"

But I wonder why you call it "variant"

There might be better options. "variant" can be used as adjective and does describe something that can change depending on situation. In this case depending on whether or not code is compiled for Windows.

9e4a1c3f65863b0175ddc534e232e63c4f82ea5c was the only that cherry-picked to 1.1.0. So that will be branch-specific requests...


Fixed game difficulty levels & dynamically changing snake speed accordingly in main.py

Fixed game difficulty levels & dynamically changing snake speed accordingly in main.py

Fixed game difficulty levels & dynamically changing snake speed accordingly in main.py


chore: setup package build and publishing pipeline

Add the package build logic to build the project for ESM and CJS. Additionally this PR adds the publishing pipeline that all the built code can also be published to npmjs.

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Requests Per Second Plot Breaks When There are too Many Unique URLs

Description of issue
Plotting requests per second breaks when locust has visited around 500 unique URLs
Expected behavior
Total requests per second works as long as needed
Actual behavior
It seems to break once you hit too many unique URLs.  I believe this is because locust gets the stats for every URL every time it updates the web ui.
Environment settings

OS: Windows
Python version: 3.7.3
Locust version: 0.10.0

Steps to reproduce (for bug reports)
I am using locust to test a retail point of sale rest api.  The api uses document SIDs in the url, so everytime I make a new transaction, I get 3-4 new urls.  Not only does this make analyzing the results harder, as I need to group the urls together with regular expressions in pandas, but i believe that it is breaking the plotting of requests per second as well.
I can hammer the api with requests that don't use the document SID in the url forever, but I can only run a few hundred transactions before the plotting breaks.
To make sure, I made 15 new receipts per second for about 30 mins and everything worked correctly.  Afterword, I changed my locust file to make a blank receipt and then request it's contents (generating a request on a new url) and was only able to run the load test for 2 mins before plotting broke.  (at around 500 unique urls)
Possible fix
I would love to be able to set the field that requests are grouped by to a string.  Something like:
response = self.client.post("/v1/rest/document" headers=self.header, json=payload, tag="creating a document")
but I'm not incredibly experienced, so this may not be as easy to implement as I'm hoping.
Also this implies that I'm correct as to why the requests per second plot is breaking.  Furthermore, this would save me (and people doing similar testing) from having to group api calls after running a test.

before the plotting breaks

what about it is broken?

Sorry, I was in a bit of a rush and totally forgot to add that.  Here's an example:

As you can see, the plot shows no data for each point in the second half, even though the rps at the top was constantly changing.

please give a clear description of the issue,  including details of what you are expecting and what is actually happening.   Please exclude all other information, conjectures, or ideas for possible fixes.  This issue report is packed with information that is completely irrelevant... which makes it difficult to follow.
(For example... I can't even tell if this is a bug report, or a feature request for tagging responses ...  it seems like both)

Fair, I'm a bit new to this if you can't tell.
Primarily, I want to fix the issue, but I believe that tagging would conveniently solve the bug as well.  Here is a revised bug report:
Description
Requests per second stops plotting under certain circumstances.
Expected behavior
The reported RPS in the locust web client should be graphed accurately in the total requests per second chart.
Actual behavior
Total Requests per second is not graphing properly under certain circumstances.
Generating Unique URLs:
Chart

JSON

Repeatedly hitting the same URL:
Chart

JSON

Environment Settings

OS: Windows and Arch Linux (running in a vm)
Python version: 3.7.3
Locust Version: 0.11.0

Steps to reproduce
Write a locust file that makes requests on a large number of unique URLs.  Once the number of requested URLs hits about 500, the graph breaks.

At risk of making more conjecture, here is where I believe the bug originates:

I believe the red bit is being truncated.  This is in web.py, starting at line 104

Have you tried adding name="string" to your request? ie
response = self.client.post("/v1/rest/document" headers=self.header, json=payload, name="creating a document")
unless I am mistaken, this is what you are after.

Wow, thanks for pointing that out.  That's exactly the feature I was looking for.
However, I'm going to leave this issue open because the total requests per second plot still breaks above 500 urls.

Fixed by #1060 if I'm not mistaken,


add support for Chocolately

Chocolately is the standard package manager for Windows; please add support for it

Hey!
Have you ever tried using Helmfile on windows?
I'm willing to do so myself but don't have a Windows machine for developing and even a test suite for running Helmfile on Windows.
I'm awaiting someone to contribute here :)

I tried, but no luck because of the PS1 files.  I can do the test work. However, you need to start replacing sh files with ps1 files.

@cilerler Thanks! Are you talking about shells scripts under https://github.com/roboll/helmfile/tree/master/test/integration specifically, or anything else?

Yes, since Shell can not be run on Windows, but Powershell can work on both platforms, those should be written PS1.  And then we may start to create a package for chocolate, I guess

@cilerler Thanks for clarifying!
I'm fine with co-maintaining PS1 version of the integration test script. (I'm pretty new to powershell and doubt I have time to fully migrate all the scripts to PS1 but co-maintaining should be feasible


Issue with trinkets (and maybe even NETS, haven't tested not enough trinket slots, but it might have an issue with it to)

Display issues with the purse menu that is showing the trinkets overlapping the purse menu.
Mod Version: 0.2.14
Fabric API: 0.92.2
Fabric Modloader Version: 0.16.0
Game Version: 1.20.1

or this might be a different mod, if it is let me know and I will find the actual mod issue.


[React-Native] New mutation edit does not reflect immediately when react-native rebundles except when i edit specific js file

Scenario:
I have a mutation in filename CreateProduct.gql
mutation createProduct($input: CreateProductInput!) {
  createProduct(input: $input) {
    clientMutationId
    instruction {
      __typename
      ...DisplayReceipt
    }
  }
}

that i use in ProductForm.js
when i edit CreateProduct.gql to
mutation createProduct($input: CreateProductInput!) {
  createProduct(input: $input) {
    clientMutationId
    instruction {
      __typename
     ... on fakeFragment {
       a
     }
      ...DisplayReceipt
    }
  }
}

it does not reflect in my usage in ProductForm.js unless i randomly add a line of code in ProductForm.js. I know this because the former returns a "Server missing query...." since there is no fakeFragment on my schema.
Is this specific to React Native only?

No it is not specific to React Native. My package replaces the import statement in the .js file with a variable declaration, meaning any file watchers don’t know to watch the .gql file. The only way for the changes in a .gql file to reflect is to do something that causes babel to run again.

Thanks for the super fast response. Do you think it is possible for the file watcher in my case watchman i think in react-native to watch for .gql? or in web using webpack?

Unfortunately, I'm not sure. I've only really used this package with my personal toolchain, which does not include watchman, and I let create-react-app handle webpack for me. I do know that regardless of whether watchman recognizes changes in the .gql files, whatever command watchman restarts will need to re-run babel or the changes still won't reflect. See the Caveats section of the README for an example of the start script I restart when I make changes to my .gql files.

Alright I'll look into more soon. What I noticed though that there is no such filepath ('node_modules/.cache/') created when im developing in react-native in my local directory.

Ah, ok, react-native may disable babel caching. If that's the case you can just ignore the part about deleting that folder, but you'll still need to rerun babel somehow on each .gql change so that the inline variable in the .js file can be updated (what my package does) based on the new contents of the .gql file.

Got it! if i have some time, ill try to look into configuring react-native to watch for .graphql. Do you think we should close this issue?

Understood. Really appreciate the work you have done! @detrohutt


Error critical!

We're sorry, but an unhandled error occurred. Please see the details below.
Class 'Al3xTig3r\BlogUtils\Components\Lang' not found...
.../public_html/plugins/al3xtig3r/blogutils/components/PrevAndNextPosts.php line 12

Bug fixed.
Thanks a lot for opening the issue! :)


SDIT-1114: 🔧 Move to new preprod prisoner search

Codecov Report
All modified lines are covered by tests :white_check_mark:
see 1 file with indirect coverage changes
:loudspeaker: Thoughts on this report? Let us know!.


I am unable to add commit or other git activity.

FYI: Also try uninstalling the vs code again.

Yesterday, I also shared some issue but vs code developer told me that it is known issue and fixed already. Why are we facing this problem again?

/gifPlease

Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, .gif files are preferred as they are displayed inline on GitHub. You may find https://gifcap.dev helpful as a browser-based gif recording tool.
If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording (Developer: Toggle Screencast Mode in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue.
Happy coding!

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


GLTF Lights import with wrong value due to specification change

Godot version
4.0 - rc2
Issue description
In blender 3.3 the light output in a GLTF file is in watts
in blender 3.4 the light output is in a new unit due to a specification change in GLTF
This means that when you import a light with blender 3.3 it will work properly in godot 4, but when you use blender 4.4 it will export the light power in a very high value.
The specification for GLTF is here and contains how the punctual lights now use the new units of measurement:
https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_lights_punctual/README.md
The change in blender is here:
https://github.com/KhronosGroup/glTF-Blender-IO/commit/3cf4d007bbf5ae5d9266e4be53e3200fdfcf8fc5
The discussion on why this was changed is here:
https://github.com/KhronosGroup/glTF/pull/2214
For the devs of GLTF: I would like if we had unit column in the .glb for the light unit used, as now files are incompatible when we make this change and or will require a user to export again, which makes original uploaders have to ensure a blender version, or the engine to check the file version.
From a user perspective it will break for them. I made this note here so that its shown on GLTF github too.
Perhaps even though a small change like this should have been a major version change.
Steps to reproduce

Open Godot 4 RC1/RC2 and import the file provided.
Open the light up, the light units will be wrongly set to a much higher value than 500 watts.

You can reproduce the issue running portable blender 2.3 and exporting a light, and also exporting another light from 3.4.
Minimal reproduction project
A 500 watt light from blender 3.4
lamp-big-500W-on.zip

Tagged as rendering too as @reduz or @clayjohn might want to use the new lighting unit too

I looked into this a few weeks ago but ended up convincing myself that it made no sense to import lights from blender and better create them directly in Godot. When exporting lights from Blender 3.4 there are now three modes: Standard, Unitless and Raw (how it used to export it). In Godot there used to be a line to convert Blender light units to Godot units but was removed in a refactoring (https://github.com/godotengine/godot/commit/3d76b91229c469879ec0eb42f54b5e2667270209#diff-fdf33f6fcd2b129d540ebd0e70fd04982b68e279cebfd9e96036d2fd7561c31fL5153).
The thing is, Godot by default uses a light unit that is more "artistic driven", so a direct conversion might be difficult. We could try and estimate a "good" conversion factor that looks good enough, which I tried, but It would look different depending on which mode you choose to export. Right now it just looks completely broken because the light is way too bright (another option is tweaking the exposure of your game so everything looks right with brighter lights, if all your lights are imported from Blender).
My rabbit hole ended when I tried again but with "Physically light units" activated, but it still looked broken. I think it should look right there, so there is probably a bug.

Ah, wonderful they finally moved to using physically based units.
On our end it should make it much simpler to convert intensity values accurately. When using physical light units it should be possible to just import the values as-is. When not using physical light units we can scale the value to something that is reasonable given the fact that there is no exposure by default

Without using physical light, assets are overexposed with the current import settings for both the old and the new units of light compared to how it is rendered in Blender. Since it is unfair to users to break backwards compatibility with old Blender assets, may I suggest to parse the version of the package that is used in Blender to export glTF files (https://github.com/KhronosGroup/glTF-Blender-IO), and use scaled or as-is values as @clayjohn suggested, when lux units are used in gtTF file.
The version from which they changed Watts to Lumen is 3.4.40. At the top of the exported glTF file this is shown:
{
    "asset" : {
        "generator" : "Khronos glTF Blender I/O v3.4.50",
        "version" : "2.0"
    },
    ...
}

I have verified that Blender 3.4 uses version 3.4.50 and Blender 3.3 uses v3.3.36.

That sounds like an excellent idea

An more general solution, is a light intensity slider on the import configuration editor GLTF files.
That would help people independent of Blender versions, or GLTF's exported from other Modelling software, and version changes related to light in the future. So they can always change the lights for all lights in their imported scene at once.

Looking forward to thus fix team! I'm currently planning out the pipeline with the artist.  I definitely want the option to try to import blender's lights.

A more general solution, is a light intensity slider on the import configuration editor for GLTF files. That would help people independent of Blender versions, or GLTF's exported from other Modelling software, and version changes related to light in the future. So they can always change the intensities for all lights in their imported scene at once.

This makes me wonder if light range should have a multiplier too, along with the attenuation curve (since these tend to work in tandem).

Right.
I think there's some confusion in this thread, because it's kinda a pretty complicated issue.
And also because I proposed a radical change in a popular specification, then withdrew that proposal, and then instead changed behaviour in a popular authoring tool based on the results of the complicated discussions surrounding that proposal, I suppose.
I guess I'll try to clear that up.

GLTF Lights import with wrong value due to specification change

in blender 3.4 the light output is in a new unit due to a specification change in GLTF

The discussion on why this was changed is here:
KhronosGroup/glTF#2214

To my knowledge, the KHR_lights_punctual GLTF specification has not changed as described in this issue #73624. In fact, if you check its commit history, you can see that it has hardly changed at all since 2018.
I proposed the linked PR because there was a lot of confusion and ambiguity across the various renderers about how (and whether) the specification was actually implemented. My own use case was that I simply wanted to be able to export with physically based units from Blender. But implementing the specification required a coefficient that wasn't explicitly defined, and when I both tried to infer it physically and later used a widespread industry standard, experimental exports following that spec were very, very wrong (overexposed) in renderers like Three.JS, Babylon.JS, and even the official Khronos group reference renderer.
Because of the ambiguity and incomplete implementations/documentation around various reference renderers, I concluded in despair at one point that changing the spec would be easier and less disruptive than fixing the Blender exporter.
However, the conclusion of the linked discussion was to not change the specification. Instead, we figured out how to implement the existing specification correctly in Blender, and we figured out why that didn't look right in the reference renderers and how they might handle it better in the future.

For the devs of GLTF: I would like if we had unit column in the .glb for the light unit used, as now files are incompatible when we make this change and or will require a user to export again, which makes original uploaders have to ensure a blender version, or the engine to check the file version.
From a user perspective it will break for them. I made this note here so that its shown on GLTF github too.
Perhaps even though a small change like this should have been a major version change.

To emphasize, the KHR_lights_punctual GLTF extension specification has not changed. This aspect of the GLTF format should still be fully compatible/remains the exact same AFAICT, and should not require either re-export nor adjustment of previously compliant tools.
What has changed is the default ways Blender exports to GLTF. The previous Blender GLTF export behaviour was incorrect. The new way now follows the spec correctly by default.

In Godot there used to be a line to convert Blender light units to Godot units but was removed in a refactoring (3d76b91#diff-fdf33f6fcd2b129d540ebd0e70fd04982b68e279cebfd9e96036d2fd7561c31fL5153).

When exporting lights from Blender 3.4 there are now three modes: Standard, Unitless and Raw (how it used to export it).

We could try and estimate a "good" conversion factor that looks good enough, which I tried, but It would look different depending on which mode you choose to export.

IIRC (and confirmed by re-reading the code):
"Standard" is the name I chose/convinced them to accept for the new, spec-compliant behaviour. The name is meant to suggest that this is the right one, because the other modes are actually technically wrong. This mode changes only two things compared to the previous behaviour: (1) We convert from total radiated power for punctual light sources, which Blender uses, to radiated power per steradian, which KHR_lights_punctual specifies, and (2) we then multiply by exactly 683 to convert from Blender's watts to GLTF/KHR_lights_punctual's lumens, which is a semi-arbitrary industry standard coefficient based on human peak perceptual luminous efficiency at 555nm green light.
"Unitless" is a new compatibility mode added because we discovered that the default exposure settings in basically all renderers (except for Filament) also didn't make much sense for compliant KHR_lights_punctual GLTF files. This mode applies the same Step 1 W→W/sr conversions as "Standard" for point-like light sources, but skips the Step 2 ×683 W→lm conversion. I.E. 1.0 in the GLTF is expected to map more or less directly to 1.0 RGB in your shaders.
"Raw" is the old, incorrect behaviour. All it does is just take the numbers you see in Blender, and save those directly in the GLTF file. If you reintroduce the removed light import code for Blender, and it worked before, then it should still work with "Raw". But again, this behaviour is incorrect. It ignores the units, and it also makes points lights significantly brighter than they should be in comparison to directional lights. If it worked correctly with Godot's GLTF import before, then that means that Godot's GLTF import was also non-compliant with KHR_lights_punctual.
To summarize. "Standard" is the only correct mode. "Unitless" is a compatibility mode for other renderers that aren't 100% to spec either. "Raw" is the old behaviour.

The relationships between the three export modes can be described as some very simple coefficients per light type. Using the old (incorrect, "Raw") Blender exporter behaviour, and internal light strengths (S), as a baseline:

Light Type
"Standard"-compliant (unit)
"Unitless" (unit)
"Raw" old behaviour (unit)

Point-like
S / (4π) * 683 (lm/sr)
S / (4π) (W/sr, or no unit)
S (W/sphere)

Directional
S * 683 (lm/m²)
S (W/m², or no unit)
S (W/m²)

All of this is implemented in def __gather_intensity() at lines 82 to 96 of exp/gltf2_blender_gather_lights.py in the glTF-Blender-IO code.
So assuming the aforementioned Blender-to-Godot lighting converter worked "correctly" for the (fundamentally incorrect) old/"Raw" Blender GLTF export behaviour, you could revive it simply by multiplying by (1/683) for directional lights, and ((4*pi)/683) for point-like light sources.

Right now it just looks completely broken because the light is way too bright (another option is tweaking the exposure of your game so everything looks right with brighter lights, if all your lights are imported from Blender).

Without using physical light, assets are overexposed with the current import settings for both the old and the new units of light compared to how it is rendered in Blender.

If I had to guess, without any investigation or Godot lighting knowledge, I'd say this is probably because you're skipping the 683 coefficient needed on import to bring large lumens values down to the 0-1.0 range that most engines are scaled to show. I.E. You may be using what we eventually decided to call the "Unitless" workflow.
A typical houselamp is actually like 700 lumens (or 56lm/sr), which is naturally going to be way overexposed if an engine is scaled for "1.0" to be a reasonable light strength.

Since it is unfair to users to break backwards compatibility with old Blender assets, may I suggest to parse the version of the package that is used in Blender to export glTF files (https://github.com/KhronosGroup/glTF-Blender-IO), and use scaled or as-is values as @clayjohn suggested, when lux units are used in gtTF file.

Seeing as I initiated the discussions and wrote the changes linked to from this issue, I feel I should offer a recommendation:

A compliant GLTF importer should work by default with the "Standard" option provided by Blender. The "Standard" option is the only spec-compliant export mode for GLTF/KHR_lights_punctual in Blender. If your GLTF importer does not handle this format correctly, then your GLTF importer is technically broken according to the spec. (Whether it's just overexposed (the 683 term), which is just an issue with defaults and easily changed, or conflating steradians with full spheres (the 4pi term), which breaks internal consistency across light types.)
To maintain backwards compatibility, files that are labelled as having been exported from versions of Blender that didn't have the spec-compliant "Standard" option can instead be interpreted according to the old/"Raw" behaviour, using the coefficients in the table above.

OR: Alternatively, if you are indeed already using a unitless workflow, you could stick with that, bring back the old Blender converter for old files, and maybe add a note in the docs about choosing "Unitless" when exporting new files from Blender.

A more general solution, is a light intensity slider on the import configuration editor for GLTF files.
That would help people independent of Blender versions, or GLTF's exported from other Modelling software, and version changes related to light in the future. So they can always change the intensities for all lights in their imported scene at once.

…When I originally added three different options to Blender's exporter, donmccurdy had some concerns about diluting the spec:

My worry (with non-spec-compliant options in general) is creating confusion in the glTF ecosystem. E.g. we add these three options, another tool tries to support these three modes and adds a fourth, etc. until there are multiple de facto behaviors outside of the spec. I'm mostly inclined to leave the dedicated "just edit the JSON" workflow to the dedicated tools like Gestaltor or the VSCode extension.

As a user I generally want my software to have options, but I do think leaving flexibility 100% open-ended in an importer also kinda defeats the whole purpose of having a standard file format. In this specific case, we decided that adding the two compatibility options to the Blender exporter was worth it, as long as we kept "Standard" as the default and labelled it as the only spec-compliant option. But I didn't mean that to create ambiguity which propagates through the ecosystem, and I would feel partly responsible for weakening the standard if that does end up happening.

It's common for level design tools in general to offer a way to multiply the energy or range of all lights in the scene, so that you can perform quick adjustments if the scene is too dark/bright.

As somebody who largely doesn't use Godot, but has used other 3D software, I think "light intensity slider" for multiplying all selected lights would be a more generally useful tool to have when working on a entire scene in general though, not just when importing.

Oh also IMO somebody should edit the title/OP of this issue so that other people who try to figure out GLTF lighting in the future don't get the wrong idea that the specification changed spontaneously one day.

@aaronfranke Do you know why Blender unit conversion code was removed in https://github.com/godotengine/godot/pull/64977?

It was an ugly hack that I hated, at first I thought it was worth it anyway but now I think we should instead fix Blender. Godot should only aim to support what's actually in the spec. As long as Godot is able to import the Khronos test model correctly, Godot is correct. If Blender uses a different unit, Blender is wrong and needs fixing. https://github.com/KhronosGroup/glTF-Sample-Models/tree/adf2abe718a61a6859b29fab481bfbbdfc05df24/2.0/Lights

As long as Godot is able to import the Khronos test model correctly, Godot is correct.

Actually, the lighting test models in that repository tend to be misleading in that they are generally designed around unitless light strength values, without any regard for whether the values they specify actually make any sense for a physically based scene.

My own comment https://github.com/KhronosGroup/glTF/pull/2214#issuecomment-1279494303:

Note that this also means that all of the example files— If they display "correctly" in the reference viewers— Are all actually ridiculous dark— And that is compensated for by all of the rendering engines having default exposures that are way too bright. E.G. the EmissiveStrengthTest file above has emissiveStrengths of 2, 4, 8, and 16. If these are in cd/m**2 (nits) as per the spec, then according to WolframAlpha the darkest one is lower than the "luminance of a twilight sky" and the brightest is still six times darker than the "a heavy overcast day". The lowest value is so dark, actually, that apparently it is outside of the range of human sight, at "0.7 × minimal luminance for human color vision". For comparison, LCD panels seem to range from 200 nits to over 1,000 nits. So the results of that example file definitely shouldn't look as bright and bloom-y as they do, with any kind of sane default exposure settings assuming units per spec.

In the file you linked:
        "KHR_lights_punctual" : {
            "lights" : [
                {
                    "intensity" : 5,
                    "…": "…"
                {
                    "intensity" : 10,
                    "…": "…"
                },
                {
                    "intensity" : 10,
                    "…": "…"
                },
                {
                    "intensity" : 1.0000003576278687,
                    "…": "…"
                }
            ]
        }

KHR_lights_punctual specification:

Property
Description
Required

…
…
…

intensity
Brightness of light in. The units that this is defined in depend on the type of light. point and spot lights use luminous intensity in candela (lm/sr) while directional lights use illuminance in lux (lm/m2)
No, Default: 1.0

If we interpret the light intensities in the reference file you're using, according to the units in the specification:

Intensity
Equivalent To

Red Point Light
5 lm/sr
5 candles

Green Spot Light
10 lm/sr
10 candles

Blue Spot Light
10 lm/sr
10 candles

Cyan Directional Light
1 lm/m^2
4 full moons

For comparison, a typical home lightbulb should be around 60 lm/sr, while direct sunlight is around 100,000 lm/m^2.
Basically, the test file is very dim compared to reasonable real-world light sources according to the spec. And if Godot wants to expose defaults that will look good with real-world-aligned physically based GLTF lights, then the image you posted is way too bright.

For reference, this is how gltf_viewer from Filament renders that test model on default camera settings when you disable its built-in IBL and Sun:

To get it to look anything look anything like how Godot (and the reference README) shows it, you have to crank the exposure time, ISO, and aperture to basically ridiculous levels:

It was an ugly hack that I hated, at first I thought it was worth it anyway but now I think we should instead fix Blender. […] If Blender uses a different unit, Blender is wrong and needs fixing.

As the person who wrote the current implementation of KHR_lights_punctual intensity conversions for Blender, and having spent a lot of time talking with somebody from the GLTF spec and Three.JS project about it in the process, I am confident in saying that the current KHR_lights_punctual export from Blender is "right", and compliant to the specification, when exported using the default "Standard" mode.

@will-ca Makes sense then, if the test asset is not conforming to to the specification for reasonable camera settings, then the test asset is wrong and we need a better test asset. Once we have that, we can fix Godot to match Blender, since as you say Blender matches the written spec even though it does not match the example file.

@aaronfranke @RevoluPowered This got lost and suggestions how to remedy this?

@fire We need an example file in order to proceed.

Like https://github.com/godotengine/godot/files/10783648/lamp-big-500W-on.zip ?

This issue also seems to appear when Importing .blend files directly within Godot

@fire We don't just need the .glb file, we also need a screenshot of what it's supposed to look like. Otherwise it's impossible for us to figure out how to import it correctly.

is it possible we can get a scaling value for .blend, .gltf light intensity imports? Not using any lights from blender is kind of an insane 'solution' artistically speaking.

Did it myself with a @tool script
https://gist.github.com/RepComm/7be8d605fc393d4a181f2658698d5d24

Attach to a Node3D (I just create one called fix_gltf_lights)
Assign your scene root

The script listens to scene child entered, initialization, and "fix now" boolean in editor block. Drag a blend file with lights into the scene (have to release mouse to see effects, scene enter isn't triggered until you fully place the model for some reason).
It works by using an arbitrary "light_energy_max" float (set in editor) to trigger scaling, and uses an arbitrary "light_energy_scale_factor" (set in editor) to multiply by.

is it possible we can get a scaling value for .blend, .gltf light intensity imports? Not using any lights from blender is kind of an insane 'solution' artistically speaking.

FYI the workaround is to export the .gltf from blender with the lights set to "RAW". This lets you use lights from blender normally.

Appreciate the tip, and I'm addition for my use case of .blend files the script is still useful. Would love a simple checkbox fix for .blend even if that checkbox is a godot import setting

FYI the workaround is to export the .gltf from blender with the lights set to "RAW". This lets you use lights from blender normally.

Note this behavior is technically non-compliant with the GLTF spec. And it doesn't just apply a uniform multiplier to light brightness; IIRC it makes point lights proportionally… 4π times too bright, compared to directional lights (steradians vs 360° flux and flux/m²) or something like that?
We debated whether to include the "Raw" option at all, or avoid enabling fragmentative implementations. (I was in favor of having it for compatibility/artist control.)
So "Raw" results in "incorrect" behavior, producing invalid "GLTF files" that won't work right anywhere else. Though maybe Godot's import accounts for it.

@will-ca Thanks for the information. In order to make Godot more compliant, we need test files, along with screenshots of what those are supposed to look like, that are fully compliant with the expected units. Otherwise, we do not have a baseline for what the "correct" behavior is supposed to be.


Can a single Docker image serve different purposes api, worker by overriding the command on docker-compose

At the moment we build three images purely to use the same Python package but different entry points. While researching how to use celery beat it occurred to me that the same worker should be used and there should not be a need to build a new image.
I read up on various articles and it's possible to commit the ENTRYPOINT and CMD portions in the Dockerfile and provide them in the docker-compose as a command directive
celery-beat:
  build: ./project
  command: celery -A core beat -l info

The Docker best practices article also demonstrates the proper use of ENTRYPOINT and CMD
ENTRYPOINT ["s3cmd"]
CMD ["--help"]

where s3cmd is the command that the container runs where as --help is the default parameters provided to the container.
We need to know what affect this has when using Kubernetes, but well worth the investigation as it would mean we would be down to a single image per image.
Reference articles:

Handling Periodic Tasks in Django with Celery and Docker
Dockerizing Django with Postgres, Gunicorn, and Nginx
Best practices for writing Dockerfiles

Refactored configuration from a current WIP, also note the depends_on has been updated:
  # Applicaiton API:
  # - In development we read secrets from .env.development
  # - Provides a FastAPI based API that runs using uvicorn in development
  api:
    container_name: ${PROJ_NAME}-api
    build:
      context: .
      dockerfile: Dockerfile.api
    command: "uvicorn acacia.api:app --host=<IP_ADDRESS> --port=80 --root-path=/api --reload"
    env_file:
      - .env.development
    restart: unless-stopped
    ports:
      - "8000:80"
    volumes:
      - ./src/acacia:/opt/acacia
    depends_on:
      - redis
      - db

  # Worker: is a celery based worker process that runs in the background
  worker:
    container_name: ${PROJ_NAME}-worker
    build:
      context: .
      dockerfile: Dockerfile.api
    command: "watchmedo auto-restart --directory=./ --pattern=*.py --recursive -- celery --app=acacia.celery.app worker --pool=gevent --loglevel=INFO --queues=celery"
    env_file:
      - .env.development
    restart: unless-stopped
    volumes:
      - ./src/acacia:/opt/acacia
    depends_on:
      - redis

  beat:
    container_name: ${PROJ_NAME}-beat
    build:
      context: .
      dockerfile: Dockerfile.api
    command: "celery --app=acacia.celery.app beat --loglevel=INFO"
    env_file:
      - .env.development
    restart: unless-stopped
    volumes:
      - ./src/acacia:/opt/acacia
    depends_on:
      - redis

requires you to drop EXEC and CMD from the Dockerfile

Worth reading this section in Kubernetes configuration spec
apiVersion: v1
kind: Pod
metadata:
  name: configmap-demo-pod
spec:
  containers:
    - name: demo
      image: alpine
      command: ["sleep", "3600"]

As of 3a7b4de1cc98bba6b57bc871e404addb37f43539 we have moved to using a single Dockerfile for both workers and api end points.
It now also assumes that we have a single codebase across all services.
Containers configuration will ensure security.
While the approach is pending further inspection, it generally makes maintaining codebases much simpler.


export ColorScale and Legend classes

Hi,
Does d3plus-react currently include the ColorScale component? I tried to import it as a stand-alone component, but it didn't work.
Thanks.

Unfortunately no, right now d3plus-react only exports Viz-type components (exported here). The Viz component is simply just a small wrapper for the raw JavaScript behavior (check out out), so it probably wouldn't be too hard to create components like this for the ColorScale and Legend.


Specify CUDA version for login node builds

Description
Currently, specifying the MFC_CUDA_CC flag can cause builds to fail on login nodes where the system can't determine the CUDA version to build for. This adds a compiler flag to specify the CUDA version explicitly. To ensure that rearranging the build process doesn't break, I force CMAKE to find CUDA when the MFC_CUDA_CC flag is set.
Fixes #(687)
Fixes https://github.com/MFlowCode/MFC/issues/687
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Something else

Scope

[x] This PR comprises a set of related changes with a common goal

If you cannot check the above box, please split your PR into multiple PRs that each have a common goal.
How Has This Been Tested?
Load modules for specific system
rm -rf build/staging
export MFC_CUDA_CC=XX where XX is a compute capability
Build GPU MFC on Phoenix and Delta

What computers and compilers did you use to test this:
See above

Checklist

[x] I have added comments for the new code
[ ] I added Doxygen docstrings to the new code
[ ] I have made corresponding changes to the documentation (docs/)
[ ] I have added regression tests to the test suite so that people can verify in the future that the feature is behaving as expected
[ ] I have added example cases in examples/ that demonstrate my new feature performing as expected.
They run to completion and demonstrate "interesting physics"
[ ] I ran ./mfc.sh format before committing my code
[ ] New and existing tests pass locally with my changes, including with GPU capability enabled (both NVIDIA hardware with NVHPC compilers and AMD hardware with CRAY compilers) and disabled
[ ] This PR does not introduce any repeated code (it follows the DRY principle)
[ ] I cannot think of a way to condense this code and reduce any introduced additional line count

If your code changes any code source files (anything in src/simulation)
To make sure the code is performing as expected on GPU devices, I have:

[ ] Checked that the code compiles using NVHPC compilers
[ ] Checked that the code compiles using CRAY compilers
[ ] Ran the code on either V100, A100, or H100 GPUs and ensured the new feature performed as expected (the GPU results match the CPU results)
[ ] Ran the code on MI200+ GPUs and ensure the new features performed as expected (the GPU results match the CPU results)
[ ] Enclosed the new feature via nvtx ranges so that they can be identified in profiles
[ ] Ran a Nsight Systems profile using ./mfc.sh run XXXX --gpu -t simulation --nsys, and have attached the output file (.nsys-rep) and plain text results to this PR
[ ] Ran an Omniperf profile using ./mfc.sh run XXXX --gpu -t simulation --omniperf, and have attached the output file and plain text results to this PR.
[ ] Ran my code using various numbers of different GPUs (1, 2, and 8, for example) in parallel and made sure that the results scale similarly to what happens if you run without the new code/feature

Mat Colgrove's advice: https://forums.developer.nvidia.com/t/cannot-compile-on-login-node/282759

@max-Hawkins let me know the status of this. Will merge when it is ready (it passed Phoenix  tests), just need to confirm it works fine on Delta - perhaps you already checked this.

Tested on both Delta and Phoenix after removing the entire build dir. All we had to do was set the NVHPC_CUDA_HOME environment variable. It just took me longer than it should have to realize this.


Surrender Button added

PR Description 📜
Added a surrender button which when clicked asks for confirmation and if it confirmed. It removes the current player who surrendered.
If only 2 people are playing then the other becomes the winner
else the game continues.
Fixes #560

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for review.

## Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

@ayush-t02 Please merge my previous PRs before merging this one. https://github.com/ChromeGaming/Dot-Box/pull/700 https://github.com/ChromeGaming/Dot-Box/pull/684


[5.9] Add a compatibility layer for SwiftSyntax

When renaming methods this new file can contain deprecated declarations to keep clients building.

@swift-ci please test

@swift-ci Please test

@swift-ci Please test Windows


Faking a date range

We're using and love graphql-faker, but we've run into an issue were we need to have dates between some range.
Faker.js seems to have this
faker.date.between('2015-01-01', '2015-12-31'); //returns "2015-04-03T20:10:12.819Z"
But I don't see it implemented here:
https://github.com/APIs-guru/graphql-faker/blob/82c3dd0af5c818dc3e9df91f528e3269c8dba15b/src/fake.ts#L78
It seems to just be future or past. Am I misreading it?
This is a great project, thanks so much for doing it!

@Robvio Thanks 👍
I want to add a few other small fixes into the next release.
So will try to release tomorrow.

@Robvio Released as<EMAIL_ADDRESS>🎉