Swift 3 Support?

As Xcode 8 and Swift 3 release becoming imminent, do you have any plans for updating this library for that?
P.S.: I have already started the PR, it's way too complicated for me!

Hey guys, @ober01 , @Juriv
It seems nobody cares about Swift 3.0 release around here. I think you guys are busy updating your projects to Xcode 8.0 compatible versions.
I have tried to upgrade this framework to support Swift 3.0 but I'm facing a vicious error which I cannot reproduce outside this project. Can anyone help solving it and add official Swift 3.0 support to paper-onboarding?
If interested, please clone my fork and try to compile it. There is a problem with >>>- operator which I can't solve.
More context: Swift 3 Generic infix operator error
Thanks,
M.

Could you please advise on Swift 3 support.

It seems like nobody cares about this lib @ Remotion!
If I can't solve the problem with the >>>- operator, I'm going to release them with a simpler function form and get rid of the operator's use altogether! Is's only 18 places and I can easily replace them.
Is everybody onboard with that?!

@mohpor fine with me, what's the progress of the fork?

@yichengsun @dhamukrish and others,
I have finished the conversion to Swift 3.0
Everything runs smoothly now.
Not sure when it'll be merged.
Checkout #19
use this until it is merged:
pod 'paper-onboarding', :git => 'https://github.com/mohpor/paper-onboarding.git', :branch => 'Swift3.0'

Cheers,
Happy coding


ZEPPELIN-2555: Run all paragraphs API does not run all paragraph as front-end user.

