fix: creating translatable models with multiple languages

This PR fixes doing something like this with a translatable model:
Category::create(['title' => ['de' => 'Maschinenbau', 'en' => 'Mechanical Engineering']]);

Spatie's docs say that's how it is supposed to work. However, with the backpack trait instead of Spatie's, I found this would create the following json for the title attribute in the database:
{"en":{"de":"Maschinenbau","en":"Mechanical Engineering"}}

where it should be this:
{"de":"Maschinenbau","en":"Mechanical Engineering"}

I'm not quite sure if my fix is the optimal way to do it since spatie does not seem to override eloquent's create method at all and it works without issues.

A new inspection was created.

The inspection completed: No new issues

Hi @kolaente, thank you for your contribution!
Indeed this bit of code has an issue, I can't understand how no one ever needed this 😅
You probably disabled the edits from maintainers, so I can't change it myself, but as soon as you commit that suggestion, this is good to go from my side ✌

A new inspection was created.

Hi @promatik, thanks for the review!

You probably disabled the edits from maintainers, so I can't change it myself, but as soon as you commit that suggestion, this is good to go from my side

I think that's because the fork is in an org, I've run into that same problem somewhere else already.
Commited your requested change, should be good to go.

The inspection completed: No new issues

Hey guys,
Thanks a lot for the fix! Since this involves changing db structure basically, we have to be really careful that it's backwards-compatible. Is this the case?
@promatik - what will happen to people who have already saved their info the "wrong" way? Will anything break for them?
@kolaente - does Backpack provide an interface that is subject to this bug (a field), or does this only happen when the dev does this manually using Category::create(['title' => ['de' => 'Maschinenbau', 'en' => 'Mechanical Engineering']]);
Again - thank you 🙏
Cheers!

Thanks a lot for the fix! Since this involves changing db structure basically, we have to be really careful that it's backwards-compatible. Is this the case?

@tabacitu Where does this change the db structure?

does Backpack provide an interface that is subject to this bug (a field), or does this only happen when the dev does this manually using Category::create(['title' => ['de' => 'Maschinenbau', 'en' => 'Mechanical Engineering']]);

I've only observed it using Category::create() so I think there's an interface that's exposed from backpack for that.

@tabacitu this is actually "keeping" the DB structure 😅
I believe this happens only when using Model::create([...]).
I tested other fields with translations and the information never reaches that function in the form of an array, only when doing Model::create([...]).
But I agree this is a very sensitive thing, @pxpm can you test it too?

@promatik @kolaente thanks for the effort here. 🙏
Wouldn't we need the same fix in the update method ? If neded ...
https://github.com/Laravel-Backpack/CRUD/blob/91f905a63eb1f409dc42faa7dbd02014009e99c8/src/app/Models/Traits/SpatieTranslatable/HasTranslations.php#L113
I also removed this create and update override from the trait, and tested Product CRUD in Demo and eveything seems to work, I can still save the translations just fine. Can anyone confirm ? Why is this needed here in the first place ?
Best,
Pedro

@pxpm Very good point. I did not explicitly test it, but updating seems to work fine. Can anyone confirm?

I also removed this create and update override from the trait, and tested Product CRUD in Demo and everything seems to work, I can still save the translations just fine. Can anyone confirm ? Why is this needed here in the first place ?

@pxpm unfortunately... I don't remember why this is needed in the first place... I went dumpster-diving to find out... checked file history, compared with original trait... still not very clear. But what I did figure out is that there were at least two things different between Backpack and the translation package:

in Backpack we have Fake Fields... which did not play well with the translation package (see getAttributeValue());
in Backpack we set the locale using the GET parameter locale, which the translation package didn't support (it only sets the locale from the config, not the request);

That being said, when comparing our trait with the original one, I noticed there are quite a few improvements we can make:

[ ] getTranslation() seems identical to the original trait now, so it could probably be removed;
[ ] our setLocale() and getLocale() use public $locale, while the ones in the original trait use private $translationLocale; we could probably eliminate the setLocale() override by using $translationLocale in getLocale();
[ ] we're using locale as the GET parameter, but we should probably be using _locale since it's a system parameter and that's how system parameters look in 4.2;
[ ] it looks like we can probably remove the create() and update() overrides... at the very least we can do that if we add those methods to the bottom __call(), so that the proper locale is set from the request;

Overall... I feel we can do a lot of things to improve this trait... probably remove 90% of it. But... in order to do any of the above with any degree of confidence... we need tests. Not individual unit tests for these methods... but a few general tests, that take in a Request object:

[ ] test_store_translatable_entry (tests the CrudController::store() method)
[ ] test_update_translatable_entry_with_default_language (tests the CrudController::update() method)
[ ] test_update_translatable_entry_with_cutom_locale (tests the CrudController::update() method)

What's important is that the tests include all attributes we support as translatable, including fake fields. Only then could we be confident enough that our changes here don't negatively impact someone.
This bit of Backpack is one of those "moving pieces". Before we change it, we should add more tests. Extensive tests. It will not only help present-us but also future-us. This is mission-critical for a lot of folks, can't believe we don't heavily test this already 🤷♂ I see we do have a testExtrasTranslatableGetFaked in CrudTraitFakeFieldsTest but that doesn't seem like enough.

On second thought... I think we can even remove this trait entirely... Instead of overriding setLocale() and getLocale() we could just do $crud->model->setLocale() in the operations that support multi-language entries (Create, Update, Show). That would take care of that.
Then we would only need to account for translatable fake fields somehow, but it's unclear to me what the problem was and how we treat it right now. We need tests to figure that out.

I will be closing this in favor of #4271
Thanks @kolaente and @promatik , I pulled your commits in that PR too so you both show up as contributors!
Cheers


Made size(RingArray) have the first value be the length of the data R…

…ingArray is sliding along
Before, size was returning the number of rows you could fit in the RingArray. Now size should return the same thing as size on the data you are sliding along.

Current coverage is 100.00%

Merging #5 into master will not affect coverage as of 31d62f9

@@            master      #5   diff @@
======================================
  Files            1       1
  Stmts           92      92
  Branches         0       0
  Methods          0       0
======================================
  Hit             92      92
  Partial          0       0
  Missed           0       0

Review entire Coverage Diff as of 31d62f9

Powered by Codecov. Updated on successful CI builds.

The size change is accounted for in this PR https://github.com/invenia/RingArrays.jl/pull/6. Will close this PR and branch.


fix(lines): discard extraneous data-points during lines animation

Brief Information
This pull request is in the type of:

[x] bug fixing
[ ] new feature
[ ] others

What does this PR do?

Discards data-points that were erroneously added to the chart during the lines animation.
Fixed issues

#10228
#11633
#12164
#12433

There are multiple issues currently open about this problem and they might all be related.
Details
Add a test to easily reproduce the bug where points are erroneously added to the chart during the lines animation and make a naive attempt at fixing it.
Before: What was the problem?

This bug happens during line-animations and it makes the chart display some invalid data-points after the animation is complete.
These erroneous data-points seem to be transient and they seem to go away after some interactions with the chart (e.g.: by manually changing the data-zoom).

This is a screenshot of the bug from the added test case (there are only two points in the series so there should only be one segment):

Reproduction link: https://jsfiddle.net/8kv71j0w/7/ (also see added test case in test/lines-extraneous.html).
After: How is it fixed in this PR?
Due to some items in the old series having been filtered out (e.g.: by the data-zoom component), the rawIndex of the removed items is different than the index. Therefore, this condition evaluates to true which results in this particular code path being executed. This in turn has the effect of keeping these removed points in the line during (and after) the animation.

The naive fix as part of this pull-request was to remove that code-block all together.
Warning: I don't have enough context to understand the full-implications of this change and it's very likely that this is not a good fix for this problem.
The main reason for opening this pull-request was to start a discussion and get some feedback from the developers about what would a proper fix look like.

That being said, this proposed change does seem to produce the expected result in the attached test case:

Usage
Are there any API changes?

[ ] The API has been changed.

Related test cases or examples to use the new APIs
See test case in: test/lines-extraneous.html
Others
Merging options

[ ] Please squash the commits into a single one when merge.

Other information
See the linked issues for more details about other instances where this bug happens.

+1 to this fix. We are seeing similar issues on line chart animations/zooming.

+1 to this fix. We are seeing similar issues on line chart animations/zooming.

Have to admit I'm very surprised this issue that bothers us for a long time can be fixed by simply removing this branch

Thank you for this awesome library!
I'm a little surprised too and to be honest I'm still a bit afraid of this change having unintended side-effects because I guess that branch must have been there for a reason.
In any case, let's see what happens and if it turns out it's a bad fix it can always be reverted.


Ldap backend: assign Admin role based on a ldap filter

Hello,
With ldap backend it is easy to limit acces to the registry using a filter (for instance cn=portus-users,ou=groups,dc=domain,dc=com)
It'd be easier if there was a filter parameter in the ldap options to get the global admin users; that would allow to put admin users in cn=portus-admins,ou=groups,dc=domain,dc=com.

Youhou!!!! :champagne:

Youhou!!!! champagne

Indeed :). bisous


Set --shm-size via run args

For a container requiring shm for inter process communication, I need to increase the default shm-size (docker default is 64M). How do I do so with dsub please? I need to be able to pass flag --shm-size=4g to the docker run command.
Thanks for any directions.

Hi @rivershah,
Please take a look at issue #191. From mbookman:

"This issue was resolved back in March as the Pipelines API was updated to set container shared memory size to the total memory size."

Thanks for linking the issue! Sorry my searches had brought up nothing. Understood and verified working


CT-1524 - Add support for python 3.11

resolves #225
Description
Python 3.11 was added as a supported version of python in several configurations throughout the code base.
setup.py was updated to remove regular expressions and move from os.path to pathlib for readability.
Checklist

[X] I have read the contributing guide and understand what's expected of me
[ ] I have signed the CLA
[X] I have run this code in development and it appears to resolve the stated issue
[X] This PR includes tests, or tests are not required/relevant for this PR
[ ] I have opened an issue to add/update docs, or docs changes are not required/relevant for this PR
[x] I have run changie new to create a changelog entry

@cla-bot check


flying dragon: reduce proc rate to 0.04

Value taken from http://freakinsweetapps.com/flying-dragon-up-time-calculator/
Hopefully this fixes the unrealistically high FD uptime in d3planner. That said, even if I go to that simulator and change the 0.04 in its source code to 0.05, I don't get values as insanely high as d3planner, so some other bug might also be present.
Simulating R6 gen on d3planner gives me insanely high FD uptimes of 93%+. There's no way this is realistic. On the website I linked, plugging in my adjusted APS gives me an uptime of ~70% (no StI) and ~80 (StI) which sounds far more like reality.
I noticed they use the same ICD/duration, but they have a proc rate of 0.04, not 0.05. But even if I change their simulator to 0.05 it doesn't compute 93% uptime unless I actually set my base APS to something like 8-9, which is clearly absurd.
What is d3planner doing differently here? Is it failing to take into account the ICD properly, perhaps? I ask because if I modify that simulator to remove the ICD (and set the proc coefficient to 0.05), I also get 93% from it.
I would test this change to see what the impact is, but after several hours I couldn't figure out how to easily integrate my changes.

