nRF52: refactor system timer handling; support tickless and nontickless using RTC/systick

Summary
This commit extends support for system timer based on ARM SysTick
or RTC timer, both for tickless and non-tickless modes. To do so,
the "arch timer" facility is used. This also restores support for WFI/WFE
which is only used when RTC is used as system timer.
Impact
System timer
Testing
Tested both options (systick and RTC) both in tickless and non-tickless modes.

This is failing the check due to #1637

This is failing the check due to #1637

Can you try applying this patch to work around the rename issue for now?
diff --git a/tools/checkpatch.sh b/tools/checkpatch.sh
index 0171d37d19..752c44eb69 100755
--- a/tools/checkpatch.sh
+++ b/tools/checkpatch.sh
@@ -91,7 +91,7 @@ check_patch() {
 }

 check_commit() {
-  diffs=`git show $1`
+  diffs=`git show --no-renames $1`
   check_ranges <<< "$diffs"
 }

I don't have that, i have this:

check_patch() {
  if ! git apply --check $1; then
    fail=1
  else
    git apply $1
    diffs=`cat $1`
    check_ranges <<< "$diffs"
    git apply -R $1
  fi
}check_patch() {
  if ! git apply --check $1; then
    fail=1
  else
    git apply $1
    diffs=`cat $1`
    check_ranges <<< "$diffs"
    git apply -R $1
  fi
}

ah, sorry, was in another line

I don't have that, i have this:
check_patch()

CI calls checkpatch.sh -g $commits
option g uses check_commit
I think my fix will work

I don't have that, i have this:
check_patch()

CI calls checkpatch.sh -g $commits
option g uses check_commit
I think my fix will work

Mmm didn't work.

I don't have that, i have this:
check_patch()

CI calls checkpatch.sh -g $commits
option g uses check_commit
I think my fix will work

Mmm didn't work.

Just tested against your PR and you are right one more change.  We should not be using show, instead we should be using diff  otherwise we get a list of the intermediate commit changes which may include files dropped.
With that we do not even need the --no-renames

This works:

git diff master..HEAD | ./tools/checkpatch.sh -

@v01d check issue should be resolved by this https://github.com/apache/incubator-nuttx/pull/1706

@btashton is ccache being used for builds? I looked at the scripts and I understand it should be working when "-c" is passed but it doesn't seem to be the case for the build workflow. Unless I'm missing something.

It will not work with the Docker container. I suppose I could enable that, but the MacOS build is by far the slowest build (by at least 2x).

Isn't it possible to cache it? I used to do that with GitLab

@btashton is ccache being used for builds? I looked at the scripts and I understand it should be working when "-c" is passed but it doesn't seem to be the case for the build workflow. Unless I'm missing something.

It will not work with the Docker container. I suppose I could enable that, but the MacOS build is by far the slowest build (by at least 2x).

Not sure how GitHub does it but you can bind mount a host directory when running docker. I mapped $HOME/.ccache when did similar thing on GitLab (private installation though). If you can do that and then cache the directory between builds, it should be usable even from within container.

@btashton is ccache being used for builds? I looked at the scripts and I understand it should be working when "-c" is passed but it doesn't seem to be the case for the build workflow. Unless I'm missing something.

It will not work with the Docker container. I suppose I could enable that, but the MacOS build is by far the slowest build (by at least 2x).

Isn't it possible to cache it? I used to do that with GitLab

It is fully doable, I am just saying that flag will not work in the docker container because it is not configured that way.  The MacOS build is more of an issue in terms of time.  I am working on that now over in the testing repo.
I am a little hesitant to preserve the cache across builds though.

@btashton is ccache being used for builds? I looked at the scripts and I understand it should be working when "-c" is passed but it doesn't seem to be the case for the build workflow. Unless I'm missing something.

It will not work with the Docker container. I suppose I could enable that, but the MacOS build is by far the slowest build (by at least 2x).

Isn't it possible to cache it? I used to do that with GitLab

It is fully doable, I am just saying that flag will not work in the docker container because it is not configured that way. The MacOS build is more of an issue in terms of time. I am working on that now over in the testing repo.

Ok, the complexity of the build system eludes me so I'm mostly thinking out loud.

I am a little hesitant to preserve the cache across builds though.

I never had a problem with it. ccache uses a hash of the preprocessed file and returns the .o (also considering flags).
at most I think it would get a false cache miss than a false cache hit.

I'm just wondering if we shouldn't change the terminology related to RTC in the NRF52 family.
Nordic uses the term RTC to refer to a Real Time Counter, but industry standard refers to the RTC as Real-Time Clock.
They are different peripherals with different uses.
Names like nrf52_rtc.c or nrf52_rtc_lowerhalf.c are a bit confusing if we have some experience with other architectures.
We probably should change all RTC-related names to RTCTIM or something similar, so that it is immediately known that we're referring to a timer instance not a clock instance.
Of course, this is a topic for a separate PR, but I'm curious what do you thing about it?

Of course, this is a topic for a separate PR, but I'm curious what do you think about it?

It should match the datasheet/reference manual for the SoC to the letter.
At the top of the nrf52_rtc.c source file place at least one line that says
The is the driver for the Nordic xxx Real Time Counter
If we do it this way, it is fully documented and self describing.

I'm just wondering if we shouldn't change the terminology related to RTC in the NRF52 family.

Lots of MCUs are in the situation and all use the RTC naming.  An exception is arch/arm/src/stm32.  The older STM32 F1's used a real time counter and the others in the family use a date time RTC.  So a distinction was necessary there:  stm32_rtcounter.c vs. stm32_rtcc.c

Yes, let's stick to vendor naming.

I'm just wondering if we shouldn't change the terminology related to RTC in the NRF52 family.
Nordic uses the term RTC to refer to a Real Time Counter, but industry standard refers to the RTC as Real-Time Clock.
They are different peripherals with different uses.
Names like nrf52_rtc.c or nrf52_rtc_lowerhalf.c are a bit confusing if we have some experience with other architectures.
We probably should change all RTC-related names to RTCTIM or something similar, so that it is immediately known that we're referring to a timer instance not a clock instance.
Of course, this is a topic for a separate PR, but I'm curious what do you think about it?

The keypoint isn't whether the hardware save the time as a counter or as y/m/d/h/m/s/us, because it is very easy to convert between these two representation(mktime and gmtime_r). The major difference is whether the timer is in an always on domain, and never stop counting. If it's true, it's better to implement rtc_lowerhalf_s, otherwise it should implement as oneshot_lowerhalf_s or timer_lowerhalf_s.

The keypoint isn't whether the hardware save the time as a counter or as y/m/d/h/m/s/us, because it is very easy to convert between these two representation(mktime and gmtime_r). The major difference is whether the timer is in an always on domain, and never stop counting. If it's true, it's better to implement as rtc_lowerhalf_s, otherwise it should implement as oneshot_lowerhalf_s or timer_lowerhalf_s.

See my response to your other comment. I don't think it is appropriate to consider this timer anything different than a nRF52 TIMER or STM32 TIM, with the difference that indeed it continues to work during WFI/WFE. Exposing the timer as oneshot/rtc means that you have to give the illusion of a timer which does not wrap around. the timer_lowerhalf_s reflects better the functionality of the timer. The only complication is with the auto-clear but that can be addressed with PPI as I mentioned. Note that nrf52_tim_lowerhalf.c is implemented in the same way but in this case the TIMER peripheral indeed supports the auto-clear by hardware on its own.

Why we provide two driver interfaces(oneshot_lowerhalf_s v.s. timer_lowerhalf_s)? The only reason is that whether the hardware will auto clear the timing count, so it's a very important difference. If you read the arch_timer.c carefully, you will find that the up_timer_gettime will drift a little bit in every interrupt and is unavoidable. Actually, I don't suggest to combine arch_timer with tickless mode since the drift is so large to make this combination useless.

The difference between oneshot/timer was not apparent to me. At least it is not documented anywhere. It would appear to be two different possible interfaces with no apparent change in semantics. Actually, the biggest difference is the fact that oneshot receives a timespec value instead of a microsecond value.
Moreover, I realized this timespec is relative (I thought it was absolute), so indeed it is a matter of representation. The difference you mention about auto-clear is documented anywhere?
Anyway, it is confusing to me that arch_timer/arch_alarm both use a timer based on a relative timeout, where arch_alarm gives the illusion to NuttX that it is working in absolute values (by using the alarm time to get a relative timeout). The point of arch_alarm is that it is supposed to be used with a timer which allows to set an absolute time in the future, see:

config SCHED_TICKLESS_ALARM
        bool "Tickless alarm"
        default n
        ---help---
                The tickless option can be supported either via a simple interval
                timer (plus elapsed time) or via an alarm.  The interval timer allows
                programming events to occur after an interval.  With the alarm,
                you can set a time in the future and get an event when that alarm
                goes off.  This option selects the use of an alarm.

                The advantage of an alarm is that it avoids some small timing
                errors; the advantage of the use of the interval timer is that
                the hardware requirement may be less

I always understood from this that it should be based on an RTC peripheral which allows you to set an absolute RTC alarm.
So, it seems to me that arch_timer should actually be implemented as arch_alarm is implemented (no drift in up_timer_gettime()) instead of having one combination which does not make sense for tickless (arch_timer).

Also, if you look at stm32_oneshot.c, you will find that when the timer expires it is stopped. So I don't really understand how you can use the counter to provide up_timer_gettime after it the "alarm" expires on arch_alarm.c. I feel there's something wrong here.

Also, if you look at stm32_oneshot.c, you will find that when the timer expires it is stopped. So I don't really understand how you can use the counter to provide up_timer_gettime after it the "alarm" expires on arch_alarm.c. I feel there's something wrong here.

Of course, it if reset and fired again it wouldn't be a one shot.  The one shot timer was created to support tickless mode operation for the two timer case:  https://cwiki.apache.org/confluence/display/NUTTX/Tickless+OS
The one shot is also used internally to support CPU load measurements with entropy: https://cwiki.apache.org/confluence/display/NUTTX/Oneshot+Timers+and+CPU+Load+Measurement

Of course, it if reset and fired again it wouldn't be a one shot. The one shot timer was created to support tickless mode operation for the two timer case: https://cwiki.apache.org/confluence/display/NUTTX/Tickless+OS

That's exactly my thought. So, arch_alarm.c using oneshot does not really sound a good combination, is it?
I mean, there will be drift while the timer is stopped between the ISR and when the next up_alarm_start is called.

Also, looking at the first wiki entry you linked:

