Add the STORE module take 2, for loaded certs, keys and more given a URI

Checklist

[x] documentation is added or updated
[x] tests are added or updated
[x] CLA is signed

Description of change
This is a redesign of #1962
This STORE module adds the following functionality:

A function STORE_open(), STORE_load() and STORE_close() that accesses
a URI and helps loading the supported objects (PKEYs, CERTs and CRLs
for the moment) from it.
An opaque type STORE_INFO that holds information on each loaded object.
A few functions to retrieve desired data from a STORE_INFO reference.
Functions to register and unregister loaders for different URI schemes.  This enables dynamic addition of loaders from applications or from engines.

Also includes a loader for the "file" scheme.  The goal is to have it load PEM files and raw DER files alike, transparently.
Fixes #1958, #1959

For the curious, I have a merge of the store2 branch (this PR) and the uri branch (#1961) being built here

This seems very much based on the concept that you can open a 'STORE', read it sequentially, and close it again. As such, it doesn't seem to apply to storage like PKCS#11. Is that something we care about?

This seems very much based on the concept that you can open a 'STORE', read it sequentially, and close it again. As such, it doesn't seem to apply to storage like PKCS#11. Is that something we care about?

For the file: scheme, you're entirely correct.  That's the only scheme that's built in, for obvious reasons.  However, the design is also to allow anyone to added their own loader for whatever sheme they see fit, and the only requirement is that this loader can simulate a sequential store of objects, given URI parameters.  The backend data doesn't have to be organised in any specific way as long as the loader can simulate sequential semantics.
I haven't looked too much into the pkcs11: scheme, but I have the impression that a URI usually refers to exactly one object, so it should be fairly simple to create a loader that supports that.

Note: this branch now uses commits from #1961 and from #2027.  If someone approves this one without looking at those, I'll consider it an approval of them as well.

I cleaned this up quite a bit, squashed what made sense to squash, and rebased on top of fresh master

I just did a huge rework of this PR.
Major new: public file scheme handlers are gone.  There are a few left for the different kinds of data, but no more separate handler for each key type.  This is instead handled through already existing OpenSSL functionality (most notably, EVP_PKEY_ASN1_METHODs).

Time to take this one out of WIP.  Comments appreciated!
Note: this PR only contains the base STORE functionality
No adaptations of other parts of OpenSSL are made here, that will appear in other PRs after this one comes through reviews.  (wishlist appreaciated)

FYI, I've some thoughts on extending the STORE with search attribute capabilities.  To be implemented in a separate PR when this one has been merged.  Such capabilities will strongly help to rewrite by_dir to use the STORE functionality.

Adapted to use the extended UR decoding recently added in #1961

I've made some changes after internal feedback from other members of the team.  No URI decomposition any more, the URI is just passed along to the scheme handler, to be dealt with by the handler.

I try to implement store2 functionality into one engine and I wonder why is responsible to define structure store_loader_st?
Could I assume that each STORE_LOADER is responsible to define own structure?

Could I assume that each STORE_LOADER is responsible to define own structure?

I think you're mixing things up.  The STORE_LOADER is an OpenSSL type to keep track of each loader, much like ENGINE is an OpenSSL type to keep track of engines.  Maybe you're thinking of STORE_LOADER_CTX?  That's a private structure that each loader is responsible for.  For the 'file:' loader, you can see the definition here
But anyhow, to add a new loader, you must create it with STORE_LOADER_new and manipulate its internals with the other STORE_LOADER_ functions, and finally register it with STORE_register_loader.  That's when OpenSSL can start using it.
Did this answer your question?  May I guess that you're working on e_nss?

@petrovr, your reviews come disconnected from the lines you're commenting on, making it impossible for me to know what you're talking about...

Richard Levitte wrote:

@petrovr, your reviews come disconnected from the lines you're commenting on, making it impossible for me to know what you're talking about...

I note the same too late. Sorry for confusion .

doc/man3/STORE_LOADER.pod
a) please add bank lines between function groups related to
STORE_LOADER_CTX - open, ctrl , load and etc
b) STORE_LOADER_free - free is void

doc/man1/storeutl.pod
typo in description section ...The B command => s/rsautl/storeutl/ ?

Richard Levitte wrote:

I think you're mixing things up.
Sorry, I mean store loader context : typedef struct store_loader_ctx_st
STORE_LOADER_CTX

But anyhow, to add a new loader[SNIP]...  For the 'file:' loader,[SNIP]
I note what is implemented in file loader.
I module is responsible to define structure above typedef will limits
scope - one source file , one store context.

It is fine with me because I plan to implement only one loader.
If some one would like in one source file to define more then one
loaders each with one context current declaration is blocking.

May I guess that you're working on e_nss?

yes

doc/man3/STORE_LOADER.pod
a) please add bank lines between function groups related to
STORE_LOADER_CTX - open, ctrl , load and etc

Do you mean something like this?
diff --git a/doc/man3/STORE_LOADER.pod b/doc/man3/STORE_LOADER.pod
index 2f12846e3f..e036a0bc4b 100644
--- a/doc/man3/STORE_LOADER.pod
+++ b/doc/man3/STORE_LOADER.pod
@@ -14,10 +14,13 @@ unregister STORE loaders for different URI schemes
  #include <openssl/store.h>

  typedef struct store_loader_st STORE_LOADER;
+
  STORE_LOADER *STORE_LOADER_new(void);
  int STORE_LOADER_set0_scheme(STORE_LOADER *store_loader, const char *scheme);
  /* struct store_loader_st is defined differently by each loader */
+
  typedef struct store_loader_ctx_st STORE_LOADER_CTX;
+
  typedef STORE_LOADER_CTX *(*STORE_open_fn)(const char *uri);
  int STORE_LOADER_set_open(STORE_LOADER *store_loader,
                            STORE_open_fn store_open_function);

b) STORE_LOADER_free - free is void

Good point, will fix.

doc/man1/storeutl.pod
typo in description section ...The B command => s/rsautl/storeutl/ ?

Oh!  Good point!  Will fix.

Richard Levitte wrote:

I think you're mixing things up.
Sorry, I mean store loader context : typedef struct store_loader_ctx_st STORE_LOADER_CTX

But anyhow, to add a new loader[SNIP]...  For the 'file:' loader,[SNIP]
I note what is implemented in file loader.
I module is responsible to define structure above typedef will limits scope - one source file , one store context.
It is fine with me because I plan to implement only one loader.
If some one would like in one source file to define more then one loaders each with one context current declaration is blocking.

Yup, you're right, that is a limitation.  I actually gave it some thought but couldn't figure out a way that would maintain some level of type safety.  I really don't want to just pass void *.
On the other hand, one loader per source file isn't a severe limitation, I think most can live with that.  If they really want to, nothing stops them from defining the structure like this:
struct store_loader_ctx_st {
    union {
        STORE_LOADER_CTX_1 ctx1;
        STORE_LOADER_CTX_2 ctx2;
        STORE_LOADER_CTX_3 ctx3;
    } _;
};

And make sure that each loader uses the correct sub-context.

Richard Levitte wrote:

doc/man3/STORE_LOADER.pod
a) please add bank lines between function groups related to
STORE_LOADER_CTX - open, ctrl , load and etc

Do you mean something like this?
diff --git a/doc/man3/STORE_LOADER.pod b/doc/man3/STORE_LOADER.pod
index 2f12846e3f..e036a0bc4b 100644
--- a/doc/man3/STORE_LOADER.pod
+++ b/doc/man3/STORE_LOADER.pod
@@ -14,10 +14,13 @@ unregister STORE loaders for different URI schemes
   #include <openssl/store.h>

   typedef struct store_loader_st STORE_LOADER;
+

ok

STORE_LOADER *STORE_LOADER_new(void);

blank here

int STORE_LOADER_set0_scheme(STORE_LOADER *store_loader, const char *scheme);

blank here

/* struct store_loader_st is defined differently by each loader */
+

no at this point.
struct store_loader_st(typo) actually is  store_loader_ctx_st(!)  and
comment is for next line

typedef struct store_loader_ctx_st STORE_LOADER_CTX;
+

ok

typedef STORE_LOADER_CTX *(*STORE_open_fn)(const char *uri);
int STORE_LOADER_set_open(STORE_LOADER *store_loader,
STORE_open_fn store_open_function);

exactly both lines are for open
[SNIP]

I did test implementation for testing purposes (only to list all certificates) -
https://gitlab.com/e_nss/e_nss/blob/store2/engines/e_nss_store.c
Test command openssl storeutl -engine e_nss --text 'nss:xx' / only scheme is , rest of uri is not used and command will list all certificates
I have some remarks amount openssl store2:

eof is called too early after open but before load . At this point function can return result only if data is not protected. Load is with UI method and could prompt for password(pin) unlike open function.

open vs load method
'open' is only with URI as argument and is difficult initialize external store(device). Initialization may require access to engine and UI method.
'load' is with context(allows access to engine) and UI method and it seems to me this is the only place to initialize external device on first call.
So far so good but documentation is opposite to function declarations.

May be open function with store loader and UI in addition to uri is compromise solution.
If open could initialize external device it may know that there is data and in such case call of eof between open and load make sense.

I have some remarks amount openssl store2:

eof is called too early after open but before load . At this point function can return result only if data is not protected. Load is with UI method and could prompt for password(pin) unlike open function.

The very simple answer is this change:
--- e_nss_store.c~	2017-03-12 21:18:50.316760863 +0100
+++ e_nss_store.c	2017-03-12 21:19:38.973236773 +0100
@@ -144,7 +144,7 @@

     /*TODO: swich URI cases*/

-    if (ctx->ndx == -2) return 0; /*TODO function is called too early !*/
+    if (ctx->ndx == -2) return 1; /* called early => eof not reached yet */

     if (ctx->certs == NULL) return 1;
     if (ctx->ndx >= sk_X509_num(ctx->certs)) return 1;

The idea is taken from feof(), which only returns a EOF indicator, which in some cases won't be set before fread() has reached EOF.  In other words, if you don't know you have reached EOF, then assume you haven't.
This does mean that the user may have to deal with STORE_INFO_UNSPECIFIED, which also indicates that EOF has been reached...  as a matter of fact, I've been wondering if I should just remove STORE_eof() entirely because of this, but haven't decided yet.
However...

open vs load method
'open' is only with URI as argument and is difficult initialize external store(device). Initialization may require access to engine and UI method.
'load' is with context(allows access to engine) and UI method and it seems to me this is the only place to initialize external device on first call.

What I hear is that the open method should also get the UI method and data, and yes, I think that's a good idea, precisely for the reason you mention, that a device may just need an initial authentication.  I will fix that (and I suppose that also gives you another way to deal with the EOF issue ;-) ).

So far so good but documentation is opposite to function declarations.

