Production instance is relying on the default repository config

Currently config.py contains
# Also listen to cobot, if the bot being ran is corobo
if not os.environ.get('COBOT_PREFIX'):
    BOT_ALT_PREFIXES = ('cobot ', )

That means if the production service had set COBOT_PREFIX, using cobot wont work.
devops needs to fix this, and then this part of the config should be removed, as dev/test instances do not need an alt prefix by default.
But I tested, and the production instance does recognise cobot ....
This is blocking https://github.com/coala/corobo/issues/365

Currently, prod instance doesn't have COBOT_PREFIX set. BOT_ALT_PREFIXES should be set to os.environ.get('COBOT_ALT_PREFIXES', '').split() instead of making this the default.

@yukiisbored , you are missing the point.
BOT_ALT_PREFIXES is currently the default values on production, which means if we change this in #365, production will fail.
Can you please do git grep environ, and ensure every environment variable is hard coded in the production instance, and not using a default value.
And then we also have to plan how we migrate production values that are only defined in config.py at the moment.
Either,

you set them as environment variables in production, and then we change config.py to use those variables.  (and note, please use BOT_*, not COBOT_* as we are deprecating the latter.)
Change production startup so that it does not use the repository config.py , until such time as the repository version of config.py loads everything from environment variables and then you can change back to using the repository version of config.py with the environment variables that it uses.

Done desu! https://github.com/coala/devops/commit/42a353caeb4a238529637082f8c3ecd6194f6b5c

No, please re-read my comment above.

There https://github.com/coala/devops/commit/b86e202c086000dab571b47ff7a30d444fb6339c

I think that does it.


docs: Removes dagger.WithWorkdir from examples

This commit removes dagger.WithWorkdir() and equivalent Dagger client configuration from some code examples. This is to avoid unexpected errors and code breaks resulting in user confusion and an inconsistent experience when the same code is run with and without dagger run.
For more information, refer to the discussion and message at https://discord.com/channels/707636530424053791/1145698713331834990/1146770191120875580

@vikram-dagger Why not simply add a warning or a note instead of removing the example?

@vikram-dagger Why not simply add a warning or a note instead of removing the example?

thing about adding a warning is that most of the time users don't read it.
the good thing about removing the WithWorkDir is that examples will work the same regardess if the user is doing dagger run or calling their pipelines through the SDK directly.

the good thing about removing the WithWorkDir is that examples will work the same regardess if the user is doing dagger run or calling their pipelines through the SDK directly.

Alright!


Adding support for julian days

Hi. I am using a lot date conversions and SwiftDate is clearly the best framework for that. But I would be so glad it also contains support for Julian Days (which are linear "dates" used by astronomers worldwide). Of course, I could create my own extensions, but I thought it would be cool to have it here. I've added tests as well. I hope I've respected style and conventions as much as possible!
Thanks anyway for the great work.

Great job! Thank you for your improvement. Can you migrate your PR to develop instead of master?

Hi. Sure, I will move it to 'develop'. Don't know how if I can do it from here, so I'll create a new PR.


wanted: googleapis

Module location
https://github.com/googleapis/googleapis/archive/refs/heads/master.zip
Link to bzlmod issue in the module's repository
No response
Any other context to provide?
There are a huge number of projects that are expending a lot of effort to be able to use Google's ProtoBuf APIs in Bazel.  Rather than reinventing the wheel, it would be helpful to have a googleapis module that everyone can use and can contribute to.  This would be very helpful, especially when using the annotations.proto.
Fund our work

[ ] Sponsor our community's open source work by donating a feature bounty

Cc @tyler-french

There are a huge number of projects that are expending a lot of effort to be able to use Google's ProtoBuf APIs in Bazel.

Even the best 'canonical' example I can find of integrating googleapis buildfarm in Java has had to DIY it in an extraordinarily cumbersome way.

https://github.com/bazelbuild/bazel-central-registry/pull/1699


Cypress/E2E: Fix failed tests on header info due to global header

Summary
This PR fixes some of the failed tests related to the use of #headerInfo when Global header is enabled.
Note:

These tests should run against a server with Global header enabled.
Once merged, we'll start running Cypress with Global header enabled as always.
Will not fix tests to handle backward compatibility.

Screenshots

Release Note
NONE

My original plan is to submit PR in partial but while here, I hope it's fine to add more fixes (https://github.com/mattermost/mattermost-webapp/pull/8789/commits/5bac869744eebd28857d779bf1d9771de47495a0 last for this PR). My only goal at the moment is to stabilize tests in daily Cypress due to new features got in for v6.0. So, I'm hoping to merge this as soon as possible, and move to next test fixes/updates.
@michelengelen Sorry but please take a look again if you get a chance. Thanks!

Done cherry-pick into release-6.0


Show personal score

Users should also be able to see their personal scores! Currently one needs to count the number of PR's made by him/her.

It's a little tricky because we don't save the personal score at the moment.
Need to add another field to the DB save the score in show it.
Are you up to it?

I don't think I will be able to do it all alone.

hey @kailashchoudhary11 I could work with you on this

I would like to work on this issue @nevo-david !! Assign me

I would love this ❤


kernel: update z_arch_switch() documentation

Clarify the intended design and how to implement optimally.
Relates to: #19759
Signed-off-by: Andrew Boie<EMAIL_ADDRESS>

Have we abandoned the idea of just passing z_arch_switch() a pair of struct k_thread pointers?

If switch_handle is meant to be a stack pointer, then don't pretend it's some opaque type that architectures are allowed to do whatever they want with.  Call it stack_pointer.

Updated; added comments on how to use ___thread_t_switch_handle_OFFSET instead of de-referencing switched_from all the way. @andyross please let me know if I got this right or if there's anything else worth adding.

also @vonhust FYI -- see #19952 , ARC code should do this as well instead of NULL checking.

OR we could just change z_arch_switch() to work for the general case, rather than make everybody bend over backwards to accommodate the special case where all the context is a stack pointer?