Since timers are a limited resource, the use of two timers could be an issue on some systems. The job could be done with a single timer if, for example, the single timer were kept in a free-running at all times. Some timer/counters have the capability to generate a compare interrupt when the timer matches a comparison value but also to continue counting without stopping. If your hardware supports such counters, one might used the CONFIG_SCHED_TICKLESS_ALARM option and be able to simply set the comparison count at the value of the free running timer PLUS the desired delay. Then you could have both with a single timer: An alarm and a free-running counter with the same timer!

arch_alarm.c should indeed use a free running timer, not one that requires restarting. Otherwise you are exactly in the case of non-alarm tickless mode.

Of course, it if reset and fired again it wouldn't be a one shot. The one shot timer was created to support tickless mode operation for the two timer case: https://cwiki.apache.org/confluence/display/NUTTX/Tickless+OS

That's exactly my thought. So, arch_alarm.c using oneshot does not really sound a good combination, is it?
I mean, there will be drift while the timer is stopped between the ISR and when the next up_alarm_start is called.

It would would not be the tidiest solution since it is just a wrapper around the timer interface and since the timer interface can be configured to support a periodic timer.
If you are clever in how you set up the next oneshot delay, then you could avoid drift.

Is the oneshot supposed to keep counting after it fires? I understand that oneshot fires once but at least stm32_oneshot.c stops counting. So implementing up_timer_gettime() as arch_alarm.c does:

int up_timer_gettime(FAR struct timespec *ts)
{
  int ret = -EAGAIN;

  if (g_oneshot_lower != NULL)
    {
      ret = ONESHOT_CURRENT(g_oneshot_lower, ts);
    }

  return ret;
}

would only work if the timer continues to run AND it handles wrap-around by adding one period on overflow and returns this monotonic value on ONESHOT_CURRENT(). Neither of those two conditions are met in stm32_oneshot.c. So is stm32_oneshot.c wrong or is that not how oneshot should work?

Is the oneshot supposed to keep counting after it fires? I understand that oneshot fires once but at least stm32_oneshot.c stops counting. So implementing up_timer_gettime() as arch_alarm.c does:
int up_timer_gettime(FAR struct timespec *ts)
{
int ret = -EAGAIN;
if (g_oneshot_lower != NULL)
{
ret = ONESHOT_CURRENT(g_oneshot_lower, ts);
}
return ret;
}
would only work if the timer continues to run AND it handles wrap-around by adding one period on overflow and returns this monotonic value on ONESHOT_CURRENT(). Neither of those two conditions are met in stm32_oneshot.c. So is stm32_oneshot.c wrong or is that not how oneshot should work?

Yes, resetting and stopping the timer is the correct behavior for a oneshot timer.  I expect that that all of the implementations do that.
My suspicion from what you say is that the those arch drivers are not compatible with the existing MCU architectures.  They are not used by any of the existing architectures in the repository; they are used only by Xiaomi hardware.  They have probably implemented an incompatible version of the one shot driver for their purposes and those arch drivers may not be usable by other architectures.
I am completely unfamiliar with those drivers.  I have never used them or even looked at them.  You would have to discuss this with Xiaomi to see if they are using some non-standard oneshot driver.  I don't know what we should do if they are.  Certainly we do not want to corrupt the semantics of the oneshot driver.

Is the oneshot supposed to keep counting after it fires? I understand that oneshot fires once but at least stm32_oneshot.c stops counting. So implementing up_timer_gettime() as arch_alarm.c does:
int up_timer_gettime(FAR struct timespec *ts)
{
int ret = -EAGAIN;
if (g_oneshot_lower != NULL)
{
ret = ONESHOT_CURRENT(g_oneshot_lower, ts);
}
return ret;
}
would only work if the timer continues to run AND it handles wrap-around by adding one period on overflow and returns this monotonic value on ONESHOT_CURRENT(). Neither of those two conditions are met in stm32_oneshot.c. So is stm32_oneshot.c wrong or is that not how oneshot should work?

Yes, resetting and stopping the timer is the correct behavior for a oneshot timer. I expect that that all of the implementations do that.

But the driver document never mention wether the counting should stop or not:
/****************************************************************************
 * Name: ONESHOT_CANCEL
 *
 * Description:
 *   Cancel the oneshot timer and return the time remaining on the timer.
 *
 *   NOTE: This function may execute at a high rate with no timer running (as
 *   when pre-emption is enabled and disabled).
 *
 * Input Parameters:
 *   lower   Caller allocated instance of the oneshot state structure.  This
 *           structure must have been previously initialized via a call to
 *           oneshot_initialize();
 *   ts      The location in which to return the time remaining on the
 *           oneshot timer.  A time of zero is returned if the timer is
 *           not running.
 *
 * Returned Value:
 *   Zero (OK) is returned on success.  A call to up_timer_cancel() when
 *   the timer is not active should also return success; a negated errno
 *   value is returned on any failure.
 *
 ****************************************************************************/

#define ONESHOT_CANCEL(l,t) ((l)->ops->cancel(l,t))

So the implementer is free to just disable the interrupt but keep the counting.

My suspicion from what you say is that the those arch drivers are not compatible with the existing MCU architectures. They are not used by any of the existing architectures in the repository; they are used only by Xiaomi hardware. They have probably implemented an incompatible version of the one shot driver for their purposes and those arch drivers may not be usable by other architectures.
I am completely unfamiliar with those drivers. I have never used them or even looked at them. You would have to discuss this with Xiaomi to see if they are using some non-standard oneshot driver. I don't know what we should do if they are. Certainly we do not want to corrupt the semantics of the oneshot driver.

But the driver document never mention wether the counting should stop or not:
So the implementer is free to just disable the interrupt but keep the counting.

OK, so this confirms my suspicion: since this is not documented we have different interpretations on how oneshot works and this leads to problems when attempting to use arch_alarm as a general solution. I think that we should document what Greg mentioned about how oneshot should work. I've only seen stm32 implementation so far, not sure if other implementations of oneshot follow this or not. Anyone familiar with other architectures?

So the implementer is free to just disable the interrupt but keep the counting. This behaviour is very important to implement the tickless mode on top of oneshot_lowerhalf_s without any drift.

My suggestion is to not base tickless mode on this expectation of oneshot continuing to count after expiration. But arch_alarm should indeed be implemented over an interface which guarantees the timer continues to run without any manual restart. timer_lowerhalf_s could be used for this, but current implementations do not guarantee this property either (stm32/smt32l4 will autoreload the timer, but for "advanced timers" this would be possible) and overflow should be handled by exposing the overflow ISR. We really need to document the semantics of each interface so that we agree on how things should work.

So the implementer is free to just disable the interrupt but keep the counting. This behaviour is very important to implement the tickless mode on top of oneshot_lowerhalf_s without any drift.

My suggestion is to not base tickless mode on this expectation of oneshot continuing to count after expiration. But arch_alarm should indeed be implemented over an interface which guarantees the timer continues to run without any manual restart. timer_lowerhalf_s could be used for this, but current implementations do not guarantee this property either (stm32/smt32l4 will autoreload the timer, but for "advanced timers" this would be possible) and overflow should be handled by exposing the overflow ISR. We really need to document the semantics of each interface so that we agree on how things should work.

timer_lowerhalf_s is modeled for the auto reload timer, oneshot_lowerhalf_s is modeled for the no auto reload timer. That's why I select oneshot_lowerhalf_s and assume the timer keep counting.

So the implementer is free to just disable the interrupt but keep the counting. This behaviour is very important to implement the tickless mode on top of oneshot_lowerhalf_s without any drift.

My suggestion is to not base tickless mode on this expectation of oneshot continuing to count after expiration. But arch_alarm should indeed be implemented over an interface which guarantees the timer continues to run without any manual restart. timer_lowerhalf_s could be used for this, but current implementations do not guarantee this property either (stm32/smt32l4 will autoreload the timer, but for "advanced timers" this would be possible) and overflow should be handled by exposing the overflow ISR. We really need to document the semantics of each interface so that we agree on how things should work.

timer_lowerhalf_s is modeled for the auto reload timer, oneshot_lowerhalf_s is modeled for the no auto reload timer. That's why I select oneshot_lowerhalf_s and assume the timer keep counting.

But this isn't documented. And at this point making oneshot conform to this expectation means to rewrite many implementations and break a lot of stuff. On the contrary, adapting arch_alarm to a different interface that gives satisfies this expectation is much easier and will not break anything currently on NuttX mainline.
The question is which interface to use to provide this semantic. timer_lowerhalf_s could be extended or a different one could be added. Either will require some work.