What is this PR for?
Run all paragraphs API (http://zeppelin.apache.org/docs/0.8.0-SNAPSHOT/rest-api/rest-notebook.html#run-all-paragraphs) does not run all paragraph as front-end user.
What type of PR is it?
[Bug Fix]
Todos

[ ] - Task

What is the Jira issue?

ZEPPELIN-2555

How should this be tested?
Testing steps in screenshot
Screenshots (if appropriate)
Before:

After:

Questions:

Does the licenses files need update? N/A
Is there breaking changes for older versions? N/A
Does this needs documentation? N/A

Tested and works as described. LGTM.

I was thinking that we should add test for the rest api. And we should create a test framework to make the test easier. Otherwise it is easy to break the api. And this is not the first time I see the rest api broken. But anyway we could do it in a separated ticket.

@1ambda  Thank you for reviewing this.
@zjffdu Yes make sense, let's start a different thread, discuss and fix it there.

Merging this if no more discussion.


Max payload size limited to 64 bytes

I´m trying to send payloads bigger than 64 bytes.
Is there a way to achieve it?

I'm not a library developer, but did you tried editing endpoints.c ?
#define RSP_BUFFER_SIZE 64

and changing udp transmit buffer:
#define UDP_TX_PACKET_MAX_SIZE 860


False-positive triggering of OWASP CRS rule 920420 with libmodsecurity 3.0.0-rc1

Configuration - nginx/1.13.4 + ModSecurity-nginx + libmodsecurity (3.0.0-rc1 / 04f7009), with OWASP CRS v3.0.2.
Request:
$ curl -XPOST -d 'd=b'  -v http://localhost/modsec-full/
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to localhost (<IP_ADDRESS>) port 80 (#0)
> POST /modsec-full/ HTTP/1.1
> Host: localhost
> User-Agent: curl/7.52.1
> Accept: */*
> Content-Length: 3
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 3 out of 3 bytes
< HTTP/1.1 403 Forbidden
< Server: nginx/1.13.4
< Date: Thu, 31 Aug 2017 16:09:28 GMT
< Content-Type: text/html
< Content-Length: 169
< Connection: keep-alive
<

<title>403 Forbidden</title>

403 Forbidden

nginx/1.13.4

* Curl_http_done: called premature == 0
* Connection #0 to host localhost left intact

Logs:
2017/08/31 16:09:28 [info] 15815#15815: *2 [client <IP_ADDRESS>] ModSecurity: Warning. Matched "Operator `Rx' with parameter `^%{tx.allowed_request_content_type}$' against variable `TX:0' (Value: `application/x-www-form-urlencoded' ) [file "/etc/nginx/modsec/owasp-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "911"] [id "920420"] [rev "2"] [msg "Request content type is not allowed by policy"] [data "application/x-www-form-urlencoded"] [severity "2"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"] [ref "v0,4o0,33o0,33v112,33"] [hostname "<IP_ADDRESS>"] [uri "/modsec-full/"] [unique_id "150419576835.295343"], client: <IP_ADDRESS>, server: , request: "POST /modsec-full/ HTTP/1.1", host: "localhost"
2017/08/31 16:09:28 [info] 15815#15815: *2 [client <IP_ADDRESS>] ModSecurity: Access denied with code %d (phase 2). Matched "Operator `Ge' with parameter `%{tx.inbound_anomaly_score_threshold}' against variable `TX:ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/modsec/owasp-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "36"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "<IP_ADDRESS>"] [uri "/modsec-full/"] [unique_id "150419576835.295343"] [ref ""], client: <IP_ADDRESS>, server: , request: "POST /modsec-full/ HTTP/1.1", host: "localhost"
2017/08/31 16:09:28 [warn] 15815#15815: *2 [client <IP_ADDRESS>] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `%{tx.inbound_anomaly_score_threshold}' against variable `TX:ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/modsec/owasp-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "36"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "<IP_ADDRESS>"] [uri "/modsec-full/"] [unique_id "150419576835.295343"] [ref ""], client: <IP_ADDRESS>, server: , request: "POST /modsec-full/ HTTP/1.1", host: "localhost"
2017/08/31 16:09:28 [info] 15815#15815: *2 [client <IP_ADDRESS>] ModSecurity: Warning. Matched "Operator `Ge' with parameter `%{tx.inbound_anomaly_score_threshold}' against variable `TX:INBOUND_ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/modsec/owasp-crs/rules/RESPONSE-980-CORRELATION.conf"] [line "61"] [id "980130"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=0,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): Request content type is not allowed by policy'"] [data ""] [severity "0"] [ver ""] [maturity "0"] [accuracy "0"] [tag "event-correlation"] [ref ""] [hostname "<IP_ADDRESS>"] [uri "/modsec-full/"] [unique_id "150419576835.295343"] while logging request, client: <IP_ADDRESS>, server: , request: "POST /modsec-full/ HTTP/1.1", host: "localhost"

So far I tracked this down to the following changeset: 039bd2c
Library built from previous changeset (ca9cbf4) works fine with the same configuration/request:
$ curl -XPOST -d 'd=b'  -v http://localhost/modsec-full/
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to localhost (<IP_ADDRESS>) port 80 (#0)
> POST /modsec-full/ HTTP/1.1
> Host: localhost
> User-Agent: curl/7.52.1
> Accept: */*
> Content-Length: 3
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 3 out of 3 bytes
< HTTP/1.1 200 OK
< Server: nginx/1.13.4
< Date: Thu, 31 Aug 2017 16:23:38 GMT
< Content-Type: text/plain
< Content-Length: 39
< Connection: keep-alive
<
Thank you for requesting /modsec-full/
* Curl_http_done: called premature == 0
* Connection #0 to host localhost left intact

Debug logs for both cases are here: https://gist.github.com/defanator/0a9658a07ed6eb005fe94162cebfba1d
Diff show something strange with variable saving parts:
--- modsec-debug-ok.log 2017-08-31 16:46:54.998207164 +0000
+++ modsec-debug-fail.log       2017-08-31 16:50:40.620265147 +0000
@@ -188,7 +188,7 @@
 [9] Matched vars updated.
 [9] Rule contains a `pass' action
 [4] Running [independent] (non-disruptive) action: setvar
-[8] Saving variable: TX:allowed_methods with value: GET HEAD POST OPTIONS'
+[8] Saving variable: TX:allowed_methods with value: GET HEAD POST OPTIONS
 [4] Rule returned 1.
 [9] (SecDefaultAction) Running action: log
 [9] Saving transaction to logs
@@ -203,7 +203,7 @@
 [9] Matched vars updated.
 [9] Rule contains a `pass' action
 [4] Running [independent] (non-disruptive) action: setvar
-[8] Saving variable: TX:allowed_request_content_type with value: application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain'
+[8] Saving variable: TX:allowed_request_content_type with value: application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain
 [4] Rule returned 1.
 [9] (SecDefaultAction) Running action: log
 [9] Saving transaction to logs
@@ -218,7 +218,7 @@
 [9] Matched vars updated.
 [9] Rule contains a `pass' action
 [4] Running [independent] (non-disruptive) action: setvar
-[8] Saving variable: TX:allowed_http_versions with value: HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0'
+[8] Saving variable: TX:allowed_http_versions with value: HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0
 [4] Rule returned 1.
...

Hi @defanator
So you're right when mentioning that change set 039bd2c is when the issue started happening here. Indeed this fixes the implicit negated operator used by a few CRS rules (including 920420) but then this leads into another issue.
After a while debugging the issue I finally realized that the problem was that the last condition in that chained rule was matching simply because macro expansion for the @rx operator (which is implicit there) is not working :(
So this immediately reminded me of issue #1528. I've read and tested PR #1536 and confirm that issue is fixed when macro expansion is enabled for @rx.
Thanks a lot for that comprehensive bug report :)


Analytic form of c distribution

Most distributions in UNITY are Gaussians or uniform distributions. However, the light curve color parameter distribution is generated as a Gaussian convolved with an exponential. @rubind wrote down the analytical form and will upload it to the repository.

Added Mathematica code, but sum of Gaussians might be easier to implement...


Toppology Modeler should run on port 4201 in devmode

Reason: parallel usage of Backend UI and topology modeler

Alright, fixed on my latest pull request.


Support contra-variant type check for object method arguments (similar to Dart)

Fixes #12965

what is contr-variant?

I was curious about that too, as I didn't understand what it was about at all.
Here's what wikipedia says:
Covariance and contravariance (computer science)
And this is what I was able to find on Dart
Dart and covariant
But if you,  @yegappan , could explain it in your own words, it would be much better.

Hi Christian,
On Fri, Sep 29, 2023 at 10:30 AM Christian Brabandt <
@.***> wrote:

what is contr-variant?
Consider the following example (from #12965):

class A
endclass
class B extends A
endclass
class C extends B
endclass
In this example, type "C" is a covariant of type "B" and "A" is
contra-variant of type "B".
This matters when overruling methods in an extended class.  The method
return value
type in an extended class can use a covariant type of return value in the
parent class.
The type of method arguments in an extended class can use a contra-variant
type.
For example (continuing the above example):
class Foo
def Doit(p: B): B
return B.new()
enddef
endclass
class Baz extends Foo
def Doit(p: A): C
return C.new()
enddef
endclass
The Doit() method in class Foo uses "B" as the argument type and "B" as the
return type.
The Doit() method in class Baz uses "A" as the argument type and "C" as the
return type.
"A" is a contra-variant of "B" and "C" is a co-variant of "B".
A detailed explanation about this is in
https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
.
I wanted to follow the model used in the Dart language (
https://medium.com/dartlang/dart-declaration-site-variance-5c0e9c5f18a5).
Regards,
Yegappan

On Fri, Sep 29, 2023 at 12:50 PM vim-dev ML @.***>
wrote:

Hi Christian,
On Fri, Sep 29, 2023 at 10:30 AM Christian Brabandt <
@.***> wrote:

what is contr-variant?
Consider the following example (from #12965):

class A
endclass
class B extends A
endclass
class C extends B
endclass
In this example, type "C" is a covariant of type "B" and "A" is
contra-variant of type "B".
This matters when overruling methods in an extended class. The method
return value
type in an extended class can use a covariant type of return value in the
parent class.
The type of method arguments in an extended class can use a contra-variant
type.
For example (continuing the above example):
class Foo
def Doit(p: B): B
return B.new()
enddef
endclass
class Baz extends Foo
def Doit(p: A): C
return C.new()
enddef
endclass
The Doit() method in class Foo uses "B" as the argument type and "B" as
the
return type.
The Doit() method in class Baz uses "A" as the argument type and "C" as
the
return type.
"A" is a contra-variant of "B" and "C" is a co-variant of "B".
A detailed explanation about this is in
https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
..
I wanted to follow the model used in the Dart language (
https://medium.com/dartlang/dart-declaration-site-variance-5c0e9c5f18a5).

Currently the type of the method arguments and return value can be a
covariant type
of the ones in the parent class method.

Yegappan

Shades of Java's PECS.
There were two ways to deal with #12965.

Adjust the parser to meet the spec.
Change the spec and various implementation things.

Doing 1. is backwards compatible with future implementation of the requested features.
Doing 2. seems rushed.
My first look, not running any code, this change seems to add little, at the expense of conceptual complexity. I was in the process of manually working through some things related to this, so I could make a comment, when it got checked in (seemed pretty quick for a change that wasn't understood).
What's to rush to add new features that have not been debated?

Hi,
On Fri, Sep 29, 2023 at 2:51 PM errael @.***> wrote:

Shades of Java's PECS.
There were two ways to deal with #12965
https://github.com/vim/vim/issues/12965.

Adjust the parser to meet the spec.

The spec currently states that:
Object methods of the base class can be overruled. The signature (arguments,
argument types and return type) must be exactly the same.
The current implementation doesn't match with this spec.   If we follow
this spec,
then the type in an overruled method cannot be a covariant or
contra-variant.
I think that will be limiting, as the method in an extended class may want
to return
a covariant type.

Change the spec and various implementation things.

Doing 1. is backwards compatible with future implementation of the
requested features.
Doing 2. seems rushed.
My first look, not running any code, this change seems to add little, at
the expense of conceptual complexity. I was in the process of manually
working through some things related to this, so I could make a comment,
when it got checked in (seemed pretty quick for a change that wasn't
understood).

Let me know if you see any cases that will break with the latest changs.

What's to rush to add new features that have not been debated?

No rush.  I didn't see any objection to the proposal in
https://github.com/vim/vim/issues/12965
and this is closer to the Dart spec.
As the changes are minimal to support this, if needed, we can make
adjustments.
Regards,
Yegappan

Shades of Java's PECS.
There were two ways to deal with #12965
1. Adjust the parser to meet the spec.

The spec currently states that:
Object methods of the base class can be overruled. The signature (arguments,
argument types and return type) must be exactly the same.
The current implementation doesn't match with this spec.

Right, I mentioned that and one option was to meet the spec. With this change,
even with the rewording of the spec, it can be argued (but not definitively)
that the changed spec is violated. Note the original spec says
Object methods of the base class can be overruled.  The signature (arguments,
argument types and return type) must be exactly the same.  The method of the
base class can be called by prefixing "super.".

The new spec still has the prefixing "super." phrase.
When I read base class can be called by prefixing "super.", in the context
of The signature ... must be exactly the same, it`s easy to interpret this
as meaning, using the current example, that
class Bar extends Foo
  def Doit(p: B): B
    return super.Doit(p)
  enddef
endclass

will compile and run OK.  But if covariant and/or contravariant types are used
you'll easily get compile or runtime error, if super. is used in this fashion.

If we follow this spec,
then the type in an overruled method cannot be a covariant or
contra-variant.
I think that will be limiting, as the method in an extended class may want
to return
a covariant type.

I strongly agree that a method may want to return a covariant type.
Nothing in the previous spec (before this change) prevents returning a
covariant type. In fact, in the following example notice the output
object<C>
object<C>

Both Foo.Doit and Bar.Doit return the covariant type C.
vim9script

class A
endclass

class B extends A
endclass

class C extends B
endclass

class Foo
  def Doit(p: B): B
    return C.new()
  enddef
endclass

class Bar extends Foo
  def Doit(p: B): B
    return C.new()
  enddef
endclass

echo typename(Foo.new().Doit(C.new()))
echo typename(Bar.new().Doit(C.new()))

2. Change the spec and various implementation things.

Doing 1. is backwards compatible with future implementation of the
requested features.
Doing 2. seems rushed.
My first look, not running any code, this change seems to add little, at
the expense of conceptual complexity. I was in the process of manually
working through some things related to this, so I could make a comment,
when it got checked in (seemed pretty quick for a change that wasn't
understood).

Let me know if you see any cases that will break with the latest changs.

What's to rush to add new features that have not been debated?

No rush.  I didn't see any objection to the proposal in #12965

And there was no support either; it was not debated. My excuse, not a great one,
is that I was focused on getting 9.1 release to meet spec and uncover any
things that would violate backwards compatibility.

and this is closer to the Dart spec.

So what? The original intent was for simplicity, AFAICT. There was a recent
case, accessing statics, where Dart is simple and was chosen.
In this case, Dart is more complex and doesn't give an advantage, IMHO.
You can already return covariant types with out this change. And adding
contravariant parameter types is confusing and I don't see what it gets you.
I don't see any advantage to making this spec change now, and some disadvantage.
If there's a need, it can be added post 9.1, but not the other way around.

As the changes are minimal to support this, if needed, we can make
adjustments.

Is that really three variations of variance in about as many days?  I can't keep up.
This is a foundational principle of OOP.  If we can't start from a common understanding of reality these threads aren't very useful.
Referencing other languages is becoming counter-productive.  I've also done this in past discussions because Bram had done so in the documentation and as a short-hand but it's becoming distracting.  Dart, in isolation, is not relevant here; it's not a pioneer of contravariance.
However, for general reference, TypeScript supports bivariance with a compiler flag for strict contravariance and Dart supports contravariance with a keyword for covariance.  The following languages, OTTOMH, all support contravariance - Python, PHP, Kotlin, Scala, Swift, Flow and others.  Java doesn't support it, presumably because it doesn't play nicely with their overloading implementation.
I'm not sure what parallel there is with the static members implementation and discussion.  The initial implementation was "weird" and it was made sane.  The functionality wasn't hobbled in some nebulous pursuit of simplicity.  This latest change makes the type system less expressive.  Given the state of play has existed for forty years I'm not sure what is going to be illuminated by deferring a decision.
Anyway, my initial report was primarily interested in having the unsound covariance resolved which it has been, thanks.

Is that really three variations of variance in about as many days? I can't keep up.
This is a foundational principle of OOP. If we can't start from a common understanding of reality these threads aren't very useful.

Yes and Yes. Hopefully we're just talking about implementation issues.

Referencing other languages is becoming counter-productive. I've also done this in past discussions because Bram had done so in the documentation and as a short-hand but it's becoming distracting. Dart, in isolation, is not relevant here; it's not a pioneer of contravariance.
However, for general reference, TypeScript supports bivariance with a compiler flag for strict contravariance and Dart supports contravariance with a keyword for covariance. The following languages, OTTOMH, all support contravariance - Python, PHP, Kotlin, Scala, Swift, Flow and others. Java doesn't support it, presumably because it doesn't play nicely with their overloading implementation.
I'm not sure what parallel there is with the static members implementation and discussion. The initial implementation was "weird" and it was made sane.

Exactly, the spec was never finished regarding statics, and a sane implementation was required. The point of mentioning that, is that the spec was unfinished and most agreed the implementation was broken.
This discussion, Xvariant behavior, is very different; it's about a spec change. I don't think Bram accidentally wrote, back in February
The signature (arguments, argument types and return type) must be exactly the same.

That sentence now appears twice in the spec. Implementing that in no way constrains future development, AFAICT. In fact, I think it provides maximum flexibility going forward. Less is more.

The functionality wasn't hobbled in some nebulous pursuit of simplicity.

I'm not sure to what this is referring. In general I agree with the implied goal.

This latest change makes the type system less expressive.

True. But, from what I've read, the type system isn't finished. I hope the type system is extended in a well thought out and coordinated fashion, rather than piecemeal (like Java?).

Given the state of play has existed for forty years I'm not sure what is going to be illuminated by deferring a decision.

Syntax. You've pointed out that there are several ways the concept can be expressed in a language. And, at least in Java, it's not supported in method signatures at all; but the concept is intimate with Java generics (PECS). The type system needs time and effort, and I would think Xvariance needs to be part of that.

Anyway, my initial report was primarily interested in having the unsound covariance resolved which it has been, thanks.

Agree. When I saw the initial report, I figured another spec violation to fix (and with suggestions for the future); not a new feature at this late date. Personally, I think every spec change requires discussion and burn in time; there are sometimes unintended consequences or implications.
Every time the spec is changed, the release date must be pushed out to insure reliability.
I'd like to see vim9.1 release soon, maybe that's a point of disagreement.

Sorry, I don't think I was notified of this reply but noticed it when checking the history of this general issue.  A day late and a dollar short...my usual style.

This discussion, Xvariant behavior, is very different; it's about a spec change. I don't think Bram accidentally wrote, back in February
The signature (arguments, argument types and return type) must be exactly the same.

That sentence now appears twice in the spec. Implementing that in no way constrains future development, AFAICT. In fact, I think it provides maximum flexibility going forward. Less is more.

In my opinion it's a pre-alpha design/help document covering a first pass partial implementation.  We can't divine how this would otherwise have turned out and I think we should just attempt to develop the best language possible.  Bram was actually pretty flexible and, for example, reworked closures after the 9.0 release.
The first line of the "spec" states: "NOTE - This is not finished yet, anything can still change! - NOTE"
It's leveraged and ignored at will, and as has come to pass again, it's been changed with the resolution to this issue.

Given the state of play has existed for forty years I'm not sure what is going to be illuminated by deferring a decision.

Syntax. You've pointed out that there are several ways the concept can be expressed in a language. And, at least in Java, it's not supported in method signatures at all; but the concept is intimate with Java generics (PECS). The type system needs time and effort, and I would think Xvariance needs to be part of that.

I wasn't proposing any syntax changes.  This is a simple type-checking.

In my opinion [the spec is] a pre-alpha

I'm not sure I'd go that far, I could see alpha, if you think of the eventual vim9.1 release as a beta, then anything implemented in the release should be beta. Haven't heard much about release targets lately (maybe some implicit hints). But I've also hear that vim9.1 class code is supposed to be compatible with the releases after that; I don't see how that's reconciled with an alpha or beta spec (for what's implemented).

we should just attempt to develop the best language possible

I agree. I guess the basic question/issue is whether or not we can release something that is compatible with future releases.

Given the state of play has existed for forty years I'm not sure what is going to be illuminated by deferring a decision.

Syntax. You've pointed out that there are several ways the concept can be expressed in a language. And, at least in Java, it's not supported in method signatures at all; but the concept is intimate with Java generics (PECS). The type system needs time and effort, and I would think Xvariance needs to be part of that.

I wasn't proposing any syntax changes. This is a simple type-checking.

What I meant by that, assuming there's evolution in the type system, is that for specifying contra-variant parameters it may be desirable to have some syntax. I think some language uses in:/out: for example (reminds me of Java's extends/super).
Saying that parameters can be contra-variant feels like a big change that could cause problems. And it would be good to know how the type system works with future stuff, there's generics in the todo list. Unless someone can say with confidence that "there's no problems and it all work" with suggestions on how it fits in with future development... If a vim9.1 release can be delayed, I'm not sure for how long, then these questions could probably be resolved before it's released.
I'm not saying contra-variant parameters shouldn't be handled. I'm asking if they need to be handled right now? What's the downside if they are not?


add Rails generators

Hello and thanks for making Blueprinter.
I made this for https://github.com/procore/blueprinter/issues/121
Would YARD doc additions be needed or is in this case the  rails g blueprinter:blueprint --help output sufficient?

ok, I'll fix for old rubies

Hey, what's the story with this?

@jesster2k10 I've been offline for a couple weeks, and I don't know that there is much of a story to tell but if you are still interested you can always bundle with my fork and play with the generator this would add. It can introspect on the ActiveRecord model you pass it or just take command flags to write a blueprinter for the model.

@philipqnguyen I believe I've addressed all your change requests. Thanks for your patience.


Unable to resize panels in Electron

The following works fine in v0.0.53 but in  v0.0.54 panels are locked to the defaultSize and cannot be resized.
import { Panel, PanelGroup } from 'react-resizable-panels';
import ResizeHandle from './components/ResizeHandle';

function App() {
  return (
    <>
      <PanelGroup direction="horizontal">
        <Panel defaultSize={50} minSize={10} collapsible={true}>Test Panel 1</Panel>
        <ResizeHandle/>
        <Panel defaultSize={50} minSize={10} collapsible={true}>Test Panel 2</Panel>
      </PanelGroup>
    </>
  );
}

Bug reports need a full repro. You didn't share the ResizeHandle component, so I can't rule out that it's correctly wrapping the PanelResizeHandle component from this library.
Here are Code Sandbox links I put together:

repro w/ 0.0.53
[repro .w/ 0.0.54[(https://codesandbox.io/s/frosty-goldstine-n55mc7)

Both versiopns seem to work fine for me.

By the way, the difference between 0.0.53 and 0.0.54 bundles is very minimal– mostly comments, and one switch to use a package export condition for the is-browser check:
2a3,4
> const isBrowser = typeof window !== "undefined";
>
24,25c26
< const canUseEffectHooks = !!(typeof window !== "undefined" && typeof window.document !== "undefined" && typeof window.document.createElement !== "undefined");
< const useIsomorphicLayoutEffect = canUseEffectHooks ? useLayoutEffect : () => {};
---
> const useIsomorphicLayoutEffect = isBrowser ? useLayoutEffect : () => {};
39,42d39
<
< // Workaround for Parcel scope hoisting (which renames objects/functions).
< // Casting to :any is required to avoid corrupting the generated TypeScript types.
< // See github.com/parcel-bundler/parcel/issues/8724
109a107
>     idWasAutoGenerated: idFromProps == null,
120a119
>     panelDataRef.current.idWasAutoGenerated = idFromProps == null;
160,163d158
<
< // Workaround for Parcel scope hoisting (which renames objects/functions).
< // Casting to :any is required to avoid corrupting the generated TypeScript types.
< // See github.com/parcel-bundler/parcel/issues/8724
823a819,823
>   useRef({
>     didLogDefaultSizeWarning: false,
>     didLogIdAndOrderWarning: false,
>     prevPanelIds: []
>   });
1271,1274d1270
<
< // Workaround for Parcel scope hoisting (which renames objects/functions).
< // Casting to :any is required to avoid corrupting the generated TypeScript types.
< // See github.com/parcel-bundler/parcel/issues/8724
1410,1413d1405
<
< // Workaround for Parcel scope hoisting (which renames objects/functions).
< // Casting to :any is required to avoid corrupting the generated TypeScript types.
< // See github.com/parcel-bundler/parcel/issues/8724

My guess is, if anything is causing weirdness for you with Electron, it must be the is-browser conditional– which maybe points to your project's build setup?

Hmm. I can't work out why the check would fail. My first thought was maybe somehow this check was being performed in preload causing window to be undefined. But both checking if window is present and wrapping the components in React.lazy yielded the same results.
The ResizeHandle just applies a bg colour similar to your example.
When I get a mo, I'll try to reproduce in a clean repo and reopen if necessary.
Thanks for pointing out the potential problems.

Hey @bvaughn I had a similar issue with a fresh electron-forge project (with electron version 27.0.1 using the vite typescript template). It seems some of the default styles aren't applied and the PanelResizeHandle has no width defined (also there's no icon). I'd have to dig deeper to figure out what's the proper fix but just adding a custom style where the width and a background color is defined makes the element visible and also the entire PanelGroup resizable.
Example code:
    <PanelGroup direction="horizontal">
      <Panel defaultSize={20}>Panel 1</Panel>
      <PanelResizeHandle style={{ width: "10px", backgroundColor: "blue" }} />
      <Panel defaultSize={50}>
        <Text>Well hello</Text>
        <Button>Click</Button>
      </Panel>
      <PanelResizeHandle />
      <Panel defaultSize={30}>Panel 3</Panel>
    </PanelGroup>```

Thanks for that added context!


How to limit codeScanner to View height and width❓

Question
Let's say the Camera has 200 width and 200 height and the device height and width is 600 and 400.
Currently, it's scanning QRs out of view, I tried to implement a boundary check with onLayout and a few more tricks but it varies so much between devices (iOS and Android, orientation...) that it works on most but it doesn't on a few that I still need to support.
Any tips on doing this in the JS side in a more elegant way without using resizeMode='contain'?
What I tried
No response
VisionCamera Version
3.6.4
Additional information

[ ] I am using Expo
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar questions in the issues page as well as in the discussions page and found none.

did you find the solution?

https://react-native-vision-camera.com/docs/api/interfaces/CodeScanner#regionofinterest

What exactly is not working about it?

@SocDario The solution I posted works 90% of the time, but there are a couple of iPhone models which do not properly report the resolution, so I have stopped using it. There is a solution in newer versions of vision camera though.

@spsaucier
Yeah they recently added corners property on scan result, but also as far as I know camera view relative coordinates and not well documented about implementation

You're right that it's not documented well. It does seem to be working everywhere, though. I'll post my new version tomorrow.

@spsaucier
Thanks mate, you are life saver!

@spsaucier
Thanks for example mate, I'll try it out today!

On iOS there's regionOfInterest. Otherwise the Frame has a bounding box. And yes, resizeMode also exists for the preview

This should be re-opened until regionOfInterest is within Android, closing it with that comment is unfair really.

Thank you for your reply JshGrn, if you open a PR to add regionOfInterest to Android I will gladly review and merge it. Otherwise I don't plan on working on this, simply because it is not part of the native Android API and will probably require HUGE efforts to implement this (as we need to resize the Frame ourselves manually, causing additional performance overhead).


[BUG] Private build JARs checked into the tree for BWC tests

Describe the bug
Currently the following JARs are checked into the tree. These are private builds of job-scheduler.

Expected behavior
No private build JARs checked in, fetch from https://aws.oss.sonatype.org/ via a dependency.

As of right now it seems like the snapshot for 1.3.0 isn't available on maven. Reaching out to job-scheduler/infra to make sure that gets updated and then will move our workflow to use a snapshot instead

I see 1.3.0 in https://aws.oss.sonatype.org/#nexus-search;gav~org.opensearch~opensearch~~~~kw,versionexpand

[BUG] Checked in versions of job-scheduler-*-SNAPSHOT.zip #17

Yes, only spi is up to date not job-scheduler. Thanks for closing this one.


Fix automatic restore.

Fix for https://github.com/tmux-plugins/tmux-continuum/issues/57.

Thanks!


Feat: clean up the canary-related resources while canary step's weight and matches were nil

Ⅰ. Describe what this PR does
this PR will clean up the canary-related resources while canary step's weight and matches are nil
Ⅱ. Does this pull request fix one issue?

Ⅲ. Special notes for reviews

Codecov Report

Merging #108 (d0763d6) into master (3165f4e) will increase coverage by 0.01%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master     #108      +/-   ##
==========================================
+ Coverage   45.63%   45.64%   +0.01%
==========================================
  Files          39       39
  Lines        3938     3948      +10
==========================================
+ Hits         1797     1802       +5
- Misses       1843     1846       +3
- Partials      298      300       +2

Flag
Coverage Δ

unittests
45.64% <50.00%> (+0.01%)
:arrow_up:

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

Impacted Files
Coverage Δ

pkg/trafficrouting/manager.go
52.97% <50.00%> (-0.17%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

/lgtm

/lgtm

/approve


cacheDir option added

Added new option to specify the cache directory.

This would need to be supported programmatically too.

Woops, I misread this. Thanks


Optional options

Hi. Thanks for this project.
I wonder if you would be open to a Pull Request that changes most of the parameter types for options to Into<Option<SomeOptions>>. That way any varible that the app wants to specify as a default() options parameter can be specified as None instead of having to spell out SomeOptions::default() every time.
I think it would make the apps that use default options a little more compact and readable.
For example, if we make Connection::connect() look like this:
pub async fn connect<C>(uri: &str, options: C) -> Result<Connection>
where
    C: Into<Option<ConnectionProperties>>,
{
    let options = options.into().unwrap_or_default();
    Connect::connect(uri, options, OwnedTLSConfig::default()).await
}

We could call it like:
let conn = Connection::connect(&addr, None)
    .await
    .expect("connection error");

I'm already working this in a fork and would be happy to send it back here when I'm done.

Why the Into part? It could just be Option without the Into.
I fail to see how None is better than Default::default() (which can be used instead of SomeOptions::default())

The Into part makes it backward compatible with what you already have. It doesn't break the existing applications in that you can still send a variable opts instead of being forced to change parameters to Some(opts).
So in that case None is equivalent to Default::default(). It's 75% fewer characters. Which his maybe silly, but looking at some of the code after None is put in, it does seem more readable overall.
Obviously another option would be to expand the API with different functions, like:
pub async fn connect(uri: &str) -> Result<Connection> { ... }
pub async fn connect_with_options(uri: &str, options: ConnectionProperties) -> Result<Connection> { ... }

...but a lot of the public functions in this library take a number of sets of options, so that doesn't seem like a great idea.

Oh, but to be clear, if the parameter takes Into<option<SomeOptions>> then the application can use any of these methods that we discussed. So it's left up to the user to decide which they prefer. The library is most flexible and doesn't dictate one way or another.
All of this would compile...
let conn = Connection::connect(&addr, None).await?;

let conn = Connection::connect(&addr, Default::default()).await?;

let conn = Connection::connect(&addr, ConnectionProperties::default()).await?;

let props = ConnectionProperties::default().with_connection_name("pubsub-example".into());
let conn = Connection::connect(&addr, props).await?;

Does Default::default() here end up being None, or Some(Default::default()) ?

If you pass in a value, you get the value. So if you explicitly pass in Default::default() then you get the defaults. But if you pass in None you also get the defaults. So the None value means "nothing more than the defaults".
Again, this is mainly to make the application code a little more readable, especially in a library like this where a lot of functions take multiple sets of options, and apps often just uses the defaults.
From my MQTT library, you might implement it like:
pub fn disconnect<T>(&self, opts: T) -> Token
where
    T: Into<Option<DisconnectOptions>>,
{
    let opts = opts.into().unwrap_or_default();

So if it's Some(val), you just unwrap it, and if it's None you use the defaults.

To sum things up:

The only change in code that uses lapin is that you can use None instead of Default::default() and everything else works like before
I understand None can be more convenient to use than Default::default(), but it's slightly less explicit, right? In the end, there will not be "no options" used, the default options will be used
It makes the documentation harder to read, it just adds extra stuff that should just be hidden imo

Overall I don't think the tiny benefit is worth the added complexity added to the documentation


Where() statements never resolve from cache

Summary of the issue
I noticed that EFCore Where() statements never get pulled from the cache.  Is this intentional?  When I change the query to be a First() statement, it will pull from the cache just fine.  I simply copy and pasted the install instructions to register the services for EFSecondLevelCache.Core.  Do let me know if you need any other information.
Environment
EFSecondLevelCache.Core v1.6.4
Asp.Net Core 2.2
Windows 10
Visual Studio 2017

Example code/Steps to reproduce:
using System.Linq;
using System.Collections.Generic;
using Microsoft.AspNetCore.Mvc;
using EFSecondLevelCache.Core;
using My.Models;

namespace My.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class BlogCommentsController : ControllerBase
    {
        private readonly MyContext _context;

        public BlogCommentsController(MyContext context)
        {
            _context = context;
        }

        [HttpGet("{id}")]
        public ActionResult<List<BlogComment>> GetBlogComment(int id)
        {
	    // This is expected to resolve from the cache, but it always queries the database
            var blogComment = _context.BlogComments.Cacheable().Where(x => x.BlogId == id).ToList();

            // This does pull from the cache
            var singleComment = _context.BlogComments.Cacheable().First(x => x.BlogId == id);

            return blogComment;
        }
    }
}

Output:
When tracing transactions for my MS-SQL database, I see the following query produced every time I hit the GetBlogComment(int id) action above.
[SELECT [x].[Id], [x].[AuthorUserId], [x].[BlogId], [x].[Content]
FROM [BlogComments] AS [x]
WHERE [x].[BlogId] = @__context_Source_Id_0](url)

Again, when changing it to First() I do not see my database getting hit, implying that it pulled from the cache.

You should put the Cacheable() before the materialization part or ToList() here.
var blogComments = _context.BlogComments.Where(x => x.BlogId == id).Cacheable().ToList();

Ah!  Yes that fixed it.  Thanks for this wonderful library.  It's very straight forward to use.  ^_^
You can go ahead and close this issue.


nits: a couple small tweaks while merging upstream

A couple small tweaks made while synchronizing with Node.js repository.

small tweak to wording for greedy args (thought it read clearer).
received warning from linter for capital Object in JSDoc.

An aside: with a lot of recent suggestions on the PR, would you like to make those changes upstream and later copy-down to parseArgs? Or make changes here and copy-up? (Whatever is easiest.)

An aside: with a lot of recent suggestions on the node PR, would you like to make those changes upstream and later copy-down to parseArgs? Or make changes here and copy-up? (Whatever is easiest.)

I'll just make a new PR with the upstream changes.


YDefsLoader: add variable interpolation support

the default YAML format does not support variable interpolation e.g. referring to another key's value, but it's possible to add it with the help of 'add_constructorandadd_implicit_resolver`.
Example usage:
c: cool
x:
  y: abcdefg
  z: hijklmno
  t: ${c}

foo: ${x.y}${x.z} ${x.t}
# foo's value would be `abcdefghijklmno cool`

This is interesting. one bit of initial feedback i'd have is that it is provide an alternate way to define variables that doesn't behave in the same way e.g. with the existing vars: you can set a variable to a literal, property, factory etc. If we could somehow meld the two that would be cool but I think having two independent ways of doing this might not be a benefit. Thoughts?

This is interesting. one bit of initial feedback i'd have is that it is providing an alternate way to define variables that doesn't behave in the same way e.g. with the existing vars: you can set a variable to a literal, property, factory etc. If we could somehow meld the two that would be cool but I think having two independent ways of doing this might not be a benefit. Thoughts?

I feel the same way as well. The proposition value of this patch is not to provide an alternate way to bring properties or replace any other run-time interpreted values, on the contrary, it aims to complement it. I'll experiment with the existing scenarios and see how these two will behave together.

Closing this in favor of https://github.com/canonical/hotsos/pull/913


Adding a graphql-dgs-codegen-client-utils

What
This commit adds a new module, the graphql-dgs-codegen-client-utils.
The intention of the module is to offer classes, and other artifacts, that can aide developers complement
the code generated by codegen. The plugin, if configured, will add the
artifacts automatically to the compileClasspath scope.
As a Developer
As a Developer you will have to be explicit on adding the client-utils
to your classpath via the plugin. To do so you will have to set the
codegen.enableUtils flag to true as follows.
codegen.enableUtils = true

or
codegen {
    enableUtils = true
}

THis needs a better name - these classes aren't utils, they are API classes that the generated code depends on. If you don't have these classes, it won't compile right?
And shouldn't this be on by default if client generation is enabled?

The PR also seems to include a bunch of reformatting :(

The PR also seems to include a bunch of reformatting :(

I did had to refactor the build.gradle files. The root build.gradle now shares configuration across the modules. I'm failing to see pure reformatting changes. Could you help me identify them so I can remove them.

THis needs a better name - these classes aren't utils, they are API classes that the generated code depends on. If you don't have these classes, it won't compile right?
And shouldn't this be on by default if client generation is enabled?

I agree that names are not ideal, probably we could use graphql-dgs-codegen-client-core instead. I also agree that folks will always need to use the module. Will flip to always on.

Steps to folllow.

Release the DGS Framework 4.3.0-rc.6 or a later version.
Merge this PR.
Finish migrating the codgen code out of the DGS Framework by merging this other PR.


Alarm volume

Added an alarm volume entity.
I've set up it as an entity instead of an attribute, as suggested in #193 so the value can be modified easily through a number entity.

Still doing some tests to check if everything is set up correctly

There is some pylint error. Probably just disable duplicate-code check in pyproject.toml.
Also I suggest using rebase instead of merge.

This needs to be documented in README.

There is a merge conflict which needs to be resolved.

The indices are shifted a bit 🙂

OMG this check is driving me crazy, so picky 😂

@ArnyminerZ, are you using pre-commit hooks locally (they run the same checks, but locally on your computer)? They can really help to quickly scan the code even before committing it :)

@ArnyminerZ, are you using pre-commit hooks locally (they run the same checks, but locally on your computer)?

Yes I do, but my WSL machine is giving some problems, so some of them had to be manually fixed.


Ethernet routing?

Given the single RJ45 port on rpi 4 and 5, how do you deploy this?  Are you using wifi only with the pi as a wifi access point, or do you have some add-on board that adds additional RJ45 ports, or a USB to ethernet adapter, or some sort of VLAN setup?  Can you provide any details, especially re hardware that supports your VLAN if it's that?  I'm not a networking expert but I'll probably understand if you explain in concrete ELI5 terms: "I have this hardware, x is plugged into y, y runs this software" :-)
Motivation for my question: I'm looking for something simple like pinewall (no UI, hackable through simple nftables etc. configuration, easy to keep updated) but want to avoid adding yet another operating system instance to manage in the form of extra hardware to support a VLAN!  So I wonder if for example I might find it workable to get away with using the pi's wifi as AP, and USB hardware as 2nd ethernet port, without causing myself other problems - e.g. limiting wifi range or ethernet bandwidth too drastically?  (I also wonder how often you update your microsd image to track security updates, but that takes me off the focus of my question)

Hi @jjlee
Yep, this setup definitely works just fine for ethernet routing despite the single port on the Pi. I have the regular single-ethernet port version of the Pi 4 plugged in via a single ethernet cable to a relatively cheap switch that's VLAN-aware.
I've got one of these switches, but any switch that's got an interface you can configure VLANs with ought to work fine.
I configure it so that my Pi is plugged into a port on the switch that supports all of the VLANs, and I plug my modem into another port on the switch which is configured to only support one specific VLAN.
In /etc/network/configs I do some magic to bring up a VLAN interface without giving it an IP address and then run pon to dial my PPPoE connection:
auto eth0
iface eth0 inet static
	address <IP_ADDRESS>
	netmask <IP_ADDRESS>
	post-up /sbin/ip link add link eth0 name vlan888 type vlan id 888 || true
	post-up /sbin/ip link set vlan888 up
	post-up /usr/bin/pon

Then I just tell my PPPoE config to expect that the upstream ISP modem is on that specific VLAN when dialing the connection:
plugin pppoe.so vlan888

Even with the single port, this works well enough for me since I've only got VDSL. I'm not quite sure how it would fare once you start trying to route faster connections. There's a few boards you can get to put a Pi 4 Compute Module on which will add a second ethernet controller but I've not tested those and I'm not sure how good they are.
I don't use the Pi itself as a Wi-Fi AP, but I think it's definitely something you could do if you really wanted. I'm not sure if it'd be a good idea since the range isn't going to be great and it's definitely more optimised to be a client chip than an AP chip, but it's definitely something that could be done. I just have a relatively cheap TP-Link WiFi 5 AP plugged into one of the other ports on the switch though.
In terms of updating the microSD, since I'm building this in GitLab CI/CD, it's easy enough there to configure a build schedule. I have it set to build the image weekly at the moment. If I get the chance, I can just write the new image to my second microSD and then slot it in to update the system. If something breaks, I can just put the previous card back in and roll back immediately. It's maybe not ideal, but I've found that there's relatively little change in the system really when it's based on such a small number of packages.
Hopefully this helps! :smile: It's probably not a deployment method used by many, but it's worked well for me for a few years now! If you get stuck I'll try and help if I can. Good luck!
Oh and about:

I'm not a networking expert

I think you might find that if you start the journey of building something like this and end up writing an entire multi-VLAN nftables config from scratch, you'll probably end up as an "expert" faster than you think :laughing:

Hopefully this helps!

Yes it does, thank you!  I've never owned a home VLAN switch and it's helpful to know how your setup works together.
I really like the simplicity and gitlab is easy for me to deal with.

I think you might find that if you start the journey of building something like this and end up writing an entire multi-VLAN nftables config from scratch, you'll probably end up as an "expert" faster than you think 😆

I am suitably warned ;-)
Honestly if I could find an "appliance" to rent or buy that seemed trustworthy I would, but the "trustworthy" part seems difficult.    Since the point of this for me is to put more trust in upstream boxes, if I'm moving from laptop/desktop OSs I somewhat understand to OSs in black boxes I don't understand and never get updated, that seems to defeat the point, if that makes sense.
So pinewall is appealing -- except just the rPi hardware doesn't quite hit what's needed to stand alone perhaps.  I once tried a cheap x86 box with multiple RJ45, though the BIOS was a problem (boot was a pain) and power consumption higher and from memory it didn't function at all as AP either.  I would go back to OpenWRT or similar but I have bad memories of becoming even more of an expert there than I think I would with pinewall!  (e.g. complicated firewall setup entangled with basic functionality, a new packaging system to learn, ...)  I think what I really want is to run something like pinewall (simple and based on a familiar linux distribution) on slightly fancier hardware, if I knew what that was.  The search continues...

If it helps, it’s also possible to run pinewall on a raspberry pi CM4 on a router carrier board (such as the DF-Robot IoT router board) which gives 2 PCI-E nics. I ran this setup for a while before switching back to x86 hardware as I upgraded my line. There’s no reason pinewall can’t be built for x86 hardware either, and thankfully this repo makes that easy. N100/N200 mini-PCs with 4x2.5G nics can be found for slightly more the the price of an RPi, with a case and PSU. Serverthehome has some decent reviews of the hardware.


Add Logging for Request/Response. Implement Contact Properties & Group API calls

Fixed find_by_email to behave according to the documentation. Implemented batch results.
Added request/response logging
Implemented ContactProperties APIs
Dump/Restore rake tasks to backup schema changes and make it easy to apply changes from one environment to another.

Any updates on this, is @adimichele still working with this?

Not that I’m aware of. I haven’t seen any activity other than mine. You’re welcome to fork my fork :-).

On Jun 10, 2016, at 6:15 PM, Dan M<EMAIL_ADDRESS>wrote:
Any updates on this, is @adimichele https://github.com/adimichele still working with this?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/adimichele/hubspot-ruby/pull/31#issuecomment-225328323, or mute the thread https://github.com/notifications/unsubscribe/AAPVNZxbOg-eDhghsMZ5igSyTGcoe462ks5qKgwZgaJpZM4G-PL0.

We stopped using Hubspot and I stopped maintaining this years ago. Would either of you like to take over?

thanks for the fast reply @adimichele....  @srgoldman looks like you have put some time in with this, you should take it if you want.  If not I would be willing, as I will be working with this quite a bit in the future....  Also @adimichele was there problems with hubspot?

@dan987 - I don't have a strong preference. I've been adding features as necessary but it's not particularly active development for us right now. It sounds like you have a more urgent need and would therefore be a more motivated custodian. I'm happy to let you have it and continue to contribute as needed. I actually have additional changes that I hadn't yet put into a PR which enable the gem to register its rake tasks in an including rails app. And @adimichele - A belated thanks for the initial groundwork which made my life much easier!

@adimichele yes thank you for this, sounds like a pass from @srgoldman.  I would be happy to take over as needed.

FYI - I’m doing some work on the Forms API at the moment, upgrading it to V2.
Seth Goldman
FlashFunders Engineering
www.flashfunders.com http://www.flashfunders.com/
<EMAIL_ADDRESS>310-729-4506

On Jun 16, 2016, at 2:43 PM, Dan M<EMAIL_ADDRESS>wrote:
@adimichele https://github.com/adimichele yes thank you for this, sounds like a pass from @srgoldman https://github.com/srgoldman. I would be happy to take over as needed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/adimichele/hubspot-ruby/pull/31#issuecomment-226622782, or mute the thread https://github.com/notifications/unsubscribe/AAPVNeJAAHtR-uJLyLi4wLi67b_N1M8Dks5qMcORgaJpZM4G-PL0.

Cool! @dan987 I made you a collaborator so you should have push perms now. I need to make you an owner on RubyGems as well - which email address would you like me to use for that?


Document known issue for incorrect drops in Diego Capacity graphs

[#165229915]
Signed-off-by: Melena Suliteanu<EMAIL_ADDRESS>

Thanks, @iplay88keys!


Consider creating a Spectrum chat community?

https://spectrum.chat
I am so so so stoked to see this project coming to life. THANK YOU!
Was wondering if it was worth creating a community channel for general discussion?

Hi! Glad you’re interested in the project. I do have a Slack channel that can be used for discussion: HTTPChat

I did make one - https://spectrum.chat/takenote.


cards

i have changed the alignment of the card description and hovering effect of add to wishlist.

2 nd pic is taken from the phone

Please resolve conflicts also add issue no. which issue you are solving like # issue_no

Please avoid making use of "Format doc" in vs code Just to Increase the no. of lines changed.
As I can below are the only change.

Please make a new PR and make the changes in required lines


V2 Dev migration applications to the Prod V1 data dump

While the migration system now applies successfully to a schema-only dump of the prod db (https://github.com/UW-Macrostrat/macrostrat/issues/70), several new issues arise when applying to a data dump:
macrostrat-core-v2
UPDATE macrostrat.strat_names SET ref_id = NULL WHERE ref_id = 0;

null value in column "ref_id" of relation "strat_names" violates not-null constraint

This is already noted as causing an error

ALTER TABLE macrostrat.cols
	ADD CONSTRAINT cols_project_fk  FOREIGN KEY (project_id) REFERENCES macrostrat.projects(id) ON DELETE CASCADE;

insert or update on table "cols" violates foreign key constraint "cols_project_fk"
DETAIL:  Key (project_id)=(5) is not present in table "projects".

This is due to the projects table being empty in the prod schema. We will need to complete the mariadb dump first

UPDATE macrostrat.col_groups cg SET project_id = c.project_id FROM macrostrat.cols c WHERE c.col_group_id = cg.id;

permission denied for schema macrostrat
LINE 1: SELECT 1 FROM ONLY "macrostrat"."projects" x WHERE "id" OPER...
                           ^
QUERY:  SELECT 1 FROM ONLY "macrostrat"."projects" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR KEY SHARE OF x

More research required for this one

partition-maps
ALTER TABLE maps.lines ADD CONSTRAINT maps_lines_geom_check CHECK (maps.lines_geom_is_valid(geom));
check constraint "maps_lines_geom_check" of relation "lines_large" is violated by some row

More research required for this one

partition-carto
ALTER TABLE carto.lines ATTACH PARTITION carto.lines_large FOR VALUES IN ('large');
insert or update on table "lines_large" violates foreign key constraint "lines_source_id_fkey"
DETAIL:  Key (source_id)=(145) is not present in table "sources".

Missing entity with id=145 in maps.sources

ALTER TABLE carto.polygons ADD CONSTRAINT polygons_pkey PRIMARY KEY (map_id, scale);
could not create unique index "polygons_tiny_pkey"
DETAIL:  Key (map_id, scale)=(3189765, tiny) is duplicated.

Duplicate primary key

I have made some "ad hoc migrations" that solve some of these data issues. In particular the "Carto" rows being duplicated is one we have solved previously.

I was able to resolve the following issues with a combination of the ad-hoc migrations and borrowing missing data from dev:
macrostrat-core-v2
ALTER TABLE macrostrat.cols
	ADD CONSTRAINT cols_project_fk  FOREIGN KEY (project_id) REFERENCES macrostrat.projects(id) ON DELETE CASCADE;

Can be fixed by importing a dump of the "macrostrat.projects" from dev

partition-carto
ALTER TABLE carto.lines ATTACH PARTITION carto.lines_large FOR VALUES IN ('large');
insert or update on table "lines_large" violates foreign key constraint "lines_source_id_fkey"

Can be fixed by copying slug with id 145 ("unknown slug") from dev to prod

ALTER TABLE carto.lines ATTACH PARTITION carto.lines_large FOR VALUES IN ('large');
insert or update on table "lines_large" violates foreign key constraint "lines_source_id_fkey"

Can be fixed by running ad-hoc migration carto-rebuild.sql

partition-maps
ALTER TABLE carto.polygons ADD CONSTRAINT polygons_pkey PRIMARY KEY (map_id, scale);
could not create unique index "polygons_tiny_pkey"

Can be fixed by running carto-rebuild.sql with the following modifications:

diff --git a/cli/macrostrat/cli/ad-hoc-migrations/carto-rebuild.sql b/cli/macrostrat/cli/ad-hoc-migrations/carto-rebuild.sql
index 9161264..8a74f69 100644
--- a/cli/macrostrat/cli/ad-hoc-migrations/carto-rebuild.sql
+++ b/cli/macrostrat/cli/ad-hoc-migrations/carto-rebuild.sql
@@ -6,6 +6,7 @@ do that until we've removed the duplicates.
 */

 ALTER TABLE carto.polygons ADD COLUMN updated boolean NOT NULL DEFAULT false;
+ALTER TABLE carto.polygons_large ADD COLUMN updated boolean NOT NULL DEFAULT false;

 INSERT INTO carto.polygons_tiny (map_id, source_id, geom_scale, geom, scale, updated)
@@ -69,4 +70,5 @@ DELETE FROM carto.polygons_large WHERE NOT updated AND map_id IN (SELECT map_id

 /** Once we have reduced duplicate geometries, we can add a unique constraint */
 ALTER TABLE carto.polygons ADD CONSTRAINT polygons_pkey PRIMARY KEY (map_id, scale);
-ALTER TABLE carto.polygons DROP COLUMN updated;
\ No newline at end of file
+ALTER TABLE carto.polygons_large DROP COLUMN updated;
+ALTER TABLE carto.polygons DROP COLUMN updated;


Cloud Build: build bundles with Go 1.21

We need to bump this since our go.mod now has the toolchain directive.
/cc @mresvanis @yevgeny-shnaidman @ybettan

/lgtm

/override operator-upgrade

/override e2e/operator-upgrade


Ignoring fields while using polymorphism

I'm using some classes which all inhertance from RawModel:
class RawModel: Object{
    @objc dynamic var pk: Int = 0
    @objc fileprivate dynamic var id: String = "0"
    @objc dynamic var _resourcetype: String = ""

    // MARK: -Function
    override static func primaryKey() -> String? {
        return "id"
    }

    override class func ignoredProperties() -> [String] {
	var keys: [String] = []

	keys.append("realm")
	return keys
    }

}

If I explicitly ignore one field it will ignore it all classes and database correctly doesn't insert it. But If I want child classes doesn't contain parent fields, this doesn't work and all ignored fields are inserted.
I'm using following function to ignore my desired fields:
override class func ignoredProperties() -> [String] {
        var keys: [String] = []
        let instance = self.init()
        var mirror: Mirror? = Mirror(reflecting: instance).superclassMirror
        repeat {
            guard let m = mirror else{
                return keys
            }
            for case let (label?, _) in m.children {
                if label == "id"{
                    continue
                }
                keys.append(label)
            }
            mirror = m.superclassMirror
        } while mirror != nil

        keys.append("realm")
        return keys
    }

But this doesn't work.
My logs shows that my desired fields are ignored in the program but realm doesn't follow it.
I'm not looking for polymorphism implementation. I'm just looking for a way to tell realm explicitly ignore some fields for me.

}

This is my logs:
BaseModel
["pk", "_resourcetype", "realm"]
Product
["url", "reviewCount", "reviewAverage", "pk", "_resourcetype", "realm"]
File
["title", "price", "isBuy", "url", "reviewCount", "reviewAverage", "pk", "_resourcetype", "realm"]
Realm framework version: 3.13.1
Xcode version: 10.1
iOS/OSX version: 12

@ali-zahedi
Realm parses all models defined in your code at launch. So any property defined at launch will be in the Realm schema. You may be able use ObjectTypes configuration on the realm if you'd like to manage different classes.


Feature designv3

:tada: This PR is included in version 2.7.0-rc.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

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


Will there be a typings file?

Hi,
I'm using your component, but I would like to use it a little bit more typesave.
I'm using typescript: Is there some typedefintion out there for mongoose-paginate(official/inofficial) or are you planning to provide one .d.ts-File?
Thanks!

I don't use TypeScript, maybe typedefinition exists somewhere, I don't know)
I think you can try to create .d.ts file here https://github.com/DefinitelyTyped/DefinitelyTyped. As I see it's repository for TypeScript type definitions

Thanks for your answer, I could even create a .d.ts in my project, but the problem is that I can't get a correct typedefintion for mongoose-paginate up and running. So I have to use an "any" type, which leverages the usage of not well-defined type-definitions. Ok perhaps someone other here has already written a .d.ts-file which works.

@Cyber1000 Yeah that is a problem with typescript. The vast majority of libs does not have a well written external (ambient) type definition, if any at all.
maybe this one can get you started ( you will need mongoose ambient typing )
///<reference path="../mongoose/mongoose.d.ts" />

declare module 'mongoose-paginate' {

  interface IOptions {
    select?: Object | string;
    sort?: Object | string;
    populate?: Array | Object | string;
    lean?: boolean;
    leanWithId?: boolean;
    offset?: number;
    page?: number;
    limit?: number;
  }

  interface IMongoosePaginate {
    (schema: Schema): any;
    paginate(query?: Object, options?: IOptions, callback?: (err: Object, result: any) => any): any;
  }

  const mongoosePaginate: IMongoosePaginate;
  export = mongoosePaginate;
}

@Jokero a lot of IDEs feed themselves with .d.ts files for IntelliSense. WebStorm too, in settings Languages & Frameworks > JavaScript > Libraries.
p.s: i don't use typescript but i do use these typings

The types are here:
https://www.npmjs.com/package/@types/mongoose-paginate

It should be noted that is only works when using PaginateModel instead of Model. Couldnt the types just extend Model?


PWA: Fixing values.yaml for pwa

Change the
icmBaseURL: https://www.example.com
to
icmBaseURL: 'https://pwa-ish-demo.test.intershop.com',

Resolved with https://github.com/intershop/helm-charts/commit/fe500dae7396ac808555a30a6c8ef17be788e23b


Debugging in Visual Studio Code does not work unless you use --legacy-bundling

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Jest debugging in Visual Studio Code does not work unless you use npm install --legacy-bundling.
This was a fun one to track down. I was not able to get Jest to debug properly to work on my primary laptop and, after several hours of mucking with it, I tried my second laptop. It worked! After comparing differences, I noticed npm was way out of date and ultimately I discovered the hack below.
If the current behavior is a bug, please provide the steps to reproduce and either a repl.it demo through https://repl.it/languages/jest or a minimal repository on GitHub that we can yarn install and yarn test.

Download VSCode and install.
Clone my debug-jest-in-vscode repo. It's simply the getting started example but with my VSCode launch config.
Use npm install, put a breakpoint on __tests__/sum-test.js:2, and run.

What I see is, even though I have the sum-test.js file open, a new tab labeled c:\github\debug-jest-in-vscode\__tests__\sum-test.js is opened (note: I cloned to C:\github\debug-jest-in-vscode). If you hover over the tab, the full path it shows is \1000\c:\github\debug-jest-in-vscode\__tests__\sum-test.js. Also, my code is wrapped with ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest){ + }});. The breakpoint is still respected and the program stops in the correct spot; however, neither placing new breakpoints nor editing code in the mystery tab seems to work.
Now, to get it to work:

Delete the node_modules folder entirely.
Use npm install --legacy-bundling, put a breakpoint on __tests__/sum-test.js:2, and run.

Now everything works as expected. Breakpoints cause my program to pause in the original source file, the source file is the same, and I can edit the source file while paused.
What is the expected behavior?
I would expect npm install's --legacy-bundling not to be needed.
Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.
Jest: 18.1.0
Node: 4.6.0
NPM: 4.2.0
OS: Windows 10 Home (Windows_NT ia32 10.0.14393)
Note: I created an issue for VSCode team as well to hopefully get some dialog going.

Maybe you'll find this thread interesting? https://github.com/facebook/jest/issues/1652

Also cc: @orta

Unfortunately, his config doesn't work at all for me:
Debugger listening on port 5858
c:\github\debug-jest-in-vscode\node_modules\.bin\jest:2
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
          ^^^^^^^

SyntaxError: missing ) after argument list
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:373:25)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Module.runMain [as _onTimeout] (module.js:441:10)
    at Timer.listOnTimeout (timers.js:92:15)

