decorators-style conflicts with Prettier

We're using default Prettier options and default @stencil/decorators-style options.
Prettier formats code like this:
class AxsTreeViewItem {
  @Event({ bubbles: true, composed: true })
  axsTreeItemSelected: EventEmitter<any>;
}

but @stencil/decorators-style says The @Event decorator can only be applied as inline.
I expect @stencil/decorators-style to work with Prettier and to not cause warnings.

eslint-plugin-decorator-position had the same bug: https://github.com/NullVoxPopuli/eslint-plugin-decorator-position/issues/289. They fixed it in https://github.com/NullVoxPopuli/eslint-plugin-decorator-position/commit/b86643a358425e5e6bcf78497140b2c2d44004db. I hope that can be of some help.

Chiming in that my CI is now broken because of this incompatibility between stencil.js and prettier. After reading the above, I've become frustrated because I have no idea how to make my CI tools get along with each other.

I guess this issue can be closed, since Prettier does not change decorators anymore (see here).
Furthermore, you're still able to configure Stencil's ESlint plugin according to your needs, i.e. set all Decorator-Styles to multiline:
{
  "parserOptions": {
    "project": "./tsconfig.json"
  },
  "extends": ["plugin:@stencil/recommended"],
  "rules": {
    "@stencil/decorators-style": [
      "error",
      {
        "prop": "multiline",
        "state": "multiline",
        "element": "multiline",
        "event": "multiline",
        "method": "multiline",
        "watch": "multiline",
        "listen": "multiline"
      }
    ]
  }
}

@nioe Prettier behavior is still the same. And I expect default decorators-style options to be compatible with Prettier. So keeping the issue open.


spaCy version

As written in the readme at "If you are an early user of spacy 2 alpha --- (and there is now spacy 2.0.6 and the version won't be lower in the future, and you could adress the project by typing its proper name with big C) ---  , you can use neuralcoref with spacy 2 without any specific modification", there should be no problem with spaCy 2 using appropriate models. Instead of this iInstalling the requirements of neuralcoref overwrites and corrupts an exisiting installation of spacy. So please update your readme directing to a working version of spaCy or upgrade your own version.

You are right, there is currently an incompatibility with spacy 2 (which is different than the alpha version I was using). I will update it to be compatible with spacy 2 next week.

Awesome, thank you @thomwolf !  :-)

Your plan is really nice.
Are you going to do this this week?

Closing this as it should now be fixed, feel free to reopen otherwise

It works, thank you!


Migration to Bootstrap Version 5

Migration to V5
This PR implements the migration to Version 5 of the BC Gov Bootstrap theme v4 (fixes #24)
Since I'm unfamiliar with Jekyll, I approached the migration by updating HTML and SCSS files accordingly. The changes include updates to class names to match the Version 5 naming conventions, as well as the creation of certain mixins and functions that were deprecated with Version 5.
For a detailed list of changes made throughout the migration, please refer to the CHANGELOG.

Closing this pull request as version 5 will be hosted in a separate repository and can be found here


How to create traindata label ?annotate lines   like verical line horizental line or the whole table?

We have used Label Image Tool for annotations.

@AyanGadpal  but how to get the mask labels


More gem updates

Coverage remained the same at 86.158% when pulling 89613a2f015446e50a8acc1c8c9a37479d02e389 on mb-update-gems into fde21df0688b9f17ae7be3b928a9a38ec3e749e9 on master.


Incorrect cone type after removecones

The cone type returned by getconeinfo and getcone is incorrect after removecones. See the broken test added in https://github.com/JuliaOpt/Mosek.jl/pull/187

This was a MOSEK issue. It has been fixed in the latest 9.1 build.


Feature/cliv2

Second iteration of a cli that uses a sane subcommand style interface and reduces weirdness.

Rebased onto latest master

@schlomo @snordhausen here is a reimplementation of the afp-cli with a better interface.

It uses subcommands instead of switches to distinguish operations.

Travis is green, landscape is broken and coveralls is reporting bs.

SInce this doesn't interfere with anything I'm going to go ahead and merge this.


z_arch_switch() passed pointer to NULL outgoing switch handle on dummy thread context switch

If CONFIG_SWITCH is enabled, the initial context switch into the main thread (either in prepare_multithreading() or smp_init_top() has a fundamental flaw. It's relying on a partially initialized "dummy_thread" for the outgoing thread information, with dummy_thread->switch_handle being NULL.
This causes a NULL pointer dereference to any arch that uses the outgoing switch handle for anything. When I enable memory protection this causes a fatal page fault on intel64.
Some solutions I've considered:

Add a NULL check in the arch switch code for the outgoing thread handle (slow)
Implement CONFIG_ARCH_HAS_CUSTOM_SWAP_TO_MAIN instead of a dummy thread, which would be mandatory for all arches implementing CONFIG_SWITCH, and there is no support for this yet in smp_init_top()
Change switch handles to be something typed (like the actual thread objects) so that dummy thread switch handles can be populated in kernel code in an arch-agnostic way

To me option 3 seems preferable
Impact:
All arches using CONFIG_SWITCH() are de-referencing a null pointer, silently unseen until now due to luck and no SMP arches having memory protection enabled.

Not completely understanding the problem.  What's trying to use the switched_from handle of a dummy thread?  Sounds like there's an unrelated bug here, maybe?  I think it's very reasonable to have a requirement that the pointers always be non-null at the arch layer and put the complexity into the kernel, that just isn't the way it works currently because of that dummy thread trick.
As far as changing a switch handle into a thread struct, I guess I don't see how it's related to the NULL issue described here exactly.  But regardless, sure, it can be done.  It will require pretty significant surgery to xtensa to make work, and defeat some relatively useful optimizations (the cross-stack call trick, pushing only caller-save registers on interrupt entry, stuff like that) there to the interrupt entry and context switch code (the same is true for x86_64, but... yeah).   But yeah, that would work just fine too.
I continue to weep internally that I haven't been able to convince anyone of the value of this architecture (which is certainly not unique to Zephyr, FWIW), but it's not like it's the only way to do things.

Just to clarify the technical question: having a NULL in the switch_handle fields just means that a thread has not been suspended by interrupt entry or a context switch (or thread initialization, of course).  Trying to switch back "to" such a thread simply doesn't make any sense, it doesn't have state to restore.
So we need to figure out where and why that's happening, regardless of what we do regarding the typing of the switch handles or whatever.

@andyross
z_arch_switch() takes two arguments: switch_to, switched_from.
On the initial context switch from dummy thread, switched from is a pointer to NULL.

Not completely understanding the problem. What's trying to use the switched_from handle of a dummy thread? Sounds like there's an unrelated bug here, maybe?

The implementation of z_arch_switch()

defeat some relatively useful optimizations (the cross-stack call trick, pushing only caller-save registers on interrupt entry, stuff like that) there to the interrupt entry and context switch code (the same is true for x86_64, but... yeah). But yeah, that would work just fine too.

Isn't all the data being manipulated at some offset from the thread struct anyway? Not seeing how this is an optimization, and it certainly hasn't been documented.
At the end of the day I don't care how this is gets solved, other than I really don't want to have to pull NULL checks in z_arch_switch() that are only true when a thread is initially started.

I think it's very reasonable to have a requirement that the pointers always be non-null at the arch layer and put the complexity into the kernel, that just isn't the way it works currently because of that dummy thread trick.

The NULL in dummy_thread->switch_handle gets passed all the way to z_arch_switch()

Isn't all the data being manipulated at some offset from the thread struct anyway?

No, on xtensa and x86_64 the context lives on the process stack.  Docs are at the arch layer obviously, see for example https://github.com/zephyrproject-rtos/zephyr/blob/master/arch/xtensa/include/xtensa-asm2-context.h and https://github.com/zephyrproject-rtos/zephyr/blob/master/arch/x86_64/core/xuk.h#L93  Doing it this way allows the entry/exit code to skip the stack pointer jiggling that would otherwise be required.  For example interrupt exit and the bottom half of switch just pop a bunch of stuff and issue an IRET synchrononously.  Or you can implement the top half of switch with a few pushes of a faked interrupt entry frame followed by a simple CALL to code that gets shared with interrupt entry.  You can also easily implement "don't spill callee-saved registers when invoking interrupt handlers" by just calling out and then pushing after the return.    Xtensa actually goes even farther with this idea and arranges for a "cross stack call" frame that allows us to avoid spilling not just the ABI registers but in fact all the up-stack register windows on the CPU.  Really, it's a good trick.  Linux does it this way too.  But it requires that you pass the resulting stack pointer around as the handle, or else store it somewhere in the thread struct (which is the exact converse of the complaint here, if I'm understanding correctly).

The NULL in dummy_thread->switch_handle gets passed all the way to z_arch_switch()

We should find out why, then.  Do you have a trace of what is trying to context switch into a dummy?  Dummy threads shouldn't do anything but take interrupts, once any other thread gets scheduled they should never be scheduled again.

I threw an assertion in trying to catch this and am not having any luck spotting it on the existing platforms in master.  Is there maybe something specific to the memory protection initialization that is trying to switch back into a dummy?

Still trying to figure out what the actual problem being reported is.  This bit has me confused:

z_arch_switch() takes two arguments: switch_to, switched_from.  On the initial context switch from dummy thread, switched from is a pointer to NULL.

That's as designed.  The switched_from argument is an output pointer: the switch code is expected to store the resulting switch handle of the current thread into that pointer before begining to execute the "switch_to" context.  Nothing should ever be reading from that pointer, just storing into it.
And FWIW, this quick patch produces working tests/kernel results on qemu_x86_64, qemu_x86_long and qemu_xtensa.  As far as I can tell nothing should ever be seeing this null.  How do I reproduce?
--- a/kernel/include/kswap.h
+++ b/kernel/include/kswap.h
@@ -78,6 +78,7 @@ static ALWAYS_INLINE unsigned int do_swap(unsigned int key,
                }
 #endif
                _current = new_thread;
+               __ASSERT(new_thread->switch_handle != NULL, "");
                z_arch_switch(new_thread->switch_handle,
                             &old_thread->switch_handle);
        }

Is there maybe something specific to the memory protection initialization that is trying to switch back into a dummy?

No...all I did was install a page table which has the 0 page unmapped and I get a fault. There is no userspace, no stack overflow protection, just you can't access the NULL page
Here, pull this branch and run any test with qemu_x86_long:
https://github.com/andrewboie/zephyr/tree/switch_problem
If you then cherry-pick in https://github.com/andrewboie/zephyr/commit/9e0834d10431f9f362bacd2ede305e3c43fe46a2 you will see that the crash goes away

And FWIW, this quick patch produces working tests/kernel results on qemu_x86_64, qemu_x86_long and qemu_xtensa. As far as I can tell nothing should ever be seeing this null. How do I reproduce?

Memory protection HW isn't enabled for ANY of these.
You have to pull my branch.

This is the code on intel64:

/*
 * void z_x86_switch(void *switch_to, void **switched_from);
 *
 * Note that switch_handle for us is simply a pointer to the containing
 * 'struct k_thread', thus:
 *
 * RDI = (struct k_thread *) switch_to
 * RSI = (struct k_thread **) switched_from
 */

.globl z_x86_switch
z_x86_switch:
	movq (%rsi), %rsi

	andb $~X86_THREAD_FLAG_ALL, _thread_offset_to_flags(%rsi)

	popq %rax
	movq %rax, _thread_offset_to_rip(%rsi)
	movq %rsp, _thread_offset_to_rsp(%rsi)
	movq %rbx, _thread_offset_to_rbx(%rsi)
	movq %rbp, _thread_offset_to_rbp(%rsi)
	movq %r12, _thread_offset_to_r12(%rsi)
	movq %r13, _thread_offset_to_r13(%rsi)
	movq %r14, _thread_offset_to_r14(%rsi)
	movq %r15, _thread_offset_to_r15(%rsi)

	movq %gs:__x86_tss64_t_ist1_OFFSET, %rsp

	/* fall through to __resume */

/*
 * Entry:
 *   RSP = top of CPU interrupt stack
 *   RDI = (struct k_thread *) thread to resume
 */

__resume:
	pushq $X86_KERNEL_DS			/* SS */
	pushq _thread_offset_to_rsp(%rdi)	/* RSP */
	pushq _thread_offset_to_rflags(%rdi)	/* RFLAGS */
	pushq $X86_KERNEL_CS			/* CS */
	pushq _thread_offset_to_rip(%rdi)	/* RIP */

	movq _thread_offset_to_rbx(%rdi), %rbx
	movq _thread_offset_to_rbp(%rdi), %rbp
	movq _thread_offset_to_r12(%rdi), %r12
	movq _thread_offset_to_r13(%rdi), %r13
	movq _thread_offset_to_r14(%rdi), %r14
	movq _thread_offset_to_r15(%rdi), %r15

	testb $X86_THREAD_FLAG_ALL, _thread_offset_to_flags(%rdi)
	jz 1f

	fxrstor _thread_offset_to_sse(%rdi)
	movq _thread_offset_to_rax(%rdi), %rax
	movq _thread_offset_to_rcx(%rdi), %rcx
	movq _thread_offset_to_rdx(%rdi), %rdx
	movq _thread_offset_to_rsi(%rdi), %rsi
	movq _thread_offset_to_r8(%rdi), %r8
	movq _thread_offset_to_r9(%rdi), %r9
	movq _thread_offset_to_r10(%rdi), %r10
	movq _thread_offset_to_r11(%rdi), %r11
	movq _thread_offset_to_rdi(%rdi), %rdi  /* do last :-) */

1:	iretq

@andyross
--- a/kernel/include/kswap.h
+++ b/kernel/include/kswap.h
@@ -78,6 +78,7 @@ static ALWAYS_INLINE unsigned int do_swap(unsigned int key,
                }
 #endif
                _current = new_thread;
+               __ASSERT(new_thread->switch_handle != NULL, "");
                z_arch_switch(new_thread->switch_handle,
                             &old_thread->switch_handle);
        }

