Add protection against use after free due to Http2ConnectionState::destroy() being called more than once per session.

Replacing the fix with a more defensive fix to protect against double delete when Http2ConnectionState::destroy() is called more than once (similar to the technique used in Http2ClientSession::destroy() via a in_destroy state). (as it looks like preventing ua_session->destroy() from being called multiple times will result in leaking the io buffers). Also resetting the shutdown_cont_event

I may not understand the condition correctly, but it sounds odd. Because if there is still a transaction alive, total_client_streams_count should not be 0 and this block should not be ran.
Is there any way to reproduce this crash?

The current change makes more sense than the first one. But it's still odd that destroy() is called twice.
Can you print _history?

I’m ok with adding this guard, but I still don’t understand how it is called twice.
Because destroy() should not be called twice, I don’t want to let it return silently without any reports. How about adding ink_assert(!in_destroy) ?
It would be really helpful if you could share an example plugin that causes the second call.

Hmm, I tried a few things to reproduce the second call on master and 8.0.x, but I couldn't.

Reenable after inactive timeout
Reenable after triggering rate limit

The plugin I wrote is like this:
TSHttpTxn transactions[128] = {0};
int x = 0;

static int
event_handler(TSCont contp, TSEvent event ATS_UNUSED, void *edata)
{
  TSHttpSsn ssnp;
  TSHttpTxn txnp;

  switch (event) {
  case TS_EVENT_HTTP_SSN_START:
    ssnp = (TSHttpSsn) edata;
    TSHttpSsnHookAdd(ssnp, TS_HTTP_TXN_START_HOOK, contp);
    TSHttpSsnReenable(ssnp, TS_EVENT_HTTP_CONTINUE);
    break;
  case TS_EVENT_HTTP_TXN_START:
    txnp = (TSHttpTxn) edata;
    TSHttpTxnHookAdd(txnp, TS_HTTP_PRE_REMAP_HOOK, contp);
    TSHttpTxnReenable(txnp, TS_EVENT_HTTP_CONTINUE);
    break;
  case TS_EVENT_HTTP_PRE_REMAP:
    txnp = (TSHttpTxn) edata;
    TSDebug("maskit", "-------------------------------------------------------- PRE_REMAP");
    transactions[x] = txnp;
    ++x;
    /* TSContScheduleOnPool(contp, 150000, TS_THREAD_POOL_TASK); */
    TSContSchedule(contp, 150000, TS_THREAD_POOL_TASK);
    break;
  default:
    txnp = (TSHttpTxn) edata;
    TSDebug("maskit", "-------------------------------------------------------- DEFAULT");
    for (int i = 0; i < 128; ++i) {
      if (transactions[i] != 0) {
        TSHttpTxnReenable(transactions[i], TS_EVENT_HTTP_CONTINUE);
        transactions[i] = 0;
        break;
      }
    }
    break;
  }
  return 0;
}

I'm -0 on this. The change seems harmless, but it would hide the real issue (the cause of double destroy).
Also, zombie_event seems to be used for a different purpose. It was introduced to detect a kind of leak, but not double free, IIUC. It would confuse us because we would have no idea which one caused the event. Any comments? @shinrich

I am also lukewarm on the change.  The zombie event, should track that the object we aren't destroying does get cleaned up within the zombie deadline, so I think the use here is ok.
Since the error was seen on an older version can cannot be reproduced on master or 8, I'd rather hold off on this change in case it is unnecessary due to some of the other numerous changes in the HTTP/2 area.

@maskit @shinrich
This happened again even with the additional guard. Found 2 different kinds of trace backs (on two different boxes) both crashing in Http2ConnectionState::destroy()
{code}
(gdb) bt
#0  0x00002ae162a280a0 in ?? ()
#1  0x0000000000616064 in destroy (this=0x2ae124cd5200) at Http2ConnectionState.h:169
#2  Http2ClientSession::free (this=) at Http2ClientSession.cc:142
#3  0x0000000000613c2e in Http2ClientSession::main_event_handler (this=0x2ae124cd4f80, event=, edata=0x2ae1a0c72470) at Http2ClientSession.cc:382
#4  0x00000000007698a0 in handleEvent (data=0x2ae1a0c72470, event=105, this=0x2ae124cd4f80) at ../../iocore/eventsystem/I_Continuation.h:153
#5  read_signal_and_update (vc=0x2ae1a0c72350, event=105) at UnixNetVConnection.cc:148
#6  UnixNetVConnection::mainEvent (this=0x2ae1a0c72350, event=, e=) at UnixNetVConnection.cc:1203
#7  0x0000000000760b33 in handleEvent (data=0x2ae0d8fbdc20, event=1, this=0x2ae1a0c72350) at ../../iocore/eventsystem/I_Continuation.h:153
#8  InactivityCop::check_inactivity (this=0x2ae0d830db80, event=, e=0x2ae0d8fbdc20) at UnixNet.cc:102
#9  0x000000000078d5ad in handleEvent (data=0x2ae0d8fbdc20, event=2, this=) at I_Continuation.h:153
#10 EThread::process_event (this=0x2ae0daa08000, e=0x2ae0d8fbdc20, calling_code=2) at UnixEThread.cc:152
#11 0x000000000078e281 in EThread::execute (this=0x2ae0daa08000) at UnixEThread.cc:234
#12 0x000000000078d04a in spawn_thread_internal (a=0x2ae0d830f280) at Thread.cc:86
#13 0x00002ae0d5dc5dc5 in start_thread () from /lib64/libpthread.so.0
#14 0x00002ae0d6e5f76d in clone () from /lib64/libc.so.6
{code}
{code}
(gdb) bt
#0  0x00002b6525eda6a0 in ?? ()
#1  0x0000000000616064 in destroy (this=0x2b64d3753f00) at Http2ConnectionState.h:169
#2  Http2ClientSession::free (this=) at Http2ClientSession.cc:142
#3  0x00000000004f3f11 in handle_api_return (event=, this=) at ProxyClientSession.cc:201
#4  ProxyClientSession::state_api_callout (this=0x2b64d3753c80, event=, data=) at ProxyClientSession.cc:153
#5  0x000000000061ae72 in Http2ConnectionState::release_stream (this=this@entry=0x2b64d3753f00, stream=stream@entry=0x2b651a9d4f90) at Http2ConnectionState.cc:1152
#6  0x00000000006075f9 in Http2Stream::destroy (this=0x2b651a9d4f90) at Http2Stream.cc:677
#7  0x0000000000607f35 in Http2Stream::terminate_if_possible (this=this@entry=0x2b651a9d4f90) at Http2Stream.cc:372
#8  0x0000000000608072 in Http2Stream::transaction_done (this=0x2b651a9d4f90) at Http2Stream.cc:361
#9  0x00000000005bb4be in HttpSM::kill_this (this=this@entry=0x2b64de8b06c0) at HttpSM.cc:7057
#10 0x00000000005bc3bd in HttpSM::state_api_callback (this=this@entry=0x2b64de8b06c0, event=event@entry=60000, data=data@entry=0x0) at HttpSM.cc:1519
#11 0x00000000004d9379 in TSHttpTxnReenable (txnp=0x2b64de8b06c0, event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5711
#12 0x00002b64a86d6943 in MemberAssignmentRequestContext::process (this=0x2b64da0bf500, url="stickyrouting/stickyrouting/memberBucketAssignments?action=fetch",
result=AtsPluginUtils::FetchResultProcessor::SUCCESS, status=TS_HTTP_STATUS_OK,
body=0x2b64908a0fb9 "{"value":{"lastIssued":1569455728,"expires":1569529305,"userGeneration":105,"coloChangedTime":1569442905,"currentBucket":"TB83","bucketGeneration":2000}}", bodyLen=153) at MemberAssignmentRequestContext.cc:89
#13 0x00002b649927809b in handleFetchEvents (cont=0x2b65f70b09a0, event=10000, edata=0x2b6488420800) at Utils.cc:172
#14 0x00000000004c4323 in INKContInternal::handle_event (this=0x2b65f70b09a0, event=10000, edata=0x2b6488420800) at InkAPI.cc:1012
#15 0x00000000004af96f in handleEvent (data=0x2b6488420800, event=10000, this=) at ../iocore/eventsystem/I_Continuation.h:153
#16 FetchSM::InvokePlugin (this=0x2b6488420800, event=10000, data=0x2b6488420800) at FetchSM.cc:104
#17 0x00000000004b1445 in FetchSM::process_fetch_read (this=this@entry=0x2b6488420800, event=event@entry=104) at FetchSM.cc:479
#18 0x00000000004b1743 in FetchSM::fetch_handler (this=0x2b6488420800, event=104, edata=0x2b6490862548) at FetchSM.cc:525
#19 0x00000000004f0737 in handleEvent (data=0x2b6490862548, event=104, this=) at ../iocore/eventsystem/I_Continuation.h:153
#20 PluginVC::process_read_side (this=this@entry=0x2b6490862438, other_side_call=other_side_call@entry=false) at PluginVC.cc:627
#21 0x00000000004f109a in PluginVC::main_handler (this=0x2b6490862438, event=, data=0x2b6520dd6ba0) at PluginVC.cc:221
#22 0x000000000078d5ad in handleEvent (data=0x2b6520dd6ba0, event=1, this=) at I_Continuation.h:153
#23 EThread::process_event (this=0x2b647d406000, e=0x2b6520dd6ba0, calling_code=1) at UnixEThread.cc:152
#24 0x000000000078e26b in EThread::execute (this=0x2b647d406000) at UnixEThread.cc:206
#25 0x000000000078d04a in spawn_thread_internal (a=0x2b647ab0f220) at Thread.cc:86
#26 0x00002b6478838dc5 in start_thread () from /lib64/libpthread.so.0
#27 0x00002b64798d276d in clone () from /lib64/libc.so.6
{code}
It seems like there's two code paths that can call Http2ClientSession::free() and they could cause a use-after-free symptom.
The crash itself seems to happen because Http2ConnectionState::shutdown_cont_event is garbage. I'm going to try and set shutdown_cont_event = null after calling cancel() inside Http2ConnectionState::destroy() to make sure it's not holding onto garbage reference.
Let me know what you think.