Actually, something else I just noticed is that this item is coded using "oncast" rather than "onhit_proc". Surely this is not right? While FD is capable of proccing without any enemy, it also procs way more when you're actually hitting things; and as far as I'm aware it scales off the proc coefficient.

I've decided to investigate this issue more closely. I performed some experiments.
1.75 * 1.25 = 2.1875 APS test
For this test I was standing in town, using FoT - Q + force stand still for 5 minutes on end. My sheet APS was 1.75. I had the R2 set bonus equipped (25% more gen APS) but no other effects.
0:04.700 start hitting
0:17.800 FD start
0:24.766 FD stop   -> 7 seconds
0:36.632 FD start
0:43.600 FD stop   -> 7 seconds
0:50.766 FD start
0:57.766 FD stop   -> 7 seconds
1:04.500 FD start
1:11.500 FD stop   -> 7 seconds
1:27.500 FD start
1:40.699 FD stop   -> 13.2 seconds (6+7)
1:42.677 FD start
1:49.699 FD stop   -> 7 seconds
1:58.533 FD start
2:16.632 FD stop   -> 18.1 seconds (5+6+7)
2:44.299 FD start
2.51.299 FD stop   -> 7 seconds
2:53.733 FD start
3:12.199 FD stop   -> 18.5 seconds (5+6+7)
3:15.866 FD start
3:22.866 FD stop   -> 7 seconds
3:29.599 FD start
3:42.766 FD stop   -> 13.2 seconds (6+7)
3:44.266 FD start
3:57.032 FD stop   -> 12.8 seconds (6+7)
3:57.066 FD start
4:04.066 FD stop   -> 7 seconds
4:17.766 FD start
4:24.766 FD stop   -> 7 seconds
5:04.700 stop hitting = 300 seconds total

Total uptime (first half): 66.3 seconds / 150 seconds ≈ 44.42% uptime
Total uptime (second half): 72.5 seconds / 150 seconds ≈ 48.33% uptime
Total uptime: 138.8 seconds / 300 seconds ≈ 46.26% uptime

For this APS, the FD uptime calculator on [1] computes 46.3%
For this APS, the FD uptime reported by d3planner is 71.88%!
Changing the coefficient of 0.04 to 0.05 on [1] increases the computed uptime to 54.4%. This, to me, confirms that 0.04 is the correct coefficient to use. As such, this patch can be applied.
However, I noticed it reports an “unusually high” number of hits per seconds: 4.78 attacks/second average (with FD in cube) and 2.95 attacks/second with no FD. Since my gen APS is only 2.1875, this caught me off guard; so I investigated it further.
1.61 APS frame timing test
I tried recording at 60 fps but either I can't render fast enough or I can't capture fast enough, so I can't get hard info about the exact frame counts, but I can get a good estimate.
I was also standing in town, using FoT - Q + force stand still. I had no attack speed bonuses other than the innate 15% dual wielding bonus.
03.949 start hitting
04.166 first punch effect
04.516 second punch effect
05.049 third punch effect
05.532 first
05.867 second
06.399 third
06.949 first
07.299 second
07.816 third
08.333 first
08.866 second
09.232 third
09.732 first
10.067 second
10.616 third
11.116 first
11.432 second
12.000 third
12.516 first
12.849 second
13.432 third
13.949 first
14.232 second
14.782 third
15.199 stop hitting

What I call “punch effect” is the first frame that includes major amounts of the orange-browny effect from quickening. I don't know where the hit actually registers, but this gives me a good visual reference point.
This gives me the following duration breakdown:
First -> Second: 0.354375 average  ≈ 21.26 frames
Second -> Third: 0.524750 average  ≈ 31.48 frames
Third -> First:  0.511857 average  ≈ 30.71 frames

Total sequence length: 1.3975 seconds average ≈ 83.85 frames => 2.14669 APS throughout sequence
Total average APS = 24 hits in 11.25 seconds ≈ 2.14669 APS

Looking at d3planner, it calculates the frame breakpoints at this APS to be 23 / 23 / 37, for a total of 83 frames per sequence; 1.38 second sequence length average. This matches my observed test results. It also calculates my real effective APS to be about 2.17. Since my own numbers are over a very short time-scale, I'll assume this info is correct since it more or less matches what I tested.
It seems that the source of confusion is the fact that generators attack faster than regular abilities: they have baseline timings significantly below 60 frames. However, this brings us back to FD proc rates. Since the sheet APS of the earlier test matched the reality of the earlier test, my best guess is that the flying dragon proc rates is scaled to the generator attack speed, normalized back to 0.04% chance at 60 frames.
Since we can rely on the d3planner frame breakpoint figures, we can determine that the correct APS for the first test up above was ~2.95 in practice. Plugging this into [1] (with coefficient 0.04) gives me ~56.66% uptime; and also bumping up the proc coefficient to 0.05 makes it ~64.1%. So even with both of these “errors” accounted for, d3planner's FD uptime is still unrealistically high. There must be a third source of error. So to go to the next step, I decided to look at proc rates when hitting a real mob. To make tests easier, I decided to make my APS as high as I could; and then just see whether in town vs hitting a mob made a difference.
2.55 * 1.25 * 1.15 = 3.665625 APS test (on mob)
0:01: start hitting
0:12: FD
0:19: FD end
0:25: FD
0:32: FD end
0:33: FD
0:40: FD end
0:45: FD
0:58: FD end  <- double-proc (13)
1:07: FD
1:26: FD end  <- triple-proc (19)
1:29: FD
1:53: FD end  <- quad-proc (24)
1:59: FD
2:06: FD end
2:09: FD
2:21: FD end  <- double-proc (12)
2:21: FD
2:28: FD end
2:31: FD
2:44: FD end  <- double-proc (13)
2:45: FD
3:05: FD end  <- triple-proc (20)
3:10: stop hitting

Total proc time (first half): 53 seconds out of 90 total ≈ 58.8% uptime
Total proc time (second half): 83 seconds out of 99 total ≈ 83.4% uptime
Total proc time: 136 seconds out of 189 total ≈ 71.95% uptime

The calculator at [1] calculates about 64.7% uptime.
d3planner calculates about 93.57% uptime.
2.55 * 1.25 * 1.15 = 3.665625 APS test (in town)
0:02 start hitting
0:04 FD
0:17 FD end <- double-proc (13)
0:25 FD
0:32 FD end
1:00 FD
1:14 FD end <- double-proc (14)
1:18 FD
1:30 FD end <- double-proc (12)
1:31 FD
1:38 FD end
1:44 FD
1:58 FD end <- double-proc (14)
2:01 FD
2:13 FD end <- double-proc (12)
2:14 FD
2:21 FD end
2:22 FD
2:35 FD end <- double-proc (13)
2:37 FD
2:44 FD end
2:47 FD
2:54 FD end
3:05 stop hitting

Total proc time: 113 seconds out of 183 total ≈ 61.7% uptime

Some minor extra luck in the first test aside, it seems that both more or less correspond to the same result, which also coincides with what the simulator at [1] calculates (64.7%). In both cases, d3planner's result is totally off. It also seems like it scales off the generator APS, since both alacrity and the R2 set bonus seem to increase the uptime.
In all cases, d3planner's uptime figures are way off the mark.
Summary

Proc rate seems to be 0.04, not 0.05 (as this patch suggests)
Proc rate does not seem to depend on whether I'm hitting mobs or not; so I would imagine the proc coefficient is also not included
Proc rate seems to be scaled by the generator's base speed somehow
Even accounting for the above errors, d3planner's figures are way too high

Some more comparisons, going purely off numbers here; (no more tests, since the tests I have so far establish that the calculator at [1] is pretty good). My first thought was that maybe d3planner is performing generator APS normalization but doing so in the wrong direction (multiplication instead of division), so I investigated this possibility:
With 1.0 APS on d3planner, it reports ~41% uptime - while the [1] tool reports ~25% uptime. This is using an ability that has an effective APS of 1.34 instead of 1.0 (fists of thunder).
Using a proc rate of 0.05 (d3planner value) and APS 1.34 on [1] gives me ~37.7% uptime.
Using a proc rate of 0.05 * 1.34 and APS 1.34 on [1] gives me ~47.6% uptime.
Using a proc rate of 0.04 * 1.34 and APS 1.34 on [1] gives me ~40% uptime.
At a higher attack speed (effective APS 2.307), I get 60.65% uptime on d3planner. On [1]:
Proc rate 0.04, APS 2.307: ~48.8% uptime
Proc rate 0.05, APS 2.307: ~56.0% uptime
Proc rate 0.04 * 1.34, APS 2.307: ~58.8% uptime
Proc rate 0.05 * 1.34, APS 2.307: ~66.3% uptime
Not sure what to make of these results. If the bug is what I thought it might be, then I would expect the last figure out of d3planner, because d3planner uses 0.05 and not 0.04. So there must be some other error. I'm just not sure what.
As for how the math should correctly be, double checking:
Proc rate 0.04, APS 1.0: ~25% uptime
Proc rate 0.04/1.34, APS 1.34: ~25% uptime
Proc rate 0.04, APS 1.72: ~38.6% uptime
Proc rate 0.04/1.34, APS 2.307: ~38.5% uptime
Proc rate 0.04, APS 2.1875: ~46.3% uptime
Proc rate 0.04/1.34, APS 2.95: ~46.6% uptime
This confirms that dividing the base proc rate of 0.04 by the coefficient for how much faster than normal the current generator hit is results in the correct FD uptime in principle.

Incidentally, it's also possible that the adjustment to the flying dragon proc rate is not based on the generator speed but on the generator's proc coefficient.
To test this, I decided to switch to static charge - because it has a significantly lower proc coefficient while having the same attack speed. The FD uptime on d3planner did not change.
2.55 * 1.25 * 1.15 = 3.665625 APS test (static charge)
Instead of counting the frames, I decided to just track the time the FD buff was present using a stopwatch. Since SC has a whopping halved proc rate compared to quickening, if it's a factor, it would be immediately noticeable.
I counted 3:15 total of FD uptime, for a test with 5 min duration, giving me an uptime of around 65%. This matches my earlier figures, so we can conclude that the proc coefficient does not factor into the FD uptime a tall, either in reality or on d3planner.

The sum of all my FoT tests are 444 seconds FD out of 672 seconds testing, which makes my overall uptime about ~66%. Again, this perfectly matches the value of ~65% computed by [1].
I noticed from https://www.reddit.com/r/Diablo3Monks/comments/20dtvk/proc_coefficients_explained_ranked_and_listed_for/ that it mentions an “innate speed modifier”, listing fists of thunder as 16%. I'm not sure where this value comes from, but I decided to try plugging it into the simulator:
Proc rate 0.05 * 1.16, APS 2.307: ~60.6% uptime
Proc rate 0.05 * 1.16, APS 2.95: ~70.1% uptime
Proc rate 0.05 * 1.16, APS 4.74: ~85.1% uptime
This somewhat matches the d3planner-reported incorrect values of 60.65%, 71.88 and 93.57%, but not quite. (The final result should be higher for the third test)
I'm out of ideas. If you know why d3planner is simulating FD correctly, feel free to fix it. But at any rate, the website on [1] matches reality, so you can use that as a reference.