I have a feeling that it is because I am working from a Windows machine. I had to switch the second runtimeArgs value to /node_modules/jest/bin/jest.js to get it to run (and got the same result... I have to do npm install --legacy-bundling).
I believe that our configs are largely the same but written in different ways. For example, "stopOnEntry":true just calls node with the --debug-brk flag and setting the program property sets what he has as his second argument. In other words, I'm just using VSCode's shortcuts and letting it handle things. So the differences are I use "--runInBand" vs "-i", I tell node "--nolazy" and use the "development" environment, and I let VSCode determine the port to use. But the --legacy-bundling bug is still present.
At this point, I have it working with:
        {
            "type": "node",
            "request": "launch",
            "name": "Debug Jest",
            "program": "${workspaceRoot}/node_modules/jest/bin/jest.js",
            "args": ["--runInBand"],
            "cwd": "${workspaceRoot}",
            "runtimeArgs": [ "--nolazy" ],
            "env": { "NODE_ENV": "development" }
        }

What I am concerned about is that Jest functions differently with --legacy-bundling vs not. Most NPM users are not going to think to use --legacy-bundling. I ran across this fix by accident. Are you mainly focused on using Yarn and does it default to not flat? I'll reach out to the NPM team and see if there is a way to determine what the causes the difference.

Just did some more playing and found that using npm install --global-style works as well.