Your assert is incorect
You need
``
__ASSERT(old_thread->switch_handle != NULL, "");

It's the OLD thread pointer which is NULL

OK, thanks.  That's the part I didn't understand.  FWIW: old_thread is just a copy of _current.  It too is never supposed to be null if we're executing code that is capable of swapping.  Will continue digging.
But do note that x86_64 in fact does have a 16k null guard, so it's not as simple as the pointer being null as it should trip there too.

Wait wait, sorry.  One more clarification, is this bit a typo?:

__ASSERT(old_thread->switch_handle != NULL, "");

Because as mentioned above that's 100% legal and expected.  If "old_thread" itself is null, that's a bug.  But the state of a currently-executing thread's switch_handle field is (for obvious reasons) indeterminate garbage.  You can only restore it after it's been saved, not while it's running.

$ git diff
diff --git a/kernel/include/kswap.h b/kernel/include/kswap.h
index d98fa44618..bc50889299 100644
--- a/kernel/include/kswap.h
+++ b/kernel/include/kswap.h
@@ -78,6 +78,7 @@ static ALWAYS_INLINE unsigned int do_swap(unsigned int key,
                }
 #endif
                _current = new_thread;
+               __ASSERT(old_thread->switch_handle != NULL, "");
                z_arch_switch(new_thread->switch_handle,
                             &old_thread->switch_handle);
        }

this reproduces the issue in a very simple form

Whoops, crossed. Yeah, that's not a bug.  We need to locate the code that's dereferencing old_thread->switch_handle and fix it.

Whoops, crossed. Yeah, that's not a bug. We need to locate the code that's dereferencing old_thread->switch_handle and fix it.

Wait so this is supposed to be NULL?
You are saying we add a NULL check in x86 long's z_arch_switch? For EVERY context switch, even though this just applies to the first switch out of the dummy thread?

The implementation of z_arch_switch() saves state to the old_thread->switch handle (which is expected to be a pointer to old_thread itself) and then pops state off the new_thread->switch_handle (which is a pointer to new_thread)
If x86 long's z_arch_switch() is implemented incorrectly we need help here, the intended design is very unclear

And if the switched_from parameter is supposed to be output-only and its contents are garbage when running, how does the implementation of z_arch_switch() know what outgoing thread to save state to?

I apologize.  Indeed we never had a single spot for arch docs so the switch implementation docs in xtensa and x86_64 was all we had for a long while.   The current design docs at https://docs.zephyrproject.org/latest/reference/kernel/smp/smp.html#switch-based-context-switching are, I think, really not so terrible though.

how does the implementation of z_arch_switch() know what outgoing thread to save state to?

It doesn't.  That's the kernel's job.  The scheduler, not the arch, figures out what threads are swapping and just tells the arch layer where to stick the resulting handle (likewise, the kernel decides what handle to return from on interrupt entry and takes the interrupted context handle as a simple function argument).  The intent was that this was low-level code typically written in assembly, often implemented over a non-zephyr HAL, and that we wanted to minimize the amount of Zephyr-knowledge needed to do it.

It doesn't. That's the kernel's job. The scheduler, not the arch, figures out what threads are swapping and just tells the arch layer where to stick the resulting handle (likewise, the kernel decides what handle to return from on interrupt entry and takes the interrupted context handle as a simple function argument). The intent was that this was low-level code typically written in assembly, often implemented over a non-zephyr HAL, and that we wanted to minimize the amount of Zephyr-knowledge needed to do it.

How do we fix this in terms of how z_arch_switch() is implemented in arch/x86/core/intel64/locore.S?
Because right now it's treating the switched_from parameter as input/output and not output only.

It looks like ARC has the same problem, they added a band-aid NULL check to skip, context, impacting performance:

SECTION_FUNC(TEXT, z_arch_switch)

#ifdef CONFIG_EXECUTION_BENCHMARKING
	push_s r0
	push_s r1
	push_s blink

	bl read_timer_start_of_swap

	pop_s blink
	pop_s r1
	pop_s r0
#endif
	/*
	 * r0 = new_thread->switch_handle = switch_to thread,
	 * r1 = &old_thread->switch_handle = &switch_from thread
	 */

	ld_s r2, [r1]
	/*
	 * r2 may be dummy_thread in z_cstart, dummy_thread->switch_handle
	 * must be 0
	 */
	breq r2, 0, _switch_to_target_thread

The intent was that this was low-level code typically written in assembly, often implemented over a non-zephyr HAL, and that we wanted to minimize the amount of Zephyr-knowledge needed to do it.

I'll be blunt this seems like a solution looking for a problem. Every single arch is going to provide their own custom z_arch_switch(), I do not see how some third-party HAL is going to provide a z_arch_switch() with the same semantics Zephyr is expecting

But as for the intel64 stuff, yeah, it's using the contents of RSI as synonym for _current, which isn't correct.  But it's very close to correct except for the case of the initial dummy thread.  I'd look at solutions that involve stuffing the "correct" arch-specific value into the dummy thread swap_handle field before switch() sees it, instead of testing inside of switch.  Maybe we could stick an arch step in in z_cstart() that allowed the arch layer to init the dummy thread (which is sort of what CUSTOM_SWAP_TO_MAIN does, but maybe simpler), or we could pass the dummy thread as an argument to z_arch_kernel_init()....
And as far as being blunt: not only was this a solution that was already present and working before being replaced with one that doesn't, the bug with stuffing context into into a null pointer went unnoticed because of the removal of the null guard page table in the early implementation that would have caught this mistake long before it merged.  I mean...  this doesn't seem fair to make me responsible for mistakes made when replacing code I wrote that didn't have them.

not only was this a solution that was already present and working before being replaced with one that doesn't, the bug with stuffing context into into a null pointer went unnoticed because of the removal of the null guard page table in the early implementation that would have caught this mistake long before it merged. I mean... this doesn't seem fair to make me responsible for mistakes made when replacing code I wrote that didn't have them.

I don't see past history as germane to the discussion, and I think anyone should be able to speak freely about design points regardless of how long a particular implementation has been in place.
We have two platforms, ARC and x86 long which are expecting the switch handles to be valid thread pointers. ARC works around it at a cost of performance, x86 long currently crashes but for both we need a solution.

Maybe we could stick an arch step in in z_cstart() that allowed the arch layer to init the dummy thread

We would need to add this call to smp_init_top() as well, but this seems a reasonable way to address this for both ARC and x86 long without impacting context switch performance.

We would need to add this call to smp_init_top() as well, but this seems a reasonable way to address this for both ARC and x86 long without impacting context switch performance.

@andyross actually this still isn't optimal. For these platforms (x86 long, ARC) which store outgoing thread information in thread->arch, we have to take the address of switched_from parameter when calling z_arch_switch(), and this is immediately dereferenced. This is some extra overhead that I do not think is optimal.
AFAICT, switch design seems more oriented towards push all your outgoing context onto whatever the current stack is, and then update switched_from to be the stack pointer after everything has been pushed. In this scenario, switched_from truly is an output-only parameter.
So it seems to me that we should not be stashing context in thread->arch like ARC and x86 long currently are, instead they should just push everything to the current stack and update switched_from to be the stack pointer? This seems the fastest way to do this and makes switched_from truly output-only.