After looking more closely into timer_lowerhalf_s it does not appear to be a good interface to provide the periodic + freerun interface either: it currently returns the "status" (which indicates the time remaining to the timeout) but not a free running counter. It would also be necessary to handle overflow. But the problem is actually that it would require distinguishing between a timer that is capable of freerunning from one that it is not (such as an STM32 basic timer, which is the current implementation).
I think this semantic should be provided by a different interface (maybe monotonic_timer_lowerhalf_s?). This would then be a better replacement for oneshot on arch_alarm.c.
An alternative path is to follow one of Xiang suggestions and expose the timer as an rtc_lowerhalf_s (using CONFIG_RTC_HIRES in this case). This is not ideal either because the timer continues to run on low power mode but not on system OFF (there's not battery backup domain on nRF52). Considering this lengthy discussion I think I will take this approach for nRF52. We can revisit this in the future if a new interface is added as previously mentioned.

So the implementer is free to just disable the interrupt but keep the counting. This behaviour is very important to implement the tickless mode on top of oneshot_lowerhalf_s without any drift.

No.  The behavior of a one shot is clear from its definition.  It requires no further definition.  A one shot generates a single pulse.  If it generates multiple pulses it is not a on shot.

If needed, we should correct the version of arch_alarm.c and arch_timer.c in the repository so that it works with all repositories.  Currently this logic is only usable by Xiaomi code.  If it is not change, then it should be removed from the repository altogether.  We do not carry vendor specific implementations that are not usable to the entire community.

I don't think the current logic is wrong per se, it is simply not the best implementation. If we added another timer interface for freerun + interval then arch_alarm can be improved and would then be a good foundation for supporting tickless and non-tickless modes easily. Let's keep it as is for now, I can try to come up with something later on. I will open an issue for this and update this PR to use rtc_lowerhalf_s.

So the implementer is free to just disable the interrupt but keep the counting. This behaviour is very important to implement the tickless mode on top of oneshot_lowerhalf_s without any drift.

No. The behavior of a one shot is clear from its definition. It requires no further definition. A one shot generates a single pulse. If it generates multiple pulses it is not a on shot.

@patacongo before you give ANY feedback, please read other people's comment CAREFULLY. I EXPLICTLY mention that "DISABLE THE INTERRUPT BUT KEEP THE COUNTING". The INTERRUPT already DISABLE, could you telll me how to generate MULTIPLE PULSE?

So the implementer is free to just disable the interrupt but keep the counting. This behaviour is very important to implement the tickless mode on top of oneshot_lowerhalf_s without any drift.

No. The behavior of a one shot is clear from its definition. It requires no further definition. A one shot generates a single pulse. If it generates multiple pulses it is not a on shot.

@patacongo before you give ANY feedback, please read other people's comment CAREFULLY. I EXPLICTLY mention that "DISABLE THE INTERRUPT BUT KEEP THE COUNTING". The INTERRUPT already DISABLE, could you telll me how to generate MULTIPLE PULSE?

A one shot, by its definition, generates a single event.  That is the required behavior to be a one shot.  Anything that generates multiple events is not a one shot.  What you are describing is not a one shot.
In order to get another event, the one shot has to be started again.  Refer to drivers/timer/oneshot.c for the definitive use of the one shot interface.

What Xiang is mentioning, I believe, is that you could have the ISR fire only once (on the ISR disable the interrupt) but have the timer continue running. This works when the timer does not autoreload itself (the ISR fires when the counter matches a value only) and will continue until wrapping around.

This works when the timer does not autoreload itself (the ISR fires when the counter matches a value only) and will continue until wrapping around.

And, after wrapping generates an erroneous event?

This works when the timer does not autoreload itself (the ISR fires when the counter matches a value only) and will continue until wrapping around.

And, after wrapping generates an erroneous event?

The timer usually generates a separate overflow event. Xiang assumption was that could could use ONESHOT_CURRENT() to retrieve the free running count even after timeout.

So the implementer is free to just disable the interrupt but keep the counting. This behaviour is very important to implement the tickless mode on top of oneshot_lowerhalf_s without any drift.

No. The behavior of a one shot is clear from its definition. It requires no further definition. A one shot generates a single pulse. If it generates multiple pulses it is not a on shot.

@patacongo before you give ANY feedback, please read other people's comment CAREFULLY. I EXPLICTLY mention that "DISABLE THE INTERRUPT BUT KEEP THE COUNTING". The INTERRUPT already DISABLE, could you telll me how to generate MULTIPLE PULSE?

A one shot, by its definition, generates a single event. That is the required behavior to be a one shot. Anything that generates multiple events is not a one shot. What you are describing is not a one shot.
In order to get another event, the one shot has to be started again. Refer to drivers/timer/oneshot.c for the definitive use of the one shot interface.

Of course, if you want to get another notification, you must call start again. Nobody change the behaviour: there is no furture event anymore once the event fired. The only difference is that the timer is keep counting.

The timer usually generates a separate overflow event. I understand Xiang assumption was that could could use ONESHOT_CURRENT() to retrieve the free running count even after timeout.

Okay, but none of the implementations in the repository work that way.

I decided to implement tickless support using RTC timer directly as it is easier for me at this point than addressing a more general solution to the problem discussed here so far. I will close this in order to start a new PR and make it easier to review.


Add PayPal

This is a feature request: Could you please add PayPal as a means of payment to the spring boot example app?

Thanks for the request. We will consider this based on our priorities. Please note that code wise adding paypal should be quite straightforward as you can replicate Ideal and change some configurations to get paypal working, but the biggest part is configuring  your paypal account itself and setting it up in the Adyen customer area see this: https://docs.adyen.com/payment-methods/paypal/web-component

Thanks for the prompt feedback. I think people are interested in how adyen integrates PayPal. I know that we can implement this on our own, but I was hoping to find a ready demo. We are currently using stripe and are considering to add PayPal OR to switch altogether to adyen. Because of that it would have been good to find an example/demo, which illustrates how one can integrate Credit Card Payment and PayPal at the same time.

Thanks for the feedback. We will try to add a demo to this app soon

That would be great! This will help companies who would like to use Credit Card + PayPal to make a decision in favor of adyen.

done via https://github.com/adyen-examples/adyen-java-spring-online-payments/commit/caf8a526e3ca9eedb0ad3a4b830aa33b44e6ca46


PP-335 Added a check for non numeric page, display_size passed

When non numeric value for page and display_size was passed it was
handling the error however validation was not populating the proper
error message, this fixes it, with a test

👍


Front End Components for Job Poster Builder - Impact

Front End Components for #916
Still more work needs to be done on #916

Adds front end elements for Job Poster Builder Impact Step

[ ] Make sure scroll works after model activates.

Handle Submit button isn't working, the modal is not appearing.
Switching from TextArea to TextAreaInput (the one designed for formik) seems to have fixed this.


Add interpreter for RsqrtOp.

closes #986

Please rebase this change on top of main. You'll also have to modify Ops.pp to include changes from Interpreter.cpp which is now merged into Ops.cpp.


Protect first_state_of_workflow_id & rename has_inherited_access_group_ids

see https://github.com/OpenSlides/openslides-backend/pull/279#discussion_r517418458

Also added the renaming of has_inherited_access_group_ids (see https://github.com/OpenSlides/openslides-backend-coordination/issues/137)


Kolibri Profile instructions

I'm unable to boot Kolibri using this configuration. What am I doing wrong?
window.onload = function() {     var emulator = window.emulator = new V86Starter({         wasm_path: "../build/v86.wasm",         memory_size: 512 * 1024 * 768,         vga_memory_size: 4 * 1024 * 768,         screen_container: document.getElementById("screen_container"),         bios: {             url: "../bios/seabios.bin",         },         vga_bios: {             url: "../bios/vgabios.bin",         },         hda: {             url: "../images/kolibri.img",         },         autostart: true,     }); } </script>

This is the error I get. Other OSs boot fine except this on my server.
SeaBIOS (version rel-1.12.1-0-ga5cab58)
Booting from Floppy...
Boot failed: could not read the boot disk
Booting from Hard Disk...
Starting system

Maybe it's floppy disk image, not hard drive?

I used the same kolibri.img  image from v86 github. I tried hda and fdd both don't work. Maybe my settings are wrong. Can you help me?

It is fda and not hda. I get the blue screen and that's it. No OS is shown.

It works now. I was using the wrong wasm file. Thanks.


Komodo 9 support

I do a lot of Jade in Komodo Edit so always loved your highlighter, but Komodo 9 says it's not compatible - any chance you could update?

Of course, i'm writing the new plugin =)

Hey, thanks for that :smile:   Unfortunately though, I think Komodo is moving faster than we are - I just tried your 0.2 xpi with the current Komodo Edit 9.2 and it won't install:

Any ideas?

I will work in the new versión... follow this issue :)

Should have closed this again a while ago - works on 9.3 :)


Revert "KYLIN-4349 Close InputStream in RowRecordReader.initReaders()"

This reverts commit 3eff292e7d0ecfca5a68d55f5c62243da719ac89.

Pull Request Test Coverage Report for Build 5600

0 of 41 (0.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.006%) to 27.519%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

engine-mr/src/main/java/org/apache/kylin/engine/mr/streaming/RowRecordReader.java
0
41
0.0%

Files with Coverage Reduction
New Missed Lines
%

engine-mr/src/main/java/org/apache/kylin/engine/mr/streaming/RowRecordReader.java
1
0%

Totals

Change from base Build 5598:
0.006%

Covered Lines:
24184

Relevant Lines:
87882

💛  - Coveralls


[BUG] errors during adding a product to cart aren't displayed

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
When I add a product to cart with some impossible quantity I'm able to add only one of it, but the message from the response is not displayed

Expected Behavior
the errors from the response are displayed, so I know what happened and why I don't have exact number of items in my cart
Steps To Reproduce

go to /detail/3c40bbdab5a94212b7834f879ab34539 route
add 9999 quantity
see the only one product was added
I can see errors object with proper warning attached - in line-item endpoint response

Environment
- OS:
- Node:
- pnpm:

Anything else?
No response

Will be covered by https://github.com/shopware/frontends/pull/1215


How should I copy a file from a container to another container?

My use case: I have a containerized service that runs in a container. This service has several integration tests that make use of test containers. Some of these containers need to be able to read a file before starting so in the initialization of the GenericContainer I would use withCopyFileToContainer(MountableFile.forClassPathResource(...)) to copy a file from the container in which the tests run to the test container, but this does not work. The file is not being copied. I assume withCopyFileToContainer only works if it is being invoked on the host.

Hi @csa777 do you have a code snippet of what you mean? I'm having a trouble visualizing your setup.


Segfault when expanding Visitor Hostnames and IPs

Hi, I've encounter a segfault issue when expanding the Visitor Hostnames and IPs panel.
==29663== GoAccess 1.5.7 crashed by Sig 11
==29663==
==29663== VALUES AT CRASH POINT
==29663==
==29663== FILE: /var/log/nginx/archive/sts.mulss.com.access.log
==29663== Line number: 71908
==29663== Invalid data: 0
==29663== Piping: 0
==29663==
==29663==
==29663== Please report it by opening an issue on GitHub:
==29663== https://github.com/allinurl/goaccess/issues

ec2-user@freebsd:~ $ goaccess --version
GoAccess - 1.5.7.
For more details visit: https://goaccess.io/
Copyright (C) 2009-2022 by Gerardo Orellana

Build configure arguments:
  --enable-geoip=mmdb
  --with-getline
  --with-openssl

I dug through the logs and found that it crashes on this line (despite the crash log reporting the last line in the file).
<IP_ADDRESS> - - [10/Apr/2022:12:29:37 +0000] "GET /?fbclid=IwAR2xdmCpdP1Hi7hAodoQMJB5fGX8fQ-4ux_-0HZEwyMfoFyTmh1U8GWkBrQ HTTP/1.1" 200 1256 "https://l.facebook.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Safari/605.1.15"
My best guess is it's just the line length that's causing the issue. It occurs with a few other similarly long lines. I compiled with --with-getline since this supposedly allows goaccess to allocate beyond 4096 chars. Do you have any ideas?
edit: it's only 308 bytes (I should have picked up on this earlier) so I'm not sure why the allocation would cause issues.

Thanks for reporting this. Could you please share the log/date/time-format that you are using? Also, please feel free to attach your config file.

Thanks for the quick response!
I'm using the default format options. I'm not using a config file. These formats work most of the time, there's just a few lines that trip it up, like the one above.
[x] NCSA Combined Log Format
Log format – %h %^[%d:%t %^] "%r" %s %b "%R" "%u"
Date format – %d/%b/%Y
Time format – %H:%M:%S