The crash itself seems to happen because Http2ConnectionState::shutdown_cont_event is garbage. I'm going to try and set shutdown_cont_event = null after calling cancel() inside Http2ConnectionState::destroy() to make sure it's not holding onto garbage reference.

+1. it should be set nullptr after canceled.

I'm wondering if it's because HTTP2_SESSION_EVENT_SHUTDOWN_INIT is going through the event loop and therefore can cause a race condition in handling shutdown_cont_event

HTTP2_SESSION_EVENT_SHUTDOWN_INIT is not going through the event loop. It's processed directly via send_connection_event.
On the first stack trace, if destroy is already called and it's the second call, triggering  VC_EVENT_INACTIVITY_TIMEOUT (105) against the session doesn't make sense. I think we need to make sure that a session don't get INACTIVITY_TIMEOUT after destroying it.

I'm wondering if it's because HTTP2_SESSION_EVENT_SHUTDOWN_INIT is going through the event loop and therefore can cause a race condition in handling shutdown_cont_event

HTTP2_SESSION_EVENT_SHUTDOWN_INIT is not going through the event loop. It's processed directly via send_connection_event.

Er, I meant the handling that follows HTTP2_SESSION_EVENT_SHUTDOWN_INIT (not that event itself).
See below.
https://github.com/apache/trafficserver/blob/master/proxy/http2/Http2ConnectionState.cc#L1056

On the first stack trace, if destroy is already called and it's the second call, triggering VC_EVENT_INACTIVITY_TIMEOUT (105) against the session doesn't make sense. I think we need to make sure that a session don't get INACTIVITY_TIMEOUT after destroying it.

I suspect the problem is because of the scheduling of a timer to process the graceful shutdown (see above). I'm going to try and run an ASAN build to see if we can confirm this.

I'm wondering if it's because HTTP2_SESSION_EVENT_SHUTDOWN_INIT is going through the event loop and therefore can cause a race condition in handling shutdown_cont_event

HTTP2_SESSION_EVENT_SHUTDOWN_INIT is not going through the event loop. It's processed directly via send_connection_event.

Er, I meant the handling that follows HTTP2_SESSION_EVENT_SHUTDOWN_INIT (not that event itself).
See below.
https://github.com/apache/trafficserver/blob/master/proxy/http2/Http2ConnectionState.cc#L1056

On the first stack trace, if destroy is already called and it's the second call, triggering VC_EVENT_INACTIVITY_TIMEOUT (105) against the session doesn't make sense. I think we need to make sure that a session don't get INACTIVITY_TIMEOUT after destroying it.

I suspect the problem is because of the scheduling of a timer to process the graceful shutdown (see above). I'm going to try and run an ASAN build to see if we can confirm this.

Following up on this -
I ran an ASAN build on one of our prod boxes for hours and couldn't catch this issue. But, based on the core dump analysis and the code that schedules a delay back to the event loop when handling a shutdown event, I'm fairly positive that this can cause a race condition with potential use-after-free depending on what plugins you may have.
IMO, the fix to reset shutdown_cont_event to nullptr seems reasonable to prevent the use-after-free and as a protection.

I'm fine with setting nullptr to shutdown_cont_event. It wouldn't break anything. However, I still think the root cause is destroy is called multiple times somehow. Your instance may work fine, but we'll lose a hint of the misbehavior (double destroy).

I'm fine with setting nullptr to shutdown_cont_event. It wouldn't break anything. However, I still think the root cause is destroy is called multiple times somehow. Your instance may work fine, but we'll lose a hint of the misbehavior (double destroy).

Like I just explained and showed the stack traces, destroy() isn’t indeed being called twice (one via inactivity timeout and the second via a unblocked stalled transaction) for the same session. It seems to be because of the logic to schedule an event with a delay when trying to gracefully close the stream. I don’t think you can prevent the two code paths from triggering in parallel because of the delay window, but may be shutdown_initiated state can be used to block the second cleanup sequence. Either way, it’s a defensive fix.

@maskit @sudheerv What do we do with this ?

The PR subject should be rephrased at least because destroy() still can be called multiple times. Then I'm ok with landing this.

@zwoop We are running this patch in our prod and haven't seen the same issues since. I can change the title of the PR to say "Protect against destroy() being called more than once per Http2Session".

Yeh, sounds like we should merge this.

Also, is this an 8.0.x candidate ?

Cherry-picked to v9.0.x branch.


some java binding classes have no package name

hi
I tested java client example
iroha/example/javaTransactionExample.java
it is OK, can be luanched at console window.
javaTransactionExample.java file has none package name,
can find some none package name classes
in  iroha-bindings-example.jar :
Transaction.class
Query.class
ByteVector.class
PublicKey.class
......

but when I want to access irohad from a java web application，
not a console base application， my java spring web framework
couldn't find those none package classes (default package class)
in iroha-bindings-example.jar
classes which have package name couldn't find
none package name classes in java.
it is possible to add package name to those none package name
java classes ?
package iroha.xxxx;
thanks

That's possible but unfortunately that will be not enough. Actually all class names, method names etc should contain package prefix inside shared library (libirohajava,so or libirohajava.jni). That means that shared library should also be recompiled for every package name.
Any non-empty package name will be fine for you, right? Please correct me if I'm wrong.

hi, @luckychess thank you.
Yes，that is what i want,
you are right, i added package name to those none package name classes
in iroha-bindings-example.jar, but that does not work.
How to add package name and recompile the libirohajava.so ?
Do you have any instructive document for my reference?
thanks

I found a file for reference:
iroha/shared_model/packages/android/android-build.sh
and modified the CMakeLists.txt file
	diff CMakeLists.txt CMakeLists.txt.bak
		68c68
		<     SET(CMAKE_SWIG_FLAGS ${CMAKE_SWIG_FLAGS} -package sun)
		---
		>     find_package(JNI REQUIRED)

thanks

@walkero thank you for your great job! Could you please open a PR with those changes, maybe it makes sense to add them directly to Iroha? (Don't forget to sign your commits with DCO though github.com/apps/dco and describe changes)

@walkero if you have any problems with it – we are glad to help. To make things faster, you can use https://gitter.im/hyperledger-iroha/Lobby or in https://chat.hyperledger.org/channel/iroha :)


udev not in system logs

RancherOS Version: (ros os version)
1.2.0
Where are you running RancherOS? (docker-machine, AWS, GCE, baremetal, etc.)
baremetal
udevd running in the udev system container does its logging via /proc/kmsg. Currently in order to view the udevd logs it is necessary to execute dmesg.
It would be nice if these logs were available in the output of
sudo ros service logs udev

as well as via syslog. This probably also applies to udev-cold.

#850 could have used this information.


Refactor API tests

Summary

This refactor adds tests for all supported OIDC types, and makes it
simpler to add new tests for new OIDC types.

Add tests for K8s and GitHub OIDC types.
Add additional verification for issued certificate values
Add dedicated test for RootCert success, don't call RootCert in every test.
Move common expectations to function. This provides a single place to
check response values.
Move common set up to dedicated functions.
Lowercase all error messages, because style.

Once #463 is submitted, I'll rebase.
Signed-off-by: Hayden Blauzvern<EMAIL_ADDRESS>Ticket Link

Fixes
Release Note

NONE

Codecov Report

Merging #483 (a87f0f4) into main (8bc09cf) will increase coverage by 0.75%.
The diff coverage is 55.88%.

@@            Coverage Diff             @@
##             main     #483      +/-   ##
==========================================
+ Coverage   46.87%   47.63%   +0.75%
==========================================
  Files          14       14
  Lines        1024     1056      +32
==========================================
+ Hits          480      503      +23
- Misses        476      480       +4
- Partials       68       73       +5

Impacted Files
Coverage Δ

pkg/config/config.go
51.90% <ø> (ø)

pkg/challenges/challenges.go
22.18% <53.12%> (+3.40%)
:arrow_up:

pkg/api/ca.go
50.56% <100.00%> (+3.97%)
:arrow_up:

Continue to review full report at Codecov.

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


implement Merton Jump-diffusion Model

Codecov Report

Merging #585 (c695c5a) into main (a5ba9d0) will increase coverage by 0.04%.
The diff coverage is 98.57%.

@@            Coverage Diff             @@
##             main     #585      +/-   ##
==========================================
+ Coverage   97.17%   97.21%   +0.04%
==========================================
  Files          56       58       +2
  Lines        2333     2403      +70
==========================================
+ Hits         2267     2336      +69
- Misses         66       67       +1

Impacted Files
Coverage Δ

pfhedge/instruments/primary/merton_jump.py
97.91% <97.91%> (ø)

pfhedge/instruments/__init__.py
100.00% <100.00%> (ø)

pfhedge/stochastic/__init__.py
100.00% <100.00%> (ø)

pfhedge/stochastic/merton_jump.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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

マージの影響でdiffがすごく大きくなっているように見えるんですが、これって修正難しいですか？

diff小さくしました．大変失礼いたしました． >> @imos


Mock call to google servers

Description:
Fix for test calling off to google servers

@balloob fixed!


Windows 10 Taskbar icon displays track playing as file downloading

Just upgraded to version 4.6.1.
When a track is playing, the Windows 10 Taskbar icon changes color as a track plays, just as it does when a large file is downloading on Chrome, with the icon turning green from left to right:

You will have turned this feature on in Desktop Settings, if you don't like it you can turn it back off again 😀


Api 28 update

this is a new pull request

This PR looks like it was opened by mistake.  Closing.


Is there has a general way to hide the right part when the window size is not enough?

My vim status line looks like this:

But I want to hide the right part of lightline when I open the files tree, (only show the mode component).
So Is there has a general way to hide the right part when the window size is not enough or open some special file type?

Based on https://github.com/itchyny/lightline.vim/issues/193#issuecomment-252462678, I believe the best you can do is to use component functions that return empty string for the (assumed) NERDTree buffer.

ok, it's a nice hint. and really appreciate the super-fast response.

https://github.com/itchyny/lightline.vim#can-i-trim-the-file-format-and-encoding-information-on-narrow-windows


Update Gemfile.lock

Versions of uglify-js prior to 2.4.24 are affected by a vulnerability which may cause crafted JavaScript to have altered functionality after minification.

[ ] Tests written and linted ℹ
[ ] Documentation written ℹ
[ ] Commit history is tidy ℹ

What this does
Explain why this PR exists
Notes for the reviewer
Instructions on how to run this locally, background context, what to review, questions…
More information

Jira ticket XX-0000
Link to documentation

Screenshots
Visuals that may help the reviewer

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


Sparkling Grid Dots not working properly in 'system' theme

Describe the bug
Sparkling Grid not working properly when you are using the theme dynamically from next-themes since it can return also system, not only light or dark, I suggest using tailwind dark: selector instead of the having the theme as prop
To Reproduce
Have your system in darkmode and open the component doc page or UiBeats homepage with incognito without interacting with the dark-light mode button

Thanks for pointing it out @ebulku, will be fixing it soon, if reproducible 💯

Fixed with the recent commits (for other components as well). Thank you so much for highlighting this :)