While investing this issue, and possible fixes for it, further; I noticed the following: I was comparing the FD proc rates across different generators (to see if the base speed boost was a factor), and arrived at these results:
2.55 APS * 1.25 * 1.15
ingame (FoT:Q): ~66% uptime over 11 mins  @ 4.74 aps
ingame (WotHF:WF): ~67.6% uptime over 6 mins  @ 4.62 aps
ingame (CW:M): ~52% uptime over 10 mins  @ 4.74 aps
ingame (DR:SG): ~58% uptime over 12 mins  @ 4.74 aps
For some reason, CW and DR both have a significantly lower FD uptime. In terms of proc rates, I get the same uptime in d3planner using the following values:
FoT:Q: 0.03
WotHF:WF: 0.03
CW:M: 0.02
DR:SG: 0.025
Ratio of FoT : WotHF : CW : DR  =  6 : 6 : 5 : 4
I tried looking for ways these numbers could have come about. The only real constants in the source for are the innate APS modifiers for the first two hits:
FoT: 1.55
WotHF: 1.275 / 1.175
CW: 1.45
DR: 1.50
None of these really seem to match. Short of just hard-coding the proc rate (perhaps after a bit more testing to confirm the numbers are accurate), I'm not sure what else to do.

In order to verify how accurate my previous tested results were, I decided to modify d3planner to use Math.random instead of Sim.random; in order to introduce some variation and see how much I should expect on a 10 minute test.
When doing so, I discovered something very interesting, which I sort of had suspect in the back of my mind already: Sim.random is not faithful to reality!
Simply modifying the FD check to Math.random() < 0.04 significantly reduces the reported FD uptime. It seems like the Sim.random metric is giving me results that are valid for a best-case scenario test, but in reality it varies something like 20% even for 10 min tests. (I pressed “simulate” a bunch of times and got anything from 60% to 80% FD uptime, but most of the time ~70%, which matches reality)
For comparison, this is what I get from Sim.random:
Sim.random, FoT:Q: 82.44%
Sim.random, WotHF:WF: 83%
Sim.random, CW:M: 82.44%
Sim.random, DR:SG: 82.44%

It seems like Sim.random assumes you're unrealistically lucky; rather than picking a good middle estimation. This highlights one of the problems I have with d3planner's simulation tool: Instead of doing a single run with a “normalized” RNG, the better way to simulate is to do multiple runs with a true RNG and average out the results you get.
In order to facilitate this change, I would highly recommend adding a “use real RNG” button that stubs out Sim.random for Math.random (essentially). Then players could get some more realistic simulation results and average them by hand. Of course, the best way to do it would be to average out a bunch of runs internally and then only display the median or something.

Thanks for the thorough testing.
Yep, Sim.random is not random by design, so that different gear sets can be compared without running hundreds of simulations (which is simply not feasible with javascript). I could add a "true RNG" switch, but there's a lot of other logic that normalizes RNG, such as calculating the number of targets for various skills.
When it causes problems, I usually add special logic to get more accurate results. Currently I do this for hungering arrow and for new grenade legendary; I suppose I should do that for FD too if you claim it gives more accurate results.

Doing it for FD sounds like a good idea. That said, there's still an issue of perfect RNG vs bad RNG which isn't easily corrected out. With a current end-game R6 generator, your damage graph looks like this:

As can be clearly seen in this example, your damage is very tied to CoE rotations, and during the cold rotation your damage goes through the roof.
Now, let's look at an example of what this DPS graph looks like with Math.random instead of Sim.random:

Even with a forced 50% FD uptime, for example, there's a huge difference between that FD proc aligning with your element rotation or not. The majority of your total damage comes from those last 2-3 cold rotations (8-12 seconds total). Having a minor difference in the seed conditions lead to a drastically different result from one simulation spec to another will make or break the result.
Also, some specs have higher potential with perfect RNG but also much worse results with bad RNG - i.e. high variance. Normalizing for RNG completely hides these factors, which makes for example BoH generally favored to BF-FitL even though the latter has a higher average and max RNG: If you get unlucky, you just deal no damage.
With multi-threaded webworkers, it would totally be reasonable to spawn some number of threads simultaneously and report a summary of their results (average, standard deviation) either as a number or a scatterplot, right? I have 32 CPU cores, for example, which means I could run 32 simulations in the same time it would currently take me to run 1.


Coding-style and improvements

I really like the example, but I really dislike the coding-style.
I've been using the Linux coding-style for years, and there's many examples of elegant code in that project where everything has a reason for being... Including the coding-style.

Hey @felipec, many thanks for putting in the work to clean up the coding style, this is much appreciated. I finally got around to adding some CI automation and merged a cherry-picked version of your changes in PR #17.


First category phrase

First category added during installation doesn't add the phrase.

Fixed in https://github.com/Xon/XenForo2-WarningImprovements/commit/27900dac4468366462888c306334c985f4f1bc99


angularfire2: upgrade: Property 'database' does not exist on type 'AngularFireDatabase'

Version info

Angular: angular/cli: ^1.4.2
Firebase: ^4.3.1
AngularFire: ^4.0.0-rc.2
How to reproduce these conditions
Steps to set up and reproduce
After upgrading my packages, the line: this.db.database.ref throws the error: Property 'database' does not exist on type 'AngularFireDatabase'.

Have looked at https://github.com/angular/angularfire2/blob/master/docs/version-4-upgrade.md but when I change the line to this.db.ref it's also not valid as: Property 'ref' does not exist on type 'AngularFireDatabase'.
import * as firebase from 'firebase/app';
import { AngularFireAuth } from 'angularfire2/auth';
import { AngularFireDatabase } from 'angularfire2/database';

@Injectable()
export class AuthService {

  constructor(
    private db: AngularFireDatabase,
    private dbAuth: AngularFireAuth,
  ) {}

  getUser(email) {
    return this.db.database.ref(keys.database.tempUser)
      .orderByChild('email')
      .equalTo(email)
      .limitToFirst(1)
      .once('child_added', (data) => {
        this.setLocalData(keys.localStorage.userIdTemp, data.key);
      });
  }
}

Debug output
Errors in the JavaScript console
Property 'database' does not exist on type 'AngularFireDatabase'.

@davideast you seem to be very helpful in these situations. :)

@magleahy Appears to be working fine here
https://stackblitz.com/edit/angular-template-firebase-kjiyoc?file=app/app.module.ts
It should be this.db.database.ref in the latest version

@Toxicable have you tried with the same version of firebase? You are using 4.3.0.

https://stackblitz.com/edit/angular-template-firebase-kjiyoc?file=app/app.module.ts
yup still works fine

I'm just starting on AngularFireDatabase and I was stumped that a working Ionic code from 3 months back no longer able to compile properly, because of the missing "database" from AngularFireDatabase class.  Since I don't know the details of how AFDB works I just let the typescript editor guide me down the defined types, and it suggests this line
this.afDatabase.database.ref(this.userRef)
should be replaced with
this.afDatabase.app.database().ref(this.userRef)
Can I ask the experts here if this is the correct changes, to use v4?

The docs here are up to date
https://github.com/angular/angularfire2/blob/master/docs/2-retrieving-data-as-objects.md
https://github.com/angular/angularfire2/blob/master/docs/3-retrieving-data-as-lists.md

@magleahy @kaceo Does calling this.db.database().ref('path') work?

@davideast not for me. Throws a TypeScript error.
@Toxicable specifically I am looking to know what replaces: this.db.database.ref(refURL)?

@kaceo thanks for concurring! :)

I am confused why it works for you @Toxicable and not for me. Life is hard sometimes! ;)