This line works fine:
<IP_ADDRESS> - - [30/May/2022:07:00:08 +0000] "GET /Admin/admin4.mp4 HTTP/1.1"<PHONE_NUMBER> "https://sts.mulss.com/Admin/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1 Safari/605.1.15"

It's not breaking on my end with those two lines. Are you able to share with me either those 71908 lines from your log or part of it?
Thanks

Here's 50 lines from the logs that includes the line above (there are several that cause it to crash though).
error-50.txt
I tried running goaccess from homebrew (goaccess--1.5.7.monterey.bottle.tar.gz) just then too which also failed with the same error.

For some reason it's not breaking on me. Here's what I get:

Are you running this on a mac? can I ask you to please run it through gdb? e.g.,
$ curl tar.goaccess.io/goaccess-1.5.7.tar.gz | tar xvz
$ cd goaccess-1.5.7/
$ ./configure --enable-debug --enable-utf8
$ make
$ gdb --args ./goaccess error-50.txt --log-format='%h %^[%d:%t %^] "%r" %s %b "%R" "%u"' --date-format=%d/%b/%Y --time-format=%T
(gdb) r <enter>
... attempt to crash
(gdb) bt full <enter>

Thanks

Gdb wasn't working for me out of the box. I ran it through Xcode instead (lldb).
Here's the stack trace
#1	0x000000010005b205 in xstrdup at src/xmalloc.c:57
#2	0x000000010000c876 in set_dash_metrics at src/gdashboard.c:1363
#3	0x000000010000a3b4 in add_sub_item_to_dash at src/gdashboard.c:1401
#4	0x000000010000a2e1 in load_data_to_dash at src/gdashboard.c:1437
#5	0x00000001000231f7 in allocate_data_by_module at src/goaccess.c:361
#6	0x0000000100021fd5 in allocate_data at src/goaccess.c:376
#7	0x000000010002358e in expand_current_module at src/goaccess.c:523
#8	0x000000010002272a in get_keys at src/goaccess.c:1150
#9	0x000000010001fcb8 in curses_output at src/goaccess.c:1280
#10	0x000000010001f389 in main at src/goaccess.c:1641

it crashed here:
char *
xstrdup (const char *s) {
  char *ptr;
  size_t len;

  len = strlen (s) + 1;  //  <<<  it's probably worth changing strlen to strnlen but I dont think that would have fixed it here
  ptr = xmalloc (len);

  strncpy (ptr, s, len);
  return (ptr);
}

variables at crash:
s	const char *	NULL	0x0000000000000000
ptr	char *	"0.0   B"	0x00000001011221f0
len	size_t<PHONE_NUMBER>

xstrdup was called by gdashboard->set_dash_metrics
1363   idata->metrics->data = xstrdup (data);

the variables here:
dash	GDash **	0x7ff7bfeff3d0	0x00007ff7bfeff3d0
metrics	GMetrics *	0x101404820	0x0000000101404820
    id	uint8_t	'\x02'
    data	char *	""	0x0000000101404880
    method	char *	NULL	0x0000000000000000
    protocol	char *	NULL	0x0000000000000000
    hits_perc	float	0
    visitors_perc	float	0
    bw_perc	float	0
    hits	uint64_t	0
    visitors	uint64_t	0
    bw	GMetrics::(unnamed union)
    avgts	GMetrics::(unnamed union)
    cumts	GMetrics::(unnamed union)
    maxts	GMetrics::(unnamed union)
module	GModule	HOSTS
totals	GPercTotals
is_subitem	int	1
idata	GDashData *	0x101122350	0x0000000101122350
meta	GDashMeta *	0x1088083f8	0x00000001088083f8
data	char *	NULL	0x0000000000000000
idx	int *	0x108808458	0x0000000108808458

and one call higher in add_sub_item_to_dash
dash	GDash **	0x7ff7bfeff3d0	0x00007ff7bfeff3d0
item	GHolderItem
module	GModule	HOSTS
totals	GPercTotals
i	int *	0x7ff7bfeff3b8	0x00007ff7bfeff3b8
sub_list	GSubList *	0x101404890	0x0000000101404890
iter	GSubItem *	0x1014048b0	0x00000001014048b0
module	GModule	HOSTS
metrics	GMetrics *	0x101404820	0x0000000101404820
id	uint8_t	'\x02'
data	char *	""	0x0000000101404880
*data	char	'\0'
method	char *	NULL	0x0000000000000000
protocol	char *	NULL	0x0000000000000000
hits_perc	float	0
visitors_perc	float	0
bw_perc	float	0
hits	uint64_t	0
visitors	uint64_t	0
bw	GMetrics::(unnamed union)
avgts	GMetrics::(unnamed union)
cumts	GMetrics::(unnamed union)
maxts	GMetrics::(unnamed union)
prev	GSubItem_ *	NULL	0x0000000000000000
next	GSubItem_ *	NULL	0x0000000000000000

I haven't tested on linux yet (which I can try later). So far macOS and FreeBSD both seem to crash. They might be sharing libraries but I don't think they're that similar these days.
I'm quite busy for the next fortnight but I'm happy to dig into the codebase after that to see what I can find :)

Thanks a lot for sharing those findings. I was able to reproduce this on a FreeBSD machine. For some reason, getnameinfo(3) on mac/BSDs will return \0 while in Linux does return a . (actual value) for some IPs. e.g.,  host <IP_ADDRESS>.
I pushed a fix, please feel free to build from development and let me know if that solves the issue on your end. I'll be pushing this out on the upcoming release.
Thanks again!

Tested on macOS (12.4) and FreeBSD (13.0), both worked great!
There's nothing quite like discovering that POSIX libraries don't match across OSs.. good catch, and thanks for the quick fix!


Update probs ontology prefix

Needs updating here:
https://github.com/ricklupton/sphinx_probs_rdf/blob/e7aabed2482f508b6f53b1e11bf65abff4dd0d09/src/sphinx_probs_rdf/directives.py#L224

Closed by #5


feat: add AoT compilation with webpack

Using nativescript-dev-webpack and @ngtools/webpack plugins.

Requires this fix to be merged: https://github.com/tjvantoll/nativescript-social-share/pull/16

@sis0k0 Just published version 1.3.2 of social share with your PR included. Thanks for letting me know!

Hey, @sis0k0 before merging this pull request could you take a look why is this happening when
the Groceries is bundled

and this is without bundling

Hey @sis0k0,
Out of curiosity why was this PR abandoned? I think this would be great functionality to have in Groceries.

Hey @tjvantoll,
We are planning to add this after 2.5 release :)

@sis0k0 Awesome 😄
Just fyi I opened an issue so this doesn’t get lost.


M-step update for sticky transitions

Hi Scott,
It was great meeting you at SfN.  Once again: we are massive fans of ssm, so I want to thank you and everyone who has worked on it for producing such a nice code base.
I wanted to ask if the m-step update for the sticky transitions is correct if your alpha parameter != 1.  In particular, I just went through the math, and believe I got a different update (where I am using alpha now to be the Dirichlet distribution parameters):

Specifically, I think the M-Step for the Sticky transitions should be:
        expected_joints = sum([np.sum(Ezzp1, axis=0) for _, Ezzp1, _ in expectations]) + 1e-8
        expected_joints += self.kappa * np.eye(self.K) + (self.alpha-1) * np.ones((self.K, self.K))
        P = expected_joints / expected_joints.sum(axis=1, keepdims=True)
        self.log_Ps = np.log(P)

Good catch, Zoe! I must have been too hasty with that implementation. Do you mind submitting a pull request with the fix?
Best,
Scott

On Nov 8, 2019, at 1:20 PM, Zoe Ashwood<EMAIL_ADDRESS>wrote:

Hi Scott,
It was great meeting you at SfN. Once again: we are massive fans of ssm, so I want thank you and everyone who has worked on it for producing such a nice code base.
I wanted to ask if the m-step update for the sticky transitions is correct if your alpha parameter != 1. In particular, I just went through the math, and believe I got a different update:
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Hi Scott, of course!  Should just have submitted it :-)

Closing now that PR https://github.com/slinderman/ssm/pull/64 is merged


Does it support tf 2.0?

CppFlow uses Tensorflow C API, and at the moment, the C API does not support officially TensorFlow 2.0
From TensorFlow C API webpage:

Note: There is no libtensorflow support for TensorFlow 2 yet. It is expected in a future release.

Actually, it does support tf 2.0 keras models.  I was able to do this for the mnist example and got it to work. However, you need to convert the models to a concrete function.  Then, convert the concrete function to a frozen graph.  See https://github.com/leimao/Frozen_Graph_TensorFlow/blob/master/TensorFlow_v2/train.py for an example of how to do this.


compatible with ie7?

it seems like coda-slider is NOT compatible with ie7. Isn't it?

sorry for my english.
i'm having problems on explorer 7/6
the overflow:hidden seems tobe one of the problems.
if you see it in chrome or another one, it see it perfect. http://www.zbv.com.ar/
but explorer 7 looks like this print screen

i wish someone can help me with this.
Thank You!

How does it look in IE 5 or IE 4? You don't want to support those too? ;-)
In short, if you still need to support very old, outdated browsers you need to learn how to fix issues like this yourself. Good luck.


Get role attributes

I was looking for if there is a way to get the attributes of a specific role that the user has assigned but I could not find the solution.
Any ideas ?
Official documentation
https://www.keycloak.org/docs/8.0/securing_apps/index.html#_javascript_adapter

Hi @itsalb3rt ,
Thanks for your feedback, to retrieve the roles for the currently logged in user you can use an hook like this
function useKeycloakUserRoles() {
  const [keycloak, kcInitialized] = useKeycloak();
  const roles = useMemo(() => {
    if (!kcInitialized) {
      return [];
    }

    return keycloak?.tokenParsed?.realm_access?.roles ?? [];
  }, [keycloak, kcInitialized]);

 return roles;
}

Hi @itsalb3rt ,
Thanks for your feedback, to retrieve the roles for the currently logged in user you can use an hook like this
function useKeycloakUserRoles() {
  const [keycloak, kcInitialized] = useKeycloak();
  const roles = useMemo(() => {
    if (!kcInitialized) {
      return [];
    }

    return keycloak?.tokenParsed?.realm_access?.roles ?? [];
  }, [keycloak, kcInitialized]);

 return roles;
}

Thank you! this answer partially helps me, but i need the attributes of the roles, is there a way to get the attributes of a specific role?


INITIAL COMMIT