but muh Linux!
`	/*
	 * void __switch_to(struct thread_info *prev,
	 *      	    struct thread_info *next,
	 *		    struct task_struct *tsk) ;
	 */

OR we could just change z_arch_switch() to work for the general case, rather than make everybody bend over backwards to accommodate the special case where all the context is a stack pointer?

My understanding from offline discussion with @andyross is that supporting the stack switching scheme makes some optimizations possible on Xtensa which would not be if xtensa stored all its context in the thread struct.
With #19952 in place, I don't feel any more that we need to re-implement anyone's current z_arch_switch() implementation, other than applying the same fix to ARC (instead of the NULL check it has now). I think we can move on to other matters.

My understanding from offline discussion with @andyross is that supporting the stack switching scheme makes some optimizations possible on Xtensa which would not be if xtensa stored all its context in the thread struct.

So then Xtensa can store a stack pointer in its k_thread (which it does, in the void *switch_handle) and use some form of offset addressing to get it, rather than forcing everyone else to play games.
That's the general case - "give me some k_threads and I'll get/store what I need from them", not, "let's optimize for the case where all we need is a stack pointer!".
Your own protection code on x86 could benefit from storing more context than a stack pointer (like, CR3) in the thread struct,  I mean, since we've resorted to counting instructions in context switches..

So then Xtensa can store a stack pointer in its k_thread (which it does, in the void *switch_handle) and use some form of offset addressing to get it, rather than forcing everyone else to play games.
That's the general case - "give me some k_threads and I'll get/store what I need from them", not, "let's optimize for the case where all we need is a stack pointer!".

@gnuless This is really a discussion for you and @andyross I'm Swiss neutrality at this point. You guys can hash it out here. I don't see anything particularly onerous about the stack-based method FWIW, this seems to me a six-of-one, half-dozen-of-the-other. But I don't have a stake in this, you guys hash it out.

Your own protection code on x86 could benefit from storing more context than a stack pointer (like, CR3) in the thread struct, I mean, since we've resorted to counting instructions in context switches..

Can you point me to specifics on this? I'm happy to address this but I'm not 100% sure what you're referring to.

@gnuless This is really a discussion for you and @andyross I'm Swiss neutrality at this point.

No need to play Switzerland.  I'll play the Vichy and sell my soul for filthy lucre.

Can you point me to specifics on this? I'm happy to address this but I'm not 100% sure what you're referring to.

You mean like the part where you call z_x86_swap_update_page_tables() with a pointer to the incoming k_thread?  And then dereference that k_thread to find a member called called stack_obj which you use to find the page tables for the thread?
Try moving that to the z_arch_switch() structure.  Now you have to repeat your 'adjustment' of switch_handle on the incoming thread to find data in the the thread struct like everybody else with anything but trivial context they can push on the stack does.
Tsk, tsk, Andrew.  How dare you want more context than the general registers.  I give you two demerits.

Really, CR3 should be simply stored in the task struct and it should be loaded directly.  If you're worried about unnecessary TLB flushes, use the G flag on global pages which is expressly for that purpose.  Similarly, store the kernel stack there and don't make the load of the kernel stack dependent on a conditional branch.
Ordinarily these are not things that I would care about, EXCEPT that I was handed an argument earlier today about how one additional indirection (to deal with the z_arch_switch() mis-specification) was unacceptable on the context-switching path.

Really, CR3 should be simply stored in the task struct and it should be loaded directly. If you're worried about unnecessary TLB flushes, use the G flag on global pages which is expressly for that purpose. Similarly, store the kernel stack there and don't make the load of the kernel stack dependent on a conditional branch.

I see it now, yes this could be optimized by caching CR3 and updating it if it's not the same between incoming/outgoing.

My understanding from offline discussion with @andyross is that supporting the stack switching scheme makes some optimizations possible on Xtensa which would not be if xtensa stored all its context in the thread struct.

What I am suggesting does not, by any means, preclude Xtensa or anyone else from storing context on the stack if they want to.  I merely state that
void z_arch_switch(struct k_thread *, struct k_thread *)
is a better generalization.  It's even better on Xtensa -- it requires the addition of (no pun intended) one addition instruction to the xtensa_switch code but eliminates other arithmetic generated by the compiler in the calling sequence to z_arch_switch().  Someone, somewhere, has to compute the offset of the switch_handle member; the current structure merely hides the fact that the compiler has to do it instead of the assembly.  Simply declare a stack_pointer member in struct k_thread and let the assembly do the offset arithmetic.
So at best, the use of z_arch_switch() in its present configuration is not an optimization, it's a wash.  I can even imagine that, recast to take k_thread * arguments, someone could micro-optimize @andyross -style, and xtensa_switch would a lose an instruction or two.
But the real problem is, that even if it did require an extra instruction or two for Xtensa, the abstraction is too specific; it implicitly assumes that:

there is no need for the switch function to access the outgoing context, despite the fact that part of its job is to save the outgoing context, and
a simple opaque word value is sufficient information to restore the incoming context

This imposes an additional cost on architectures/implementations that stray from the simplistic "all I need is a stack pointer for my context" model.

With #19952 in place, I don't feel any more that we need to re-implement anyone's current z_arch_switch() implementation, other than applying the same fix to ARC (instead of the NULL check it has now). I think we can move on to other matters.

I vehemently disagree.  For architectures that need more than just one opaque pointer as context, or wish to store context somewhere off-stack for other reasons (i.e., @andrewboie's memory protection code), we need to respecify the interface.
The current "workarounds" for this in ARC and x86 clearly demonstrate this: not only does the compiler do unnecessary arithmetic in the calling sequence to z_arch_switch(), the switching assembly then has to "undo" that arithmetic.  The fix in #19952 is a clever workaround, but it's still a workaround, and it's making a mockery of the idea of a switch_handle as an abstraction, instead taking advantage of the fact that it is a member of the desired k_thread, breaking the abstraction entirely.
There is simply no reason why z_arch_switch() is tailored as it is to the special case when there's no benefit to specifying it that way; on the contrary, it leads to suboptimal sequences and broken abstraction for everything but that special case.

So just to summarize.  If we change to void z_arch_switch(struct k_thread *, struct k_thread *) we have these objective benefits:

have no impact, or possibly a positive impact, on the xtensa_switch sequence
avoid awkard workaround instruction sequences in the ARC architectures and x86 architectures
reduce the number of instructions generated in do_swap when invoking z_arch_switch()
eliminate a member of k_thread (switch_handle) and the need to update it in the interrupt path

What are the downsides?

also @vonhust FYI -- see #19952 , ARC code should do this as well instead of NULL checking.

Understood,  will change after #19952 is merged

Picking out one technical bit:

Your own protection code on x86 could benefit from storing more context than a stack pointer (like, CR3) in the thread struct, I mean, since we've resorted to counting instructions in context switches..

Why not just push CR3 to the stack?  I mean, it's not like this is a fundamentally different concept, you can put data anywhere you want.  The core benefit to doing it on the stack is that (1) the hardware on almost all architectures has already done some of it for you, and (2) you don't need access to the current thread pointer on interrupt entry and can avoid the somewhat complicated assembly code needed to extract it.  If you follow the code on x86_64 and count instructions, you can see that the number of instructions required to affect the context switch is just a tiny number (four, in fact) higher than the number of instructions required to spill and fill each register.  There aren't even any logic branches!  The jump from the user code to the kernel switch routine is an inline CALL that also has the side effect of pushing the return address for us.
I mean... there's a real technical argument here, and at this point I know I won't win it, but there are better ways to do this, and z_arch_switch() was designed for the benefit of the better scheme.
But sure, it can work under a thread based one too.

Why not just push CR3 to the stack?

@andyross yeah this was pretty much how I was contemplating fixing this.
Push CR3 onto the stack at the beginning of z_arch_swap().
Then on the way out, pop it back into a register, compare with current CR3 value, update if necessary.
Given that this code only runs when KPTI is disabled (not the case for any of our current boards as they are all Meltdown vulnerable), this fix isn't high on my priority list, but that's how I'd imagine I'd do it.
I'd also push/pop _main_tss.esp0 values.
If there's a strong argument that thread-based switching is clearly better than stack-based switching, at this time I do not see it.

Why not just push CR3 to the stack? I mean, it's not like this is a fundamentally different concept, you can put data anywhere you want.

Well, typically the stack pointer and CR3 change together, atomically, because the stack you want is only visible in the target context's page tables.

If there's a strong argument that thread-based switching is clearly better than stack-based switching, at this time I do not see it.

That's NOT the argument that I'm making.  I'm saying that z_arch_switch() in its present form is unnecessarily biased towards that mechanism.  The two different forms of z_arch_switch() are nearly isomorphic.  You can translate either presentation to the other with little difficulty.  You can do stack-based or thread-based context switching with either.  For stack-based switching, they're essentially equivalent in terms of cost.  For thread-based switching, however, the switch_handle form is cumbersome and comes at a cost.  If the general, straightforward solution is also the less burdensome for all conceivable scenarios, I'm not sure what the argument is for using the specific version that has known costs in present (not imaginary) use cases could be.

That's NOT the argument that I'm making. I'm saying that z_arch_switch() in its present form is unnecessarily biased towards that mechanism.

Thinking aloud, we could perhaps define some mutually exclusive Kconfigs and have something like
#ifdef CONFIG_SWITCH_THREAD
extern void z_arch_switch_thread(struct k_thread *incoming, struct k_thread *outgoing);
#endif
#ifdef CONFIG_SWITCH_STACK
extern void z_arch_switch_stack(void *switched_to, void *switched_from)
#endif

Which arches could select as needed.
But I mean, I'm still baffled at your point of view.
Unlike me, you already knew that this was really intended for stack-based switching from the get-go, you told me as much in an email last week.
And just now you also agree that these are isomorphic.
So why did you decide to do a thread-based z_arch_swap() for x86 long instead of a stack based one??? This seems like a problem of your own making. If this is just an elaborate way of making some point about the abstract-ness of the interface there are better ways of communicating this..

Thinking aloud, we could perhaps define some mutually exclusive Kconfigs and have something like
#ifdef CONFIG_SWITCH_THREAD
extern void z_arch_switch_thread(struct k_thread *incoming, struct k_thread *outgoing);
#endif
#ifdef CONFIG_SWITCH_STACK
extern void z_arch_switch_stack(void *switched_to, void *switched_from)
#endif

No, no, no.  That sort of special-casing is precisely what I'm trying to eliminate!  We need fewer special cases, fewer convoluted constructions, not more.

So why did you decide to do a thread-based z_arch_swap() for x86 long instead of a stack based one???

Because that was the intent of its creators - that's why they have callee_save and other fields architecturally defined.  If you meant why did I create z_arch_switch() to make it stack-based, it's because was a trivial transformation of existing, working code to go from swap to switch and I wasn't going to rewrite it all, especially when I'm not entirely sold that the stack thing is the best approach.  But again, this isn't an argument about that.

you already knew that this was really intended for stack-based switching from the get-go

I didn't.  I wrote a swap() function in the original.  For why switch follows the same scheme, see above.

But I mean, I'm still baffled at your point of view.

Then I'm explaining it poorly.

If you meant why did I create z_arch_switch() to make it stack-based, it's because was a trivial transformation of existing, working code to go from swap to switch and I wasn't going to rewrite it all

Alright, that's fair.

No, no, no. That sort of special-casing is precisely what I'm trying to eliminate! We need fewer special cases, fewer convoluted constructions, not more.

My thinking was that this would not be invasive since z_arch_switch() is invoked in just one spot in ksched.h. And then they could be documented as being specific to stacks/threads rather than left vague. But I am not attached to this, other ideas lets consider them.
For now, I'm inclined to merge this patch as it provides some useful context to the switch function, such that people doing arch ports in the future may have an easier time.

Also let me take another stab at the problem statement as you see it @gnuless :
We have an API for context switching which on the surface appears to be an abstraction to let the arch code do context switching as it sees fit, but actually is really designed for stack-based switching. Doing this with thread pointers has unexpected complications and some minor inefficiencies and this API definition should be made more specific to its intended purpose.
If I've got that right, then I think there is a corollary: we have two arch ports that do thread-based switching (ARC, x86 long). If we revise the API to clearly indicate that this is a mechanism for stack-based switching, what do we do with these?
As far as the fate of z_arch_swap(), I opened an enhancement GH the other day to convert all remaining arches to switch see #19932 , I'd like to see swap eventually purged.

If I've got that right, then I think there is a corollary: we have two arch ports that do thread-based switching (ARC, x86 long). If we revise the API to clearly indicate that this is a mechanism for stack-based switching, what do we do with these?

I'd say move them to stack-based switching then.  Rename switch_handle to stack_pointer even, and be very explicit that we do our context storage on the stack.  That's fine.  In that case, I'd still argue to change the arguments to k_thread *:  the argument for that is:

it does not impose any additional costs in the existing implementations. we're just changing where the offset computation occurs (in the switch proper rather than the caller of switch),
it does not require convoluted (if clever) tricks to get more information if we need to restore the context.

#2 is not a "but maybe someday we might..." over-engineering thing.  Think again of caching CR3 -- I don't know if you saw my previous comment but storing it on the stack will impose limitations that we probably don't want to live with in perpetuity (namely, that the outgoing and incoming contexts must both have mapping for the incoming thread's stack -- you can't get at CR3 if it's not...).  That's just one example.  There might be others that crop up later.
Short story: changing the API slightly in this way costs nothing, results in something that is more obviously understood (oooh, that's a STACK POINTER! I get it) and is future proof in a straightforward way (need a new data member? no tricks required).
That's really the entirety of my point....
.... I told you I was explaining it badly.

For now, I'm inclined to merge this patch as it provides some useful context to the switch function, such that people doing arch ports in the future may have an easier time.

Yeppers, no problems here.  Documentation good.  I've said my piece about the specification.

I mean... there's a real technical argument here, and at this point I know I won't win it, but there are better ways to do this, and z_arch_switch() was designed for the benefit of the better scheme.

Yeah, I'm not necessarily making the point that we should be storing the context in the k_thread.  I'm 98% sold on that, your points are valid.  It's just about the arguments to z_arch_switch() being too limiting for some realistic cases.

Very very good point here.
Can't pop the new cr3 off the incoming stack if it's not in the address space. It only works now because we have identity page tables. Still contemplating this but it's been on my mind.
On Oct 21, 2019 3:28 PM, "Charles E. Youse"<EMAIL_ADDRESS>wrote:
Why not just push CR3 to the stack? I mean, it's not like this is a fundamentally different concept, you can put data anywhere you want.
Well, typically the stack pointer and CR3 change together, atomically, because the stack you want is only visible in the target context's page tables.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/zephyrproject-rtos/zephyr/pull/19938?email_source=notifications&email_token=AAZ272MK32DXAPHNYI24BBDQPYUIHA5CNFSM4JCKRQD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB3737Y#issuecomment-544734719, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAZ272LBLNY6GWBEBKFUCNTQPYUIHANCNFSM4JCKRQDQ.

Can't pop the new cr3 off the incoming stack if it's not in the address space

FWIW: the address space of all z_arch_switch'd stacks is going to be the kernel space already, so it's a non-issue for the specific API we're talking about.  It's true that there's some work to do on interrupt entry if a userspace context was interrupted, but because of the address space change required by KPTI, we have to take that cost under all circumstances anyway.  That is: the trampoline code needs to save the interrupted CR3 somewhere that is neither the kernel stack nor the thread struct initially, so the final destination doesn't matter much at all.  Realistically the entry code would stick it in a register and save off the original register contents somewhere in the trampoline memory, at which point we can store it wherever we want in kernel-address-space half of interrupt entry.
Again, memory is memory.  It's not like indirecting off the stack pointer instead of a GPR creates fundamental logic problems.

FWIW: the address space of all z_arch_switch'd stacks is going to be the kernel space already

That's true now.  It is by no means a safe assumption that all kernel stacks for every thread are (or should be visible) from every other thread context, kernel-space or no.  And I'm not talking about whacky schemes-- even Unix processes from the very early days had kernel stacks that were only visible from their own contexts.
Zephyr's own memory protection and security models are very much works in progress, with new information and new requirements appearing all the time.  Why paint ourselves into a corner?

Push CR3 onto the stack at the beginning of z_arch_swap().  Then on the way out, pop it back into a register, compare with current CR3 value, update if necessary.

I'd also push/pop _main_tss.esp0 values.

Another argument against this strategy is that we're forced -- unnecessarily -- to take unchanging data about a thread and write it onto the stack and read it off the stack.  Why are we taking, known, static values about a thread (which could easily be stored in, and referenced in, their k_thread) and instead 'caching' them on the stack ...?  These gymnastics are only necessary because we're trying to insist that the context-switching primitive use only the stack in its operation.

That is: the trampoline code needs to save the interrupted CR3 somewhere that is neither the kernel stack nor the thread struct initially, so the final destination doesn't matter much at all.

I don't see this at all.  CR3 is basically a static attribute of a k_thread.  Transition to the kernel via the trampoline doesn't have to save CR3 anywhere.  We know which thread we interrupted.
But this is a digression...

It's true that there's some work to do on interrupt entry if a userspace context was interrupted, but because of the address space change required by KPTI, we have to take that cost under all circumstances anyway.

I think we will be OK - regardless of whether KPTI is in effect or not, we will always end up on a kernel stack, this is handled I believe correctly by existing code. If KPTI is disabled, there's still an automatic stack switch to the kernel stack on IRQs due to us setting the esp0 pointer in _main_tss. We shouldn't ever end up in a situation where we are in z_arch_swap()/z_arch_switch() on a user mode stack; this would be a DoS concern since a thread could constuct a stack context which faults when the kernel switching code in supervisor mode tries to push more stuff onto it.
My intention for virtual address spaces was that the kernel stacks would always be in the kernel's half of memory and global to all address spaces. I think we're OK for this particular scenario.

Another argument against this strategy is that we're forced -- unnecessarily -- to take unchanging data about a thread and write it onto the stack and read it off the stack. Why are we taking, known, static values about a thread (which could easily be stored in, and referenced in, their k_thread) and instead 'caching' them on the stack ...?

If we can show that this is faster when we have a thread pointer available (and I think it is) then this is a good example. Because we'd only need logic in the second half of the function when we restore context. I can put together a prototype of both approaches for fixing this on 32-bit to illustrate, I can spend some time on this when I get back from France.


CTCP-998: Update JSON schema

Updated the Json schema to tighten up the validation.

This just needs to be checked a little more, but it seems to work with CC015C and CC014C.

Actually, I'm not sure I like that I've somehow made the test cases smaller - I'm just gonna look into that.

I realised that I'd done that, and I wasn't happy, so I've been through it to fix the regexes. The JSON files in the version you checked were based on the XML files that were used in the tests here.
It's interesting that tightening the schema caused these errors, but there we are.


-d and -t are ignored

Hi!
I tried to use pip-compile-multi for my project it has following structure
requirements/
   |- base.in
   |- dev.in
   |- test.in
requirements.in

The requirements.in is needed for exporting a package and can not be changed. The others are used otherwise.
So if I want to just run pip-compile-multi on the requirements.in it seems to ignore it and just compile the ones in the folder
running
pip-compile-multi -d .

or
pip-compile-multi -t requirements.in

I also tried
pip-compile-multi -t ./requirements.in

But all yield
Locking requirements/base.in to requirements/base.txt. References: []
Locking requirements/test.in to requirements/test.txt. References: ['requirements/base.in']
Locking requirements/dev.in to requirements/dev.txt. References: ['requirements/base.in', 'requirements/test.in']

if I run verify like
pip-compile-multi verify -d .

It yields
OK - requirements.txt was generated from requirements.in.

Do you have any idea what the problem could be?
Thanks a lot!

What's the contents of requirements.in?

# this file is only necessary for the package export
aiohttp>=3.8.3
pydantic<2.0.0

And two company internal packages


OverflowError in crypto_recognizer

Describe the bug
On certain text inputs, analyze method throws OverflowError
To Reproduce
Here's the environment setup:

Running on python:3.12

presidio-analyzer==2.2.354

Sample script that throws exception when run:
from presidio_analyzer import AnalyzerEngine
from presidio_analyzer.nlp_engine import NlpEngineProvider

default_lang = "en_simple"
supported_languages = ["en_simple"]
configuration = {
    "nlp_engine_name": "spacy",
    "models": [
        {"lang_code": "en_simple", "model_name": "en_core_web_sm"},
    ],
}
provider = NlpEngineProvider(nlp_configuration=configuration)
nlp_engine = provider.create_engine()

# Pass the created NLP engine and supported_languages to the AnalyzerEngine
analyzer = AnalyzerEngine(
    nlp_engine=nlp_engine, supported_languages=supported_languages
)

analyzer.analyze(
    text='{"awsAccountId":"327878933619","digestStartTime":"2023-10-15T22:04:04Z","digestEndTime":"2023-10-15T23:04:04Z","digestS3Bucket":"paul-trail","digestS3Object":"AWSLogs\/327878933619\/CloudTrail-Digest\/ap-northeast-1\/2023\/10\/15\/327878933619_CloudTrail-Digest_ap-northeast-1_paul-trail_us-west-2_20231015T230404Z.json.gz","digestPublicKeyFingerprint":"be2f0b997552f44942837300ba1aba9d","digestSignatureAlgorithm":"SHA256withRSA","newestEventTime":"2023-10-15T22:58:17Z","oldestEventTime":"2023-10-15T22:04:51Z","previousDigestS3Bucket":"paul-trail","previousDigestS3Object":"AWSLogs\/327878933619\/CloudTrail-Digest\/ap-northeast-1\/2023\/10\/15\/327878933619_CloudTrail-Digest_ap-northeast-1_paul-trail_us-west-2_20231015T220404Z.json.gz","previousDigestHashValue":"8f953371d3e85eddb89b05ed6b9e680791055315c73e1025ab5dba7bb2aee189","previousDigestHashAlgorithm":"SHA-256","previousDigestSignature":"11c11e253f4929eaded49c9d826b257a5ab894ce002988bd07ed2bc6407f1b0ef74f48634c364c6884c6470c9416d73f0742f8758746fc8db4cf23b75c713304779bb6d181ccae4b6a78ae5106f1602ce49af3f9dea4e9ba92761fcaf3e02a5f3d64558d7f4b2eff85f0cc523a770a3b1092e0e37aa665f3c37b75ecc93c94a4640825e0ebe44b2b4fa48b7477040f08a83db2224b403c46476ca25a1b53b5b5db86be04e623fef2d9a2a8eba482239439d6d49cb5eb759a90184f72506a8788fb085f56830c46f51d6e216152bf9156b33cbbee3aeeb5b00540f333708f870d316291f37dd530491a7785ddafdb83543c327fa504e200efefbadd644fed9b9a","logFiles":[{"s3Bucket":"paul-trail","s3Object":"AWSLogs\/327878933619\/CloudTrail\/ap-northeast-1\/2023\/10\/15\/327878933619_CloudTrail_ap-northeast-1_20231015T2205Z_iRIoDMA9l9Q4kmFy.json.gz","hashValue":"4309c6161e37538de72ec6f679e86b7e45aebed71fa7e76af70c3019fef44e19","hashAlgorithm":"SHA-256","newestEventTime":"2023-10-15T22:04:51Z","oldestEventTime":"2023-10-15T22:04:51Z"},{"s3Bucket":"paul-trail","s3Object":"AWSLogs\/327878933619\/CloudTrail\/ap-northeast-1\/2023\/10\/15\/327878933619_CloudTrail_ap-northeast-1_20231015T2300Z_aDYIgZODwysx0Irn.json.gz","hashValue":"de90c3b55016bc5fad9c12378ccc6fc38180a15bd95879305415572a4472b1a9","hashAlgorithm":"SHA-256","newestEventTime":"2023-10-15T22:58:17Z","oldestEventTime":"2023-10-15T22:58:17Z"},{"s3Bucket":"paul-trail","s3Object":"AWSLogs\/327878933619\/CloudTrail\/ap-northeast-1\/2023\/10\/15\/327878933619_CloudTrail_ap-northeast-1_20231015T2300Z_9eJ8qdKnXIfFg2wM.json.gz","hashValue":"85e79f9b40d5a57be15fa6ac6f54d3ea1919611e37ca682c1e753287ac7b9bcb","hashAlgorithm":"SHA-256","newestEventTime":"2023-10-15T22:58:17Z","oldestEventTime":"2023-10-15T22:58:17Z"},{"s3Bucket":"paul-trail","s3Object":"AWSLogs\/327878933619\/CloudTrail\/ap-northeast-1\/2023\/10\/15\/327878933619_CloudTrail_ap-northeast-1_20231015T2225Z_OviGSSWadUI1W1r7.json.gz","hashValue":"58583ed7d52597e47e073db9b756f38815a8a5aff92911911710f18e65e1c44d","hashAlgorithm":"SHA-256","newestEventTime":"2023-10-15T22:20:34Z","oldestEventTime":"2023-10-15T22:10:12Z"},{"s3Bucket":"paul-trail","s3Object":"AWSLogs\/327878933619\/CloudTrail\/ap-northeast-1\/2023\/10\/15\/327878933619_CloudTrail_ap-northeast-1_20231015T2225Z_j5hj9VuYmchJHAkK.json.gz","hashValue":"c18c49161f97def10a14cffa5b5ab441c8fe8194af1cb1d79d470b6173f901c4","hashAlgorithm":"SHA-256","newestEventTime":"2023-10-15T22:20:34Z","oldestEventTime":"2023-10-15T22:20:34Z"}]}',
    language=default_lang,
)

Here's the stack trace:
  File "/Users/udayan/Desktop/theom/presidio/presidio_venv/lib/python3.12/site-packages/presidio_analyzer/analyzer_engine.py", line 207, in analyze
    current_results = recognizer.analyze(
                      ^^^^^^^^^^^^^^^^^^^
  File "/Users/udayan/Desktop/theom/presidio/presidio_venv/lib/python3.12/site-packages/presidio_analyzer/pattern_recognizer.py", line 97, in analyze
    pattern_result = self.__analyze_patterns(text, regex_flags)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/udayan/Desktop/theom/presidio/presidio_venv/lib/python3.12/site-packages/presidio_analyzer/pattern_recognizer.py", line 210, in __analyze_patterns
    validation_result = self.validate_result(current_match)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/udayan/Desktop/theom/presidio/presidio_venv/lib/python3.12/site-packages/presidio_analyzer/predefined_recognizers/crypto_recognizer.py", line 62, in validate_result
    bcbytes = self.__decode_base58(pattern_text, 25)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/udayan/Desktop/theom/presidio/presidio_venv/lib/python3.12/site-packages/presidio_analyzer/predefined_recognizers/crypto_recognizer.py", line 79, in __decode_base58
    return n.to_bytes(length, "big")
           ^^^^^^^^^^^^^^^^^^^^^^^^^
OverflowError: int too big to convert

Expected behavior
code should run without any errors, or at least the exception should be documented
Additional context
There might be a smaller input that causes the same error, but this is what I have right now.

Hi! Thank you so much for the fix 💪 when there will be a release to include this change?

Hi @larissaleite, we're waiting for a few more additions before the next release. In the mean time, I would suggest to copy the crypto recognizer's code from github and add it as a new recognizer instead of the existing one, or remove the crypto recognizer if you don't expect to have crypto entities in your datasets.

@omri374 , do you have a date estimate on when the next release with the fix would be available? I am also experiencing this issue but can't add custom recognizers because I use presidio with docker and call it via the /analyze API

Hi @larissaleite, we're waiting for a few more additions before the next release. In the mean time, I would suggest to copy the crypto recognizer's code from github and add it as a new recognizer instead of the existing one, or remove the crypto recognizer if you don't expect to have crypto entities in your datasets.

@idelarosa3232 this would likely take 2-3 weeks. If you need help creating a docker image with custom recognizers, please let us know here or via email<EMAIL_ADDRESS>

@omri374 looks like this bug was not fixed yet, can the issue be reopened?


Test SigServ

This his test PR, don't merge

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


Add Logging

Issue
Add Logging
Discussion
Logging would make debugging easier.
Recommendation(s)

Create a logging package and handler.
Log all successful and attempted changes made to Azure-based resources.
Use JSON.
Use a configurable path for the logging destination.

`
import logging
import os
Configure logging
log_file_path = os.getenv('LOG_PATH', './vm_creation_logs.json')
logging.basicConfig(filename=log_file_path, level=logging.INFO,
format='{"time": "%(asctime)s", "level": "%(levelname)s", "message": "%(message)s"}')
class AzureVM:
def create_virtual_machine(self, resource_group_name, vm_name, admin_user, admin_password, ports=[], image_data=None, vm_size=None):
    try:
        logging.info(f"VM {vm_name} created with ID: {vm_info.id}")
    except Exception as e:
        logging.error(f"Failed to create VM {vm_name}. Error: {str(e)}")