Well, at least we've moved from "fundamental flaw" to "still isn't optimal", I guess.  The dereference isn't actually needed, it's just the way the code works right now.  You can recover the thread pointer from the field address with a subtract.  I'll submit something later today.
But yes: this was designed with the intent of allowing stack-based context frames to be implemented naturally.  But it really doesn't require that, it just doesn't provide a space on its own to store the spilled registers.

The dereference isn't actually needed, it's just the way the code works right now. You can recover the thread pointer from the field address with a subtract. I'll submit something later today.

Thanks.
My understanding at this point is that if the switch handles are stack locations, this all works flawlessly and there are no problems with the design.
However if the handles are something related to the thread struct, or the thread struct itself, I think we have some extra overhead, and these unanticipated problems with dummy thread initialization.
Does it make sense to make a documentation pass on this? We have a prototype for z_arch_switch() in include/sys/arch_interface.h that could have some expansion on its docstring. You do have good overall SMP documentation but given that ARC and x86-long tripped over the details, and I got confused too, I think it's worth doing..
Also at some point I think we should re-do the ARC and x86 long switch implementations so that they are using stack-based handles? This seems to allow for the tightest context switching implementation.


Add ClojureScript logo

There is an official repo with the SVG in: https://github.com/cljs/logo. It's different to the Clojure logo so worth having its own representation

It's already on the collection.
Thanks

My bad, didn't try "cljs" 🙈


[5.6] JSON assertion bugfixes

I've added tests which illustrate the issue I'm having, and this PR adds a fix.
Bug Description
JSON Request Response:
{"id":200,"data":"Lorem Ipsum..."}

Running the following would fail:
$response->assertJsonMissing(['id' => 20]);

The reason this was failing is because the assertion functions search for: "id":20 which clearly is present in the response.
If instead we search for:

"id":20,
"id":20}
"id":20]

We guarantee that the value we are searching for is present, and not just a portion of the value.
Long Term
The existing way that the assertion functions operate, i.e. via string comparison isn't ideal, and I'd suggest refactoring it to work recursively walking through the leaves of the array, and then performing value comparisons. Note that this is likely to be less efficient.

I see. Thanks.

Just opened a PR to revert this as it broke existing feature. See https://github.com/laravel/framework/pull/24900


plugins: Move hard coded messages out of code

This begins to move the large chunks of hard coded messages out of
code and into markdown template files. This will make it easier for other
organizations to adopt corobo and customize it to their needs.
Closes https://github.com/coala/corobo/issues/257
Reviewers Checklist

[ ] Appropriate logging is done.
[ ] Appropriate error responses.
[ ] Handle every possible exception.
[ ] Make sure there is a docstring in the command functions. Hint: Lookout for
botcmd and re_botcmd decorators.
[ ] See that 100% coverage is there.
[ ] See to it that mocking is not done where it is not necessary.

AFAIK the markdown templates can't be limited to 80 characters because Gitter renders those extra newlines literally.

fyi, waiting for a potential newcomer fix to arrive; due to expire in a few hours, which I suspect will work nicely with Andrew's timezone anyway.

unack https://github.com/coala/corobo/pull/471/commits/abc438afa3e284333a58ae6d21d9af3ddd99c21b