Hmm?  Not sure I understand.  However, I'm just noticing that I haven't documented how the STORE_LOADER method functions are supposed to work, at all (except a little in store.h).  That needs fixing too, thanks for having me think of it.

STORE_open_fn now takes a ui_method and a ui_data

I've also added documentation in doc/man3/STORE_LOADER.pod, I hope that it's understandable enough.

Richard Levitte wrote:

I have some remarks amount openssl store2:

eof is called too early after open but before load . At this point function can return result only if data is not protected. Load is with UI method and could prompt for password(pin) unlike open function.

The very simple answer is this change:
--- e_nss_store.c~	2017-03-12 21:18:50.316760863 +0100
+++ e_nss_store.c	2017-03-12 21:19:38.973236773 +0100
@@ -144,7 +144,7 @@

      /*TODO: swich URI cases*/

-    if (ctx->ndx == -2) return 0; /*TODO function is called too early !*/
+    if (ctx->ndx == -2) return 1; /* called early => eof not reached yet */

      if (ctx->certs == NULL) return 1;
      if (ctx->ndx >= sk_X509_num(ctx->certs)) return 1;

The idea is taken from feof(), which only returns a EOF indicator, which in some cases won't be set before fread() has reached EOF.  In other words, if you don't know you have reached EOF, then assume you haven't.

if eof() returns 1 before load next called method is close() .
engine "e_nss" set.
...TRACE_E_NSS nss_store_open(uri="nss:bongo"):  ...
...TRACE_E_NSS nss_store_open():  ctx=0x1b71200->name=":bongo"
...TRACE_E_NSS nss_store_eof(ctx=0x1b71200, ...):  ...
Total found: 0
...TRACE_E_NSS nss_store_close(ctx=0x1b71200):  ...
...TRACE_E_NSS nss_finish()
May be logic is inverted. Currently zero mean 'more data'
[SNIP]

May be logic is inverted. Currently zero mean 'more data'

argh, no...  it was my brain farting, never mind, zero is the correct return.

Richard Levitte wrote:

STORE_open_fn now takes a ui_method and a ui_data
10x
Now engine test implementation is updated with new more intuitive logic
for open, eof, load and close.

Engine supports one commands that list X.509 certificates:
LIST_CERTS: List certificates (1=User, 2=CA, 3=All)
(input flags): NUMERIC
For each certificate outputs certificate 'nickname' and information for
subject(distinguished name). In this context 'nickname' is like
identifier used to find certificate or key - "key id".
I update command to use store api and I have some design questions.
Store info support some types. Name type is one of them but model does
not allow name to be  used with other types in one STORE_INFO. I mean
that when load returns key or certificate value there is no way to
return URI of returned data in same instance.
I wonder why name is separate type?

I did next step to unregister store on engine destroy. Unfortunately e_nss regression test with sig/verify operation start to fail. Quick check (trace) show that crash is in STORE_unregister_loader.
Test without sign/verify operation pass but unregister function returns NULL.

I'm willing to take a closer look at e_nss for this.  What branch or commit should I go for?

I did next step to unregister store on engine destroy. Unfortunately e_nss regression test with sig/verify operation start to fail. Quick check (trace) show that crash is in STORE_unregister_loader.
Test without sign/verify operation pass but unregister function returns NULL.

I'm willing to take a closer look at e_nss for this.  What branch or commit should I go for?

Duh, never mind...  the store2 branch, of course ;-)

@petrovr:

Store info support some types. Name type is one of them but model does not allow name to be  used with other types in one STORE_INFO. I mean that when load returns key or certificate value there is no way to return URI of returned data in same instance.
I wonder why name is separate type?

It's to provide "directory listing" functionality that the caller can do what they wish with.  The "name" must be a new URI that can be used with STORE_open.
So basically, nss_store_load in e_nss_store.c isn't quite right, all those NSS_QUERY_LIST* should return a STORE_INFO_NAME type object with a URI that can be used to get each certificate.
Compare this to the file: scheme...  STORE_open("file:/foo/bar/", ...) will return a list of names, like this, for example "file://foo/bar/ca.pem" and "file:/foo/bar/user.pem", and then, the user or application can use whichever they choose of those to get the object (or objects, as the case may be) they want.
Does this clarify things for you?

The other possibility is that you were thinking that, for example, nss:list=ca would work a bit like a PEM file in the file: scheme, and simply return all objects in there.  That's absolutely fine, but in that case, nss:list=ca works like a container, and is the URI to get them, all in one go.  That's how the file: scheme treats PEM files and PKCS#12 files, for example.
This gives you a choice.  If you truly want to list a series of URIs that can be used to pick individual certificates, it will have to be a two step process.  If you'd rather want to just return the objects, you will have to accept that the listing URI is the way to get them.  Either way, the application already knows the URI to get them, there's no point returning the name together with the object.

I did next step to unregister store on engine destroy. Unfortunately e_nss regression test with sig/verify operation start to fail. Quick check (trace) show that crash is in STORE_unregister_loader.
Test without sign/verify operation pass but unregister function returns NULL.

I'm willing to take a closer look at e_nss for this.  What branch or commit should I go for?

I figured it out.  I'm calling destroy_loaders_int much too early.  Fixing it now

I also hacked e_nss_store.c to provide a list of nickname URIs when list URIs are used, and to parse that same nickname URI when given.

Hi,
Richard Levitte wrote:

This gives you a choice.  If you truly want to list a series of URIs that can be used to pick individual certificates, it will have to be a two step process.  If you'd rather want to just return the objects, you will have to accept that the listing URI is the way to get them.  Either way, the application already knows the URI to get them, there's no point returning the name together with the object.

Thinking more between different solutions finally I decided that simple
solution is enough.
From functional point of view proposed API is complete.

P.S.
May be store "open" method could be declared with "store loader" as
first argument :
typedef STORE_LOADER_CTX *(*STORE_open_fn)(
const STORE_LOADER *store_loader
const char *uri,
const UI_METHOD *ui_method,
void *ui_data);
, i.e. pseudo object oriented style.
Roumen Petrov wrote:

Hi,
Richard Levitte wrote:

This gives you a choice.  If you truly want to list a series of URIs
that can be used to pick individual certificates, it will have to be
a two step process. If you'd rather want to just return the objects,
you will have to accept that the listing URI is the way to get them.
Either way, the application already knows the URI to get them,
there's no point returning the name together with the object.

Thinking more between different solutions finally I decided that
simple solution is enough.
From functional point of view proposed API is complete.

P.S.
May be store "open" method could be declared with "store loader" as
first argument :
typedef STORE_LOADER_CTX *(*STORE_open_fn)(
const STORE_LOADER *store_loader
const char *uri,
const UI_METHOD *ui_method,
void *ui_data);
, i.e. pseudo object oriented style.

I don't think so.  It might be pseudo OO style, but it's not very much OpenSSL style.  Also, that would probably make things more confusing.

From functional point of view proposed API is complete.

Cool, glad you approve.
If you take a look at the STORE project, you can see that there are a few more PRs with additional functionality.

Ok, I've addressed all stuff I said I'd address.
Also, I've renamed STORE_LOADER_set0_scheme to STORE_LOADER_set_scheme, so we don't get tangled in the set0/set1 semantics, which the current implementation simply doesn't meet.
I'm also pondering if the scheme shouldn't rather be given through STORE_LOADER_new, considering how important it is that it's set...

Ok. I'll try and take another pass through tomorrow.

Second pass done. Aside from these items I think the main sticking points we need to resolve are 1) comment style 2) multi-thread issue 3) OPENSSL_assert 4) OPENSSL_init_crypto 5) OpenConnect licence issue.

Addressed most (all?) added comments.  5) now resolved.

Looking good; thanks. If I can find time I'll be doing two things::
• Work up a PKCS#11 module proof-of-concept to validate that we're not missing anything needed for that.
• Modify app(s) to use it. My success criterion here is that I can ditch the hundreds (thousands?) of lines of code I currently have for loading certs, and replace it with a single call to a function which will do the right thing.
Regarding the OpenConnect reference: I don't mind about attribution per se, but it might be useful to have some comment about the origin, just to help us remember to keep in sync when new forms are added. And you have inherited my TODO item of ensuring that you handle non-ASCII passwords correctly in the test suite. Try a password which is U+0102 U+017B  :)

Looking good; thanks. If I can find time I'll be doing two things::
• Work up a PKCS#11 module proof-of-concept to validate that we're not missing anything needed for that.
• Modify app(s) to use it. My success criterion here is that I can ditch the hundreds (thousands?) of lines of code I currently have for loading certs, and replace it with a single call to a function which will do the right thing.

Cool.  Although, it will take a little more than one line...  but not hundreds or thousands!  ;-)

Regarding the OpenConnect reference: I don't mind about attribution per se, but it might be useful to have some comment about the origin, just to help us remember to keep in sync when new forms are added.

"someone" could simply make a PR with an update of 90-test_store.t a little now and then ;-)

And you have inherited my TODO item of ensuring that you handle non-ASCII passwords correctly in the test suite. Try a password which is U+0102 U+017B  :)

That's a bit outside of the scope of this effort...  is there a clear concensus that all passwords should be what, take as is (with the risk of failure on machines with a different default encoding)?  Convert to utf-8 before use?  Convert to unicode (wchar_t) before use?  That's a subject for a whole different PR.

Second pass done. Aside from these items I think the main sticking points we need to resolve are 1) comment style 2) multi-thread issue ~3) OPENSSL_assert~ ~4) OPENSSL_init_crypto~ ~5) OpenConnect licence issue~.

all OPENSSL_assert have now been changed to assert
clarified

Second pass done. Aside from these items I think the main sticking points we need to resolve are 1) comment style ~2) multi-thread issue~ ~3) OPENSSL_assert~ ~4) OPENSSL_init_crypto~ ~5) OpenConnect licence issue~.

I've added thread safety around the loader registry bits.

Remains the comment style, which is pretty much unanswered on the team list...

Another issue I thought of. Are we at liberty to claim the STORE_* namespace? It seems quite likely that we could get symbol clashes with some other application somewhere. Should it be OSSL_STORE_* or similar?

I would rather not rename the namespace, but it's a good question. I've tried more than once to do a sweep over SDK docs I could find to see if I could find a clash somewhere, but have found none to date.
Ask on openssl-dev?

It sounds like something we should have a general policy on. I'd raise it with the team and/or openssl-dev.

Not if the new name is an opaque pointer.

So @levitte you don't like the "base type" idea because there is nothing common in base?  I suggest at least putting an int for a "type identifier".  Then you can check it in the per-file modules if you want.  It's more future-proof (imagine a future vresion that has locking in a common place).  Please think about it, over your weekend :)

Why should any loader share anything with another loader, dictated by the core? The core has its own context anyway, if there would be a common lock, that's where I would put it.