-built a responsive microsite that displays weather based on given conditions.

thanks, we will review it soon!


Add option to call FastCGI through unix socket and TCP

Hey,
We use this consumer to execute numerous fast process in php and we realized that the startup cost of php took most of the execution time.
To resolve this issue we tried launching the process through FastGCI (PHP-FPM for this case) and we saw an improvement and now we would like to add this possibility to this consumer.
Would you consider accepting a PR adding an option to consume message though FastCGI unix socket ? default behavior would still be launching a script.

Hi @johnduro,
Agreed, script startup is a factor not to be underestimated. This is specially true if throuput is essential. But before adding another complexity to this project, I suggest you have a lock at https://github.com/skolodyazhnyy/amqp-cgi-bridge. As I understand said project is doing exactly what you are asking for.
Can you please have a lock and let me know if the amqp-cgi-Bridge is suits to your needs?

Hey,
Thanks for showing me this project, it does what we want but we use your consumer on a daily basis in production and we are pretty happy about it and about the fact that it is maintained, your quick response to issues is a good example. On the contrary amqp-cgi-bridge seems to have less users and activity
(the last commit is 9 month old).
In the light of these we would prefer to modify your consumer if i can convince you ! I think we could add this feature and keep a clean and understandable code.
Do you think it is worth a try ?

Not having recent commits is not a bad thing per se but I understand what you are saying. Thanks for your trust in me and this project. Indeed I am willing to follow along with this idea.
@johnduro If I understand you correctly, you would be willing to contribute the implementation of the FastCGI feature. If that is correct, please directly contact me by email. I would like to sync your work with some other ideas I have in mind and I would like to reduce the potential for conflicts and frustration.

great ! just sent you a mail

Target branch for this feature must be https://github.com/corvus-ch/rabbitmq-cli-consumer/tree/version-3.

@corvus-ch @johnduro  Is there a design spec for this feature? I don’t see how FastCGI is used here. I have a rough idea but some clarification would be good.
Also please keep in mind you ideally want to implement tcp and Unix sockets.

Is there a design spec for this feature? I don’t see how FastCGI is used here. I have a rough idea but some clarification would be good.

@estahn So far I do not have anything related to the implementation of this. The only thing I have so far is the interface I came up to bring the current shell exec and FastCGI under the same umbrella. See https://github.com/corvus-ch/rabbitmq-cli-consumer/wiki/Architecture and #68.

Also please keep in mind you ideally want to implement tcp and Unix sockets.

Yes, I agree. We should have support for both.

@estahn @corvus-ch yes i put only socket in the issue but it should/will be available for both.
If one of you have a preference for a package to use to make those calls i'm all ears.

Adding this and ability to subscribe to multiple queues (like https://github.com/skolodyazhnyy/amqp-cgi-bridge does) would make an amazing PHP-powered queue processor! <3


Fix WinFX casing and targets import

Supersedes #5346
https://github.com/microsoft/msbuild/blob/26f6d1d87700faa8b38d215dbde5968e6b8381f6/src/Tasks/Microsoft.NETFramework.CurrentVersion.targets#L129
https://github.com/microsoft/msbuild/blob/26f6d1d87700faa8b38d215dbde5968e6b8381f6/src/Tasks/Microsoft.Common.CurrentVersion.targets#L6151
These targets point to WinFX casing but has WinFx casing in the MSBuildToolsPath. This will result in file not found, if the targets get imported in a case-sensitive file-system. Since, no one used WinFX targets on Mono, they have not been reported, I think.
Also NETFX 2 has WinFX casing but NETFX 4 has WinFx casing. So, In order to cope with both WinFX and WinFx, I renamed the redirection targets to the correct case and then added a workaround which F# team uses to import either ones on a case-sensitive file system.

All Related PRs:

dotnet/wpf#2975
dotnet/wpf#2976
dotnet/sdk#11606

@rainersigwald /cc @ryalanms @vatsan-madhavan @marcpopMSFT

/azp run


DBZ-3611 Avoid NPE with database include/exclude lists

https://issues.redhat.com/browse/DBZ-3611

Hey, I don't quite understand that fix yet. What is triggering the NPE mentioned in the issue comments? In particular, I'd have expected that these unsupported props won't be touched whatsoever by this connector (which doesn't support them atm.), but you seem to indicate that their sole presence in the actual config will trigger some NPE?

So the default behavior in JdbcConnection#readSchema is the problem.
This method relies solely on the database driver to correctly return the catalog, schema, and table names but unfortunately the Oracle driver defaults to always turning the catalog name as null.  This means when we construct the TableId from this tuple and then verify if the tuple passes the TableFilter it fails, so the table isn't added to the list of tables. This leads to an inconsistency in RelationalSnapshotChangeEventSource#createSchemaChangeEventsForTables where the lookup of the table by TableId returns a null Table entry and the call to table.id() leads to the NPE.
Instead I'm looking if I could refactor the DatabaseMetadata loop where for Oracle we could resolve the catalog name from either the database.pdb.name or database.dbname and use that in place of the rs.getString(1) call to avoid the NPE.  If that's doable then I'll update the PR with that fix but if not this may require a bit more of an in-depth change.  I'll let you know.

HI @gunnarmorling so this approach should be more ideal; let me know.

Thanks @gunnarmorling, I'm hoping this small change will also then make supporting multiple PDBs easier :).

Yes, that'd be cool!


Update source links on single results page

Fixes

Fixes #2731 by @obulat
Related to #2582 by @fcoveram
Description

This PR implements only part of #2582: makes the links stack vertically, and adds the external link icon. It does not add the information tooltip.
Testing Instructions

Checklist

[ ] My pull request has a descriptive title (not a vague title likeUpdate index.md).
[ ] My pull request targets the default branch of the repository (main) or a parent feature branch.
[ ] My commit messages follow best practices.
[ ] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[ ] I tried running the project locally and verified that there are no visible errors.
[ ] I ran the DAG documentation generator (if applicable).

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

Closing in favor of #2851.


Adjust pipeline tasks granularity

Proposal 1: Adjust pipeline tasks granularity
Findings
As a garden linux maintainer, I want fast and targeted feedback on the code that I am comiting. The ability to run a subset of tests tasks in granular way would help me getting faster feedback.
Proposal
I would like to enable a way of running certain parts of the nightly workflow less intertwined and with more flexible input parameters. The input parameters decide which jobs do run with a certain subset of settings.

input parameters to nightly (or any similar workflow)

version --> version to built (parameter already exists)
jobs --> run only certain jobs

build
tests --> can be run without build phase by passing an already existing version
upload
container

arch --> run only certain architecture
platform --> run only for certain platforms (e.g. GCP)
use_kms --> do (not) run jobs that need KMS secrets
modifier --> image modifiert (e.g. "-gardener_prod")

Not sure about this, I did not often feel the need to run a subset of the platform tests.
I think that keeping an overview of our github workflows is pretty hard, we have a lot of workflows that partly call each other, so being informed about which tests we have is not trivial.
If this proposal does not make that situation worse by adding more complexity, then it's fine with me, but honestly I would prioritise simplification over more flexible invocation.

Descision: @yeoldegrove documents the feedback received in the meeting on 23rd Sept. We go forward and execute in October as agreed


split iot-agent build and packaging

What does this PR do?
Continuation of https://github.com/DataDog/datadog-agent/pull/25885 for the IOT agent this time

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


use env variables instead of using plain passwords

Signed-off-by: Krasi Georgiev<EMAIL_ADDRESS>

I don't think this is a good idea, as it requires more environment boilerplate for a user to get a working setup. The intent of this repository is to be used as building blocks, not a production deployment.

That is only a single env variable $JWT_SECRET.
The $POSTGRES_PASSWORD one will be set to a default "postgres" when not set.
Apart from this change I don't see anything else that needs changing to use it production. If that is not the case can you give some more details on what else would be needed to make it production ready?

the reason for this change is so that I can just copy and paste the compose file and init scripts without going through each line and removing/changing passwords.
This in my opinion is more work than just exporting these env variables with
export .....

Thanks @krasi-georgiev but I agree with @blocknonip. These files are intended to make it really easy (and predictable) for people to get started as one can simply run docker-compose up to spin up an environment. The created databases, users and passwords also matches with the loraserver.toml and lora-app-server.toml file configuration, so the whole setup is self-contained.
For some users using env. variables is not an issue, but for many it is.

using $POSTGRES_PASSWORD doesn't enforce the user to set this variable as it is set to the default of postgres when not set.
This change allows me to just copy and past the skeleton without going through each line every time there is an update to see what changes are required to make it production ready.


you forgot some things

here is the fixed functions:
bool C_BaseEntity::IsPlayer() { 	return GetClientClass()->m_ClassID == ClassId_CCSPlayer; }
`bool C_BaseEntity::IsWeapon()
{
int iClassId = GetClientClass()->m_ClassID;
return iClassId == ClassId_CAK47
	|| iClassId == ClassId_CSCAR17
	|| iClassId == ClassId_CDEagle
	|| iClassId == ClassId_CFlashbang
	|| iClassId == ClassId_CHEGrenade
	|| iClassId == ClassId_CSmokeGrenade
	|| iClassId == ClassId_CMolotovGrenade
	|| iClassId == ClassId_CDecoyGrenade
	|| iClassId == ClassId_CIncendiaryGrenade
	|| (iClassId >= ClassId_CWeaponAug && iClassId <= ClassId_CWeaponXM1014);

}`
It broke for my atleast.
What i found was wrong while using this base to my cheat, sorry if theres something still left!

Thanks for your contribution, I'll merge it asap
Feel free reporting another bugs and fixes :)

no problem, Love this source and still using it since I started making internals!

Should be fixed, try it now(updated vfunc indexes, not checking client class)

Should be fixed, try it now(updated vfunc indexes, not checking client class)

I haven't checked if it needs changing but the commit is called IsWeapon... and IsWeapon() didn't change.

hmm i should be changed it from 160 to 160 :trollface:

after merging your merge requests it can be closed?

issue answer timed out


Menu CSS cleanup / spec feedback

Changes

Add padding-right to menu items so that they wrap before colliding with the green arrow.
Consolidates -content-2, -content-3 styles.
Fixes padding issues on -grid styles where the menus where getting different padding at different levels.

Testing

gulp build 'n' check the mobile menu.
Desktop should be unaffected.

Review

@jimmynotjim
@KimberlyMunoz
@sebworks
@duelj @ajbush

Screenshots
1st level

2nd level

3rd level

Looks great to me!

:+1:


🎨 : Introduced Adaptive alert action for adaptive dialog.