`
For the VM i was thinking something like this maybe?


politics

the norm on posting CWs about politics probably bears further discussion. As one example:

Seen several "put content warnings on politics" posts and I don't know how to tell white people that 90% of all life is politics. You're asking people to hide the stuff you find unpalatable and that's not a reasonable thing to expect other people to do for you.

seldo

I definitely would like to have more discussion about this! (And I have nothing but infinite respect for Laurie!) Here are my thoughts on the matter, just as a counterpoint. I'm kind of stuck on two ideas. I'm not sure they're necessarily in conflict:
One is what you've got listed above. All things are political! And technology certainly moreso than most topics. I bristle at the whole "don't bring politics into tech/etc." thing. And this community we're establishing is heavily steeped in politics, it effects 99.9% of our work.
But I realize that mastodon is largely a group of other folks' communities and they have established rules of how they want to engage with the world. And moreover, this is a space largely created by queer and underrepresented folks and allies originally. I personally am trying to be sensitive to the established fediverse norms and not act like a colonizer.
And also - yes we can indeed expect folks in our community to hide stuff we find unpalatable, that's what we do in communities. We're not saying "don't talk about it," we're saying be kind in how you talk about it. Just like any other content warning.
(Moreover, I also love that CWs can easily help me filter out the noise of lots of topics I don't care about, e.g. sports.)
Politics, and US politics in particular, can be triggering for folks. What we do on local is one thing, but posting publicly impacts the world around us. And we should approach those spaces respectfully. That's why I think this belongs under Norms (and not COC necessarily).
But this is just my personal, single opinion! Totally open to more conversation here, of course!

Helpful discussion, and thanks for this!
And yep, agreed on this for sure: "be kind in how you talk about it." It's worth saying that precisely — possibly broken out somewhere, in the Code of Care or elsewhere.
A lot of what you've said here is context that not everyone will have, and will be needed to help folks understand the why of some of these guidelines. And if what we'd recommend is different on local than publicly, that should be outlined here too.
This said, the CW recommendation here right now is super wiggly: what, precisely, "off-topic" is here is super arguable until it's been documented or otherwise established.
Also super open to more conversation here: I wonder if anyone else might want to chime in.

I also 100% agree with what's already been said about everything being politics, and that "off-topic" is very arguable. I'm a fan of my current instance's etiquette on CWs, specifically list of things that you are encouraged to CW, and the mention that:

"this is important, so I won't CW" and "this is urgent, so I won't CW" are non-sequiturs - the importance and the urgency have nothing to do with whether that content is more accessible with a content warning

Specifically, my interpretation is that "more accessible" here means that others in the fediverse are less likely to mute or block accounts, and that CW'd content is more likely to get boosted more widely and have a wider reach than otherwise. That might be more useful context in explaining the norms.
I also think it's worth mentioning that people shouldn't feel like they have to CW their identities; this might help balance avoiding colonizing existing spaces, and not put extra onus on new comers from minority groups?:

We don't want to ask anyone to CW their identities. We particularly don't want to ask marginalized people to CW their marginalization

Politics is a trickier one for what we want to encourage, given "everything is politics", and the general focus of the server (civic tech). I don't have any good ideas there. ☹

Hi again, I've had a few conversations with folks and I've come around on my thinking on this.
I 1000% agree with Bryce's comment that people shouldn't feel like they have to CW their identities.  If everyone here is in agreement (it sounds like we are!) I'll remove the politics language from the CW bit?  (Please thumbs-up this comment if y'all are in agreement).


feat: resolve passthrough package.json files

Previously, a re-directing package.json was ignored by the resolver.
Now, package.json files are globbed from the root of any resolved packages, avoiding nested node_modules folders.
Re-Directing package.json file:

A package.json that has an export that redirects to a directory with another package.json"exports": {
    "." "./somedir_with_different_package.json/file.js"
}

Previously Detected (final package.json file):
- ./somedir_with_different_package.json/package.json
Now Detected (all/intermediate package.json files:
-  ./somedir_with_different_package.json/package.json
- ./package.json

Was just curious, is there a reason that this repo doesn't have an automated CI job on it? :-)

GitHub actions hadn't been released yet back when I first put this together 😅. The initial (commercial) project I where I used nexe had its own CI/CD...
But no reason not to add it now 🎉
https://github.com/nexe/resolve-dependencies/pull/21
https://github.com/nexe/resolve-dependencies/actions/runs/4629105141


Add in-portal documentation

- [ ] Description of core concepts to empty states of the tables (especially resources, gateways, etc.)
- [ ] Make sure that when the table is empty buttons in the empty description act as a call to action (to give poor mans onboarding flow)
- [ ] Collapsable documentation sections on the core pages (relays, gateways, clients, actors, etc.) giving short intro in the concepts and linking to additional docs

@jamilbk @jefferenced It would be really helpful if somebody could write that documentation so that we just need to go and do the coding part.

Piece of content from another task for the Gateways:
Description: Gateways must have network-level access to any resource you want to access with Firezone

@AndrewDryga Will hopefully be able to pick up some of the documentation work soon

Note to handle the renaming mentioned here: https://github.com/firezone/firezone/pull/2641#issuecomment-1810725450


Problem with PHP 7.1 at first session initialization and save

Symfony raises an error 500:

An exception has been thrown during the rendering of a template ("Warning: session_start(): Failed to read session data: user (path: /var/lib/php/sessions)").

When reloading the page it will work. It's just at the 1st session init.
The load session mustn't return null but an empty string.
https://stackoverflow.com/questions/48245296/php-custom-session-handler-problems-php-7-1?rq=1

Seems the bundle version we use is outdated. I'll check with new version.

it seems that you're right
=>  http://php.net/manual/en/function.session-start.php#120589
even our current bundle version returns null
=> https://github.com/M6Web/RedisBundle/blob/master/src/Redis/RedisSessionHandler.php#L59
so I'd be ok to approve your PR when you open it

Done.

Closing this, it is outdated.


Looks great, but possible to use with only remote debugging?

Looks like this really solves my problem, but I'm using Chrome headless in a docker image, so I only want to interface w/ port 9222. This seems to use the binaries and maybe phantomjs in the npm install?

Hi! Could you solve it?
There's a way to use it remotely. I couldn't document it yet, but if you send the host, port and a variable indicating that you're debugging remotely, that's it. Oh, and you also must indicate the module don't to launch Chrome.
So, your settings object will look something like:
const settings = {
    launchChrome: false,
    chrome: {
        host: 'http://yourhost.com',
        port: 9222,
        remote: true
    }
}

I hope it helps.
Please, if you make it work, and you can submit a PR with an example in the readme, that will be awesome! So others can benefit from this too.
Thanks!
Luciano

Yep will document this as soon as I get my first end-to-end test working :)


fix: catch exception when already associated

When the association already exists the bootstrap fails, but should succeed.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hi,
sorry for the huge delay here. we do have a conflict here. can you resolve that first before i merge? ty! :)
David


Add ability to pass a storage destination to the Keystore

The Keystore file has a hard-coded default storage path that is dependent on the working directory (i.e. where the java app was started).
private static final String KEYSTORE_PATH = System.getProperty("user.dir") + "/keystore";
It would be really helpful for the aion_ui if we could create and list acoounts to/from a path given as a parameter. This way, we can keep all the configs and files in, say, ${user.home}/.aion directory
Alternatively there could be a custom property that we can set and use for the default path instead od user.dir
NOTE: This issue is resubmitted here afer a request from @qoire in https://github.com/aionnetwork/aion_ui/issues/46

@centrys-otniel Can your team implement this enhancement and submit a PR?

@AionJayT we made a PR for this - https://github.com/aionnetwork/aion/pull/516
let's talk on gitter if you have any concerns


Allow direct $dsn assignment for MONGOLAB_URI

In PaaS, such as Heroku, when you add on a "MongoDB" service, you get a MONGOLAB_URI, which appears to be the entire $dsn required to connect. It should be possible to set the $dsn => $_ENV["MONGOLAB_URI"] rather than having to parse it all out just to be re-combined in Connection.php.
Tommy

You can pass the entire dsn just by using the dsn config key.

My apologies, I looked at the code and didn't see anything that indicated that, but it has been a long time since I worked on PHP :)
~tommy


[k8s] ipv6 support for ip-masq-agent

https://github.com/kubernetes-incubator/ip-masq-agent/pull/45


The $where filter condition is not accepted in the MongoDB Atlas free tier

When I run my application in a MongoDB Atlas with free tier, I get this error
Mongo::Error::OperationFailure: [8000:AtlasError]: $where not allowed in this atlas tier

In my case, the problem is the find_and_lock function in the lib/mongoid/locker/wrapper.rb file.

Looks like https://stackoverflow.com/questions/54200300/how-do-i-solve-mongoerror-where-is-not-allowed-in-this-atlas-tier. Feel free to contribute a different implementation that works on all tiers.

Thank you! I'll suggest you a change via pull request..
On Fri, Mar 3, 2023, 21:56 Daniel (dB.) Doubrovkine <
@.***> wrote:

Looks like
https://stackoverflow.com/questions/54200300/how-do-i-solve-mongoerror-where-is-not-allowed-in-this-atlas-tier.
Feel free to contribute a different implementation that works on all tiers.
—
Reply to this email directly, view it on GitHub
https://github.com/mongoid/mongoid-locker/issues/100#issuecomment-1454118293,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC4XAHT3Z7E2OXTXIXPSRMDW2JLHTANCNFSM6AAAAAAVO4UKYQ
.
You are receiving this because you authored the thread.Message ID:
@.***>


Results reproducibility

Hello, @ruinmessi. Thank you for great research and open source implementation of paper. I tried your implementation on COCO and was disappointed by results.
Shortly, I used your code (without any changes) and your weights for validation on COCO 2014 minival and got next results.
For RBF512-E:
alexkirnas@dev:~/Projects/RFBNet$ CUDA_VISIBLE_DEVICES='0' python test_RFB.py -d COCO \
-v RFB_E_vgg -s 512 --trained_model ./weights/RFB512_E_34_4.pth --save_folder=./eval

....
A lot strings
....

~~~~ Summary metrics ~~~~
 Average Precision  (AP) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.186
 Average Precision  (AP) @[ IoU=0.50      | area=   all | maxDets=100 ] = 0.273
 Average Precision  (AP) @[ IoU=0.75      | area=   all | maxDets=100 ] = 0.204
 Average Precision  (AP) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.137
 Average Precision  (AP) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.271
 Average Precision  (AP) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.271
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=  1 ] = 0.287
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets= 10 ] = 0.430
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.484
 Average Recall     (AR) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.250
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.521
 Average Recall     (AR) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.686

For RBF-Mobile:
alexkirnas@dev:~/Projects/RFBNet$  CUDA_VISIBLE_DEVICES='0' python test_RFB.py -d COCO \
-v RFB_mobile -s 300 --trained_model ./weights/RFB_mobile_20_7.pth --save_folder=./eval
....
A lot strings
....

~~~~ Summary metrics ~~~~
 Average Precision  (AP) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.135
 Average Precision  (AP) @[ IoU=0.50      | area=   all | maxDets=100 ] = 0.217
 Average Precision  (AP) @[ IoU=0.75      | area=   all | maxDets=100 ] = 0.144
 Average Precision  (AP) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.015
 Average Precision  (AP) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.159
 Average Precision  (AP) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.258
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=  1 ] = 0.207
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets= 10 ] = 0.300
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.311
 Average Recall     (AR) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.035
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.328
 Average Recall     (AR) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.584

Note: I run code on Python 3.6 with newest PyTorch (v 0.3.0, installed via pip) and CUDA8.0.
This results is to much different from reported one in the paper so this is cannot be connected with usage of different data (your report results on trainval35k set). Can you reproduce your results with newest PyTorch?
Thanks,
Alex

@ALEXKIRNAS I reproduced RBF512-E results on 2014minival as follows, and no problem occured.
~~~~ Summary metrics ~~~~
 Average Precision  (AP) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.341
 Average Precision  (AP) @[ IoU=0.50      | area=   all | maxDets=100 ] = 0.547
 Average Precision  (AP) @[ IoU=0.75      | area=   all | maxDets=100 ] = 0.361
 Average Precision  (AP) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.183
 Average Precision  (AP) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.375
 Average Precision  (AP) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.486
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=  1 ] = 0.288
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets= 10 ] = 0.445
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.476
 Average Recall     (AR) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.282
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.509
 Average Recall     (AR) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.639

I am not sure about what happens in your results. I suggests you choose your dataset annotations first, and then recompile the nms code. Also you can try the "time" branch of this repo.

@ALEXKIRNAS I reproduced RBF512-E results on 2014minival as follows, and no problem occured.
~~~~ Summary metrics ~~~~
 Average Precision  (AP) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.341
 Average Precision  (AP) @[ IoU=0.50      | area=   all | maxDets=100 ] = 0.547
 Average Precision  (AP) @[ IoU=0.75      | area=   all | maxDets=100 ] = 0.361
 Average Precision  (AP) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.183
 Average Precision  (AP) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.375
 Average Precision  (AP) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.486
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=  1 ] = 0.288
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets= 10 ] = 0.445
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.476
 Average Recall     (AR) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.282
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.509
 Average Recall     (AR) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.639

I am not sure about what happens in your results. I suggest you check your dataset annotations first, and then recompile the nms code. Also you can try the "time" branch of this repo.

@ALEXKIRNAS I reproduced RBF512-E results on 2014minival as follows, and no problem occured.
~~~~ Summary metrics ~~~~
 Average Precision  (AP) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.341
 Average Precision  (AP) @[ IoU=0.50      | area=   all | maxDets=100 ] = 0.547
 Average Precision  (AP) @[ IoU=0.75      | area=   all | maxDets=100 ] = 0.361
 Average Precision  (AP) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.183
 Average Precision  (AP) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.375
 Average Precision  (AP) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.486
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=  1 ] = 0.288
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets= 10 ] = 0.445
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.476
 Average Recall     (AR) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.282
 Average Recall     (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.509
 Average Recall     (AR) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.639

I am not sure about what happens in your results. I suggest you check your dataset annotations first, and then recompile the nms code. Also you can try the "time" branch of this repo, which uses a new pytorch gpu nms version.

@ruinmessi,@ALEXKIRNAS ,how about the result of voc2007 AP75?could you share your result?

@gittigxuy I have not test it yet, you can just modify the parameter of evaluation code in voc0712.py for AP75.


error adding symbols: Bad value

So first I was getting this:
$ make
[ 10%] Built target jerry-libm
[ 85%] Built target jerry-core
[ 93%] Built target jerry-ext
[ 96%] Built target jerry-port-default-minimal
[ 99%] Built target jerry-port-default
[100%] Linking C executable ../bin/jerry.exe
/bin/ld: unrecognized option '-z'

So I removed this:
https://github.com/jerryscript-project/jerryscript/blob/25b81c106c07f33f576fb24c5c636d5799ac1eff/CMakeLists.txt#L183
but it still fails:
$ make
[ 10%] Built target jerry-libm
[ 85%] Built target jerry-core
[ 93%] Built target jerry-ext
[ 96%] Built target jerry-port-default-minimal
[ 99%] Built target jerry-port-default
[100%] Linking C executable ../bin/jerry.exe
/bin/ld: ../lib/libjerry-core.a(ecma-helpers-number.c.o): bad string table size 0
../lib/libjerry-core.a: error adding symbols: Bad value

What is your build platform? Architecture, OS, version?
What is your compiler, linker? Name, version?
What is your build target? Architecture, OS, version (if applicable)

$ uname -a
CYGWIN_NT-6.1 Steven-PC 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin

$ find /bin -samefile /bin/gcc.exe
/bin/gcc.exe
/bin/x86_64-pc-cygwin-gcc-7.4.0.exe
/bin/x86_64-pc-cygwin-gcc.exe

@cup Please, note that cygwin has never been among the supported platforms of this project. Anyway, I cc: @ossy-szeged , who has been working on the Windows support lately. Perhaps he knows what's going on there. But you are also welcome to contribute if you can find the fix to the build system.

I tried cygwin build and got the following error message:
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
compilation terminated.
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/bin/ld: ../lib/libjerry-core.a(ecma-builtin-json.c.o) (/711
/10): Section flag STYP_GROUP (0x4) ignored
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/bin/ld: ../lib/libjerry-core.a(ecma-builtin-json.c.o) (/711
/10): Section flag STYP_COPY (0x10) ignored
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/bin/ld: ../lib/libjerry-core.a(ecma-builtin-json.c.o): warning: COMDAT symbol '.gnu.lto_ecma_builtin_json_parse_next_token.6ef7c7fa669409d5' does not match section name '/711
/10'
And I found this related cygwin bug report:
http://cygwin.1069669.n5.nabble.com/Error-Linking-LTO-programs-using-GCC6-4-td136659.html
It seems LTO is still buggy on cygwin (tried with latest cygwin with GCC 7.4). But without LTO enabled, the build suceeded for me. Until this bug is fixed in cygwin, you should pass --lto=OFF to build.py.
Otherwise do you have any reason to use cygwin instead of native Windows build? The native build works fine and tested day by day. You only need cmake, python and MSVC installed.

Otherwise do you have any reason to use cygwin instead of native Windows
build? The native build works fine and tested day by day. You only need cmake,
python and MSVC installed.

Using the current version with the pull request merged, solved the issue for me.
In regard to Cygwin version vs Native Windows build, I dont have a preference,
I just figured the Cygwin build would be easier to make. Also I didnt realize
that builds are already available here:
https://ci.appveyor.com/project/jerryscript-project/jerryscript
that should probably be mentioned somewhere, so people are building for no
reason. In regard to building the native version, by MSVC I assume you mean
Visual Studio? If I am building native I will use mingw64, as its about 2 orders
of magnitude smaller than Visual Studio.
At any rate, thanks all.

https://github.com/jerryscript-project/jerryscript/pull/3147

A few things to point out:

Please note that the CI builds are for testing.
The JerryScript is (mainly) library with lots of build/runtime options. It is possible that the options defined for CI build/testing is are too much/few for a given project/usage. There are also no pre-built shared libraries for other platforms.
The jerryscript-main (from which the executable is built) is an example REPL for the project.
Regarding the binary sizes it is interesting to hear, it would be good to have concrete numbers (in a different issue). What I'm guessing there is a difference on compiler options.


Remove non-working printout of the diagnostic

Accidentally left in the code this naïve implementation.

@bot-gradle merge

WARN: The milestone of this PR is 8.7 RC1, but the base branch version is 8.8

The merge queue build has started. Click here to see all failures if any.

@bot-gradle cancel

The merge queue build has started. Click here to see all failures if any.

The merge queue build has failed. Click here to see all failures.

@bot-gradle merge

The merge queue build has started. Click here to see all failures if any.


Tuple pattern

What was wrong?
Add tuple pattern matching.
This PR depends on #770
To-Do

[ ] OPTIONAL: Update Spec if applicable

[ ] Add entry to the release notes (may forgo for trivial changes)

[ ] Clean up commit history

I decided to include this in #770


add default terminal timeout

Terminal wait for click forever without this option.

Hi, thanks for the PR!
In what situations does Terminal what forever? I am using the latest versions of capistrano-nc and terminal-notifier and I don't have this problem. For me, the notification automatically slides away after about 3 seconds and Terminal does not hang.
terminal-notifier (1.8.0)
capistrano-nc (0.1.4)
OS X El Capitan 10.11.6 (15G1510)

Never mind, I see the hanging behavior in my Terminal now. Thanks for figuring this out!

I did some more research and found that this is actually a bug in version 1.8.0 of the terminal-notifier gem: https://github.com/julienXX/terminal-notifier/issues/223
The author suggests that we use version 1.7.2 until this bug is fixed.
I'd rather the fix be done upstream than implement a workaround in capistrano-nc.
Can you try pinning terminal-notifier to 1.7.2 in your project's Gemfile and see if that fixes the problem?

I change terminal-notifier to 1.7.2, the script will end perfectly, but the popup window still need close by manually.

I believe you can get the popup to auto-dismiss by choosing the "Banners" style in Notification Preferences, like this:

That seems good, but changing this setting will effect whole terminal-notifier ?

This is another case where the fix should be in an upcoming version of the terminal-notifier gem: https://github.com/julienXX/terminal-notifier/issues/231#issuecomment-312201682

terminal-notifier version 2.0.0 as been released with alerter features removed https://github.com/julienXX/terminal-notifier/releases/tag/2.0.0 so this issue is now fixed if you update.

This should be fixed by #9.


Add extra RPC modules (grandpa)

Adds grandpa and babe RPCs.

remove the old extensions builder if possible :)

Definitely, we'll have to port over all of these first. Working on SyncState now.


Release workflow

Purpose
Adds a workflow automatically compiling native dependencies and attaching a jar with the dependencies embedded to new releases when created. Also generates javadoc both as a .jar attached to the release and as a "site" deployed to https://concordium.github.io/concordium-java-sdk/javadoc/concordium-sdk/apidocs/
Result of release demonstrated as release in https://github.com/magnusbechwind/concordium-java-sdk/tree/v2.0
Changes
Added workflow and updated the pom
Checklist

[x] My code follows the style of this project.
[x] The code compiles without warnings.
[x] I have performed a self-review of the changes.
[x] I have documented my code, in particular the intent of the
hard-to-understand areas.
[x] (If necessary) I have updated the CHANGELOG.

In addition to the proposed changes, the settings/pages should also be changed accordingly to correctly deploy javadoc to pages


File Methods should resolve to file name

Instead of having get,put,append,rename,delete resolve to undefined have them resolve to the files they operated on.
The reason for me is that I'm uploading an entire directory of files to a remote server.
I use BlueBird.map for this.
I would like to delete my source file if the put is successful.
But I cannot tell what file was uploaded in the put's promise resolution.

Sounds like a solid idea -- I would gladly accept a PR with this change.


Move applications/ URL paths from beta->v0

:nut_and_bolt: Description: What code changed, and why?
In preparation for a GA release of the EAS applications functionality, the API URL paths are moved from beta/ to the versioned/stable v0 paths.
:chains: Related Resources
#1958
:+1: Definition of Done
:athletic_shoe: How to Build and Test the Change

build automate-gateway and -ui; start all services
the UI should function as before
export T=$(get_admin_token)
APIs should be accessible with curl via URLs under api/v0, e.g.: curl -k -H "api-token: $T" https://a2-dev.test/api/v0/applications/services

:white_check_mark: Checklist

[x] Docs added/updated?

Discussed in meatspace that we can merge this one now since it's not changing default visibility.


Listen for file system changes

Is your feature request related to a problem? Please describe:
With the current api there's no way to run code when some file/folder get's added or removed from the virtual file system. This can happen for example by running a command. If you want to show a FileSystem tree in your UI it's important to keep it in sync with the virtual file system and sometimes running the sync after a command run it's not enaugh (for example there are long running processes that generate files and you want those to be visible in the UI).
Describe the solution you'd like:
Add a webcontainer.fs.watch command that receive a callback that runs whenever the filesystem changes.
Describe alternatives you've considered:
Right now i'm running a parallel task with chokidar and i manually parse the logs from chokidar but that's not a wonderful solution at all and it's very risky.

Hey @paoloricciuti 👋 . Yes, we currently don't expose a way to watch a file or folder with WebContainer API but that's definitely a valid feature request. I created an internal ticket to track this.

Hey @paoloricciuti 👋 . Yes, we currently don't expose a way to watch a file or folder with WebContainer API but that's definitely a valid feature request. I created an internal ticket to track this.

Thank you very much, it would be very much appreciated

This could do the job maybe? https://github.com/wheatjs/webcontainer-reactive-fs

Hi :wave:. fs.watch is now available inthe WebContainer API as of version 1.1.8 :tada:
https://webcontainers.io/api#▸-watch


[Experiment] read libra trace from elastic search

Motivation
(Write your motivation for proposed changes here.)
Have you read the Contributing Guidelines on pull requests?
(Write your answer here.)
Test Plan
(Share your test plan here. If you changed code, please provide us with clear instructions for verifying that your changes work.)
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/libra/website, and link to your PR here.)

:umbrella: The latest upstream changes (presumably 5a023ac61e0c4936878b7feef9c9d8f4cceb85c6) made this pull request unmergeable. Please resolve the merge conflicts.

:umbrella: The latest upstream changes (presumably cdd1c933cb8378620d422006b84346e53b223ef2) made this pull request unmergeable. Please resolve the merge conflicts.

:umbrella: The latest upstream changes (presumably fece82d1258bed157b6ee2d5b0ee4a454db5a846) made this pull request unmergeable. Please resolve the merge conflicts.

:umbrella: The latest upstream changes (presumably 7a881f4d654a70b076df9b174ba2d1f2a1691a60) made this pull request unmergeable. Please resolve the merge conflicts.


Fixes #1207: add counters for total active service connections

I'm going to refactor this to move the counters into their own entity.  Marked as draft for now.


Use PSI for running the tests currently running on Travis

Move the tests currently running on Travis to PSI cluster. These are mainly OpenShift 3.11 and Kubernetes tests.

[x] Kubernetes tests on PSI #4287
[ ] OpenShift 3.x tests on PSI #4288

/area testing
/assign @mohammedzee1000

Move the tests currently running on Travis to PSI cluster.

AFAIK PSI is already overloaded with the test execution running on ocp 4.* clusters with multiple platform and we are in need of more resources. IIRC we intentionally removed 3.11 cluster on PSI due to insufficiency of resources and moving travis to PSI will be even worse I think. IMO choosing PSI would be nice if we have ample of resources and that would definitely take some time. More importantly we can not escape running tests on kubernetes for long because it might lead to broken code as before. IMO using Github CI could be a best choice instead of PSI. Once we have ample of resources, we can think of moving it slowly. @kadel @mohammedzee1000 WDYT?

Based on the discussion we had on stand-up call, I think we're good to use PSI hardware for these tests. We need to bring up minikube & minishift using containers instead of bringing them up as VMs. Breaking this down into two issues. Let's start by focussing on minikube since it boots fast and we really need to get k8s tests back ASAP.

AFAIK PSI is already overloaded with the test execution running on ocp 4.* clusters with multiple platform and we are in need of more resources.

How do you know that the ocp 4.x cluser is overloaded? I'm using it almost every day, and haven't noticed any problems.
Do we have any metrics suggesting that it is getting overloaded?
on PSI we are using about 3/4 of resources, we still have a lot to spare

/remove-lifecycle stale
@rnapoles-rh @prietyc123 please close this one when the issues related to it are done.

OpenShift 3.x tests on PSI Use PSI for running OpenShift 3.x tests #4288

Not relevant anymore. As we don't support 3.11 now. Apart from this all the tests running on travis (windows and macOS unit test, kubernetes job) are successfully running on prs now. So closing this issue
/close


soc: imx8m: change RDC configuration based on device tree

Can disable RDC configuration if RDC node is disabled.

Addressed @decsny  comments and rebased.


DVX-48: Add support for search log access

Todos

[x] monitor views of assets over some time span (this is part of the new search log)
[x] monitor search queries for patterns (common / emerging) — also part of the new search log (via cmd + k)
[x] add unit and integration tests.
[x] add snippets to the developer portal docs.

Sample Snippets
1.  Without time range
from pyatlan.model.search_log import SearchLogRequest
from pyatlan.client.atlan import AtlanClient

client = AtlanClient()

request = SearchLogRequest.by_guid(
    guid="<asset-guid>", user_size=2
)
response = client.search_log.search(request)

print(f"Total Assets Views : {response.total_views}")

for user in response.unique_users:
    print(
        f"Username : {user.name}, View count: {user.view_count}, Last view timestamp : {user.view_timestamp}"
    )

Output:
Total Assets Views : 39
Username : aryaman.bhushan, View count: 37, Last view timestamp : 2023-12-05 11:27:56.977000+00:00
Username : chris, View count: 2, Last view timestamp : 2023-12-05 09:52:46.723000+00:00

2. With time range
client = AtlanClient()

# 4 hrs ago
request = SearchLogRequest.by_guid(
    guid="<asset-guid>",
    user_size=2,
    start_time=1701766262000,
    end_time=1701780919766,
)

response = client.search_log.search(request)
print(f"Total Assest Views : {response.total_views}")

for user in response.unique_users:
    print(
        f"Username : {user.name}, View count: {user.view_count}, Last view timestamp : {user.view_timestamp}"
    )

Total Assest Views : 13
Username : aryaman.bhushan, View count: 12, Last view timestamp : 2023-12-05 11:27:56.977000+00:00
Username : chris, View count: 1, Last view timestamp : 2023-12-05 09:52:46.723000+00:00

3. Retrieve recent search log
client = AtlanClient()
request = SearchLogRequest.get_recent_search(usernames=["aryaman.bhushan"], size=5)
response = client.search_log.search(request)

print(f"Total search count: {response.total_count}")
for asset_log in response:
    print(asset_log.dict())

Total search count: 81
{'log_host': 'devx.atlan.com', 'log_ipaddress': '<ip_address>', 'log_user_agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15...', 'log_username': 'aryaman.bhushan', 'log_guid': '<asset_guid>', 'log_qualified_name': '<asset_qualified_name>', 'log_type_name': 'Table', 'log_timestamp': datetime.datetime(2023, 12, 6, 8, 26, 59, 986000, tzinfo=datetime.timezone.utc)}
...
...

Looking good to me — just curious if the response object(s) are capturing all output that comes back (full response payload)?

Looking good to me — just curious if the response object(s) are capturing all output that comes back (full response payload)?

Nope, I'm only capturing aggregations{}, approximateCount, and excluding "searchParameters": {"dsl": "{}", "querystring": {}} (since it's the same as the request payload)
    "aggregations": {
        "topVisitors": {
            "doc_count_error_upper_bound": 0,
            "sum_other_doc_count": 0,
            "buckets": [
                {
                    "key": "aryaman.bhushan",
                    "doc_count": 40,
                    "viewsSum": {
                        "value": 40.0
                    }
                },
                {
                    "key": "chris",
                    "doc_count": 2,
                    "viewsSum": {
                        "value": 2.0
                    }
                }
            ]
        },
        "totalDistinctUsers": {
            "value": 2
        },
        "uniqueUsers": {
            "doc_count_error_upper_bound": 0,
            "sum_other_doc_count": 0,
            "buckets": [
                {
                    "key": "aryaman.bhushan",
                    "doc_count": 40,
                    "latest_timestamp": {
                        "value":<PHONE_NUMBER>995
                    }
                },
                {
                    "key": "chris",
                    "doc_count": 2,
                    "latest_timestamp": {
                        "value":<PHONE_NUMBER>723
                    }
                }
            ]
        }
    },
    "approximateCount": 42

thinking it would be good to have the user_size parameter also be optional (e.g. "just show me everyone who's viewed this asset in the last 90 days"), or is it required in the request? (if required in the request we might still want to just default it to some value like 10 if not passed to the method)

It is optional, and I have set the default value to 20, similar to the frontend UI.

also I would probably change the named parameter from user_size to max_users

Sure, that would be nice, I'll update that!

excluding "searchParameters": {"dsl": "{}", "querystring": {}} (since it's the same as the request payload)

But we are capturing the original request, so we can use that to simplify paging (just iterating over the results object), right? 🤞

Did you get paging to work in the end, or is it still not working?

Yes, it works for retrieving detailed search log entries.


turbolink

when i click the back button in browser, turbolinks loads twice. how to solve this problem

Sorry, but please consider this project deprecated. In hindsight, it really isn't an ideal solution at all.
Consider http://ricostacruz.com/rsjs instead (disclaimer: I wrote this document, and onmount which it mentions a few times)

@rstacruz let's make it finally deprecated. Sorry that it took me that long.
Could you please update README and direct people to your solution? I did really lost track and don't understand all the issues of jquery.turbolinks, so I won't be able to clearly communicate it.

Done - #67, I've also outlined a quick rationale to explain why. :)

thanks , i'll check


Universal UI

Read this http://jxnblk.com/writing/posts/patterns-for-style-composition-in-react/
The author created awesome libraries like rebass and reflexbox.
I think this is the right path.

Text, it's must for inline styles
Link, to replace both a and React Router Link, it's the must for inline styles. In React Native it will use react-router-native Link.
Paragraph? It's no go since we would have to parse elements from the string. The paragraph is actually just a styled Text.
etc.

We can create universal ../../common/components. How? With the higher order component injecting a platform-specific element via context like I suggested here: https://github.com/yahoo/react-intl/issues/600
Something like injectElements(Foo, { Text, View }), not sure yet.
import { injectElements } from 'react-universal'
We are not there yet. Use src/browser/app/components and src/native/app/components if you want to use inline styles now.
Blocked by https://github.com/yahoo/react-intl/issues/600

const styles = {
  app: {
    marginLeft: 'auto',
    marginRight: 'auto',
    maxWidth: theme.fontSize * 42,
  },
};

class App extends Component {

  render() {
    return (
      <div style={styles.app}>

I think This is the future:
import { Text, Link } from '../../common/components'

Inconsistencies

lineHeight, browser uses multiple, native pixels

Hmm, this looks very pretty https://github.com/jxnblk/rebas

I think we still need the https://necolas.github.io/normalize.css/ It's tiny.


Allow to circumvent Scala version checks

Just in case. Having issues with it with locally published Scala versions right now, so I'd rather disable this check if I can.
Needs https://github.com/scalacenter/bloop-config/pull/20, https://github.com/scala-cli/bloop-core/pull/129

Just in case. Having issues with it with locally published Scala versions right now, so I'd rather disable this check if I can.
Needs scalacenter/bloop-config#20, scala-cli/bloop-core#129

What is the issue you are getting? It should work correctly for locally published jars, last time I checked the correct bridge was used if available.

What is the issue you are getting? It should work correctly for locally published jars, last time I checked the correct bridge was used if available.

Precisely, bridges are fetched from the default coursier repositories, so ~/.ivy2/local and Maven Central. For reproducibility, we use a custom repo in an arbitrary directory in the test added here. Having Bloop accept the bridge JAR alongside the compiler JARs allows to get that bridge JAR via the custom repo, that the build tool (Scala CLI) knows about, while Bloop doesn't.

Just moved the non-regression test, along with the Bloop-related changes it requires, to https://github.com/VirtusLab/scala-cli/pull/1889

Closing this for now, as there's been no activity neither here nor in the prerequisite PRs for a long while.
Feel free to reopen if you continue working on this.
Progress is to be tracked under #2447.


Added result for 'what is the average airspeed velocity of an unladen swallow'

Implemented by popular request: https://twitter.com/#!/GovUK/status/164755846507663360

I think this is an excellent idea!


It stopped working

It just stopped working after a VS Code update. I tried uninstalling, restarting, then installing it from the browser marketplace, and from VS Code itself. I uninstalled other extensions for snippets and tried all over again, and nothing. I don't know what else to try, and I'd really like this to work again. Any ideas what I can do?
Thanks.

@danieltkach , Can you provide the details like the version of the plugin and the version of the VS Code? Thanks!


CFP: mTLS security between hubble-cli & hubble-relay

Cilium Feature Proposal
Is your feature request related to a problem?
Right now everyone with network access to the hubble-relay port can view all traffic within the cluster by providing --tls-allow-insecure flag.
At the same time the hubble-cli client can establish secure mTLS authenticated connection with either cilium-agent hubble port or hubble-relay hubble-port.
Similarly hubble-ui is most probably able to establish secure mTLS connection with hubble-relay https://github.com/cilium/cilium/blob/master/install/kubernetes/cilium/templates/hubble-ui/deployment.yaml#L87
Describe the feature you'd like
Right now mTLS in hubble-relay server side is explicitly disabled in code https://github.com/cilium/cilium/blob/master/hubble-relay/cmd/serve/serve.go#L200
I would like mTLS support to be added, so clients have to authenticate themselves using TLS certs.
(Optional) Describe your proposed solution
The smallest change needed to enable mTLS which gives better security in terms of in cluster visibility is to just pass caFiles already used for hubble-relay <-> cilium-agent communication
--- a/hubble-relay/cmd/serve/serve.go
+++ b/hubble-relay/cmd/serve/serve.go
@@ -197,7 +197,7 @@ func runServe(vp *viper.Viper) error {
        } else {
                tlsServerConfig, err := certloader.NewWatchedServerConfig(
                        logger.WithField("config", "tls-server"),
-                       nil, // no caFiles, mTLS is not supported for Relay clients yet.
+                       vp.GetStringSlice(keyTLSHubbleServerCAFiles),
                        vp.GetString(keyTLSServerCertFile),
                        vp.GetString(keyTLSServerKeyFile),
                )

This is not backwards compatible though and raises a few questions:

Is it safe to assume that we can reuse the same CA for hubble-CLI/hubble-relay mTLS which is used for hubble-relay/cilium-agent mTLS? Or should we rather generate a new CA for hubble-cli/hubble=relay?
Should we add an additional flag to allow disabling (or enabling) server-side mTLS in hubble-relay so you can still access it without any certs (keep current behavior available).

I created PR addressing this issue. Currently this is left disabled by default. https://github.com/cilium/cilium/pull/25582


Accordion Item doesn't accept custom className

Describe the bug
The accordion items within the accordion does not accept custom classnames. This complicates styling of nested accordions, or different styling of accordion-items within the same accordion.
To Reproduce

Create an accordion containing an accordion item.
Give the accordion item a className.
See that it's not in the html.

Expected behavior
I expect to be able to style Accordion Items individually. I'm trying to differentiate a nested sets of accordion-items within an accordion-item as shown below. This is for an internal tool.
Desktop (please complete the following information):

OS: Red Hat Enterprise Linux Server 7.7
Browser: Chrome
Version:  "@fremtind/jkl-accordion-react": "1.0.0"

We really should not nest accordions, but the component should accept custom class names in either case, so I'll start a PR.
I bet this is something a designer would love to take a stab at if you let them 😉 (@Mikkelinski?) I would check out the sketches for FLYT in Figma for inspiration on how to deal with progressive disclosure in containers (cards).

Hehe, yeah I know. That's why I specified it was for an internal tool - to "kind of" redeem myself.
I do however have a pretty complex structure that I don't think we will run into too often, so this specific case might not be worth a designers time, but as it's demonstrated in the screenshot above may be something that appears several places.

I think the complex and "unique" cases can be very rewarding to solve for our designers! We really need practice in using our profile right now, so every problem is a good problem 😁 If you're lucky, they might even find a less complex solution!
A fix for your issue is none the less right around the corner :)


A11y_AzureDataStudio_BigDataClusterOverviewPage_ScreenReader : VoiceOver is not announcing control type for the buttons such as "Big Data Cluster Overview"

"Check out Accessibility Insights!- Identify accessibility bugs before check-in and make bug fixing faster and easier."
GitHubTags:#A11y_ADS_OctTestPass;#A11yMAS;#A11yTCS;#MAS1.3.1;#MAS4.1.2;#DesktopApp ;#VoiceOver;#SQL AzureDataStudio;#Mac
Environment Details:
Application Name: Azure Data Studio
Version: 1.12.0-insider (user setup)
Commit: 6582debd7388b1be512fc3a9b956d3e54f6115e7
Date: 2019-10-03T08:56:27.454Z
VS Code: 1.38.0
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS:macOS Mojave Version 10.14.6(18G87)
Additional Details:
Tool Name : VoiceOver
Steps to Reproduce:

Install and Launch the application the azure data studio application.
Open the “Connections” viewlet (CTRL + SHIFT + D)
Navigate to the “SQL Server Big Data Clusters” section and expand it
Navigate to the "Add SQL Server big data cluster controller…" node and click on it.
Fill in the connection information for the BDC Controller Endpoint
Click “Add”
Navigate to the controller node in the “SQL Server Big Data Clusters” view and right click on it, then select “Manage” to open the dashboard
Start Voiceover.
Navigate till "troubleshoot " button  using tab and then use ctrl-option-arrows navigation.
Observe the announcement by screen reader when screen reader focus moves to the "Big Data Cluster Overview"

Actual:
Screen reader only announce the "Big Data Cluster Overview" and not the control type  for it .
Expected:
Screen reader should announce the "Big Data Cluster Overview" and the control type  for it  that is button.
User Impact:
Screen reader user will  find it difficult to navigate the screen.
Attachment for Reference:

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

#Azure Data Studio - New Features_Mac;

A11ySev2

#Closed; #Regressed:07-14-23;


fix(query): check content for query schema

Status
READY
Description
Fix issue #247
Steps to Test or Reproduce
check issue #247

Hello @mwlazlo, thanks for the pull request. I didn't know that a parameter could have a content there are some cases where it's needed instead of a schema directly? Also would be interesting to not only handle application/json in that case no?

Hi @anymaniax! Yes, we didn't realise it either until the generator tool we use for backend code failed to emit a parser for an object unless we specified the mime type.
Currently, Orval will automatically emit application/json if the schema is an object, so this fix is equivalent while supporting the spec (admittedly only for this specific use case).
Besides, I have no idea how or why you would render an object as, say, text/plain :-)


How to run this project file in Local Environment using IntelliJ

Can some one provide the proper document how to run this project on the local machine. That would be helpful. Because I am facing lots of error while running the application on my IntelliJ. And also please let me know which version of JDK is supported as well as Groovy version!
Thanks in advance
Sanjay B S

resolved


update from upstream

fix: set maximum backtrace
chore(deps): update docker/build-push-action action to v4.1.0
chore(deps): update actions/checkout action to v3.5.3
chore(deps): update returntocorp/semgrep docker tag to v1.26.0
chore(deps): update rust:1.70.0 docker digest to 508253a
chore(deps): update docker/build-push-action action to v4.1.1
chore(deps): update dependency semantic-release to ^21.0.5
chore(deps): update docker/metadata-action action to v4.6.0
chore(deps): update alpine docker tag to v3.18.2
chore(deps): update returntocorp/semgrep docker tag to v1.27.0
chore(deps): update docker/setup-buildx-action action to v2.7.0
chore(deps): update github/codeql-action action to v2.20.0
chore(deps): update alpine:3.18.2 docker digest to c7431a7

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


Help generating docs from collection of nested index.d.ts and tsconfig.json files

Search terms
Help generating docs from collection of nested index.d.ts and tsconfig.json files.
Question
I am attempting to create TypeDoc documentation from the Types-for-Adobe repo.
I am able to successfully generate docs if I cd into specific sub-directories (see my ae-types branch), but would ideally like to generate a single ./docs folder at the root of the project. If possible, I would also like each entry point to be represented as a "module" in the menu of the generated docs website, rather than the single "types-for-adobe" that shows up in my example.
Also, I'd like to propose this change to the maintainers of the Types-for-Adobe repo and would therefore like to achieve this with minimal disruption of files/workflow. Is this possible?
My current approach is to list each index.d.ts file as an entryPoint in a typedoc.js options file (seen in my fork of the project). But, this results in:
error Unable to find any entry points. Make sure TypeDoc can find your tsconfig
How do I make sure TypeDoc can find each index.d.ts respective tsconfig.json files? I've tried switching entryPointStrategy to each of the options but have had no luck.

TypeDoc supports packages as an entry point strategy for handling projects with multiple tsconfig files, but using that requires a package.json file for each dependent package. In this case, I'd probably recommend a script which generates them in each documented directory, and then cleans up after itself when complete.
https://github.com/fartinmartin/Types-for-Adobe/pull/1

Awesome—thank you for taking a look! I will close for now and work on a script as you describe. I'll come back to comment my solution or re-open if necessary.

Ha! Didn't see that you wrote that script for me—thanks so much!


Toolbar Disappear when using image picker for photo send.

My bottom toolbar disappear when using image picker for selecting photo from gallery.Help please regarding this.

@nileshjaiswal16 When presenting, the system will present and replace the current view controller that makes the presenting view controller the top of the view controller stack. It is an expected behavior.

Hello everyone!
I'm sorry to inform the community that I'm officially deprecating this project. 😢 Please read my blog post for details:
http://www.jessesquires.com/blog/officially-deprecating-jsqmessagesviewcontroller/
Thus, I'm closing all issues and pull requests and making the necessary updates to formally deprecate the library. I'm sorry if this is unexpected or disappointing. Please know that this was an extremely difficult decision to make. I'd like to thank everyone here for contributing and making this project so great. It was a fun 4 years. 😊
Thanks for understanding,
— jsq


Configuration file dataset config always uses IID splitter

It is not possible to test non-IID data splits by editing the .yaml configuration files as the IID splitter is always used.
To replicate, run blades/tuned_examples/fedavg_cifar10_resnet_noniid.yaml where
       iid:
        grid_search: [False]
       alpha:
        grid_search: [0.1, 0.5, 1, 100]

The resulting trials use the IID data splitter and have the same results for different alpha values.

Using the partitioner_config configuration as in the new examples works. Addressed in #81

Using the partitioner_config configuration as in the new examples works. Addressed in #81

Thank you so much @MarkHolmstrom for your contribution! The non-IID partitioner is running smoothly now. I am now closing this issue. I appreciate your reported issue and the modifications you provided. Looking forward to possibly collaborating again in the future!

I am looking forward to it as well as I plan to use this library for a research project.


Add ReorgYolo

Add support for the ReorgYolo op to the PlaidML plugin. It is possible that code for this already exists and just needs to be wrapped in calling code in inference-engine/src/plaidml_plugin/ops/reorg_yolo.cpp.

In particular, there's an oplib reorg_yolo (see plaidml/op/op.h in the PlaidML repo) that we can probably wrap to implement this.


DO NOT USE this app. SPYWARE WARNING

https://github.com/wewewe718/QrAndBarcodeScanner/issues/144

If you use F-Droid you're fine.
So, just use F-Droid.

If you use F-Droid you're fine. So, just use F-Droid.

I currently use Obtainium, which gets releases from github directly

If you use F-Droid you're fine. So, just use F-Droid.

I currently use Obtainium, which gets releases from github directly

Do not use github until some pr similar to this one merge https://github.com/wewewe718/QrAndBarcodeScanner/pull/151 meanwhile download the fdroid version

I use Barcode Scanner by Atharok, UI is great, everything just works fine(including flash) with no data collection at all :-)

This is also an Android issue, i have to give permission to use camera, storage, etc, but no permissions requested for internet. Go Netguard (~2020 version) or some kind of firewall…


Failed to start gauge API: Timed out connecting  (Gauge-Python)

Expected behavior
gauge should start running tests
Actual behavior

Failed to start gauge API: Timed out connecting <IP_ADDRESS>:{port_no}
Issue similar to #1432 . I am facing a similar issue with gauge-python test suite.
Also I am not able to view api.logs file . logs folder.

I have tried updating to latest gauge version but issue persist.
Steps to reproduce
You can reproduce it by running sample gauge-python project in a kubernetes pod.

Build docker image by using below dockerfile in your project. and then host image.
Install minikube & kubectl and start minikube.
Run image in kuberentes pod

Setup
I am running test cases within a kubernetes pod and sometimes getting the same error.
Please look into this
ERROR Screenshot:

Default Properties:

Dockerfile

Was able to solve this issue.
The kubernetes pod was not having enough resources to connect within default timeout period.
For more description refer here.


Add singularity resources

Update Makefile to download singularity .deb and .rpm packages
from Github Releases, and add singularity-deb and singularity-rpm
as slurmd resources.

@heitorPB Is it approved now?


[Request] Separate Stable Process For Updates

Can you please add a separate process that automatically checks for and installs updates.
I think it’s important to have stable and automated updates early on in development.
Because, if any vulnerabilities or bugs were to be discovered later on then it would not be as big of an issue to fix.
As opposed to having manual updates which would result in lots of users who still have old vulnerable or unstable versions because, they forgot to check for updates, I can give many examples of this happening.
Thanks

That would be redundant and incompatible with package managers already available for your operating system.
This kind of this is better managed by choco, homebrew, apt, pacman, etc. We should rather help dnscrypt-proxy2 get into these package repositories if it is not available already :)


fix(browser): Dedupe external deps from bundle

@bugsnag/core and @bugsnag/plugin-window-unhandled-error both had local copies of the same external modules in their node_modules.
This meant error-stack-parser and iserror got included twice in the output bundle. This commit exposes the modules from inside @bugsnag/core and the unhandled rejection plugin references it from there, so they are sure to get only one and the same module.

Before
After
Diff

min
44.01kB
39.15kB
-11.0%

min + gz
11.83kB
11.68kB
-1.2%

I'm going to reopen this with a different branch name. The / doesn't work with the test container registry.


Simplistic writer

This draft shares my initial implementation of a simplistic writer that assumes a single process writing messages from a topic to a delta table.
There is a fair bit left to do before I move this into official PR status:

[x] Add a simple end-to-end integration test
[x] Add command line arguments via clap
[x] Handle allowed_latency
[x] Handle the many unwrap() invocations as errors
[x] wrap start and internal state in a struct to add a control plane surface area
[ ] Breakup and tidy run_loop
[ ] Add more info to README

Consider the stage this repository is in @xianwill , I recommend this come out of draft and we just go ahead and merge it. There's nothing that jumps out at me that must be addressed right now.


 That will allow to generate the HISTORY.md file and maybe use semantic-release to automatically publish to npm.
This commit messages convention is used in many projects. @rstacruz, are you OK with it?
Some projects the use this commit format:

https://github.com/ReactiveX/rxjs
https://github.com/cyclejs/cyclejs

Not my personal style (I always preferred writing changelogs manually), but I understand the need so I'm happy to go ahead with it.
Care to document how it works? Maybe in CONTRIBUTING.md?

yes, I'll add a CONTRIBUTING.md


Documentation forthcoming?

Any plans to beef up the documentation on this? Building/running?

We are actively working on the documentation which will be evolving over the next 3 months.

Great, I'm looking forward to it!