feat: Added OpenAPI metadata to version docs (#38)

Pull Request Checklist

[x] Make sure to read the contributor guide here.
[x] Make sure you are making a pull request against the main branch.
[x] Make sure your pull request title matches the requested format.
[x] Make sure to lint, type-check, and run unit and API tests.

Description
closes #38
My first try looked like this:
            async def get_openapi() -> Any:
                openapi_args = {
                    'title': title,
                    'version': version_str,
                    'routes': router.routes,
                    'description': self._app.description,
                    'terms_of_service': self._app.terms_of_service,
                    'contact': self._app.contact,
                    'license_info': self._app.license_info,
                }
                if hasattr(self._app, 'summary'):
                    # Available since OpenAPI 3.1.0, FastAPI 0.99.0
                    openapi_args['summary'] = self._app.summary
                return fastapi.openapi.utils.get_openapi(**openapi_args)

But mypy didn't like that:
fastapi_versionizer/versionizer.py:231: error: Argument 1 to "get_openapi" has incompatible type "**dict[str, Sequence[object] | dict[str, str | Any] | None]"; expected "str"  [arg-type]
fastapi_versionizer/versionizer.py:231: error: Argument 1 to "get_openapi" has incompatible type "**dict[str, Sequence[object] | dict[str, str | Any] | None]"; expected "str | None"  [arg-type]
fastapi_versionizer/versionizer.py:231: error: Argument 1 to "get_openapi" has incompatible type "**dict[str, Sequence[object] | dict[str, str | Any] | None]"; expected "Sequence[BaseRoute]"  [arg-type]
fastapi_versionizer/versionizer.py:231: error: Argument 1 to "get_openapi" has incompatible type "**dict[str, Sequence[object] | dict[str, str | Any] | None]"; expected "Sequence[BaseRoute] | None"  [arg-type]
fastapi_versionizer/versionizer.py:231: error: Argument 1 to "get_openapi" has incompatible type "**dict[str, Sequence[object] | dict[str, str | Any] | None]"; expected "list[dict[str, Any]] | None"  [arg-type]
fastapi_versionizer/versionizer.py:231: error: Argument 1 to "get_openapi" has incompatible type "**dict[str, Sequence[object] | dict[str, str | Any] | None]"; expected "list[dict[str, str | Any]] | None"  [arg-type]
fastapi_versionizer/versionizer.py:231: error: Argument 1 to "get_openapi" has incompatible type "**dict[str, Sequence[object] | dict[str, str | Any] | None]"; expected "dict[str, str | Any] | None"  [arg-type]
fastapi_versionizer/versionizer.py:231: note: "Dict" is invariant -- see https://mypy.readthedocs.io/en/stable/common_issues.html#variance
fastapi_versionizer/versionizer.py:231: note: Consider using "Mapping" instead, which is covariant in the value type
fastapi_versionizer/versionizer.py:231: error: Argument 1 to "get_openapi" has incompatible type "**dict[str, Sequence[object] | dict[str, str | Any] | None]"; expected "bool"  [arg-type]
Found 8 errors in 1 file (checked 9 source files)

So this solution is a bit easier. I hope you still like it. 😃

@worldworm Sorry, one last request. Can you update the "simple" test/example to include some of these fields so we can make sure this case has proper test coverage?

Sure, that's a good idea.
I have added description and termsOfService. I think they look better than a license_info or your name as a contact. 😄
I thought about checking the summary attribute, but having a version dependency in the test case doesn't look "simple.py" to me. Hope you are fine with my pick.

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


question about test

I meet the following problem
Traceback (most recent call last):
File "CAMixerSR/codes/basicsr/test.py", line 12, in
test_pipeline(root_path)
File "CAMixerSR/codes/BasicSR/basicsr/test.py", line 40, in test_pipeline
model.validation(test_loader, current_iter=opt['name'], tb_logger=None, save_img=opt['val']['save_img'])
File "CAMixerSR/codes/BasicSR/basicsr/models/base_model.py", line 48, in validation
self.nondist_validation(dataloader, current_iter, tb_logger, save_img)
File "CAMixerSR/codes/BasicSR/basicsr/models/sr_model.py", line 245, in nondist_validation
self.metric_results[metric] /= (idx + 1)
UnboundLocalError: local variable 'idx' referenced before assignment

This issue might be due to having no validation data while still needing to calculate metrics. You could either remove the part that calculates metrics from the yml file or check the path to your validation data to make sure it's not empty.


Fixes: nl-nl translation errors

Describe your changes:
Fixes n/a

I updated the nl-nl localization file. The previous file contained some translation errors.

Type of change:

[x] Bug fix
[ ] Improvement
[ ] New feature
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation

Checklist:

[x] I have read the CONTRIBUTING document.
[x] My PR title is Fixes <issue-number>: <short explanation>
[ ] I have commented on my code, particularly in hard-to-understand areas.
[ ] For JSON Schema changes: I updated the migration scripts or explained why it is not needed.

Great work @sandervanlaar  🙌🏻, Thanks for the contributions ✨


Dnsmasq domain override not used for static hostnames

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues and I'm convinced that mine is new.
Description
It is possible to specify domain override in Dnsmasq configuration. The specified domain is used only for dynamic DHCP leases, while for static the system domain is used.
To Reproduce
Steps to reproduce the behavior:

Go to Services -> Dnsmasq DNS -> Settings
Configure Domain override
Apply settings.

Actual behavior
cat /var/etc/dnsmasq-hosts
<IP_ADDRESS>   ap1.home.local ap1
[...]
# dhcpleases automatically entered
<IP_ADDRESS>  some-host.home.old some-host            # dynamic entry from dhcpd.leases

Expected behavior
Both hosts use the same domain (home.old in this example).
Environment
OPNsense 20.7.5-amd64
FreeBSD 12.1-RELEASE-p10-HBSD
OpenSSL 1.1.1h 22 Sep 2020
Possible solution
At first I forked core repo and committed this change. I didn't want to create a PR without confirming that this is a bug (and I think it is). If my solution looks OK, I am happy to create a PR.

@jmatraszek the link (https://github.com/jmatraszek/core/commit/466a71b9097cad947acdf22b46fae875d9a0da470) returns a 404, if you want to discuss the proposed change from a PR that's also ok by the way.

Oh, sorry. I've created a PR now — #4539.

https://github.com/opnsense/core/commit/1adefd7440efc245360290017250be4c8aa6ec2b


Random "Cannot write index/EOM" errors when unmounting sync_type=unmount tape

Describe the bug
Sometimes, when unmounting a cartridge (mounted with sync_type=unmount) that has been completely filled so it has dropped to read-only, the index will fail to write because the drive seems to reach the end of the partition/medium. I have compression enabled, although I'm writing only files that cannot be much compressed by the drive.
To Reproduce
Steps to reproduce the behavior:

Create a tape, mount it with -o sync_type=unmount and write files to it until the tape is full and drops to read-only
Unmount the tape

Expected behavior
The index is written successfully and the tape is unmounted.
Unmount logs

f5479 LTFS17235I Writing index of LT0011 to b (Reason: Unmount, 503 files) xxx.
f5479 LTFS30222W Received low space warning (early warning) in write filemarks.
f5479 LTFS30222W Received low space warning (early warning) in write.
f5479 LTFS30222W Received low space warning (early warning) in write.
f5479 LTFS30222W Received low space warning (early warning) in write.
[above repeated 50 times]
f5479 LTFS30205I WRITEFM (0x10) returns -21300.
f5479 LTFS30263I WRITEFM returns End-of-Partition/Medium Detected (-21300) /dev/sg1.
f5479 LTFS12047E Cannot write file marks: backend call failed (-21300). Dropping to read-only mode.
f5479 LTFS11084E Cannot write index: failed to write a trailing file mark (-21300). The medium is in an inconsistent state; unmount and run ltfsck.
f5479 LTFS11083E Cannot write index: failed to generate and write XML data (-21300). The medium might be in an inconsistent state; unmount and run ltfsck.
f5479 LTFS17235I Writing index of LT0011 to a (Reason: Unmount, 503 files) xxx.
f5479 LTFS11082E Cannot write index: failed to write file mark (-1126).
f5479 LTFS11033E Cannot unmount: failed to write an index.
f5479 LTFS30205I MODESENSE (0x5a) returns -20501.
f5479 LTFS30263I MODESENSE returns Invalid Field in CDB (-20501) /dev/sg1.

Successful mount logs

1e1055 LTFS14000I LTFS starting, LTFS version <IP_ADDRESS> (10470), log level 2.
1e1055 LTFS14058I LTFS Format Specification version 2.4.0.
1e1055 LTFS14104I Launched by "ltfs -o devname=/dev/sg1 -o sync_type=unmount -f /mnt/ltfs/".
1e1055 LTFS14105I This binary is built for Linux (x86_64).
1e1055 LTFS14106I GCC version is 11.1.0.
1e1055 LTFS17087I Kernel version: Linux version 5.10.84-1-lts (linux-lts@archlinux) (gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP Wed, 08 Dec 2021 10:17:01 +0000 i386.
1e1055 LTFS17089I Distribution: NAME="Arch Linux".
1e1055 LTFS17089I Distribution: LSB_VERSION=1.4.
1e1055 LTFS17089I Distribution: .
1e1055 LTFS14064I Sync type is "unmount".
1e1055 LTFS17085I Plugin: Loading "sg" tape backend.
1e1055 LTFS17085I Plugin: Loading "unified" iosched backend.
1e1055 LTFS14095I Set the tape device write-anywhere mode to avoid cartridge ejection.
1e1055 LTFS30209I Opening a device through sg-ibmtape driver (/dev/sg1).
1e1055 LTFS30250I Opened the SCSI tape device <IP_ADDRESS> (/dev/sg1).
1e1055 LTFS30207I Vendor ID is HP      .
1e1055 LTFS30208I Product ID is Ultrium 5-SCSI  .
1e1055 LTFS30214I Firmware revision is I57H.
1e1055 LTFS30215I Drive serial is xxx.
1e1055 LTFS30285I The reserved buffer size of /dev/sg1 is 1048576.
1e1055 LTFS30294I Setting up timeout values from RSOC.
1e1055 LTFS17160I Maximum device block size is 1048576.
1e1055 LTFS11330I Loading cartridge.
1e1055 LTFS39805W The timeout table is not configured: SCSI OP code 0x4d. Use the default timeout.
1e1055 LTFS11332I Load successful.
1e1055 LTFS39805W The timeout table is not configured: SCSI OP code 0x4d. Use the default timeout.
1e1055 LTFS17157I Changing the drive setting to write-anywhere mode.
1e1055 LTFS11005I Mounting the volume.
1e1055 LTFS39805W The timeout table is not configured: SCSI OP code 0x4d. Use the default timeout.
1e1055 LTFS39805W The timeout table is not configured: SCSI OP code 0x4d. Use the default timeout.
1e1055 LTFS30205I MODESENSE (0x5a) returns -20501.
1e1055 LTFS30263I MODESENSE returns Invalid Field in CDB (-20501) /dev/sg1.
1e1055 LTFS39805W The timeout table is not configured: SCSI OP code 0x4d. Use the default timeout.
1e1055 LTFS39805W The timeout table is not configured: SCSI OP code 0x4d. Use the default timeout.
1e1055 LTFS17227I Tape attribute: Vendor = IBM     .
1e1055 LTFS17227I Tape attribute: Application Name = LTFS                            .
1e1055 LTFS17227I Tape attribute: Application Version = <IP_ADDRESS> .
1e1055 LTFS17227I Tape attribute: Medium Label = .
1e1055 LTFS17228I Tape attribute: Text Localization ID = 0x81.
1e1055 LTFS17227I Tape attribute: Barcode = LT0011                          .
1e1055 LTFS17227I Tape attribute: Application Format Version = 2.4.0           .
1e1055 LTFS17228I Tape attribute: Volume Lock Status = 0x00.
1e1055 LTFS17227I Tape attribute: Media Pool name = .
1e1055 LTFS11031I Volume mounted successfully. LT0011 : Gen = 3 / (a, 5) -> (b, 2975316) / xxx.
1e1055 LTFS14111I Initial setup completed successfully.
1e1055 LTFS14112I Invoke 'mount' command to check the result of final setup.
1e1055 LTFS14113I Specified mount point is listed if succeeded.
1e1696 LTFS14029I Ready to receive file system requests.

Additional context
The index can sometimes be recovered by running ltfsck -l, which rewrites the index and may succeed straight away. I have not reproduced the issue with default sync_type for now, however I'm not sure whether the issue may only happen with sync_type=unmount.
My drive is a HP Ultrium 5-SCSI FH with firmware I57H, the tape make this last happened with is Quantum.
Version
ltfsck version <IP_ADDRESS> (10470).
LTFS Format Specification version 2.4.0.
Thank you for any help!

Interesting.
It looks LTFS receives early warning at writing the first FM of an index. And this HP drive returns end-of-medium just after 50 writes when early warning is reported. LTFS writes a record with 512KiB. So it means HP drive reports early warning just before 30 MiB at most.

Could you provide a the log before f5479 LTFS17235I Writing index of LT0011 to b (Reason: Unmount, 503 files) xxx. ? I need to check the second line of your unmount log is the first report of early warning.
It looks your index is slightly long. Do you know why the index has such capacity?

Do you use long file name?
Do you store something into extended attribute?

These are the log lines printed when the write fails due to the tape being full and the tape goes to read-only:
f5649 LTFS30222W Received low space warning (early warning) in write.
f5649 LTFS11072E Cannot write blocks: failed to write to the medium (-1051).
f5649 LTFS11077E Cannot write: failed to write blocks to the medium (-1051).
f5649 LTFS13014W Data partition writer: failed to write data to the tape (-1051).

Then the unmount log starts when I umount the tape.
Filenames are 45 characters long on average and files have no extended attributes. There are 503 files on this specific tape as it was filled in one go.

Thanks for the information. I have since opening this issue written 7 Fujifilm and HP tapes and have not had this issue (similar filenames and file count), so I'm not sure whether this issue only reproduces with Quantum tapes. I want to add the tape I had this issue with was on its first write after being formatted.

Generally, tape has a kind of spare capacity to write down data to meet the LTO spec. And usually, LTO drive returns early warning when some amount of data is written.
So drive might return early warning at the very close to the tape end, if write quality is not good. I guess your quantum tapes would not have a good performance against your tape. R/W quality stuff is so much complicated, I recommend to use HP's media because they might adjust their tape head to their tape.
I know LTO has a kind of compatibility but it doesn't mean every drives can use every tapes with the best quality.


sudo yum update returns a checksum error

==> ps-vagabond: Loaded plugins: ulninfo
==> ps-vagabond: http://public-yum.oracle.com/repo/OracleLinux/OL7/UEKR3/x86_64/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum
==> ps-vagabond: Trying other mirror.
==> ps-vagabond: http://public.yum.oracle.com/repo/OracleLinux/OL7/UEKR3/x86_64/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum
==> ps-vagabond: Trying other mirror.
==> ps-vagabond:
==> ps-vagabond:
==> ps-vagabond:  One of the configured repositories failed (Latest Unbreakable Enterprise Kernel Release 3 for Oracle Linux 7Server (x86_64)),
==> ps-vagabond:  and yum doesn't have enough cached data to continue. At this point the only
==> ps-vagabond:  safe thing yum can do is fail. There are a few ways to work "fix" this:
==> ps-vagabond:
==> ps-vagabond:      1. Contact the upstream for the repository and get them to fix the problem.
==> ps-vagabond:
==> ps-vagabond:      2. Reconfigure the baseurl/etc. for the repository, to point to a working
==> ps-vagabond:         upstream. This is most often useful if you are using a newer
==> ps-vagabond:         distribution release than is supported by the repository (and the
==> ps-vagabond:         packages for the previous distribution release still work).
==> ps-vagabond:
==> ps-vagabond:      3. Disable the repository, so yum won't use it by default. Yum will then
==> ps-vagabond:         just ignore the repository until you permanently enable it again or use
==> ps-vagabond:         --enablerepo for temporary usage:
==> ps-vagabond:
==> ps-vagabond:             yum-config-manager --disable ol7_UEKR3
==> ps-vagabond:
==> ps-vagabond:      4. Configure the failing repository to be skipped, if it is unavailable.
==> ps-vagabond:         Note that yum will try to contact the repo. when it runs most commands,
==> ps-vagabond:         so will have to try and fail each time (and thus. yum will be be much
==> ps-vagabond:         slower). If it is a very temporary problem though, this is often a nice
==> ps-vagabond:         compromise:
==> ps-vagabond:
==> ps-vagabond:             yum-config-manager --save --setopt=ol7_UEKR3.skip_if_unavailable=true
==> ps-vagabond:
==> ps-vagabond: failure: repodata/primary.xml.gz from ol7_UEKR3: [Errno 256] No more mirrors to try.
==> ps-vagabond: http://public-yum.oracle.com/repo/OracleLinux/OL7/UEKR3/x86_64/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum

To manually resolve the issue, I updated the /etc/yum.repos.d/public-yum-ol7.repo by hand. This was in version 0.0.4 of the vagrant box.

sudo rm /etc/yum.repos.d/public-yum-ol7.repo
cd /etc/yum.repos.d
wget http://public-yum.oracle.com/public-yum-ol7.repo

I wasn't able to get a re-creation case on this, but I think it may be related to the recent transition of OEL 7.2 to 7.3.  I experienced an almost identical error when trying to provision a CentOS 7.2 VM.
At any rate, I went ahead and upgraded the Vagrant box to use OEL 7.3 - so running vagrant box update should upgrade bring it up to date.
C:\pum_images\fscm92
λ vagrant box outdated
Checking if box 'jrbing/ps-vagabond' is up to date...
A newer version of the box 'jrbing/ps-vagabond' is available! You currently
have version '0.0.4'. The latest is version '1.0.0'. Run
`vagrant box update` to update.

C:\pum_images\fscm92
λ vagrant box update
==> ps-vagabond: Checking for updates to 'jrbing/ps-vagabond'
    ps-vagabond: Latest installed version: 0.0.4
    ps-vagabond: Version constraints:
    ps-vagabond: Provider: virtualbox
==> ps-vagabond: Updating 'jrbing/ps-vagabond' with provider 'virtualbox' from version
==> ps-vagabond: '0.0.4' to '1.0.0'...
==> ps-vagabond: Loading metadata for box 'https://atlas.hashicorp.com/jrbing/ps-vagabond'
==> ps-vagabond: Adding box 'jrbing/ps-vagabond' (v1.0.0) for provider: virtualbox
    ps-vagabond: Downloading: https://atlas.hashicorp.com/jrbing/boxes/ps-vagabond/versions/1.0.0/providers/virtualbox.box
    ps-vagabond: Progress: 100% (Rate: 18.8M/s, Estimated time remaining: --:--:--)
==> ps-vagabond: Successfully added box 'jrbing/ps-vagabond' (v1.0.0) for 'virtualbox'!

C:\pum_images\fscm92


Feature/Sort kata solutions by runtime execution

It would be great if in kata solutions would be an opportunity sort by runtime execution.

This has been brought up many times before and it doesn't work on CW at all, not to mention it's a bad idea, because:

CW does not have a tightly controlled runtime environment, it's run on docker containers on cloud. Whatever result you get cannot be called a benchmark if they're not run on the same machine in the same condition
Katas don't use a set of fixed test cases but rely on random tests to ensure correctness, so by nature every run will give a different runtime. If you want 0.1% uncertainly with 99% confidence statistically you have to run the same code for about 4 million times. Good luck with that
In the end, what does it achieve anyway? The commonly stated purpose is along the lines of "get rid of this short, 'clever', UUN but O(n^2) instead of O(n) solution that I don't like from the top solutions list", but it'd be extremely problematic if a criteria is invented just because some people don't like short code; not to mention that shooting at these solutions is not solving their problems at all since what they actually wanted is solutions that is UUN, which is not solution that is the fastest. CW's not an OJ site (it'd be a pretty terrible one if it was) either, and even along that line nobody likes OJ problems that encourages/mandates micro-optimizations because they're mostly pointless.

Hi, @Voileexperiments! Thank for your detail answer. This problem became more clear for me, and now I absolutely agree with your point of view.


Add impersonation to gcp operators

Make sure to mark the boxes below before creating PR: [x]

[ ] Description above provides context of the change
[ ] Unit tests coverage for changes (not needed for documentation changes)
[ ] Target Github ISSUE in description if exists
[ ] Commits follow "How to write a good git commit message"
[ ] Relevant documentation is updated including usage instructions.
[ ] I will engage committers as explained in Contribution Workflow Example.

In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.
Read the Pull Request Guidelines for more information.

Can you

@turbaszek, yes I working on it.

@olchas should we do this in a follow up PR? @mik-laj wdyt? There's already a lot of changes

Yes. We can split it into smaller chunks.

I knew that in some classes you added a parameter description, and in others you did not.  What criterion did you have?

Yes. We can split it into smaller chunks.

In that case maybe I should rename this branch to add-impersonation-to-gcp-hooks?

I knew that in some classes you added a parameter description, and in others you did not. What criterion did you have?

I was trying to remain consistent with current state of hooks - some of them already contained description of parameters in their docstrings (in case of which I was adding description of new parameter), while other did not (in case of them I was leaving the docstring unchaged).

In that case maybe I should rename this branch to add-impersonation-to-gcp-hooks?

Up to you, we don't have any branch naming convention :<


armor break particle effect

I need to be able to add a particle effect when the superarmor bar deplate

Use OnStop event inside SuperArmorEffect together with Particles


Fix travis builds

All travis builds fail.
6 different compilers 2000 CRW each. 12000 CRW Total

Fixed !

Address for payment: 1nfernow9yCJGQN6RxvpA13y9HjNGvgDw
Post transaction ID when payment has been made. You guys can decide on the total payment. Transaction ID for proof bounties are being paid.


feat: use member field instead of hard-code

fix #1451 It's better to use member filed self.positive_label than hard code to 1.

@Adel-Moumen Hi this PR aims to address issue #1451

Lgtm.


mba: making MBA policy parser and checker pluggable

Pluggable MBA theory of operations
The module keylime/mba/mba provides an interface for measured boot attestation verification that consists of four functions.

bootlog_parse()

converts a boot log from binary to JSON.
authenticates the log by checking the consistency of its digests.
provides a set of PCRs that can be verified against the TPM quote.
provides a boot aggregate for use by Keylime IMA verification.

policy_load()

load a policy from a file into a Python string
optionally validate that the policy is syntactically correct (this is TBD)

policy_is_valid()

test whether a string is valid policy

bootlog_evaluate()

check the parsed boot log against the loaded policy, and return a list of policy failures.

A default implementation for all four functions is predefined in Keylime, and is backwards compatible (i.e. this is not a breaking change). The functions are implemented in keylime/mba/elparsing and keylime/mba/elchecking respectively.
However, these functions can be overridden by specifying a list of modules to load in the configuration option verifier.measured_boot_imports. Upon initialization MBA loads the modules as specified by the verifier option. These modules can contain implementations of the four functions above.
At runtime keylime chooses the active implementation for each of the functions described above by enumerating the ordered list of imported modules and picking the first implementation of the function it can find.

@aplanas can we talk briefly on Slack CNCF? Thanks!

@galmasi I think that if you rebase, the failing test should disappear


remote url appending browserName chrome - causing issues for non-chrome tests

When tests are being pushed up to a remote instance, the capability browserName: chrome  is automatically added. This creates an issue when testing for something like iOS Safari on a remote instance because the remote grid receives two browerName caps.
If I'm reading this right, it looks like it defaults to chrome in the config.py file.

In the webdriver_factory.py file, it seems to run through the logic of these browsers, but if it's not detected then it raises an exception.

Scrolling down a bit in the webdriver_factory.py, the build_remote() builds the remote driver to send to the grid and uses the build_options() function defined earlier.

I think there's two things which are conflicting here:

remote_url is appending the capability browserName with chrome. I'd think that this would be set explicitly when using a remote driver.
The logic for the build_options() in webdriver_factory.py should be adjusted so this doesn't fail if it's chrome, firefox, IE, oprea, edge.

@ElSnoMan Thanks for the fast response. I'm not sure what the best method for showing this information but I'll try to provide screenshots / details below
For context, I'm using LambdaTest for device testing. To start the test, I've got a shell script that I'm running which has the remote_url parameter set and the path to the test. Example: run_mobile_scroll_screenshot.sh
#!/usr/bin/env bash

<EMAIL_ADDRESS>
FILTER="tests/screenshots/test_mobile_scroll_screenshot.py"

pytest $FILTER --remote_url=$REMOTE_URL -s

In my pylenium.json file I've got the following
{
    "driver": {
        "remote_url": "",
        "wait_time": 10,
        "page_load_wait_time": 0,
        "options": [],
        "capabilities": {
            "build": "Site Name Test",
            "name": "PyTest Build Testing run",
            "console": true,
            "network": true,
            "video": true,
            "visual": true

        },
        "experimental_options": null,
        "extension_paths": [],
        "local_path": ""
    },
    "logging": {
        "screenshots_on": false,
        "pylog_level": "debug"
    },
    "viewport": {
        "maximize": true,
        "width": 1440,
        "height": 900,
        "orientation": "portrait"
    },
    "custom": {
        "urls": [
            "URL_HERE..."
        ],
        "caps": {
            "desktop": [
                {
                    "browserName": "Safari",
                    "version": "14.0",
                    "platform": "MacOS Big sur",
                    "resolution": "2560x1440"
                },
                {
                    "browserName": "Safari",
                    "version": "14.0",
                    "platform": "MacOS Big sur",
                    "resolution": "1920x1080"
                },
                {
                    "browserName": "Chrome",
                    "version": "89.0",
                    "platform": "Windows 10",
                    "resolution": "1366x768"
                },
                {
                    "browserName": "Chrome",
                    "version": "89.0",
                    "platform": "Windows 10",
                    "resolution": "1366x768"
                }
            ],
            "mobile": [
                {
                    "platformName": "iOS",
                    "deviceName": "iPhone 12",
                    "platformVersion": "14.2",
                    "appiumVersion": "1.19.1",
                    "w3c": true
                },
                {
                    "platformName": "Android",
                    "deviceName": "Galaxy S20 Plus",
                    "platformVersion": "10",
                    "appiumVersion": "1.17.1",
                    "w3c": true
                }
            ]
        }
    }
}

My script loops through each browser under the mobile capabilities. Let me know if there's anything additional I can provide.

No activity on this issue for some time, so closing it out.


Engine Bump for Feb insiders

[x] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
[x] Title summarizes what is changing.
[ ] Appropriate comments and documentation strings in the code.
[ ] Has sufficient logging.
[ ] Has telemetry for feature-requests.
[ ] Unit tests & system/integration tests are added/updated.
[ ] Test plan is updated as appropriate.
[x] package-lock.json has been regenerated by running npm install (if dependencies have changed).

Disabling auto-merge to address test failure. cc/ @DonJayamanne


Investigate flaky tests

Tests are really flaky in this project.
I think most of them are because of I/O, timers and reconnects.
They should be investigated and fixed

cc @marco-ippolito

Ill look into it

still flaky: https://github.com/mercurius-js/mercurius-gateway/actions/runs/4023965438/jobs/6915447409#step:5:1367

I'll try another approach on this test probably it's better to rewrite it completely.

Possibly related/FYI:
Tests in our application warn with A worker process has failed to exit gracefully and has been force exited. This is likely caused by tests leaking due to improper teardown. Try running with --detectOpenHandles to find leaks. Active timers can also cause this, ensure that .unref() was called on them.
This happens when we have reconnect enabled:
            wsConnectionParams: {
              reconnect: true,

We're disabling reconnects during tests as a workaround for the time being.


Add post (blog) json-ld schema

https://developers.google.com/search/docs/advanced/structured-data/article

Done


python310Packages.pyoverkiz: 1.7.7 -> 1.7.8

Changelog: https://github.com/iMicknl/python-overkiz-api/releases/tag/v1.7.8
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

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

3 packages built:

home-assistant-component-tests.overkiz
python310Packages.pyoverkiz
python311Packages.pyoverkiz


Android changes for 1.2.4 patch

Related Issue
Contains fixes:

Issue
Issue #
PR #

Button icons placed on the left of the title are pushed out of the button, icon size not honored
#3543
https://github.com/microsoft/AdaptiveCards/pull/3547

Spacing within Choice sets not rendered
#3554
https://github.com/microsoft/AdaptiveCards/pull/3594

Newline Character ("\n") inside TextBlock not rendered
#3531
https://github.com/microsoft/AdaptiveCards/pull/3599

For Choice sets with compact style, when no option is explicitly pre-selected, first option gets pre-selected
#3605
https://github.com/microsoft/AdaptiveCards/pull/3615

Microsoft Reviewers: Open in CodeFlow

/azp run


Go to definition goes to the wrong place

https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/scm/electron-browser/scmViewlet.ts#L667
Try Cmd clicking on SCMMenuItemActionItem. It should go to
https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/scm/electron-browser/scmViewlet.ts#L61
but goes to
https://github.com/Microsoft/vscode/blob/master/src/vs/platform/actions/browser/menuItemActionItem.ts#L99

This is correct. For new expressions, go to definition jumps to the constructor. As SCMMenuItemActionItem does not implement its own constructor, we open the parent class constructor.
Go to type definition will jump to the class itself.

I understand why it happens. But I don't think it is the correct behaviour. It should jump to SCMMenuItemActionItem regardless of whether it has overridden the ctor.

No, this really is how the feature is designed to work. For new expression we always jump to the constructor definition itself. This lookup behaves like it would for any overridable method in that is jumps to the actual implementation of that method instead of to a subclass


Optimised line intersection by adding two simple prechecks.

I added two simple checks to the line intersection function.
This avoids calculating intersections with edges that arent in the minimal rectangle containing fragmentTexCoord and lightPos.
The change should make the algorithm faster, altho I dont know how to test that.

Hi @marmottchen! Thank you very much!! I created a script for benchmarking the code, here. Somehow, I found that the code with the two checks is a bit slower than the old version. Look at the outputs below. Avg. mspt means how many milliseconds it takes to render one frame on average.
My guess is that since the values calculated for the checks are not used later in the function, we ultimately lose more time than we save. Anyway, I still think doing the two checks is smart, but maybe we need to do this strategically? Any ideas?
Btw, if you try to run the benchmarks you will probably get the error _moderngl.Error: out of range offset = 0 or size = 6400. You need this fix (it just allocates more memory).
OLD code
======== Benchmark 0 ========
lights: 10, hulls: 10, vertices per hull: 4
running...
Avg. mspt: 0.7299156188964844

======== Benchmark 1 ========
lights: 200, hulls: 1, vertices per hull: 3
running...
Avg. mspt: 4.665932655334473

======== Benchmark 2 ========
lights: 10, hulls: 200, vertices per hull: 4
running...
Avg. mspt: 7.464873790740967

======== Benchmark 3 ========
lights: 200, hulls: 200, vertices per hull: 4
running...
Avg. mspt:<PHONE_NUMBER>38208

NEW code
======== Benchmark 0 ========
lights: 10, hulls: 10, vertices per hull: 4
running...
Avg. mspt: 0.7444717884063721

======== Benchmark 1 ========
lights: 200, hulls: 1, vertices per hull: 3
running...
Avg. mspt: 4.6094441413879395

======== Benchmark 2 ========
lights: 10, hulls: 200, vertices per hull: 4
running...
Avg. mspt: 7.780803839365642

======== Benchmark 3 ========
lights: 200, hulls: 200, vertices per hull: 4
running...
Avg. mspt:<PHONE_NUMBER>2365112

My idea was to eliminate edges that are clearly not going to intersect by observing the rectangles for which they are the diagonals. Like boxes around the edges.
I guess the original calculation isnt expensive enough for this to make a difference tho.
We could try the same idea a step higher up with the hulls.
I am thinking that when defining a hull, we calculate the bounding rectangle and save it as another attribute.
Then when we do checks, before checking the edges of a hull, we check against the bounding box of the light edge.
I can try to adapt the code on the weekend, altho I dont know how to give the shader the additional hull information.
Could you maybe explain how one would go about giving the shader an additional 4 values per hull ?

That seems like a great idea. There's one catch, hull data can change from frame to frame, because it's useful to have movable hulls in a game. So, we need to compute the bounding boxes every frame. This may be worth it tho, especially if we cache the bounding boxes, since we can expect that most hulls won't change.
For sending this data to the shader, first you need to create an SSBO uniform in the light shader. Just take a look at how hullVSSBO is defined. It's the list of hull vertex coordinates, and it is an array of floats (instead of vector2) because it is a flattened list. I assume that you can just define two more such arrays for the bounding boxes, one for the lower bounds and another for the upper bounds.
Then, you need to go to LightingEngine and reserve enough memory for the SSBOs you just defined. You should do this in the _create_ssbos function, I think it should be 8*max_num_hulls bytes for each SSBO. It's very similar to the other lines of code in that function.
Lastly, to send the bounding box data in each frame, simply do as in function _send_hull_data of the LightingEngine.
If you are having trouble implementing this, just ping me and I'll be happy to help. Also, no need to implement the caching yet, we can do that later. Excited to see what you come up with :)


API: Swagger for keptn api shows wrong version

Describe the bug
When accessing the swagger-ui for the API it shows version 0.1.0.

To Reproduce
Steps to reproduce the behavior:

Install keptn
Go to swagger UI of the API

Expected behavior
I was expecting the current version of keptn or the API to be displayed, which would have been 0.5.0
Maybe we can auto-generate the version in swagger.yaml/swagger.json?

Just verifed this, and it seems to work. Good job!


Issue with k8s.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

This is a Bug Report

Problem:
link 'Upgrading kubeadm cluster from 1.15 to 1.16'
leads to 'Upgrading kubeadm cluster from 1.16 to 1.17'
Proposed Solution:
working link
Page to Update:
https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

Thanks for the report @conseque
/priority important-longterm
/kind bug
/assign
/language en

/sig release


Add workaround for test on Red Hat 8 POWER

Due to an issue with SSSD, this commit adds a workaround for the test to modify a user's password on Red Hat 8 POWER machines (ppc64le). We have submitted an ITHELP ticket (ITHELP-100250) for a more permanent fix.

This should be backported to 7.x as well


feat: add startLevel prop to mux-video-react

Hey team,
A small PR that allows you to add the startLevel prop in the MuxVideo react component.
API doc - https://github.com/video-dev/hls.js/blob/master/docs/API.md#startlevel

Hey @staniwasd,
Appreciate the eager and proactive engagement with the Open Elements project! Some way of programmatically stipulating a preferred initial rendition/media playlist sounds like a good feature add. For these kinds of changes, we'll want to discuss with the team before merging them, including details on how we'd want to solve that general problem.
Just in case we don't accept this PR, I'd recommend starting with filing a Feature Request Issue to avoid any wasted effort on your part. Also, when it comes to directly exposing hls.js API details (including config), we've been very intentional about the shape of this API, as we don't want to be overly-coupled to relying on this as our underlying "playback engine". Additionally, if we do end up exposing some API for starting rendition/level/playlist, we'll probably want that to be implemented for the other elements as well.
Let me check in with the team and get back to you on how we'd like to approach this! Assuming folks from the team are on board, if you're still interested in contributing, we can let you know what changes we'd want for a more general solution here.
Thanks again!

Closing this. Intended purpose of the changes should be covered by #833


fix function param type define error

fix error when generate logic code.
In handle tpl file,the funcition is called: l.{{.Call}}({{if .HasRequest}}&req{{end}}), the last param is address, but in logic define, the last param is strcut, so my vscode report error.

Currently, there is no problem with the logic parameters generated by the api. You can describe the bugs you encounter in detail and describe your problems and scenarios. The following is part of the code I generated, thanks for you contribution!
func (l *HelloLogic) Hello(req *types.Request) (resp *types.Response, err error) {
	// todo: add your logic here and delete this line

	return
}

but I see the tpl file, in logic.tpl,the code is :func (l *{{.logic}}) {{.function}}({{.request}}) {{.responseType}} {...
may be our go-zero version is not consistence?
my gomod:github.com/zeromicro/go-zero v1.4.4

I know the problem.When I use generate with goctl-go-compact , this error occur.But it work normally when not goctl-go-compact.

goctl-go-compact might need to be updated?


typos

hey, noticed a couple of typos, maybe you want to correct them ?
in TemplateParser.ahk :

tempALtes should be tempLAtes

in Gui.ahk :

l26: maKRdown should be maRKdown
l29: Edit_image_tempALte  should be Edit_image_tempLAte

in GuiControl.ahk

l32-33: maKRdown should be maRKdown
l36-37: tempALte should be tempLAte

Yes, you're right, thank you!!


DNS

Source: http://www.ethicalhack3r.co.uk/zone-transfers-on-the-alexa-top-1-million-part-2/

If you want more:
http://www.ethicalhack3r.co.uk/zone-transfers-on-the-alexa-top-1/
https://github.com/rbsec/dnscan


Turn off Browser Sync on Heroku Deploys

Currently a user can log into Browser Sync on all web instances.
Don't do that.

#11 Should start this process, though its not totally removed. There are still some assets being loaded on the client's browser that dont need to be loaded on production.


Node 18 takeback?

Had a project previously built for Heroku that I started deploying to Cloud Run October 2022 or so using gcloud run deploy that specified
  "engines": {
    "node": "18.x"
  },

in package.json.
And as of Nov 28 this was building (and running) correctly. Here's a relevant portion of build log from the 28th:
===> BUILDING
[builder] === Node.js - Runtime<EMAIL_ADDRESS>===
[builder] 2022/11/28 19:43:57 [DEBUG] GET https://dl.google.com/runtimes/ubuntu1804/nodejs/version.json
[builder] Installing Node.js v18.12.1.
[builder] 2022/11/28 19:43:57 [DEBUG] GET https://dl.google.com/runtimes/ubuntu1804/nodejs/nodejs-18.12.1.tar.gz
[builder] === Node.js - NPM<EMAIL_ADDRESS>===
[builder] Installing application dependencies.

but as of Nov 29 the same build receives an error:
===> BUILDING
[builder] === Node.js - Runtime<EMAIL_ADDRESS>===
[builder] 2022/11/29 23:33:20 [DEBUG] GET https://dl.google.com/runtimes/ubuntu1804/nodejs/version.json
[builder] Failure: (ID: 9cd081f9) invalid Node.js version specified: failed to resolve version matching: 18.x
[builder] --------------------------------------------------------------------------------
[builder] Sorry your project couldn't be built.
[builder] Our documentation explains ways to configure Buildpacks to better recognise your project:
[builder]  -> https://github.com/GoogleCloudPlatform/buildpacks/blob/main/README.md
[builder] If you think you've found an issue, please report it:
[builder]  -> https://github.com/GoogleCloudPlatform/buildpacks/issues/new

After looking around a bit, I couldn't find standard documentation of max version (which is an issue on its own - if LTS is not supported docs should say so.) I did find closed issues stating that Node 18 was not working on Ubuntu 18 and so was not supported, but they all predate it seemingly working as shown above.
I can probably regress this project to Node 16, but I've another I'd like to move over that won't be so easy. Besides heading off unsupported conditions a bit earlier through docs, it'd be helpful to know when 18 will be supported again.

This my fault, I updated the supported version range to exclude Nodejs18 because I was under the impression that our base image didn't support it. I could have sworn that I tested this right after Nodejs18 was released and I discovered that it didn't work because Ubuntu18 ships an unsupported version of glibc. Maybe something changed...
For now, there are a few things to note:

The Nodejs18 tarballs are still available, the buildpacks are just refusing the resolve the version constraint, so if you pin down to the patch you can still use Nodejs18:
"engines": {
    "node": "18.12.0"
  },

We are working on publishing a new builder based on Ubuntu 22.04, which will definitely support Node.js 18. We recommend everyone upgrades when it becomes available in the next couple weeks.

I will spend some time investigating Nodejs18 compatibility with Ubuntu 18.04. If it is actually supported, I can quickly update the version manifest to allow resolving constraints like 18.x again.

Here is the commit where Node.js bumped the minimum glibc/Ubuntu versions in their BUILDING.md: https://github.com/nodejs/node/commit/3671cc043233d9e75994ce17abb050ee0581dce0

IIRC when we originally tested Node.js 18 it didn't compile, so the fact that these tarballs got published suggests something changed.

Thanks for tip 1 (pin down to the patch), that should suffice for a few weeks for this particular project.
In case it's helpful in working back to what happened, it appears first successful build I had targeting "18.x" was on October 25:
===> BUILDING
[builder] === Node.js - Runtime<EMAIL_ADDRESS>===
[builder] 2022/10/25 13:25:10 [DEBUG] GET https://dl.google.com/runtimes/ubuntu1804/nodejs/version.json
[builder] Installing Node.js v18.11.0.
[builder] 2022/10/25 13:25:10 [DEBUG] GET https://dl.google.com/runtimes/ubuntu1804/nodejs/nodejs-18.11.0.tar.gz

I've tried now with quite a number of different explicit node versions but all of them are getting 404 during build:
18.2.1
Failure: (ID: 7fdca554) fetching https://dl.google.com/runtimes/ubuntu1804/nodejs/nodejs-18.2.1.tar.gz returned HTTP status: 404

18.12.x
Step #0 - "Buildpack": 2023/01/14 07:29:22 [DEBUG] GET https://dl.google.com/runtimes/ubuntu1804/nodejs/version.json
Step #0 - "Buildpack": Failure: (ID: ae212299) invalid Node.js version specified: failed to resolve version matching: 18.12.x

18.13.0
Failure: (ID: 8be17978) fetching https://dl.google.com/runtimes/ubuntu1804/nodejs/nodejs-18.13.0.tar.gz returned HTTP status: 404

We're looking into it.

@u12206050 What has happened here is that we constrained the set of versions that we download and publish, as well as the versions available when using version resolution to select a version.
18.2.1 didn't work because a nodejs v18.2.1 was never released.
18.12.x didn't work because it requires version resolution, and >=18.0.0 < 19.0.0 was removed from the set of resolvable versions.
18.13.0 didn't work because this was released after we removed >=18.0.0 < 19.0.0 from the set of versions to download and publish.
The latest version that we have downloaded and published is 18.12.1.  Using this as the version specifier is currently working to allow deployments.
With all that said, we are close to having the new Ubuntu 22.04 builder available.

We also just released the Ubuntu22 builders for our buildpacks. I'll be doing a longer writeup for it soon, but you can give it a try with pack: pack build --builder=gcr.io/buildpacks/builder:google-22 <image name>
or with Cloud Build:
gcloud builds submit \
    --pack builder=gcr.io/buildpacks/builder:google-22,image=<region>.pkg.dev/<project>/<repository>/<image-name>

You can check the write up announcing the Ubuntu 22 builder here https://github.com/GoogleCloudPlatform/buildpacks/discussions/271
Closing the issue since we now have a path for ya'll to use Node.js 18. Please feel free to open a new issue  if you find that Node.js 18 still doesn't quite work on the new google-22 builders


RTL: WTF! Code is Reversed!

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

Version: 1.86.1 (user setup)
Commit: 31c37ee8f63491495ac49e43b8544550fbae4533
Date: 2024-02-07T09:08:20.941Z
Electron: 27.2.3
ElectronBuildId: 26495564
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.22621

The code:
content: "ویرایش"; /* Edit */

How it looks like:

It's fine, don't add RTL support, but what the hell is this? You are breaking the defaults!

Update
This issue happens when this option is set to true:
{
    "editor.fontLigatures": true,
}

I'm closing this because the issue is caused by the font (JetBrains Mono) that I'm using.

As I stated before, things work fine when the "editor.fontLigatures" option is set to false.
The reason that I closed the issue was that I couldn't reproduce the issue with the default font that vsCode uses.
I tested it out with another font (Fire Code), and the issue persists.
I'm not sure, but I think the default font doesn't support ligatures and because of that things don't break.


reformat & add .gitignore

Hi guys, all reformats will be rejected. I format my code examples the way I find them most readable. If you want to fork and reformat, go ahead. If you submit new code that is formatted the way you like it, fine. But don't reformat existing code. Not unless there is an obvious  formatting error, like an indentation missing etc.


Relaton-ISO creates cache for unclean references

In geolexica.org , both of these files are created in the cache:

iso_12620_1999.xml
iso_12620_1999_.xml

Both files have the same content. Obviously when Relaton creates the cache file, it must be using the normalized document identifier, not what was directly given. e.g. given "ISO 12620:1999 - blah", the normalized filename should still be iso_12620_1999.xml.
There are 7 of these in geolexica.org:

iso_12620_1999.xml and iso_12620_1999_.xml
iso_31_2_1992.xml and iso_31_2_1992_.xml
iso_8601_2000.xml and iso_8601_2000_.xml
iso_iec_11179_3_2003.xml and iso_iec_11179_3_2003_.xml
iso_22028_1.xml and iso_22028_1_.xml
iso_iec_19501_2005.xml and iso_iec_19501_2005_.xml
iso_iec_tr_14252.xml and iso_iec_tr_14252_.xml

This also applies to ITU, geolexica.com has:

itu_r_rec.tf.686_1.xml and itu_r_rec.tf.686_1_.xml

@ronaldtse I'll fix the issue with the underscores.
Concerning using a document identifier. We can't use a document identifier as a filename. The problem is we don't have a document identifier when fetching a document. We have a reference only. Before we retrieve the document from the internet we should check if there is a file with a name matched to the reference.
One document could be fetched by many different references. For example "ISO 123 2014" returns a document and we save it to iso_123_2014. If we search by "ISO 124" reference we will get the same document if it is the lastest with the number. But we don't know it before we fetch the document.
There are other cases like all parts, attempts ISO/IEC and stages, when one document could be fetched by different references. If we save these documents using their document identifiers, how do we find the files by references?

This issue is related to relaton gem. Move it there.

This is now superseded by https://github.com/metanorma/relaton/issues/53


Use TemporaryFile for stdout to support large emails

I ran into an issue where my email was getting cut off somewhere in the middle of the HTML. It turns out it was over 65kb, which I guess is the limit for subprocess.PIPE where stdout is being redirected to - so I switched this to a TemporaryFile.

Hi Nick Day, thanks for your update! I'll check it and release this fix in a month and a half.

What's the status on this fix? We're getting bitten by this same issue and would love a quick resolution if possible!  Thanks!

@liminspace the rendering performance is not a huge concern since we are not sending a significant amount of emails.  Also, we don't want to incur the additional cost of spinning up a server (along with orchestrating and securing it) just to render a few emails.  Would it be possible to at least accept the pull request so we can include the commit in our python dependencies?
Thanks!

@sklarsa you can temporary use this version https://github.com/nickday/django-mjml/tree/master if it works for you correctly.
I must added that using tcpserver mode must be cheaper than cmd mode because it keep mjml in memory and not restart it all time. It's very simple to use docker for it. There is the container with mjml that is working well liminspace/mjml-tcpserver.

Ah understood! Thanks!
On Mon, Oct 1, 2018 at 6:50 PM Igor Melnyk<EMAIL_ADDRESS>wrote:

@sklarsa https://github.com/sklarsa you can temporary use this version
https://github.com/nickday/django-mjml/tree/master if it works for you
correctly.
I must added that using tcpserver mode must be cheaper than cmd mode
because it keep mjml in memory and not restart it all time. It's very
simple to use docker for it. There is the container with mjml that is
working well liminspace/mjml-tcpserver.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/liminspace/django-mjml/pull/59#issuecomment-426089882,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB1xRcEqJ5Aq-Sam2uJ2Drk3HFYoK-Y_ks5ugpwbgaJpZM4WlrYu
.

I've added test case to test a big mjml-template (5 Mb) and I see that problem is only for mjml v3.3.5 https://travis-ci.org/liminspace/django-mjml/builds/443788636
I think it is not Python problem. And I don't know if there is a reason to fix this problem for mjml v3.3.5 as it is old version.
Please, update to mjml v4.1.2 and check.

Using temporary file is not a good idea as it is disk-IO-operation that increase overhead.

As cmd mode is not a production mode I added using TemporaryFile for stdout. It is an easier solution than using a subprocess for stdout reading.

Version 0.5.4 was released.


SAMZA-871: Heart-beat mechanism between JobCoordinator and all running containers

@abhishekshivanna  Is there any plan to make the heartbeat interval tunable? Or do we have some estimate on what the optimal value should be?

@navina regarding making the heartbeat interval tunable via config I think it was bought up in the SEP discussion that we can choose a sensible default for now and if needed make it a tunable in the future.


Remove unbroken tests

The new version of MA should fix these

I've already removed some of them in #26, the ones around allocations continue to fail with MA-1.4.3

Ok, I'll stake a look at the broken tests. I find it convenient to communicated the required fix as @test_broken


[WIP] Completion support

This PR adds completion support (as per #211). Right now it's mostly stripped out parts of haskell-ide-engine, put back together into the rule-based system of ghcide. It seems to work for value level things, but not so well for type-level things, so further investigation is needed.
The information shown is also very basic. In the future the idea is to also return the documentation of the functions, if available.

PS: right now there's a problem about how I published my branch, and it seems that the TH-related changes have also slipped in this branch. Hopefully once the TH branch is merged, this problem will go away.

I thought the idea was to not implement completion support directly in ghcide but as some kind of plugin. Has that plan changed?

@mpickering I think the plan was always to implement completions inside ghcide. It was things like Hoogle/HLint/LiquidHaskell we thought were best handled by plugins.

I was not aware on any plans on this respect, I just found ghcide to be a nice project to contribute to! But if you prefer to do it in other way, I'm happy too :)

Just wanted to say I tried this out and it works very nicely!

Just mentioning that you are probably inheriting https://github.com/haskell/haskell-ide-engine/issues/1434 from me.

Thanks for the heads up @fendor - would be great if we can eventually share these (either because hie and ghcide merge, or because there is a common underlying library everyone uses)

Thanks for the PR, I’m hoping to get around to taking a look at this tomorrow but from an initial look, it looks great :+1:

There's still a problem I need to solve. The completions only work if the chnages make the problem still typecheck. For example, if I have
thing :: String -> I

and I want to obtain completions for I, then nothing happens. But if I have
thing :: String -> Int

this is type-correct code and Int32, Int64 and so on are shown.
The question here is: is there any way to "save" the latest type correct TypecheckedModule and use it if the new one gives problems? That would be the solution to these problems.

The core of the IDE was designed to support getting stale values, e.g. useWithStale https://github.com/digital-asset/ghcide/blob/master/src/Development/IDE/Core/Shake.hs#L432. I'm not sure where that is poked out, or even if it still works (or in fact ever worked), but that was the original design, precisely for this purpose.

So if I changed my usage of use TypeCheck with useWithStale TypeCheck, everything should in theory work? Thay would be great!

useWithStale definitely works (at least in some circumstances), we use this in DAML. But for ghcide, I would have expected that the -fdefer-type-errors stuff takes care of making sure that you still get a typechecking result even if typechecking fails.

defer type errors will defer type errors, but not parse or name errors, which tends to be when you are asking for completions, and typically I want the best completions that can be found in < 0.1s. I think this is the right place to use deferred type checking.

The code looks good to me, thanks a lot! I’ve also tested it on an internal codebase and it doesn’t seem to increase memory usage significantly which I was a bit afraid off. I am trying to figure out what we need to make sure that this doesn’t cause any licensing problems. I’ll get back to you once I know what steps need to be taken.

It would be great if you could test the code. It seems that everything works fine except for qualified imports, but I cannot find the reason why. Also, the new version with useWithStale works quite well, but not in a completely reliable way.
Some other issues before considering merging:

The code from HIE uses something called withSnippets, but I cannot completely understand why. I am leaning towards removing that part.
The code which obtains the type for elements doesn't work for imported functions (for example, the completion of head only shows Prelude, but not the type). My gut feeling is that it's related to getComplsForOne (around line 300 of IDE/Core/Completions), but any help would be great.

Thanks for fixing the positions, I would still like to see some tests before merging this. Doesn’t need to be comprehensive but at least one basic integration test and one that exercises the useWithStale code path and checks that the positions are correctly remapped.

I've written some preliminary tests. However, I cannot get my head around how to check the stale file; I've tried several ways but all of them lead to a stuck test.

I’ve pushed a fix for the tests. The two expected failures where caused by the fact that those did not typecheck nor did you have a stale result. I changed them to first produce something that typechecks so you have a stale result. Given that this already exercises the stale codepath I’ve removed the separate test for that.
Do you have anything else that you want to address? Otherwise I think this should be ready to land (I’ll be on vacation so it might take me longer to respond).

No, the PR looks perfect to me. I guess we now should wait for bug reports and other problems that may arise.


Make it as snap package

Hello.
Would you consider making f.lux as snap package so that it can be installed on any Linux distro?
I've also heard that starting from 18.04, Ubuntu will be "all snap" packages instead of current .deb packages.
https://snapcraft.io/

https://github.com/mkg20001/fluxgui-snap
But d-bus does not seem to work...

Hey @mkg20001. Please tell us about your problem and we might be able to help:
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Also, I see that you are working on a new design for the v4 version. Do you think you can make something like for Ubuntu too? I mean, your app for Ubuntu still says "year 2010".

I think like @faraco , it may not be necessary to open a new ticket and direct this as a discussion. Currently Flatpak works better on the desktop and has a much wider adoption than Snap, which makes Flatpak the best option.

This is the best thing I would love to have on my development machine.
I can't sleep without it!


[Error after update to 8.3.1 from 8.3.0] First argument to String.prototype.startsWith must not be a regular expression

Environment

Operating System: Windows_NT
Node Version:     v20.9.0
Nuxt Version:     3.10.3
CLI Version:      3.10.1
Nitro Version:    2.8.1
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      app, site, schemaOrg, vue, ssr, devtools, modules, image, googleFonts, ogImage, i18n
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Reproduction
This error does not occur in “stackblitz starter”
In nuxtjs/i18n 8.3.0 version everything worked fine.
After update to 8.3.1 (Verified that only the upgrade itself causes this).
and nuxt generate  throws errors and blocking the generation of the page.
Describe the bug
Error appeared after last update, does not allow to generate static page.

Additional context
No response
Logs
No response

This project is too big to reproduce. I will try to use a similar configuration in as little code as possible.
Is there a chance for some tips to fix this or what to pay attention in reporduction?
Up until version 8.1.1, everything worked fine.

Closing this due to inactivity and lack of reproduction, if you're still experiencing this issue please open a new issue with a (minimal) reproduction.


Cannot read property 'key' of undefined

I opened the keybase client and went to chat and got this error
my log id: f7fde6109b9930c476b6231c

@gene1wood This has been fixed in the latest public version, which you don't seem to be running.
And the version you are running doesn't seem to be a public version.  How did you install it?

Oh!  You're on Linux.  It all makes sense to me now.
Okay, just update through your package manager to get the fix.

@cjb Will do, thanks.


Filters aggregation

I think the two stack.yaml.lock files should be removed from git. And perhaps added to .gitignore.


KYLIN-4741 Support to config the sparder application name

Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce to Kylin?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have create an issue on Kylin's jira, and have described the bug/feature there in detail
[x] Commit messages in my PR start with the related jira ID, like "KYLIN-0000 Make Kylin project open-source"
[x] Compiling and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If this change need a document change, I will prepare another pr against the document branch
[ ] Any dependent changes have been merged

Further comments
If this is a relatively large or complex change, kick off the discussion at user@kylin or dev@kylin by explaining why you chose the solution you did and what alternatives you considered, etc...

After setting 'kylin.query.sparder-context.app-name' to 'sparder_on_docker' and restart kylin instance, the name of sparder context is shown below:

Codecov Report

:exclamation: No coverage uploaded for pull request base (kylin-on-parquet-v2@49dcdd2). Click here to learn what that means.
The diff coverage is n/a.

@@                  Coverage Diff                   @@
##             kylin-on-parquet-v2    #1521   +/-   ##
======================================================
  Coverage                       ?   24.31%
  Complexity                     ?     4619
======================================================
  Files                          ?     1138
  Lines                          ?    64439
  Branches                       ?     9512
======================================================
  Hits                           ?    15669
  Misses                         ?    47134
  Partials                       ?     1636

Continue to review full report at Codecov.

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