Introducing new widget for displaying adaptive action buttons for adaptive alert dialog
Issue : https://github.com/flutter/flutter/issues/134347

NO breaking changes introduced in the changes, just new widget added for the community.

Pre-launch Checklist

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[x] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
[x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
[x] I signed the [CLA].
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is [test-exempt].
[x] All existing and new tests are passing.

@aliasgar4558 could you have the account for @rspl-aliasgar sign the CLA as well? Context tells me it's you, but it can be tricky legally if all accounts tied to commits to a PR haven't signed it.

@MitchellGoodwin - you are right, it's me , but I mistakenly commited the change with different email (user) but I have already signed the CIA on that account as well. Don't know why it didn't reflect. You got any idea for that? Or just let me know if someone I can revert the commit and commit again with my primary account (email)....

I triggered the rescan and it caught it. 👍

I triggered the rescan and it caught it. 👍

Great - Thank you so much mate.

Thank you for taking the time to put together this contribution, but after speaking with others on the team, we do not think this is the direction we want to go, as we do not want to enforce any sort of implied default, and if the developer wants their behavior it's simple to write themselves. If you are interested in taking this further, please feel free to make a package providing it.


[Feature] Better systems managing

Implemented:

System groups
Automatic multithreading (based on requested read/write access to components)
Systems ordering
And a lot more related to systems. Check updated Readme.

Added Example with collision detection (multiple systems with ordering running in parallel). Here is screenshot from example:

If you don't like this approach, please let me know.

Oh wow! Nice work! I'm still kind of going through it. but just from my first pass I do have a few concerns.

[Minor] I'd prefer to not have this library depend on other major libraries (such as Raylib)
Theoretically, because systems contain a pointer to the main World, they can very easily bypass the lock-enforced restrictions.
Queries should ideally be cached (rebuilding queries each frame is somewhat expensive because of all of the work done to figure out of what archetypes it needs to run for). So in your MovementSystem, for example, it'd be better to have the struct maintain a reference to the Query rather than a reference to the world. Doing that would actually fix Problem 2 that I mentioned above.
[Minor] I'd prefer for systems to be just functions if possible, rather than full structs. Just to so that adding systems is as easy as possible.

The way I was thinking of going with this is somewhat similar to how Bevy does it. Of course some of Go's language "quirks" make this more difficult:

System function signatures contain all of the resources that are required to run that function. So for in your MovementSystem example, you might have: func MovementSystem(dt time.Duration, query *ecs.View2[Position, Velocity]) { /* query.MapId(...) { ... } */ } (Also, maybe dt time.Duration might be a Resource).
When you add the system to a group, some sort of dependency injection-type code will run, generating a struct (similar to what you have), which defines all of the requirements: Queries, Read Dependencies, Write Dependencies, System Name (from function name).
I think GetRunAfter can be computed based on these read and write dependencies: A system must run after every system before it in the system list which writes to anything that it reads from. There is hopefully a way to convert the list of systems into a DAG based on their dependencies and then execute them down that tree. It might even be possible to do this locklessly as well.

Obviously my idea has a lot of problems based on the current code base:

Queries don't define read vs write dependencies, technically everything is a pointer to the underlying slice, so everything is a write dependency.
Filters are also passed in dynamically (rather than being compile time-typed), so they also make it hard to statically know the required component dependencies of a query
The library needs better formalization of how Writes should occur in systems. I've played around with a lot of ideas but haven't really liked any of them to be honest. Was thinking of doing something similar to Bevy Commands
I was kind of playing around with how the dependency injection would work here: https://github.com/unitoftime/ecs/blob/master/system.go#L33-L82 But couldn't really come up with anything that I loved. Go makes it hard because you end up with functions like NewSystem1, NewSystem2, NewSystem3, which can be kind of painful.

One thing to keep in mind also is that the amount of time it takes to do all of this preparation work doesn't matter, because It's only going to happen at app launch time, so we would want to precalculate and pre-cache as many queries as we can.
All that said, great work on this. It looks like a great start. This is obviously a very challenging problem to solve.
Thanks,
Unit


Fix JupyterLab not expanding to the full visual area

Description
Sometimes JupyterLab does not expand to the full visible area. This PR fixes this issue by iteratively checking and expanding the iframe.
Fixes: #1075
Checklist

[x] I have manually tested my changes and I am happy with the result.
[x] The documentation reflects the changes.
[x] The PR branch is set up to merge into dev instead of master.
[x] I haven't introduced breaking changes that would disrupt existing jobs, i.e. backwards compatibility is maintained.
[x] In case I changed the dependencies in any requirements.in I have run pip-compile to update the corresponding requirements.txt.
[x] In case I changed one of the services' models.py I have performed the appropriate database migrations (refer to the DB migration docs).
[x] In case I changed code in the orchest-sdk I followed its release checklist.
[x] In case I changed code in the orchest-cli I followed its release checklist.

Landed a different fix https://github.com/orchest/orchest/pull/1060/commits/f2e6087c9e6309f98dbc35432c41290b819cd94b


Can't remove all array elements from global

Bug Report
I have an array in a global. I can add elements to it and can remove elements from it as long as it still has elements.
But if i am removing ALL the elements in the array, the save does nothing and the global reverts back to its state before saving.
I think this is a MAJOR issue as this is blocking a normal flow.
Current Behavior
Removing the last element(s) in an array in a global doesn't work and global revert to its last state before saving.
Expected Behavior
Removing the last elements in an array in a global should make an empty array.
Steps to Reproduce

Open attached project
Navigate to the example global and create some elements in the array
Try to delete only one element (works)
Try to delete all remaining elements in the array (fails)

Detailed Description
Project: payload-global

Good catch @ahmedHusseinF – just deployed a fix for this. Update Payload and give it a shot! 👍


Import & Export of Data Models into Legend

Looking for some guidance on how we can import data models into Legend. Could not find any documentation around that, so was hoping someone can walk us through importing data models into Legend in different formats (json/avro/ddl/xml/ via a database connection..) from the Data Loader option/file upload via the api and possibly from different tools if there are any plugins built.
Also are there any options for exporting the data model in Legend in user friendly data format (csv,excel,pdf..)?

@beekemarie we here in DB are also looking for the same. Would be great to have some docs on this.

Import – There is no plug-in built yet. Legend supports any file formats via API integration or you can copy/paste JSON schema into the UI. Noted this down as a coverage gap in our docs to be added.
Export – Legend currently supports JSON schema, AVRO and Protobuf. For this, please select “New file generation” from the Studio UI. Please note that this feature is still in beta state and we’re working on debugging. Building out more user-friendly export formats are currently not on our roadmap. But that may be a good first issue other contributors could work on?

@AJ73 Please see answer above and let me know if you have any follow up questions.

Moved this issue to the Legend FAQ wiki page. https://github.com/finos/legend/wiki/Legend-FAQs


New Documentation structure

How to categorize this issue?

/area documentation
/kind enhancement
/priority normal
Umbrella issue for the new documentation structure.
The new documentation structure consists of different levels of knowledge which should represent the learning path.
And also should represent the different personas and their prerequisites to get started.

[ ] First task is to adapt the documentation to match the new levels.

Motivation

[x] what is Landscaper, why do I need it, what does it
[x] first simple example

install Landscaper helm chart
nginx example

Level 0 (Beginner)

[ ] how can I install Landscaper (landscaper-cli init)

landscaper configuration (credentials)
Deployer

[ ] what components does Landscaper consists of

their relationship
only user facing components (Blueprint, Component Descriptor installation, target/dataobject, deploy item)
were do the components live (compare to containers)

[ ] Blueprint

only parts: imports, exports

[ ] Installations

find issues
Provide configuration (data)
create initial installation

Level 1 (Intermediate)
Landscaper Operator

[ ] how can I install the landscaper (full blown)

production ready setup
landscaper configuration (credentials)

[ ] Deployers

Developer

[ ] tutorials
[ ] Blueprint, ComponentDescriptor documentation
[ ] test locally

render
inline blueprints etc...

Level 2 (Landscaper Core)

[ ] oci artifacts: description, manifests, blobs

ℹ   Feel free to add additional points

cc @gardener/landscaperctl-maintainers @gardener/landscaper-maintainers

cc @gardener/landscaperctl-maintainers @gardener/landscaper-maintainers

How do we go on with this one here ? I mean, how should we start creating the new documentation structure, based on the "Chapter Outline" above ? I would suggest we create a readme_new.md, and start working on that one in a new branch. After that has been finished and most relevant and up to date documentation has been created and/or existing docs have been properly linked from this Overview Readme, we can exchange the old one with the new one. Agreed ?

How do we go on with this one here ? I mean, how should we start creating the new documentation structure, based on the "Chapter Outline" above ? I would suggest we create a readme_new.md, and start working on that one in a new branch. After that has been finished and most relevant and up to date documentation has been created and/or existing docs have been properly linked from this Overview Readme, we can exchange the old one with the new one. Agreed ?

Sounds good to have a new document with the new structure and update that one continuously.
But I would not wait until all the new docs are available (I do not see that in the near future). So I would rather create the new structure with the old linking besides the old one. With the old one containing a link to the new one.
With that we are always up-to-date and users can follow the new, not-yet-finished structure if they want.
WDYT?

Yes, makes sense. So I will try and go ahead creating a readme_new.md, with the structure above, and link to existing documents which are (from my point of view :) ) still up-to-date. All the other missing docs we will create and properly link from the new readme over the next weeks.

Current State

Motivation Chapter Done
Level 0 (Beginner) more or less done

One chapter of the new readme file can be deleted (as the topic is included in the previous chapters already)
Link to CLI Documentation about how to use the CLI / install the landscaper needs to be added

@In-Ko closed because outdated and/or copied into internal project


Should deny further write if ParquetWriter is aborted

Describe the bug, including details regarding any error messages, version, and platform.
After PARQUET-2437, InternalParquetRecordWriter will switch to aborted state if write throws, but still accept further writes even though these writes will not be flushed during close, leaving the file incomplete. Users will not notice the corrupted file until they actually read the file.
Should we check for aborted state and reject further writes to avoid such surprises?
@gszadovszky
Component(s)
No response

@hellishfire, How users would not notice the corruption when the related exception is thrown? My change is related to auto-closing to not to write anything automatically (at closing) after an exception happened. The users of the API shall not continue writing data after an exception.

@hellishfire, How users would not notice the corruption when the related exception is thrown? My change is related to auto-closing to not to write anything automatically (at closing) after an exception happened. The users of the API shall not continue writing data after an exception.