Ever since npm@5 came out, we've been seeing occasional problems where node_modules
would get into a inconsistent state, across the team.
So we occasionally do:
rm -rf node_modules // or your OS equivalent
npm install
npm install angularfire2@latest --save (to fix https://github.com/angular/angularfire2/issues/1113)

hasn't that change a long time ago?
i thought you were suppose to call the action you wanted to perform on the db ( object or list or smth like that)
private db: AngularFireDatabase
this.db.list(ref);

@magleahy Make sure your node_modules aren't lying to you (they often do). Try upgrading to the latest 5.0 version and see if that helps.

@larssn That's a valid point, but please change // to # in your example rm …command. Someone may copy-paste that to a terminal as such, without noticing the difference.

@Toxicable those links are 404
As I just ran an npm update and encountered this same issue it's still not clear in this thread what the new API should be. I'm still on 4 rc0 and don't see the database prop removed from the AngularFireDatabase class on github.
Is v5 compatible with the old firebase db? It's my understanding it is not.

@tinomen v5 rebuilt the RTDB API to match the Firestore API. Both are compatible.

FYI it appears that the git tag 4.0.0-rc0 on github has the property #database still in place but the npm package installed for 4.0.0-rc.0 does not have it. Bummer.

Reverting firebase back to ^3.6.6 with 4.0.0-rc.0 works.

Cant you use one of the later release candidates for v4?
There issue that keeps reverting to rc0 (due to bad npm package naming), keep that in mind.


[Gally]: master <- dev

Automatically created by Git-Ally

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


fix: move to flowise compiler for rendering logic

Description
Flowise has logic built in which is tested for building the logicDef from transformer nodes, the task is to move the current formilt compiler from a custom implementation to just a transpiler to flowise and use the flowise compiler to output the logicDef.

deprioritised rn


Snowflake DECIMAL casting when running row validation with concat

When running row validation and there is DECIMAL(p,s) in Snowflake and NUMERIC(p,s) in BigQuery, the concat and hash will create different results due to how Snowflake handles DECIMAL.
Running test:
data-validation validate row \
  -sc bq_conn \
  -tc sf_conn \
  -tbls tst.TEST=tst.TEST  \
  --concat order_number,invoice_sum,status \
  --primary-keys order_number,account \
  -rr \
  -rbs 100

BigQuery DDL:
create table tst.TEST (
    order_number STRING,
    account STRING,
    invoice_sum NUMERIC(10,2),
    status STRING
);

Snowflake DDL:
create table tst.TEST (
    order_number STRING,
    account STRING,
    invoice_sum DECIMAL(10,2),
    status STRING
);

Example results:
Snowflake:
22777.10
BigQuery:
22777.1
In a nutshell:
If Snowflake has DECIMAL(10,5), the string representation is 10.00000 for 10 and 10.12000 for 10.12
If BigQuery has NUMERIC(10,5) (or DECIMAL), the string representation is 10 and 10.12 for 10.12

Hi,
Just for the reasons you point out - treating numeric as string is not a great idea. A better approach is to cast it into something that is meaningful for you from a business perspective. For example if the data is holding currency, you may only care about the first two digits of precision. If it is holding latitude or longitude, you will want more digits of precision. You could write a custom query validation where you custom query transforms the decimal into a string for comparison. It may also be possible to use Calculated Fields, though I am not very familiar with that feature.
Let me know if that resolves your issue.
Sundar Mudupalli

I'll have a look at this. We had a similar issue in the past with PostgreSQL conversions from decimal to string.

Better testing has highlighted that we have this same issue on MySQL too.

@henrihem thanks for highlighting this, it has identified a flaw in our tests which I've now also fixed. Hopefully the fix unblocks decimal validations for you.


gocd-server: 16.5.0-3309 -> 16.6.0-3590

Motivation for this change
Things done

[x] Tested using sandboxing
(nix.useChroot on NixOS,
or option build-use-chroot in nix.conf
on non-NixOS)

tested using nix-build

Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"

https://gist.github.com/swarren83/3acfc0e8408a3658a185826b8b291896

[x] Fits CONTRIBUTING.md.

Update gocd-server package version to 16.6.0-3590 including new sha.  Modify heapSize
and maxMemory mkOption to accurately reflect their intended purpose of configuring
initial java heap sizes.

I'll be reviewing this tonight.
Thanks!

Well ... that's fine too :P thanks, @garbas


1743630 p7

Hue Outdoor Welcome Floodlight

Good work! Don't know anything about the coding, but adding "fixes #74" to the comment, or similar would close the original issue when the pull request is merged. Would be easier to keep track on the issues, and also to not keep issues open when they're already fixed. All the best! https://help.github.com/en/articles/closing-issues-using-keywords

Really nice! Please add the device info in the release notes aswell. After that we can merge it into Dev.


STM32L4x5/6 Missing Registers

According to the reference manual page 309-310, the GPIO port bit reset register GPIOx_BRR and the GPIO port analog switch control register GPIOx_ASCR register should exist, under the respective GPIOs. They are in the SVD but are missing in the library.

Likewise the Prescaler field under ADC common control registerADC_CCR is also missing. Reference manual page 613.


Internal I2C uses Wire1 (not Wire)

Hello M5Stack
please also see the discussion in this thread.
Thanks
Felix


Quickpick tooltip not appearing

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.77 Inisders
OS Version:

Steps to Reproduce:

Install Jupyter extension
Remove the python extension if installed
Open a notebook and go into the kernel picker for Python Environments
The quick pick item Install Python Extension shoudl have a tooltip

Originally reported by @connor4312
https://github.com/microsoft/vscode-jupyter/issues/13086
I don't see a tooltip on the initial "install python" hint

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.76.2. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Anything in DevTools perhaps?

@connor4312 /cc
Please can you check devtools.

However the Install Python Extension is not a kernel source, its a standard quick pick that is genrated by the Jupyter exetnsion and it works for me and tyler, but not for @connor4312
So, looks like the issue still exists even if we were to fix the issue identified above.


Shadow problems!

Win10, Nvidia 960m godot 3
When i tested my old project some problems were like spotlight didn't worked when shadow was turned on and omni were showing some holes and directional light shadow was far from contact.
But when i build new scene some problems disappeared like spotlight one and omni hole yet i can see see some problems like spotlight have some stripy line at the side of cube, directional light contact problem omni spike line and non gradient shadow as i think omni should have gradient shadow!

OLD PROJECT in new editor

shadow.zip

This is not a bug, this is how shadow mapping works. for the self shadowing
you can adjust the bias or invert face culling to get something you like.
For less jaggy outlines you can either increase shadow resolution or
enhance the filter to PCF13
On Mon, Aug 21, 2017 at 11:55 AM, Himanshu singh<EMAIL_ADDRESS>wrote:

Win10, Nvidia 960m godot 3
When i tested my old project some problems were like spotlight didn't
worked when shadow was turned on and omni were showing some holes and
directional light shadow was far from contact.
But when i build new scene some problems disappeared like spotlight one
and omni hole yet i can see see some problems like spotlight have some
stripy line at the side of cube, directional light contact problem omni
spike line and non gradient shadow as i think omni should have gradient
shadow!
[image: screenshot 86]
https://user-images.githubusercontent.com/13883739/29524892-b12b4786-86ae-11e7-8d8c-3fb45c3598b8.png
[image: screenshot 82]
https://user-images.githubusercontent.com/13883739/29524890-b122fbb2-86ae-11e7-9ed2-4453ab439bc3.png
[image: screenshot 83]
https://user-images.githubusercontent.com/13883739/29524894-b14e2918-86ae-11e7-9d94-100084a297af.png
[image: screenshot 84]
https://user-images.githubusercontent.com/13883739/29524891-b128de88-86ae-11e7-84d8-d37643c9a40c.png
[image: screenshot 85]
https://user-images.githubusercontent.com/13883739/29524893-b1328528-86ae-11e7-83db-34443892e221.png
OLD PROJECT in new editor
[image: screenshot 88]
https://user-images.githubusercontent.com/13883739/29524925-c43ac9c8-86ae-11e7-919e-820719af1001.png
[image: screenshot 89]
https://user-images.githubusercontent.com/13883739/29524927-c4f90d5c-86ae-11e7-9af6-c35ee5a433ff.png
[image: screenshot 87]
https://user-images.githubusercontent.com/13883739/29524926-c49afcb2-86ae-11e7-90a1-097e238d851f.png
shadow.zip https://github.com/godotengine/godot/files/1239168/shadow.zip
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/10504, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z23OO4AgJAw4bCNvRc0vPO2zSro8cks5saZpdgaJpZM4O9dCC
.

there is a shadow mapping tutorial in the godot docs, i suggets you check
that.. it needs to be updated to 3.0 though
On Mon, Aug 21, 2017 at 11:57 AM, Juan Linietsky<EMAIL_ADDRESS>wrote:

This is not a bug, this is how shadow mapping works. for the self
shadowing you can adjust the bias or invert face culling to get something
you like. For less jaggy outlines you can either increase shadow resolution
or enhance the filter to PCF13
On Mon, Aug 21, 2017 at 11:55 AM, Himanshu singh<EMAIL_ADDRESS>
wrote:

Win10, Nvidia 960m godot 3
When i tested my old project some problems were like spotlight didn't
worked when shadow was turned on and omni were showing some holes and
directional light shadow was far from contact.
But when i build new scene some problems disappeared like spotlight one
and omni hole yet i can see see some problems like spotlight have some
stripy line at the side of cube, directional light contact problem omni
spike line and non gradient shadow as i think omni should have gradient
shadow!
[image: screenshot 86]
https://user-images.githubusercontent.com/13883739/29524892-b12b4786-86ae-11e7-8d8c-3fb45c3598b8.png
[image: screenshot 82]
https://user-images.githubusercontent.com/13883739/29524890-b122fbb2-86ae-11e7-9ed2-4453ab439bc3.png
[image: screenshot 83]
https://user-images.githubusercontent.com/13883739/29524894-b14e2918-86ae-11e7-9d94-100084a297af.png
[image: screenshot 84]
https://user-images.githubusercontent.com/13883739/29524891-b128de88-86ae-11e7-84d8-d37643c9a40c.png
[image: screenshot 85]
https://user-images.githubusercontent.com/13883739/29524893-b1328528-86ae-11e7-83db-34443892e221.png
OLD PROJECT in new editor
[image: screenshot 88]
https://user-images.githubusercontent.com/13883739/29524925-c43ac9c8-86ae-11e7-919e-820719af1001.png
[image: screenshot 89]
https://user-images.githubusercontent.com/13883739/29524927-c4f90d5c-86ae-11e7-9af6-c35ee5a433ff.png
[image: screenshot 87]
https://user-images.githubusercontent.com/13883739/29524926-c49afcb2-86ae-11e7-90a1-097e238d851f.png
shadow.zip
https://github.com/godotengine/godot/files/1239168/shadow.zip
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/10504, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z23OO4AgJAw4bCNvRc0vPO2zSro8cks5saZpdgaJpZM4O9dCC
.

okz finally i got what i was doing wrong ! still a bit trouble with directional but i am trying the settings ! thank you!


[UI] Present timestamps in browser's locale

Is this a BUG REPORT or FEATURE REQUEST?:
BUG REPORT
What happened:
the workflow show time is not native time.it is utc

What you expected to happen:
i hope it is set cst
How to reproduce it (as minimally and precisely as possible):
install argo as offical says
Environment:

Argo version:

$ argo version
argo: v2.1.1
  BuildDate: 2018-05-29T20:39:36Z
  GitCommit: ac241c95c13f08e868cd6f5ee32c9ce273e239ff
  GitTreeState: clean
  GitTag: v2.1.1
  GoVersion: go1.9.3
  Compiler: gc
  Platform: linux/amd64

Kubernetes version :

$ kubectl version -o yaml
clientVersion:
  buildDate: 2018-08-07T23:17:28Z
  compiler: gc
  gitCommit: bb9ffb1654d4a729bb4cec18ff088eacc153c239
  gitTreeState: clean
  gitVersion: v1.11.2
  goVersion: go1.10.3
  major: "1"
  minor: "11"
  platform: linux/amd64
serverVersion:
  buildDate: 2018-07-17T18:43:26Z
  compiler: gc
  gitCommit: b1b29978270dc22fecc592ac55d903350454310a
  gitTreeState: clean
  gitVersion: v1.11.1
  goVersion: go1.10.3
  major: "1"
  minor: "11"
  platform: linux/amd64

We also desire this enhancement.

This is for Argo v2.1.1, and now shows time relative.

Thanks, @alexec ! We're using v2.4.3 of argo-ui and we're still seeing the UTC timestamps; is there a configuration change we need to make to get the relative ones? I'm not finding documentation about it.


bower install ion-google-place only picks up 0.0.1

bower install ion-google-place#1.0.2 --save
bower not-cached    git://github.com/israelidanny/ion-google-place.git#1.0.2
bower resolve       git://github.com/israelidanny/ion-google-place.git#1.0.2
bower ENORESTARGET  No tag found that was able to satisfy 1.0.2
Additional error details:
Available versions in git://github.com/israelidanny/ion-google-place.git: 0.0.1

same here

same issue #66


Abstract preset and config to separate command

It is currently necessary to specify which network is being used in every single command. There are also a number of conditional checks for the current preset throughout the codebase to determine which network is being used, and each network has a slightly different configuration. This problem will be exacerbated when we eventually add a mainnet preset.
Would it be possible to separate the configuration into a mn config command (either with args or interactive) and store the current configuration somehow so the checks in the code can be generalized? Would it then become possible to change the command syntax to a simple mn start, with the preset selection done in advance, possibly with any other settings like IP, fullnode/masternode, port, BLS privkey, etc?
Expected Behavior
Preset does not need to be specified in every command, making the tool more intuitive to use for non-technical users. Code is marginally easier to maintain by somehow abstracting preset checks.
Current Behavior
preset must be specified in every command.
Possible Solution
mn config command which must run first and stores config state somewhere in a file. This file would be cleared by a future mn reset command.
Alternatives Considered
None, just thinking aloud here really.

OK, I have a WIP for the config command here. Can you help evaluate my approach and see if this makes sense? It is based on the Stream CLI. A few questions:

Should we be saving the config all in one file with nested JSON, or multiple flat files?
Which specific config options do we want to save in the settings, and what remains in the .env files? Which settings should Docker Compose find in a file and which ones should be passed as arguments? Does it matter?
What is the best way to integrate util/configs.js in the existing functions, what objects should we be passing around, should we load settings through the util or just require the file directly? What sort of validation should we do on settings before loading them?
I'm having a lot of trouble with handling errors and exiting when conditions are met, there is always too much debug info output. How do I use the error handling properly?
config:reset is not implemented yet, I think I need to see (2) answered before trying this.
Lots of comments throughout the code where I could use advice on specific problems, but I can probably resolve most of these myself...

Cool! I'll take a look:

I think, one JSON file is ok.
I would move everything to configs and pass all env variables directly to docker-compose. But there is one case when we need .env when we want to use Docker Compose CLI so in order to address it we could add config:dump <name> that will create .env with env vars for a specific config.
I would read configs in createDIContainer and store it in the container then other code can easily use it as a dependency.
I'll leave comments in code.

Thanks for the comments!

I had a go at changing it so configs are stored in a single file and it resulted in a lot of code that I found difficult to read because of difficulty handling the array indices. Is there a good reason to keep it all in a single file? Or a nicer way of modifying how the data is passed around? A function like set shouldn't need access to the entire array of all configs if it is just changing a single value of the current config. Would it be better to move all functions that deal with writing the file to the util class?
Cool, I totally agree on this one.
I had a go at this but failed due to limited understanding of awilix and DI. I think I'm having trouble switching my thinking to pass around functions that create objects, rather than passing the objects directly. Also, doesn't injecting all of these functions into the context result in a lot more drive and memory operations compared to only loading them when necessary?
Looking forward to working on this with you :)