shrug.  ok.

@richsalz, what I hear from you is that the STORE loaders should receive a STORE_CTX pointer, i.e. that the core context structure should be passed around everywhere, a bit like a EVP_CIPHER_CTX pointer is passed down to the individual symmetric algo implementations and those get to extract their algo-specific data pointer from that common structure...
I do understand why the passing around of a common EVP_CIPHER_CTX pointer came to be, but for the STORE, I want a stronger separation between the core library and the loaders, clear line in the sand kind of thing.  I won't change my mind on that one.

@levitte, about the CTX pointer, I'm fine.  I made a point, you considered it and disagree, it's okay with me.

If you're adding a store API which takes passwords for the objects being retrieved then please don't say that the charset encoding is the subject of a further PR. It is a fundamental part of this new API, surely? Get it right in the first place before anyone makes assumptions around current behaviour; don't make it an afterthought.
Imagine reviewing a PR with an API which takes a void * string but neglects to specify if it's char or wchar_t, or even whether it's NUL-terminated or Pascal-style {Len,Chars[]}.
That expression on your face... and that "Hell No!"you type in the review... that's what I want to see for any suggestion of  password API which doesn't specify the charset expectations. Don't do it;

If you're adding a store API which takes passwords for the objects being retrieved then please don't say that the charset encoding is the subject of a further PR. It is a fundamental part of this new API, surely? Get it right in the first place before anyone makes assumptions around current behaviour; don't make it an afterthought.

No, it's not a fundamental part of this API.  This API is merely a user of whatever PBE APIs there are in other parts of OpenSSL (more specifically, it uses PKCS12_verify_mac and PKCS12_pbe_crypt).

Imagine reviewing a PR with an API which takes a void * string but neglects to specify if it's char or wchar_t, or even whether it's NUL-terminated or Pascal-style {Len,Chars[]}.

Our UI library (which is what STORE uses to get passwords) deals with NUL-terminated char arrays, that should clarify your question.  This means that we really only need to deal with the encoding (i.e. is this string UTF-8 or ISO-LATIN-{x}?).

That expression on your face... and that "Hell No!"you type in the review... that's what I want to see for any suggestion of  password API which doesn't specify the charset expectations. Don't do it;

I agree it should be dealt with, but not as part of this PR.

@dwmw2, the best way to make sure the password encoding issue doesnt get lost is to create an issue.  Please feel free to do so.

Comments reformatted to better fit our style guide
DECODED renamed to EMBEDDED
Copyright years corrected or amended as needed
store_local.h renamed to store_locl.h

That should address almost everything to date, no?

The question of STORE_INFO_new_ENDOFDATA vs a ferror like function.

No, it's not a fundamental part of this API. This API is merely a user of whatever PBE APIs there are in other parts of OpenSSL (more specifically, it uses PKCS12_verify_mac and PKCS12_pbe_crypt).

In this context, that isn't a valid observation. The STORE API needs its documentation to stand alone and describe how to use it. Its use of other functions internally is purely an implementation detail.

Our UI library (which is what STORE uses to get passwords) deals with NUL-terminated char arrays, that should clarify your question. This means that we really only need to deal with the encoding (i.e. is this string UTF-8 or ISO-LATIN-{x}?).

What I'm saying is that a failure to clearly define the encoding is AS BAD AS not knowing if it's NUL-terminated chars or something else. For the new STORE API, please at least document precisely what is expected to be passed in.
And if you can't clearly specify it, with http://david.woodhou.se/draft-woodhouse-cert-best-practice.html in mind, then it's not really appropriate to pass the buck and say "but the PKCS12_* functions are broken already and it's not my fault". By simply using those and further entrenching their problems in new APIs, you are making the situation worse. Please don't do that.
We have an opportunity here to introduce a new API which applications can use to Do The Right Thing, without the hundreds of lines of code that I mentioned. Please please please let's not infest it with legacy behaviour and portability issues right from the start.

@dwmw2, could we at least investigate our PBEs and what needs to be done with them?
Also, it sounds like you're asking me to reimplement our PBEs as part of this PR, and perhaps even make them part of the file scheme loader.  That will not happen.
As for "The STORE API needs its documentation to stand alone and describe how to use it"...  The STORE API uses UI_METHOD for password prompting....  are you saying that the UI_METHOD docs should be duplicated into the STORE docs?
In essence, the STORE API and library aren't standalone, they aren't designed that way.

Upon more carefull thought, the issue is even less part of the STORE API than I expressed.  With regards to passphrases / passwords, the STORE API itself does nothing, by design.  All it does is pass around a UI_METHOD, that the loaders can use as they please, and they can treat the result from the UI calls as they please as well.
So it would seem to me that your issue with passwords here belongs with the file scheme loader that's implemented as part of this PR.
Maybe this separation of stuff makes things clearer for you?

You don't need to duplicate the UI_METHOD docs. It's OK to refer to them, of course.
But if the UI_METHOD docs don't specify the character set, then you transitively inherit that same problem in your own code. And sure, you can pass the buck already and say "the old code was broken". But now you've added new APIs which are similarly broken, which is less OK.
And you have potentially made it worse, if we end up in a situation where one back end expects one thing (the locale charset) while others expect another (a PKCS#11 store probably really does require UTF-8 since that's specifiied by PKCS#11). So users of your new API now have to make guesses based on internal details and pass something different according to their guess.
The reason I'm pushing for this now, as a precursor to this landing, is because if we merge it with that kind of ambiguity then we end up with the API problem for ever. The API should be stable before it lands.

Ah, I thought I had already added references to the the UI / UI_METHOD docs. Apparently not. Will fix.

Still not good enough if the UI_METHOD docs don't specify charset handling, and if your overall resulting behaviour isn't correct given what is said about it.

As for the rest of what you say, @dwmw2, I repeat, let's fix the code where it's actually broken.

Sure, but typically one tries to fix such brokenness before propagating it and producing new ambiguous APIs. But as long as it gets done before an actual release with the STORE API, I suppose that's fine. We still shouldn't end up in a situation where applications have to jump through hoops to do different things for different back ends or different versions of OpenSSL.

Based on the team discussion I consider (2) resolved (my objection about requiring different translation units can be fairly easily worked around). (4) is also resolved - OPENSSL_init_crypto() is required to ensure the atexit handlers get invoked properly.

So, remaining issues:

STORE_ vs OSSL_STORE_ prefix (not yet concluded as far as I can see)
app name (store or storeutl)
ENDOFDATA vs ferror like interface.

I'm currently working on 3.  1 is waiting on team decision (I want it to become policy if we decide for OSSL_STORE_)...  and quite frankly, 2 seems like a small thing, I would prefer "storeutl".

@dwmw2, regarding the passphrase issue, I'll have to insist on raising a separate issue for it, not in this PR.  I'm pondering the whats and what nots right now.
Regarding what's done first or after, what about in parallell?

I think @dwm2 makes a strong point.  If the current UI is broken for non-ascii passwords, then adding a new API on top of that also seems broken.

You know, I figured that yes, some work needs to be done in the file scheme loader with regards to passwords.  I suddenly remembered that the encoding issue was dealt with in the pkcs12 app, where a given pass phrase will be tried as is first when loading a file, and failing that, a pass phrases that's been converted from whatever encoding it's in to utf8 will be attempted instead.  The same kind of operation should be attempted in the file scheme loader.
Why it should be done this way?  Because there are existing keys that have been encrypted with iso-8859-* encoded pass phrases, and of course, there are also keys encrypted with utf8 encoded pass phrases.
In a similar vein, we cannot assume to know exactly what encoding each loader wants.  That will be up to loader specific decisions and implementations.  So for example, I would assume that a loader for PKCS#11 would make sure to convert the pass phrase it gets from UI calls to utf8.  That should be a matter of what, one library call?  Either OPENSSL_asc2utf8 or something similar from a more potent character conversion library.
UI, btw, will give you straight (or as straight as possible) what it was fed, with the current local encoding.  It delivers NUL-terminated char *, and that's it.

STORE_ vs OSSL_STORE_ prefix (not yet concluded as far as I can see)

I think doing a policy will be very difficult.  The consensus seems to be that STORE is a generic name, and we shouldn't claim it.  Can we just do with that one change?  What's the policy, if not.  "Don't use common names, otherwise prefix with OSSL"  Our exported symbols have 73 items that start with openssl, and none that start with ossl:
; grep -i '^openssl' *num | wc
73     292    6010
; grep -i ossl *num
exit 1
;
I agree OPENSSL_STORE is big and ugly, but it is the convention we already have OPENSSL_LHASH _sk, _thread, etc.

app name (store or storeutl)

This is not a hill worth fighting over.  Pick whatever name you want.

ENDOFDATA vs ferror like interface.

If it can look like BIO or FILE* with feof indicators, awesome.  If not, so be it.

app name (store or storeutl)

This is not a hill worth fighting over.  Pick whatever name you want.

I prefer "store" (in my mind the utl bit doesn't add anything). But its just a preference so I will accept whatever you decide.
BTW, I am now struggling to load this PR in my browser. Github keeps throwing up a page saying it is taking too long to load.

@richsalz wrote thusly:

STORE_ vs OSSL_STORE_ prefix (not yet concluded as far as I can see)

I think doing a policy will be very difficult.  The consensus seems to be that STORE is a generic name, and we shouldn't claim it.

X509 is also pretty generic (and we already have one clash).  RSA as well.  I could go on...

Can we just do with that one change?  What's the policy, if not.  "Don't use common names, otherwise prefix with OSSL"  Our exported symbols have 73 items that start with openssl, and none that start with ossl:
; grep -i '^openssl' *num | wc
73     292    6010
; grep -i ossl *num
exit 1
;
I agree OPENSSL_STORE is big and ugly, but it is the convention we already have OPENSSL_LHASH _sk, _thread, etc.

Hmmm, hadn't thought of the OPENSSL_LHASH_ case...  ok then.

app name (store or storeutl)

This is not a hill worth fighting over.  Pick whatever name you want.

ENDOFDATA vs ferror like interface.

If it can look like BIO or FILE* with feof indicators, awesome.  If not, so be it.

Well, we do have the end-of-file indicator already, but not the error indicator.

BTW, I am now struggling to load this PR in my browser. Github keeps throwing up a page saying it is taking too long to load.

Yup, I have the same issue.  As far as I can tell, it's load related (on github's side)

X509 is also pretty generic (and we already have one clash). RSA as well. I could go on...

And most, if not all, of these come from the SSLeay days. :)  Things are different now, and we want to avoid naming conflicts if we can.

In a similar vein, we cannot assume to know exactly what encoding each loader wants. That will be up to loader specific decisions and implementations. So for example, I would assume that a loader for PKCS#11 would make sure to convert the pass phrase it gets from UI calls to utf8. That should be a matter of what, one library call? Either OPENSSL_asc2utf8 or something similar from a more potent character conversion library.