We found that some users still try to write after exception, then successfully close the file, only to find out later that the file can not be opened for read because of missing file footer.
Perhaps it's better to deny any write to make it fool-proof?

On another note, in InternalParquetRecordWriter.java
  public void write(T value) throws IOException, InterruptedException {
    try {
      writeSupport.write(value);
      ++recordCount;
      checkBlockSizeReached();
    } catch (Throwable t) {
      aborted = true;
      throw t;
    }
  }

Should we narrow the try-catch scope to exclude exceptions thrown by writeSupport (i.e. illegal input values denied by writeSupport), which is irrelevant to actual file io operation?

We found that some users still try to write after exception, then successfully close the file, only to find out later that the file can not be opened for read because of missing file footer.
Perhaps it's better to deny any further write to make it fool-proof?

I don't think parquet-java is fool-proof in any ways. And how do you think we should handle the case of continue writing with a writer that is already "aborted"? Throw yet another exception? I am not against it but cannot see the point. Also, it shall not significantly impact write performance.

Should we narrow the try-catch scope to exclude exceptions thrown by writeSupport (i.e. illegal input values denied by writeSupport), which is irrelevant to actual file io operation?

It would make sense but I am not sure if we can 100% differentiate the potential exceptions and whether we already had impact on the file writing at the throwing time or not.
Feel free to put up a PR if you would like to work on this. I'm happy to review.

@hellishfire, my bad, should have explained in more details. In many cases, Parquet writers are used in a try-with-resources construct. It invokes close in any case including exceptions thrown during the writes. close invokes flush by default which actually does some writing. It may cause issues like throwing exceptions while closing which is not always a problem. But, if you would use e.g. direct memory via the ByteBufferAllocator interface, it needs to be released and if fails, it may lead to memory leaks.


Mutliple PLEX servers

Authentication failed : org.simpleframework.xml.core.PersistenceException: Element 'Server' is already used with @org.simpleframework.xml.Element(name=Server, type=class fr.arsenelapostolet.plexrichpresence.model.Server, data=false, required=false) on field 'Server' private fr.arsenelapostolet.plexrichpresence.model.Server fr.arsenelapostolet.plexrichpresence.model.MediaContainerServer.Server at line 4

Yes it's a know issue : #6

Yes it's a know issue : #6

Yes it's the multiple plex server error, I forgot about it

Yes it's the multiple plex server error, I forgot about it

Thank you @Ombrelin !

Thank you @Ombrelin !

The bug has been fixed, the first plex server is now selected. I'll improve that either by polling all the user's server or by featuring a server selection UI.

The bug has been fixed, the first plex server is now selected. I'll improve that either by polling all the user's server or by featuring a server selection UI.

@Ombrelin I tried to login but it doesnt log me in
INFO  - Authentication failed : Unable to connect to plex server.

@Ombrelin I tried to login but it doesnt log me in
INFO  - Authentication failed : Unable to connect to plex server.

Mmmh I tested with multiple server myself, might be something else. We'll release a new version soon with a new login technique so maybe it'll fix this. Keep me posted if it doesn't !

Mmmh I tested with multiple server myself, might be something else. We'll release a new version soon with a new login technique so maybe it'll fix this. Keep me posted if it doesn't !

I'll try to be on top when you release the new version :) Sometimes I skip the notifications, too many of them

I'll try to be on top when you release the new version :) Sometimes I skip the notifications, too many of them

@Ombrelin it's working now :D
Slight issue (not for me), your app uses 300mb+ of ram, I can see a problem with preople with less then 16gb of ram

Oh and, if I'm not on the plex app or the web interface, it says that I'm idle on discord, is that how it's supposed to be? Not really sure how hard it is to detect that you are on plex app or not

Oh and, if I'm not on the plex app or the web interface, it says that I'm idle on discord, is that how it's supposed to be? Not really sure how hard it is to detect that you are on plex app or not

I just implemented this.
@Ombrelin let me know if you want to submit PR for this.

Indeed that would be very helpful !

@Ombrelin it's working now :D
Slight issue (not for me), your app uses 300mb+ of ram, I can see a problem with preople with less then 16gb of ram

Glad to hear !
For the memory usage, I'll look into it

Thank you guys @Ombrelin and @mclarence ❤
I would like to help with this, but I don't have enough knowledge of Java, specifically never used a Java framework like spring boot

No problem ! Any input is valuable 😉
But don't be afraid of the Spring Boot usage in this project, it's only leveraged for Dependency Injection nothing too fancy

@Ombrelin unfortunately, I can't get it to work now, it doesn't capture that I am watching something

It says no session detected whereas you have a session playing on PLEX ?

yup..

You have multiple plex servers right?
Are you playing the media (shown in the screenshot) from another server or your main one?
Does it work on your other server?

tried both, neither one of them showed up in here

Before it worked fine, on 1.3

It's very weird, since the server fetching process did not change between 1.3 et 1.4, @mclarence correct me if I'm mistaken

No, it has not changed.
I will probably post a new jar file of the app with increased verbosity in the logging so that we can pin point the cause of the issue.

plex-rich-presence-1.4.jar.zip
Please run the above jar file using java -jar <path to jar file>. Reproduce the issue and post the log to this issue.

plex-rich-presence-1.4.zip
Please run the above file with java -jar plex-rich-presence.jar -Dlogging.level.root=DEBUG and post the output from the command line here.

Sorry I haven't found the time to do it yet, Noticed there was a similar issue with the other user, so I guess it doesn't have a fix?

Yes, if you are not the owner of the plex server then the program will not detect the streams.
However, just post the debug log on pastebin and i'll have a look at it.

@Ombrelin it's working now :D
Slight issue (not for me), your app uses 300mb+ of ram, I can see a problem with preople with less then 16gb of ram

Glad to hear the new login fixed your problem !
For the memory usage, I'll look into it

In regards to memory usage, i've tested it with AdoptOpenJDK 11 + OpenJ9 JVM and it seems to have reduced the usage by quite a bit. From around 250-300 MB to around 160-180MB.

That's good news ! I guess you added JavaFX as a Maven dependancy then ?

Yes.
jmetro had to be bumped up to 11.6.14 also.

Okay ! My only fear with bumping the Java version is that people most commonly have JRE 8 installed by default.

Maybe you can bundle it with the windows installer.

Yes I think there is definitely an option in launch4j to do that

Should be fixed in 2.0 version !


chore: Pull noir for u64 as array lengths

subrepo:
subdir:   "noir"
merged:   "e80c5f73a"
upstream:
origin:   "https://github.com/noir-lang/noir"
branch:   "master"
commit:   "e80c5f73a"
git-subrepo:
version:  "0.4.6"
origin:   "???"
commit:   "???"
Please read contributing guidelines and remove this line.

Benchmark results
Metrics with a significant change:

