Boost default tick rate to double digit kHz on tickless hardware

Since the introduction of pervasively-supported tickless mode, it's been possible for apps to achieve effectively arbitrary timing precision (up to the limits of the hardware counter, of course) by adjusting the CONFIG_SYS_CLOCK_TICKS_PER_SEC value.
But experience has shown that this mechanism is too confusing or too controversial for app authors, its uptake has been very low, and there are now currently two separate reimplementations of system timing architectures in review.  All to achieve a feature that... was supposed to already be present.
So let's just make it default.
On all tickless capable hardware platforms, the default tick rate is now 10 kHz.  On nRF5x devices, which have a counter that doesn't divide well into decimal frequencies, we're using a raw tick rate of 32768 Hz to exactly match the hardware counter (pleasingly, this GREATLY simplifies the generated code for the ISR and should show significantly improved latency numbers).  Note that software emulation platforms (qemu and nsim) which expose the host clock must continue to use a 100 Hz default, as the emulator timing precision is limited by host OS scheduling quanta.
Note that this is a small patch series (that removes more lines than it adds!), and that almost all the content is just kconfig muckery. There were only a handful of bugs fixed, two were bad test assumptions about tick rate and one was an issue found by inspection in the "next tick round up" code in the nrf driver.
This completes sanitycheck correctly on the emulation platofrms, and runs tests/timer and tests/sched tests successfully on nrf52840_pca10056 and frdm_k64f.  I'm having trouble with my SAM E70 board at the moment but hope to have results from that in a bit.
Anyway, hopefully this can help people looking for increased precision in the near term while we continue to discuss the various rewrites.

@nashif discovered two more tests with assumptions that break with fast ticks, and split out the header change that @erwango pointed out had been incorrectly squashed.

Here is results on the https://github.com/zephyrproject-rtos/zephyr/pull/16653/commits/eb5dd1970ade5125be34dd21907ca364d4f9052e benchmark run on top of this PR:
log-proposal-32k.txt

Here is comparison of the https://github.com/zephyrproject-rtos/zephyr/commit/eb5dd1970ade5125be34dd21907ca364d4f9052e benchmark results ran on the top of #16653 and #16782 (to be more specific: I am comparing https://github.com/zephyrproject-rtos/zephyr/files/3261227/log-proposal-32k.txt with https://github.com/zephyrproject-rtos/zephyr/files/3285409/log-proposal-32k.txt)
k_timer() benchmark:

Measurement
#16653
#16782

Minimum difference between requested and measured timeout
0 us
7 us

Average difference between requested and measured timeout
21.8 us
553.9 us

Maximum difference between requested and measured timeout
59 us
968 us

k_usleep() benchmark:

Measurement
#16653
#16782

Minimum difference between requested and measured timeout
30 us
56 us

Average difference between requested and measured timeout
50.4 us
541.6 us

Maximum difference between requested and measured timeout
88 us
1023 us

@pizi-nordic Are you suggesting that we do #16653 instead of this PR?

@joerchan: We need precise timing in Zephyr. We have 3 different approaches on the table. Now we should select the one most suitable for us.
The #16653 is the best in my opinion, but since I am author of this PR, this statement might be not objective :)

Can we not do the dueling rewrite thing in this PR?  This is just a kconfig thing that changes defaults, with some fixes to tests that you're going to need for any high resolution timer implementation.

I don't have spare Zephyr time to test this; if all tests pass I won't object.  #12542 presents some concerns that may be relevant and describes a test that could reproduce them.
I would like to see the commit description of 86ad9bda5416380a184414cd9473d36530641801 changed:
(Though in practice, the MIN_DELAY value of 32 seems very
conservative.  Simple testing seems to show that the programming
always happens within a single ~30us hardware cycle, so maybe
MIN_DELAY of 2 -- the theoretical minimum to prevent slippage -- would
be a better choice.)

32 is definitely far too conservative, but 2 won't work.  The delay between reading the counter and setting the compare register may usually be less than the 30.6 us interval of the RTC but the counter may still increment during that interval, and you'd set a compare to N+2 when the counter is at N+1 and miss.
If you're feeling lucky you could do 3.  I have doubts that the nRF51 (at 16 MHz with non-constant-time software divide) will always be take than 30.6 us (I remember being burned on #12605), so I use 4 in my RTC-based timer implementations.
Yes, this is only a change to a commit message and has no effect on the implementation, but a future maintainer may see the statement above, believe it, and replace the 32 with 2 resulting in a system that will nondeterministically experience 512 s delays.

(Actually to not take my own advice: I'm convinced both @pizi-nordic's high maxima numbers and @pabigot's point about the MAX_DELAY are in fact the same root cause.  Those maximum deltas seen on current code are, in fact, just about exactly the 977us we would expect to see for a MAX_DELAY of 32.  I'm going to have to add some better optimized overrun detection to keep up with @pizi-nordic's driver, it seems.)

@andyross: I used slightly different approach: If the next announcement is closer than XX us, I am not reprogramming the counter, but wait for announcement instead. I know, that this is not the best solution, but this way the counter interrupts are not being delayed even if the timeout list is constantly updated (in current implementation you can delay the clock announcement indefinitely due to MAX_DELAY).
Please also note, that @nordic-krch currently is adding overrun detection to counter API, and this will solve both your and my problem.

I don't think there's any problem with the existing overrun algorithm in nrf_rtc_timer; just drop MAX_DELAY to 4 and it should be fine.
There are tricks you can play to preserve the compare event when the next alarm's deadline has already been reached at the point it's scheduled, which eliminates MAX_DELAY and causes the interrupt to re-execute immediately, but they're relevant only if you have late-to-set alarms (not expressible in upstream Zephyr) or the ISR execution takes more than one tick.

Getting the rollover detection right was more subtle than expected, and once working it exposed what seems to be a nRF HAL bug (filed in in #16823, but worked around in this PR).  But this should be close to optimal precision as far as "how close to now can we set a timeout".

So. many. tests. to fix.
I think this is set now.  It passes everything in emulation (where in theory nothing has changed) and now runs successfully on nrf52840_pca10056 across the entirely test suite (modulo the 8 failures that are already present in master).  The nrf driver is about as optimized as it's going to get (though there are alignment cycles to be saved in k_sleep and the timeout code still, I think).
And amusingly there were only two bugs fixed in the core kernel: one simple units glitch in mem_pool, and one somewhat more mindbending interaction in the scheduler between the nonatomic swap workaround, the timeslicing configuration API, and fast ticks.

Here are benchmark results on the updated PR.
k_timer() benchmark:

Difference between requested and measured timeout
master
#16398
#16653
#16782

Minimum
-5189 us
0 us
0 us
0 us

Average
435.9 us
23.6 us
21.8 us
24.9 us

Maximum
7043 us
59 us
59 us
60 us

k_usleep() benchmark:

Difference between requested and measured timeout
master
#16398
#16653
#16782

Minimum
10179 us
61 us
30 us
30 us

Average
11818.4 us
112.0 us
50.4 us
55.9 us

Maximum
11856 us
205 us
88 us
85 us

Notes:

Numbers presented for #16653 include overhead caused by counter abstraction as well as counter-generic layer.
In order to compare apples with apples, the CONFIG_SYS_CLOCK_TICKS_PER_SEC has been set to 32768 for #16398.
#16398 is not intended to improve timing of the OS API. Instead it proposes new k_alarm API, which is used to as clock source for kernel.

Rebased, removed the debug cruft @pizi-nordic pointed out.  Clarified comments in the nrf patch.

I found an extra cycle to save, just pushed.  The case where we have an imminent interrupt has three subcases, not two: (1) we missed it and can flag an interrupt immediately, (2) we have to slip by a cycle, but also (3) the newly set timeout is still two cycles in the future and we can leave it in place.   This morning we were slipping (3) also, needlessly.  Worth a few microseconds anyway.
And, while @pizi-nordic has the rig ready, if you're willing to spin here (as I think the new implementation does, right?) you can do even better.  In case (2) we can spin to the next cycle instead of slipping, fixing the one overrun case.  Personally I don't think this is a good idea for the reasons detailed in the comment, but if that's the competition and people agree we want it, it's probably worth measuring:
--- a/drivers/timer/nrf_rtc_timer.c
+++ b/drivers/timer/nrf_rtc_timer.c
@@ -20,6 +20,23 @@
                      / CONFIG_SYS_CLOCK_TICKS_PER_SEC)
 #define MAX_TICKS ((COUNTER_MAX - CYC_PER_TICK) / CYC_PER_TICK)

+/* Experimental feature.  We have the capability of detecting the case
+ * where an interrupt is to be set "at the next cycle", but no ability
+ * in the hardware to deliver that interrupt.  The default choice is
+ * just to slip the event to the next cycle. But... for some apps,
+ * maybe it's preferable to spin instead for accuracy.
+ *
+ * Note that this has severe tradeoffs: one of course is that we're
+ * increasing latency for every other interrupt in the system,
+ * potentially by a lot (e.g. on a 64 MHz nrf52, a RTC cycle is 2000
+ * CPU cycles).  A more subtle one is that it introduces priority
+ * inversion conditions, where it's now possible for a high priority
+ * thread to "sleep" expecting to give the CPU to a lower priority
+ * thread, yet because of the spin here the thread won't actually pend
+ * and the lower priority thread will never run.
+ */
+#define SPIN_FOR_IMMINENT_INTERRUPT 1
+
 static struct k_spinlock lock;

 static u32_t last_count;
@@ -162,7 +179,13 @@ void z_clock_set_timeout(s32_t ticks, bool idle)
                        NVIC_SetPendingIRQ(RTC1_IRQn);
                } else if (counter_sub(cyc, t2) == 1) {
                        /* Too soon, interrupt won't arrive. */
+#ifdef SPIN_FOR_IMMINENT_INTERRUPT
+                       while (counter_sub(cyc, counter()) == 1) {
+                       }
+                       NVIC_SetPendingIRQ(RTC1_IRQn);
+#else
                        set_comparator(cyc + 1);
+#endif
                }
                /* Otherwise it was two cycles out, we're fine */
        }

But what's preventing COUNTER from incrementing between the read of t2 and the set of the comparator on the next line?

Nothing.  But if that were fatal then it would never be possible to do this check robustly at all and the doucmentation would need to say 3 instead of 2 cycles.  And then software engineers would say actually we can't exactly detect 3 cycles, we need 4 to be safe.  And the docs would be updated, and....
You can't robustly lock against realtime.  All timing requirements like this have inherent race conditions.  If testing the counter and comparator on adjacent bus cycles like this isn't enough to meet the requirements of the specification, then nothing can be.  That doesn't mean the spec (or hardware) doesn't have bugs, but what this is doing is legal per paper.
In fact I played with this.  On nRF52, there is an internal pipeline/synchronizer/something delay of something like 1/5th of a RTC cycle.  As long as you get the value in earlier than that, the interrupt will set reliably.   You don't need 2 full cycles, ~1.2 is enough on this one platform.
As for the mechanism used to elevate to an ISR to trap a synchronous announcement, I'm neutral.  We don't need to use the NVIC, we can use a PendSV exception (though that adds a test to the userspace entry), set a flag to test in the interrupt exit code, call it synchronously underneath an existing ISR, trap to an SVC call in thread mode...  But this driver is written to use one comparator from one RTC, so this seemed like the natural mechanism.  It's certainly simple.