I would probably try to reframe @dwmw2's position as "you should document exactly what format the input to the new APIs should be in, including charset/encoding/etc." (Unicode normalization form?)  Ideally this would be a nice clean and consistent interface that is easy to describe, though the initial implementation might be accompanied by warnings of buggy behavior in some cases that does not match up with the clean API spec.  A more "messy" API that has the encoding depend on which backend is in use might be possible to document accurately as well; I didn't look very hard.  But consumers of the new functions should be able to have a very specific understanding and expectation for their behavior.  If the encoding really is solely up to the UI_METHOD and that's all that STORE is passing around, then maybe we need to add some NIDs for various encodings and a way to query the UI_METHOD what is needed.
But to reiterate, I agree with @dwmw that character encoding is a giant minefield, and I think the best way we can help our consumers avoid issues is to clearly document how to correctly use our code; secondarily is to make correct usage simpler and more consistent.

Please move the pass phrase encoding discussion to #3531.  I will refuse to answer these questions further here.

Please move the pass phrase encoding discussion to #3531.

Thank you for filing that.

I will refuse to answer these questions further here.

... except where they are directly related, I hope. Specifically:
• Please explicitly document the expectation implied by #3531, that the UI_METHOD passed in to STORE_open() is expected to provide strings in the locale charset, except where OPENSSL_WIN32_UTF8 is defined.

Can I suggest closing this PR and reopening it with a different PR number? Github just cannot cope with loading this page now - I guess because there have been so many comments. Most times I get an error page :-(

Closing this PR, please redirect your attention to #3542


Fix problems with empty annotation intersection

This commit changes several things:

Make sure pipeline terminates in an ordered way if no circRNAs are detected
Rework the last few steps of the BSJ detection
Rework the structure of the output directory
Update the documentation

I ran 4 samples (2 samples with circRNA detection and 2 without detection).
Previous results:
HC01: 2 circles
HC02: 1 circle
HC04: 0 circles
RR05: 0 circles
New results:
HC01: 3 circles
HC02: 2 circles
HC04: 1 circle
RR05: 0 circles
Additionally, I encountered the following error:
ERROR ~ Error executing process > 'NFCORE_CIRCRNA:CIRCRNA:CIRCRNA_DISCOVERY:ANNOTATION:ANNOTATE (RR05:circrna_finder)'

Caused by:
  Process `NFCORE_CIRCRNA:CIRCRNA:CIRCRNA_DISCOVERY:ANNOTATION:ANNOTATE (RR05:circrna_finder)` terminated with an error exit status (1)

I have attached the output file (slurm-505469.txt) which details the error (the specified working folder has the RR05.intersect.bed file empty).

@mashehu you really see everything, very impressive


Fabric + Optifine Crashes the game

Describe the Bug
Whenever I use the fabric version of the mod and use optifine with bygone nether upon trying to start up the game minecraft just crashes and gives me Error code: 1, which means no crash report. I tried optifine and fabric with the "it takes a pillage mod" and it works perfectly fine the only thing that I think that might be breaking is probably one of the mod's mob's.
Reproduction Steps
1.Install fabric
2.Instal fabric API
3.Instal the fabric version of bygone nether
4.Install Optifine and Optifabric
5.Try booting up Minecraft
Expected Result
Game crashes giving you Exit code: 1
Screenshots and Videos
No response
Crash Report or Log
No response
Operating System
Windows 10
Mod Version
1.2.1
Minecraft Version
1.19.2
Forge Version
Fabric - 0.14.21
Other Mods
No response
Additional Context
No response

The possibility exists it might be an issue on Optifabric's end, since it's not officially supported by Optifine's developers. There might be no crash report, but if you open the debug log (it's a box you can check in the launcher settings) does it say anything at the end? It might also help to install a debugging mod like https://www.curseforge.com/minecraft/mc-mods/not-enough-crashes

Fixed in eb5881b. It was an incompatibility with one of MidnightLib's mixins


Tree layout of checkbox

I suggest to implement new kind of input form.
In order to display items in tree instead list.
What is the expected result?
$form->field($model, 'activities')->checkboxTree($rootActivities, 'childActivities');

What do you get instead?
I need to implement very complex methods in view to achieve the tree layout.
Additional info

Q
A

Yii version
2.0.12

PHP version
5.6.31

Operating system
Win 10

My current script to make a checkbox tree:
<?php
function build_node($model, $attribute, $parentItem){
	$items = $parentItem->getItems()->indexBy('id')->all();
	if (count($items) > 0) {
		return '
' . Html::activeCheckboxList($model, $attribute, $parentItem->getItems()->indexBy('id')->all(), [
			'item' => function ($index, $label, $name, $checked, $value) use ($model, $attribute, $parentItem) {
				return '
' . Html::checkbox($name, $checked, [
					'value' => $value,
					'label' => $label->name,
				]) . '
' . build_node($model, $attribute, $label);
			},
		]) . '
';
	}
	return '';
}
?>

<?= $form->field($model, 'activities')->checkboxList($rootActivities, [
	'item' => function ($index, $label, $name, $checked, $value) use ($model) {
		return Html::checkbox($name, $checked, [
			'value' => $value,
			'label' => $label->name,
		]) . build_node($model, 'activities', $label);
	},
]); ?>

I also need a submit button that looks like a pony. Then user click on it and form is valid, pony says "и-го-го". You know what I mean?
Yii privides ActiveField::widget() and InputWidget for such situations. You can place all the logic inside the widget.
Also you can use third-party solutions. http://demos.krajee.com/tree-manager-demo/tree-view-input

this is out of scope for Yii core and should be solved in an extension.

I don't want uber crazy tree view manager, only simple style that shows checkboxlist as checkboxtree. It should be easy for Yii to have such features. I do not want to implement it and care about internal stuff in Yii. Code that I write is in 70% copy from Yii library.

@mklemarczyk, Yii should not care about third-party ui elements. This is not a standard form element. Not even the standard bootstrap component.

@ptz-nerf Oh, now I see.


PP-9534 Project agreements/ payment instruments

Depends on https://github.com/alphagov/pay-ledger/pull/1861 (in order to extend AgreementService)

Add entity factory to reduce event streams to AgreementEntity and
PaymentInstrumentEntity.
Use the standard ledger reduce -> object mapper for standard fields.
Specifically extract top level event digest fields to set:

resource id
created date
service id
live
event count

Hook agreement and payment instrument event stream processing into the
EventDigestHandler.
This will allow events consumed from SQS or passed to the event endpoint
to be processed with resource type AGREEMENT and PAYMENT_INSTRUMENT.
Update tests to accomidate now supporting agreements, cover individual
entity mapping and end to end (integration) consuming and projecting
events.

@alexbishop1 totally agreed with comments, could come later but have followed up now to make sure they get in https://github.com/alphagov/pay-ledger/pull/1864/commits/bf09669b1f4542f30024e982c736a9b4da939b74


SQS: message send param validation

Closes https://github.com/getmoto/moto/issues/7398

@bblommers the tests are now taking ~15mins, is this version 5 improvements?? I'm pretty sure they used to take 3 times as much 👏 👏 👏
On the PR - could you rerun the failing tests? 3.8 defo looks like CI issue, perhaps 3.12 is too

Hi @rafcio19! Yes, those are all v5 improvements. Now that we have the new config-attribute the IAM managed policies are no longer loaded by default, and it's now also possible to configure the boto3 session to not reset. Those two made all the difference in performance, so I'm quite happy with that!
About the PR: AWS does allow you to configure a fifo-queue with the DelaySeconds-attribute - but I think the current implementation would error when sending a message against a fifo-queue with that attribute.
Would be good to add a test to Moto with that specific configuration, to ensure it works:
sqs.create_queue(QueueName="test3.fifo", Attributes={"FifoQueue": "true", "DelaySeconds": "10"})
sqs.send_message(
    QueueUrl="test3.fifo",
    MessageBody="test",
    DelaySeconds=0,
    MessageGroupId="test",
    MessageDeduplicationId=str(uuid4()),
)
# message can be received as usual...


Update README.md

A preview environment was automatically created via Qovery.
Click on the link below to follow its deployment and use it.
:point_right: [PR] prev-env - Update README.md - 2023-02-10T14:01:27Z
Another comment will be posted when deployments are terminated

Your preview environment has been successfully deployed !
Click on the link below to open your service:
:point_right: app1
:point_right: app2


Create offer

User  can  create offer even the balance is zero.
It should not place an offer if user have no enough balance.


Add option to have outline open in fully collapsed mode

Is your feature request related to a problem? Please describe.
When I use the LspSaga outline feature, I commonly want all collapsible objects to be collapsed to get a high level overview of the current file.
I have tried setting detail=false in my lspsaga setup which does not seem to do this action and I don't see any other available option in the documentation (https://nvimdev.github.io/lspsaga/outline/) that looks applicable.
Describe the solution you'd like
I would like to see an option to open the outline with every collapsable object in the collapsed state by default. It could for example look like
require('lspsaga').setup({
	-- The default value of collapsed could be false to align with current behaviour
	outline = { collapsed = true }
})