I think it is better to have templates stored as plugins/templates/<plugin_name>/**.jinja2.md.

I'm flexible on this.  fwiw, I think we'll end up reusing some of labhub error message in other plugins.

Will get this done in a few hours! Thanks for the reviews!

@jayvdb What's blocking this atm?

#329

ack https://github.com/coala/corobo/pull/471/commits/11ce167b47c96c3536e1de68a1b27e410353025c


Fix: CI send coverage condition

pull-request events are not triggered when a PR is merged
push events are not triggered when a PR created from a fork repository
So we need both to run tests on every PR and after merging

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

Comparison is base (c9d5f40) 100.00% compared to head (1803222) 100.00%.
Report is 70 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #71   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         2
  Lines           83        83
=========================================
  Hits            83        83

Flag
Coverage Δ

unittests
100.00% <ø> (ø)

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

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


feat: add UTC export by default for devices and assets

What does this PR do ?
WIP
How should this be manually tested?

Step 1 :
Step 2 :
Step 3 :

Other changes

Boyscout

Should this take a timezone also?
Do we need to keep both timestamp and formatted time ?

Should this take a timezone also? Do we need to keep both timestamp and formatted time ?
As we are exporting raw UTC time, the timezone is out of scop of this PR
Yes, we need to keep raw timestamp on one hand, the formatted time is for convenience so that it is easier for human to analyze the data


cilium: K8s CI testing for sockops

To date we've had some basic tests for sockops negative case in k8s and some simple netperf runtime tests. This adds nertperf K8s tests and http tests using wrk.
After this we can add https tests to include ssl and contrib scripts to extract performance metrics over time.

This change is

Coverage decreased (-0.003%) to 46.061% when pulling 4fd8c1d70786c1c68ac9664187e16e50c9a9c6cc on ci-sockops into f694b3ba28ac2936c413fddec7771ef14a2c8808 on master.

test-me-please

test-me-please

retesting old error here, https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/15993/

I removed netperf-policy.yaml because I no longer use it in k8sT/DatapathConfigurations.go but its still used in Chaos tests. Add it back and retest.

test-me-please

At the moment results are not published the plan is to push a contrib script to extract the results and then I can run it locally on bare-metal where performance is interesting on some cadence (nightly) and then push results somewhere? Any idea where? I was initially thinking just a git repository with all the data so folks could do whatever with it, consume it and publish in dashboard, etc.


Capacitor 4

Is it possible to use this plugin with Capacitor 4?
Right now, I'm getting errors when I try to install the plugin with npm using npm install @capacitor-community/native-audio:
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/@capacitor/core
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/@capacitor-community/native-audio
npm ERR!   @capacitor-community/native-audio@"*" from the root project

Oops sorry I just saw the Pull Request...


Removed non-working manifest for Google Chrome Beta version 92.0.4515.107.

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Wow, I approved and msftbot merged.


mach-o, but not built for iOSMac

I was able to build the app, however it depends on a couple of Carthage backed frameworks. When I try to launch the executable I get:
dyld: Library not loaded: @rpath/UCLKit.framework/UCLKit
  Referenced from: /Users/tiferrei/Library/Developer/Xcode/DerivedData/APIBuddy-bvqcebscaljzwkdnrmlnfebxizli/Build/Products/Debug-iphonesimulator/APIBuddy macOS.app/APIBuddy macOS
  Reason: no suitable image found.  Did find:
        /Users/tiferrei/Library/Developer/Xcode/DerivedData/APIBuddy-bvqcebscaljzwkdnrmlnfebxizli/Build/Products/Debug-iphonesimulator/APIBuddy macOS.app/Frameworks/UCLKit.framework/UCLKit: mach-o, but not built for iOSMac
[1]    15327 abort

I believe this might be due to either not using the correct platform version, although I've tried both macOS and iOS versions of the frameworks, or secondly, due to the way Carthage compiles the frameworks.
Any ideas?

@zhuowei gotcha, thanks.


🧪 test: add delete test

fix

修复修改 mtime 过早导致 mtime 错误

test

新增删除测试

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Details

10 of 15 (66.67%)  changed or added relevant lines in 2 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+12.5%) to 70.928%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

crates/rfuse_device_disk/src/local_disk.rs
6
8
75.0%

crates/rfuse_core/src/sys_fs.rs
4
7
57.14%

Files with Coverage Reduction
New Missed Lines
%

crates/rfuse_device_disk/src/local_disk.rs
1
65.7%

Totals

Change from base Build<PHONE_NUMBER>6:
12.5%

Covered Lines:
1215

Relevant Lines:
1713

💛  - Coveralls


New version: GitHub.cli version 2.49.1

Checklist for Pull Requests

[X] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[X] Does your manifest conform to the 1.6 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Missing Properties value based on version 2.49.0:
ProductCode

Multiple Installers now, ProductCode included in each node and removed from root.
https://github.com/microsoft/winget-pkgs/blob/fbad48fb601bafb1c743a4fd891715a2da31f5cb/manifests/g/GitHub/cli/2.49.1/GitHub.cli.installer.yaml#L21-L29

@wingetbot run


Unity 5.4b16 Native Motion Vector usage

Is this effect already using unity native motion vector or still using custom one?

From what I've seen it use a custom one.
Works great so far for me.

Guys please make it work with native unity vectors!

Agreed, it would be great to have it adjusted to work with Unity's built-in vectors now, which are automatically enabled for objects, and I'm sure they probably are generated a lot more efficient since they are generated in a more low-level way.
But also, it's not like PlayDead are selling this, so maybe someone else will get around to it!

I've jsut added Motion Vector support for one of my effect so far it works great.
So I think I can make it work for this too.


Needless sudo?

Thank you for publishing this wonderful feature!
I see sudo is used within the install script, but this script is assumed to be run as root, so probably unnecessary?
I also think sudo may not be installed in the base image.

The install.sh script for each Feature should be executed as root during a container image build.

https://containers.dev/implementors/features/#invoking-installsh
https://github.com/stuartleeks/dev-container-features/blob/4ef7c8ae0a65fa242e30427aa425609b7de6a24e/src/shell-history/install.sh#L27

Good point
When I looked at the script again, it wasn't clear to me whether the sudo calls added to .bashrc etc could be removed, but I've just tested with a new container/volume and it appears that they can!

Thanks for the quick update!

Just realised that I had inadvertently picked up a cached feature definition in my tests. After re-running, it looks like the calls in the .bashrc etc are required so I'll revert part of the change I made


Doesn't work with iTerm2 3.0.0 (stable) or later

Just updated iTerm2 to version 3.0.2 and it still doesn't work. I select the commands, but it appears Shuttle doesn't interact with the new version at all. I guess it's an applescript issue again.

If you have a really old version of shuttle you will have to update your shuttle.json to have the nightly directive "iTerm_version":"nightly"  Also check out this issue. #176 and this pull #175
Also make sure that your global settings reflect the default profile in iTerm or make sure that your iTerm has a default profile and that profile is called "Default" also make sure that your iTerm is not set Don't Open Any Windows in Preferences/General/Startup
I'm using 10.11.5 and I have iTerm 3 nightly everything is working so it seems that its a configuration problem.
Please check these things and report back.

The issue is about the stable iTerm2 branch, not the nightly one. And my Shuttle version is the latest one.

Confirmed.   With Shuttle 1.2.6 and iTerm 3.0.4 (latest stable) it does not work.   Shuttle will launch the iTerm2 app, but fails to inject anything on the command line.
Downgraded to iTerm2 2.1.14.    Shuttle works correctly with this version

Same problem here. Another hint: if iTerm is closed, Shuttle does open it but then the iTerm window crashes and closes all of a sudden, without prompting the "cmd".

Ah! Thanks for the extra info... this is because the shuttle directive "iTerm_version":"stable" launches the applecripts for the legacy iTerm 2.14
Even though you are using iTerm stable tell shuttle that you are on the nightly branch using  "iTerm_version":"nightly" and everything should be okay.
Now that iTerm 3.x is out and in the Stable branch perhaps shuttle should be more specific with its names.
Let me know if this works for you.

Changing it to nightly does correctly launch and inject the command line
with 3.0.4.
Yes you might want to make changes around the iTerm version used.
Someone has forked and is upgrading the original iTerm program and calling
it iTerm3.    So perhaps something like iTerm_program: iTerm, iTerm2,
iTerm3, (next).   Then iTerm_version based on iTerm_program.   With
iTerm2...  2.x, 3.x, stable, nightly.
On Wed, Jul 6, 2016 at 11:15 AM, Matt Turner<EMAIL_ADDRESS>wrote:

Ah! Thanks for the extra info... this is because the shuttle directive
"iTerm_version":"stable" launches the applecripts for the legacy iTerm
2.14
Even though you are using iTerm stable tell shuttle that you are on the
nightly branch using "iTerm_version":"nightly" and everything should be
okay.
Now that iTerm 3.x is out and in the Stable branch perhaps shuttle should
be more specific with its names.
Let me know if this works for you.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fitztrev/shuttle/issues/181#issuecomment-230823558,
or mute the thread
https://github.com/notifications/unsubscribe/AAssEc30ulSygkN52ZbZUV_8G2H8p6q1ks5qS9SzgaJpZM4JC0Zq
.

@mkoepke Thanks for the update.
I want shuttle to support iTerm 2.14 as some user may still want to use it. Now that that 3.x is in Stable there will be no apple script changes.
I propose we have 3 directives
"iTerm_version":"legacy"

This supports the legacy 2.14 version
"iTerm_version":"stable"

This supports the now stable iTerm 3.x branch
"iTerm_version":"nightly"

This supports the nightly versions of iTerm

That makes sense.
On Wed, Jul 6, 2016 at 11:59 AM, Matt Turner<EMAIL_ADDRESS>wrote:

@mkoepke https://github.com/mkoepke Thanks for the update.
I want shuttle to support iTerm 2.14 as some user may still want to use
it. Now that that 3.x is in Stable there will be no apple script changes.
I propose we have 3 directives
"iTerm_version":"legacy"
This supports the legacy 2.14 version
"iTerm_version":"stable"
This supports the now stable iTerm 3.x branch
"iTerm_version":"nightly"
This supports the nightly versions of iTerm
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fitztrev/shuttle/issues/181#issuecomment-230837048,
or mute the thread
https://github.com/notifications/unsubscribe/AAssESQ3pZttiRCps8Y_dAjH3ceSaEkbks5qS98IgaJpZM4JC0Zq
.

@mkoepke Thanks for the feedback... I'll wait for some more feedback and if users agree I'll put these changes in 1.2.7

No argue from me too. The more options we have, the better!

@philippetev
Thanks for the feedback. I'll proceed with the following:
"iTerm_version":"legacy"

This will support the applescripts that work the legacy iTerm 2.14 version
"iTerm_version":"stable"

This will support the applescripts that work with the iTerm stable 3.x branch
"iTerm_version":"nightly"

This will support the applescripts that work with the nightly versions of iTerm
Until these changes make it to 1.2.7; everyone that is using the new iTerm stable will need to tell shuttle that your using nightly

Came here with the same problem; telling shuttle I'm using nightly solved it. Thanks 👍

@johnpuddephatt You're welcome! I'll have this fixed in the next version.

Closed! fixes are in 1.2.7


CRITICAL:main:Unable to open device: open failed

Hello,
I have a problem starting pyocd gdbserver.
sudo pyocd gdbserver
0000309:INFO:board:Target type is k64f
0000309:CRITICAL:__main__:Unable to open device: open failed
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pyocd/probe/pydapaccess/interface/hidapi_backend.py", line 49, in open
    self.device.open_path(self.device_info['path'])
  File "hid.pyx", line 72, in hid.device.open_path
OSError: open failed

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pyocd/probe/cmsis_dap_probe.py", line 141, in open
    self._link.open()
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pyocd/probe/pydapaccess/dap_access_cmsis_dap.py", line 545, in open
    self._interface.open()
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pyocd/probe/pydapaccess/interface/hidapi_backend.py", line 51, in open
    raise six.raise_from(DAPAccessIntf.DeviceError("Unable to open device: " + str(exc)), exc)
  File "<string>", line 3, in raise_from
pyocd.probe.pydapaccess.dap_access_api.DAPAccessIntf.DeviceError: Unable to open device: open failed

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pyocd/__main__.py", line 343, in run
    self._COMMANDS[self._args.cmd](self)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pyocd/__main__.py", line 571, in do_gdbserver
    with session:
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pyocd/core/session.py", line 287, in __enter__
    self.open()
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pyocd/core/session.py", line 363, in open
    self._probe.open()
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pyocd/probe/cmsis_dap_probe.py", line 153, in open
    six.raise_from(self._convert_exception(exc), exc)
  File "<string>", line 3, in raise_from
pyocd.core.exceptions.ProbeError: Unable to open device: open failed

Please provide more information. What probe are you using? What OS and version? I can make guesses, but I'd rather not.

Thank you for the quick response. I am on macOS mojave and using segger j-link on frdm-k64f.

pyOCD doesn't support J-Link probes; it supports CMSIS-DAP and STLink (see the readme for details). It shouldn't even try to connect, or show an available probe, if you only have a J-Link connected.
It's unclear what it is attempting to connect to… the log shows it using the hidapi backend, which only supports USB HID interfaces, but J-Link only provides a vendor-specific bulk interfaces, so hidapi should not see it at all.
Btw, you should never run pyOCD via sudo on a Mac, nor should you ever need to.
Could you please provide the output of these two commands:

pyocd list -vv
pyocd gdb -vv

This might help shed some light on what it's trying to connect to.

pyocd list -vv
0000567:DEBUG:session:Project directory: /Users/murdocgal
Probe              Unique ID

0   FRDM-K64F [k64f]   024002261e101e0d000000000000000000000000e3c9e3b5
pyocd gdb -vv
0000551:DEBUG:session:Project directory: /Users/murdocgal
0000557:INFO:board:Target type is k64f
0000562:DEBUG:dap_access_cmsis_dap:CMSIS-DAP probe 024002261e101e0d000000000000000000000000e3c9e3b5 firmware version: 1.0
0000570:DEBUG:sequencer:Running task load_svd
0000572:DEBUG:sequencer:Running task create_flash
0000572:DEBUG:sequencer:Running task dp_init
0000612:INFO:dap:DP IDR = 0x2ba01477 (v1 rev2)
0000612:DEBUG:sequencer:Running task power_up
0000614:DEBUG:sequencer:Running task find_aps
0000620:DEBUG:sequencer:Running task create_aps
0000620:DEBUG:sequencer:Running task create_ap.0
0000624:INFO:ap:AP#0 IDR = 0x24770011 (AHB-AP var1 rev2)
0000626:DEBUG:ap:AP#0 default HPROT=3 HNONSEC=0
0000628:DEBUG:ap:AP#0 implemented HPROT=3 HNONSEC=0
0000630:DEBUG:sequencer:Running task create_ap.1
0000638:INFO:ap:AP#1 IDR = 0x001c0000 (proprietary)
0000638:DEBUG:sequencer:Running task check_mdm_ap_idr
0000638:DEBUG:target_kinetis:MDM-AP version 0
0000639:DEBUG:sequencer:Running task check_flash_security
0000667:INFO:target_kinetis:K64F not in secure state
0000667:DEBUG:sequencer:Running task init_ap_roms
0000667:DEBUG:sequencer:Running task init_ap.0
0000680:INFO:rom_table:AP#0 ROM table #0 @ 0xe00ff000 (designer=43b part=4c4)
0000711:INFO:rom_table:[0]<e000e000:SCS-M4 class=14 designer=43b part=00c>
0000716:INFO:rom_table:[1]<e0001000:DWT class=14 designer=43b part=002>
0000725:INFO:rom_table:[2]<e0002000:FPB class=14 designer=43b part=003>
0000731:INFO:rom_table:[3]<e0000000:ITM class=14 designer=43b part=001>
0000738:INFO:rom_table:[4]<e0040000:TPIU-M4 class=9 designer=43b part=9a1 devtype=11 archid=0000 devid=0:0:ca1>
0000745:INFO:rom_table:[5]<e0041000:ETM-M4 class=9 designer=43b part=925 devtype=13 archid=0000 devid=0:0:0>
0000751:INFO:rom_table:[6]<e0042000:ETB class=9 designer=43b part=907 devtype=21 archid=0000 devid=0:0:0>
0000757:INFO:rom_table:[7]<e0043000:CSTF class=9 designer=43b part=908 devtype=12 archid=0000 devid=0:0:28>
0000757:DEBUG:sequencer:Running task create_cores
0000757:DEBUG:coresight_target:Creating SCS-M4 component
0000762:INFO:cortex_m:CPU core #0 is Cortex-M4 r0p1
0000771:INFO:cortex_m:FPU present: FPv4-SP
0000816:DEBUG:sequencer:Running task halt_on_connect
0000824:DEBUG:sequencer:Running task create_components
0000824:DEBUG:coresight_target:Creating DWT component
0000831:INFO:dwt:4 hardware watchpoints
0000831:DEBUG:coresight_target:Creating FPB component
0000838:INFO:fpb:6 hardware breakpoints, 4 literal comparators
0000838:DEBUG:fpb:fpb has been disabled
0000846:DEBUG:coresight_target:Creating ITM component
0000874:DEBUG:coresight_target:Creating TPIU-M4 component
0000882:DEBUG:sequencer:Running task check_for_cores
0000882:DEBUG:sequencer:Running task notify
0000954:INFO:server:Semihost server started on port 4444
0000966:INFO:gdbserver:GDB server started on port 3333

pyocd gdb is working now. What changed? Maybe that you weren't running as root?
Also, you don't have the J-Link firmware installed on your FRDM-K64F, you have DAPLink installed. (Evident by the fact that it shows up at all with pyocd list, and the unique ID format.)

I don't see any issues here? The gdbserver is running succesfully.
Can this issue be closed?

@medjutim Can this issue be closed now?


Move match length setting to number of seconds integer passed via MPM…

…odPrivateData
(Note this value in the .json files for the presets should now be represented in seconds as well instead of the old enum - will need coordination or transition period)

@tobiasksu
What happens if I create a 13 minute game, and an 0.3.9 client joins?

@roncli
Works - tested this scenario.
Old client starts game on new server = OK
New client starts game on new server = OK
Where it will go bad is new client starting match on an old server, do we want effort to prevent that?

Like, the "right" answer is yes, but the practical answer is probably not... how many olmod players are going to try to create a game on a vanilla server?

@maestrodk Heads up that me and you are going to have to coordinate changes to the .json files on the OTL and OCT sites.  Won't be until like the 2nd week of May, I think.


Adds "Google Authenticator" to the list of recommended extensions

This PR adds the extension "Google Authenticator" to the "System" list where recommended extensions are listed.
Install the patch and check the functionality! :-)

You need to increase the version number in meta.xml file.

[ ] Add promo block

Solved all issues, please re-check. Thank you!


Cell motion detection missing

Description
Entities Cell Motion Detection is not provided by Tapo-Control anymore after updating to 5.7.2.
Integration-Overview is showing Versionnumber 5.6.3 after updating and restarting HASS...
Reproduction Steps
Update to 5.7.2, check your entities from Tapo-Control, Entities Cell Motion is marked as not provided anymore
Expected behavior
Entities Cell Motion Detection should be available, or at least another binary-sensor, so that we could react on motion.
If applicable, add error logs.
No response
Device Firmware
1.2.8 Build 240606 Rel.39146n
Integration Version
5.7.2
Using stream component
No
Does camera work via official integrations?
Yes
Camera has all attributes filled out in developer tools
No
HASS Environment
VM on Synology NAS
Search for similar issues
Yes
Additional information
No response

Read FAQ. Nothing changed regarding this between updates.


USA weird death cases predictions depending on random execution trials

Summary
For USA, the confirmed cases predictions for 24Oct20 are a little bit off by ~250.000, but deaths cases predictions are totally wrong (actual ~229.000, predicted ~455.000 almost doubled). The first time I executed:
Codes and outputs:
   usa_scenario = cs.Scenario(jhu_data, pop_data, "USA")
   usa_scenario.records().tail()
   _ = usa_scenario.trend()
   usa_scenario.summary()
   usa_scenario.estimate(cs.SIRF)
   usa_scenario.summary()
   _ = usa_scenario.history_rate()
   usa_scenario.clear()
   usa_scenario.add(days=7)
   usa_pred = usa_scenario.simulate() -> observe usa_pred

I found a weird way to overcome this though.

Why is this happening and how can this be solved? Please further investigate.
Also, one time I noticed and a third behavior. On some execution trial the weird death predictions followed the same weird triangular pattern (as in Greece deaths predictions, see #271 and as in Russia/Spain death predictions, see #273). And this time if I rerun the analysis as I said before without reinitializing the scenario object, the error now still persists. It is very weird and frustrating and seems to be random depending on the execution trial.

Also, the predicted confirmed cases are wrong (280.000 cases off) compared with the actual data.

Environment

CovsirPhy version: 2.9.1
Python version; 3.8
Installation: Anaconda, Spyder, pip
OS: Windows

Please help with me to try Scenario.estimate(cs.SIRF, timeout=120) mentioned in #274 to find the cause.

Except for 0th phase (09Feb2020 - 05May2020), I did not find weired results with COVID-19 Data Hub. We need to focus on 0th phase.
https://github.com/lisphilar/covid19-sir/blob/master/example/scenario_analysis_usa.py
Actual data:

Simulated data:

Summary:

Start
End
Rt
theta
kappa
rho
sigma
tau
RMSLE
Trials
Runtime

9-Feb-20
5-May-20
5
0.00102
0.001213
0.021878
0.003155
720
20.79586
939
1 min  0 sec

6-May-20
14-Jun-20
2.1
0.032899
0.000237
0.009478
0.004134
720
0.190943
954
1 min  0 sec

15-Jun-20
5-Jul-20
3.62
0.001569
0.000191
0.01195
0.003101
720
0.036643
959
1 min  0 sec

6-Jul-20
18-Jul-20
4.39
0.009637
1.43E-05
0.015224
0.003423
720
0.01313
225
0 min 15 sec

19-Jul-20
29-Jul-20
2.43
0.001015
0.00015
0.012798
0.005119
720
0.008411
227
0 min 15 sec

30-Jul-20
12-Aug-20
2.11
0.016288
3.93E-05
0.008762
0.004049
720
0.00849
471
0 min 30 sec

13-Aug-20
27-Aug-20
1.8
0.020675
1.42E-05
0.006329
0.003422
720
0.007471
218
0 min 15 sec

28-Aug-20
13-Sep-20
1.62
0.003562
7.91E-05
0.005084
0.003047
720
0.008261
155
0 min 10 sec

14-Sep-20
29-Sep-20
1.71
0.000461
9.81E-05
0.005108
0.00289
720
0.00807
333
0 min 20 sec

30-Sep-20
12-Oct-20
2.34
0.001674
5.43E-05
0.005576
0.002324
720
0.006276
174
0 min 10 sec

13-Oct-20
22-Oct-20
2.39
0.004536
9.26E-05
0.006864
0.002772
720
0.006384
175
0 min 10 sec

23-Oct-20
1-Nov-20
2.57
0.000555
0.000111
0.007181
0.00268
720
0.007266
683
0 min 25 sec

That's interesting, because if I run USA analysis, not by that script, but using the following lines (which do the same thing), it shows weird cases (I run with version 2.9.1-beta.fix.282.283):
import covsirphy as cs

from collections import defaultdict
from datetime import timedelta
from dateutil.relativedelta import relativedelta
import functools
from IPython.display import display, Markdown
import math
import os
from pprint import pprint
import matplotlib.pyplot as plt
import matplotlib.cm as cm
import matplotlib
from matplotlib.ticker import ScalarFormatter
get_ipython().run_line_magic('matplotlib', 'inline')
import numpy as np
import pandas as pd
import dask.dataframe as dd
pd.plotting.register_matplotlib_converters()
import seaborn as sns
import scipy as sci
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.cluster import KMeans
import sympy as sym

np.random.seed(123)
os.environ["PYTHONHASHSEED"] = "123"
# Matplotlib
plt.style.use("seaborn-ticks")
plt.rcParams["xtick.direction"] = "in"
plt.rcParams["ytick.direction"] = "in"
plt.rcParams["font.size"] = 11.0
plt.rcParams["figure.figsize"] = (9, 6)
# Pandas
pd.set_option("display.max_colwidth", 1000)

data_loader = cs.DataLoader(directory="kaggle/input")
jhu_data = data_loader.jhu()
population_data = data_loader.population()
usa_scenario = cs.Scenario(jhu_data, population_data, "USA")
usa_scenario.records().tail()
_ = usa_scenario.trend()
usa_scenario.summary()
usa_scenario.estimate(cs.SIRF)
usa_scenario.summary()
_ = usa_scenario.history_rate()
usa_scenario.clear()
usa_scenario.add(days=7)
usa_scenario.simulate().tail(7).style.background_gradient(axis=0)

[MAJOR UPDATE!!!]:
What causes the weird results in my code is the following two imports:
import seaborn as sns
import sympy as sym
When they are both, it creates I guess some kind of conflict, please further investigate!

I tried scenario_analysis_usa.py code with importing seaborn and sympy without def main() for 5 times, but I could not reproduce the weired result.
Please kindly share the output of Scenario.summary() to see RMSLE scores and runtime.

I will post these results too when I get home from work. Are you running this in windows and in interactive console? I think that probably the root cause is in the multiprocessing.

I ran this code in

local environment: Windows subsystem for Linux / Ubuntu
Google Colaboratory

And what plots do you get for USA?
Is it possible for you to try it also in Spyder?

Please see my codes and outputs with Google Colab (2 CPUs, Python 3.6.9) on
https://gist.github.com/lisphilar/4d9dbc5ea39ef808e2139e2fd4b655f4
I have not installed and used Spyder, but I will try it tomorrow. I'm using Bash in WSL and VS code for coding and running codes.

Have you tried Spyder? I tried to use n_jobs=1; sometimes it runs smoothly (after a long long time), but usually it has similar results:

I also run your single py file and had this result:

which is very very wrong about the deaths simulated cases at the end (the quickly rising line):

21-10-20
8401849
224660
4869492
3307697

22-10-20
8474386
225862
4918341
3330183

23-10-20
8547633
227075
4967664
3352894

24-10-20
8621600
228301
5017465
3375834

25-10-20
8696290
229539
5067748
3399003

26-10-20
8704446
225714
5018277
3460455

27-10-20
8785132
249457
5049937
3485738

28-10-20
8866306
273344
5081782
3511180

29-10-20
8947973
297376
5113814
3536783

30-10-20
9030133
321553
5146033
3562547

31-10-20
9112790
345876
5178441
3588473

01-11-20
9195945
370346
5211037
3614562

02-11-20
9279604
394964
5243824
3640816

03-11-20
9363767
419731
5276801
3667235

04-11-20
9448437
444646
5309971
3693820

05-11-20
9533617
469712
5343333
3720572

06-11-20
9619310
494929
5376889
3747492

07-11-20
9705518
520297
5410640
3774581

08-11-20
9792244
545818
5444586
3801840

09-11-20
9879491
571492
5478729
3829270

10-11-20
9967261
597320
5513069
3856872

11-11-20
10055557
623303
5547607
3884647

12-11-20
10144383
649442
5582345
3912596

I installed Spyder4 and Python 3.8 with Anaconda3 in WIndows OS for the first time.
Then, I install Covsirphy version 2.10.0 (codes are the same as 2.9.1-theta) and ran the next codes.
import seaborn as sns
import sympy as sym
import covsirphy as cs

cs.__version__

# Load datasets
data_loader = cs.DataLoader("input")
jhu_data = data_loader.jhu(verbose=False)
population_data = data_loader.population(verbose=False)
# Set country name
country = "United States"
abbr = "usa"
# Start scenario analysis
snl = cs.Scenario(jhu_data, population_data, country)

# Show records
snl.records().tail()

# Show S-R trend
snl.trend().summary()

# Parameter estimation
snl.estimate(cs.SIRF)
snl.summary()

# Add future phase to main scenario
snl.add(name="Main", days=7)
# Simulation of the number of cases
snl.simulate(name="Main").tail()

However, parameter estimation in phases except for 11th phase was not completed for > 10 min.

I'm trying a solution with https://stackoverflow.com/questions/48078722/no-multiprocessing-print-outputs-spyder (Run > Configuration per file > Execute in an external system terminal), but the codes do not finish.

Is it necessary to upload CovsirPhy package to Anaconda?

Is it necessary to upload CovsirPhy package to Anaconda?

I don't think so, you can run inside a conda environment "pip install covsirphy" first and then run from there spyder (at least that's what I am doing)

I did pip installation in conda console and get the error I mentioned in the above.
Are the other settings necessary for multiprocessing in Spyder?
Or, please share the output of Scenario.summary() to discuss runtime and the number of trials.

As far as I know, no. The multiprocessing runs automatically, unless specified otherwise. But as I said earlier, it is problematic inside an interactive python console, such as Spyder's.

However, parameter estimation in phases except for 11th phase was not completed for > 10 min.

Oh I thought you were referring to an error! This is normal behavior I guess, only the last phase result is printed out in the console! This happens to my executions as well all the time for multiprocessing. But this is not an error I think.
My result with multiprocessing is:
<SIR-F model: parameter estimation>
Running optimization with 12 CPUs...
	11th phase (27Oct2020 - 06Nov2020): finished  630 trials in 1 min  1 sec
Completed optimization.

Change timeout of estimation: Scenario.estimate(cs.SIRF, timeout=60) (default: 60 sec) to Scenario.estimate(cs.SIRF, timeout=120) (120 sec)
Improve covsirphy.simulation.Estimator etc. to cut runtime

I'm trying the second solution for log time, but I could not find how to improve it.

Did you find any solution for the weird simulated results?

For the USA what bothers me is the triangular curve and for Spain the totally wrong deaths.
Any news for the Spyder problems? What can I do to have more normal results?

I could not reproduce your figures with Spyder.
I'm trying to improve Estimator class in #270 and #291 .
Please try to

use timeout argument as I mentioned in the previous comment and
run scripts with command line tools in Windows, not Spyder, to find the root cause.

Oh yes you are right, the small timeout seems to be the root cause for some reason. I use now always timeout=120. But why is this needed? I think you don't use 120sec right?  Is this platform dependent?
Nevertheless, for USA I have this weird infected spike at the beginning, which you don't have:

And for Spain, despite the fact that the curves seem normal, the simuled cases error is big, for confirmed ~20% and for deaths ~6.4% (compared to today's cases, 12Nov20)

Required runtime of parameter estimation depends on CPU performance. Max value of runtime is set as timeout argument. With Estimator class, CovsirPhy continues estimation while runtime does not over timeout and max simulated number of cases is not in the range of (max actual number * 0.98, max actual number * 1.02).
I changed default value of timeout from 60 sec to 180 sec with issue #291 and pull request #327.
Please find the results for USA and Spain with Google Colab and version 2.10.0-mu as-of 13Nov2020.
https://gist.github.com/lisphilar/6d235d2ca3355e54687ba8cd27815022#file-usa_spain_13nov2020-ipynb
Do you have any ideas to improve Estimator and ChangeFinder.run()?
Spikes are raised when accuracy of estimation is low and the number of cases are over-estimated. This is because of normal behaivior that initial values of past phases are fixed to the initial values of actual data of the phases.

Yes fortunately I have now the same results with you at last! The timeout parameter is very significant.
I have some questions about the results for Spain.
What does this line mean in the figure?

And most importantly, why the recovered and deaths curves are not strictly monotonically increasing? Should be added a check during the simulation, that the results (deaths, recovered and confirmed) must monotonically increase?

What does this line mean in the figure?

The line means that there are many phases in the narrow range. This is because the number of infeced cases increased sharply.

why the recovered and deaths curves are not strictly monotonically increasing?

This is because simulation is performed in each phase and conbined. For the change dates of phases, values of start dates of next phases will be used. When accuracy of estimation is low and the number of cases are over-estimated, spikes occur and monotonic increasing is broken.
For Spain, I think the first four phases are accurately splited. Estimator should be improved.

So in order to overcome these spikes occurrences and ensure monotonic increasing behavior, what should we do?
For the simulated cases right before and after the phase change date, could we rework the values and adapt them in such a way that it is monotonically increasing?

I do not have create ideas, but rework after estimation could be selected as you mentioned.

Check that the previous phase values are in user-defined allowance (0.98, 1.02) of the next phase values.
If not in the allowance, find internal chane dates in the previous phase.
Try parameter estimation

I updated my idea.
New method Scenario.trend_estimate(model, timeout=120, max_iteration=3, **kwargs) performs the following steps.

S-R trend analysis with all records
Parameter estimation in each phase with timeout
S-R trend analysis with the phases in which estimation failed
Parameter estimation in new phases with 'timeout`
Repeat.

The results with version 2.13.1-alpha are in https://gist.github.com/lisphilar/8f64aca428a3eb065c8c39ef827b3fc5
We move forward to #354 (and new issues) to improve the accuracy of parameter estimation.


fix inconsistent behavior on toggle button delay

Details

In withDelayToggleButtonState HOC, don't clear and restart timer when press while in delay state
In CopyTextToClipboard, replace showCheckmark timeout logic with withDelayToggleButtonState

Fixed Issues
$ https://github.com/Expensify/App/issues/17751
PROPOSAL: https://github.com/Expensify/App/issues/17751#issuecomment-1523206935
Tests
Same as QA step

[ ] Verify that no errors appear in the JS console

Offline tests
Same as QA step
QA Steps

Login any account
Go to Settings > Workspaces > any workspace > Reimburse expenses
Click copy icon many times quickly
Verify that copy icon changed to copied and keep copied icon with no impact on pressing for 1800ms
Verify that after 1800ms, it resets to copy icon and able to press again
Press icon again and verify Steps 4. and 5.
Go to any chat and click user profile avatar in any chat message
Repeat Steps 3-6
Go to Settings > Profile > Contact method
Repeat Steps 3-6

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://user-images.githubusercontent.com/96077027/236384421-ab140ff1-e3ae-4720-ac17-d24e9b9f8fe8.mov

Mobile Web - Chrome
https://user-images.githubusercontent.com/108292595/236383108-424ceb02-dd1d-4d6f-ba97-aa02f9eb4ff1.mov

Mobile Web - Safari
https://user-images.githubusercontent.com/108292595/236383078-b822b479-3b11-477c-b35a-0f0d03ae1548.mov

Desktop
https://user-images.githubusercontent.com/96077027/236384450-2691ab22-e0ac-4501-96eb-9c1ea42e62e3.mov

iOS
https://user-images.githubusercontent.com/108292595/236383000-33502063-9b10-4a52-b10d-f04fdc1fa8aa.mov

Android
Not able to test android because of this known issue - #17368

Thanks @situchan. Looking at the code change, I spent sometime trying to dig deeper. Here are my findings:

I think that it doesn't makes sense to call toggleDelayButtonState() when isDelayButtonStateComplete is already true.

This PR introduced the change in ContextMenuItem to call toggleDelayButtonState even if isDelayButtonStateComplete is true to solve this issue. As already discussed in the PR, the issue is still reproducible. I think new issue is created to handle it which will also solve the issue with multiple clicks. cc: @thesahindia @tgolen

So, I will propose the following changes:

Let's not call toggleDelayButtonState when isDelayButtonStateComplete is already true. Some changes made in this PR will be reverted.

Want to know your thoughts @tgolen @thesahindia @situchan ?
(Context: We are trying to make "Copy to Clipboard" icon consistent throughout the app)

I agree with @sobitneupane as long as it doesn't cause regression of what https://github.com/Expensify/App/pull/17286 fixed and also fixes https://github.com/Expensify/App/issues/17751

@thesahindia What do you think of this suggestion? And have we already created the issue to handle this issue that you raised? It should solve the issue of multiple clicks as well.

@situchan I think we are now good to go with the suggested changes.

@sobitneupane ready for review

Please do update the screen recordings to reflect the latest changes.

@situchan Changes you made in withDelayToggleButtonState can be unchanged now. In fact, some of the code added in https://github.com/Expensify/App/pull/17286/files can be removed.

That's correct. But as withDelayToggleButtonState is low level HOC, isn't it safe to add my changes?
As clearTimeout is removed, there might be multiple setTimeout at the same time (though not exist in our codebase)

I would prefer removing if it is of no use now. It can always be added back whenever required. But If it has any current use case, we can keep it.

Thanks for the reviews. Anything remaining before merge?

No, I tried to merge it earlier today and couldn't (github was facing some issues). Doing it now.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/danieldoglas in version: 1.3.13-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/Beamanator in version: 1.3.13-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Initial startup fails on Catalina with SBCL

$ sbcl --load ./cl-jupyter.lisp
This is SBCL 1.5.9, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
... initialization mode... please wait...
To load "cl-jupyter":
  Load 1 ASDF system:
    cl-jupyter
; Loading "cl-jupyter"
...While evaluating the form starting at line 5, column 0
  of #P"/Users/glenhenshaw/Code/cl-jupyter/./cl-jupyter.lisp":

debugger invoked on a ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR in thread
#<THREAD "main thread" RUNNING {10005184C3}>:
  OPERATION instances must only be created through MAKE-OPERATION.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY                        ] Retry
                                     compiling #<GROVEL-FILE "pzmq" "grovel">.
  1: [ACCEPT                       ] Continue, treating
                                     compiling #<GROVEL-FILE "pzmq" "grovel">
                                     as having been successful.
  2:                                 Retry ASDF operation.
  3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the
                                     configuration.
  4:                                 Retry ASDF operation.
  5:                                 Retry ASDF operation after resetting the
                                     configuration.
  6: [ABORT                        ] Give up on "cl-jupyter"
  7: [RETRY                        ] Retry EVAL of current toplevel form.
  8: [CONTINUE                     ] Ignore error and continue loading file "/Users/glenhenshaw/Code/cl-jupyter/./cl-jupyter.lisp".
  9:                                 Abort loading file "/Users/glenhenshaw/Code/cl-jupyter/./cl-jupyter.lisp".
 10:                                 Ignore runtime option --load "./cl-jupyter.lisp".
 11:                                 Skip rest of --eval and --load options.
 12:                                 Skip to toplevel READ/EVAL/PRINT loop.
 13: [EXIT                         ] Exit SBCL (calling #'EXIT, killing the process).

(ASDF/SESSION:SYSDEF-ERROR "OPERATION instances must only be created through MAKE-OPERATION.")
   source: (ERROR 'FORMATTED-SYSTEM-DEFINITION-ERROR :FORMAT-CONTROL FORMAT
                  :FORMAT-ARGUMENTS ARGUMENTS)
0]

Since it's the last version of sbcl there may be some incompatible dependency ? The error seems related to ASDF (and maybe quicklisp ?). I'll try to reproduce it anyways.

...I think this is probably pilot error. Uninstalling sbcl via Homebrew, followed by deleting the quick lisp directory and installing from scratch, appears to mostly have solved the problem.
The one remaining problem was an error when starting the Jupyter lisp kernel that reported that "sbcl" cannot be found. Homebrew installs into /usr/local/bin, and it looks like Jupyter isn't looking there. So I modified the json file directly to give it an absolute path to sbcl and then it started working.


feat: Add example code snippets for fine grained access control tokens

Add code examples of generating tokens with different permissions for GenerateAuthToken docs
~Builds will fail on the PR workflow jobs because the SDK changes are not yet merged/released but I have run these locally.~ Fixed by updating sdk version after new momento sdk was released

><EMAIL_ADDRESS>doc-examples
> tsc && node dist/doc-example-files/doc-examples-js-apis.js

[2023-07-11T01:00:29.152Z] INFO (Momento: CacheClient): Creating Momento CacheClient
[2023-07-11T01:00:29.170Z] INFO (Momento: CacheClient): Creating Momento CacheClient
[2023-07-11T01:00:29.171Z] INFO (Momento: ControlClient): Creating cache: test-cache
Cache 'test-cache' created
Key 'test-key' was not found in cache 'test-cache'
Key 'test-key' stored successfully
[2023-07-11T01:00:29.686Z] INFO (Momento: ControlClient): Deleting cache: test-cache
Cache 'test-cache' deleted
[2023-07-11T01:00:29.713Z] INFO (Momento: ControlClient): Creating cache: test-cache
Cache 'test-cache' created
Caches:
default-cache
momento-loadgen
test-cache
cache

Cache 'test-cache' flushed
Key 'test-key' stored successfully
Retrieved value for key 'test-key': test-value
Key 'test-key' deleted successfully
Key 'test-key' incremented successfully. New value in key test-key: 11
Item type retrieved successfully: SCALAR
Key 'test-key' already exists in cache 'test-cache', so we did not overwrite it
List fetched successfully: a,b,c
Values added successfully to the back of the list 'test-list'. Result - Success: listLength: 9
Values added successfully to the front of the list 'test-list'. Result - Success: listLength: 15
Length of list 'test-list' is 18
Last value was removed successfully from list 'test-list': three
First value was removed successfully from list 'test-list': one
Value 'x' added successfully to back of list 'test-list'
Value 'x' added successfully to front of list 'test-list'
Value 'b' removed successfully from list 'test-list'
Retaining elements from index 1 to 4 from list 'test-list'
Dictionary fetched successfully-
test-field : test-value
Field test-field fetched successfully from cache 'test-cache' with value: test-value
Values fetched successfully-
key1 : value1
key2 : value2
Field set successfully into cache 'test-cache'
Fields set successfully into cache 'test-cache'
Field value incremented by 1. Result - 11
Field removed successfully from dictionary 'test-dictionary'
Fields removed successfully from dictionary 'test-dictionary'
Element added successfully to set 'test-set'
Elements added successfully to set 'test-set'
Set fetched successfully-
test-element1 : test-element1
test-element2 : test-element2
test-element : test-element
Element 'test-element' removed successfully from set 'test-set'
Elements 'test-element1' and 'test-element2' removed successfully from set 'test-set'
Value 'test-value' with score '5' added successfully to sorted set 'test-sorted-set'
Elements added successfully to sorted set 'test-sorted-set'
Values from sorted set 'test-sorted-set' fetched by rank successfully-
test-value : 5
key1 : 10
key2 : 20
Values from sorted set 'test-sorted-set' fetched by score successfully-
test-value : 5
key2 : 25
key1 : 100
Element with value 'key1' has rank: 2
Element with value 'key1' has score: 10
Element scores retrieved successfully -
key1 : 10
key2 : 20
Score for value 'test-value' incremented successfully. New score - 11
Element with value 'test-value' removed successfully
Elements with value 'key1' and 'key2 removed successfully
Generated an auth token with AllDataReadWrite scope!
Auth token starts with: eyJlbmRwb2
Refresh token starts with: eyJhbGciOi
Expires At:<PHONE_NUMBER>
Generated an auth token with read-only access to cache foo!
Auth token starts with: eyJlbmRwb2
Refresh token starts with: eyJhbGciOi
Expires At:<PHONE_NUMBER>
Generated an auth token with read-write access to all caches!
Auth token starts with: eyJlbmRwb2
Refresh token starts with: eyJhbGciOi
Expires At:<PHONE_NUMBER>
Generated an auth token with publish-subscribe access to all topics within cache bar!
Auth token starts with: eyJlbmRwb2
Refresh token starts with: eyJhbGciOi
Expires At:<PHONE_NUMBER>
Generated an auth token with subscribe-only access to topic where_is_mo within cache mo_nuts!
Auth token starts with: eyJlbmRwb2
Refresh token starts with: eyJhbGciOi
Expires At:<PHONE_NUMBER>
Generated an auth token with multiple cache and topic permissions!
Auth token starts with: eyJlbmRwb2
Refresh token starts with: eyJhbGciOi
Expires At:<PHONE_NUMBER>
Generated auth token; refreshing!
Auth token refreshed!
Refreshed auth token starts with: eyJlbmRwb2
New refresh token starts with: eyJhbGciOi
Refreshed auth token expires At:<PHONE_NUMBER>
[2023-07-11T01:00:32.233Z] INFO (Momento: TopicClient): Creating Momento CacheClient
[2023-07-11T01:00:32.237Z] INFO (Momento: TopicClient): Creating Momento CacheClient
Value published to topic 'test-topic'
Successfully subscribed to topic 'test-topic'
Publishing values to the topic 'test-topic': test-value
Waiting for the published values

Can you demonstrate the common errors one would see? Eg cache does not exist, invalid permission combination, ...

Caches and topics do not need to exist when the token is created. Invalid permission combination would make it very verbose. I will add a check for error in the snippet

Caches and topics do not need to exist when the token is created. Invalid permission combination would make it very verbose. I will add a check for error in the snippet

👍  That's fine -- I meant to just add error handling for the common failure cases.


Streaam Collector: fix stdout artifact build

Project: Scala Stream Collector - stdout
Version: 1.0.0
Expected behavior: The jar should be created with name - snowplow-stream-collector-stdout-{$versionn-no}.jar
Actual behavior: The project just clean and compile and no jar is created
Steps to reproduce:
sbt "project stdout" assembly

Just try to create an assembly for scala stream collector module where the output set to stdout  -
using the command -
sbt "project stdout" assembly

PR already create to resolve it -
https://github.com/snowplow/snowplow/pull/4278

Thanks @tgampiyush! Hey @benjben or @dilyand am I right that this is a regrerssion from R118?

Or actually from R117 https://github.com/snowplow/snowplow/blob/master/CHANGELOG#L119

@chuwy there is no scala-stream-collector-stdout on our Bintray, so I'm not sure that it has ever been published somewhere.
Already in R114 before sbt-native-packager was introduced we were not publishing it.

Yup, I spotted this ticket today morning. Not sure what's going on with #4278, but at least this is clearly not a regression.


Changed console report handling for the case where all test were skipped

Status
READY
Description
Changed the way console reporter show the case where all tc:s in the run were skipped. This case should now be reported as inconclusive rather than pass. No exit codes were changed and no changes were done to other reports.
Todos

[x] Tests

No longer valid. Not needed. Closing PR.


Check for duplicate player names

Make sure there ain't 2 people with the same nickname in the game so the bot doesn't get confused.

or perhaps instead of targeting a player name target a player number.
Up for debate.


Pressing the Up-Arrow right after sending a message will edit the previous message

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Navigate to any chat in NewDot.
Send a message and immediately (within a half second) press the [Up Arrow] key.
Notice how the edit message UI comes up for the message before (second to last message), not the message you just sent.

Expected Result:
The last message sent should be edited.
Actual Result:
The second to last message sent is edited.
Workaround:
Wait a bit longer before pressing the [Up Arrow].
Platform:

Where is this issue occurring?

Web
iOS
Android
Desktop App
Mobile Web

Version Number: v1.1.18-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
View all open jobs on GitHub

Triggered auto assignment to @tjferriss (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

@tjferriss Makin this a weekly since it's an edge case that probably won't affect many users.

Current assignee @mallenexpensify is eligible for the External assigner, not assigning anyone new.

Triggered auto assignment to @parasharrajat (Exported)

Triggered auto assignment to @AndrewGable (Exported), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

Based on this (internal) comment, @jasperhuangg mentioned this can be external so I'm adding the label, assigning myself too because this might be my #1 pet peeve issue, it happens to me EVERY day.
Job is posted on Upwork https://www.upwork.com/jobs/~011aacaaa4df6cfa41

This is my #1 pet peeve and I literally had a To-do to make a GH for it today. Thanks Jasper 🙏

We can these snippets to ReportActionCompose.js file:
line 453 (we add a boolean and reset it after 2 seconds)
    submitForm(e) {         this.shouldDelayDueToNewPost = true;         if (this.timer) {             clearTimeout(this.timer);         }         this.timer = setTimeout(() => {             this.shouldDelayDueToNewPost = false;         }, 2000);
line 363 (we check for that boolean, if it was true we fire the event after 1 second instead of firing it immedietly)
`
if (e.key === 'ArrowUp' && this.state.isCommentEmpty) {
e.preventDefault();
        const handleArrowUp = () => {
            const reportActionKey = _.find(
                _.keys(this.props.reportActions)
                    .reverse(),
                key => ReportUtils.canEditReportAction(this.props.reportActions[key]),
            );

            if (reportActionKey !== -1 && this.props.reportActions[reportActionKey]) {
                const {
                    reportActionID,
                    message,
                } = this.props.reportActions[reportActionKey];
                Report.saveReportActionDraft(this.props.reportID, reportActionID, _.last(message).html);
            }
        };

        if (this.shouldDelayDueToNewPost) {
            setTimeout(handleArrowUp, 1000);
        } else {
            handleArrowUp();
        }
    }

`

Sorry, fam, but I'm closing this out pending further internal discussion. I'm fairly confident that this problem can't be solved without back-end changes.

@sharifhh apologies. If/when we reopen this issue, your proposal will be reviewed.  It's very rare we open/close issues like this, especially once we've already created the job in Upwork.
I removed the Upwork job for now too


Create a separate updateable and updating cache

We had an implementation of an updating cache that would automatically update data. This separates the layering to have a cache that can be updated underneath a cache that automatically updates. This also exposes the .Start() method as public.

UpdatingObjectCache.cs is showing up as a binary file in the diffs. Can you check its encoding to make sure it's UTF-8 or Unicode or something else standard that git recognizes?

Thanks - I just pushed a fix for that. It seems like we've got some encoding issues going on. Recent PRs keep having that happen...

LGTM


Meshlab

Hi, An Tao. Thanks to you for providing the code.  Do you know how to export HD images in MeshLab (as shown in the paper)? All I can find is the screenshot button.

Sorry, I don't know. I use the screenshot button too.

Hello, AnTao!
    I am wondering if you made a mistake in writing algorithmic operations in one of your papers "SegGroup". In Algorithm 1 Node Clustering, the 6th step should be Cp=Cq, right?
------------------ 原始邮件 ------------------
发件人:                                                                                "AnTao97/dgcnn.pytorch"                                                                                @.>;
发送时间: 2022年5月1日(星期天) 上午9:53
@.>;
<EMAIL_ADDRESS>主题: Re: [AnTao97/dgcnn.pytorch] Meshlab (Issue #70)
Closed #70.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

@csgogo Yes, it is a mistake. Recently we will update our paper in arxiv.


Fix merge conflict text in yarn.lock

🙈

Coverage remained the same at 71.965% when pulling caa8273f36e92bd8f227b1febd6668c165f73ef7 on acburdine:fix-lockfile into 6843eb45fc4314efef95942f581e30df2a8a96a1 on TryGhost:master.

😬 oops! Thanks for the fix 😄


In item chapter: success scores are partially displayed

Describe the bug
In a chapter, for some validated items the score is partially displayed: there's an empty green circle
To Reproduce
Steps to reproduce the behavior:

Go to this chapter as usual user
See first and last chapter items

Expected behavior
Either the score or a tickbox should be displayed.
Screenshots

Covered by #804


Truncate links to commits

For example, /commit/440c62a29faa6bf113da2d9eeb820d88a105f340 to a href="/commit/440c62a29faa6bf113da2d9eeb820d88a105f340" 440c62a29f
This is especially nice in comments on issues (eg: resolved in 440c62a29f)
Edit: I see this is already done in email alerts.

Hmm... can you give some visual comparison for this?

Sorry, how do you mean?
When you paste a full link to a specific commit, I was suggesting that it gets truncated to a link with the only text being the first 10 or so characters of the commit hash.
For example:
https://github.com/gogits/gogs/commit/e0f0f72a362e98073980d9e3c70cde8cd161614b when pasted here becomes https://github.com/gogits/gogs/commit/e0f0f72a362e98073980d9e3c70cde8cd161614b

Thanks.
Why would you paste link in the commit message?

Sorry, the link wouldn't be in a commit message. The link would be on a comment in an issue.
For example,
Someone opens up an issue "We need to speed up our app" and it sits there for awhile.
 This person didn't reference the issue # in the commit message.
When cleaning up issues, you could post in the comments "This was resolved in [link to commit that sped up the app]" and then close the issue

Please see https://try.gogs.io/gogs/gogs/issues/1 ... is that what you're looking for?

Yup! That seems like the kind of thing I'm looking for!

Great... then this issue is no longer needed.


403 Error on Pimary Domain event with Manual .htaccess override

I'm still getting the 403 error on my primary domain even when I manaully add the /.well-known/acme-challenge/.htaccess
The install process delete's the .htaccess.  I've tried removing my root .htaccess as well. At firsty I thought it was because I was using apache + nginx in proxy mode, but the install worked on a subdomain.

Hey, @thezenmonkey
The workaround I advised in #63 was to put .htaccess in the domain's root, because the plugin should put the generated .htaccess file in the acme-challenge by itself. Anyway the plugin was improved and a stub file is no longer required.
Please, check out a new version of the extension.

I tried that, I cleared all custom apache and nginx directives set in Plesk and it threw a 500 error. I'm not sure if the CMS is causing issues but with rewrites it shoudl be avoiding the CMS .I ended up temporarily pointing the domain to an empty directory, installing and then switching back. Hopefully it renews OK.
For reverence here is the error I got
Error: Let's Encrypt SSL certificate installation failed: Failed letsencrypt execution: Failed authorization procedure. www.domain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.intellijointsurgical.com/.well-known/acme-challenge/DNm7J5t37m-eIu2EoWzyEAZwzDvaq-Z4t3Eh8THOkZU [IP]: 500, domain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://domain/.well-known/acme-challenge/d4ZKQB9ai_f3kL31Ljp7JtFpBQyG4YkZFwInhtPLFr0 [IP]: 500
IMPORTANT NOTES:
- The following errors were reported by the server:

Domain: www.domain.com
Type: unauthorized
Detail: Invalid response from http://www.domain.com
/.well-known/acme-challenge/DNm7J5t37m-eIu2EoWzyEAZwzDvaq-
Z4t3Eh8THOkZU [IP]: 500

Domain: intellijointsurgical.com
Type: unauthorized
Detail: Invalid response from http://domain.com
/.well-known/acme-
challenge/d4ZKQB9ai_f3kL31Ljp7JtFpBQyG4YkZFwInhtPLFr0
[IP]: 500

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.

There are a lot of reasons causing the error code 500.
It could be either a conflict of plugin's .htaccess with server settings or domain's misconfiguration in Plesk.
Could you check Apache and nginx error logs during the certificate renewal.
Log-browser in Plesk might be very useful here.

Ok looks like 1.5 works. The last issue was between the keyboard and the chair. Thanks


Ignore dot-file directories

I ran into an issue trying to build a hugo site stored in an SVN repository.  I'm using SVN client 1.6, which stores a .svn directory in every directory of the checked-out repo (I believe SVN 1.7 clients and above no longer do this).  When I try to build the site, I get the error:
2014/03/25 11:51:19 Fatal Error: Error converting unsupported file type 'unknown' for page 'entries'

which I believe is from trying to determine the file type for one of the .svn/entries files.  I believe the fix is to call ignoreDotFile for directories as well as regular files here:
https://github.com/spf13/hugo/blob/d84f707da1d46b7334ff10db2443ac17a17bbff2/source/filesystem.go#L90

Sorry for necromancing this thread, but I have a use-case where this is becoming a bit of a problem. I want to add some pgp keys within content/.well-known/openpgpkey/* so that they should up at /.well-known/openpgpkey. Is there a way I can override this behaviour? Should I open a separate issue?


user forum

It is not at all clear where one would go to ask questions and exchange ideas with other users of Panel. If such a forum exists, you should link to it prominently in the documentation somewhere.
Also, because the name "Panel" is quite common in programming, it is very difficult to conduct useful google or stack overflow search. You might want to consider rebranding to a more unique name (or spelling).
You may want to suggest an official tags to use with stack overflow. E.g. the tag panel is not especially useful by itself (https://stackoverflow.com/questions/tagged/panel) where panel plus pyviz currently only has 6 questions (https://stackoverflow.com/questions/tagged/panel+pyviz).

Thanks for raising this. We are currently planning to set up a Discourse instance, where such discussion will take place. I hope to have some updates on that soon at which point we will link it prominently everywhere.

But in the meantime, we converse at https://gitter.im/pyviz/pyviz , which is linked from the homepage.

Thanks. I do think that you should seriously consider rebranding to a more unique name to avoid confusion (e.g. panL, panyl, panil, or just pyviz.panel). It really would make it a lot easier for people seeking help. Better to do that now while the project is still relatively immature.

It is far too late for that, I'm afraid!

That's too bad, because it really is going to require you to do a lot more work on organizing documentation and developer resources than you would otherwise have had to do.

We now have a Discourse forum: https://discourse.holoviz.org/c/panel


Add FrameExtractor to Hub

Related code https://github.com/jina-ai/example-video-search/blob/main/executors.py#L23:L110

Related PR: https://github.com/jina-ai/executor-video-frameextractor/pull/2

Related PR: jina-ai/executor-video-frameextractor/#3


HTTPs support

Does fakenet support HTTPs? I thought the support was added sometime ago, but it does not work in either the latest version (3.3) or the previous one (v3.2-alpha). Is this a fakenet bug or do I need to configure something?
3.3
PowerShell
PS C:\Users\flare\Desktop > Invoke-WebRequest -Uri "https://ana.com/api/123" -OutFile "C:\Users\flare\AppData\Local\Temp\ana.bin" -UseBasicParsing
Invoke-WebRequest : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS
secure channel.
At line:1 char:1
+ Invoke-WebRequest -Uri "https://ana.com/api/123" -OutFile "C:\Users\f ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
   eption
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

fakenet
12/05/24 05:52:52 PM [        DNS Server] Received A request for domain 'ana.com' from svchost.exe (2040)
12/05/24 05:52:52 PM [          Diverter] powershell.exe (2832) requested TCP <IP_ADDRESS>:443
12/05/24 05:53:13 PM [          Diverter] explorer.exe (4004) requested TCP <IP_ADDRESS>:443

v3.2-alpha
PowerShell
> Invoke-WebRequest -Uri "https://ana.com/api/123" -OutFile "C:\Users\flare\AppData\Local\Temp\ana.bin" -UseBasicParsing
Invoke-WebRequest : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS
secure channel.
At line:1 char:1
+ Invoke-WebRequest -Uri "https://ana.com/api/123" -OutFile "C:\Users\f ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
   eption
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

fakenet
11/28/24 03:47:55 PM [          Diverter] powershell.exe (1360) requested TCP <IP_ADDRESS>:443
11/28/24 03:47:55 PM [          Diverter] svchost.exe (1876) requested UDP <IP_ADDRESS>:53
11/28/24 03:47:55 PM [        DNS Server] Received A request for domain 'ctldl.windowsupdate.com'.
11/28/24 03:47:55 PM [          Diverter] powershell.exe (1360) requested TCP <IP_ADDRESS>:80
11/28/24 03:47:55 PM [    HTTPListener80]   GET /msdownload/update/v3/static/trustedr/en/authrootstl.cab?f909d1009cd4d331 HTTP/1.1
11/28/24 03:47:55 PM [    HTTPListener80]   Connection: Keep-Alive
11/28/24 03:47:55 PM [    HTTPListener80]   Accept: */*
11/28/24 03:47:55 PM [    HTTPListener80]   User-Agent: Microsoft-CryptoAPI/10.0
11/28/24 03:47:55 PM [    HTTPListener80]   Host: ctldl.windowsupdate.com
11/28/24 03:47:55 PM [    HTTPListener80]

I suspect this needs https://github.com/mandiant/flare-fakenet-ng/pull/98 or an updated certificate.
#98 would be great to get merged regardless though...