batch_insert_into_append_only_tree_16_depth_ms (8): 18.2 (+41%)
batch_insert_into_append_only_tree_16_depth_hash_ms (8): 0.769 (+41%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit 8307dadd and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
128 txs

l1_rollup_calldata_size_in_bytes
54,212
214,436
855,332

l1_rollup_calldata_gas
259,928
1,019,768
4,058,468

l1_rollup_execution_gas
354,114
1,139,216
4,279,869

l2_block_processing_time_in_ms
1,281 (-2%)
4,850
19,248 (-5%)

note_successful_decrypting_time_in_ms
215 (-7%)
633 (+3%)
2,261 (-4%)

note_trial_decrypting_time_in_ms
30.4 (-41%)
75.7 (+58%)
189 (-12%)

l2_block_building_time_in_ms
22,270 (+4%)
88,419 (+4%)
358,301 (-1%)

l2_block_rollup_simulation_time_in_ms
16,874 (+5%)
67,137 (+6%)
273,385

l2_block_public_tx_process_time_in_ms
5,358
21,199
84,568 (-5%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
17,329 (+2%)
33,789 (+6%)

note_history_successful_decrypting_time_in_ms
1,414
2,726 (-1%)

note_history_trial_decrypting_time_in_ms
298 (+75%)
230 (-9%)

node_database_size_in_bytes
19,189,840
36,560,976

pxe_database_size_in_bytes
29,923
59,478

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
340
44,664
27,457

private-kernel-ordering
209 (-3%)
45,777
14,627

base-rollup
1,850 (+4%)
175,344
933

root-rollup
82.9 (-1%)
4,192
825

private-kernel-inner
443 (-1%)
73,099
27,457

public-kernel-app-logic
273 (-2%)
32,254
25,379

merge-rollup
7.99
2,712
933

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
2 leaves
8 leaves
16 leaves
32 leaves
128 leaves
64 leaves
512 leaves
1024 leaves
2048 leaves
8192 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.4 (-1%)
10.8 (-2%)
:warning: 18.2 (+41%)
17.3 (-4%)
23.8 (+2%)
65.8 (-24%)
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.9
17.5
23.0
31.6
47.0
143
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.600 (-1%)
0.597 (-2%)
:warning: 0.769 (+41%)
0.535 (-4%)
0.491 (+1%)
0.450 (-24%)
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
N/A
N/A
N/A
76.7 (+1%)
48.2 (-3%)
243
467 (-2%)
918 (-1%)
3,621 (-6%)

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
N/A
N/A
N/A
159
96.0
543
1,055
2,079
8,223

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
0.472 (+1%)
0.493 (-3%)
0.442
0.437 (-2%)
0.435 (-1%)
0.434 (-6%)

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
N/A
N/A
N/A
114
58.5 (-2%)
354 (-2%)
697
1,386
5,528 (-6%)

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
N/A
N/A
N/A
207
104
691
1,363
2,707
10,771

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
0.509
0.506 (-2%)
0.479 (-1%)
0.478
0.476 (-1%)
0.477 (-5%)

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
N/A
N/A
65.3 (-3%)
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
N/A
N/A
110
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
N/A
N/A
0.562 (-3%)
N/A
N/A
N/A
N/A
N/A
N/A

Miscellaneous
Transaction sizes based on how many contracts are deployed in the tx.

Metric
0 deployed contracts
1 deployed contracts

tx_size_in_bytes
18,472
34,542

Transaction processing duration by data writes.

Metric
0 new note hashes
1 new note hashes

tx_pxe_processing_time_ms
3,448 (+8%)
1,728 (+14%)

Metric
0 public data writes
1 public data writes

tx_sequencer_processing_time_ms
0.0315 (-5%)
655 (-3%)


[FLINK-32370][client] Fix warn log in result fetcher when job is finished

What is the purpose of the change
This PR aims to fix warn log in result fetcher when job is finished which should log debug log in fetcher. When the fetcher print warn information in log file, it may cause jdbc e2e test fail
Brief change log

Use ExceptionUtils.findThrowableWithMessage to check exception in fetcher instead of ExceptionUtils.findThrowable

Verifying this change
This change added tests and can be verified as follows:

Added RestClusterClientTest.testSendCoordinationRequestException to check exception message

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no) no
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no) no
The serializers: (yes / no / don't know) no
The runtime per-record code paths (performance sensitive): (yes / no / don't know) no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know) no
The S3 file system connector: (yes / no / don't know) no

Documentation

Does this pull request introduce a new feature? (yes / no) no
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Hi @libenchao Please help to review this PR for test case in JDBC and Sql Gateway when you're free, thanks


fix: futura font name in css

Intranet changed font name some time ago. It's not showing the right font in some contexts (see screenshot below).

The two classes might also not be necessary anymore. I could only verify on Linux + Firefox though. In the comment is says it was a fix for Windows...


Fixed redirect handling. Includes tests

I was using supertest when developing the other day and realized that redirects could not be examined. This fixes that issue.

I agree with @naterkane, the redirection and the destination url should be tested separately. @mikelax ?

@nfroidure I'm agree with you.
@ravenac95, can you update your PR ?


Possibility for collaboration

Hi, I just stumbled over your project here when checking the list of projects dependent on h3o. I am implementing something related to what you are starting here - so maybe it could be helpful for you. It is more of a hobby project I try to work on when I find the time for it. Maybe parts of this could be helpful for you:

h3arrow - is a rust library is a integration of h3o with arrow2. It already exposes quite a few algorithms. It is not yet on crates.io, but I want to push it the next few days. Has some integration with geoarrow
h3ronpy - is a python extension bringing the former library to python using pyarrow and some wrappers for pandas and polars

Hey Nico, thanks for reaching out, this is great news!
I actually did come across your work when I was trying discover any prior art for implementing H3 functionality with polars dataframes. If I recall correctly, I think I saw that h3ronpy was using the h3ron library at the time, or at least I assumed as much and then saw the note on the h3ron README that the project was in maintenance mode.
So from there, I believe I assumed that work would be stopping on h3ronpy and hadn't seen that you were in the midst of rewriting it to use h3arrow and h3o.
Given that it's pretty much what we were looking for, and that you're much farther along in implementing the H3 API, we'll probably pivot to using h3ronpy and will archive/deprecate this h3o_polars_ext project. And we'll work to report any issues and contribute code where we can. Thanks again, looking forward to getting familiar with h3ronpy more :)

The naming situation maybe is a bit confusing - I switched to h3o from h3ron a while ago, but did not want to change the name h3ronpy as it was already used in a few other projects. The switch itself took quite a while as I got sidetracked by other things while after I started the migration.
I must confess I feel a bit bad now as I did not want to stop your project here :wink:  Looking forward to your contributions  - there certainly is quite some room for further improvements.

The naming situation maybe is a bit confusing - I switched to h3o from h3ron a while ago, but did not want to change the name h3ronpy as it was already used in a few other projects.

Yeah, that makes sense, I think I would've done the same as well, it was my own assumptions that led me astray.

I must confess I feel a bit bad now as I did not want to stop your project here

Please don't, I'm happy to see that there's a project filling the need 😄

Great. It is also really interesting for me to see where my project is getting used.


Provide DockerContainer implementation (#2089)

Note for reviewers: Only the second commit is relevant here. The first is part of another pull-request which is to be merged first.
This implementation is an abstraction layer for using Docker containers as OpenWhisk action containers - in preparation of a new container pool implementation (#2086). The DockerContainer implementation provides a high-level abstraction for the operations required by OpenWhisk:

Create, destroy, halt, resume a container
Initialize and run an action inside a container
Obtain container logs

Closes #2089

PG3 - 594 🔵


Page is simply "dist/index.html" on fresh install

Following this instructions on Node 5.11.1, the page at localhost:3000 is plaintext: dist/index.html
If I add a slash and some letters e.g. localhost:3000/dist then I get something resembling the starter app but with a 404 instead of the increment/decrement area.
There were no errors or warnings that I noticed. This is on Windows 8, and my colleagues suspect some kind of windows-specific webpack weirdness.

This happens for me too :( (Windows 10)

Same on Windows 10

Can anyone confirm if this is still happening with the latest version of pux and pux-starter-app?

It's not happening for me with the latest version :)


Add option to call profile service from introspection

Similar to "update claims on refresh" option

Should we do something similar on userinfo?

Also, we should always call IsActive regardless if we reload profile. That's a bug IMO.

@brockallen  please open new issue


Dynamically setting connection string

Is it possible for a URL param to determine which database to connect to when using PostGraphQL as a library? This is what I tried but doesn't work; it just hangs when trying to visit localhost:3000/user/graphiql. If you visit localhost:3000/user/graphql it throws the expected 'Only POSTrequests are allowed' error.
var express = require('express');
var postgraphql = require('postgraphql').postgraphql;

const app = express();

var services = {
 notification: 'CONNECTION_STRING_TO_NOTIFICATION_SERVICE',
 user: 'CONNECTION_STRING_TO_USER_SERVICE',
};

app.use('/:service', function(req, res, next){
 var service = services[req.params.service];
 if(!service) {
  res.status = 404;
  res.send({
   error: req.params.service + ' is not a valid service',
  });
  return;
 }
 req.service = service;
 next();
});

app.use(function(req, res, next) {
 return postgraphql(req.service, 'public', {
  graphiql: true,
  })(req, res, next);
})

app.listen(3000, function() {
 console.log('Listening on 3000');
});

+1

Referring to: https://github.com/postgraphql/postgraphql/blob/master/docs/library.md
I'd go with two postgraphql instances, so you want something like this (untested):
const express = require('express');
const postgraphql = require('postgraphql').postgraphql;

const app = express();

var services = {
 notification: 'CONNECTION_STRING_TO_NOTIFICATION_SERVICE',
 user: 'CONNECTION_STRING_TO_USER_SERVICE',
};

app.use(postgraphql(services.notification, 'public', {
  graphiql: true,
  graphqlRoute: '/notification/graphql',
  graphiqlRoute: '/notification/graphiql',
});

app.use(postgraphql(services.user, 'public', {
  graphiql: true,
  graphqlRoute: '/user/graphql',
  graphiqlRoute: '/user/graphiql',
});

app.listen(3000, function() {
 console.log('Listening on 3000');
});

Doing this the way @benjie described is a good idea. Alternatively, you could set up a memoization function. The key thing is to not call postgraphql more times then the number of services you have. So if you have two services you want to only be calling postgraphql twice and not once for every request. This is because every time postgraphql is called PostGraphQL will perform a fresh introspection of your database schema and generate the GraphQL API from that. This is probably why you are seeing some lag 😊
What I think should make the most sense for you (based on your described usecase) is something much like what @benjie described, but you could even make it a little more programatic:
const services = {
 notification: 'CONNECTION_STRING_TO_NOTIFICATION_SERVICE',
 user: 'CONNECTION_STRING_TO_USER_SERVICE',
};

for (const [service, connectionString] of Object.entries(services)) {
  app.use(postgraphql(services.notification, 'public', {
    graphiql: true,
    graphqlRoute: `/${service}/graphql`,
    graphiqlRoute: `/${service}/graphiql`,
  }));
}

If you want to swap your PostGraphQL instance out based on some information provided in the HTTP request you could do something like:
const services = {
 notification: postgraphql('CONNECTION_STRING_TO_NOTIFICATION_SERVICE', 'public', {
    graphiql: true,
  }),
 user: postgraphql('CONNECTION_STRING_TO_USER_SERVICE', 'public', {
    graphiql: true,
  }),
};

app.use((req, res, next) => {
  if (someCondition) {
    services.notification(req, res, next);
  } else {
    services.user(req, res, next);
  }
});

Let us know how it goes!

Thanks @calebmer and @benjie .
Works pretty great !!!

To keep things manageable I'm going to close this issue as I think it's solved; but if not or you require further help please re-open it.

Hello @calebmer,
I think you have a bug in your code snippet:
for (const [service, connectionString] of Object.entries(services)) {
  app.use(postgraphql(services.notification, 'public', {
    graphiql: true,
    graphqlRoute: `/${service}/graphql`,
    graphiqlRoute: `/${service}/graphiql`,
  }));
}

There is:
app.use(postgraphql(services.notification, 'public', {
but should be:
app.use(postgraphql(connectionString, 'public', {
The same is in the documentation:
https://www.graphile.org/postgraphile/multiple-schemas/
Kind regards,
Richard

I believe the code is correct; services.notification is the relevant connection string:
const services = {
 notification: 'CONNECTION_STRING_TO_NOTIFICATION_SERVICE', // < Connection string
 user: 'CONNECTION_STRING_TO_USER_SERVICE',
};

Syntactically correct, semantically incorrect ;)

Oh I see what you’re saying 👍

Fixed in both places :+1:  https://github.com/graphile/graphile.github.io/commit/4cf240f4cc340c8b0fc37012377e19efc0b0fc7f


Contact and stability sharp ib

Description of the problem
-This PR aims to add the possibility to handle contact between IB_particles. This PR also includes a complete reformulation of the stabilization of the integration of the particles. Since some of the DEM code from the DEM solver is used, the solver was moved to the FEM-DEM solver section.
Description of the solution

Add a IB_particle_dem_solver. This solver is used to solve the dynamics of the particle at a different time scale in order to be able to take into account the contact between particles.
Rework of the stabilization of the integration of particles.

How Has This Been Tested?

2 tests have been added

[ contact_test] This test simulate the contact between 2 particles. It verifies that the solution of the position and force on both particles are not modified.

[  coupled_moving_stokes] This test simulates the moving stokes case with the particle dynamics coupled. We verified that we have the L2 error norm expected.

Future changes

In the future, a lubrification model will be added to consider the loss of precision when two particles are too close to each other.

Comments

Anything that you want to add up that didn't fit in any other category can be written here

@Luckabarbeau  all your tests fail in Debug. Seems like a dude I know has launched the code in debug in a while meh? Wink Wink

@Luckabarbeau I have refactored the particle-particle and particle-wall contact force calculations to remove all the code duplications. Now all the force calculations are performed inside the DEM class. There are a few things left to be done. First the DEM parameters should be initialized inside the gls_sharp_navier_stokes (you will see the error when you compile), and the contact force calculations should be rechecked for possible bugs (I think the tests you added can help us for this purpose). I leave these corrections to you, as the main job is finished. :)