I feel it will be ok when we introduce 2 classes so it doesn't matter how you store data:

Config

getName() - returns name
get(path) - gets property value (use lodash.get to access nested properties)
set(path, value) - sets property value  (use lodash.set to access nested properties)
reset() - resets config to default. you need to store fromConfig too in order to be able to reset to it.

ConfigManager

loadConfigs() - load configs from file
saveConfigs() - save configs to file
getAllConfigs() - returns all Config instances.
create(name, [fromConfig]) - creates a new config
remove(name) - removes a config
setCurrentConfig(name) - sets current config (config:select)
getConfig(name) - get config instance by name

Container build and inject thing when it requires it so it's lazy loading as you described. You will need just to register asClass(ConfigManager) and then inject it when it needed. Also you need to call loadConfigs in command init (https://github.com/dashevo/mn-bootstrap/blob/245770e08400168b61a583a0f1dae695c41bd277/src/oclif/command/BaseCommand.js#L14)

I’ve proposed another structure in your repo. I would also add validation of config with JSON Schema in order to maintain the right structure. I would add Config#validate and call it on Config#set to prevent of adding wrong options. Also, we need to validate the whole config file on the read and write.


Input waypoints

The directions, distance and surface APIs all require input waypoints. Let's specify this in more detail...
At the python SDK level, all of the services take an iterable/list of GeoJSON-like feature mappings. At the command line, it's not clear to me exactly what the inputs will be.
The CLI will take x and normalize it to a list of features where x could potentially be