Interesting, have you tried yarn too?

I hadn't before, but yes the issue appears when using yarn as well.
I'm still blown away that --global-style made a difference. With only one dependency, it doesn't seem like there would be much of a difference between having Jest's deps in a child folder vs a sibling folder.
I think I'm going to try a different version of Node and see if that changes things. I use 4 because I've been doing a lot of AWS Lambda stuff and they're still stuck on 4 for now. I would expect this to change to 6 soon as LTS for 4 changes to maintenance in April.

Found it!
I contacted NPM and they told me to try moving the module folders one by one and see if I could track down what module was causing the issue. I wrote a program to do this for me and narrowed it down to babel-jest inside of jest-runtime. Now, it works with --legacy-bundling so I had to assume another module was picking it up and changing things as a result. After searching all modules for "babel-jest", only one file had it: jest-config in build/normalize.js.
Now that I had the potential source, I removed the node_modules folder, did npm install the normal way, and confirmed the problem still exists. After several tests, I found that changing line 279 to if(false) fixed everything. So, for whatever reason, setting config.transform to { '^.+\.jsx?$': 'babel-jest' } breaks debugging in VSCode.
This only happens when using npm install without --legacy-bundling or --global-style because normalize.js is doing a weird check for installed modules and finds babel-jest. With the flags, babel-jest is nested in a way that normalize.js cannot find it.
So, anyway... the problem seems to start here.