Describe alternatives you've considered
An alternative solution could be the already requested feature (https://github.com/nvimdev/lspsaga.nvim/issues/1435) where one has to press the "collapse all" button when using the outline.
Another possible solution would be to add a keybind which lets you jump to the next collapsible object in the list so that one can jump between high level objects in an easy way. This keybind would be useful for getting a slightly better high level overview of the file, but I belive it to be less useful for the problem at hand.
Additional context
To me, it sounds similar in scope to the already mentioned feature  request of being able to collapse all items in the outline (https://github.com/nvimdev/lspsaga.nvim/issues/1435) so the two features could probably be implemented in tandem.

this would be a great addition! i would love to have this


incubator/azuremonitor-containers - (set image repo corresponding cloud and doc updates)

Is this a new chart

NOTE: We're experiencing a high volume of PRs to this repo and reviews will be delayed. Please host your own chart repository and submit your repository to the Helm Hub instead of this repo to make them discoverable to the community. Here is how to submit new chart repositories to the Helm Hub.

What this PR does / why we need it:
This PR has following changes

set the image repository based on the cloud domain
doc updates for other azure clouds

Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

@lachie83, can you please help on reviewing this PR?

Hi, @jlegrone , can you please help on reviewing this PR?

@lachie83 , @jlegrone, Appreciate if you guys can help on reviewing this PR asap.

Hi, @lachie83 , @jlegrone , We would like to get this PR merged soon. Appreciate if  one of you can help on reviewing  and merging this PR.

/ok-to-test

Hi, @lachie83 , @jlegrone, @zanhsieh , We would like to get this PR merged soon. Appreciate if one of you can help on reviewing and merging this PR.

@ganga1980
Have ping-ed @lachie83 . Hope he would see this.

/lgtm


Add --simple-binary

#17
# Run a simple program
$ ./ckb-debugger --simple-binary /src/ckb-vm-pprof/res/abc
Run result: 0
Total cycles consumed: 1459

# Run a simple program and profile it
$ ./ckb-debugger --simple-binary /src/ckb-vm-pprof/res/abc --pprof /tmp/flamegraph.txt
$ cat /tmp/flamegraph.txt | inferno-flamegraph > /tmp/flamegraph.svg

# Run a simple error program
$ ./ckb-debugger --simple-binary /src/ckb-vm-pprof/res/outofmemory
Backtrace:
??:??
/code/outofmemory.c:main
/code/outofmemory.c:c
/code/outofmemory.c:b
/code/outofmemory.c:a
/code/outofmemory.c:5
Machine returned error code: OutOfBound

The format of backtrace is strange
/code/outofmemory.c:main
/code/outofmemory.c:c
/code/outofmemory.c:b
/code/outofmemory.c:a
/code/outofmemory.c:5
Machine returned error code: OutOfBound

It should contain file, line number and symbol for every single entry.

The output format is done by ckb-vm-pprof, maybe we can merge the PR first, and then modify ckb-vm-pprof


Requesting a function to obtain the current viewport bounds

It would be nice to have a way to obtain the 2d overlay bounds, so that UI can be scaled to the player's screen.
glasses.getOverlayBounds(user:string): number, number
Returns the maximal x and y coordinates for the given player.
This probably requires a client round-trip to actually query since the current screen size affects these values.

isn't the resolution static and content is scaled anyways?
512 x 288 if i figured that out correct

I was getting different values when I resized my game window and tested again.
I tested by writing a quick event dump to capture mouse events, then clicking in the lower-right corner.

are you using some version <1.10.2?

I am not: OpenGlasses-MC1.12.1-1.5.4.jar

please take a look on this bug, that might help you to actually convert the position the event triggers to the internal resolution of openglasses. but note that this actually is a workaround and could change in future releases: https://github.com/StarChasers/OCGlasses/issues/36

If that's the solution, then aside from needing the bounds (constants would be fine if the coords are to be fixed), that bug definitely needs a squash, because the mouse events for the overlay definitely vary with the screen size.

@marcin212 i would suggest to expose the internal resolution of 512/288 to the lua backend.
i would put it on my todo list if you agree with that.

new event:
https://img.bymarcin.com/2017-09-20_11-55-56_jr0Yls0CXbMBlHgx.png

Much appreciated!  I'll give that a poke next release :)


arrow-cpp: 1.0.0 -> 1.0.1

Motivation for this change
A bugfix release: https://github.com/apache/arrow/blob/apache-arrow-1.0.1/CHANGELOG.md
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build arrow-cpp
@GrahamcOfBorg build python37Packages.pyarrow
@GrahamcOfBorg build python38Packages.pyarrow


Not able to access pre trained models and captions

Hi,
Thanks a lot for providing detailed codes and explanations. However, I am not able to access 'https://people.eecs.berkeley.edu/~lisa_anne/snowboard_misc/final_weights_eccv2018.zip' as it asks for username and password. Is it not meant to accessed by everyone?

Check out the updated README by the author. A new link is mentioned there.
Copying it here for easy reference:
https://drive.google.com/drive/u/1/folders/1i1wE01EH-x7OAun0ITI_Dvr47cGjHLC9


Single item contains

Makes contains matcher generic so that we could use it for both: vecs and single items, e.g.
conains(vec![1, 2])
contains(1)

See: https://github.com/Valloric/hamcrest2-rust/issues/3

This change is

This has now been released as part of 0.2.4. Thanks again!


'Included in' and intersect with null results "Could not resolve expression"

null included in Interval[1, 10]
Interval[1, 10] intersect Interval[5, null)

These issue is resoled

Is this a bug report? Any more details here?


Support T-Few (model and window service)

Requires finetuning

Closing for now.  Will support via fine-tuning APIs.


The file on disk has changed

When i open ~/.config/micro/settings.json I always see prompt The file on disk has changed.
My /etc/fstab:
# /dev/mapper/cryptroot LABEL=arch
UUID=02790d6b-b3ed-442b-865b-8161eddfd539       /home   btrfs   rw,noatime,ssd,commit=600,discard=async,space_cache=v2,subvolid=261,subvol=/@home      0 0

Does micro require atime/realtime instead noatime??????????????????
❯ micro --version
Found existing alias for "micro". You should use: "nano"
Version: 2.0.11
Commit hash: 225927b9
Compiled on August 09, 2022

Same problem with realtime.
❯ findmnt /home
TARGET SOURCE                        FSTYPE OPTIONS
/home  /dev/mapper/cryptroot[/@home] btrfs  rw,relatime,ssd,discard=async,space_cache=v2,commit=600,sub

~
❯ stat ~/.config/micro/settings.json
  File: /home/sergey/.config/micro/settings.json
  Size: 331             Blocks: 8          IO Block: 4096   regular file
Device: 0,40    Inode: 7800329     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  sergey)   Gid: ( 1000/  sergey)
Access: 2022-08-21 21:51:23.978554911 +0300
Modify: 2022-08-21 21:51:27.441836219 +0300
Change: 2022-08-21 21:51:27.441836219 +0300
 Birth: 2022-08-21 21:20:29.664083643 +0300

~
❯ cat ~/.config/micro/settings.json
{
    "colorcolumn": 80,
    "ft:go": {
        "tabstospaces": false
    },
    "ft:python": {
        "colorcolumn": 78,
        "tabsize": 4
    },
    "ftoptions": false,
    "lsp.server": "python=pylsp,go=gopls,typescript=deno lsp",
    "rmtrailingws": true,
    "softwrap": true,
    "tabsize": 2,
    "tabstospaces": true
}

~
❯ stat ~/.config/micro/settings.json
  File: /home/sergey/.config/micro/settings.json
  Size: 331             Blocks: 8          IO Block: 4096   regular file
Device: 0,40    Inode: 7800329     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  sergey)   Gid: ( 1000/  sergey)
Access: 2022-08-21 21:53:27.619185690 +0300
Modify: 2022-08-21 21:51:27.441836219 +0300
Change: 2022-08-21 21:51:27.441836219 +0300
 Birth: 2022-08-21 21:20:29.664083643 +0300

~
❯ micro ~/.config/micro/settings.json
Found existing alias for "micro". You should use: "nano"

Fixed by #3009


Lack of variables in some contexts breaks unit tests in class varnish::params

Class varnish::params defines variables $systemd_conf_path and $systemd_ncsa_conf_path, but not in all contexts. These variables are inherited, respectively, from classes varnish::serviceand varnish::ncsa. In the contexts they are not defined, unit tests fail complaining of undefined variables.

Created PR 156


plugins not loading

[x] Your Hyper.app version is 2.0.0. Please verify your using the latest Hyper.app version
[x] I have searched the issues of this repo and believe that this is not a duplicate

Any relevant information from devtools? (CMD+ALT+I on macOS, CTRL+SHIFT+I elsewhere):

Is the issue reproducible in vanilla Hyper.app?
don't know how to check

Issue

plugins are not showing so i checked my package.json and saw that none of my plugins are there so i npm installed it manually and it still doesn't load them up. tried reinstalling like 3 times

Hyper version: undefined "2.0.0"

OS ARCH VERSION: win32 x64 10.0.17134

Electron: 1.8.4  LANG: undefined

SHELL: undefined   TERM: undefined

 ~/.hyper.js contents

          {
  "updateChannel": "stable",
  "fontSize": 12,
  "fontFamily": "Menlo, \"DejaVu Sans Mono\", Consolas, \"Lucida Console\", monospace",
  "fontWeight": "normal",
  "fontWeightBold": "bold",
  "cursorColor": "rgba(248,28,229,0.8)",
  "cursorAccentColor": "#000",
  "cursorShape": "BLOCK",
  "cursorBlink": false,
  "foregroundColor": "#fff",
  "backgroundColor": "#000",
  "selectionColor": "rgba(248,28,229,0.3)",
  "borderColor": "#333",
  "css": "",
  "termCSS": "",
  "showHamburgerMenu": "",
  "showWindowControls": "",
  "padding": "12px 14px",
  "colors": {
    "black": "#000000",
    "red": "#C51E14",
    "green": "#1DC121",
    "yellow": "#C7C329",
    "blue": "#0A2FC4",
    "magenta": "#C839C5",
    "cyan": "#20C5C6",
    "white": "#C7C7C7",
    "lightBlack": "#686868",
    "lightRed": "#FD6F6B",
    "lightGreen": "#67F86F",
    "lightYellow": "#FFFA72",
    "lightBlue": "#6A76FB",
    "lightMagenta": "#FD7CFC",
    "lightCyan": "#68FDFE",
    "lightWhite": "#FFFFFF"
  },
  "shell": "",
  "shellArgs": [],
  "env": {},
  "bell": "SOUND",
  "copyOnSelect": false,
  "defaultSSHApp": true
}
      {

"plugins": [
"hyperborder",
"hyperterm-terminal",
"hypercwd",
"hyperterm-tab-icons",
"hyper-blink",
"hyperterm-cursor",
"hyperpower",
"hyper-alt-click"
],
"localPlugins": []
}

Did you found out why? My plugin is not loading too.

No, I just stopped using hyper

Plugins stopped working for me.

Plugins stopped working for me.

@MoonCh0w I got it work by fork a currently working plugin and refactor based on it.


Increase code cov

Codecov Report

Merging #1861 into tendermint will decrease coverage by 3.38%.
The diff coverage is 50%.

@@              Coverage Diff               @@
##           tendermint    #1861      +/-   ##
==============================================
- Coverage       34.82%   31.44%   -3.39%
==============================================
  Files              68       68
  Lines            3334     3155     -179
==============================================
- Hits             1161      992     -169
+ Misses           2173     2163      -10


CR-6132-uninstall-force-flag

Codecov Report

Merging #125 (b271845) into main (86af48b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #125   +/-   ##
=======================================
  Coverage   25.13%   25.13%
=======================================
  Files           1        1
  Lines         187      187
=======================================
  Hits           47       47
  Misses        134      134
  Partials        6        6

Continue to review full report at Codecov.

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


🦺[Tech debt] Add develop & GS keys file 43

Overview
This work allows other iOS developers to compile the project without the private prod files.

cc: @JCHeist

@kcw-grunt After following the readme I got past all my pod issues but I am having issues with signing and accessing the LitewalletPartnerAPI.
Signing
I am using my personal development team. Should I be using a different one, or use other settings in the loafWallet "Signing & Capabilities?"