line-delimited GeoJSON features on the stdin stream (output of fio cat)
path to a GeoJSON file containing a featurecollection of points (probably the most common case?)
paths to GeoJSON files each containing point features (makes interop with geocoding easier since you're likely to get one feature per call)
stream or file of GeoJSON geometries
stream or multiple args with JSON arrays of coordinate pairs "[lat, lon]" (ala the input to reverse geocoder)
... others? ...

So the question is, What types of inputs will we support for waypoints? On one hand I want to support the most common workflows even if that means accepting a bunch of different input formats. On the other hand, unix design principles - let other tools do the lifting to get data into our expected format.
And on a related note, if we're accepting GeoJSON and the service requires points, how should we handle other geometry types? Automatically explode multipoints and lines to points? Skip them? Be strict? Most of these validation decisions will likely be implemented at the SDK level but it might be useful to discuss them in this context.
cc @sgillies

Seems to me that we've got to support at least these two inputs:

streams of coordinate pairs (either as JSON or comma-delimited pairs), the most abstract input
geocoding output, the least abstract input

Let's put other possible inputs (GeoJSON geometries) aside for now.
To generate a list of waypoints from a list of addresses, a user needs to make multiple geocoding requests, select from multiple results for each, and probably ends up with a feature collection containing point-of-interest type features. Agree with your assessment above that this is the most common use case.
In converting those types of features to points, I think the least surprising thing to do is to compute a centroid of the feature geometry instead of exploding them into multiple points. The workflow is something like this, right?
  Geocoding stuff --> FeatureCollection --> list of [x, y] --> API

utility that merges the best points of interest from every address query into one feature collection

It's a bit funky but bash and fio collect can already do that:
cat <(x-mapbox geocoding "Portland, OR" | jq -c .features[0]) \
    <(x-mapbox geocoding "Bend, OR" | jq -c .features[0]) \
    <(x-mapbox geocoding "Corvallis, OR" | jq -c .features[0]) \
    | fio collect > points_featurecollection.geojson

Your bash fu is strong, @perrygeo.

So the current supported input options are:

Coordinate pair(s) of the form [0, 0], 0,0 or 0 0
An input stream/file containing either a GeoJSON feature or feature collection.
For functions that accept points only, any non-point feature is silently filtered out.

Calling it good for now


Ability to re-order requests in an itinerary

We need to be able to do basic request ordering on the itinerary management page.
The schema includes an orderindex column which we'll use to do this.

@tonysurma You can assign to me please as I have a small start on this


[docs] Content 3: Field and Text Input demos

https://deploy-preview-903--base-ui.netlify.app/new/components/field

@vladmoroz

The input is 42px tall but other buttons/controls are 40px. Heights should be consistent across components. I would use height rather than padding to achieve this.
The input hint seems too far from the input. It also seems odd to me that the label and hint are not equidistant from the input.


feature request: Import support

I was wondering if there where plans to get import support on the roadmap?
https://developer.hashicorp.com/terraform/language/import
This is for us poor unfortunate people that did not deploy day 1 with terraform :/
`
terraform import apstra_asn_pool.Private-4200000000-4294967294 Private-4200000000-4294967294
apstra_asn_pool.Private-4200000000-4294967294: Importing from ID "Private-4200000000-4294967294"...
Error: Resource Import Not Implemented
This resource does not support import. Please contact the provider developer for additional information.
`

At this time, we have not implemented any.
Hi, were there any specific resources/use-cases you were interested in?


[ja] Add dockerhim depreaction FAQ blog post

Add dockerhim depreaction FAQ blog post and modify related links/messages.

add https://kubernetes.io/blog/2022/02/17/dockershim-faq/
rename https://kubernetes.io/ja/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/ to check-if-dockershim-removal-affects-you and chenge "deprecation" to "removal" in its content (from 9211599)
add dockershim-removal codeblock i18n (adding dockershim_message variable)

This closes #39251.

/assign

@nasa9084 Thank you! I applied your suggestions.

/approve
please wait for other reviewer to review

@t-inu Thank you for your thorough review! I applied your suggestions.

/retitle [ja] Add dockershim deprecation FAQ blog post


Update Composer dependencies (2021-10-19-00-04)

Visual regression test passed!
View the visual regression test report


Cloudstate protobuf files define an incorrect and incompatible "go_package"

All Cloudstate .protobuf files define an incorrect and incompatible go_package:
https://github.com/cloudstateio/cloudstate/blob/v0.5.1/protocols/protocol/cloudstate/event_sourced.proto#L27
option go_package = "cloudstate/protocol";

While this works to some extent, some tools don't like the incorrect use of such a go package, one is CUE.
The protocol buffers reference documentation defines:

The .proto file should contain a go_package option specifying the full import path of the Go package that contains the generated code.

which leads to the following correct definition:
option go_package = "github.com/cloudstateio/go-support/cloudstate/protocol;protocol";

The Go User Language Support Library with milestone v0.2.x corrects this. Changes have to be copied over to the main repository.

@marcellanz, sounds good to just go ahead and apply these changes to the cloudstate repo.


Errors like below occurred:
=== RUN   TestSubmit
    submit_test.go:131: in git-client/, ran [git tag -f work.mailed] with git version 2.39.2
        :
        exit status 1
        error: There was a problem with the editor 'false'.
        Please supply the message using either -m or -F option.
--- FAIL: TestSubmit (0.43s)

What did you expect to see?
All test passes.

Thanks for reporting this.
The git configuration surface is quite large, and this appears to be a case where one of the configuration values conflicts with the expectations of git-codereview, causing test errors.
Can you clarify if this is causing a problem for your workflow? Or are you simply reporting it because you spotted it?
While git-codereview can be updated for this particular case, it might not be viable to do that holistically. An alternative approach is to not to use this configuration when working with Go repositories. For example, that can be done by running git config --local commit.gpgsign false inside Go repositories where you need to use git-codereview. Would that work?

Thanks for your comment.
I reported this simply I spotted it.
Sorry I was not accurate about the description in "What did you do?" section.
Actually I happen to set commit.gpgsign and tag.gpgsign to true in my ~/.gitconfig.
I tried again with setting commit.gpgsign and tag.gpgsign to false locally:
$ git config --local commig.gpgsign false
$ git config --local tag.gpgsign false

Verify the configs:
$ git config --get-all commit.gpgsign
true
false
$ git config --get-all tag.gpgsign
true
false

Test still fails, for example:
$ go test -v -run TestHookPreCommitEnv
=== RUN   TestHookPreCommitEnv
    hook_test.go:328: in git-client/, ran [git tag work] with git version 2.39.2
        :
        exit status 1
        error: There was a problem with the editor 'false'.
        Please supply the message using either -m or -F option.
--- FAIL: TestHookPreCommitEnv (0.30s)
FAIL
exit status 1
FAIL    golang.org/x/review/git-codereview      0.304s

The commit used for test is:
$ git rev-parse HEAD
c91ae924997076a8e6e6f16d1d9fb75f812e0cdd

However with the following diff:
$ git diff HEAD~
diff --git a/git-codereview/util_test.go b/git-codereview/util_test.go
index 931d017..932e7ab 100644
--- a/git-codereview/util_test.go
+++ b/git-codereview/util_test.go
@@ -200,6 +200,7 @@ func newGitTest(t *testing.T) (gt *gitTest) {
                write(t, client+"/.git/hooks/"+h, "#!/bin/sh\nexit 0\n", 0755)
        }

+       trun(t, client, "git", "config", "tag.gpgsign", "false")
        trun(t, client, "git", "config", "core.editor", "false")
        pwd, err := os.Getwd()
        if err != nil {

Now the test passes:
$ go test -v -run TestHookPreCommitEnv
=== RUN   TestHookPreCommitEnv
    hook_test.go:335: git-codereview hook-invoke pre-commit
    hook_test.go:335: stderr:
        git-codereview pre-commit gofmt hook disabled by $GIT_GOFMT_HOOK=off
--- PASS: TestHookPreCommitEnv (0.35s)
PASS
ok      golang.org/x/review/git-codereview      0.354s

I think this is just about the unit test in git-codereview which creates new repositories?


Unable to send a message

I can request validation code, and I can register account.
But when trying to send a message, the application keeps loading, and give me the following:
tx  <stream:features></stream:features>

tx  <auth user="[my phone number]" mechanism="WAUTH-2"></auth>

rx  <from s.whatsapp.net=""></from>

rx  <stream:features></stream:features>

rx  <challenge>ec3e7fe586cb571b720f477f03e2ccf63d32cc21</challenge>

tx  <response>c5ebfd0732d1389ba5176b4fa082036059517acb5606e763fc46c8161c35b60ae31676038a146f8f8f2caa7d6cb733bc44bc1e720019ea641bfd76e7cb3237d8853455b1fcec485249c94a271b</response>

tx  <iq id="1" xmlns="w:p" type="get" to="s.whatsapp.net">
tx    <ping></ping>
tx  </iq>

tx  <iq id="2" xmlns="w:p" type="get" to="s.whatsapp.net">
tx    <ping></ping>
tx  </iq>

tx  <presence type="unavailable"></presence>

tx  <stream:features></stream:features>

tx  <auth user="[my phone number]" mechanism="WAUTH-2">dea977a53835323935363532393630ec3e7fe586cb571b720f477f03e2ccf63d32cc2131343833353134303332</auth>

rx  <from s.whatsapp.net=""></from>

rx  <stream:features></stream:features>

rx  <challenge>a5db87fbd84a6774ad9cc52c8c3ea1940a4f95a2</challenge>

tx  <response>eda35543e5c798cd6ba040853f90f9a9e2c905eb5e95f8d2dfe2f69b74dc67b44d6e2acb506eff7bd0168579dc2dddf4e49fcad059fa61a687613b2a5ab70a5cf722b4f9fd3db34fb3c9926620</response>

My environment is OS X 10.11.6,
XAMPP with php 5.6.24,
Laravel 5.3.28

I have exactly the same problem. I think WP has change their protocol and there is nobody who check and fix the chat-api for free.

Hi guys, did anyone manage to solve this issue?


feat(migrations): Support migrations across all encrypted storages supported by pluto encrypted

This is a relative big PR so i'll extend my explanation here and let the review go with enough space.
The main reason why we cannot make it work with the default migration plugin provided by rxdb is that, password protected databases are part of another plugin, and migration plugin is not aware of this, so, won't be passing the instance password to the creation of a new migrated storage, ending in errors.
Also, LevelDB came from the inMemory implementation which was not really removing the data, but updating the data with .deleted=true field, which leads to multiple issues. I've refactored inMemory and LevelDB in order to prevent that, trying to minimise code duplication as much as possible.

:tada: This PR is included in version 1.1.0 :tada:
The release is available on<EMAIL_ADDRESS>Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.1.0 :tada:
The release is available on<EMAIL_ADDRESS>Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.2.0 :tada:
The release is available on<EMAIL_ADDRESS>Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.2.0 :tada:
The release is available on<EMAIL_ADDRESS>Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.2.0 :tada:
The release is available on<EMAIL_ADDRESS>Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.1.0 :tada:
The release is available on<EMAIL_ADDRESS>Your semantic-release bot :package::rocket:


[Feature Request] : (Enhancement): NeoError

Currently there generic error interface that is used to throw error.
As well as the result errors are not part of the error but need to explicitly check record.
record.Err()
Instead of this can we have a checked NeoError which does proper error mapping with error code , message etc...
also moving the error from record interface and Session.Run itself maps internally to avoid checking the error.
Neo4j Version: 4.x Community
Neo4j Mode: Single instance
Driver version: Go driver 1.8.2
Operating System: Ubuntu 16.10 on AWS

Hi @grizzly-monkey
I'm not sure exactly what you mean with some of these suggestions.
I cannot see us changing the driver methods to not return the "generic error" interface, I haven't seen any Go package that doesn't use standard error handling. But that is maybe not what you suggest. The 1.8 driver is backwards compatible with 1.7 and shouldn't change much, there is ongoing work on a 4.0 driver with quite a lot of API changes, in this version the database error will be made public so you could check if err is of that type. Please look at 4.0-dev branch for more info..
Not sure what you mean with check record error, there is no record.Err function. Do you mean that you need to check result.Err() before retrieving a record? But that isn't the case, if result.Next returns true, there is a record, you only need to check result.Err when result.Next returns false.
On 1.7, database errors were not returned until starting iterating, so on 1.8 session.Run sometimes "delays" the error to be backwards compatible. On upcoming 4.0 driver this will not be the case. Not sure if this is what you mean with "Session.Run itself maps internally..".

https://github.com/mongodb/mongo-go-driver/blob/master/mongo/errors.go
Was talking about these kinda error wrapper instead of return errors.New("some error")

What is the reason you want the underlying error structs? They are used internally to control retry logic and other things. But if we are exposing them they are part of the API.
It helps in mapping the errors or categorizing them. What I am doing is depending upon the DB error code i map it to  appropriate HTTP status code eg. 400 , 502 etc...

Access to the database error is already in the plan for upcoming 4.0 release of the driver. Not sure what we do for 1.8.
I doubt that the database errors will be very helpful for generating HTTP status codes. You need to check the Neo4j manual for types of errors, these are the kinds of errors you get when you can connect to a database instance, other types of errors will not be database errors.

okay i will wait for 4.0 release.. any ETA for this ?


Automated reports in local using docker compose - Failed taking a screenshot Message: 'geckodriver' executable needs to be in PATH.

Following the docker-compose for non dev, configured it locally on Mac OSX, I was unable to get the reports to my email even after setting up the SMTP setting
How to reproduce the bug

Go to 'https://superset.apache.org/docs/installation/installing-superset-using-docker-compose'
Follow the setup to install and run the Apache super set using the docker
Enabling Alerts and Reports features with Redis, celery_best schedule, and other configurations as specified in the setup
After setting up reports for a sample or custom-created chart I see the below errors.

Expected results

email to be recieved
what you expected to happen.

Actual results
Errors
what actually happens.
Screenshots
Since I was receiving gecko-driver errors, I tried to install them in requirement.txt but it din't work, please let me know what to be added in requirements txt so that gecko-driver is installed,

Environment
(please complete the following information):

browser type and version: chrome
superset version: superset version 2.1.0
python version: python --version 3.8
node.js version: node -v docker node
any feature flags active: Alerts and Reports

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[ Yes ] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[ Yes ] I have reproduced the issue with at least the latest released version of superset.
[ Yes ] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
Add any other context about the problem here.

Have you tried running the -dev image of whatever Superset version you want to deploy?
From the Alerts & Reports documentation:

Note: All the components required (Firefox headless browser, Redis, Postgres db, celery worker and celery beat) are present in the dev docker image if you are following Installing Superset Locally. All you need to do is add the required config variables described in this guide (See Detailed Config).
If you are running a non-dev docker image, e.g., a stable release like apache/superset:2.0.1, that image does not include a headless browser. Only the superset_worker container needs this headless browser to browse to the target chart or dashboard. You can either install and configure the headless browser - see "Custom Dockerfile" section below - or when deploying via docker-compose, modify your docker-compose.yml file to use a dev image for the worker container and a stable release image for the superset_app container.
Note: In this context, a "dev image" is the same application software as its corresponding non-dev image, just bundled with additional tools. So an image like 2.0.1-dev is identical to 2.0.1 when it comes to stability, functionality, and running in production. The actual "in-development" versions of Superset - cutting-edge and unstable - are not tagged with version numbers on Docker Hub and will display version 0.0.0-dev within the Superset UI.

This is not a bug report, it's a configuration question, so I'm going to close this and convert to discussion.  Feel free to keep talking in the discussion if you have further issues.


2.1.3: mongoose.c please clarify license

https://github.com/ariya/phantomjs/blob/master/src/mongoose/mongoose.c#L6-L7

Copyright (c) 2014 Cesanta Software Limited
All rights reserved

mongoose.c have no license grant which usually non-free (i.e. proprietary) but Mongoose appears to be GPL-2 licensed.
Please document the license.

Any plan for version > 2.1.1 is effectively abandoned. Please see #15344 for more details.


openshift: wait for build pod separately

Fixes the openshift CI fail in https://github.com/sclorg/s2i-php-container/pull/283

@phracek PTAL

Not sure if ct_os_wait_rc_ready is being used with s2i builds, but if yes I would rather split the function in two (one to check s2i build result and one to check for rc status).

@pkubatrh In case of POD failed, like here: https://gist.github.com/rhscl-bot/399ec0aac1d605f5183bcb004f1629b5#file-s2i-php-container-48-sh-L4513 I don't see any output from oc?
That was the reason why I have added a function ct_os_get_status. But we can use ct_os_print_logs instead of ct_os_get_status
The function ct_os_enable_print_logs is not used by in test-lib-openshift.sh. I did not find out any call. It has to be called directly from container. Like here: https://github.com/sclorg/postgresql-container/blob/master/test/run-openshift-local-cluster#L422

Well yes, ct_os_enable_print_logs needs to be run in the container tests to enable the print logs feature, it is not enabled by default. But once it is enabled the logs get printed out on any failure during the test run.
If we added your suggestion to this PR then the logs would be printed out twice for this specific failure, if the print log feature is enabled. Is this explanation more understandable?


cpu_spec: add :icelake

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

I noticed that the :icelake family was missing from here while running brew tests.
Note that for my machine, from brew config:
CPU: octa-core 64-bit icelake

Note also that :icelake is already located in cpu.rb (and also in the Linux one).

Thanks for the fix @miccal!

เมื่อ อา. 21 มิ.ย. 2563 เวลา 17:13 Jonathan Chang<EMAIL_ADDRESS>เขียนว่า:

Thanks for the fix @miccal https://github.com/miccal!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Homebrew/brew/pull/7775#issuecomment-647107899, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AP55P56AXUEI5JFJ6TWT22LRXXMMNANCNFSM4ODH5O7Q
.


Relase training pipeline, training cost ,and training dataset?

Hi,
Is releasing training pipeline, training cost ,and training dataset on the schedule?
Thanks!

Ehh, this model performance less than I expected, seems the data used has made Yi-34B more like LLaMA sft models instead of Yi.
Some Yi-34B flavor has lost


Allow newer jwt versions (>=1.5.2)

Due to strict versioning, jwt may clash with existing other gems. To fix this, we allow JWT lib equal and greater then 1.5.2
See: #23

Coverage decreased (-12.2%) to 84.706% when pulling 3bdaf7da7a0c27847a235808937a72f7700b1b68 on gencer:patch-1 into cbc68b5a6ec59ebf65a884c3fad2c8a59d95aca5 on chriswarren:master.

Hm.. I'm thinking this failures could be the reason of Ruby v2.2.1 targeted.

It looks like 11 of the 12 failures are around 2 identical problems, so getting tests passing hopefully won't be too bad.
I won't be able to merge this until you've addressed them. I think doing that should raise the test coverage back up as well.
If you're not interested in doing that we can close this until I have time to look at it, but I don't know when that will be.


Neodigm Parallax | iOS Safari Mobile

While parallax is turned OFF by default on mobile, it is possible to turn it on. Do this with caution because it will not work properly on an iPhone. This is a known Safari issue. If we can find a graceful compromise, thats cool, but we will not be doing the "if safari" thing.

This is not really an issue. The answer is to not turn it on for mobile, simply accept the library's default.


Fix regular expression for used disk space check output

The current regular expression, which matches the command line output for the used disk space check, parses a maximum of two digits.
Example
This means that a disk usage of 100% is actually parsed as 00%, which is obviously wrong. I think it is okay to simply parse any digit before the % sign.
Example

Thank you!


Provide example of how to test dependencies which depend on Request object

First check

[x] I added a very descriptive title to this issue.
[x] I used the GitHub search to find a similar issue and didn't find it.
[x] I searched the FastAPI documentation, with the integrated search.
[x] I already searched in Google "How to X in FastAPI" and didn't find any information.
[x] I already read and followed all the tutorial in the docs and didn't find an answer.
[x] I already checked if it is not related to FastAPI but to Pydantic.
[x] I already checked if it is not related to FastAPI but to Swagger UI.
[x] I already checked if it is not related to FastAPI but to ReDoc.

Example
Here's a self-contained, minimal, reproducible, example with my use case:
from fastapi import FastAPI

app = FastAPI()

class User:
    def __init__(self, name):
        self.user = name

def get_user(request: Request):
   # look at request headers to determine user and do other stuff
   return User(request.headers["user"])

@app.get("/")
def read_root(user: str = Depends(get_user)):
    return {"Hello": user}

Description
What is the recommended way to test a dependency, like get_user in the example above? I cannot find an easy way to instantiate a Request object and populate the proper HTTP headers to pass into get_user during a test.
I am aware of dependency_overrides, however this doesn't help because I don't want to stub out get_user, I want to verify that it returns the proper values, which are not easily observable from the responses from the actual endpoints.
I am aware of TestClient, however since this app uses a database, it requires significant effort to stub/mock out all the interactions for the entire app, just to exercise this internal method.
Environment

OS: Ubuntu 20
FastAPI Version: 0.63.0
Python version: 3.8.9

@ascended121,
You could do:
def test_get_user():
    r = Request(scope={"type": "http", "headers": [[b"user", b"example_username"]]})
    user = get_user(r)
    assert user.user == "example_username"

Thank you. I was struggling to figure out how to instantiate the Starlette Request object which was making it seem like it there wasn't an easy way to instaniate them... didn't pick up that it needed to be a double-list containing byte-arrays. Much appreciated.

Thanks for the help here @SnkSynthesis ! 👏  🙇
Thanks for reporting back and closing the issue @ascended121  👍

Sorry for the long delay! 🙈  I wanted to personally address each issue/PR and they piled up through time, but now I'm checking each one in order.


zeppelin dependency break on Dataproc image version 1.3

Accessing snappy compressed files (parquet, avro) results in an error:
org.apache.spark.SparkException: Job aborted due to stage failure: Task 0 in stage 1.0 failed 4 times, most recent failure: Lost task 0.3 in stage 1.0 (TID 4, dataproc-jball-w-0.c.viv-speed.internal, executor 2): java.lang.UnsatisfiedLinkError: org.xerial.snappy.SnappyNative.uncompressedLength(Ljava/nio/ByteBuffer;II)I
at org.xerial.snappy.SnappyNative.uncompressedLength(Native Method)
at org.xerial.snappy.Snappy.uncompressedLength(Snappy.java:565)

This is an upstream issue in Spark SPARK-24018, which we are working on fixing.
In the meantime a workaround is the initialization action of:
rm -f /usr/lib/spark/jars/snappy*
wget https://repo1.maven.org/maven2/org/xerial/snappy/snappy-java/<IP_ADDRESS>/snappy-java-<IP_ADDRESS>.jar \
   -P /usr/lib/spark/jars

I'll leave the issue open until it is fixed in Dataproc image version 1.3.

I can confirm this works against dataproc version 1.3.1.

Seems to have been fixed last year: https://cloud.google.com/dataproc/docs/release-notes#august_24_2018


fix(networks): review how networks are loaded for usage in multiple v…

…iews
Reviews how the networks are loaded in different views & using different providers:

Provider Docker Swarm mode:

templates: local networks + swarm attachable networks (API version > 1.25)
container-creation: local networks + swarm attachable networks (API version > 1.25)
container-details (join list): local networks + swarm attachable networks (API version > 1.25)
service-creation: all swarm networks

Provider Docker Swarm standalone:

templates: global networks
container-creation: global networks
container-details (join list): global networks

Provider Docker standalone:

templates: local networks
container-creation: local networks
container-details (join list): local networks
Fix #1103

An image is available for this implementation: portainer/portainer:pr1104 (linux amd64 build)


Question about personality keys used in USBPorts.kext

I'm attempting to improve my USB situation. I've been using my own version of USBPorts.kext, generated with trial-and-error using Hackintool, but it's far from perfect and I don't think Thunderbolt is working correctly.
When reviewing this repo's USBPorts.kext file I noticed that the IOKitPersonalities use iMacPro19,1 even though PlatformInfo info is iMac19,1.
https://github.com/baughmann/designaire-z390-intel-i9-9900k-opencore/blob/1fcca8f9fb662fe127b2efa6b363940270faf98b/EFI/OC/Kexts/USBPorts.kext/Contents/Info.plist#L25
https://github.com/baughmann/designaire-z390-intel-i9-9900k-opencore/blob/1fcca8f9fb662fe127b2efa6b363940270faf98b/EFI/OC/Kexts/USBPorts.kext/Contents/Info.plist#L212
a. Typo and the keys of "personalities" don't really matter?
b. It's important that they use iMacPro19,1 instead of iMac19,1 for reasons?
c. None of the above?

Hi @JonMcL I think you're right about the key values. My understanding from creating my own USB map was they needed to match the SMBIOS of you computer. I think the "newer" method being used USBToolbox avoids this as it states

Override any built-in Apple USB maps attaching based on SMBIOS and controller name

but it wasn't used for this kext. As such they should be iMac19,1 and not iMacPro19,1.  I'll look into this a bit more to see if I can include 2 personalities (MacPro7,1 and iMac19,1) in the USBPort.kext, otherwise I'll update and rename the old USBPorts.kext as an optional download for those continuing to use iMac19,1.
Thanks for this.

New USBPorts.kext included in the latest EFI should resolve this issue. Thanks.


zh_cn fix for 6.3.0 prerelease1

Use blockstates for kakejuku...?

It is too late to use blockstates...


GoLive Activities Checklist - MackTrucks BO

Checklist of all activities needed for the GoLive of MackTrucks BO:
Preparation tasks

[x] #1

Pre, during, and post-GoLive:

[ ] #2

Pre-GoLive:

[x] #3
[x] #4
[ ] #5
[x] #6
[x] #7
[ ] AEM GoLive steps:
Performance validation
Legacy redirects
Favicon
CDN configuration
Update production host

Post-GoLive:

[ ] AEM Post-GoLive Validation:
Performance validation
404 Report

Content migrated and site is live


fix(cassandra) change float to number schema field

Summary

float doesn't exist as a schema field. Aligns C* with postgres

@darrenjennings please rebase branch/PR to master (we'll cherry-pick this for 1.4.0 final)


Feature: Add support for the mouse back/forward buttons

Currently, Nora handles changing pages using the Alt + Left Arrow and Alt + Right Arrow keyboard shortcuts.
It would be great if Nora also handles the mouse Back and Forward buttons.

Hi! That feature is already being worked on and should be released in one of the next updates :D
Thanks a lot for the suggestion ❤


Http2 to origin

This implements the HTTP/2 to origin feature.

This is a rebase of #8963 from 10-Dev onto master. The only way to change the base branch of a PR is to re-open a new PR.

[approve ci]

LGTM, I will look at trailers separately and continue testing it

Let me quickly review the entire change once again. I'm not going to go into the detail this time but I'd like to make sure anything important isn't removed or commented out.


Rename module to github.com/grafana/gomemcache

The upstream repo github.com/bradfitz/gomemcache looks stale, the last commit was made 1.5 months ago, and commit before the last one was made almost 1 year ago. Open PRs are waiting for review for a long time.
I suggest moving to grafana fork as a main dependency in repos where this dependency is used to get rid of replacement directives.
For example loki: https://github.com/grafana/loki/blob/9d5665e34aba3fb01cd17aa5c16c562af0ea8a06/go.mod#L324. This replacement is there for more than 2 years

@bboreham could you please take a look? I couldn't add reviewers, that's why mentioned you :)

On a point of detail, my upstream PR was reviewed in October this year.

I meant that when a repo is a fork, the default behavior of Github's UI is to open PRs on the original repo.


Bot core proposal

We want to serve a large programming community with varying competency. For this reason I would like to have a core bot built in Python using discord.py, and very quickly dispatch in a generic way into modules that can be written in any language. The onus is on the contributor to integrate whatever language they're using.
I think the core bot should look something like this:
from modules import *

commands = {
    'weather': weather.weather,
    'eval': runner.evaluate,
}

async def on_message_or_whatever():
    if command in commands:
        post_message(commands[payload]())

Where we pull in everything with a modules directory, which will contain the entry point for every command, regardless of what language it is written in. We define a dictionary or config file that maps bot string commands such as !bot weather onto a Python function that takes the contents of the message, and returns the contents of a reply message. The primary job of the core bot is to dispatch to handlers, and to avoid making this overcomplicated so that people unfamiliar with Python have little difficulty integrating their work.

Sounds good to me. I can see the flow going something like
run bot->
on_message event handler called->
redirects to command handler in bot core->
bot core either connects to something that links languages in core,
  or a module that links to other language on its own ->
function called and returned, and answer posted by bot

The on_message event handler definitely works with discord.py. I think Mathbot does it, so someone can take some inspiration from there if needed.

I like it, can we finalize on what the directory should look like?

All the basic stuff at the top level, and put all the commands in a directory. Now add something already.

How do we wanna call the bot in the server? !bot <cmd> is what it was and I was thinking -ab <cmd> for new version?

Sounds good to me. I would prefer something more specific that just calling it bot

Prefix can be dynamic, we can pick a placeholder for now and make awesomebot fetch prefix from the config.


Switch RHCOS_IMAGE_URL to reflect changes in openshift-installer.

Switch RHCOS_IMAGE_URL to reflect changes in openshift-installer.
Per commit https://github.com/openshift/installer/commit/8599867bef65c539e7fe2ea39dd1d1c5b4df79f5
baseURI was changed to releases-art-rhcos.svc.ci.openshift.org,
since it now has publicly accessible storage.

This looks right.  However I want to explain that we are trying to introduce "oscontainer only" builds.  That's why the tip build in the previous URL doesn't have openstack (or any other image).
See https://url.corp.redhat.com/a61eba3

This looks right. However I want to explain that we are trying to introduce "oscontainer only" builds. That's why the tip build in the previous URL doesn't have openstack (or any other image).

@cgwalters thanks for the additional context.  I feel like we need to figure out a better way to consume changes like this though - is there any way to consume a periodic tag of both OS images and container images?
We're reacting to changes almost every day, and ideally I think we should rebase openshift-metalkube/kni-installer at the start of each sprint, pin to the latest/recent OCP artifacts at this point, then hopefully have fewer reactive firedrills when things change that we weren't aware of.
Would, say, a weekly tagged build be feasable to help us improve stability during our sprints?

Build FAILURE, see build http://<IP_ADDRESS>:8080/job/dev-tools/560/

is there any way to consume a periodic tag of both OS images and container images?

I think that tag is reflected in the pinned bootimage in openshift/installer.

(As far as container images, released installers pin the release image)

Build SUCCESS, see build http://<IP_ADDRESS>:8080/job/dev-tools/561/

We went with https://github.com/openshift-metalkube/dev-scripts/pull/359 since that couples us to the version used by kni-installer instead of using either hardcoded or latest versions, thanks!


Automatically move assigned PRs into champion columns

Several team members have requested that when a PR is assigned to them, that it should be automatically moved into their column on the PR project board. When we introduced the issue/PR project boards, we stated that there would be no automation to move issues/PRs into the "middle" columns, but this is a popular enough request that we should consider it.
We could do the same with issues as well--if an issue gets assigned to pod member, but the issue is still untriaged, it could be moved into their triage column.
If we do implement this, we'll need to have something that maps the github username to the pod member's columns on the boards.

There are issues with how this was implemented.  The pullRequestNeedsChampion and pullRequestChampionAssigned tasks are battling each other. pullRequestChampionAssigned only fires when the pull request is already on the project board in the Needs Champion column. But the pullRequestNeedsChampion task moving the pull request onto the board won't trigger the other task to fire.
We'll need to approach this differently, likely combining those two tasks together and using conditions on the author of the PR to go directly to their column, or perhaps to have the Needs Champion task first add it to the board and then move it to the column for the author (which should gracefully fail).

Test comment


Features/fix uart flow control

Added support for uart hardware flow control

Removed up related changes and put in a separate pull request


Datadog provider is out of date

Thank you for reporting an issue.
The latest Datadog provider version in the OpenTofu registry is v3.44.1 while the Terraform registry is at v3.46.0.
We previously ran terraform but switched to tofu in our pipelines, and terraform pinned the version to v3.46.0. This breaks the automation, and I'm unable to switch between versions/registries.
I've tried setting TERRAGRUNT_TFPATH='terraform' in order to try to force the Terraform registry, but it didn't work. I've also tried to run terragrunt state replace-provider 'registry.opentofu.org/datadog/datadog' 'registry.terraform.io/datadog/datadog' which just fails like plan with the following error:
│ Error: Failed to install provider
│
│ Error while installing registry.opentofu.org/datadog/datadog v3.46.0:
│ authentication signature from unknown issuer

The fix is the update, but if anyone can provide a workaround to swap the registry or downgrade the version, I'd appreciate that too.
OpenTofu Version
OpenTofu v1.6.2
on darwin_amd64

OpenTofu Configuration Files
terraform {
  required_version = ">= 1.0.0, < 2.0.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    datadog = {
      source  = "DataDog/datadog"
      version = "~> 3.44"
    }
  }
}