This is actually expected behaviour for Jest. That's why we advise to install babel-jest next to jest itself when working with Babel, because we support Node 4, which ships with npm 2 resolving dependencies this way. This is not needed in npm 3 and 4 or Yarn, because they flatten dependencies.
Maybe we could warn better about this?

But what you are proposing will break it. I AM using NPM 4 and the expected behavior leads to breakpoints and debugging being broken in VSCode.

So you include jest and babel-jest as "devDependencies" and it doesn't work? I only see jest in your repo.

I tried doing exactly as you say just to double check. Yes, it's still broken. What you are proposing will force it to always be broken. Consistency, yes... but not the desired outcome.
What I've been saying all along is that by NOT flattening, VSCode's debugger will work without issue. Flattening breaks things.

Any thoughts?

FYI - I was having this same issue until I added the following into my jest config "testRegex": "platform/.*\\.test\\.js$"
Once I added that, the debugging started working fine. Stopped on breakpoints in the non-transpiled code.

@orta can you advise on the next steps here? Anything we need to do?

I'm not sure there's anything we can do here TBH, other than recommend people update node if they're having this specific issue.

For anyone interested - I think I have a simple fix for this. I commented on the VS Code issue here: https://github.com/Microsoft/vscode/issues/19566#issuecomment-301254539