A somewhat specious answer might help here: your concern could be addressed by simply setting the comparator first and then checking the counter to see if we "still had" two cycles left.  And maybe I should do that for clarity.
But as mentioned, the state returned by the RTC is dynamic, and the immediate counter read doesn't reflect the "still in flight" comparator write.  So really there's near-zero difference at the hardware level, and in fact the discrimination of the race condition that you really want isn't even possible in theory.  Which is why the docs pad the number in the first place :)

IMO you're making some unsafe assumptions how the peripheral actually behaves (including on nRF51, for which nRF52 observations may be a poor predictor).   But doing the read after the set would appear to address my concern, so that'd satisfy my change request.

New version to address concerns.  Swapped the order of the comparator set and counter read for @pabigot.  Added a failsafe for features like ZLI that can preempt an irq lock for @pizi-nordic.
(Note that we have absolutely zero test coverage for CONFIG_ZERO_LATENCY_IRQS.  This was tested via some whiteboxed delays I stuffed in manually.  I'll file a bug on that.)

Removed the editorializing to address @pfalcon's concerns.
FWIW: I'm not a big fan of "file a bug to fix the test".  Like it or not, the tests define (more so even than the docs) the API we actually need to implement for real users.  In general my philosophy is that they should see minimal churn, even when we know they're of questionable quality.  The comment was there for future readers to understand why the test seems broken, and to guide reimplementations if we ever decide to throw it out.

Removed the editorializing to address @pfalcon's concerns.

Thanks, that commit looks much clearer now.

Like it or not, the tests define (more so even than the docs) the API we actually need to implement for real users. In general my philosophy is that they should see minimal churn

I kinda agree, tests are kinda on meta-level to "normal" code. But in their own level, they're just software component with all its possible shortcomings and maintenance needs. And if we want to maintain it to best practices (fix issues consistently, and not in random-spot manner, etc.), documenting them as tickets and seek for wider exposure to gather critical mass to fix them well, is still the best way, like we or not.
Removing -1, but don't feel knowledgeable enough to give +1 for the entire patchset.

Here are benchmark results on the updated PR.
k_timer() benchmark:

Difference between requested and measured timeout
master
#16398
#16653
#16782

Minimum
-5189 us
0 us
0 us
0 us

Average
435.9 us
23.6 us
21.8 us
22.1 us

Maximum
7043 us
59 us
59 us
60 us

k_usleep() benchmark:

Difference between requested and measured timeout
master
#16398
#16653
#16782

Minimum
10179 us
61 us
30 us
30 us

Average
11818.4 us
112.0 us
50.4 us
56.8 us

Maximum
11856 us
205 us
88 us
90 us

Notes:

Numbers presented for #16653 include overhead caused by counter abstraction as well as counter-generic layer.
In order to compare apples with apples, the CONFIG_SYS_CLOCK_TICKS_PER_SEC has been set to 32768 for #16398.
#16398 is not intended to improve timing of the OS API. Instead it proposes new k_alarm API, which is used to as clock source for kernel.

@andyross I will leave it to you to decide whether to apply @nordic-krch 's suggestion in this PR or get this merge and then him follow-up on a second PR, since strictly speaking the suggestion is not directly related to the PR goals.

I don't know that there's a huge rush.   This is an easy PR to rebase, so I'm happy to wait for debate to finish.

I don't know that there's a huge rush. This is an easy PR to rebase, so I'm happy to wait for debate to finish.

Not huge but we definitely need this for 2.0 (cc @ioannisg)

@carlescufi

@andyross I will leave it to you to decide whether to apply @nordic-krch 's suggestion in this PR or get this merged and then him follow-up on a second PR

I think that can be fixed later on.

@andyross could you rebase so we can merge?

Still some doxygen errors @andyross, not sure why those suddenly appeared now.

Rebased.   Fixed up doc errors due to the endrst/endrststar change that this crossed and mismerged with.


add orchestration settings STO-6877

Added the following to Aqua Security scanner reference:

Container Image settings
Authentication settings

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://659edba6b1061c0ac6d6bda3--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://659eea24f48e2e15c0266e87--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://65a05c147c21153cecbcf10e--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://65a17e242296ab25600c8cdf--harness-developer.netlify.app


[BUG] Forced execution of search shard requests causes memory issues

Describe the bug
There are cases like shard failure where we force the execution of search shard request on an already stuffed queue which causes the search queues to go beyond the queue limits and subsequently causes memory consumption to go unchecked
https://github.com/opensearch-project/OpenSearch/blob/0e9f74e35f1255cb9ec45be3d8960aad195a9f6e/server/src/main/java/org/opensearch/action/search/AbstractSearchAsyncAction.java#L306-L324
Expected behavior
The search thread pool queue should keep within its bound
Screenshots
If applicable, add screenshots to help explain your problem.

Host/Environment (please complete the following information):

OS: [e.g. iOS] Linux
Version [e.g. 22] 4.9

Next steps - look into the use cases where we would force an execution and understand why this is needed. Once we know why a forced-execution is required, we can assess if a solution is possible to the queue-over-limit problem

@Bukhtawar, do you know why forced-execution is required?

More specifically, the code linked above specifically says "we can not allow a stuffed queue to reject execution here". Allowing a queue to grow unbounded is obviously not good, but why are executions not allowed to be rejected in this case currently?

Closing this due to lack of details. @Bukhtawar feel free to reopen if needed.

I think I have given sufficient details on the problem. If the request can't remember something from the top of his head doesn't mean it lack details.
I am not sure you realize the requester doesn't necessarily have permissions to reopen. So would appreciate if you could confirm before closing the issue

Sorry @Bukhtawar didn't mean it lack of detail, I meant the issue has been open for while and there are 2 questions asking for extra clarification and no body response. I am reopened the issue, Please feel free to assign it to yourself, if you are going to work on it.


Fix unicycler tool for unicycler 0.2.0 bioconda package.

Ping @bgruening @nekrut
The pilon trick and the no_long option seem to work for me with the bioconda Unicycler. Maybe you are using a dev version that is different than 0.2.0 for testing?
With this PR this wrapper essentially works semantically with unicycler that is on bioconda and the first test passes, but the second test fails at the minimap step - a machine instruction fault. Here is a log of that second test case - https://gist.github.com/jmchilton/b411b695170c1daea6589f5d76e326cb - I get essentially the same thing whether running it directly or using the tool wrapper via Planemo.
Any clue based on that log if that is a problem with this version of unicycler or with the bioconda packages? My next step would be to install unicycler outside of Conda and see if I can reproduce that problem.

For testing I was using unicycler outside conda. The unicycler has been updated recently, so perhaps we need to update the conda package, no?

Try the conda version 0.3.0b.

@bgruening: I do not see 0.3.0b in bioconda though

@bgruening @nekrut https://bioconda.github.io/recipes.html and https://anaconda.org/bioconda/unicycler are giving different results :/ version 0.3.0b is in the latter...


Undo complicated rake tasks no longer needed

evm:db:seed
Rake::Task['environment'].invoke 87ed9bc9dd7
It was introduced to avoid error when resetting a non-existing database. Rails has since fixed this
evm:db:destroy
Rake::['db:drop'].invoke (and :create) fa37b84c
introduced for SqlServer. No longer using SqlServer (Postgres always worked w/ original)
this is actually rolling back to the original code pre SqlServer
set_region
:setup_region -- set this up like we have in manageiq-schema
The test setup, initialize, and others just set an environment variable. Do the same here.

I'm ok with these cop warnings.
I could change the way we generate random numbers, but was trying to keep stuff as close to the original

@miq-bot cross-repo-test /all

The cross repo test failures are the same unrelated failures, so merging anyway.


New commands for index.html deployment

To solve issue from #25

It still does not work :( :(
It works on my fork: https://github.com/bebatut/training-material/commits/master
I do not understand why. The token?

I may have a clue. The encrypted token (with travis command, see there for more details) was done for my fork and not yours...


panelOLS.predict()  Help wanted

Hi Kevin,
As I've built a fixed-effect regression model for panel data, I want to use the panelOLS.predict() method to predict dependent variable values for different dataframes. I tried passing in 5 columns in a list as the input parameters, but it raised a ValueError.
I have three dataframes with the same column attributes:
df10 represents data of year 2010.

df16 represents data of year 2016.

df is a multi-level index dataframe contains both year 2010 and 2016 data. This df is used to build the fixed_effect model.

Codes:
Creating multi-level index to define the entities and the time periods
df10['YEAR'] = df10['YEAR'].astype(int)
df16['YEAR'] = df16['YEAR'].astype(int)
df = df10.append(df16, ignore_index=True)
df = df.set_index(['ID', 'YEAR'])
df = df.sort_index()

Building the fixed-effect model.
Both dependent and independent variables are dataframe columns.
mod_entity= "PanelOLS.from_formula("INRIX_VOL \
                       ~ CHAMP_VOL \
                       + TNC_VOL\
                       + AVG_DUR_MAJOR_ARTERIALS \
                       + AVG_DUR_MINOR_ARTERIALS \
                       + BASE_INRIX_VOL_PRESIDIO \
                       + EntityEffects",
             data = df)
res_entity = mod_entity.fit(cov_type='clustered', `cluster_entity=True)

Failed Attempt 1:
res_entity.predict(df[['CHAMP_VOL', 'TNC_VOL', 'AVG_DUR_MAJOR_ARTERIALS', 'AVG_DUR_MINOR_ARTERIALS', 'BASE_INRIX_VOL_PRESIDIO']])
Failed Attempt 2:
exog_vars = ['CHAMP_VOL', 'TNC_VOL', 'AVG_DUR_MAJOR_ARTERIALS', 'AVG_DUR_MINOR_ARTERIALS', 'BASE_INRIX_VOL_PRESIDIO']
exog = sm.add_constant(df10[exog_vars])
res_entity.predict(exog)

I read the documentation of panelOLS.predict(), but I still don't understand how to use the parameters. Please advise!

I can't run enough of the example to make is useful.  Here is a very plain example showing predict.
import numpy as np
import pandas as pd
from linearmodels import PanelOLS

year = np.arange(2010, 2020)
obs_id = np.arange(100)
index = pd.MultiIndex.from_product([obs_id, year], names=["id", "year"])
df = pd.DataFrame(index=index, columns=["y", "x"])
df = df.reset_index()

rg = np.random.default_rng(0)
x = rg.standard_normal(df.shape[0])
e = rg.standard_normal(df.shape[0])
y = x + e + df.id
df["y"] = y
df["x"] = x
df = df.set_index(["id", "year"])
mod = PanelOLS(df.y, df[["x"]], entity_effects=True)
res = mod.fit()
print(res.summary)

in_sample_fit = res.predict(df[["x"]])

new_df = pd.DataFrame(rg.standard_normal((300, 1)))
res.predict(new_df)

res_entity.predict(df[['CHAMP_VOL', 'TNC_VOL', 'AVG_DUR_MAJOR_ARTERIALS', 'AVG_DUR_MINOR_ARTERIALS', 'BASE_INRIX_VOL_PRESIDIO']])

looks like it should work. What error do you see with this?

One thing I notice is the df just have a 2-level multiindex or it is reshaped. What does df with this subsampling look like?

res_entity.predict(df[['CHAMP_VOL', 'TNC_VOL', 'AVG_DUR_MAJOR_ARTERIALS', 'AVG_DUR_MINOR_ARTERIALS', 'BASE_INRIX_VOL_PRESIDIO']])

looks like it should work. What error do you see with this?

Hi Kevin, this command does work, and it returns a desired dataframe. However, I want to predict the values for df10 and df16, and also a counterfactual case for df16 with some dummy variables being 0.
We I try
res_entity.predict(df10[['CHAMP_VOL', 'TNC_VOL', 'AVG_DUR_MAJOR_ARTERIALS', 'AVG_DUR_MINOR_ARTERIALS', 'BASE_INRIX_VOL_PRESIDIO']])
or res_entity.predict(df16[['CHAMP_VOL', 'TNC_VOL', 'AVG_DUR_MAJOR_ARTERIALS', 'AVG_DUR_MINOR_ARTERIALS', 'BASE_INRIX_VOL_PRESIDIO']])
A ValueError shows up:

ValueError: matmul: Input operand 1 has a mismatch in its core dimension 0, with gufunc signature (n?,k),(k,m?)->(n?,m?) (size 5 is different from 1)

Can you show the index of the data frame you are using?
On Thu, Dec 10, 2020, 19:23 Fitzroy<EMAIL_ADDRESS>wrote:

res_entity.predict(df[['CHAMP_VOL', 'TNC_VOL', 'AVG_DUR_MAJOR_ARTERIALS', 'AVG_DUR_MINOR_ARTERIALS', 'BASE_INRIX_VOL_PRESIDIO']])
looks like it should work. What error do you see with this?
Hi Kevin, this command does work, and it returns a desired dataframe.
However, I want to predict the values for df10 and df16, and also a
counterfactual case for df16 with some dummy variables being 0.
We I try
res_entity.predict(df10[['CHAMP_VOL', 'TNC_VOL',
'AVG_DUR_MAJOR_ARTERIALS', 'AVG_DUR_MINOR_ARTERIALS',
'BASE_INRIX_VOL_PRESIDIO']])
or res_entity.predict(df16[['CHAMP_VOL', 'TNC_VOL',
'AVG_DUR_MAJOR_ARTERIALS', 'AVG_DUR_MINOR_ARTERIALS',
'BASE_INRIX_VOL_PRESIDIO']])
A ValueError shows up:
ValueError: matmul: Input operand 1 has a mismatch in its core dimension
0, with gufunc signature (n?,k),(k,m?)->(n?,m?) (size 5 is different from 1)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bashtage/linearmodels/issues/292#issuecomment-742740247,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABKTSRM7CMVYOCPJ3AOKARDSUENZTANCNFSM4USTY3IA
.

One thing I notice is the df just have a 2-level multiindex or it is reshaped. What does df with this subsampling look like?
I'm pretty sure this is the problem.

I generated df by appending df16 to df10, and set a 2-level multiindex (id, year) to represent each entity. The subsampling df looks like this:

What are the indices of df10 and df16?  Are they the same as df?
Also, what do you get when you run

from linearmodels.panel.data import PanelData
panel = PanelData(df10[['CHAMP_VOL', 'TNC_VOL', 'AVG_DUR_MAJOR_ARTERIALS', 'AVG_DUR_MINOR_ARTERIALS', 'BASE_INRIX_VOL_PRESIDIO']])
print(panel.shape)
print(panel.dataframe.head())

Kevin, thank you for your further explanations! I figured out the problem, as my df10 and df16 only have one single index instead of   a multi-index. I really appreciate your time!


Killing gx while it is installing deps leaves source directories in bad state

In my case the rewrite was not run so it wasn't working.
There should be lock file or something similar to signal that source directory was processed properly

OpenWrt uses stamp-files, e.g. .stamp.installed, .stamp.built, etc.

working on this here: https://github.com/whyrusleeping/gx/tree/hook-run-files

this has been addressed


Use Scalar::to_u16

https://github.com/rust-lang/rust/pull/67604#issuecomment-569413675 r? @RalfJung

Thanks!
@bors r+

:pushpin: Commit b7e6135d7bdd006d4f80d90e20db127ce3be0c3a has been approved by RalfJung

:hourglass: Testing commit b7e6135d7bdd006d4f80d90e20db127ce3be0c3a with merge 60447d3ef7abae6b5c889144f3b8ff8786169c0e...

:broken_heart: Test failed - status-appveyor

Ah of course, you'll have to update rust-version.

@bors r+

:pushpin: Commit c60ab94d20af93161dd48525d46ef6b010a34f6c has been approved by RalfJung

:hourglass: Testing commit c60ab94d20af93161dd48525d46ef6b010a34f6c with merge 16f5d20ab07368b0eaff51d2c0a9ae805920d92d...

:sunny: Test successful - checks-travis, status-appveyor
Approved by: RalfJung
Pushing 16f5d20ab07368b0eaff51d2c0a9ae805920d92d to master...


[] with a range

The current behavior is misleading, and does not match what Ruby does.
> User[:first_name][3,7].to_sql
SUBSTRING(`users`.`first_name`, 4, 4)
> User[:first_name][3..7].to_sql
SUBSTRING(`users`.`first_name`, 4, 5)

I would be very useful to match the semantics of Ruby, i.e., 0 being the first position, not 1.


remove nonce check from ovmSETNONCE

Fixes

Fixes # https://github.com/ethereum-optimism/roadmap/issues/225

Contributing Agreement

[ ] I have read and understood the Optimism Contributing Guide and Code of Conduct and am following those guidelines in this pull request.

allowing users to set their nonce is a feature; should be allowed to set regardless of current nonce.

@kfichter can you confirm no short-term geth scares on this one?


Add Compound Intrest Calculator

Is your feature request related to a problem? Please describe.
Add Compound Intrest Calculator
Describe the solution you'd like
Add Compound Intrest Calculator
Describe alternatives you've considered
Add Compound Intrest Calculator
Additional context
Add Compound Intrest Calculator

@Sulagna-Dutta-Roy Please assign me the issue

#1899 closing this as exists


test: add a babel example

closes #539
TODO:

[ ] docs linking to require('babel-core/register') + stage-3 preset or babel
[ ] figuring out why async (ctx, next) => {} doesn't work. anyone know why it doesn't work?

it's fixed now... waiting on https://github.com/babel/babel-eslint/issues/199 for linting

for review, guys!

LGTM


[bug] GC compaction bug

Please describe the bug
I noticed this morning that running the test suite with NOKOGIRI_TEST_GC_LEVEL=verify crashes during verification.
Help us reproduce what you're seeing
NOKOGIRI_TEST_GC_LEVEL=verify bundle exec rake test
# or, for debugger:
NOKOGIRI_TEST_GC_LEVEL=verify bundle exec rake test:gdb

I'm trying to bisect when this started happening, will provide more info when I have it.

I can reproduce with Ruby 3.2.3 on both Nokogiri v1.15.0 and v1.16.3 ...
I cannot reproduce with Ruby 3.1.4 ...
So I'm bisecting Ruby. Will include the bisect log here:
git bisect start
# status: waiting for both good and bad commits
# bad: [52bb2ac0a6971d0391efa2275f7a66bff319087c] bump teeny
git bisect bad 52bb2ac0a6971d0391efa2275f7a66bff319087c
# status: waiting for good commit(s), bad commit known
# good: [957bb7cb81995f26c671afce0ee50a5c660e540e] Merge Time-0.2.2
git bisect good 957bb7cb81995f26c671afce0ee50a5c660e540e
# good: [0abf781ab431f44c054523a3ab8f2b1c3768c898] NEWS: Mention about more strict conversions for [Feature #17485]
git bisect good 0abf781ab431f44c054523a3ab8f2b1c3768c898
# bad: [b2d0f788694c680d2abf695358e42d819b11b2ec] Fix private methods reported as protected when called via Symbol#to_proc
git bisect bad b2d0f788694c680d2abf695358e42d819b11b2ec

:thinking: I'm betting this is a bug in GC.verify_compactoin_references when called many times.

Looks like ruby/ruby@a41fbc2c95cc2f7ba9071aca091d8262a8f2cf60 which first appeared in ruby 3.2.0 but was originally committed on 2022-05-04
:thinking: weird that nobody's noticed this, let me do some more due diligence

:thinking: OK, ruby v3.3.0 still shows this leak when using double_heap: but not when using enable_heap: :shrug:
I guess it's not an issue anymore, and this isn't a production feature, so I'm just going to disable that test suite feature for Ruby < 3.3.0.


Write initial spec, and add some examples

This PR writes the initial spec text for module declarations. There are some TODOs left for some edge cases, but everything else is here. It's a diff on top of https://github.com/tc39/ecma262/pull/2905.
I also added an examples folder with some examples: I used them to help myself specifying the correct semantics, and throwing them away would have felt wasteful :P

Closes #19
Closes #15: module declarations' names are identifiers and not URL fragments, but they can be exported&imported
Closes #6
Closes #4: module declarations are private by default, unless explicitly exported

PREVIEW

Some new thoughts after seeing @ljharb's review.

It should be like a function declaration. Hoisted, usable before definition, and no TDZ.
It should not limit to the top level, this limitation does not make sense and break the symmetry between declaration and expression. IMO a Module Declaration should be hoistable block scoped.

{
    import(a) // ok
    module a {}

    // means:
    // const a = module {} // hoisted
    // import(a)
}
a // reference error

But this requires more spec work and also creates a separate link-stage variable namespace.
module a {}
{
    module a { "hit this one!" }
    import(module {
        import a
    })
}

If a module declaration is not at the top level, would you expect it to be statically importable? I suppose not since the binding would not exist in the top level scope. In that case, would they be strictly equivalent to the corresponding module expression assigned to a variable, or would there be any semantic differences?

@mhofman The difference is that module declarations are statically analyzable, so you can statically import them:
module mod { export const x = 2 }
import { x } from mod; // works

const mod = module { export const x = 2 }
import { x } from mod; // error! At linking time (before evaluation), there is no way to know that `mod` is a module

Ok I pushed a commit to support module declarations nested in blocks&functions.
The main complexity comes from dividing the logic to validate/instantite module declarations in two places:

for function f() { module mod {} } it must necessarily be tied to the current lexical environment record, because we don't want all module declarations to be generically attached to the top-level of the module;
for export module mod {} it must be tied to the module itself, because it needs to be available during module loading which happens before creating execution contexts and environments records.

Re-reading the discussions, the only unresolved one is about the strict-function-like hoisting behavior, and there are point in favor of both the alternatives. I'll keep it as it is for now (so, without TDZ), but I'll make sure to mention it in plenary during the presentation.
There are some TODOs left in the spec text, but it should be enough for the "Initial spec text" criterion :)


'Uncaught Exception: RangeError: Invalid string length' after regaining lost network connection

Brief Description: Shortly after regaining network and Internet connectivity after a router restart, Open Bazaar showed the following error dialog.
A JavaScript error occurred in the main process

Uncaught Exception:
RangeError: Invalid string length
    at log (/usr/lib/openbazaar2/resources/app/mainBuilt.js:601:9)
    at LocalServer.<anonymous> (/usr/lib/openbazaar2/resources/app/mainBuilt.js:609:10)
    at triggerEvents (/usr/lib/openbazaar2/resources/app/node_modules/backbone/backbone.js:370:57)
    at triggerApi (/usr/lib/openbazaar2/resources/app/node_modules/backbone/backbone.js:356:19)
    at eventsApi (/usr/lib/openbazaar2/resources/app/node_modules/backbone/backbone.js:155:16)
    at LocalServer.Events.trigger (/usr/lib/openbazaar2/resources/app/node_modules/backbone/backbone.js:346:5)
    at LocalServer._log (/usr/lib/openbazaar2/resources/app/js/utils/localServer.js:266:12)
    at /usr/lib/openbazaar2/resources/app/js/utils/localServer.js:295:23
    at Array.forEach (native)
    at LocalServer.obServerLog (/usr/lib/openbazaar2/resources/app/js/utils/localServer.js:294:26)

Clicking the provider 'OK' button resulting in the dialog closing and immediately reopening. After several reopenings, the error changes to the following.
A JavaScript error occurred in the main process

Uncaught Exception:
RangeError: Invalid string length
    at LocalServer._log (/usr/lib/openbazaar2/resources/app/js/utils/localServer.js:265:25)
    at /usr/lib/openbazaar2/resources/app/js/utils/localServer.js:295:23
    at Array.forEach (native)
    at LocalServer.obServerLog (/usr/lib/openbazaar2/resources/app/js/utils/localServer.js:294:26)
    at Socket.<anonymous> (/usr/lib/openbazaar2/resources/app/js/utils/localServer.js:108:23)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at readableAddChunk (_stream_readable.js:178:18)
    at Socket.Readable.push (_stream_readable.js:136:10)
    at Pipe.onread (net.js:560:20)

This message that repeated continually, and the process needed to be terminated via a killall openbazaar2 command.
Operating System (OS and version): Ubuntu 16.04 LTS
OpenBazaar version (shown on About OpenBazaar page in menu):
Hardware: Desktop PC - ask if full specifications required.

This is the v1 repo. I'm assuming you meant this for v2?

Indeed, that's for pointer. I've re-created this issue here: https://github.com/OpenBazaar/openbazaar-desktop/issues/953


chore(release): 2.33.0

PR Checklist
Please check if your PR fulfills the following requirements:

[ ] The commit message follows Conventional Commits
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Refactoring
[ ] Code style update
[ ] Build or CI related changes
[ ] Documentation content changes

What is the current behavior?
Closes #
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Codecov Report

Merging #1351 (cdb2b4a) into main (b6e0395) will increase coverage by 3.23%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1351      +/-   ##
==========================================
+ Coverage   64.64%   67.87%   +3.23%
==========================================
  Files         766      611     -155
  Lines        8739     7113    -1626
  Branches     1741     1466     -275
==========================================
- Hits         5649     4828     -821
+ Misses       2673     1916     -757
+ Partials      417      369      -48

Flag
Coverage Δ

addon-charts
?

addon-doc
?

addon-editor
?

addon-mobile
?

addon-table
?

addon-tablebars
?

cdk
82.33% <ø> (ø)

core
69.00% <100.00%> (ø)

kit
63.54% <ø> (ø)

summary
67.87% <100.00%> (+3.23%)
:arrow_up:

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

Impacted Files
Coverage Δ

projects/core/constants/version.ts
100.00% <100.00%> (ø)

...jects/addon-charts/components/bar/bar.component.ts

projects/addon-charts/components/bar/bar.module.ts

projects/addon-commerce/test.ts

...ects/addon-commerce/components/card/card.module.ts

projects/addon-charts/constants/line-handlers.ts

.../addon-doc/src/components/code/parse-code-block.ts

...doc/src/components/navigation/navigation.module.ts

...addon-commerce/constants/default-card-validator.ts

...input-card-grouped/input-card-grouped.providers.ts

... and 146 more

Continue to review full report at Codecov.

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


Memo + ForwardRef = false positive?

Eslint complains about myProp being missing in prop validation
when a forwardRef'd component is memoized.
const myComponent = memo(forwardRef( ({ myProp }, ref) => {
....
}

If I add myProp to prop validation.
const myComponent = ({ myProp }, ref) => {
....
}
myComponent.propTypes = { myProp: PropTypes.number.isRequired }
default export memo(forwardRef(myComponent));

Then eslint stops complaining, but now the site wont render:

Warning: forwardRef render functions do not support propTypes or defaultProps. Did you accidentally pass a React component?

Is there someway to use memo and forwardRef that eslint doesn't complain about?

forwardRef callbacks aren’t components and don’t take props or propTypes - if you have a forwardRef, why isn't it using the ref argument?

forwardRef callbacks aren’t components and don’t take props or propTypes - if you have a forwardRef, why isn't it using the ref argument?

Whoops, you're right, forgot the 2nd param "Ref" for this example. Fixed.
I realized that forwardRef'd components don't have propTypes, what I'm saying is Eslint complains if I don't validate props using propTypes when I have a memoized forwardRef. If fowardRef doesn't have propTypes then a memoized forwardRef shouldnt either, yet eslint want's me to add propTypes to it.
Hence why i think this is a false positive.

If it only happens with the combination - ie, with memo and forwardRef, but not just with forwardRef - then it’s definitely a bug.

If it only happens with the combination - ie, with memo and forwardRef, but not just with forwardRef - then it’s definitely a bug.

That's what i thought.

Having multiple wrapper was not supported, it should be fixed in v7.14.3. Thanks for the report 🙂
Also you must add the propTypes to the final component:
const myComponent =  memo(forwardRef(({ myProp }, ref) => {
  // ...
}))
myComponent.propTypes = { myProp: PropTypes.number.isRequired }
default export myComponent;

Thanks for the report
Thanks for the fix!

When I use memo and forwardRef in react project, out of memory!


[e2e]: delegator-lowperms tag main default slsa3

Repo: https://github.com/slsa-framework/example-package/tree/v47.0.278
Run: https://github.com/slsa-framework/example-package/actions/runs/8742595694
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.delegator-lowperms.tag.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.delegator-lowperms.tag.main.default.slsa3.yml
Trigger: push
Branch: v47.0.278
Date: Thu Apr 18 18:06:40 UTC 2024

Repo: https://github.com/slsa-framework/example-package/tree/v47.0.279
Run: https://github.com/slsa-framework/example-package/actions/runs/8757725984
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.delegator-lowperms.tag.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.delegator-lowperms.tag.main.default.slsa3.yml
Trigger: push
Branch: v47.0.279
Date: Fri Apr 19 18:27:56 UTC 2024
Tests are passing now. Closing this issue.


Adding support for integrating analysis modules as micro-services

Thanks for developing this amazing piece of opensource software. It has helped us a lot and we are actively using it as the basis of our UI.
One of the features that can add a lot of flexibility to HistomicsTK is to support addition of analysis modules as micro-services. Apart from python modules, we have a few other modules that are written in C++/Java/Lua and integrating them with HistomicsTK is not straightforward. Having a protocol (or a template) for integrating such modules can be a big advantage, IMHO. Even current analysis modules can also be framed as independent micro-services and this can improve a few things, such as faster build process for the main HistomicsTK plugin.
Please let me know what you think and whether there are any similar plans to enhance HistomicsTK's modularity. Once again, thank you all for your great work.

We have item tasks that do something similar.. I am doing something similar
but it's hard to figure out how to make this completely generic..
On Tue, May 28, 2019, 11:01 AM Kaveh Taghipour<EMAIL_ADDRESS>wrote:

Thanks for developing this amazing piece of opensource software. It has
helped us a lot and we are actively using it as the basis of our UI.
One of the features that can add a lot of flexibility to HistomicsTK is to
support addition of analysis modules as micro-services. Apart from
python modules, we have a few other modules that are written in
C++/Java/Lua and integrating them with HistomicsTK is not straightforward.
Having a protocol (or a template) for integrating such modules can be a big
advantage, IMHO. Even current analysis modules can also be framed as
independent micro-services and this can improve a few things, such as
faster build process for the main HistomicsTK plugin.
Please let me know what you think and whether there are any similar plans
to enhance HistomicsTK's modularity. Once again, thank you all for your
great work.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/DigitalSlideArchive/HistomicsTK/issues/661?email_source=notifications&email_token=AAFODTWKNTOY26PDNQMCVSDPXVQNJA5CNFSM4HQFK4K2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GWI7TBQ,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFODTXMF3NL7WLG62M6IR3PXVQNJANCNFSM4HQFK4KQ
.

There are several approaches to this, and I expect we'll eventually make a way to compose efficient workflows between containers with small services.  Several clear, specific use cases will clarify which approach makes the most sense.


Environment variables not passed to webhooks

 Issue by kbrandwijk
Monday Nov 06, 2017 at 04:22 GMT
Originally opened as https://github.com/graphcool/prisma/issues/1170

Current behavior
When I define an environment variable for a function in my service definition, that variable is available in process.env for inline functions. However, these variables are not passed to webhooks.
Reproduction
functions:
  hello:
    handler:
      webhook:
        url: http://localhost:4000/hello
    type: resolver
    schema: src/hello.graphql
    environment:
      var1: value

Expected behavior?
In the original feature request for environment variable support, I proposed adding them to the context of the function. This would work for webhooks. They should be part of the request object.

Subscribe + ping :)


terraform-ls: 0.23.0 -> 0.25.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/terraform-ls/versions.
meta.description for terraform-ls is: "Terraform Language Server (official)"
meta.homepage for terraform-ls is: "https://github.com/hashicorp/terraform-ls"
meta.changelog for terraform-ls is: "https://github.com/hashicorp/terraform-ls/blob/v0.25.0/CHANGELOG.md"
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
/nix/store/fggqah0m28qv1jkqxkzan37sk3hbf1sr-terraform-ls-0.25.0/bin/terraform-ls passed the binary check.
1 of 1 passed binary check by having a zero exit code.
0 of 1 passed binary check by having the new version present in output.
found 0.25.0 with grep in /nix/store/fggqah0m28qv1jkqxkzan37sk3hbf1sr-terraform-ls-0.25.0
found 0.25.0 in filename of file in /nix/store/fggqah0m28qv1jkqxkzan37sk3hbf1sr-terraform-ls-0.25.0

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

3 package rebuild(s)

3 x86_64-linux rebuild(s)
2 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
docbookrx
terraform-ls
vscode-extensions.hashicorp.terraform

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/fggqah0m28qv1jkqxkzan37sk3hbf1sr-terraform-ls-0.25.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A terraform-ls https://github.com/r-ryantm/nixpkgs/archive/73adab1541ecf0289930fee78d7760973940d106.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/fggqah0m28qv1jkqxkzan37sk3hbf1sr-terraform-ls-0.25.0
ls -la /nix/store/fggqah0m28qv1jkqxkzan37sk3hbf1sr-terraform-ls-0.25.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

terraform-ls
vscode-extensions.hashicorp.terraform

Maintainer pings
cc @martinbaillie @06kellyjac @kalbasit for testing.

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

2 packages built:

terraform-ls
vscode-extensions.hashicorp.terraform


CVSL-224: Add condition 9B

Added condition 9B
Added addAnother button to conditions 9A and 9B, would like to query these with service design as it doesn't seem to make sense to me but I have build as the ticket suggests, I can revert if design changes after discussion

Codecov Report

Merging #104 (e478d72) into main (4870829) will increase coverage by 0.05%.
The diff coverage is 78.94%.

@@            Coverage Diff             @@
##             main     #104      +/-   ##
==========================================
+ Coverage   68.10%   68.16%   +0.05%
==========================================
  Files         123      124       +1
  Lines        2082     2098      +16
  Branches      312      313       +1
==========================================
+ Hits         1418     1430      +12
- Misses        664      668       +4

Impacted Files
Coverage Δ

...itionalConditionInputs/reportToApprovedPremises.ts
71.42% <71.42%> (ø)

server/config/conditions.ts
100.00% <100.00%> (ø)

...additionalConditionInputs/reportToPoliceStation.ts
71.42% <100.00%> (ø)


Reverting few changes

Changelogs

Avoid removing dirpath from config as used for saving checkpoint to wandb
Setting mlp_expansion_ration from 4 back to 2

Checklist:

[ ] Was this PR discussed in an issue? It is recommended to first discuss a new feature into a GitHub issue before opening a PR.
[ ] Add tests to cover the fixed bug(s) or the new introduced feature(s) (if appropriate).
[ ] Update the API documentation is a new function is added, or an existing one is deleted.
[ ] Write concise and explanatory changelogs above.
[ ] If possible, assign one of the following labels to the PR: feature, fix or test (or ask a maintainer to do it for you).

discussion related to that PR

@kerstink-GC , can you check this PR?

Please make sure that the change in default value is well documented


docs: add welcome and installation guide

:tada: This issue has been resolved in version 0.17.0 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Change indentation rules for all keywords at once

Currently, we have
(define-clojure-indent
  (-> 1)
  (->> 1)
  ;; Ideally, we would be able to set the identation rules for *all*
  ;; keywords at the same time. But until we figure out how to do
  ;; that, we just have to deal with every keyword individually.
  (:import 0)
  (:overall-average 0)
  (:require 0)
  (:use 0))

in init.el. This code makes it so that the arguments of a keyword used as a function are indented by two spaces. However, I can't figure out how to add an "every keyword" entry to define-clojure-indent, so instead I've just been adding every keyword I run into that's used as a function, one at a time. The disadvantages of this approach are hopefully obvious.

See https://github.com/clojure-emacs/clojure-mode/issues/420.

Instead, I decided to use the standard indentation rules.


Updated versions of TAEF and C++/WinRT. Fixed DevCheck -SyncDependencies

Updated versions of TAEF and C++/WinRT to latest
Fixed DevCheck -SyncDependencies (wasn't updating files)
Updated DevCheck to treat -SyncDependencies equivalent to -CheckDependencies++ (before was treating -SyncDependencies equivalent to -All -SyncDependencies)
Updated dependencies via DevCheck -SyncDependencies
Removed references to non-existent .natvis files

/azp run

/azp run

/azp run


Consider using AccessLevelHelper.GetEffectiveAccessibility for SA1623/SA1624

Currently the implementation of SA1623/SA1624 relies on a locally-implemented method IsPubliclyVisible. The helper method AccessLevelHelper.GetEffectiveAccessibility implements a more precise and accurate version of this functionality. If possible, the implementation of SA1623/SA1624 should be update to use it.
Marked as a :bug: because the implementation of IsPubliclyVisible currently looks for the private modifier for classes, when it should probably be looking for the internal modifier.

It should be looking for internal when the accessibility of the type (and all of its parents) is public, it should be looking for private when the accessibility of the type (or one of its parents) is internal.

Grabbing this


Problem testing the ent-elk crud example

Hi,
I was following https://entgo.io/blog/2021/07/29/generate-a-fully-working-go-crud-http-api-with-ent
When i try to run the server i get this error
go run -mod=mod main.go
# command-line-arguments
.\main.go:32:26: "elk-example/ent/http".NewPetHandler(c, l).Mount undefined (type *"elk-example/ent/http".PetHandler has no field or method Mount)
.\main.go:32:36: undefined: "elk-example/ent/http".PetRoutes

Here is the github repo https://github.com/Exnoic/ent-elk-example
Please tell me if you need any other information!
Best regards,
Henrik

Hey @Exnoic, thanks for reaching out.
I just had a look: The current master of elk-example is working as it should.
The blog post you are reading is outdated (sadly).
Your repo uses elk in v0.5.2 while the example uses v0.2.1. So there have been some changes made.
To fix your Code:
go get -u entgo.io/ent@master # to fix a bug in 0.9.2 you are using

And  make the following change to your main.go:
``diff

elk.NewPetHandler(c, l).Mount(r, elk.PetRoutes)

elk.NewPetHandler(c, l).MountRoutes(r)

Thank you for the help it now works.
I will close this now.


Add neutralPrimaryAlt color

This PR adds a new color, neutralPrimaryAlt (#3c3c3c), and creates all of the associated mixins and classes.

This is great--thanks Mike! Approved.

Looks good, thanks! 👀 👍

The PR to add this to the documentation site is merged, so I'll go ahead and merge this one.


Update for Diesel 2.0 RC 0

Hello,
Diesel 2.0 RC 0 has been released, and https://github.com/weiznich/diesel_async has been updated accordingly. Would it be possible to update this repo to that version?

Thanks for the heads up, just upgraded to diesel 2.0.0!


Feature/release200x npm devcontainer

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Escape file paths before using them in URL path

Closes https://github.com/netlify/open-api/issues/113

Still WIP because I'm not 100% sure this fixes the issue yet.

Might need http://golang.org/pkg/net/url/#PathEscape instead.  I'll investigate tomorrow.

cc @rybit could you spend 20 minutes today reviewing / attempting to fix up if needed?

This is purely an idea based on an issue I ran into with the JS client, I never got a chance to experiment if this works or not.

We haven't seen this in ages, so closing for now.


"Terraform Landscape: a parsing error occured. Falling back to original Terraform output..."

I initially had the errors regarding the ruby changes (_1 things). Added the RUBYOPT="-W0"  prefix for landscape to suppress them and then got the error Terraform Landscape: a parsing error occured. Falling back to original Terraform output... (with the spelling as shown).
Running with --trace, I get ...
Traceback (most recent call last):
	13: from /usr/local/Cellar/terraform_landscape/0.3.3/libexec/bin/landscape:23:in `<main>'
	12: from /usr/local/Cellar/terraform_landscape/0.3.3/libexec/bin/landscape:23:in `load'
	11: from /usr/local/Cellar/terraform_landscape/0.3.3/libexec/gems/terraform_landscape-0.3.3/bin/landscape:7:in `<top (required)>'
	10: from /usr/local/Cellar/terraform_landscape/0.3.3/libexec/gems/terraform_landscape-0.3.3/lib/terraform_landscape/cli.rb:25:in `run'
	 9: from /usr/local/Cellar/terraform_landscape/0.3.3/libexec/gems/commander-4.4.7/lib/commander/delegates.rb:15:in `run!'
	 8: from /usr/local/Cellar/terraform_landscape/0.3.3/libexec/gems/commander-4.4.7/lib/commander/runner.rb:68:in `run!'
	 7: from /usr/local/Cellar/terraform_landscape/0.3.3/libexec/gems/commander-4.4.7/lib/commander/runner.rb:446:in `run_active_command'
	 6: from /usr/local/Cellar/terraform_landscape/0.3.3/libexec/gems/commander-4.4.7/lib/commander/command.rb:153:in `run'
	 5: from /usr/local/Cellar/terraform_landscape/0.3.3/libexec/gems/commander-4.4.7/lib/commander/command.rb:182:in `call'
	 4: from /usr/local/Cellar/terraform_landscape/0.3.3/libexec/gems/terraform_landscape-0.3.3/lib/terraform_landscape/cli.rb:34:in `block (2 levels) in define_commands'
	 3: from /usr/local/Cellar/terraform_landscape/0.3.3/libexec/gems/terraform_landscape-0.3.3/lib/terraform_landscape/cli.rb:53:in `print'
	 2: from /usr/local/Cellar/terraform_landscape/0.3.3/libexec/gems/terraform_landscape-0.3.3/lib/terraform_landscape/printer.rb:42:in `process_stream'
	 1: from /usr/local/Cellar/terraform_landscape/0.3.3/libexec/gems/terraform_landscape-0.3.3/lib/terraform_landscape/printer.rb:99:in `process_string'
/usr/local/Cellar/terraform_landscape/0.3.3/libexec/gems/terraform_landscape-0.3.3/lib/terraform_landscape/terraform_plan.rb:40:in `from_output': Expected one of [\\s], [ ], '~', '-/+', '-', '+', '<=' at line 3, column 3 (byte 5) after  (TerraformLandscape::TerraformPlan::ParseError)

So, dropping the --trace and taking into account that the report above says line 3, column 3, this line in the untraced plan is :
Terraform Landscape: a parsing error occured. Falling back to original Terraform output...
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

module.bastion_instance.random_string.awscli_output_temp_file_name: Refreshing state... [id=n75VMsI0uBE8aJQa]
module.bastion.data.template_file.userdata: Refreshing state...
module.api_app_cms_asg.module.current_desired_capacity.random_string.awscli_output_temp_file_name: Refreshing state... [id=7geBb0mEmxXcIasA]
...

Also tried with -no-color for the terraform plan ... no difference.
Using tfenv in general, but this project is using ...
Terraform v0.12.26
+ provider.aws v2.66.0
+ provider.cloudflare v2.7.0
+ provider.external v1.2.0
+ provider.local v1.4.0
+ provider.random v2.2.1
+ provider.template v2.1.2

And just read that it looks like Terraform v0.12.* is not supported. Please can you consider adding this restriction to the README. Would save some time.

Thanks for the feedback! Agreed, we should make this clearer.
Added in 46a754d7a8e6c704203ee1cb10624bdff0b90974.


Remove <?php in code examples

Not sure if this works, but in the Symfony documentation we configured the syntax highlighting on a global level, so there is no need to add <?php, which also reduces some noise.
As you told me, there is some mongodb overall documentation stuff thingy, it might be a) not possible or b) it should be kept.
In this case, just close this PR, thanks.

@alcaeus I believe that the new tooling doesn't require the <?php to recognize that it's valid PHP, based on the two PHP blocks on https://www.mongodb.com/docs/manual/indexes/#create-an-index.


Make configs available via env vars

💡 Summary
all configs should be exposed as env vars
Motivation and context
If you want to run weewx in a completely stateless mode, then you should be able to do it
Useful for running the app in, for example, home assistant os and you don't want to persist anything

I like this idea.  Do you have an example of another project that is implement like this for reference?
Also, since you mentioned Home Assistant, I'd like to point out that I just released the first version of my Home Assistant extension for WeeWX:

https://github.com/felddy/weewx-home-assistant


Won't start after server upgrade

I was using nginx-proxy with JrC's docker-letsencrypt-nginx-proxy-companion and compose v1 successfully. After an update/upgrade today on the Ubuntu 14.04.5 LTS server, the nginx proxy container failed to start, restart, or stop.
Error returned:
ERROR: for proxy  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).

I couldn't find much on the issue, except docker-compose issue docker/compose#3834 and docker/compose#1045. I used docker-compose pull for new proxy service images, but no luck. I will try restarting the nginx-proxy containers once all other containers are stopped later today.

It appears the nginx-proxy broke the docker daemon. Restarting with service restart docker resolved the issue


Infinite loop

Is there any method for infinite loop?

Can be achieved by modifying getItemCount method the adapter.


Forge compiles all test contracts when specified to only use one contract.

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (935c113 2022-06-22T00:14:50.974796Z)
What command(s) is the bug in?
forge test --match-contract <CONTRACT_NAME>
Operating System
macOS (Apple Silicon)
Describe the bug
I'm not sure if this is intended behavior or not but would be nice if when using forge test --match-contract <CONTRACT_NAME> the only test contract that is compiled is the contract mentioned and all the necessary imports.
This is how the situation unfolded for me:
I made a change in a function in contract A.sol and I have two test contracts BTest.sol and CTest.sol both with tests using that function, I'm aware that tests in contract CTest.sol will fail to compile so I wanted to only test contract BTest.sol. Because forge compiles all contracts at the same time I'm unable to test BTest.sol without fixing CTest.sol.

Awesome! Feel free to close this issue if you decide that support won't be added. Would be good to add this to the foundry book if anyone has a similar issue.

Related to sparse mode which had some bugs

Hey, bump on this one.
Is there a plan to add this feature? (filter before contract compilation in forge test)

same trouble, is there any better solution rather set two folder?

I see, the contract filter is applied after the project is compiled.
filtering before we compile is not that trivial because of dependencies that may be in conflict with the filter.
But I guess for test contracts it shouldn't be that problematic since those usually only inherit.
this is the first time this came up, so have to think about if support for this scenario is worth adding.
a current workaround would be to use two test folders and two profiles so you can test separately via FOUNDRY_PROFILE=b forge test

yeah, what is b forge test? what's that mean?

Fixed by https://github.com/foundry-rs/foundry/pull/7334 and https://github.com/foundry-rs/foundry/pull/7941


Elasticsearch v2 Upgrade

This upgrades the bundled version of Elasticsearch to v2.4 (up from v1.7). Since Elasticsearch v1.7 will be end-of-life'd next month, we need to get on a newer version. Version 2 should also bring various speed and stability benefits.
We're also upgrading to v2 rather than the latest v5, since v2 has an easier upgrade path. Upgrading from v1 to v2 should just require a full cluster restart, whereas jumping to v5 will require reindexing data. At some point we'll probably need to tackle the v5 upgrade, but that at least becomes easier once everything's on v2 (so any old v1 data can be reindexed in place).
It's also worth noting that based on earlier discussions (eg, https://github.com/NREL/api-umbrella/pull/248#issuecomment-225398939), it seemed like upgrading older databases from v1 to v2 was going to be problematic given that our old data (before API Umbrella v0.12) may have contained field names with dots and Elasticsearch v2 had disabled support for any field names with dots (if you tried to upgrade an existing database with dotted field names, Elasticsearch v2 would refuse to start). Luckily, Elasticsearch 2.4.0 rolls back some of these restrictions so older API Umbrella installations (pre API Umbrella v0.12) where dotted field names may have been present can now be upgraded directly without reindexing all the data.
One final note is that while we're upgrading our default bundled version of Elasticsearch to v2, API Umbrella is still compatible with v1 if you happen to be running an external Elasticsearch cluster (rather than relying on the versions bundled with API Umbrella). If you need to continue connecting to an Elasticsearch v1 cluster, then you'll need to update your /etc/api-umbrella/api-umbrella.yml config to include:
elasticsearch:
 api_version: 1

However, since Elasticsearch v1 is end-of-life'd next month, I'm thinking we probably won't support this beyond the next release, unless there's a need.

Oh, and one more additional note about Elasticsearch v2 indexing performance: On the initial implementation, we were hitting bottlenecks in our test suite with requests not being indexed into Elasticsearch in a timely manner. However, with some tweaking, indexing performance is back to where it should be. But this might be worth highlighting in case anyone's using an external Elasticsearch instance. The short version:

Elasticsearch's index.translog.durability setting should probably be set to async.
We also had do disable API Umbrella's collection of the request_query object inside Elasticsearch (which we've never used, but had been collecting). We had actually already disabled the collection of this recently for other reasons (see https://github.com/NREL/api-umbrella/commit/a432b2205b33fec2a66000104efd62c1da87f136), but with Elasticsearch v2's performance differences, it's probably more important this this remain off and we entirely remove the ability to turn it back on.

The longer explanation is in the commit message here: https://github.com/NREL/api-umbrella/commit/c3afad9faa7b9713d7aff8280c3904a4fe395691


Filter Github messages from repos with app installed

Ref: https://mozilla-hub.atlassian.net/browse/RRM-172
Don't send repository webhook messages to Bigquery where we also have the app installed, since the message will be a duplicate.
This implementation expects a file to be available at a path stored in an environment variable APP_INSTALLATIONS_CONFIG_PATH which contains a full repository name <org>/<repo> on each line.

Closing this PR. Instead of making a code change here, we'll modify tokens in the webhooks to manage the cutover from repository webhooks to app webhooks


removes log-watching for binary proto

Instead, uses wait_for_binary_proto kwarg to start. A couple instances of log-watching left in bootstrap_test.py since those are currently not being run and failures introduced by this change wouldn't be noticed.
Affected tests pass locally on trunk, 2.1, and 2.0, as verified with:
CASSANDRA_VERSION=git:trunk nosetests --verbosity=3 -x cqlsh_tests.py sstable_generation_loading_test.py:TestSSTableGenerationAndLoading.remove_index_file_test ttl_test.py
CASSANDRA_VERSION=git:cassandra-2.1 nosetests --verbosity=3 -x cqlsh_tests.py sstable_generation_loading_test.py:TestSSTableGenerationAndLoading.remove_index_file_test ttl_test.py
CASSANDRA_VERSION=git:cassandra-2.0 nosetests --verbosity=3 -x cqlsh_tests.py sstable_generation_loading_test.py:TestSSTableGenerationAndLoading.remove_index_file_test ttl_test.py

Fantastic, +1


[Feature] Support for ESP32-H2 and ESP32-C6

I would like to use ESP Web Tools for H2 and C6 family boards. I see that these families are not currently supported. Do you plan on adding support for these boards? What would I need to do for them to be supported?

Huh? Never heard of any ESP32-S6 yet.
Do you have a link about those?

Huh? Never heard of any ESP32-S6 yet. Do you have a link about those?

You're right, meant to say ESP32-C6. Fixed that above.

Have you tried it? Upstream esptool-js supports them and so I don't see why it wouldn't work. What error do you get?

Is this 10.0.1 version deployed online on https://web.esphome.io?

Is esp32-H2 supported. I have the issue: issues/537


Name clash in Val on flatMap

I get a compile error on Val.java on the default method flatMap
I am running OpenJDK 17 and eclipse 2022-09

Changing ObservableValue<U> to ObservableValue<? extends U> on line 267 and 477 solves the issue.
I also have to change FlatMapped.java line 12 and 63 to the same.

Hi, I Had the same problem with OpenJDK Zulu 11.0.17 I have made the same modification and it works
Thanks for the tips @buestad


New layout structure documentation

Status
Ready
Description
Documentation to describe the new layout structure

@glicht added a note about the incident/indicator type association

@glicht @anara123 added link to phishing layout instead of json example


N27: Chaos Theory

Part of #818
Guess who spent 2 days trying to optimize the gif

The time was well spent, that's a very small gif 😄


Exclude assessments not relevant to student from profile

@alexsoble @AmirHadjihabib: Students who are English-only are showing ACCESS block. Although empty "-" (as would be expected since only ELLs take ACCESS), we should not show the ACCESS block for students who do not take it --- this is confusing.

Another example:

Assessment records should only show if they exist.

Will be covered as part of student profile redesign #373.


Routable Tabs on "/" index.html

This is a (multiple allowed):

[x] bug

[ ] enhancement

[ ] feature-discussion (RFC)

Framework7 Version: 2.0.7

What you did
I created routable tabs on the index "/" page. It loads all the tabs and switching to the second tab works perfectly. But going back to the first tab does not work.
{
  path: '/',
  url: './index.html',
  tabs: [
    {
      path: '/',
      id: 'home',
      component: home
    },
    {
      path: '/second/',
      id: 'second',
      component: second
    }
  ]
}

Expected Behavior
Clicking on the first tab (while on the second tab) should go to the first tab page and load the content of it.
Actual Behavior
Nothing happens when clicking (while on the second tab) on the first tab.
Edit: Clicking on a tab only works the first time. Changing the tab a second time does not work.

but for me, it must add the dot so it can work!


Unable to open lbia files when using multiple threads to compile procedures

Gilles,

This is probably more a OpenEdge issue, but when using multiple threads to
compile procedures, I often get this error:

[PCTCompileExt] Unable to open or create
C:\Jenkins\smartcomponents-head\_temp\lbia05512, error 13. (354)

Would it be possible to create a subfolder for each thread when using
PCTCompileExt?

The reason for the error is unkown to me... Maybe different threads do compile
the same resource at a given point... (maybe a class that is referenced by two
different procedures?). I don't know, just guessing here...

Lieven

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 21 Aug 2014 at 7:21

Won't be fixed, that's something to be reported to Progress tech support


Remove retry extension from performance test base class

This caused the performance tests to be retried much more, since the
coordinator build itself already retries it twice.

Great! I should have done this but I got some failures yesterday: https://builds.gradle.org/project.html?projectId=Gradle_Check&branch_Gradle_Check=blindpirate%2Fremove-retry-master


On Dispose not triggered if closing a new window when using with MacosApp Widget: [package:desktop_multi_window]

Description
I am currently building an application with this package for macOS. In this app, I am using the plugin package:desktop_multi_window which allows me to use multiple windows. It was configured using your CLI.
In the application I am building I make use of the dispose() method to release different controllers onClose of this widget.
Unfortunately, it seems that if a user closes a window by clicking the red close button is not trigger this lifecycle.

Is it possible that the close method used with this button is ignoring the flutter lifecycle?
Or am I doing something wrong?

Nvm, managed to fix it.
The trick is to also add the dependency "window_manager"
Then extend  the main widget of the new window with WindowListener
class _MainWidgetState extends State<MainWidget> with WindowListener {

     @override
  void onWindowClose() async {
    // Execute the logic here instead of on dispose
    super.onWindowClose();
  }
}


Improvements in visualization

-Added arrow shape to translation gizmo
-Added blending to selection color
-Scale correction in bounding circle in rotation gizmo

Amazing! Thanks a lot Vazquinhos!


Run error

Step:
1: git clone https://github.com/hydro-sdk/hydro_demo.git & cd hydro_demo
2: npm install
3: flutter pub get
4:node node_modules/@hydro-sdk/hydro-sdk/dist/compiler -t 'ota/hello-world.ts' -m 'hello-world' -d 'assets' -p debug -w 'ota'
5: run app
Expection:
Restarted application in 1,205ms.
flutter: I/Hydro 0 native, 646 virtual prototypes
flutter: attempt to call a nil value null with []
Error raised in:
require
 defined in main_chunk:0

anonymous closure
 defined in main_chunk:0

VM stacktrace follows:
@.hydroc/03f1598dde0a8071b05d51c2480ca193e15a89d217a291ca8a10f8d3d786a6ed/hello-world:7
(_Lmain_chunk::d71c39187689639986b4a58c858b8f43c02ed5546a801bc21b68dbaea44632b1::require::file::0)
@.hydroc/03f1598dde0a8071b05d51c2480ca193e15a89d217a291ca8a10f8d3d786a6ed/hello-world:13123
(null)
Dart stacktrace follows:
#0      Thread.attemptCall
package:hydro_sdk/…/thread/thread.dart:42
#1      call
package:hydro_sdk/…/instructions/call.dart:28
#2      Frame.cont
package:hydro_sdk/…/vm/frame.dart:272
#3      call
package:hydro_sdk/…/instructions/call.dart:23
#4      Frame.cont
package:hydro_sdk/…/vm/frame.dart:272
#5      Closure._dispatch
package:hydro_sdk/…/vm/closure.dart:96
#6      Closure.dispatch
package:hydro_sdk/…/vm/closure.dart:83
#7      HydroFunctionImpl.pcall<…>
════════ Exception caught by widgets library ═══════════════════════════════════
The following NoSuchMethodError was thrown building RunFromNetwork(dirty, state: _RunFromNetwork#04cf2):
Closure call with mismatched arguments: function ‘dispatch’
Receiver: Closure: (List) => Null
Tried calling: dispatch(Instance(length:0) of ‘_GrowableList’, parentState: Instance of ‘HydroState’)
Found: dispatch(List) => Null
The relevant error-causing widget was
RunFromNetwork
lib/main.dart:7
When the exception was thrown, this was the stack
#0      Object.noSuchMethod (dart:core-patch/object_patch.dart:51:5)
#1      _RunFromNetwork.build
package:hydro_sdk/runFromNetwork.dart:300
#2      StatefulElement.build
package:flutter/…/widgets/framework.dart:4744
#3      ComponentElement.performRebuild
package:flutter/…/widgets/framework.dart:4627
#4      StatefulElement.performRebuild
package:flutter/…/widgets/framework.dart:4800
…
════════════════════════════════════════════════════════════════════════════════
Application finished.

Hi @lyxia , thanks for trying out Hydro!
I performed a fresh clone of hydro_demo (as of 5d31ca050f265104ab64f565d32d85e64ceacb09) and can't seem to reproduce the error you're seeing. Could you provide some information? What operating system are you on? What kind of device are you running on? What version of Flutter are you using?

Flutter 1.22.1 • channel stable
MacOS 10.15.7
Commit :5d31ca050f265104ab64f565d32d85e64ceacb09

@lyxia have you made any changes to the demo repository before running?

@lyxia what about any changes to the Typescript or Dart code?


AuthenticationError is not exported.

AuthenticationError is not exported.

When ever there is a Error occurs while authenticating passport throws a AuthenticationError to the express error handler i.e. next(AuthenticationError)
Now if we have a global error handler middleware to handle different types of error differently then we can't do this.
If we export AuthenticationError then the users can handle passport errors differently using
if(err instanceof AuthenticationError){
  // do some thing different
}

Expected behavior
AuthenticationError should be exported.
Actual behavior
AuthenticationError is not exported.
Environment

Operating System: *
Node version: 16.x
passport version: 0.5.2

My recommendation is you check error.status rather than instanceof.  For example:
if(err.status === 401){ // authentication error
  // do some thing different
}

Checking instanceofcan be problematic, since individual strategies may error with instances of classes within their package, which would not satisfy an instanceof check.  By checking for status, you can handle all authentication related errors, without depending on internals of middleware or strategies.

At least Can we have error formatter? @jaredhanson
Something similar to serializeUser

Can you describe more what you would expect from a proposed API?  What would it offer that can't be accomplished in middleware?

See suppose we want to change the error message / delete the stack trace or any manipulation we want to do with the error.
Then what we have to do is after every passport middleware we will have to attach a passportErrorHandler i.e
router.get(
    '/github/',
    passport.authenticate('github'),
    passportErrorHandler,
    login
);
router.get(
    '/bitbucket',
    passport.authenticate('bitbucket'),
    passportErrorHandler
    login
);

Even this doesn't ensures that the error is from passport only.
Suppose we have some default middleware just before passport and they throw some error then also it will reach the passportErrorHandler.
Thus if we are able to set a errorFormatter then it can cover this issue entirely.
@jaredhanson I can raise a PR if you agree.

See If I put it in very simple terms how can I exactly know that this particular error is form passport and I need to handle that differently.
Earlier you suggested :
if(err.status === 401){ // authentication error
  // do some thing different
}

This doesn't makes sure that the error is from passport only.
@jaredhanson

It'll be from passport if that was the middleware preceding the error handler.  For example:
router.get(
    '/github/',
    someOtherMiddlewareThatMightDo401Error,
    nonPassportAuthErrorHandler,
    passport.authenticate('github'),
    passportErrorHandler,
    login
);

That will let you trap non-passport errors earlier in the stack, if you need.  Express, is quite flexible in this regard.   That being said, this seems like quite an edge case and I am curious as to what other middleware besides passport would be yielding errors with a 401 status that need to be handled in a special manner.


Doesn't work with silverstripe 3.1.x-dev.

Doesn't work with silverstripe 3.1.x-dev.
composer installed following command:
$> composer require silverstripe/dms dev-master
Problem 1
- Can only install one of: silverstripe/cms[3.1.15, 3.1.x-dev].
- Can only install one of: silverstripe/cms[3.1.x-dev, 3.1.15].
- Can only install one of: silverstripe/cms[3.1.15, 3.1.x-dev].
- Installation request for silverstripe/cms <IP_ADDRESS> -> satisfiable by silverstripe/cms[3.1.15].
- Installation request for silverstripe/cms == 3.1.9999999.9999999-dev -> satisfiable by silverstripe/cms[3.1.x-dev].

@robbyahn what does your composer file look like?

This composer file worked for me:
{
	"name": "silverstripe/installer",
	"description": "The SilverStripe Framework Installer",
	"require": {
		"php": ">=5.3.2",
		"silverstripe/cms": "3.1.x-dev",
		"silverstripe/framework": "3.1.x-dev",
		"silverstripe-themes/simple": "*",
		"silverstripe/dms": "dev-master"
	},
	"require-dev": {
		"phpunit/PHPUnit": "~3.7@stable"
	},
	"config": {
		"process-timeout": 600
	},
	"minimum-stability": "dev"
}

I'm going to close this as I can't replicate, if you still have the problem, feel free to re-open and share your composer.json file


feat: HD derivationPath

#233

Added derivationPath as an optional parameter to constructor of the clients below.

Added derivationPath as an optional parameter to setPhrase

[x] ethereum  -- example of derivationPath m/44'/60'/0'/0/5

[x] bitcoin -- example of derivationPath m/84'/0'/0'/0/1

[x] bitcoincash -- example of derivationPath m/44'/145'/0'/0/1

[x] litecoin -- example of derivationPath m/84'/2'/0'/0/1

[x] thorchain -- example of derivationPath 44'/931'/0'/0/1

[x] binance -- example of derivationPath 2 (this is just the stringified index as the SDK doesn't allow to specify the whole path)

To reviewers:
Let me know where I should add more comments; documentation; and what other tests cases I should look at; (maybe you can give me your own derivation paths and results from other sources than here!)
For thorchain I am not sure if the addresses path /1 are good; please double check.

@davidp94 Could you give some more information about your goal with this PR, pls? Do you need to handle different pathes or just different indexes? Currently xchain-* libs have paths hard-coded as defined in #13 to handle different indexes (but not paths) in the future. Check following note:

BIP 44 compatibility with other wallets. However the client will only use Index 0, but can in future handle multiple indexes at the same time (eg, like using "sub-accounts" in a single wallet).

^ https://github.com/xchainjs/xchainjs-lib/issues/13

@davidp94 Could you give some more information about your goal with this PR, pls? Do you need to handle different paths or just different indexes? Currently xchain-* libs have paths hard-coded as defined in #13 to handle different indexes (but not paths) in the future. Check following note:

BIP 44 compatibility with other wallets. However the client will only use Index 0, but can in future handle multiple indexes at the same time (eg, like using "sub-accounts" in a single wallet).

^ #13

Goal is to handle different paths (which includes indexes supports); not only indexes.
The fact is that Ledger for ethereum used different paths in legacy version so this approach allows us to be more flexible (cf. https://www.reddit.com/r/ledgerwallet/comments/bpoyoa/which_derivation_path_m44600_or_m4460/ )
Actually #13 might be included for this PR too.

Ha yes right; maybe we should still keep getAddress ({address?: string}) ?
if we want to get the balance for another one.
or we would give const secondAddr = getAddress(1)
then getAddress(secondAddr)
On Fri 7 May 2021 at 00:47 Mike Wyszinski @.***> wrote:

@.**** commented on this pull request.
In packages/xchain-bitcoincash/src/client.ts
https://github.com/xchainjs/xchainjs-lib/pull/308#discussion_r627786079:

@@ -289,8 +292,9 @@ class Client implements BitcoinCashClient, XChainClient {
*
* @throws {"Invalid address"} Thrown if the given address is an invalid address.
*/

getBalance = async (address?: string): Promise<Balance[]> => {
return utils.getBalance({ haskoinUrl: this.getHaskoinURL(), address: address || this.getAddress() })

getBalance = async (index = 0): Promise<Balance[]> => {

yeah, keeping it as a string allows the lib to be used to get balances
that are outside of the HD wallet, so it might make it liitle more flexible
to change that back to string.
FWIW JP mentioned using index in the xchain telegram ->
https://t.me/xchainjs/1775 , perhaps he had some different thought about
it
getAddress() -> address for 0, default
getBalance() -> balance for 0, default
transfer(params) -> transfer from 0, default
getTransactionHistory() -> history for 0, default
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/xchainjs/xchainjs-lib/pull/308#discussion_r627786079,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGFVWNKFLW2I3B2UIKY7BODTMME5PANCNFSM43QITBEQ
.


Wrong viewport size on Windows - good on Ubuntu

When I run my game on Windows it looks as if the viewport is about 1.25x the size of the screen (photo attached) while on Ubuntu it is just fine (the same screen, the same laptop).
Here is how I turn on full screen:
DisplayMode mode = LwjglApplicationConfiguration.getDesktopDisplayMode();
config.fullscreen = true;
config.vSyncEnabled = true;
config.resizable = true;
Here is how I create stage:
stage = new Stage(new ExtendViewport(1280, 800), new SpriteBatch());
Here is how I react to resize:
screen.stage.getViewport().update(width, height, true);
screen.stage.getCamera().translate(MaApp.px, MaApp.py, 0);
// although centering doesn't seem to work, I have to manually translate the camera by gutter sizes (px, py are just negative gutter size).
How it looks on Ubuntu: https://www.dropbox.com/s/yns8va8t4rro9x8/20160201_144202.jpg?dl=0
How it looks on Windows: https://www.dropbox.com/s/udk09gvwnh3epbu/2016-02-01 14.41.33.jpg?dl=0
PS. The laptop screen I am testing on is 1920x1080, the resulting screen is about 2400x1300, when started in window mode the window is also larger than I specify as size (by the same margin).

I have found the reason - scaling of elements in Windows was by default set to a larger value to compensate for the screen size. Is there a way to detect such setting and compensate?

PS. Adding:
width = width/(width/Gdx.graphics.getBackBufferWidth());
height = height/(height/Gdx.graphics.getBackBufferHeight());
to resize seems to have solved the problem...

https://github.com/libgdx/libgdx/wiki/More-Info

I am having the same issue.
On Windows 10, there is a feature called UI Scaling described in this article: https://www.thurrott.com/windows/windows-10/4597/windows-10-feature-focus-display-scaling
When this feature is enabled, two very bad things happen for libGDX:

In full screen mode, we only see the upper left portion of the screen according to the degree of the UI scaling.

Nearest Neighbor pixel rendering screws up and shows blurry pixels instead of sharp edges.

I have confirmed this by running my program with UI scaling turned off (it works perfect) then turning UI scaling on. (these bad effects happen)
If you'd like to see my code, here is the commit I tested this effect on: https://github.com/BenMcLean/badroguelike/commit/31afc8fdba22180d9b9d47b5a9fd8aaf2417a516

Discussion on IRC has revealed that this is probably a LWJGL issue. Their wiki (may be out of date) says they only have a high DPI mode implemented for OSX. http://wiki.lwjgl.org/wiki/Using_High_DPI_Mode.html

I'm seeing this issue on my high dpi laptop.
There's a "barebones" example at https://github.com/voxelv/bitcorfab/blob/master/core/src/com/derelictech/bitcorfab/Screen1.java
The following post tries to meet most of the "More Information Needed" criteria.
http://www.badlogicgames.com/forum/viewtopic.php?f=11&t=26659&p=105000#p105000

It appears there is nothing we can do on our end. LWJGL2 is getting old and no longer maintained. Consider using LWJGL3, if possible.


Fix failed tests after upgrading to JDK 17

Cherrypick the fix from master.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

OK, I've already triggered a build for you.


[Feature Suggest] From All-Reduce to Ring-All-Reduce

Dear author,
Challenge and solution
This repository has implemented Tensor Parallel, which facilitates the system by distributing the computation workload evenly to each node, achieving nearly linear acceleration in terms of inference time. However, the communication workload is not distributed. In other words, the transfer time will increase with the number of workers. This situation can be solved by changing all-reduce to ring-all-reduce, which distributes the transfer data workload to every worker.
Let me briefly introduce the concept of all-reduce and ring-all-reduce.
All-reduce

This master-worker architecture has currently been implemented.
It can be changed into ring-workers.
Ring-all-reduce
The ring-all-reduce algorithm is divided into two stages.
stage 1
First, Distribute P workers on a ring and divide each worker's data into P parts. In your case, the hidden_dim is divided into P parts.

Next, look at the k-th worker, who will send the k-th data to the next worker and receive the k-1-st data from the previous worker.

Afterwards, the worker will integrate the received k-1-st data with their own k-1st data, and then send the integrated data to the next worker.

After P-1 cycles, each worker will include a copy of the final integration result.

stage 2
In the second stage, each worker sends the integrated part to the next worker. Workers can update the corresponding part of its data after receiving the data. After P-1 cycles, each worker will include a full copy of the final integration result. This result is the same as All-Reduce.
Assuming that each worker's data is a vector of length hidden_dim = h, the amount of data sent or received by each worker is 2(P-1)*h/P, almost independent of the number of workers P.

When P=1, the transfer data is 0;
When P=2, the transfer data is h;
When P=4, the transfer data is 1.5*h, less than current 3*h;
When P=8, the transfer data is 1.75*h, much less than current 7*h;
When p->∞, the transfer data is 2*h, of course less than ∞h

Summary
Ring AllReduce can avoid the problem of the master needing to handle the amount of O(h*P) data in the master-worker architecture, which can become a network bottleneck when the number of devices increases to 8 or more.
Best Regards.
For your reference: Optimization of Collective Communication Operations in MPICH .pdf

I am working on this. Please spend your time on other priorities. @b4rtaz

https://github.com/pikaxinge/distributed-llama/tree/ring-reduce


Rainbow bracket toggle button

https://github.com/vizhub-core/vzcode/issues/722
Working on this right now, created a button so far to toggle.

No current functionality as of yet, just added the button dropdowns.

I tested it and it seems like it does not work. Here's the screen recording of the test:
rainbowBracketsTest.mp4

Hi, I've been working on this on a separate branch right now. I had the PR up as a draft since it isn't completed yet. Will be finishing it up soon.

Should be ready.
It might have a quick delay before the render update on the rainbow brackets happen after switching toggle.


Write a GO program to find power of a number by recursion

Description
Write a GO program to find power of a number by recursion
Power of a number is calculated by multiplying the number by itself for the given number of times. For example, 2^3 = 2 * 2 * 2 = 8.
Power of a number can be calculated by recursion. The formula is:
x^n = x * x^{n-1}

Input  : 2 3
Output : 8

How to contribute

Save the solution in find_power_of_a_number_by_recursion.go file
Add find_power_of_a_number_by_recursion.go file in find-power-of-a-number-by-recursion folder

!assign

!assign


Create fb hack

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at<EMAIL_ADDRESS>Thanks!

@JOJO31X updated the pull request.


[feature] YAMLDataLoader and YAMLDataSaver as default data adapters

Adding the option to do I/O using YAML files, similar as what we have with json.
Changes
Adding YAML as default data adapter
How I tested this
Same test module as others default data adapters, 3 unit tests:

Isolated load
Isolated save
Using both loader and saver.

Notes
Followed pattern of json, but expanded the options of applicable_types
Checklist

[x] PR has an informative and human-readable title (this will be pulled into the release notes)
[x] Changes are limited to a single goal (no scope creep)
[x] Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
[x] Any change in functionality is tested
[x] New functions are documented (with a description, list of inputs, and expected output)
[x] Placeholder code is flagged / future TODOs are captured in comments
[ ] Project documentation has been updated if adding/changing functionality.

thanks for the review @skrawcz and totally agree! Nice to learn how the plugins works too :)

Fixed back the PrimitiveType issue. @skrawcz  lemme know if something still missing

Thanks @wmoreiraa !


Add Error Handler

Check out gorilla/mux's error handling
I added one for not found via: r.NotFoundHandler = http.HandlerFunc(notFound)
Look through docs to find others

looks like there is method not allowed
server errors will be fairly generic... like "oops! we did it again.."


Ingress secret name as value

Hi,
Regarding TLS, it would be great to add secret name for at least Element and Synapse ingresses in the values file.
Keeping matrix-tls / element-tls as default, so we could use existing certificate instead of let's encrypt.
Anyway, great job !

Great ! Thank you very much.


Issue with multiple/threaded replies from Twitter ->Mastodon

Hi again :)
The Android Twitter app seems to have been recently updated to allow you to post multiple messages in reply to someone else (i.e. when you click the "reply" button, there's now a "+" button in the reply activity to let you add more Tweets to the reply). This is great news for overly-verbose people like myself, but it seems to have tripped up Moa :(
For example, this three-Tweet reply of mine resulted in the second and third Tweets being posted to Mastodon as completely normal messages; the first reply was correctly ignored. (I've since deleted those erroneous messages from Masto to save confusion of people reading only the latter two-thirds of a reply!)
I appreciate that posting "replies to yourself" to Masto is the correct behaviour, which would be why this happened, but hopefully it won't be too big of a deal to check if the first message in a string of self-replies is a reply to someone else (both from a technical perspective, and from hoping that doing so won't adversely affect something else)?
(I used to operate a PHP-IRC bot for which I wrote a module to syndicate Tweets into an IRC channel, and I used to have to deal with problems like this all the time. I'm rather glad I don't have to anymore!)
Thanks again for your work on this, and hosting it publicly! :)

The problem is that Moa can't track replies to messages it doesn't know about.  There's no way for Moa to know that these replies should be changed to be self-replies. Unfortunately I can't think of a solution for this problem.


Create Autonomous for Blue Right

Create an autonomous mode program for when we are on the blue alliance and start on the right

Initial auto code committed


Conflict with Dictionary Plugin

The Text Generator plugin seems to conflict with the obsidian-dictionary plugin. When text-gen is enabled, the scroll bar in obsidian-dictionary disappears.
https://github.com/nhaouari/obsidian-textgenerator-plugin/assets/68677082/1a535e31-3101-4081-bc5e-72e246dbfd92
This might be a problem with other plugins as well.

Similar issue, don't have dictionary plugin installed...

can you test it in version 0.5.27-beta


Outdated information

The information on this page is not accurate now that the 365 defender pages have been moved around.

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

ID: 1541fb66-1414-579d-344c-fc1e25ba4ea0
Version Independent ID: 1541fb66-1414-579d-344c-fc1e25ba4ea0
Content: How-to deploy and configure the report message add-in
Content Source: microsoft-365/security/office-365-security/step-by-step-guides/deploy-and-configure-the-report-message-add-in.md
Service: microsoft-365-security
Sub-service: mdo
GitHub Login: @MSFTBen
Microsoft Alias: tracyp

@MSFTBen for visibility.

@ColmanPerkins-Stephen Thank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/13142
Once the author approves, the changes will be live.
Thanks
Sri


VAO's leak in adaptive code

Instructions.bindVertexArray catpures the input vao in the its closure.
The closure is referenced by mapMod (mapping over current context)
CurrentContext mod has the closure in the output
The prepared render object itself gets disposed
all is fine but via 3,2,1 all input buffers remain in main memory

https://github.com/vrvis/aardvark/commit/2c9b3bfe06d32ff65027a335b79b9ec92cf346e2 demonstrates the problem as abstract test case.

Solved via weak outputs in base and explicit removal in IAdaptiveCode.Dispose


update Dockerfile for API 25

awesome, thank you very much!
just one more thing: could you please add this to the CHANGELOG too?

Sorry, I'll do that ;)
Thanks again!

Thank you!  :heart:  bitrise!

Thanks, we ❤ you too! ;)