"Personal development teams, including "Jasper Heist", do not support the Push Notifications capability."
"No profiles for 'com.litecoin.loafwallet' were found
Xcode couldn't find any iOS App Development provisioning profiles matching 'com.litecoin.loafwallet'."

LiteWalletPartnerAPI

"https://github.com/litecoin-foundation/LitewalletPartnerAPI.git: The remote repository could not be accessed. Make sure a valid repository exists at the specified location and that the correct credentials have been supplied."

@kcw-grunt  Cool, no problem. Ill await that, meanwhile I took a look at that other PR. For whatever help I can be while I don't have it running.

@kcw-grunt After following the readme I got past all my pod issues but I am having issues with signing and accessing the LitewalletPartnerAPI.
Signing
I am using my personal development team. Should I be using a different one, or use other settings in the loafWallet "Signing & Capabilities?"

"Personal development teams, including "Jasper Heist", do not support the Push Notifications capability."
"No profiles for 'com.litecoin.loafwallet' were found
Xcode couldn't find any iOS App Development provisioning profiles matching 'com.litecoin.loafwallet'."

LiteWalletPartnerAPI

"https://github.com/litecoin-foundation/LitewalletPartnerAPI.git: The remote repository could not be accessed. Make sure a valid repository exists at the specified location and that the correct credentials have been supplied."

Thanks @JasperHeist this is the proper path and I need to submit another PR for you. The one I just submitted should be a starting point. But this is good progress. The fault is mine. Thanks for your patience.

@kcw-grunt After following the readme I got past all my pod issues but I am having issues with signing and accessing the LitewalletPartnerAPI.
Signing
I am using my personal development team. Should I be using a different one, or use other settings in the loafWallet "Signing & Capabilities?"

"Personal development teams, including "Jasper Heist", do not support the Push Notifications capability."
"No profiles for 'com.litecoin.loafwallet' were found
Xcode couldn't find any iOS App Development provisioning profiles matching 'com.litecoin.loafwallet'."

LiteWalletPartnerAPI

"https://github.com/litecoin-foundation/LitewalletPartnerAPI.git: The remote repository could not be accessed. Make sure a valid repository exists at the specified location and that the correct credentials have been supplied."

So the LitewalletPartnerAPI is fixed now since I was added to that Github organization, but I still am having the push notification error. Do I needed to be added to an Apple Development team or should I just turn off push notifications in Capabilities? @kcw-grunt


Pitch and roll response curve

Let me start by saying thanks so much for this mod and how you continue to improve it!
One thing I wanted to ask you about is if there's any chance you could adjust the response curves for the pitch and roll? Making them a bit less "aggressive".
I'm also using the mod linked below for the Bonanza G36 and one thing I really like about that mod/aircraft is how it has exactly this, less aggressive response curves for both pitch and roll. Making it feel more realistic and less "arcade'ish".
https://github.com/roblenvic/Bonanza-Turbo
Again, many thanks for your work on this aircraft and I love how we now can also open the doors 🙂

I can't realise that, because it's only subjectively. I don't have real TBM930 pilot, and not have real information about that


(PUP-10598) Change default value of ignore_plugin_errors to false

If ignore_plugin_errors is true(default value before this commit),
puppet agents can fail to pluginsync and will be missing facts/types/providers
that may be needed to request and apply the catalog.
For example, missing custom/external facts can change which classes are
included in the catalog or cause compilation failures if the manifests
references the missing fact

CLA signed by all contributors.

jenkins please test this with servertests

Could you backport the rubocop commit to master, as pull requests based off of master and main are failing the assignment rubocop rule. To avoid future conflicts between 5.5.x and master versions of configurer.rb, it may be best to backport the rubocop fix to 5.5.x.
We unfortunately don't run rubocop or tests when merging up from earlier branches so these kinds of issues can creep in...

rubocop and schema should be good after https://github.com/puppetlabs/puppet/pull/8341 gets promoted

Not sure why this test is failing, but it seems the expected function output is missing (separate from the fact output)
Expected /Notice: --\*\w+-i18ndemo function: それは楽しい時間です\*--/

Needs rebase on upstream/main to get the rubocop fix/resolve conflicts in c3a37a92d5

Test error is not related to this PR changes and will be handled in: https://github.com/puppetlabs/puppet/pull/8340

jenkins please test this with servertests


Clear waveData

Hey, what a great package, very good job !
I have used to record and after I want to preview it, it works fine but I want to clear the waveData manually and I've seen it's not possible since the method reset is private.
Could you made it public to let us use it ?
Thanks a lot !

Hey @clemortel, yes after releasing the first thing I noticed was this so if you check this PR, it is resolved there. But that PR had some issue with multiple players so that's why it has not been merged yet.

Hey @clemortel we have released audio_waveforms: ^0.1.1 which fixes this issue you can check out here


[pattgen] Fix width of literal in pattgen_chan.sv

I think this was probably copied from the previous line. pda_o should
be a single bit output.

Thanks for catching that Rupert.  LGTM.


shell: cmd-clink

fix #1066

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

3 of 29 (10.34%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.3%) to 57.419%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

internal/shell/cmd_clink/action.go
0
3
0.0%

internal/shell/cmd_clink/snippet.go
0
23
0.0%

Totals

Change from base Build<PHONE_NUMBER>1:
-0.3%

Covered Lines:
3065

Relevant Lines:
5338

💛  - Coveralls


isCloseTo doesn't work with arrays

Summary
double[] x = ...;
double[] y = ...;
// This doesn't compile:
assertThat(x).isCloseTo(y);

Example
Without this, you get errors like:
org.junit.ComparisonFailure: expected:<...0.5, 0.5, 0.75, 0.25[, 0.75, 0.25]]>
    but was:<...0.5, 0.5, 0.75, 0.25[000000000000006, 0.75, 0.25000000000000006]]>

Java 8 specific ?

NO

There is indeed no isCloseTo for arrays of numbers.
I'm curious: how would you define isCloseTo mean for arrays ?

I would expect the semantics to work element-wise, the same way that the regular isCloseTo works for scalars. (You could define other metrics to measure similarity between matrices, e.g. an L_2 norm, but I think the element-wise max difference makes the most sense as a sane default.) i.e. the assertion would fail if there was a difference in any given element position of greater than a specified epsilon. The assertion would also fail if the arrays were of different sizes.
It probably makes sense to provide support for at least 1D, 2D and 3D  matrices.

That makes sense, do you want to contribute ? (that's ok if you can't)

I figured why not, I'll give this a shot. I just spent the last 45 minutes setting up an AssertJ Eclipse project and figuring out how to write this, then I realized that containsExactly with a precision argument already does this exact thing. It's probably not ideal to duplicate the API for containsExactly in the form of isCloseTo. What do you think?
As an aside, it would make it much easier to hack on AssertJ if you check in the Eclipse project files/dirs (.project, .classpath, .settings) into GitHub. Then Eclipse can immediately find the existing project from the git URL, set it up automatically with Maven and with the correct classpath for running tests, etc.

@joel-costigliola I guess this can be closed?