Create a local action to test SAMI, LZIFU and S7 at each push

As per title.

Also, fix the currently running tests...

Tests for SAMI have now been implemented. Not implementing tests for LZIFU and S7 for now due to storage limitations.


Added CSV to JSON converter

Developer Checklist

[X] Followed guidelines mentioned in the readme file.
[X] Followed directory structure. (e.g. ProjectName/{USERNAME}/...yourfiles)
[X] Starred ⭐ the Repo (Optional)

Summary
Converter to Convert your csv to Json using webworker
Screenshot

Live Project Link
add a working project link here

@PBJI resolved all the issues you can review it now

@thinkswell this was closed without merge?


chore: Fix MSSQL example add egress security group rule for db to directory services

Description
Domain join fails in the current complete-mssql example.
The security group for the database needs an outbound rule that allows the db to communicate with the directory.
AWS docs:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.html

Note: There are other open PRs that contain fixes for this complete-mssql example to apply successfully outside of this particular issue.
Motivation and Context

Closes #336

Breaking Changes
No
How Has This Been Tested?

[x] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[x] I have tested and validated these changes using one or more of the provided examples/* projects
[x] I have executed pre-commit run -a on my pull request

This PR is included in version 4.5.0 :tada:


Fix typo assesment -> assessment

Bug/issue #, if applicable:
Summary
I found typos in some places, so fixed them. please correct me if I am wrong.
Dependencies
None
Testing
Please check the spelling
Checklist
Make sure you check off the following items. If they cannot be completed, provide a reason.

[ ] ~Added tests~
[x] Ran the ./bin/test script and it succeeded
[ ] ~Updated documentation if necessary~

@swift-ci please test

@swift-ci please test

I see. Thank you. What kind of tests do I need to add? Sorry, it,s my first time contribution and not sure what to do actually.

It corresponds to the code in RenderHierarchyLandmark.swift.
After searching in project, it turns out that we currently do not have any sort of test case for openapi json file. Maybe we can add such later when swift-openapi-generator is mature.

@swift-ci please test


Unable to deploy robusta helm chart with ArgoCD

Describe the bug
Original slack conversation: https://robustacommunity.slack.com/archives/C02R0LVANKY/p1707937278191989
I am unable to deploy robusta when using a yaml templated application for ArgoCD. As suggested on slack, I have tried a number of different ways to refer to my secret values, none of them have worked. Example yaml application for Argo to deploy the helm chart:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: robusta
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: robusta
  project: default
  source:
    chart: robusta
    repoURL: https://robusta-charts.storage.googleapis.com
    targetRevision: 0.10.29
    helm:
      values: |
        globalConfig:
          signing_key: "{{ '{{' }} env.SIGNING_KEY {{ '}}' }}"
          account_id: "{{ '{{' }} env.ACCOUNT_ID {{ '}}' }}"
        sinksConfig:
        - robusta_sink:
            name: robusta_ui_sink
            token: "{{ '{{' }} env.ROBUSTA_UI_TOKEN {{ '}}' }}"
        - discord_sink:
          name: mckernans_discord_sink
          url: "{{ '{{' }} env.DISCORD_SINK_WEBHOOK {{ '}}' }}"
        enablePlatformPlaybooks: true
        runner:
          sendAdditionalTelemetry: true
        rsa:
          private: "{{ '{{' }} env.RSA_PRIVATE {{ '}}' }}"
          public: "{{ '{{' }} env.RSA_PUBLIC {{ '}}' }}"
        runner:
          additional_env_vars:
            - name: SIGNING_KEY
              valueFrom:
                secretKeyRef:
                  name: environment
                  key: SIGNING_KEY
            - name: ACCOUNT_ID
              valueFrom:
                secretKeyRef:
                  name: environment
                  key: ACCOUNT_ID
            - name: ROBUSTA_UI_TOKEN
              valueFrom:
                secretKeyRef:
                  name: environment
                  key: ROBUSTA_UI_TOKEN
            - name: DISCORD_SINK_WEBHOOK
              valueFrom:
                secretKeyRef:
                  name: environment
                  key: DISCORD_SINK_WEBHOOK
            - name: RSA_PRIVATE
              valueFrom:
                secretKeyRef:
                  name: environment
                  key: RSA_PRIVATE
            - name: RSA_PUBLIC
              valueFrom:
                secretKeyRef:
                  name: environment
                  key: RSA_PUBLIC

To Reproduce
Steps to reproduce the behavior:

Create a secret with your environment values (I am using the 1password operator, but any secret should work)
Try to deploy robusta with argocd, using the manifest above
Receive an error like this:

Failed to load target state: failed to generate manifest for source 1 of 1: rpc error: code = Unknown desc = Manifest generation error (cached): `helm template . --name-template root --namespace argocd --kube-version 1.28 <api versions removed> --include-crds` failed exit status 1: Error: parse error at (root/templates/robusta.yaml:20): '{{' Use --debug flag to render out invalid YAML

Expected behavior
I should be able to deploy Robusta and reference environment secrets

The solution ended up being using a separate values file, using a yaml file located in the repository instead of trying to inline in an argocd application directly. example:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: robusta
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: robusta
  project: default
  sources:
    - chart: robusta
      repoURL: https://robusta-charts.storage.googleapis.com
      targetRevision: 0.10.31
      helm:
        valueFiles:
          - $values/values/robusta.yaml

Thanks, I'll update our docs accordingly. Can you explain what $values refers to in valueFiles? Is that something specific to your company to differentiate between different environments?

Thanks for getting the docs updated! I chopped off a few lines by mistake, here's the context on what $values refers to:
  sources:
    - chart: robusta
      repoURL: https://robusta-charts.storage.googleapis.com
      targetRevision: 0.10.31
      helm:
        valueFiles:
          - $values/values/robusta.yaml
    - repoURL: "git@github.com:mckernanin/homelab.git"
      targetRevision: HEAD
      ref: values

Got it, thanks. I've opened a new PR correcting it. If you could take a look, it would be greatly appreciated!
https://github.com/robusta-dev/robusta/pull/1451


Fix popup

I accidentally made it so the popup always follows the mouse exactly, by using the wrong variable name - only just spotted it

https://github.com/theosanderson/covince/pull/52/commits/85c12a2245ea114b42606cd2ef6db39756f1c25c is the only real commit


'Chromosome not found in BAM/CRAM header'

Hi, thanks for helping me with my previous Issue. I got an error message as below
thread '' panicked at 'Chromosome not found in BAM/CRAM header', /opt/conda/conda-bld/perbase_1645626738058/work/src/lib/par_granges.rs:289:18
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
however, there are chromosomes information in my file (I have attached the first page of it). so not sure what is the problem.
many thanks, Surar

the problem was in the bed file used with the option perbase base-depth -b.
many thanks

If anybody encountered this problem: I get rid of all the chromosome scaffolds/contigs and kept the regular chromosomes, 1:23, X,Y,M and error was gone.


add privacy statement

is there any kind of boilerplate simple statement like a CC license?
Implement and check 2 week PII log deletion and add a statement about that. Will need some kind of caveat like "on logs we control" or "logs are deleted as soon as practicable consistent with best practices".

related to #24.


Change Pylenium default log level from INFO to DEBUG

Change the py.log.info messages to py.log.debug. It's a lot of detail and information that you most likely don't care about since the exceptions and traces are more helpful. However, if you do want to see the order of operations from the point of view of Pylenium, you can switch to DEBUG

This looks like it is fixed already.


How to fix textboxes

Hello, I noticed the textboxes are horrible, ex. can't use arrow keys, can't highlight the text, etc.
Is it possible to make the textboxes more normal compared to how textboxes usually are?
Also is it possible to give the textboxes hints? So when there is nothing typed in the box, it will show a "hint" text.the when the user clicks on the textbox, the hint goes away.
Thanks.

@ElectroGamesYT raygui is a simple immediate-mode ui library, it implies some limitations. If you are looking for full-featured ui components probably raygui won't fit your needs. Implementing the features you mention would imply a number of state variables that due to the nature of the library can not be saved.

Hmm okay. Do you know if there are any alternatives?
Also I tried creating another class but when I include my main class, or the raygui, I get a bunch of errors for all of the controls saying they already exist and some other errors, here are a few of the errors:
LNK1169	one or more multiply defined symbols found
LNK2005	main already defined in Editor.obj
LNK2005	GuiWindowBox already defined in Editor.obj
LNK2005	GuiValueBox already defined in Editor.obj
LNK2005	GuiUnlock already defined in Editor.obj
LNK2005	GuiToggleGroup already defined in Editor.obj

About the duplicate symbols issue, that's because RAYGUI_IMPLEMENTATION must be defined in only one compilation unit.
About alternatives, I recommend using Dear ImGui.


Can't define project managers when "Allow everybody to access to this project" is checked

When the "Allow everybody to access to this project" is checked, the interface to add users as a 'Project Manager' disappears.
To add a project manager in this case, you have to uncheck, save, add user as manager, recheck, save.

Yes, this is the expected behaviour at the moment.


Bad gateway on one particular ALB ingress

Heya,
I have an up and working aws-alb-ingress-controller, which works properly for other services.
For this particular one, I can't seem to figure out what's wrong though.
I have the following Ingress resource:
$ kubectl describe ingress api-gateway-ingress
Name:             api-gateway-ingress
Namespace:        orbix-mvp
Address:          4ae1e4ba-orbixmvp-apigatew-c613-1873743362.eu-central-1.elb.amazonaws.com
Default backend:  default-http-backend:80 (<none>)
TLS:
  api-gateway.orbixpay.com terminates api-gateway.orbixpay.com
Rules:
  Host  Path  Backends
  ----  ----  --------
  *
        /*   api-gateway:3000 (<none>)
Annotations:
  kubernetes.io/ingress.class:                       alb
  alb.ingress.kubernetes.io/scheme:                  internet-facing
  alb.ingress.kubernetes.io/ssl-policy:              ELBSecurityPolicy-2016-08
  alb.ingress.kubernetes.io/subnets:                 subnet-0c4cb5452b630939e, subnet-0e5d3c389bfbefee9
  alb.ingress.kubernetes.io/success-codes:           302
  kubectl.kubernetes.io/last-applied-configuration:  {"apiVersion":"extensions/v1beta1","kind":"Ingress","metadata":{"annotations":{"alb.ingress.kubernetes.io/scheme":"internet-facing","alb.ingress.kubernetes.io/ssl-policy":"ELBSecurityPolicy-2016-08","alb.ingress.kubernetes.io/subnets":"subnet-0c4cb5452b630939e, subnet-0e5d3c389bfbefee9","alb.ingress.kubernetes.io/success-codes":"302","kubernetes.io/ingress.class":"alb"},"labels":{"app":"api-gateway"},"name":"api-gateway-ingress","namespace":"orbix-mvp"},"spec":{"rules":[{"host":"api-gateway.orbixpay.com","http":{"paths":[{"backend":{"serviceName":"api-gateway","servicePort":3000},"path":"/*"}]}}]}}

Events:  <none>

It's pointed toward the following service:
$ kubectl describe service api-gateway
Name:                     api-gateway
Namespace:                orbix-mvp
Labels:                   io.kompose.service=api-gateway
Annotations:              kompose.cmd: kompose convert
                          kompose.version: 1.16.0 (0c01309)
Selector:                 io.kompose.service=api-gateway
Type:                     NodePort
IP:                       <IP_ADDRESS>
Port:                     3000  3000/TCP
TargetPort:               3000/TCP
NodePort:                 3000  30262/TCP
Endpoints:                <IP_ADDRESS>:3000
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

And the service has the following endpoint:
$ kubectl get endpoints | grep api
api-gateway               <IP_ADDRESS>:3000                    3d

The pod on that endpoint is the following one:
$ kubectl describe pod api-gateway-675c99c97d-5jvzs
Name:               api-gateway-675c99c97d-5jvzs
Namespace:          orbix-mvp
Priority:           0
PriorityClassName:  <none>
Node:               ip-10-0-1-87.eu-central-1.compute.internal/<IP_ADDRESS>
Start Time:         Mon, 11 Mar 2019 13:32:45 +0200
Labels:             io.kompose.service=api-gateway
                    name=api-gateway
                    pod-template-hash=2317557538
Annotations:        <none>
Status:             Running
IP:                 <IP_ADDRESS>
Controlled By:      ReplicaSet/api-gateway-675c99c97d

When I do a kubectl port-forward api-gateway-675c99c97d-5jvzs 3000:3000 everything works as expected. When I check the ingress though - I get a bad gateway error.
I created the secret using the following guide for a self-signed SSL certificate:
https://kubernetes.github.io/ingress-nginx/user-guide/tls/
Any help is appreciated, thanks in advance :)
I also can't seem to get an invite to kubernetes.slack.com which is why I'm asking here. Hopefully someone can help.

I just tried the Ingress without https, and on http it's working properly.
Which now leaves the question - how does one properly use the AWS ALB Ingress Controller with HTTPS and an actual SSL certificate?
Any help is appreciated.

In case someone stumbles upon this - the resolution is that an SSL certificate needs to be generated in AWS ACM (Amazon Certificate Manager). Once the SSL is generated, it will either be autodiscovered, or you will need to use an annotation in the following way in order to specify it:
alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:eu-central-1:1231234564:certificate/4564abc12-d3c2-4455-8c39-45354cddaf03

Once I did that, the load balancer started resolving over TLS. Hope this helps someone.


Create gradle ansible role

@harimohanr : @samirparhi-dev merged https://github.com/Be-Secure/ansible-role-oah-gradle/pull/2 with ansible-role-oah-gradle main branch


Fix for issue #316 - failed build on LWS (Linux Windows Subsystem)

Fix for issue #316 - failed build on LWS (Linux Windows Subsystem) because of lack of reference to WinMain@16 during linking

Merged as ffa8c66979d4262a95cad584894b9a5fbeea0e84 on master.
I just added a comment on the added line and edited the commit message (it's WSL).
Thank you very much :+1:


Log a more accurate connection message

Not all connections are for writes, some are for mapping shards.

:+1:


reduce k value to result count

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
we reduce k to equal the result count, which vastly improves search latency. Since we have moved to lucene we no longer see the error with inner hits not being returned

What is the current behavior? (You can also link to an open issue here)
Search latency is very high due to a high k - this is a problem since we moved from NMSLIB to lucene based search.

What is the new behavior (if this is a feature change)?
Reduces search lateny on large indexes by approx 20x.

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
no

Have unit tests been run against this PR? (Has there also been any additional testing?)

Related Python client changes (link commit/PR here)

Related documentation changes (link commit/PR here)

Other information:

Please check if the PR fulfills these requirements

[ ] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes/features)
[ ] Docs have been added / updated (for bug fixes / features)

Code to test the impact of missing inner hits:

An OpenSearch community member's gist
OpenSearch contributor's gist

Ran test suite, all passed


Add Kibo x Kendrick by PitapoutVA

Song Name
Kibo x Kendrick
Artist Name
PitapoutVA
Source
Youtube
Youtube Link
https://youtu.be/FGcKyKHHkkY
Direct File Link
No response
Song ID
456732
Start Offset [ms]
0
Extra
Created from Auto Nong.
Created for level: 110017353
Downloaded: No

Repost


Dovekey Auction: Where does the publishers ad server fit in the flow?

The recent Dovekey Auction explainer details a new flow where the contextual ad request is encrypted and sent to DoveKey which is then forwarded to the SSP.
However, in a typical page flow today, contextual bids are collected from an SSP and sent into the publishers Ad Server where they can be compared against direct sold campaigns.
Where would a Publisher's ad server fit in the Dovekey flow?

Thank you for your question.
To confirm, the Publisher’s ad server will run the final auction and return the winner ad back to the browser for rendering, is that right?
If I understand it correctly,  in the scenario that you described, since the SSP only returns contextual bids, and the publisher only has direct sold (not Interest Group) ads, I am not sure how Interest Group ads serving fits into your scenario. Could you elaborate?
Thanks a lot!

If a publisher wants to consider SSP contextual ads, IG ads and their direct sold ads all in the same request, how will this work with DoveKey?
Should the ad server pass the winning direct sold ad to dovekey along with the encrypted SSP request? Will dovekey return some information about the winning ad so it can be passed to the ad server for final auction? Perhaps something else?

Thanks for the followup.
The answer may depend on a few details in your current production setup, including:

Is there a SSP’s tag on the publisher's page to generate the ad requests that the SSP receives?
What cross-domain identifiers are available for the SSP and its partners to provide IG ads? How much do you expect this to change after 3p cookie deprecation?
Which server has the logic to select the most appropriate one among multiple possible house ads or direct sold ads?

Furthermore, in your current production setup, which server does the majority of the following function:

Enforce publisher controls, e.g buyer/creative exclusion and pricing rules?
Handle billing and payment?
Conduct auctions to select winning ads among diversified demands, including IG ads?

Thanks!

There is a lot of diversity in how publishers configure their ad serving stack and there will be many combinations of answers for each of your questions.
To fully monetize inventory, all demand should have a shot at winning every ad impression based on configured business rules. To do so, both direct sold ads and IG ads must be part of one or more auctions that compete for any given impression.
From the Dovekey explainer:

The Dovekey server returns the winning bid and snippet to the browser and the ad tag (maybe in the form of an opaque handle) for rendering.

If Dovekey's response is opaque to the publisher, there is no way for it to feed this response into the ad server for participation in a downstream auction. Since an opaque response is a key privacy mechanism of TURTLEDOVE I don't expect this can be changed. Is there some way for ads from the ad server to compete for an impression where Dovekey is utilized? or do you believe they are incompatible?

Hi Brad,
To satisfy applicable privacy requirements, there might be two possible auctions that IG ads may participant

In-browser auction orchestrated by the browser in the TurtleDove and/or FLEDGE style.
Auction in the Dovekey server that implements an acceptable trust model.

Ads from publishers’ ad servers may participate in either one of the two auctions to compete against IG ads. To do so, one possible setup is to change the labels in the diagram as follows:

Replace “SSP” with “Publishers’ ad server”
Replace “DSP” with “Demand source”.

Without knowing more applicable constraints, it is not apparent to me why Dovekey server might be incompatible with publishers’ ad servers. Would you like to elaborate? Thanks!

I believe publishers would like for 3 types of ads to all compete within the same impression:

Direct Sold Ads in the Pubisher's Ad Server
Contextual Ads from one or more SSPs
IG Ads from Dovekey

Does Dovekey support a configuration where all 3 of these sources can compete?


Service Worker Gateway activation message not showing for mobile and small screen situations

Could simple make the message always showing as:
.message {     position: absolute;     top: 50%;     width: 50%; ...
But pretty sure it should not be the best solution.

You're right @HenryFMa. I'll take a look asap to solve this.
Thank you! 🙏


Configure Renovate

Welcome to Renovate! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.
🚦 To activate Renovate, merge this Pull Request. To disable Renovate, simply close this Pull Request unmerged.

Detected Package Files

tutorial/stage-go/Dockerfile (dockerfile)
tutorial/stage-python/Dockerfile (dockerfile)
tutorial/stage-go/go.mod (gomod)
tutorial/stage-python/requirements.txt (pip_requirements)

What to Expect
With your current configuration, Renovate will create 7 Pull Requests:

Update dependency numpy to v1.21.0

Schedule: ["at any time"]
Branch name: renovate/numpy-1.x
Merge into: master
Upgrade numpy to ==1.21.0

Update dependency pandas to v1.3.0

Schedule: ["at any time"]
Branch name: renovate/pandas-1.x
Merge into: master
Upgrade pandas to ==1.3.0

Update dependency pytz to v2020.5

Schedule: ["at any time"]
Branch name: renovate/pytz-2020.x
Merge into: master
Upgrade pytz to ==2020.5

Update dependency six to v1.16.0

Schedule: ["at any time"]
Branch name: renovate/six-1.x
Merge into: master
Upgrade six to ==1.16.0

Update golang Docker tag to v1.16.5

Schedule: ["at any time"]
Branch name: renovate/docker-golang-1.x
Merge into: master
Upgrade golang to 1.16.5-alpine

Update python Docker tag to v3.9.6

Schedule: ["at any time"]
Branch name: renovate/docker-python-3.x
Merge into: master
Upgrade python to 3.9.6-slim

Update dependency pytz to v2021

Schedule: ["at any time"]
Branch name: renovate/pytz-2021.x
Merge into: master
Upgrade pytz to ==2021.1

❓ Got questions? Check out Renovate's Docs, particularly the Getting Started section.
If you need any further assistance then you can also request help here.

This PR has been generated by Renovate Bot.

Desculpa gente, estava testando uma GitHub app com a minha conta pessoal e ela acabou criando esses PRs na maior parte das orgs que faço parte.