unable to run GTS on a custom dataset

The module seems to run fine with the provided datasets.
But it throws error on when I've included a custom dataset.
Errortrace:
MWPToolkit/mwptoolkit/model/Seq2Tree/gts.py line 220, in train_tree
current_num = current_nums_embeddings[idx, i - num_start].unsqueeze(0)
IndexError: index 124 is out of bounds for dimension 1 with size 118

I'm not sure the specific reason. But you could check the value of these variables below.
dataset.copy_nums
dataset.num_start
dataset.generate_list
dataset.out_idx2symbol

they are all about the decoder's vocabulary of GTS, or other models. Pleasr check if they are currect.
Second, you may pay attention to the inputs(batch_data) of the model.
At the line where throw the error , current_nums_embeddings means all number embedding at current decoding step (generate number + copy number). The size of it should be [batch_size, 118, hidden_size] , 118 is the sum of generate size (static in different batches) and copy size (dynamic in different batches, it's up to max(batch_data["num size"])). You could check if batch_data["num size"] is currect.
Another point is batch_data[num stack], in GTS, if a number appears twice or more in question sentence (one number has two position). So it has two optional symbols to generate. Which symbol to choose is decided while decoding. So target token is replaced by ``UNK_token, when decoding, choose the symbol which has maximal score as target symbol.  batch_data["num stack"]means candidate symbols forUNK_token.If UNK_tokenis not replaced by candidate symbols currectly, it may cause theindex out of bounds```.  So please check batch_data["num stack"] if is currect.

Code for building number stack
MWPToolkit/mwptoolkit/data/dataset/abstactdataset.py line 192
    def _build_num_stack(self, equation, num_list):
        num_stack = []
        for word in equation:
            temp_num = []
            flag_not = True
            if word not in self.dataset.out_idx2symbol:
                flag_not = False
                if "NUM" in word:
                    temp_num.append(int(word[4:]))
                for i, j in enumerate(num_list):
                    if j == word:
                        temp_num.append(i)

            if not flag_not and len(temp_num) != 0:
                num_stack.append(temp_num)
            if not flag_not and len(temp_num) == 0:
                num_stack.append([_ for _ in range(len(num_list))])
        num_stack.reverse()
        return num_stack

Code for choosing the target symbol according to maximal score
MWPToolkit/mwptoolkit/model/Seq2Tree/gts.py line 357
    def generate_tree_input(self, target, decoder_output, nums_stack_batch, num_start, unk):
        # when the decoder input is copied num but the num has two pos, chose the max
        target_input = copy.deepcopy(target)
        for i in range(len(target)):
            if target[i] == unk:
                num_stack = nums_stack_batch[i].pop()
                max_score = -float("1e12")
                for num in num_stack:
                    if decoder_output[i, num_start + num] > max_score:
                        target[i] = num + num_start
                        max_score = decoder_output[i, num_start + num]
            if target_input[i] >= num_start:
                target_input[i] = 0
        return torch.LongTensor(target), torch.LongTensor(target_input)

So I looked into the variables,
apparently the values are:

there are a few target tokens, who exceed beyond the specified num
I'd previously patched them:
target_t = torch.LongTensor([t if t<118 else 117 for t in target_t])
But its definitely screwing something during training.

I encountered a similar problem.
I think one possible reason is that: the text of equation/question has a different format. Eg. you are using "x=1+2" as the equation but the data loader is expecting "1+2".


[KYUUBI #6666] Upgrade spark ranger plugin to 2.5.0

:mag: Description
Issue References 🔗

This pull request fixes #6666
Describe Your Solution 🔧
Bump ranger version to 2.5.0
Release notes: https://cwiki.apache.org/confluence/display/RANGER/Apache+Ranger+2.5.0+-+Release+Notes
Types of changes :bookmark:

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Test Plan 🧪
Behavior Without This Pull Request :coffin:
Behavior With This Pull Request :tada:
Related Unit Tests

Checklist 📝

[ ] This patch was not authored or co-authored using Generative Tooling

Be nice. Be informative.

Can we make the CI happy? Thank you @Madhukar525722

Sure, I will work. Spark tests are failing with

check ranger policy file *** FAILED ***
Line 24 is not expected. The file (/home/runner/work/kyuubi/kyuubi/extensions/spark/kyuubi-spark-authz/src/test/resources/sparkSql_hive_jenkins.json) is out of date.  Please regenerate it by running dev/gen/gen_ranger_policy_json.sh. Expected "    "[policyItems" : [ {]", but got "    "[conditions" : [ ],]" (PolicyJsonFileGenerator.scala:79)

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

Project coverage is 0.00%. Comparing base (7198c72) to head (88e1e12).
Report is 7 commits behind head on master.

Additional details and impacted files
@@          Coverage Diff           @@
##           master   #6692   +/-   ##
======================================
  Coverage    0.00%   0.00%
======================================
  Files         684     684
  Lines       42237   42279   +42
  Branches     5755    5765   +10
======================================
- Misses      42237   42279   +42

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

HI @yaooqinn , CI is smiling. Please review
@bowenliang123
After running the policy generator and updating the json. The test was failing due to order mismatch. Thats why I have used serialisation.

Thanks, merged to master


Functionality - Installation

Hi,
For my review, I am trying to check-off this one,

Functionality

[ ] Installation: Does installation proceed as outlined in the documentation?

I have two problems.

It is very easy to install your package, run the tests, and still miss the fact that PolyChord and/or PyPolyChord are completely missing. I think this could be improved. E.g., since this is a Python package and PolyChord v1.14 is required, why not make PyPolyChord a requirement and indicate that it is missing?

Without PyPolyChord, I could run the tests quite quickly (and a few of them were skipped). Upon installing PyPolyChord, I ran the tests. I saw lots of Polychord Warning: Non deterministic loglikelihood, and it ran for a long time without finishing. A note about this warning and some indication about how long this step might take would be helpful.

It is very easy to install your package, run the tests, and still miss the fact that PolyChord and/or PyPolyChord are completely missing. I think this could be improved. E.g., since this is a Python package and PolyChord v1.14 is required, why not make PyPolyChord a requirement and indicate that it is missing?

The tests are deliberately designed to run without PyPolyChord so people who only use C++ and Fortran likelihoods can perform tests without installing PyPolyChord. Similarly the tests check the code required for C++ and Fortran likelihoods without needing a compiled executable (which would be a pain for the user). Another reason for this approach is that it allows the use of continuous integration with travis CI, which would otherwise be very difficult or impossible due to the need to download PolyChord from sourceforge with a login.
You are correct that this is a bit confusing - I have added a warning to the tests which triggers if PyPolyChord is not installed, reminding the user that it isnt installed but is only needed if they want to use Python likelihoods.

Thanks for your responses. I’m happy that the first one is now addressed. About the second one, I’ll have to get back to you tomorrow after running the tests again. I’ll try to isolate which test caused that behaviour, whether other messages were printed, and tell you my version numbers etc.

sounds great, thank you very much!

Sorry, I spoke too soon. I just checked the change https://github.com/ejhigson/dyPolyChord/commit/6ba7ec0a02e645ff7b3e17890e8785f2b24de417. It looks good, except that the warning could be printed if PyPolyChord is present but mpi4py isn’t.

Well spotted! Fix in fc4a90ce51c4fd1affab284671b9393f97401081

Problem
After git pulling today (latest commit fc4a90ce51c4fd1affab284671b9393f97401081), I found the same as yesterday,
andrew@andrew-laptop:~/repos/dyPolyChord$ nosetests &> nosetests.log
andrew@andrew-laptop:~/repos/dyPolyChord$ more nosetests.log
............................F/home/andrew/repos/dyPolyChord/dyPolyChord/nlive_allocation.py:49: UserWarning: Smoothing has added turning points to nlive allocation when dynamic_goal=0. I am using the unsmoothed nlives instead.
  'instead.'), UserWarning)
Polychord Warning: Non deterministic loglikelihood
Polychord Warning: Non deterministic loglikelihood
Polychord Warning: Non deterministic loglikelihood

The warning is repeated many times and it doesn't finish in a reasonable time.
Version numbers etc
My versions are
python -V
Python 2.7.15rc1

>>> numpy.__version__
'1.15.1'
>>> nestcheck.__version__
'0.1.8'
>>> scipy.__version__
'1.1.0'

PolyChord_v1.15.tar.gz

The installations all went OK, with the exception of PyPolyChord, where I had to export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libmpi_cxx.so to avoid a missing symbol problem with MPI. I believe though that my installation is fine, though unfortunately there aren't any tests, e.g.,
andrew@andrew-laptop:~/codes/PolyChord$ python run_PyPolyChord.py
...
 ____________________________________________________
|                                                    |
| ndead  =         1039                              |
| log(Z) =           -1.73781 +/-            0.24593 |
|____________________________________________________|
Install matplotlib and getdist for plotting examples

Isolating tests that fail
By investigating further I found that the test that doesn't finish in a reasonable time is test_dynamic_evidence. When I remove that one by adding return True
andrew@andrew-laptop:~/repos/dyPolyChord$ git diff
diff --git a/tests/tests.py b/tests/tests.py
index 8067f7f..4194899 100644
--- a/tests/tests.py
+++ b/tests/tests.py
@@ -128,6 +128,7 @@ class TestRunDyPolyChordNumers(unittest.TestCase):

     def test_dynamic_evidence(self):
         """Test numerical results for nested sampling with dynamic_goal=0."""
+        return True
         dynamic_goal = 0
         dyPolyChord.run_dypolychord(
             self.run_func, dynamic_goal, self.settings,

I find though that two other tests fail
andrew@andrew-laptop:~/repos/dyPolyChord$ nosetests
............................F.F.....
======================================================================
FAIL: Test numerical results for nested sampling with
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/andrew/repos/dyPolyChord/tests/tests.py", line 163, in test_dynamic_both_evidence_and_param
    self.assertEqual(e.count_samples(run), 556)
AssertionError: 426 != 556

======================================================================
FAIL: Test numerical results for nested sampling with dynamic_goal=1.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/andrew/repos/dyPolyChord/tests/tests.py", line 182, in test_dynamic_param
    places=12)
AssertionError: 0.06839158405509836 != 0.029776073688009493 within 12 places

----------------------------------------------------------------------
Ran 36 tests in 4.719s

FAILED (failures=2)

Tweaking precision_criterion
i reduced the precision_criterion as your code indicates that this could be related to the non-deterministic errors.
andrew@andrew-laptop:~/repos/dyPolyChord$ git diff
diff --git a/tests/tests.py b/tests/tests.py
index 8067f7f..c7d3513 100644
--- a/tests/tests.py
+++ b/tests/tests.py
@@ -111,7 +111,7 @@ class TestRunDyPolyChordNumers(unittest.TestCase):
             # errors. These occur due in the low dimension and low and nlive
             # cases we use for fast testing as runs sometimes get very close
             # to the peak where the likelihood becomes approximately constant.
-            'precision_criterion': 0.01,
+            'precision_criterion': 0.001,
             'seed': 1,
             'max_ndead': -1,
             'base_dir': TEST_CACHE_DIR,

I find that it then runs alright, but still fails
andrew@andrew-laptop:~/repos/dyPolyChord$ nosetests
............................F/home/andrew/repos/dyPolyChord/dyPolyChord/nlive_allocation.py:49: UserWarning: Smoothing has added turning points to nlive allocation when dynamic_goal=0. I am using the unsmoothed nlives instead.
  'instead.'), UserWarning)
FF.....
======================================================================
FAIL: Test numerical results for nested sampling with
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/andrew/repos/dyPolyChord/tests/tests.py", line 162, in test_dynamic_both_evidence_and_param
    self.assertEqual(e.count_samples(run), 556)
AssertionError: 525 != 556

======================================================================
FAIL: Test numerical results for nested sampling with dynamic_goal=0.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/andrew/repos/dyPolyChord/tests/tests.py", line 143, in test_dynamic_evidence
    self.assertEqual(e.count_samples(run), 548)
AssertionError: 554 != 548

======================================================================
FAIL: Test numerical results for nested sampling with dynamic_goal=1.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/andrew/repos/dyPolyChord/tests/tests.py", line 181, in test_dynamic_param
    places=12)
AssertionError: 0.09796131954595269 != 0.029776073688009493 within 12 places

----------------------------------------------------------------------
Ran 36 tests in 5.565s

FAILED (failures=3)

andrew@andrew-laptop:~/repos/dyPolyChord$ git pull
Updating fc4a90c..70a9e62
Fast-forward
 tests/tests.py | 34 ++++++++++++++++++----------------
 1 file changed, 18 insertions(+), 16 deletions(-)
andrew@andrew-laptop:~/repos/dyPolyChord$ export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libmpi_cxx.so
andrew@andrew-laptop:~/repos/dyPolyChord$ nosetests
............................FFF.....
======================================================================
FAIL: Test numerical results for nested sampling with
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/andrew/repos/dyPolyChord/tests/tests.py", line 164, in test_dynamic_both_evidence_and_param
    self.assertEqual(e.count_samples(run), 1093)
AssertionError: 920 != 1093

======================================================================
FAIL: Test numerical results for nested sampling with dynamic_goal=0.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/andrew/repos/dyPolyChord/tests/tests.py", line 145, in test_dynamic_evidence
    self.assertEqual(e.count_samples(run), 1169)
AssertionError: 924 != 1169

======================================================================
FAIL: Test numerical results for nested sampling with dynamic_goal=1.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/andrew/repos/dyPolyChord/tests/tests.py", line 183, in test_dynamic_param
    places=12)
AssertionError: -0.029540931478677097 != -0.05323120028149568 within 12 places

----------------------------------------------------------------------
Ran 36 tests in 33.492s

FAILED (failures=3)

Gotcha! The random seeding is working ok - the problem was a rogue division of integers when computing how many samples to use
samp_tot = init_run['logl'].shape[0] * (nlive_const / ninit)
With a fresh download of the latest PolyChord, running in python 2, the fix in 84ee43ac91e2ddd3f88bd92847de87d202d8398d is now working for me whereas without the fix I got the exact same errors as you. I work almost exclusively in python 3 and this must have somehow slipped past my previous python2 testing.
Thank you very much for your help finding this @andrewfowlie! If you confirm this is working for you I will close the issue

andrew@andrew-laptop:~/repos/dyPolyChord$ nosetests
....................................
----------------------------------------------------------------------
Ran 36 tests in 28.845s

OK

Great! Thanks for investigating this.


StorageCluster: Update the storagecluster uninstall annotations

We were not updating storagecluster before because of which changes were
not reflecting in the object. Update the storagecluster with
annotations.
Co-authored-by: Raghavendra Talur<EMAIL_ADDRESS>Signed-off-by: Nitin Goyal<EMAIL_ADDRESS>

Hi @jarrpa Without this change uninstall does not work. Can you pls take a look.
cc @raghavendra-talur

/override ci/prow/images


Modernize build toolchain with rollup

Update build toolchain while keeping built artifacts and dev process mostly the same.
Changes

Rollup replaces requirejs and monaco-plugin-helpers in our build script

kustoWorker.js and kustoMode.js now share code in a main file, instead of duplicating code (1)

When not in CI, source maps are now created
yarn watch works again

Uses Rollup to build .js files instead of tsc

/release/esm no longer bundles /node_modules

(1)
Before

After

Another question how come the kustoMode size is reduced from 118K to 39K? is it tree-shaking?

Another question how come the kustoMode size is reduced from 118K to 39K? is it tree-shaking?

I've updated imports with type when possible, which caused some code to not be included in that bundle.


error: "HttpRequest" has no attribute "user"

Hi there,
I have the following code:
class MyView(RedirectView):
    def get_redirect_url(self, *args: Any, **kwargs: Any) -> Optional(str):
        if self.request.user.is_authenticated():
            do_something_with_user()

Which results in:
$ mypy
> api/users/authentication/views.py:28: error: "HttpRequest" has no attribute "user"

Which is probably because the HttpRequest class doesn't really have the user but it is almost always added through the authentication middleware (either User or AnonymousUser).
So how do I fix this?

It would be great to have a general solution for this -- Django has several things which are added by middleware (the other one which immediately springs to mind is the session attribute).

I don't know if it makes sense to do, but I changed my request type to WSGIRequest, which subclasses HTTPRequest and adds a user attribute (as AbstractUser).
It silenced the error at least....

It could be added as a plugin, like, "if some AuthenticationMiddleware", add user to some HttpRequest". We need some way to describe this fact in the middleware class.


fix: Use upstream cache persist

Use upstream cache persist

@wtrocki I think the repo is incorrect

This will be still ongoing.


Issue89 code independent files

Motivations:

Trying to separated PR #75 , #76 and #79  into smaller independent parts
This PR focuses on adding the files from those PR that do not directly affect the code
I did not really review them since this is mostly documentation (that can evolve) and I focus on the lower-level tasks
Since they cannot affect the code or unit tests directly, it is safe to merge this PR

Proposition:

It is best practice to not put ipynb into the code directly but rather in a directory dedicated to documentation
Thus I created a /doc folder where I put all ipynb and where I suggest we put all documentation-related files
Later we can set-up automated documentation using sphinx or doxygen, these specialized libraries typically work with a dedicated /doc directory.

Yes ! That looks like good practice indeed
Good, I'll check sphinx and doxygen once the core is well written also :)


Missing options to set detect scan arguments

It is not possible to set all detect scan arguments like:
    #       --detect.project.version.name
    #       --detect.project.name
    #       --detect.included.detector.types
    #       --logging.level.detect
    #       --detect.source.path

and so on.
Kindly regards

Hi @DavidGailmannVW these can be set by passing environment variables like:

DETECT_PROJECT_VERSION_NAME
DETECT_PROJECT_NAME
etc.

This is described in "Additional Detect Properties" in the README. This is a standard way to use Detect. We opted to only pass things by environment variable to avoid dealing with escaping and cross-platform issues going from the NodeJS runtime to the command line.

Perfect ist works. Thank you very much :)


Where's the setCursor?

Where's the setCursor? I updated to 0.13.29. It's gone

And what is searchCursor? There is no such thing in dts

app.workspace.activeLeaf.view.editor.setCursor(cursor)


ldeep: 1.0.10 -> 1.0.11

Motivation for this change
Update to latest upstream release 1.0.11
Things done

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

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

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

Result of nixpkgs-review pr 119985 run on x86_64-linux 1

1 package built:

ldeep


App Crashes on Huawei after latest EMUI update

Device is Huawei CLT-L29 (P20 Pro) and the EMUI version is 9.0.0 (this is the update after which SimpleToDo stopped working I believe) and the android version is 9.
As the title says, after the latest update (which I believe was an EMUI update and not android itself, which I think also included some security patches from the December 1 Android security patch) the application cannot launch. I will click it and it will flash for a second as if the screen was going to change to the application, but then it immediately closes. Same happens when trying to enter the application from the widget's title button.
I'd be happy to give it a go in terms of debugging but any pointers as to how I could do that would be appreciated. (I'm assuming using Android Studio?)

Hello, @KGMIT ! Probably your problem is not in the new EMUI version, but in the critical bugs of the app itself. Try to clear the app data or reinstall it, as @esmoak advised.
Also wait for the next app update. It contains a lot of stability improvements :)


Hero button desktop too small

ISSUE - energise button on hero image too small on desktop
ACTION - increase size of button on hero image

I will use this as an example of what could have been changed with further development after the MVP stage.


Run May 2022 Event

@caseydietrich because I did not change the loop function in your NAM download code to loop over 30 days instead of 31, we now have this 9 digit jump in numbering moving from April 30 to May 1. However, we are not missing any on the NAM download files. Can I run the convert to fort.22 program with this jump in numbering, or do all the NAM download files need to be numbered perfectly sequentially (no jumps)?

@caseydietrich I wrote a python script to correct this numbering jump so the question is now moot.

@ththelen In the queue submission script (grb2owi.csh), please add this line before the grb2owi script is called:
setenv PATH /full/path/to/grb2owi-master:$PATH
where you replace the full path to where that folder is located in your files. (cc: @anardek )

Good morning @caseydietrich, the grb2owi script finished running yesterday. The script ran to completion and the only error message I saw is snipped below. Even with this 'FATAL ERROR' message, the script still produced a fort.221 and fort.222 file. I think the 043 NAM file was one of about 10 files I had to download by hand because the automatic download script timed out. It is strange that only this file out of the ones I manually downloaded and renamed prompted the error.

That said, the other 486 files processed without incident, so I would like to believe the fort.22* files are fine even if one of the NAM timesnaps failed to process. Would you agree with this assessment?

@ththelen The way to check is to type:
grep "DT=" fort.221 > junk
which will dump all of the snap header lines into a junk text file. In that file, you can check (a) does the file contain the correct overall number of snaps, and (b) do all of the snaps proceed in 3-hr increments. (cc: @anardek )

@caseydietrich thanks for the tip. There was an erroneous time stamp. I redownloaded the 043 NAM file and re-ran the grb2owi program. The second time it ran without errors.

River discharge for May event: 2000 ft^3/s = 60 m^3/s
60% of flow into estuary from Cape Fear River: 60 m^3/s / 0.6 = 100 m^3/s total flow rate to apply

Water Level Offset
Discussion item: what water level offset should we use for the May 2022 runs.
NOAA Wrightsville gauge: avg. verified - avg. predicted = 0.135 m
NOAA Wilmington gauge: avg. verified -avg. predicted = 0.0565 m

First run with old +0.15m offset crashed out. Using +0.1m for the offset as the average of Wilmington and Wrightsville

@caseydietrich my Apr/May 2022 first leg run crashed out again. The error that I get in the padcswan run file is below.

... lots of iostat =               64

I check the headers for both the fort.221 and fort.222 files using your grep "DT=" fort.221 > junk command. Everything looks good there. Both files have the same number of lines (488), and have headers that proceed on in 3 hour increments like the following screen capture of the first several fort.221 file headers.

Do you have any suggestions for where I should start troubleshooting this error?

@ththelen Can you please share your 221/222 files with me? Post them (in /share/jcdietri/For/Casey) and change the permissions (using 'chmod 777' and then the file/folder name). (cc: @anardek )

@ththelen Thanks for sharing. These files contain only the header lines -- the fields of surface pressures and winds are missing. Were there any errors when you built the 221/222 files? (cc: @anardek )

@caseydietrich the first time I ran the grb2owi script I got the error documented here: https://github.com/NCSU-CHAZ/Sunny-Day-Flooding/issues/20#issuecomment-1307213631
I deleted the fort.221/222 files from the previous grb2owi run, redownloaded the 043 NAM file, and re-ran grb2owi. The results are below. There are no error messages at any of the 488 time snaps.

time snaps 54-467. no error messages

@ththelen I'm not sure what the error is. I will need to look at the wind files and script to try to debug, but they are too large to share. Can we look together on Mon morning? (cc: @anardek )

@caseydietrich I am in Carolina Beach on Monday, but I am free Tuesday before 3:00 pm. If there is a time that works for you Tuesday before 3:00, let me know and I will make a calendar event.
When we meet, I would like to discuss the errors documented in this thread and the errors when I try to run the Nov 2021 simulation on the remeshed, cut down NC9 rev2.2 mesh. Those issues are (roughly) documented in the last couple posts in the thread linked here: https://github.com/NCSU-CHAZ/Sunny-Day-Flooding/issues/21#issuecomment-1312509499. I can provide more detail when we meet.

@ththelen Sure thing, can you visit my office hours at Tue 1-2pm? (cc: @anardek )

Yes, I'll be there

@caseydietrich good news and bad news from our troubleshooting session this morning.
Bad news: fixing the environment path in the grb2owi.csh submission script did not fix the headers-only error in fort.22* files. Even with the corrected file path, we are not interpolating data from the NAM files, just reading in the headers. I will come to class this afternoon to discuss.

@caseydietrich please find the .tgz file with all the NAML time snaps at the file path linked below. I think the permissions should be set such that you can view.
/gpfs_common/share01/jcdietri/For/Casey/221115-NAML-Thelen

@ththelen I created the 221/222 files and posted them here:
/gpfs_common/share01/jcdietri/For/Thomas/221115-NAM
(cc: @anardek )

@caseydietrich could you please confirm that the script to build the fort.22* files ran to completion?  When I submitted the job this morning, the run errored out 2% of the way through the simulation. The error messages (copied below) look like the same messages I was seeing when I tried to submit the job with the headers only fort.22* files.

@caseydietrich I scrolled through the whole fort.221 and fort.222 files in vi and I think I found the issue. It is not that the fort.22* builder did not run to completion. Instead, there is one time snap in the fort.221 file and three snaps in the fort.222 file that have headers only and no data associated with those 4 headers. The first of these is the<PHONE_NUMBER> time stamp called out in the error message above.
I think I can work around this problem by deleting the four headers that have headers only. Assuming there is nothing magical about the 3-hour time increment such that our simulation would crash if we skip a handful of time steps in the fort.22* files, I do not anticipate that missing this data will noticeably affect our runs.
Time steps missing fort data:
fort.221:<PHONE_NUMBER>
fort.222:<PHONE_NUMBER><PHONE_NUMBER>00<PHONE_NUMBER>

Update @caseydietrich: I just found this blurb in the ADCIRC fort.22 documentation. It looks like the 3 hour time step must be kept constant, so mix fix to delete headers missing data will not work. It looks like we will have to find a way to get the grb2owi script to run without outputting any blank headers

I am also concerned by the fact that ADCIRC was reading in data from April 1 at all. I am trying to run this simulation over the dates April 10-30. Does that mean my fort.221 and fort.222 files should start on April 10 as well instead of April 1 as we currently have it set up?

@ththelen This is a good catch. I don't know why those four snaps would be skipped/omitted from the files. I tried to work-around this issue by copying the snaps immediately preceding those skipped snaps. For example, I copied the file for<PHONE_NUMBER> to also be used as<PHONE_NUMBER>. This is sub-optimal, because the same wind snap would be used twice in a row, but it would keep the timing okay.
I did this and posted the files here:
/share/jcdietri/For/Thomas/221116-NAM
but they look to be the same size as the previous set, so I am not confident that this attempted work-around was successful. Do you have an automated way to check whether all snaps are present in the files?
To your other question, we need to adjust the fort.22 file to tell ADCIRC to skip the first snaps in the files. In the fort.22 file, the second line has an integer as the number of blank snaps to be inserted at the start of the simulation. If this number is positive, then ADCIRC will insert blank snaps. If this number is negative, then ADCIRC will skip that many snaps in the 221/222 files. So if you want to skip the first 14 days, you would use:
( 14 days ) * ( 8 snaps per day ) * ( -1 to tell ADCIRC to skip snaps ) = -112
(cc: @anardek )

@caseydietrich I do not have an automated way to check this, but by opening the fort.22* in vi and searching for "20220" I can skip to each file header and look see if there is any data below it (e.g. below).

It looks like the new fort.22* files you shared are still missing data at the same snaps. I am going to try to copy the missing data from the prior time snaps using the vi text editor to implement your workaround. I just need to figure out the right vi keystrokes to pull this off

@ththelen In that same folder, I added two more options: (1) repeating snaps as described above; (2) using only the snaps every 6 hr (instead of every 3 hr); and (3) redownloading (from the NOAA site) the four snaps that were troublesome. Please look at these files and see if any are promising. (cc: @anardek )

Good morning @caseydietrich, question about running the second leg of the May 2022 event here. Yesterday when we talked you said that the fort.26 file should have the start date of the second leg (May 9) as the start date as shown in Figure 1 below. My question now is about the fort.221 and fort.222 files. If I am using 0 as the NWBS value in my fort.22 file, should my fort.22* files to run the second leg have their first time snap as the start of the first leg (Apr 30) or as the start of the second leg (May 9)?

Figure 1

Figure 2

Hello @caseydietrich and @anardek, I finished my write-up on the results for the May 2022 simulation. The attached Jupyter Notebook printout has water level, wind, and wave comparisons. Please do spend some time with this document when you have a chance. The document is fairly long because it contains all the code I used to import and plot data, but if you skip to headers/bolded sections and figures you should be able to navigate it fairly quickly.
CE596_Proj1_May2022_NC9rev2.1+0.1m.pdf


Support request body overrides in Ruby

Codecov Report

Merging #978 into master will increase coverage by 0.01%.

@@             Coverage Diff              @@
##             master     #978      +/-   ##
============================================
+ Coverage     85.12%   85.13%   +0.01%
  Complexity       40       40
============================================
  Files           340      340
  Lines         13309    13328      +19
  Branches       1508     1509       +1
============================================
+ Hits          11329    11347      +18
- Misses         1547     1548       +1
  Partials        433      433

Impacted Files
Coverage Δ
Complexity Δ

...former/ruby/RubySampleMethodToViewTransformer.java
98.23% <100%> (+0.23%)
0 <ø> (ø)
:x:

...en/discovery/transformer/ruby/RubySampleNamer.java
91.66% <83.33%> (-8.34%)
0 <ø> (ø)

Continue to review full report at Codecov.

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


Local Clone

This is the task for the local clone in the bootcamp/inclass folder

this has been done and is currently in the branch feature/HTML


Use the Context API of React

https://reactjs.org/docs/context.html

is noted, gotta make my mind about this one, since I had some issues with properly setting the board id via context


Add notification feature

:sparkles: What kind of change does this PR introduce? (Bug fix, feature, docs update...)
It's a feature.
:arrow_heading_down: What is the current behavior?
It can not check and request notification permission.
:new: What is the new behavior (if this is a feature change)?
Support check and request notification permission
:boom: Does this PR introduce a breaking change?
No.
:bug: Recommendations for testing
:memo: Links to relevant issues/docs
:thinking: Checklist before submitting

[x] All projects build
[x] Follows style guide lines (code style guide)
[x] Relevant documentation was updated
[x] Rebased onto current develop

Thank you for contributing. We will introduce this feature in our next release.


Vagrant box does not exist

following the instructions at http://vccw.cc/#h2-2, i get the following message at the "vagrant box add" step:
$ vagrant box add vccw-team/xenial64 --name=vccw-team/xenial64
The box 'vccw-team/xenial64' could not be found or
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Atlas, please verify you're logged in via
`vagrant login`. Also, please double-check the name. The expanded
URL and error message are shown below:

URL: ["https://atlas.hashicorp.com/vccw-team/xenial64"]
Error: The requested URL returned error: 404 Not Found

Operating System: Ubuntu 16.04
Vagrant Version: 1.8.6
Virtual Box Version: 5.1.34

You can try few things, first is to update Vagrant because i guess it tries to fetch box from the old source list and second is simply define new source like here https://github.com/hashicorp/vagrant/issues/9442#issuecomment-363080565


[Feature Request] Add support for Faraday proxy

Hi,
I tried to get this working myself by pulling the weaviate-ruby repo and langchainrb, but could not get it to work.
I couldn't get bundler to use the local Gem versions for some reason, I think due to Homebrew overriding the path, or something.
So thought I'd ask for a feature request, rather than bang my head against gem dependencies, as I was getting no where fast.
Here's my Git Diff:
% git diff
diff --git a/lib/weaviate/client.rb b/lib/weaviate/client.rb
index d957ac7..c57b9ed 100644
--- a/lib/weaviate/client.rb
+++ b/lib/weaviate/client.rb
@@ -5,7 +5,7 @@ require "graphlient"

 module Weaviate
   class Client
-    attr_reader :url, :api_key, :model_service, :model_service_api_key, :adapter
+    attr_reader :url, :api_key, :model_service, :model_service_api_key, :adapter, :proxy

     API_VERSION = "v1"

@@ -23,7 +23,8 @@ module Weaviate
       api_key: nil,
       model_service: nil,
       model_service_api_key: nil,
-      adapter: Faraday.default_adapter
+      adapter: Faraday.default_adapter,
+      proxy: nil
     )
       validate_model_service!(model_service) unless model_service.nil?

@@ -32,6 +33,7 @@ module Weaviate
       @model_service = model_service
       @model_service_api_key = model_service_api_key
       @adapter = adapter
+      @proxy = proxy
     end

     def oidc
@@ -100,7 +102,7 @@ module Weaviate
     end

     def connection
-      @connection ||= Faraday.new(url: "#{url}/#{API_VERSION}/") do |faraday|
+      @connection ||= Faraday.new(url: "#{url}/#{API_VERSION}/", proxy: proxy) do |faraday|
         if api_key
           faraday.request :authorization, :Bearer, api_key
         end

A proxy feature would be super useful in debugging connection issues.
Perhaps a better way to do this, to ensure other connection options are also supported, would be to allow a hash of connection options passed to the Client, as seen in this example I found online:
conn_options = { ssl: {verify: false} }
conn_options[:proxy] = "http://localhost"
conn = Faraday.new(url, conn_options) do |conn|
  # middleware ...
  conn.adapter :em_http
end

Thanks,
Ryan

@ethicalhack3r Have you tried passing adapter: :em_http in the initializer? What's your use-case, is it storing multiple vectors in parallel?

@andreibondarev Hi! Not sure if adapter: :em_http is relevant, but perhaps I'm misunderstanding your response.
The use case is to use a web proxy see the raw HTTP requests and responses that Faraday makes, so that I can debug connection problems.
But I think it would be a good idea to be able pass arbitrary Faraday connection options within a Hash.
Hope that makes sense.

@ethicalhack3r Over the long-term I'd like to switch to using Net::HTTP native library instead of requiring the faraday dependency. Do you have any thoughts here?


Fix string interpolating in scala path

Specific property of single quotes in Bash is that it does not interpolate variable in string.
For example:
name=John
echo 'name=$name'
# name=$name
echo "name=$name"
# name=John

As a result Scala directory is not added to path in .bashrc => you cannot use scala.
Example of such wrong .bashrc:
# Some more alias to avoid making mistakes:
# alias rm='rm -i'
# alias cp='cp -i'
# alias mv='mv -i'

export PATH=~/scala-$SCALA_VERSION/bin:$PATH

@hseeberger great! Is this one already available on docker hub?

Yes: 8u141_2.12.4_1.0.2

@hseeberger great. And what about 0.13.16?

Sorry, but I can't and won't maintain a multi-dimensional matrix of releases.

@hseeberger that's sad. Nevertheless, thank you for your work!


Chart.js 3.0.0-rc.5: Plugins are not registered correctly if used for specific chart instances.

Expected Behavior
I expect to be able to specify a plugin for a specific chart instance without having to register it globally
Current Behavior
Plugin is not effective. Not all plugin lifecycle events seem to be called when adding a plugin to a specific chart instance.
Steps to Reproduce
https://codepen.io/santa-85/pen/BaQgqYe?editors=1111
To see correct behaviour, add chartjsPluginAnnotation to the Chart.register call
Environment

Chart.js version: 3.0.0-rc.5
Link to your project: https://github.com/valor-software/ng2-charts/pull/1276

@santam85 did this happen in other beta/RC versions?

@etimberg I started testing this only since the first rc version, but I suspect it was there for a while.

The afterRegister / afterUnregister hooks are not called (obviously) on instance plugin. Annotation plugin registers its elements in those hooks, so you'd need to do that manually for it to work.
The elements are not actually exported in that plugin, so this is an oversight there.

The afterRegister / afterUnregister hooks are not called (obviously) on instance plugin
It was not that obvious to me. I would have expected the plugin to be registered when that particular instance of the chart is rendered...

@kurkle how do you suggest I proceed with this? It is not clear to me from the documentation of either the plugin or chart.js itself that if a plugin is used only on an instance, there's a chance it would not work, depending on its implementation. At this point I am even asking myself what's the point of adding a plugin only to an instance, if I need to register all the elements and defaults globally anyway.

I added some more documentation on the plugin hooks and added some flow charts on how create/update work. There are other hooks (start/stop) that get called for all plugins on a per-chart basis when a plugin is added/removed from the chart instance.
This specific issue with the annotation plugin is because it was never written to handle being applied inline. Depending on the plugin, and what is needs to do, inline can make sense. For example, a plugin to draw the framerate of the chart animations could likely be done with no options, defaults, or registered elements so adding inline is totally fine.

At this point I am even asking myself what's the point of adding a plugin only to an instance, if I need to register all the elements and defaults globally anyway.

That might be the reason annotation is not designed to work inline. It would anyway need to register its elements and defaults globally, so its no different than disabling it by default.


Prevent 2FA to overwrite an existing contract

Problem
As we know, NEAR Protocol can deploy only one smart contract per account, and some power users may have a smart contract deployed to their account.
NEAR Wallet provides 2FA by deploying a special multisig contract connected to the Contract Helper.
As of today, the wallet doesn't verify if there's a pre-existing smart contract in the account, deploying the 2FA contract in a way that overwrites any pre-existing contract (and its state!).
This behavior can lead to irreversible and disastrous data loss.
Expected Behavior
2FA deployment fails if there's already a contract deployed to the account.
Steps to reproduce

create a new account on NEAR Wallet (testnet or mainnet)
deploy a random smart contract (e.g. the Status Message from near.dev)
test the contract writing a few messages in the account and viewing them
deploy the 2FA
repeat step 3

Technically is not exactly a bug, but from a usability point of view, we should at least alert the user and ask if they are good to overwrite the existing contract.

Duplicate of #2261


urlparse.urljoin restricts URL patterns

The documentation for urljoin reveals that it has some very strange behavior.  Calling build(... , base_url="https://example.com") and also having a method @get("//unrelated.com/users") means that the method would execute on "https://unrelated.com/users".
Is this the intended behavior? I personally think it is very confusing. The following code snippet does not work as one might expect:
request = utils.Request("METHOD", "/api.php?id={id}", {}, None)
uplink_builder.client = http_client_mock
uplink_builder.base_url = "https://example.com/feature"
request_preparer = builder.RequestPreparer(
    uplink_builder, request_definition
)
return_value = request_preparer.prepare_request(request)
assert return_value[0] == "METHOD"
assert return_value[1] == "https://example.com/feature/api.php?id={id}"
assert return_value[2] == {}

The above code snippet fails, as return_value[1]=https://example.com/api.php?id={id}.
Should we consider using a simple path.join() on URLs? Or should we allow for the complex, yet fairly convoluted behavior? If we want to allow for convoluted behavior (and continue using urljoin), I think it's worth raising an exception if base_url is not a true "base" (since its child paths will be trimmed anyway)

I used urlparse.urljoin because its behavior corresponds with how Retrofit builds URLs:

Following the rule "Endpoint values which contain a leading / are absolute" from above, the code snippet has the expected behavior.
However, I agree that their behavior is nebulous, and the scenario you presented is a clear example of that.

Wow.. I never expected to close this issue as "by design". I guess it's just something that I was entirely not used to. But, just to be stubborn, my complaint still stands!

@brandonio21  Definitely a warranted complaint. If we're keeping this behavior, I think adding an explanation of how urls are joined in the documentation is necessary.


feat: new feature 6

Description
copilot:summary
Related Issue

Explanation of Changes
copilot:walkthrough
Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] Implemented tests for new features.
[ ] I tested the features already implemented.
[ ] Added usage examples in the readme.

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


upgrade simple line icons fonts to v2.2.2

Is it came from https://github.com/thesabbir/simple-line-icons ?

不是的 我自己fork你改的。


Beta Testing

Could really use this plugin and was attempting to be a beta tester.  I have added it to Sentry via pip install https://github.com/getsentry/sentry-auth-saml2/archive/master.zip and it installs successfully but I don't see it in the Auth page.  It says there are no providers to be found.
Any tricks?

It's disabled behind a switch.
Add SENTRY_FEATURES['organizations:saml2'] = True into your sentry.conf.py. You also need sentry 8.20.0. More stuff is being added into 8.21.0 yet, so functionality may be slightly limited as this is under active development.

Awesome thanks.  I'm on 8.20.0 right now and have this running in Swarm so it's easy to upgrade.  Thank you for the fast response


dnf-json: Test metadata expire handling

There may be some issues with handling expired metadata. I have a test in lorax-composer for this and may be able to rewrite it to apply to dnf-json.

The behavior I observed on 3/31 was that coreutils-8.31-10 was trying to be installed by osbuild-composer/osbuild but the mirror had a newer version (8.32-4). There had been 2 builds since 8.31-10 was built in February so there was more than enough time for the metadata to have expired and caught one of the newer versions (8.32-3 was built on 3/11). After removing the cache in /var/cache/osbuild-composer/ it worked fine.

I have a test, but it passes. Can't make progress until I can reproduce it, so closing this for now until I observe it again and capture the cache directory for examination.
https://github.com/bcl/osbuild-composer/tree/master-test-metadata is my WIP branch.


Pro: Taglist create new tag on Mobile - 'Enter' Key Issue in Multi-field Form

Reproduction
https://formkit.link/20a202d89d02fed6d00b270f73d73c5d
Describe the bug
I am trying to setup a taglist input that accepts new tags from the user. It works as expected on desktop but I have some trouble creating new tags when used on mobile devices.
Hitting 'Enter' takes me to the next field instead of creating a new tag. It did work when taglist was the only field I had in the form.
I have tested this on Firefox mobile and Chrome. On Firefox it works as expected.
You can reproduce the issue by opening the playground link above on a mobile device using a chromium based browser.
Environment
• OS: Android 12
• Browser chrome
• Version 117

So far we’ve been unable to reproduce this. Has it been fixed?

Closing this for now until a reproduction is produced.


Support for RustDesk Server.

Hi,
Requesting you to look into RustDesk If we could manage to create an app for its self hosted server - https://github.com/rustdesk/rustdesk-server/blob/master/docker-compose.yml and add it to your App Store.
This server is available on https://github.com/WisdomSky/CasaOS-Coolstore - And hence the suggestion as I know if someone can implement this properly it can only be you.

@kaumudpa Thanks for the suggestion! You can suggest it to be added here: https://community.bigbeartechworld.com/c/big-bear-casaos/bigbearcasaos-suggestions/40


refactor conv block and generalized unet to use LayerInfo abstraction

Codecov Report

Merging #57 (3e35095) into main (df86d51) will decrease coverage by 0.04%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #57      +/-   ##
==========================================
- Coverage   71.80%   71.76%   -0.05%
==========================================
  Files          71       71
  Lines        4802     4802
  Branches     1047     1047
==========================================
- Hits         3448     3446       -2
- Misses       1031     1032       +1
- Partials      323      324       +1

Flag
Coverage Δ

unittests
71.76% <ø> (-0.03%)
:arrow_down:

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

Impacted Files
Coverage Δ

meddlr/metrics/functional/image.py
78.57% <0.00%> (-1.30%)
:arrow_down:

Continue to review full report at Codecov.

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


Avoid unneeded installation tasks run

Don't run installation tasks when Vault is already installed with the
required version.
This is to prevent playbook runs to report unwanted changes.

Cool, thanks!


iOS plugin fails to build after Locker iOS library update to v3

Error:
SwiftFlutterLockerPlugin.swift:61:23: error: initializer for conditional binding must have Optional type, not 'String'
                    guard let secret = secret else {

This is because after Locker was migrated to swift in v3.0, the retrieveCurrentSecret success callback is now not optional source.

Hey, thanks for using the package.
Fix is out on pub.dev (2.0.1).


"address-of-packed-member" warning

I ran into this issue when trying to build the garnet network simulator (step 3).
build/Garnet_standalone/base/inet.hh:355:45: error: taking address of packed member of 'ip_opt' may result in an unaligned pointer value [-Werror=address-of-packed-member]
Is this a warning that I can ignore? If it has to be fixed, can you please provide a way to fix it?
Thank you.

I ran into this issue when trying to build the garnet network simulator (step 3).
build/Garnet_standalone/base/inet.hh:355:45: error: taking address of packed member of 'ip_opt' may result in an unaligned pointer value [-Werror=address-of-packed-member]
Is this a warning that I can ignore? If it has to be fixed, can you please provide a way to fix it?
Thank you.

Hi , Have you installed all packages necessary to build gem5? If yes, then please ignore this and try to build it? let me know of during the run-time you are facing issues

Hi,
I tried to rebuild this in Ubuntu (previously tried to build it in CentOS and got the "address-of-packed-member" warnings). It's now working great but I have to ignore "maybe-uninitialized" warnings.
Thanks!


More docs improvements

Main improvement is prioritising the "generic" Windows setup over the VS one, as it covers all the dependencies. This makes the OS setup docs all cover the same thing: installing dependencies and command-line builds.
Also more specific Linux requirements and not listing "building" under "prerequisites" in most of the docs.

Thank you!


HBASE-25190 Create an hbase-tool module and move here standalone tool…

…s bundled with core
Creates new hbase-tool module that depends on hbase-server.
Moves the preupgrade validator tool here from hbase-server.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
6m 24s
Docker mode activated.

 U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

I've been getting pinged lately about why the preupgrade check tool isn't in something easy to get without a while new hbase install. This would be a nice incremental improvement.
What about putting this module in hbase-operator-tools?

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 50s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 37s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 34s
master passed

+1 :green_heart:
compile
3m 40s
master passed

+1 :green_heart:
shadedjars
8m 55s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 53s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m  1s
the patch passed

+1 :green_heart:
compile
2m 48s
the patch passed

+1 :green_heart:
javac
2m 48s
the patch passed

+1 :green_heart:
shadedjars
6m 36s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 42s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
174m 24s
root in the patch passed.

219m  1s

Subsystem
Report/Notes

Docker
Client=19.03.13 Server=19.03.13 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 802c1b42bc86 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 70d2f37ee3

Default Java
2020-01-14

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/1/testReport/

Max. process+thread count
6791 (vs. ulimit of 30000)

modules
C: hbase-server hbase-tool . U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 22s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 35s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 36s
master passed

+1 :green_heart:
compile
2m 22s
master passed

+1 :green_heart:
shadedjars
6m 42s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
2m 41s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 21s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 25s
the patch passed

+1 :green_heart:
compile
2m 23s
the patch passed

+1 :green_heart:
javac
2m 23s
the patch passed

+1 :green_heart:
shadedjars
6m 34s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
2m 57s
the patch passed

_ Other Tests _

-1 :x:
unit
322m  3s
root in the patch failed.

357m 45s

Subsystem
Report/Notes

Docker
Client=19.03.13 Server=19.03.13 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 09a974ae9197 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 70d2f37ee3

Default Java
1.8.0_232

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/1/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-root.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/1/testReport/

Max. process+thread count
5268 (vs. ulimit of 30000)

modules
C: hbase-server hbase-tool . U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
2m 32s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 28s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  2s
master passed

+1 :green_heart:
checkstyle
2m 15s
master passed

+1 :green_heart:
spotbugs
12m  5s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 46s
the patch passed

+1 :green_heart:
checkstyle
2m 14s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
xml
0m  3s
The patch has no ill-formed XML file.

+1 :green_heart:
hadoopcheck
19m  1s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1 3.3.0.

+1 :green_heart:
spotbugs
13m  8s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 36s
The patch does not generate ASF License warnings.

68m 41s

Subsystem
Report/Notes

Docker
Client=19.03.13 Server=19.03.13 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/2/artifact/yetus-general-check/output/Dockerfile

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

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle xml

uname
Linux 30a28bda8957 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 70d2f37ee3

Max. process+thread count
122 (vs. ulimit of 30000)

modules
C: hbase-server hbase-tool . U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 28s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 32s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 12s
master passed

+1 :green_heart:
compile
2m 47s
master passed

+1 :green_heart:
shadedjars
6m 40s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 21s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 59s
the patch passed

+1 :green_heart:
compile
2m 50s
the patch passed

+1 :green_heart:
javac
2m 50s
the patch passed

+1 :green_heart:
shadedjars
6m 33s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 37s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
164m 48s
root in the patch passed.

202m 53s

Subsystem
Report/Notes

Docker
Client=19.03.13 Server=19.03.13 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux a6455f5a0031 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 70d2f37ee3

Default Java
2020-01-14

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/2/testReport/

Max. process+thread count
6751 (vs. ulimit of 30000)

modules
C: hbase-server hbase-tool . U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 30s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 31s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 39s
master passed

+1 :green_heart:
compile
2m 23s
master passed

+1 :green_heart:
shadedjars
6m 35s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
2m 37s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 25s
the patch passed

+1 :green_heart:
compile
2m 26s
the patch passed

+1 :green_heart:
javac
2m 26s
the patch passed

+1 :green_heart:
shadedjars
6m 32s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
2m 56s
the patch passed

_ Other Tests _

-1 :x:
unit
322m 14s
root in the patch failed.

356m 56s

Subsystem
Report/Notes

Docker
Client=19.03.13 Server=19.03.13 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 25179c38ec28 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 70d2f37ee3

Default Java
1.8.0_232

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/2/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-root.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/2/testReport/

Max. process+thread count
5956 (vs. ulimit of 30000)

modules
C: hbase-server hbase-tool . U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2552/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

Moving tools to hbase-tool means we can not use the tool in hbase-server module any more, what if later we find out that we need to use this tool in hbase-server? What's the plan?
And what is the plan for hbase-mapreduce module? We want to make it depend on hbase-tool on make hbase-tool depend on it or they are completely no relationship?
And what is the plan for the shaded module? We used to have a hbase-shaded-server, and once we created the hbase-mapreduce module, we changed the shaded module to hbase-shaded-mapreduce. So what is the plan for this new hbase-tool module? Have you written it down somewhere?
Why not write a design doc before writing the code? You just do what you want, without telling others your 'plan'. I just asked about what is the scope of the new module, then you put up a bunch of changes without design doc, without consensus?


Dear Vether

I saw your work and I am interested in this project.
But there is not enough with review data.

Yes ! This project only just start ! I'm working hard to develop !

Hi, nice project. What's the difference between this and https://vagmi.vercel.app? Thank you

Oh! God! This project is exactly the same as my idea.

Hi, nice project. What's the difference between this and https://vagmi.vercel.app? Thank you

Oh! God! This project is exactly the same as my idea.


ConfigureCell function will called after data source disposed

I changed example project's EditingExampleTableViewController.swift data source like following
      let dataSource = RxTableViewSectionedAnimatedDataSource<NumberSection>(
        animationConfiguration: AnimationConfiguration(insertAnimation: .top,
                                                       reloadAnimation: .fade,
                                                       deleteAnimation: .left),
        configureCell: { [weak self] (dataSource, table, idxPath, item) in
          guard let strongSelf = self else { fatalError() }
          let cell = table.dequeueReusableCell(withIdentifier: "Cell", for: idxPath)
          cell.textLabel?.text = "\(item)"
          return cell
      },
        titleForHeaderInSection: { (ds, section) -> String? in
          return ds[section].header
      },
        canEditRowAtIndexPath: { _, _ in
          return true
      },
        canMoveRowAtIndexPath: { _, _ in
          return true
      }
      )

The problem is configureCell will called after data source disposed due to layoutIfNeeded function call so the app will crash after pop view controller (because self is nil).
I'm not sure this is expected behavior or not, maybe I should return an empty UITableViewCell when self is nil?
In this case, I need call self do something other work, what is the best practice?

Hi @retsohuang ,
you should never call self in configureCell. That's a design smell.

Yes I know, but sometimes I don't have a chose, for example:
I need to do some work when user tap on the button on the cell (rather than an entire cell), no matter I use delegation or reactive way, I always need to call self to do that work right?
Any ideas are appreciated.

You don't. Instead of using self.something declare a local variable let something = self.something and then call something from closure vs self.something.


Question: Datatypes and semantics for preload in _BaseRaw

In the RawArray class, I noticed this line: https://github.com/mne-tools/mne-python/blob/master/mne/io/array/array.py#L47 which passes data as the second argument. This led me to this: https://github.com/mne-tools/mne-python/blob/master/mne/io/base.py#L236.
I have three questions:
1/ Why don't we have a separate data argument? It took me a while to realize that preload could actually be an ndarray too -- which is different from what the public API for preload is (bool or str). It can confuse a developer looking at the code for the first time.
2/ What is the reason for this: https://github.com/mne-tools/mne-python/blob/master/mne/io/base.py#L238 ? We do allow 'single' format. In fact, that is what we strongly recommend when saving our files: https://github.com/mne-tools/mne-python/blob/master/mne/io/base.py#L1183.
3/ Finally, here is another weird thing I discovered:
from mne.datasets import sample
from mne import io

data_path = sample.data_path()
raw_fname = data_path + '/MEG/sample/sample_audvis_filt-0-40_raw.fif'
raw = io.Raw(raw_fname)
print('Actual data type of data: %s' % raw[0][0].dtype)
print('Data type stored in raw object: %s' % raw.orig_format)

Does this mean that all the processing is done with float64 but the data is saved in float32 format? Is this by design or a bug? Why are they not the same precision? I am a bit confused ...

In the RawArray class, I noticed this line: https://github.com/mne-tools/mne-python/blob/master/mne/io/array/array.py#L47 which passes data as the second argument. This led me to this: https://github.com/mne-tools/mne-python/blob/master/mne/io/base.py#L236.
I have two questions:
1/ Why don't we have a separate data argument? It took me a while to realize that preload could actually be an ndarray too -- which is different from what the public API for preload is (bool or str). It can confuse a developer looking at the code for the first time.

hum... that's indeed convoluted.
basically if preload is an array we should set the _data attribute and
keep preload as True (ie str or bool).
eric ok?

2/ What is the reason for this: https://github.com/mne-tools/mne-python/blob/master/mne/io/base.py#L238 ? We do allow 'single' format. In fact, that is what we strongly recommend when saving our files: https://github.com/mne-tools/mne-python/blob/master/mne/io/base.py#L1183.
3/ Finally, here is another weird thing I discovered:
from mne.datasets import sample
from mne import io
data_path = sample.data_path()
raw_fname = data_path + '/MEG/sample/sample_audvis_filt-0-40_raw.fif'
raw = io.Raw(raw_fname)
print('Actual data type of data: %s' % raw[0][0].dtype)
print('Data type stored in raw object: %s' % raw.orig_format)
Does this mean that all the processing is done with float64 but the data is saved in float32 format? Is this by design or a bug? Why are they not the same precision? I am a bit confused ...

it's a waste of space to save as float64. Using float32 with cals is
good enough in terms of precision, but you don't want to do numerics
(linalg or ffts) with float32. Or at least errors can be noticeable.

it's a waste of space to save as float64. Using float32 with cals is good enough in terms of precision, but you don't want to do numerics (linalg or ffts) with float32. Or at least errors can be noticeable.

okay, but why don't you convert to float64 when doing these operations and then back to float32? Otherwise, you are wasting RAM. At least that's how the image processing community handles arrays AFAIK (see example: http://in.mathworks.com/help/images/ref/imfilter.html). If the input to the function is float32, it returns float32 and so on ...

... and here is the other problem that happens due to the upcasting:
from mne.datasets import sample
from mne import io
data_path = sample.data_path()
raw_fname = data_path + '/MEG/sample/sample_audvis_filt-0-40_raw.fif'
raw = io.Raw(raw_fname, preload=True)
raw._data += 1e-60 # and some other operations that the user does

# now just save and load the data back
raw.save('test.fif', overwrite=True)
raw2 = io.Raw('test.fif', preload=True)

# I should have the same data now
from numpy.testing import assert_array_equal
assert_array_equal(raw._data, raw2._data)

we cannot change everything.
the _data attribute should always be float64 or complex128 and by default
we should follow what everybody does which is to store data in single
precision.
saving as float64 if raw._data is float64 while blow up the disks

but do you agree that the simple operation of file write and read should preserve the data? At the very least, the documentation should warn the user if there is an upcasting going on while reading the data. Otherwise, it may result in nasty surprises.

I spent close to 2 days trying to figure what the problem was ...

I spent close to 2 days trying to figure what the problem was ...

data are the same up to numerical precision. All tests of IO use relative
differences because of this.

1/ Why don't we have a separate data argument? It took me a while to
realize that preload could actually be an ndarray too -- which is different
from what the public API for preload is (bool or str). It can confuse a
developer looking at the code for the first time.

IIRC it would end up being redundant. Maybe we should call it
"preload_result" or something.

basically if preload is an array we should set the _data attribute and
keep preload as True (ie str or bool).
eric ok?

I think that's already what happens eventually...?
My recommendation is to improve docs and variable names of the base class.
Unless you have a lot of free time and a masochist steak it's probably
better to avoid chasing the base class.
In particular I think a lot of these weird choices were motivated by the
complex set of possibilities that exist across different readers
(especially FIF) and preload options. Unless you're prepared to try to
understand it all -- it took me a day or two last time I needed to -- it's
probably better not to mess with it.

okay, but why don't you convert to float64 when doing these operations
and then back to float32? Otherwise, you are wasting RAM. At least that's
how the image processing community handles arrays AFAIK (see example:
http://in.mathworks.com/help/images/ref/imfilter.html). If the input to the
function is float32, it returns float32 and so on ...

You will lose some precision bouncing back and forth compared to staying in
float64 the whole time.

... and here is the other problem that happens due to the upcasting:

Floating point arithmetic is not exact, and expecting it to be will lead to
pain. So this example is expected behavior in my mind.
Staying in float32 will lead to more cumulative error compared to float64
when multiple operations (filtering, ICA, SSP, maxwell filtering, ...) are
carried out.  This can negatively impact data, and it's impact should be
worse than the example you posted.

I spent close to 2 days trying to figure what the problem was ...

data are the same up to numerical precision. All tests of IO use relative
differences because of this.

It is a painful lesson to learn that floating point operations should never
be expected to be exact, but worth learning. I agree we probably could have
saved you some time with better docs, though, so feel free to mention the
upconversion somewhere.

Staying in float32 will lead to more cumulative error compared to float64 when multiple operations (filtering, ICA, SSP, maxwell filtering, ...) are carried out. This can negatively impact data, and it's impact should be worse than the example you posted.

I am not saying that you shouldn't ICA etc. in float64. But if your data is originally in float32, upcasting it creates the false impression that you have more precision than you actually have. The final result should be float32, no matter how you do the intermediate steps. Significance arithmetic tells you that you simply can't do better than the precision of the data you started off with. I can think of a few fixes:

Use raw.orig_format to downcast your data in get_data() and similar functions
Throw an error if you try to save data in an upcasted format. raw.orig_format will tell you that

etc.

I am not saying that you shouldn't ICA etc. in float64. But if your data
is originally in float32, upcasting it creates the false impression that
you have more precision than you actually have. The final result should be
float32, no matter how you do the intermediate steps. Significance
arithmetic tells you that you simply can't do better than the precision of
the data you started off with.

But if you do a sequence of operations on the same data, e.g. Maxwell
filtering, filtering, then SSP computation, the cumulative error should be
lower by upcasting, operating, and downcasting, than staying in float32 the
whole time. Do you agree?
If so, one problem with get_data always giving  (at best) float32 is that
the user might want to insert some step above in between e.g. filtering and
SSP computation, and put the data back.

I think the best way to fight this false impression is with better
documentation

I think the best way to fight this false impression is with better
documentation

+1

But if you do a sequence of operations on the same data, e.g. Maxwell filtering, filtering, then SSP computation, the cumulative error should be lower by upcasting, operating, and downcasting, than staying in float32 the whole time. Do you agree?

I agree.

If so, one problem with get_data always giving (at best) float32 is that the user might want to insert some step above in between e.g. filtering and SSP computation, and put the data back.

well ... the user could save the data in between and load it back -- and this will have the same issue. In fact, this is very often the mode of operation for most users. They maxfilter the data and save a new file. Then they have another script, which loads the maxfiltered data and epochs it. Then, they save this as epochs (actually, now I'm not sure if epochs.save uses float32 or float64 as default to save). Then there is another script which loads this and runs some decoding. This is a very common mode of analysis. One rarely runs all the steps in one go when you have multiple subjects. The only problem is that, right now -- all this is happening silently.

I think the best way to fight this false impression is with better documentation

I agree this is the least we should do. Maybe in the "pitfalls" section which is discussed in this issue: https://github.com/mne-tools/mne-python/issues/1495. I have tagged this issue as DOC.

This is a very common mode of analysis. One rarely runs all the steps in one go when you have multiple subjects. The only problem is that, right now -- all this is happening silently.

Yeah that's true. FWIW the pipelines we use at UW partially operate in this way -- not all the steps, but as many as we can. We have to do Maxwell filtering separately because we haven't transitioned to mne-python's version yet (and we'll probably still save the intermediate result because MF with movement compensation takes forever). But our filtering, resampling, and SSP computations are all done in memory. So such chaining does happen in practice.

I agree this is the least we should do. Maybe in the "pitfalls" section which is discussed in this issue: #1495. I have tagged this issue as DOC.

I've added it to #1495, so I'm going to go ahead and close this issue.

Thanks, sounds like a plan


What is the origin of the fpizdam name?

Inquiring Romanian speakers want to know...

@dandv I couldn't translate (using google translate). Can you give us a rough translation?

In Russian it sounds like PHdickP FPcuntM. It's funny watching the media talk about it.

Both are swearing vocabulary, the first word (part) is related to a man’s limb, the second is woman’s... you got the idea. Also, second sounds like somebody is in a real trouble.

I'm pretty sure in every slavic language hui and pizda are common swear words too :)

Dude, this is rude :)

At least here, Google gives the uncensored result for "what does pizda
translate to in english"
On Mon, Oct 28, 2019, 16:10 Emil Lerner<EMAIL_ADDRESS>wrote:

Hi, @dandv https://github.com/dandv,
I'm really eager to know what it means in Romanian (or what phrase it is
similar too).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/neex/phuip-fpizdam/issues/18?email_source=notifications&email_token=AAAIGIJUNW5XXD73OI6PSGTQQ5IL3A5CNFSM4JF6EZ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECOM4GY#issuecomment-547147291,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAIGINGUSFLVZ4IADQ6V63QQ5IL3ANCNFSM4JF6EZ3Q
.

Pizda is not ony in Romanian, it is in al yugo-slavic languages, let's say everybody in Balkan would know Pizda, Picka.... I think in english you would have more specific translations like: twat, pussy, cunt. It depends how deep the context is, usually you would describe some unbelivebale unluck, but mostly is in use when you would like to express deep negative emotions about person or subject....

In Russian "fpizdam" (or in Polish similarly "w pizdę") I think it would also mean in this context "in the face" as "pizda" could also be vulgar word for a "face".
Slavic language swears can have a lot of meanings. Take polish "kurwa" as an example, infinite meanings ;)


Ubuntu 16.04 LTS

Now that the current Ubuntu LTS is 16.04 ("Xenial Xerus"), could you possibly add it to your list of supported OSes?
Thanks!

Hey @billinghamj!
The short answer is "Yes!"
The long answer is, I'm building automated infrastructure that will magically detect these things and ship them for us without human intervention. This means new OS releases will become available within hours of them showing up in the NodeSource repos as opposed to within weeks.
The automated bits for this repo are done here: https://github.com/nodesource/docker-node/blob/automate/tools/get_releases.sh
I'm working on automating the build infrastructure now so the machines will be provisioned and kick off builds when changes are detected upstream. This may take a few days, but it's on the horizon!

Any progress on this? Need any help to get it running?

Hey @mansona
Sorry, I've been AFK for my honeymoon. The automated tooling should be picking this up, strange that it isn't. Taking a look today.

@retrohacker Did you manage to find out why it isn't being pulled in? :)

@retrohacker is the automated tooling opensource or on github? might be worth bringing the discussion to that repo if there is anything to be gained from our help 😄
(also congrats 🎉 🎊 )

Thanks @mansona!
And the tooling is opensource, it lives at https://github.com/nodesource/docker-node/blob/master/tools/build.sh
Running build.sh kicks off the chain of events that lead to a fresh batch of Docker images :smile:

So all that's needed is to just add three lines to the gen-dists.sh file...?

See #54

@billinghamj thank you for all of your help here!
This landed!
https://hub.docker.com/r/nodesource/xenial/
https://hub.docker.com/r/nodesource/wily/
https://hub.docker.com/r/nodesource/fedora23/
https://hub.docker.com/r/nodesource/fedora24/
all shipped late last night!

:tada:

👍


Failing to log to Neptune.ai when resuming from checkpoint

🐛 Bug
I'm trying to resume training from a checkpoint, and I'm trying to resume logging using the Neptune.ai logger, but it throws this particular error:
neptune.api_exceptions.ChannelsValuesSendBatchError: Received batch errors sending channels' values to experiment CAS-68.
Cause: Error(code=400, message='X-coordinates must be strictly increasing for channel: b7ab6110-7a1b-4093-a35f-dc0904ff943f. Invalid point: InputChannelValue(timestamp=2021-01-23T11:02:05.882Z, x=98.0, numericValue=0.30072227120399475, text', type=None) (metricId: 'b7ab6110-7a1b-4093-a35f-dc0904ff943f', x: 98.0) Skipping 3 values.

At the point that I'm resuming, I've already trained for 7000 steps, yet the logger tries to log at step x=98.0 as seen in the error message.
Please reproduce using the BoringModel
I'm not sure how I should reproduce this bug since it's more related to how Neptune.ai's logger specifically works, but I can try to come up with a repro soon.
Environment

PyTorch Version (e.g., 1.0):
OS (e.g., Linux): Linux
How you installed PyTorch (conda, pip, source): pip
Build command you used (if compiling from source):
Python version: 3.8.5
CUDA/cuDNN version: 11.1
GPU models and configuration: Tesla V100
Any other relevant information:

Duplicate? #5130
A PR for a fix is in development.

Duplicate? #5130
A PR for a fix is in development.


Allowed namespace injection without managed

Hi @jkasturi-sf
I have added the error message for the parse_url_string when the url doesn't have set origin. This is possible while we run flows.
Please review the code
Thank you

Hey @jkasturi-sf Please review this PR

Hey @jstvz I have added the functionality to infer namespace from target org directly along with tests.


[incrementals-publisher] Add Incrementals.jenkins.io

Is this a new chart

[x] CODEOWNERS is updated
[x] If secrets are needed, .sops.yaml must be updated with appropriated public gpg key ID, and full public gpg key must be provided to @olblak

What this PR does / why we need it:
Which issue this PR fixes

fixes # INFRA-XXXX

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X] Chart Version bumped
[x] Variables are documented in the README.md
[X] Title of the PR starts with chart name (e.g. [stable/mychartname])

i'm super lazy, basic readme generated by helm-docs

YOLO!
merging


Cyclical Dependencies when using Inspect in a complex environment

Description
I have a complex plugin-based application. In this application I build multiple bundles and load them at runtime with a single bundle containing common dependencies. I tried using @xstate/inspect in the common plugin which loads before my other plugins, however I get a problem with JSON.stringify(service.machine). It finds cycles and fails to serialize the machine.
Expected Result
I should be able to configure inspect before the rest of my application code runs without
Actual Result

Reproduction
Creating a reproduction in the sandboxes proved difficult. You can see the current version of our code at https://github.com/sonatype/nexus-public. components/nexus-rapture is the common plugin that loads first, plugins/nexus-coreui-plugin is the bundle where most of the application views are created. I tried adding the dependency and the inspect method to nexus-rapture/src/frontend/index.js.
Workaround
I finally figured out that if I add the dependency to the "child" plugin (nexus-coreui-plugin) that things would work as expected. This means any plugin that wishes to use the inspector must declare its own copy of the dependency and call the inspect method. I should still be able to extract the library to the common parent to reduce the bundle size, but I don't understand why I can't just call inspect from the parent. If this is expected feel free to close this issue.

Thanks for reporting. This is a duplicate: #1497 we'll track it there. 👍


Logger in library mode

Hello!
I have some issues about usage custom added peers to torrent.
I see useful debug log in the library.
But in library mode I don't see any log message.

@cenkalti I send you PR with these features #106

Done.


Add derive_eq to bindgen config

This is a compilation error fix for https://github.com/esp-rs/esp-idf-hal/pull/166

This fix is no longer required. twai_timing_config_t won't be exposed.


Revert "Fix the module path (after forking it)"

When I created PR https://github.com/fenglyu/go-dmidecode/pull/1 I did that from the main branch of my repository. And shortly before the PR was merged I introduced a problem there: I changed the package path to use my fork instead of the upstream repository. Reverting this changes. Sorry for this.

@xaionaro , no worries!  I've fixed the module path after merging your PR, so I wil close this PR.


Unrealistic weather rendering

Hi all,
first of all thanks for your great work! Our issue is probably related to  #3494 and #3545. Increasing the cloudiness leads to an "unrealistic" rendering, especially of the sky. Everything looks fine with a cloudiness of 30. Around 35 the sky gets unrealistically dark (till black), even though everything else is still quite bright. We used the provided environment.py for changing the weather parameters. This happens for Carla versions 0.9.11, 0.9.12, and 0.9.13 on Ubuntu 18.04 or 20.04 and Windows, packaged version and built from scratch.
Using Carla version <IP_ADDRESS>, everything looks as expected. I don't see how it could be related to the opengl issue mentioned in the previous issues. Also the rain and fog is rendered correctly, unlike mentioned in some of the previous issues. A contributor even mentioned that opengl isn't supported anymore for the newer Carla versions.
We're more than happy to provide further details, if necessary.
Hoping to find a solution! Thanks!

We generated a few screenshots to illustrate the problem. The following are sample images by using the provided environment.py, first setting the sun to day, followed by changing the wheather (clear, overcast, rain).
Carla <IP_ADDRESS>:

Carla 0.9.13 (the images are identical for versions 0.9.11 and 0.9.12 and probably, but we haven't tried it, for 0.9.10):

Any update on this error?

same question. Hope any one gives solution. I try 0.9.14 (-vulkan:bad), <IP_ADDRESS>(-opengl:fine, -vulkan:fine)

@zzj403 Take a look at this  issue. It resolved the problem for me; I don't remember the details, since it was a long time ago.


PoC with in-memory cache (process level)

Doing some tests locally, this makes it go from 326  to 265 queries for the dashboard request. The cache is shared across requests but not between processes. This same approach can be applied to other frequent requests.
I checked the sequel cache plugin implementation and seems pretty decent in terms of ruby/sequel standards, so it makes little sense to implement my own stuff.
Another possiblity is to use a redis cache.
cc/ @javisantana @juanignaciosl @Kartones

I don't like this approach because it assumes that user does not change across all the request (which can be right for most of the cases). I don't know if that plugin manages the invalidation too
In any case if this improves the performance...

The plugin manages invalidation as far as the invalidation is done through the User class.

A permission shouldn't change in the same request except upon creation (and similar with table). User id doesn't changes either... so sems relatively safe if invalidation is ok.
Tests will tell if permission and table creation work, but being temporal code until we remove Sequel I don't see it too bad.

Frontend tests were OK :+1: (details)

@juanignaciosl the gem request_store works pretty well for this use-case (and after testing I'll be glad to pay for it)
I think this first in-memory cache level is pretty safe and will have a big gain in performance. We can think of a 2-level cache later on.

Great, I'll think about using it for the rewrite branch as well :-)

retest this, please

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

retest this, please

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)


Package request: Chicago95

Project description
The best XFCE/GTK2/GTK3 Windows 95 based theme for Linux.
Metadata

homepage URL: https://github.com/grassmunk/Chicago95
source URL: https://github.com/grassmunk/Chicago95
license: GPL-3.0+/MIT
platforms: Linux

On it — testing GTK3 themes on KDE is a bit challenging but I think I got it to work

Somehow I just completely forgot about this even though I got it working :woman_facepalming:

Somehow I just completely forgot about this even though I got it working 🤦♀

Can you share or push what you did 😄 ?


feat: apply resource/resources to namespace

Changes

Use modal confirm component for applying resource/resources

Apply resource/resources to selected namespace

Option to create a new namespace if it does not exist in the cluster and apply the resource/resources to it

[x] tested locally

[ ] added new dependencies

[ ] updated the docs

[ ] added a test

@topliceanurazvan looking good Razvan - i'm wondering if we could populate the list of namespaces with the namespaces defined in the target cluster!? You could use the NamespaceHandler.listResourcesInCluster to get this list (with some post processing required) .
Also - perhaps we should have give users the possibility to create a new namespace in this dialog - i.e. if the user specifies a namespace that doesn't exist (in the list of found namespaces) we prompt if they want to create the namespace instead - we could use the CoreV1Api.createNamespace of the kubernetes-client method for this!? Or should that be a separate issue?
what do you think @erdkse @devcatalin ?

@devcatalin @olensmar I've added the things discussed above and the PR is ready to be reviewed.

looks good - but unfortunately i'm not seeing all namespaces from my cluster (see list below):

@olensmar I've committed some changes and updates. Could you please test it again and see if now there are shown all the namespaces in the dropdown?

@olensmar I've committed some changes and updates. Could you please test it again and see if now there are shown all the namespaces in the dropdown?

Thanks @topliceanurazvan - I get all my namespaces now:

@topliceanurazvan i'm missing this when deploying a helm-chart - both helm install and helm template commands have the -n namespace argument for setting the target namespace, and a --create-namespace argument to create the specified namespace is missing (which we could use instead of creating the namespace ourselves) - see https://helm.sh/docs/helm/helm_install/ and https://helm.sh/docs/helm/helm_template/


error: regular expression is too complex

Hello.
After parsing I have rules.
But I can't use them:
yara main_linux.yara /bin/ls
yara main_windows.yara prog.exe

I have error described below:
main_windows.yara(464362): warning: $signature in rule Win_Trojan_Lineage_85 is slowing down scanning
main_windows.yara(468844): warning: $signature in rule Win_Exploit_CVE_2006_4182_1 is slowing down scanning
main_windows.yara(804367): error: regular expression is too complex
main_windows.yara(804385): error: regular expression is too complex
main_windows.yara(821872): warning: $signature in rule Win_Trojan_SwizzorA_1 is slowing down scanning
main_windows.yara(821881): warning: $signature in rule Win_Trojan_Swizzor_607 is slowing down scanning
main_windows.yara(870184): warning: $signature in rule Win_Adware_Multiplug_3 is slowing down scanning
main_windows.yara(881315): error: invalid field name "virtual_address"

+1

注释掉


adding docker_worker subnet_ids and logic to allow static vpc

cc @lmilbaum not 100% this will work but this is my best first shot at this

CI is broken

Changes:

Switching to pinned os runner version while here
adding python version to reduce flakes in precommit
original feature: allow users to pass static VPC for both agent and works and subnet ID for just workers

Proven this works!


thoughts about/links with sat-api-browser

I have not seen a demonstration, but fair amount of work apparently happening:
https://github.com/developmentseed/sat-api-browser

This was just opened yesterday during the STAC sprint, and we talked about features and requirements. Some work is going to continue on this over the week and we'll see where it is on Friday.  Can probably give a demon at Pangeo meeting in a couple weeks.

I think this can probably be closed. But maybe the current version is that there could be an integration with stac_ipyleaflet.