Sorry I did not remember containsExactly already supported that (facepalm)
The API is already big enough to avoid adding duplicate unless I have a very good case.
I have added the eclipse project files (but it's easy to import the project in eclipse in you have a maven plugin).

All good, thanks!


Feature request: Clicking the crate {x} button takes you to the crate

Something that would be nice in my opinion is if you clicked where it said "Crate ormx" it'd redirect you to the crates page (in this case, crates.io/crates/ormx)

I tried to contribute but couldn't find the correct file lmao. If a contributor could help me find out where I have to edit I'd be grateful!

@Milo123459 I found why this is hard - you meant the crate button on rustdoc pages; I thought you meant the one on /crate pages. The one on rustdoc pages is hard to change because we don't control rustdoc's output.

@Milo123459 I found why this is hard - you meant the crate button on rustdoc pages; I thought you meant the one on /crate pages. The one on rustdoc pages is hard to change because we don't control rustdoc's output.

Am I ok the wrong repo? If so, sorry!

@Milo123459 no - docs.rs uses rustdoc internally to generate the docs, and /crate pages are specific to docs.rs. The tricky thing here is finding a way to tell rustdoc to change its behavior just for docs.rs.
Hmm, I wonder if a better approach would be to rewrite the HTML as we stream it from S3. The relevant code is in https://github.com/rust-lang/docs.rs/blob/4a1b3464d1b7631e54a889ec824cbb13aca23637/src/utils/html.rs#L11, you might be able to do it there without changes to rustdoc.

Hmm. Not sure. Shall have a look into it, thanks!

After looking into it, I still have 0 clue. I think you need to make sure that is only generated for docs.rs?

@Milo123459 can you join the discord so I can help you more quickly? Github isn't great for extended discussions: https://discord.gg/f7mTXPW. I don't really understand your current question and it will be faster with less delay between responses.


Logo issue in dark mode

app logo is creating a white background when it goes to dark mode.
Hey @param-code,
can you please assign it to me??

can you assign the issue


Execute command just freezes

Which API Provider are you using?
Ollama
Which Model are you using?
qwen2.5:32b
What happened?
Anytime Cline executes a command, the command executes but never returns control back to Cline. Not sure what is happening. I'm using fish shell, so wondering if that is it.
Steps to reproduce

Have cline create a script it needs to run (python, usually)
Agree to run it
It never continues even after the command has finished

Relevant API REQUEST output
[write_to_file for 'count_snps.py'] Result:

The content was successfully saved to count_snps.py.

<environment_details>
# VSCode Visible Files
count_snps.py

# VSCode Open Tabs
bcf_parser.py
count_snps.py
</environment_details>

Additional context
No response

I have simillar issue.
models tried: llama 3.2 3b, 3.1 70b, lfm 40b MoE using openrouter
❯ code --version
1.92.0
b1c0a14de1414fcdaa400695b4db1c0799bc3124
arm64

default shell:
❯ echo $SHELL
/run/current-system/sw/bin/fish

using starship:
❯ starship --version
starship 1.19.0
branch:
commit_hash:
build_time:1980-01-01 00:00:00 +00:00
build_env:rustc 1.77.2 (25ef9e3d8 2024-04-09) (built from a source tarball),

device:
❯ uname -a
Darwin Haniels-MacBook-Air.local 24.0.0 Darwin Kernel Version 24.0.0: Tue Sep 24 23:36:26 PDT 2024; root:xnu-11215.1.12~1/RELEASE_ARM64_T8103 arm64

It runs command on terminal, then never returns back to cline.

Same issue using OpenRouter.
The command runs successfully in the terminal. However, the control is never returned. Screenshot attached.

i have the same issue, running on zsh

Same here. Also qwen2.5:32b

Also an issue running zsh

I've started having this issue as well despite it working ok in the past

am also using zsh and facing the same issue.. for the time being I changed back to bash and it works. I hope they get it fixed
Here is how to do it
1. Open Visual Studio Code: Launch your VSCode application.
2. Access Terminal Settings:

Open the integrated terminal by selecting Terminal > New Terminal from the top menu.
Click on the dropdown arrow next to the + icon in the terminal tab, then select Select Default Profile.

3. Select Bash:

From the list of available shells, choose Bash. This will set Bash as the default shell for the integrated terminal.

I've had this as well, it Cline sits waiting for the command to finish - but it's actually already finished. The workaround I've found is to click into the terminal and press enter, then cline seems to wake back up again. It's annoying for sure.


Updated documentation to clarify Component's required_packages

Proposed changes:

The list of requirements is actually a list of importable python
modules, not package names. See issue #3647 for more details.

Status (please check what you already did):

[x] made PR ready for code review
[ ] added some tests for the functionality
[x] updated the documentation
[ ] updated the changelog
[x] reformat files using black (please check Readme for instructions)

Thanks for the PR, we'll give it a review as soon as possible.


Itemset command crashes game

when you hitting "space" key after "itemset" - game crashes

I can't reproduce...
I typed the command, pressed space, selected the biome and it worked normally.

I guess also something that has got fixed, thanks for checking.


Local Importance shows the same graph for all objectives

With Hyperparameter importance, if you select "local Importance", the same graph is displayed for all objectives. If you select Fanova, however, different graphs are displayed.

See for example this run:
mo_run.zip

Should be fixed with #113


A question about "CefViewClient::V8ValueToCefValue"

A comment states the following:

"The IsDouble, IsInt and IsUint methods return a boolean value indicating whether the CefV8Value instance is a target type or can be converted to the target type."

My question is, from where do you deduce that those functions tells if the value can be converted, beside testing the type?
Looking in the CEF headers, I read this and (if I am not mistaken) conclude that the functions ONLY check the type.
So the order in which the IsDouble, IsInt and IsUint functions are used should be irrelevant.
  ///
  /// True if the value type is int.
  ///
  /*--cef()--*/
  virtual bool IsInt() = 0;

  ///
  /// True if the value type is unsigned int.
  ///
  /*--cef()--*/
  virtual bool IsUInt() = 0;

Thanks

I remember this comment was added by fixing the issue (#10).
And after debugging, I found there is mistake in this comment.
Just try the code below:
   auto v = CefV8Value::CreateInt(1000);
   auto isDouble = v->IsDouble();
   logD("isDouble: %d", isDouble);  // true
   auto isUnint = v->IsUInt();
   logD("isUnint: %d", isUnint);    // true
   auto isInt = v->IsInt();
   logD("isInt: %d", isInt);        // true

And also, there is a bug in the executeJavascriptWithResult method, I am fixing it now.

Thanks.

Argh! My bad. If I understand correctly in Javascript there is only one value (V8Value) of type "Number" stored as float.

So that's probably why "1000" will always give true in all three conditions: technically it's a "double", but it can be converted to "uint" and "int".
Excuse me, but if that is the case I see a problem with the order of your conditions: if isDouble() is always "true", this prevents the other conditions isUint(), is Int() from being reached.
So wouldn't it make sense to check the value in the order: isUint(), isInt(), isDouble()?

uhm..... I think you are correct...will draft a fix

can review this commit: https://github.com/CefView/CefViewCore/commit/aa4b74228ad4ce9b6e1459620e9d00c85251366d


Demo using ModelNet40

Hi,
I tried to demo using a point cloud object(chair) from ModelNet40.
However, the PCN shape completion did not work.

Please let me know if there are some concrete steps to prepare the datasets which can work with the pre-trained models provided in this repository.
Thank you

The point clouds in ShapeNet, which are used to train the provided model, are mean-centered and normalized within the unit sphere. Note that this normalization applies to the complete point cloud or mesh model rather than the partial one.

Did you find a solution for this? I tried mean centering and normalizing the point cloud, yet I am getting the same kind of results for point clouds that are not a part of ShapeNet. @wentaoyuan @sheshappanavar

@wentaoyuan can you share the part of code doing mean-centering and normalization? I created my data (it is not from shapenet) based on the codes provided in sample and render folders but I think there is an scaling problem (not the scale of the points). or can you provide more information about the shapenet dataset that I change my custom data to those features.


Possible to override NPM version separate from the local/global Node?

Is it possible to select, say<EMAIL_ADDRESS>globally or locally instead of always using the NPM that comes with the Node version selected? I assume I could go in and remove the shim for NPM, but I wanted to see if there was a supported way to do this. I work in repositories that run on specific versions of Node, but my team wants to use NPM6's security features.
I would also be okay with simply using the system NPM in this case (and I could just install NPM versions with brew)
Thanks

The npm global install is installed with the node version itself, which means you can create specific "node versions" that have specific desired versions of npm.
Say you have node 8 installed (which ships with npm 5). You'd like to have this node use npm 6 in some projects, but other projects should still use node8+npm5.
With the node you want to duplicate already installed, first cd to the versions directory and rename the node. Then activate the newly renamed node and install the desired version of npm. And lastly, re-install node8 which gives you the "stock" npm.
cd $(nodenv root)/versions
mv 8.11.2{,+npm6}
nodenv shell 8.11.2+npm6
npm i -g npm
nodenv install 8.11.2

This gives you two node8 nodes, one with the stock npm5 and the other with npm6. nodenv won't mess with any global modules as you switch between nodes, so whatever npm you choose to install globally will remain with that node. (Unlike n which force-reinstalls the stock npm each time you switch nodes 😦 )
Of course, you can name the node whatever you like. I find the "+..." style to be pretty clear to distinguish from the default name. I've used this setup successfully for quite a while (especially back during the npm2 -> npm3 transition).
Of course, you can extrapolate this to any global module setup you like, doesn't need to be specific to npm.

Thanks @jasonkarns, that sounds exactly like what I want!


How disable hits tracking

Please use the following questions as a guideline to help me answer
your issue/question without further inquiry. Thank you.
Which version of Elastic are you using?
[ ] elastic.v2 (for Elasticsearch 1.x)
[ ] elastic.v3 (for Elasticsearch 2.x)
[ ] elastic.v5 (for Elasticsearch 5.x)
[ X] elastic.v6 (for Elasticsearch 6.x)
I have a very large Cardinality Aggregation Query. In my manual query I set "track_total_hits": false. I don't see a way to set this in SearchSource struct. Without this, my query takes quite awhile to run each time. With this value, I believe ES cache helps subsequent runs return quickly.
Is there a way to do this?

Looks like it’s missing. I will add it to the relevant files. It’s a long weekend, and I hope to finally get my hands on Elastic again in the next days.

@olivere Thanks! For what it's worth, I noticed that this feature is also missing from the ES REST clients. Since they change their API so frequently, do you think it would make sense to add a method to add additional 'properties' to the query?

@lordnynex I see what you're after. Adding a properties field will make things worse in the long run, I guess. People start using it and you won't have a chance to get them back to the specific property once you add it. Also, for simple properties this might work. But what about more complex properties like object? I think we open up a can of worms with properties.
While we're never up to date it's also a chance for me to keep up-to-date with changes in Elasticsearch.


Fix disappearing walls when 'Start BFS' is clicked

When the simulation is started, all walls/barriers are cleared because init() was called again and again, when it should only be called to reset the grid.

@zhirzh  I appreciate your help but I am already working on that visualization. If you want to contribute to this repository please let us know at #27

Okay. I see. I didn't know that.


[vcpkg] update msys-libtool version

Describe the pull request

What does your PR fix?
Fixes #28896
libtool-2.4.6-9-x86_64.pkg.tar.xz is no longer available, updated version to libtool-2.4.7-3.

Can anyone merge this ASAP?

When will this change be available on master?

For anyone who is urgent: Create your own registry! 😂

Create your own registry! 😂

Won't solve the issue. You need to supply your own SCRIPTS folder in that case.

@JonLiu1993 Please check all msys tools if they are latest. If not update them accordingly.

Yes, I mean create your own fork, it can be used for a custom vcpkg and registry, and its fast.

Also this stuff can be avoided for existing users via setting up an asset cache https://vcpkg.io/en/docs/users/assetcaching.html

Yes, I mean create your own fork, it can be used for a custom vcpkg and registry, and its fast.

Definitely going to do this once we have a working build.


Correct is diffSoln, no difSoln

https://github.com/semuconsulting/pyubx2/blob/b9da2f67694959b65d13444b41bd3b07032c66b3/src/pyubx2/ubxtypes_get.py#L2432

Hi @klepo
Sorry - what specifically is the issue here?  I'll need a lot more information than this.

OK typo will be fixed in next release, but the attribute can still be referenced now as msg.difSoln in the meantime.


source code missing

Why is the source code in the /src/main/java/net/sf/jsqlparser/parser directory of this project incomplete and missing many classes?

Greetings.
Those parts are generated by JavaCC during the build.


CBLAS Build error in dlib external

Hi!
I'm trying to compile cblas that is in external/cblas folder of dlib.
I'm using MSVS 2015.
I run
cmake -G "Visual Studio 14 2015 Win64"
and I got
-- The Fortran compiler identification is unknown
CMake Error at CMakeLists.txt:11 (enable_language):
No CMAKE_Fortran_COMPILER could be found.
I installed G95 fortran compiler before but Cmake doesn't see it.
Could someone advise how to fix this ?

Why do you want to do this in the first place?

Davis,
You mean in external/cblas ?
I thought Ican build a library just to add this lib to the project after.

I don't see any reason why anyone would want to build that cblas project when using visual studio.  If you want a BLAS library, download the Intel MKL.
I should also point out that cblas doesn't contain a BLAS, it's just part of something that's useful in certain situations when you already have a BLAS library, which I highly doubt is your situation.


Rspec proposal

This is a proposal about using RSpec for unit testing
My idea, if you are up to it, would be to rewrite the tests in rspec format so that later I could split the gnuplot file to organize the code to facilitate contributions.
Here I am also adding simplecov to check spec code coverage

sounds reasonable, I could merge in a few days when it has quieted a bit,
or would you like to be a maintainer?
On Wed, Nov 6, 2019 at 3:07 PM Favini<EMAIL_ADDRESS>wrote:

@darthjee commented on this pull request.
In spec/integration/arrtest_spec.rb
https://github.com/rdp/ruby_gnuplot/pull/52#discussion_r343353914:

@@ -0,0 +1,44 @@
+describe "Array Plot Example" do

let(:file_path)    { 'spec/tmp/array_plot.eps' }
let(:fixture_path) { 'spec/fixtures/plots/array_plot.eps' }

the idea of this test is rely on a pregenerated file when testing the
whole integration
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rdp/ruby_gnuplot/pull/52?email_source=notifications&email_token=AAADBUC6QOTKGW2D26OX6EDQSM52HA5CNFSM4JJ6LB32YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCKSJVZA#pullrequestreview-312777444,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAADBUHUL2RPF5OMGDYELTLQSM52HANCNFSM4JJ6LB3Q
.

Well, since this is the first proposal, I would sugest not to merge yet, and I will write the specs for everything and then we do just one merge, WDYT?
About being maintainer, I could do that yes, I have deeply interest in this gem, but I have no hurry , I will only have time to actually use it next year :P

let me know when you feel ready with it :)

Sure, still a lot to cover. one thing though, I think I found a bug
plot = Gnuplot::Plot.new
plot.title "my title"
plot.title "My NEW Title"

plot['title'

this sounds like it should return My NEW Title while it is returning my title still
if that is the case, I know where the fix should go and can prepare a parallel PR for that

Sure.
On Mon, Nov 25, 2019 at 2:00 AM Favini<EMAIL_ADDRESS>wrote:

Sure, still a lot to cover. one thing though, I think I found a bug
plot = Gnuplot::Plot.new
plot.title "my title"
plot.title "My NEW Title"
plot['title'
this sounds like it should return My NEW Title while it is returning my
title still
if that is the case, I know where the fix should go and can prepare a
parallel PR for that
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rdp/ruby_gnuplot/pull/52?email_source=notifications&email_token=AAADBUCYPU4OSQ5HO5VXHADQVOH3XA5CNFSM4JJ6LB32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFBUKPQ#issuecomment-558056766,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAADBUFFTTGDU3HWGW23PLDQVOH3XANCNFSM4JJ6LB3Q
.

Right now, the specs are covering 84%
There is still a lot to cover (84% is not a real metric)
Since I will go on vacation, I would merge this one and finish it in January
Also, this can help with any refactoring comming

Awesome, you rock!


Inference Engine crash when using Activation layer with type="sigmoid"

Using the latest 2018R4 release of Intel's OpenVINO, a very simple network with a Convolution layer and a Activation layer crashes at run time with the following error:
Illegal instruction (core dumped)

But the network is ok if the activation type is changed from sigmoid to tanh.
The net is defined as follows in the IR xml:
<layers>
	<layer id="0" name="data" precision="FP32" type="Input">
		<output>
			<port id="0">
				<dim>16</dim>
				<dim>32</dim>
				<dim>8</dim>
				<dim>8</dim>
			</port>
		</output>
	</layer>
	<layer id="1" name="conv_fwd" precision="FP32" type="Convolution">
		<data dilations="1,1" group="1" kernel="3,3" output="32" pads_begin="1,1" pads_end="1,1" strides="1,1"/>
		<input>
			<port id="0">
				<dim>16</dim>
				<dim>32</dim>
				<dim>8</dim>
				<dim>8</dim>
			</port>
		</input>
		<output>
			<port id="2">
				<dim>16</dim>
				<dim>32</dim>
				<dim>8</dim>
				<dim>8</dim>
			</port>
		</output>
		<blobs>
			<weights offset="0" size="36864"/>
		</blobs>
	</layer>
	<layer id="2" name="act_fwd" precision="FP32" type="Activation">
		<data type="sigmoid"/>
		<input>
			<port id="0">
				<dim>16</dim>
				<dim>32</dim>
				<dim>8</dim>
				<dim>8</dim>
			</port>
		</input>
		<output>
			<port id="1">
				<dim>16</dim>
				<dim>32</dim>
				<dim>8</dim>
				<dim>8</dim>
			</port>
		</output>
	</layer>
</layers>
<edges>
	<edge from-layer="0" from-port="0" to-layer="1" to-port="0"/>
	<edge from-layer="1" from-port="2" to-layer="2" to-port="0"/>
</edges>

Hi,
Could you provide more information (command line or something like that)?
Illegal instruction
It looks like you are using CPU plugin. Am I right?
Could you provide your hardware configuration? I mean the CPU model if you are using the CPU plugin.

My CPU model is E5-2650v2. It's not on the supported list of OpenVINO. This could be the problem.
But the odd thing is, if the positions of the two layers are exchanged, i.e. from conv-act(sigmoid) to act(sigmoid)-conv, the inference engine has no problem running the net.


enumerate core data types to be included/supported

Enumerate core data types that should be supported as part of wis2box (ingest, API, UI, testing).

Closing in lieu of #549


Cross versioned CI.

ActiveRecord::Type::Json is implemented at Rails 5.2.

implements with #2.

implements with #2.


feat(prettier) print simple types

Current dependencies on/for this PR:

main

PR #1378

PR #1379   👈

This stack of pull requests is managed by Graphite.

Merge activity

Nov 17, 8:11 AM: @Boshen started a stack merge that includes this pull request via Graphite.


Is there a file for the case ???

Hello first of all wow , amazing work.
A long time ago i decided to just drop the idea of controlling my AC because the inverter on my bedroom doesnt support the LG wifi module.
I am so pumped that you made this work, i already submitted the files to PCBway so they can build and assemble for me , however i was wondering if you happen to have the file for the accrylic case ? I kinda want to have everything made by them and i do not have any 3d printer .
Thanks

It's just an Adafruit 2359 Raspberry Pi case :) When I designed the PCB I was hoping it'd fit in a Pi case and this one works well.
It's also in the list of materials in hardware/materials.md

Thanks , i somehow missread that part.
One last thing i am a bit confused , do we have to power the unit itself with USB C and then connect to the HVAC ???? or does it use the power from the HVAC unit ?

One last thing i am a bit confused , do we have to power the unit itself with USB C and then connect to the HVAC ???? or does it use the power from the HVAC unit ?

It's powered by the HVAC unit. You only need the USB port to flash the firmware on it the first time before connecting it to the AC.

So my pcbs are finally done but i think some of the orientation of the smds might be wrong .
Can someone take a look at this?

Do you think the R values are incorrect?
Because otherwise resistors have no polarity, their orientation doesn't matter.

I am patienly waiting now for the order to be delivered , i went ahead flashed the firmware already on both of my esphomes, they are recognized in home assistant however i cannot add them in the ESPhome addon , i want to manage them in the esphome addon from home assistant for easier updates and such.
Ps i also orde your pcbs @florianbrede-ayet , they arrive soon

Finally everything is here altho i am encountering some issues.
I am attaching some pictures i know that the cables do not match , but i think i got it correctly , the espmodule doesnt even come on.

You need to switch the red and yellow wires on the PCB.
If you look at the colors of the wires from the AC it should be (from left to right on your picture) Red, Yellow, Black. Because the cable has different colors, it should be Yellow, Black, Red from left to right in the picture you posted.
I should have added some labels to the PCB about the colors, but my first goal was to get it working at all and back then I didn't expect this PCB to become so popular.

I have tried to swit many cables around and nothing happens , the esp light doesnt even come on , i can power the esp with a USB cable without problems and its recognized already in HA. Does the led on the ESPmodule is supposed to come on ?

Maybe the CN-REMO connector is not plugged into the board ?

I have tried to swit many cables around and nothing happens , the esp light doesnt even come on , i can power the esp with a USB cable without problems and its recognized already in HA. Does the led on the ESPmodule is supposed to come on ?

The LED will be off when connected to the AC. It will only be on when connected to USB.

The LED will be off when connected to the AC. It will only be on when connected to USB.

Yup ,so stupid of me LOL i am kinda newbie to this esp world , just figured it out , works perfectly however commands take a few seconds to arrive to the unit when pressing them on the HA app is this the same behaviour for you ??

Yup ,so stupid of me LOL i am kinda newbie to this esp world , just figured it out , works perfectly

Great!  🎉

however commands take a few seconds to arrive to the unit when pressing them on the HA app is this the same behaviour for you ??

Yes that's expected. The LG communication protocol is slow (sending a complete message takes at least a second) and the controller internally "updates" every 6 seconds so there can be a delay of about 1-6 seconds depending on this 6 second cycle.

Yes that's expected. The LG communication protocol is slow (sending a complete message takes at least a second) and the controller internally "updates" every 6 seconds so there can be a delay of about 1-7 seconds depending on this 6 second cycle.

Awesome job man , i cant thank you enough for all of the help , would be amazing if we can just use esphome addon on home assistant to just update the firmware , guess i need to learn more linux lol

Awesome job man , i cant thank you enough for all of the help

No problem! It's great to see people all over the world using this. If you don't mind sharing, what kind of LG units do you have? I have a list of supported units in the README.

would be amazing if we can just use esphome addon on home assistant to just update the firmware , guess i need to learn more linux lol

It may be possible to upload the firmware within Home Assistant and/or the ESPHome dashboard / add-on, but I don't really know this part of HA/ESPHome. When I was writing the software it was just easiest to use the command-line tools for testing. Maybe someone else reading this knows more about it.

No problem! It's great to see people all over the world using this. If you don't mind sharing, what kind of LG units do you have? I have a list of supported units in the README.

Yup , i have the ARNU18GSCR4 , which worked
Also works on the ARNU36GSVA4
Altho i broke the pin on one of the JSX connectors so i need to wait until monday to fix it since i am away for the weekend. I only have 1 working so far but tested on both devices and it worked.

It may be possible to upload the firmware within Home Assistant and/or the ESPHome dashboard / add-on, but I don't really know this part of HA/ESPHome. When I was writing the software it was just easiest to use the command-line tools for testing. Maybe someone else reading this knows more about it.

Will be a plus but its not necessary so happy that i did not purchased the LG wifi module , plus the ARTCOOL Mirror doesnt even support it now i need to get some temperature sensors so i can automate the climate to always be on the perfect temperature , pumped about this.

Wow, the ARNU36GSVA4 is very powerful.
I added these to the README; maybe it will help someone with similar units.


frei: init at 0.1.0

Description of changes
It's something I've had in my local setup for a little while, so thought to finally upstream it.
Adds frei to nixpkgs at its current version, 0.1.0
frei is a version of free written in Go which displays the memory/swap usage in a nice bar graph.
Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Done!

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

1 package built:

frei


The first click on a facet is disabled

This is priobably caused by the input.on('change') that redraws everything.

Fixed via e58a4eda1d96271ad2c6320b9d3d8e93e5b1d6cd


TDEAL-16: ZAP improvements

TDEAL-16

@coderabbitai review
I'm testing the AI code review tool CodeRabbit here. Please bear with me. And if it comments some useful feedback, please address it.

@coderabbitai review
Sorry about that.


add_author

Updated README.md
added Jian Tao as an author

@dreamer2368 @ckendrick @andersonw1 @pravija12345 Can any two of you review and approve this PR and merge it to master? I have just added Jian Tao from TAMU as an author of pylibROM. We should have added him from the beginning.


Remove unexpected profile

Remove file mistakingly added in PR https://github.com/DataDog/integrations-core/pull/15051 when resolving conflicts.

@NouhaManai96 the profile is not ready as is yet so best to remove for now