As discussed in the OpenTofu Slack, this UI shows an incorrect latest version and the OpenTofu registry does contain v3.46.0. My issue was caused by swapping back and forth between terraform and tofu and getting it in a weird state.
Switching back to tofu while using terragrunt was the solution in this case.


TFLite benchmark tool - example to use input_layer_value_files

Please go to Stack Overflow for help and support:
https://stackoverflow.com/questions/tagged/tensorflow
If you open a GitHub issue, here is our policy:

It must be a bug, a feature request, or a significant problem with the
documentation (for small docs fixes please send a PR instead).
The form below must be filled out.
It shouldn't be a TensorBoard issue. Those go
here.

Here's why we have that policy: TensorFlow developers respond to issues. We want to focus on work that benefits the whole community, e.g., fixing bugs and adding features. Support only helps individuals. GitHub also notifies thousands of people when issues are filed. We want them to see you communicating an interesting problem, rather than being redirected to Stack Overflow.

System information

Have I written custom code (as opposed to using a stock example script
provided in TensorFlow): No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 20.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue
happens on a mobile device:
TensorFlow installed from (source or binary): Source
TensorFlow version (use command below):
Python version:
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:
Exact command to reproduce:

You can collect some of this information using our environment capture script:
https://github.com/tensorflow/tensorflow/tree/master/tools/tf_env_collect.sh
You can obtain the TensorFlow version with:
python -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"

Describe the problem
I am trying to use the Android TFLite benchmark tool to run inference time analysis for my TFLite model. Going through the repo, I am interested in passing custom inputs to the benchmark tool. I am specifically looking for how to use input_layer_value_files flag. Could you provide an example of a sample file? Thanks!
Source code / logs

@AbinayaKumar25
Could you please refer to the Benchmark tools and let us know if it helps.
Thank you!


Should configure resource usage

Presently system gets crippled when running for a long time. To avoid this:

Limit resource usage for processes.
allow signal from outside sbt, after limiting jvm resources.

Main problem seems to be the server having the wrong memory.

Not clear this is needed (as problem was with server).


feat: export io_source::IoSource

We implemented it, but never export it.

It seems an internal concept. But the mio::net::TcpListener and TcpStream is different from std ones, especially lack of methods. I wonder if it's necessary.


Printer function not work with online printer

Describe the bug
When used function "printer" with online printer or pdf printer not show the list of printer and no generate printer property in object.

systeminformation package version: 4.34.7
OS: Ubuntu and Windows 7

@ferlolo si.printer() is not part of systeminformation Version 4. You can try Version 5 and it would be great if you try the following code directly in node:
const si = require('systeminformation');
si.printer().then(data => console.log(data));

If you still encounter problems here, please post the full output of the above code.
Closing it for now.


[Server] Streaming replication endpoints (only sending)

Endpoint to list all files SINCE given date (or since beginning)
Permissions for replication
File fetching in replication endpoint
Support for server-side encryption in replication mode (for zero-knowledge backup replication)

This does not make sense in this form.
Reworked concept into "SecureCopy" - a mechanizm to provide a copy of files, but not a working replica. The copy mechanism is called secure, because it supports a zero-knowledge copying using server-side encryption. In future there may be a possibility to store multiple versions of files and restore automatically on-demand given version of file.
Replication could be better implemented using distributed filesystems such as glusterfs, drbd, s3 and by database replication in PostgreSQL and MariaDB.


Failed fetching remote preset: auth error

Version
3.0.5
Reproduction link
http://localhost:8080
Node and OS info
npm
Steps to reproduce
no
What is expected?
it's work
What is actually happening?
Failed fetching remote preset git@gitee.com:lisiyizu/helloworld.git

I believe this is a problem that most people will encounter.

https://cli.vuejs.org/guide/plugins-and-presets.html#remote-presets
preset.json is required for presets.

thanks again!


Remove the network plugin syncer from submariner

create the CRD in route agent by adding a hander in response to an endpoint create event.
Remove the network-plugin-syncer
Update kind to have an OVN IC setup

We also need to make sure we stop referencing it in subctl, e.g in places like diagnose and related-images.

We also need to make sure we stop referencing it in subctl, e.g in places like diagnose and related-images.

I already have a local commit for that.


cilium status doesn't report IPAM pools in k8s mode

A user reported in Cilium slack the output of cilium status:
$ kubectl -n kube-system exec -it cilium-4q4j8 -- cilium status
KVStore:                Ok   etcd: 1/1 connected: https://cilium-etcd-client.kube-system.svc.cluster.local:2379 - 3.2.22
ContainerRuntime:       Ok   docker daemon: OK
Kubernetes:             Ok   1.11 (v1.11.3) [linux/amd64]
Kubernetes APIs:        ["core/v1::Node", "core/v1::Namespace", "CustomResourceDefinition", "cilium/v2::CiliumNetworkPolicy", "networking.k8s.io/v1::NetworkPolicy", "core/v1::Service
", "core/v1::Endpoint", "core/v1::Pods"]
Cilium:                 Ok   OK
NodeMonitor:            Disabled
Cilium health daemon:   Ok
Controller Status:      20/20 healthy
Proxy Status:           OK, ip <IP_ADDRESS>, port-range 10000-20000
Cluster health:   4/4 reachable   (2018-09-19T18:07:55Z)

Compare with output from a non-k8s setup in dev VM:
$ cilium status
KVStore:                Ok         Consul: <IP_ADDRESS>:8300
ContainerRuntime:       Ok         docker daemon: OK
Kubernetes:             Disabled
Cilium:                 Ok         OK
NodeMonitor:            Listening for events on 2 CPUs with 64x4096 of shared memory
Cilium health daemon:   Ok
IPv4 address pool:      3/65535 allocated
IPv6 address pool:      2/65535 allocated
Controller Status:      12/12 healthy
Proxy Status:           OK, ip <IP_ADDRESS>, port-range 10000-20000
Cluster health:   1/1 reachable   (2018-09-19T18:20:49Z)

This is because the user most likely had debug-mode disabled:
https://github.com/cilium/cilium/blob/5dc61ed8d21bf62ce53917c622f2c36639cf7309/daemon/status.go#L160-L162
This is an easy fix as we can unconditionally dump the IPAM in the status. However, we do lock the ipamConf.allocatorMutex when dumping; is that perhaps the reason we we only want IPAM information in the status output when debug is enabled? cc: @raybejjani , @tgraf

is that perhaps the reason we we only want IPAM information in the status output when debug is enabled?

That lock should practically never be contented so it's absolutely fine to hold it.


Update django support

Problem

Remove Django 3.1 from Python 3.10 env in tox.

Confirm support for Django 4.0

Add USE_TZ setting.

Solution
Explain the solution that has been implemented, and what has been changed.
Commandments

[ ] Write PEP8 compliant code.
[ ] Cover it with tests.
[ ] Update CHANGES.rst file to describe the changes, and quote according issue with GH-<issue_number>.
[ ] Pay attention to backward compatibility, or if it breaks it, explain why.
[ ] Update documentation (if relevant).

Thanks @adamchainz for your review!


Write unit tests for grappviz dot files

Tests for changes in: 52bce89fb6e7855c71ddc30b4f2d1e530b453944

Hey, i will take this issue if you let me!