Get-AzureADApplicationProxyApplication

Hello,
When running this PS "Get-AzureADApplicationProxyApplication -ObjectId $item.objectid":
https://github.com/Azure/azure-docs-powershell-azuread/blob/live/azureadps-2.0/AzureAD/Get-AzureADApplicationProxyApplication.md
Error received:
Get-AzureADApplicationProxyApplication : Error converting value "aadHeaderBased" to type 'System.Nullable`1[Microsoft.Open.MSGraph.Model.OnPremisesPublishingSingleSignOnObject+SingleSignOnModeEnum]'. Path 'singleSignOnSettings.SingleSignOnMode', line 1, position 948
Tested with Preview and Normal AzureAD version.
Any ideas?

Hello @lightupdifire , thanks for your query.
Could you share the definition you used for the variable $item. There is seems to be a problem with the data type conversion.
You could also try running this as:
Get-AzureADApplicationProxyApplication -ObjectId $ObjectId
by replacing $ObjectId with the ObjectId of your application. Let me know how that goes.

@msewaweru
Thanks for the feedback! I think I got this as well, have to give it like a bigger object :)
I try to find all on-prem apps and add a new cert as our thumbprint changed... below code worked, maybe can add a second article to replace the wildcard if the thumbprint is different.
`Write-Host "Reading Azure AD applications. This operation might take longer..." -BackgroundColor "Black" -ForegroundColor "Green"
$App = Get-AzureADApplication -All $true | Select-Object Displayname, ObjectId
$i = 1
$count = $app.count
Foreach ($apps in $app)
{
Write-Progress -Activity "Getting $($apps.DisplayName) App-proxy information" -Status "$i of $count" -PercentComplete ($i/$count*100)
try {
$proxy = Get-AzureADApplicationProxyApplication -ObjectId "$($apps.Objectid)" -ErrorAction Stop
#####The Above cmdlet is used to get list of App-proxy Applications###########
if (($proxy.IsOnPremPublishingEnabled -eq $true) -and ($proxy.ExternalUrl -like "mycustomdomain.com"))
{
Write-Host ("Found on-premise Application with External domain as mycustomdomain.com: $($apps.Displayname)") -BackgroundColor "Black" -ForegroundColor "Yellow"
			if ($proxy.VerifiedCustomDomainCertificatesMetadata.Thumbprint -notmatch $certThumbprint)
			{
			Write-Host ("SSL certificate change required for the Azure AD Application Proxy App below: $($apps.Displayname) with ObjectID: $($apps.Objectid)") -BackgroundColor "Black" -ForegroundColor "Green"
			Set-AzureADApplicationProxyApplicationCustomDomainCertificate -ObjectId  $($apps.Objectid) -PFXFilePath $pfxPath -Password $securePassword
			}
		}
      } #End of Try Statement
  catch {
         $Problem = $PSItem.exception.message
        } #End of Catch statement
$i++

} #End of Foreach loop
End of Core ###`


🚀  Like Button

Setting up the like button.

Added the like button functionality in the feed/views.py file.
Set a like URL which include the post to like ID
Links the existing dummy like button to the url
Added tests

Only an authenticated user can like a post.
Future Improvements:

Prevent the page from completely reload when hitting the like button. (#112)
If an authenticated user have liked a post, he should see the like button as a filled thumbs up pic instead of the empty existing one (#113)

Close #110

the way authenticate is used here should be revised https://docs.djangoproject.com/en/4.0/topics/auth/default/#authenticating-users It is a low level authentication, Dont you think the logic should be done ins the App side?

Updated, you could find the updates in the test file added to this PR in lines 139 and 157.
Hope that I understood correctly.

Hi @Yarboa,
Changed the tests to assert content of the response context.
Also added another test test_after_like_redirect_to_detail_view to check redirection after success like when HTML REFFER is disabled, but couldn't figure out how or if to check redirection when HTML REFFER is allowed.

Hi @Yarboa, Changed the tests to assert content of the response context. Also added another test test_after_like_redirect_to_detail_view to check redirection after success like when HTML REFFER is disabled, but couldn't figure out how or if to check redirection when HTML REFFER is allowed.

You should run another request with client to the redirect URL
you should reach the redirected page, with 200OK and context

Hi @Yarboa, Changed the tests to assert content of the response context. Also added another test test_after_like_redirect_to_detail_view to check redirection after success like when HTML REFFER is disabled, but couldn't figure out how or if to check redirection when HTML REFFER is allowed.

You should run another request with client to the redirect URL you should reach the redirected page, with 200OK and context

I've added the 200 status code in the test_like_url_unlikes test.
And I also have this test:
def test_after_like_redirect_to_detail_view(self, post, logged_in_client):
        # Testing that after successful like, if the user got to the like URL
        # by typing it, he would get redirected to the post detail view page.
        # Also, if a user turned off the HTTP_REFERER option in his browser he would
        # get returned to the post detail view
        response = logged_in_client.get(post_like_url(post.id))
        assert response.status_code == REDIRECT_URL_STATUS
        assert response.url == POST_DETAIL_URL + f'{post.id}/'

But I think there is another test missing and I cant figure out how to set it, I tried:
def test(self, post, logged_in_client):
        logged_in_client.get(FEED_URL)
        response = logged_in_client.get(post_like_url(post.id))
        assert response.url == FEED_URL

but I dont get the feed to be the response.url, I get the post detail view as the test before.
What im trying to test here are lines 57-59 in the feed/views.py:
 origin_url = request.META.get('HTTP_REFERER')
        if origin_url is not None:
            return HttpResponseRedirect(origin_url)

Hi @Yarboa, Changed the tests to assert content of the response context. Also added another test test_after_like_redirect_to_detail_view to check redirection after success like when HTML REFFER is disabled, but couldn't figure out how or if to check redirection when HTML REFFER is allowed.

You should run another request with client to the redirect URL you should reach the redirected page, with 200OK and context

I've added the 200 status code in the test_like_url_unlikes test. And I also have this test:
def test_after_like_redirect_to_detail_view(self, post, logged_in_client):
        # Testing that after successful like, if the user got to the like URL
        # by typing it, he would get redirected to the post detail view page.
        # Also, if a user turned off the HTTP_REFERER option in his browser he would
        # get returned to the post detail view
        response = logged_in_client.get(post_like_url(post.id))
        assert response.status_code == REDIRECT_URL_STATUS
        assert response.url == POST_DETAIL_URL + f'{post.id}/'

But I think there is another test missing and I cant figure out how to set it, I tried:
def test(self, post, logged_in_client):
        logged_in_client.get(FEED_URL)
        response = logged_in_client.get(post_like_url(post.id))
        assert response.url == FEED_URL

but I dont get the feed to be the response.url, I get the post detail view as the test before. What im trying to test here are lines 57-59 in the feed/views.py:
 origin_url = request.META.get('HTTP_REFERER')
 if origin_url is not None:
        return HttpResponseRedirect(origin_url)

Just review the UI talk, you have those sample tests.
Once you received redirect url, you should call from the client again

response = client.get('/posts')
assert response.status_code == 301
response = client.get(response.url)
assert response.status_code == 200
assert isinstance(response.context['blog_list'], list)

Hi @Yarboa, Changed the tests to assert content of the response context. Also added another test test_after_like_redirect_to_detail_view to check redirection after success like when HTML REFFER is disabled, but couldn't figure out how or if to check redirection when HTML REFFER is allowed.

You should run another request with client to the redirect URL you should reach the redirected page, with 200OK and context

I've added the 200 status code in the test_like_url_unlikes test. And I also have this test:
def test_after_like_redirect_to_detail_view(self, post, logged_in_client):
        # Testing that after successful like, if the user got to the like URL
        # by typing it, he would get redirected to the post detail view page.
        # Also, if a user turned off the HTTP_REFERER option in his browser he would
        # get returned to the post detail view
        response = logged_in_client.get(post_like_url(post.id))
        assert response.status_code == REDIRECT_URL_STATUS
        assert response.url == POST_DETAIL_URL + f'{post.id}/'

But I think there is another test missing and I cant figure out how to set it, I tried:
def test(self, post, logged_in_client):
        logged_in_client.get(FEED_URL)
        response = logged_in_client.get(post_like_url(post.id))
        assert response.url == FEED_URL

but I dont get the feed to be the response.url, I get the post detail view as the test before. What im trying to test here are lines 57-59 in the feed/views.py:
 origin_url = request.META.get('HTTP_REFERER')
 if origin_url is not None:
        return HttpResponseRedirect(origin_url)

Just review the UI talk, you have those sample tests. Once you received redirect url, you should call from the client again

response = client.get('/posts')
assert response.status_code == 301
response = client.get(response.url)
assert response.status_code == 200
assert isinstance(response.context['blog_list'], list)

Thanks done, also moved the like count to a fixture.


Library can use better mixin selection.

Beyond automating confirmation the selected mixins are recent enough, not always being the last mixin when doing frequent transactions would be beneficial. That said, there are some natural limitations to this (if you spend immediately after, you can only use mixins from the same block as your output; that alone would be suspicious).

This is a caveat according to the README.


add new 16 questions and answers in 1-1 section and jupyter notebooks as the answers on 1-1, 2-1 and 2-2 sections

add new interesting 17 kinda questions on 1-1 section.

add jupyter notebooks as answer on several sections.

こちらもコンフリクトしているので，PR取り下げて差分をまたPRします．


Add confirm delete in trash

Closes #7707

@beradeep Thanks for working on this. I've added a comment to issue #7707 adding details about how I think this feature should behave.

@cketti Shall I continue working on it, and try to incorporate the suggestions?

Shall I continue working on it, and try to incorporate the suggestions?

That would be great.
Please note that messages can also be deleted from places other than the message list. Looking at references to K9.isConfirmDelete* should reveal those locations.

This turned out to be more complex than I initially thought (see #7731). I think it'll be a while before our code is in a shape where we can easily implement this feature.
Closing this pull request. The feature request issue remains open.


Feat: implement Admin.deleteTopicRecords

Not linked to an issue but was briefly discussed in PR #895
Ended up being a fair few things to add/tests to write, but I tried to follow existing patterns where possible so hopefully not too out-of-the-ordinary 🤞
Recap:

Add deleteRecords to the protocols. I only went up to v1... there's also a v2 but I don't think it has anything of value, just this new TAG_BUFFER field I'm not familiar with.
Add deleteRecords to the broker.
Implement as deleteTopicRecords in the admin. Called deleteTopicRecords instead of deleteRecords as it works on a single topic at a time (otherwise the logic becomes messy if you have to pass an array with multiple topics and nested multiple partitions; I think deleting from a single topic at a time should be sufficient for most people)

The test cases should describe most of the behaviours in detail, but there's a couple of things I wanted to highlight, as I made some assumptions about what "should" happen in these scenarios (let me know if you disagree):

if one of the passed-in partition offsets is out-of-range, Kafka would throw an error anyway, so I've set it up to throw pre-emptively before sending any request (to avoid a possible confusing situation where it fails half-way through, after you've already deleted from one or more partitions).
if one of the passed-in partitions has no broker/does not exist, it's a no-op and we log a warning and ignore. Perhaps an outright error is better though?
if one of the passed-in partition offsets is below the LWM (but still above 0), Kafka allows this... it just means nothing gets deleted on that partition. So we log a warning.

if one of the passed-in partition offsets is below the LWM (but still above 0), Kafka allows this... it just means nothing gets deleted on that partition. So we log a warning.

I agree with this choice. In a way, the caller's request has already been fulfilled if the lwm is below the requested offset.

if one of the passed-in partition offsets is out-of-range, Kafka would throw an error anyway, so I've set it up to throw pre-emptively before sending any request (to avoid a possible confusing situation where it fails half-way through, after you've already deleted from one or more partitions).

Hmm, I see. I understand your thinking here. Since we would reject with an error as soon as one of the responses come back with an error, the caller wouldn't necessarily be able to tell which offsets were deleted.
Let's think about it for a bit and figure out what the best outcome for the user is. Say I'm deleting records from 3 different partitions that are on 3 different leaders. One of the requests fail because the requested offset is out of range.
// Say we fail to delete partition 2
await admin.deleteTopicRecords({ topic, partitions: [
  { partition: 1, offset: 10 },
  { partition: 2, offset: 15 },
  { partition: 3, offset: 12 }
]})

Now how do I deal with this as a user? If we do the early check on the client side, I get a KafkaJSOffsetOutOfRange telling me that partition 2 offset 15 is not maintained by this server. Partition 1 and 3 have not been modified (the only reason I know this is because I read the code though). So I can fetch offsets and re-make the request with the correct offset. The downside is some duplication of logic that already lives on the broker, but overall not terrible. It's a bit annoying that if partition 3 is also out of range, I'll get another error and have to repeat the process, but again, not terrible.
If we let the broker deal with it, the call will reject with the same error as above. Assuming that the requests were made in the same order that we specified the partitions in, partition 1 would have been processed and partitions 2 and 3 not, but there's no way for the user to know that. Not great.
A third option is to let the broker deal with it but aggregate the errors ourselves. Basically we throw the requests into Promise.allSettled and if any of them errored, we reject with our own error that wraps the protocol errors. Something like:
interface DeleteTopicRecordsResult {
  topic: string,
  partitions: DeleteRecordsResult[]
}

interface DeleteRecordsResult {
  partition: string;
  offset: number;
  error: Error // This would be the original error from the broker
}

class KafkaJSDeleteTopicRecordsError extends KafkaJSError {
  constructor(result: DeleteTopicRecordsResult) {
    /*
     * This error is retriable if all the errors were retriable
     * Not sure if it's a good idea or not, but it seems right to me.
     */
    const retriable = result.partitions
      .filter(({ error }) => error != null)
      .every(({ error }) => e.retriable === true)

    super('Error while deleting records', { retriable })
    this.name = "KafkaJSDeleteRecordsError"
    this.partitions = result.partitions
  }
}

This would allow the user to know exactly which partitions failed to be deleted and why.
Do you have any thoughts?

Thanks for the feedback 😄

It's a bit annoying that if partition 3 is also out of range, I'll get another error and have to repeat the process, but again, not terrible

Ah yes I didn't factor that in; you're right.. if one partition is out of range it's possible/probable that another one might well be, making it a little annoying for the user to go through the same process again.

A third option is to let the broker deal with it but aggregate the errors ourselves

I like the example you gave - makes sense. The only element that sits a little uncomfortably with me, conceptually, is the idea of a request that ultimately responds with an error, but nevertheless is allowed to partially modify the state of the data. But this is me coming from my risk-averse mindset where I try to make everything idempotent and wrap it all inside a postgres transaction 😂 . I guess in your example, partition 1 and 3 would have been modified anyway, if partition 2 was correct, so the request is unlikely to be corrupting the data... so I don't feel strongly about it.. happy to go with aggregating the errors (which will hopefully be more elegant than the early check).
I've got a couple of work deadlines this week but will have a go at this over the weekend, and respond to your other comments as well - I had a quick read but would like to set some proper time aside to respond fully and clean the PR up etc etc - if that's ok.

The only element that sits a little uncomfortably with me, conceptually, is the idea of a request that ultimately responds with an error, but nevertheless is allowed to partially modify the state of the data.

Oh I agree completely. If there was a way we could guarantee atomicity here, I would be all for it, but since we are actually potentially making several calls to several brokers, there's no way to roll back the other operations if one of them fail. Even trying to check the offset early is just lulling you into a false sense of security, as some of the operations may still fail, either because the offsets have become out of range since you did the check or for some other reason, and then you're in the exact same situation where the operation may have partially succeeded.

I've got a couple of work deadlines this week but will have a go at this over the weekend, and respond to your other comments as well - I had a quick read but would like to set some proper time aside to respond fully and clean the PR up etc etc - if that's ok.

Sure thing. There's no rush on my account, as long as we eventually get it merged.

Hopefully we're getting there.. it should be correctly matching up the errors to the partitions now, and will handle multiple errors from a single broker response.
There is a (small) bit of extra complexity in the response handler: am passing the requested topic data into the response handler, so it can attach the requested offset to the error that's thrown back. Let me know if you prefer to leave it out.
To handle the possibility of multiple errors from a single broker, I'm also using the same KafkaJSDeleteTopicRecordsError  structure to throw these to the admin, but can create a separate one if it's preferable.

(edit: forgot to re-request a review - not sure if you get pinged only when I push a PR update)

No, I don't get any notification unless you re-request a review. Even if I did, I wouldn't know if you were still working on it or if it's ready to be reviewed again, so requesting is greatly appreciated.

Just a minor suggestion as well as some merge conflict to handle, but then we should be good to go.

Cool, thanks :)
Fortunately the conflict wasn't too bad - was just missing an extra error class.


Upgrade @dfinity/* Package Version

@dfinity/agent-js current version v0.11.2
in this repo v0.10.4

@dfinity/agent-js current version v0.11.2 in this repo v0.10.4

Ah yes I will fix that soon. Thanks for reporting.

@dfinity/agent-js current version v0.11.2 in this repo v0.10.4

Should be fixed now. Try latest version 0.1.0


Question: pass authorization headers in Window.open, iframe scenarios

First of all a big thank you and I greatly appreciate the work and the support you are giving for the Identity Provider.
I have couple of scenarios In my application and I am sure at least some of the people who are using this identity provider might be facing or faced all these issues before. So If you are aware, Can you please let me know what are the best approaches for these problems.
Before we implement Identity provider, our application used to work on cookie based authentication. Our UI is built on angularJS and we have some applications that were included in iframe's that were built in MVC and asp.net forms (for the some of the SQL SEREVER reportviewer limitations). This is all used to work with cookie based authentication. But after we switch to Identity provider, all these end points are expecting authorization headers and since we can not pass auth headers to iframes or window.open, This functionality is breaking.
The same thing with window.open which calls webapi end point and result is a redirect action, Not sure how an authorization header can be passed in this context too.
Appreciate any help!!

I don't quite follow... but if you have resources that expect an access token then pass them. I don't see that this is a question about this library or bug report.


Input Gpx file format

Hello,
What is the format of the GPX file to run this API?
Please help me to find the sample file.

For general questions or discussion about GraphHopper, please use our forum.


Issue with showing party HP

Issue showing player HP when entering within 1200m of each other. HP shows player as "red" or dead, but shows correct HP when player leaves the 1200m radius.

This should have been fixed with 949c89803c9e11f37dfad1f5278c7f431b88d749
If it's still happening after updating to the latest version, please send me the script log from the client.

Seems to be fixed with the latest update indeed.


Add aggregated graphs to master dashboard

/assign @mm4tt
Add a set of new graphs to Graphana dashboard, using quantile_over_time(0.99, query.

/retest

/lgtm
/approve


Simplify protected and private

It is currently not possible for a class member and a class method to have the same name, as Lily accesses both through the use of a dot outside of a class. Based on this, I'd like to simplify protected and private a touch.
class abc() {
    protected var @a = 10
    private define v() { ... }
}

down to:
class abc() {
    protected @a = 10
    protected v() { ... }
}

Lily should infer that if it is a '@', that it's a var declaration, and anything else must be a define. This is because the private and protected are always followed by something.

No. With the current syntax, one can easily grep define on a file to get all of the function definitions that are contained within it. Similarly, grep var can grab most of the vars. This is shorter, but I think it would hurt the ability to grep through code (you'd have to get define, protected, and private, but not have @* because those are vars).


Crash when viewing a post

E.g. when going to https://takahe.social/<EMAIL_ADDRESS>nothing happens for a while and then eventually a " bad gateway" message is displayed.

This only started happening recently, after load increased by people importing their followers. Could be related. Also it only happens with posts which have (lots of?) replies.

It's only that specific post, so it's likely something in there is triggering it. I'm currently on vacation in Australia, so I'll try to download this post onto my local test server once I'm back home.

No, if I click 'View post and replies' on posts that look popular (skipping those that obviously won't trigger the issue) then it happens about 25% of the time. It's pretty reliable.
Here are some more:
https://takahe.social/<EMAIL_ADDRESS>https://takahe.social/<EMAIL_ADDRESS>https://takahe.social/<EMAIL_ADDRESS>https://takahe.social/<EMAIL_ADDRESS>

Now I'm back from Aus, I have dug in a little more and found that those posts are causing the entire thread to raise SystemExit. I don't quite know why yet.

OK, traced this down to there being no index on Post.in_reply_to - calculating post reply counts was astonishingly slow. It's still not speedy to display, but there's some general performance improvements I'm going to be making to all pages, so closing this with https://github.com/jointakahe/takahe/commit/afc94f63135a80bef49c9501f4b6ae0c46d67f53 as the designated fix.

Nice one!
I wonder if adding a number_of_replies field to the post might be even faster than adding an index. Certainly the index is easier and requires no upkeep, tho.

We already have a general stats field for post counts - it's used for likes and boosts already, just needs a bit of code to add replies.


[Bug]:

Description
I tried buying airtime from safaricom to airtel on the app it says pending but the airtime has already been sent but the recipient hasn;t recieved it yet
Steps to reproduce

open stax app
go to buy airtime
input mpesa as the payment option
input telkom as the recipient network
enter number, amount then click continue and confirm
the status remains pending but the money has been sent yet the airtime doesnt reach the recipient on the other network

Expected result
sttus should change to completed and airtime should succesfully be sent to other network
Actual result
sttus remains pending and the airtime doesnt reach the other network
Link to screenshots/screen recordings
https://drive.google.com/drive/folders/1sdo2b0QevGWDOZi90vNAjwWUwj9wibEp?usp=sharing
Device name
cubot
Android OS
10.1.0
Is your phone dual SIM or single SIM?
Dual SIM
Which telco are you using for this test?
Safaricom
Stax device ID or email address
58ee3f13f1e19686

@RoyalRoys435 is this still an issue?


🐛 BUG: Formatter results in unwanted whitespace

Describe the Bug
The extension automatically formats the following code:

  some text (<SomeComponent>content</SomeComponent>)

into:

  some text (<SomeComponent>
    content
  </SomeComponent>)

which results into the following text on screen (containing a space after ( and one before ):
some text ( content )

Steps to Reproduce

Create new Astro project: npm create astro@latest
Create a new component
Use it in a page or layout
See the result in your browser. I think the expected result would be to have spaces removed.

I think this is withastro/prettier-plugin-astro#308.

No, this is a different issue, since it's not inside an expression. Nonetheless, it is a prettier plugin issue and not language tool


add pytorch support for precompute transform

This PR adds PyTorch support for our precompute transforms, amongst other small adjustments.
Core Code:

[ ] Add PyTorch forward/inverse spherical harmonic transform
[ ] Add PyTorch forward/inverse Wigner transform
[ ] Add PyTorch resampling and quadrature functions.
[ ] Add PyTorch implementation of HEALPix Fast Fourier transforms.

Unit Tests

[ ] Roundtrip error for PyTorch spherical harmonic and Wigner transforms.
[ ] Regression error for PyTorch spherical harmonic and Wigner transforms (against base implementations).
[ ] Validation of PyTorch gradients against finite differences

Contributions for next PRs

[ ] Speed benchmarking of PyTorch implementation against JAX on GPU.
[ ] Add PyTorch support for recursion based transforms.

Further comments
HEALPix FFTs require modular indexing into torch tensor, which results in a non-unique tensor of index locations at which to update an existing tensor in place. This doesn't currently work with the expected array[index_array] += new_array behaviour so a workaround was needed. If this changes in future we should update accordingly.

@all-contributors please add @kmulderdas  for bug

@jasonmcewen difficult to test the HEALPix quadrature authentically as its not exact and shouldn't pass an f00 test. I did however extend the testing to cover DH. Overall should be at around 94% which is fine I think.


Added Client class for UART-DEM & terminal access tool

I've amended the last commit to include the current changes to 'cl_dem_uart' and 'terminal'.
Should the changes to osd-target-run just be a separate commit or a separate PR?
Also, there is still a problem with reading the incoming data. If there is no '\n' (or presumably some other control character) written to /dev/pts/* at some point, then any read() won't return.

I tried to incorporate all the suggestions and amended the commit.

Can you please also commit (in a separate commit) the osd-target-run integration, in whatever WIP state it is right now so I can test you code?

Done.
Note that there are still some problems with read() not returning if no \n is written. So I don't think the commit should be merged in its current state.

I tried to resolve all issues but i couldn't find any previous comment relating to autoconf.

Regarding the autoconf comment: That is already resolved, I was suggesting moving #define _XOPEN_SOURCE line into autoconf, but it seems it was already there and you removed it from the code.
Finally: I'll be back at university tomorrow if you want to discuss something in person.

All the small things should be fixed.
Turns out there is a ICRNL flag in the termios struct, which turns CRs into NLs and is enabled by default. I tried to play around with some of the other flags (INLCR, OCRNL, ONLCR) and it seems to be working correctly now but im not yet 100% sure why.

Should be all done now :)

Great work, thanks @ThomasLeyk! Its merged into OSD now, and I'll import it into OpTiMSoC once I have a working compute tile design.


Collection loader should check the complete prototype chain instead of the 'own' object.

When defining a BaseModel for my project to extend from I wanted to define the connection in this BaseModel. And then extend the BaseModel in my implementation model, lets say User. Then the validator in the collection loader kicks in 'The connection  specified in User does not exist!' Which is not true, but due to the fact that the check uses hasOwnProperty the prototype chain is not checked.
Here is the line that causes the issue: https://github.com/balderdashy/waterline/blob/master/lib/waterline/collection/loader.js#L99
The code to reproduce.
BaseModel.js
var Waterline = require('waterline');
module.exports = Waterline.Collection.extend({
	connection: 'default',
});

User.js
var BaseModel =  require('./BaseModel.js');
module.exports = BaseModel.extend({
	identity: 'User',
	attributes: {
		name: 'string'
	}
});

It is possible to check the full chain by using in.
'connection' in model  // => true

Good point, @vincentheet.  I'd definitely take a look at a PR for this.

:+1:

If you are extending from a base model that isn't needed as an actual model just make it an object and use something like lodash assign to extend the object being created.


Bug of ApplicationGatewaySslPredefinedPolicy in Azure.ResourceManager.Network

The ResourceType of ApplicationGatewaySslPredefinedPolicy is Microsoft.Network/applicationGatewayAvailableSslOptions/predefinedPolicies. However, the list operation of ApplicationGatewaySslPredefinedPolicy will get following results:
{
  "value": [
    {
      "name": "AppGwSslPolicy20150501",
      "id": "/subscriptions/testSub/resourceGroups//providers/Microsoft.Network/ApplicationGatewayAvailableSslOptions/default/ApplicationGatewaySslPredefinedPolicy/AppGwSslPolicy20150501",
      "properties": {
        "cipherSuites": [
          "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
          "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
          "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
          "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
          "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
          "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
          "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384",
          "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256",
          "TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
          "TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
          "TLS_RSA_WITH_AES_256_GCM_SHA384",
          "TLS_RSA_WITH_AES_128_GCM_SHA256",
          "TLS_RSA_WITH_AES_256_CBC_SHA256",
          "TLS_RSA_WITH_AES_128_CBC_SHA256",
          "TLS_RSA_WITH_AES_256_CBC_SHA",
          "TLS_RSA_WITH_AES_128_CBC_SHA",
          "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
          "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
          "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
          "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
          "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
          "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
          "TLS_DHE_DSS_WITH_AES_256_CBC_SHA256",
          "TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
          "TLS_DHE_DSS_WITH_AES_256_CBC_SHA",
          "TLS_DHE_DSS_WITH_AES_128_CBC_SHA",
          "TLS_RSA_WITH_3DES_EDE_CBC_SHA",
          "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA"
        ],
        "minProtocolVersion": "TLSv1_0"
      },
      "type": "Microsoft.Network/ApplicationGatewayAvailableSslOptions/ApplicationGatewaySslPredefinedPolicy"
    },
    {
      "name": "AppGwSslPolicy20170401",
      "id": "/subscriptions/testSub/resourceGroups//providers/Microsoft.Network/ApplicationGatewayAvailableSslOptions/default/ApplicationGatewaySslPredefinedPolicy/AppGwSslPolicy20170401",
      "properties": {
        "cipherSuites": [
          "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
          "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
          "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
          "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
          "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
          "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
          "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
          "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
          "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
          "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
          "TLS_RSA_WITH_AES_256_GCM_SHA384",
          "TLS_RSA_WITH_AES_128_GCM_SHA256",
          "TLS_RSA_WITH_AES_256_CBC_SHA256",
          "TLS_RSA_WITH_AES_128_CBC_SHA256",
          "TLS_RSA_WITH_AES_256_CBC_SHA",
          "TLS_RSA_WITH_AES_128_CBC_SHA"
        ],
        "minProtocolVersion": "TLSv1_1"
      },
      "type": "Microsoft.Network/ApplicationGatewayAvailableSslOptions/ApplicationGatewaySslPredefinedPolicy"
    },
    {
      "name": "AppGwSslPolicy20170401S",
      "id": "/subscriptions/testSub/resourceGroups//providers/Microsoft.Network/ApplicationGatewayAvailableSslOptions/default/ApplicationGatewaySslPredefinedPolicy/AppGwSslPolicy20170401S",
      "properties": {
        "cipherSuites": [
          "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
          "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
          "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
          "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
          "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
          "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
          "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
          "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
          "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
          "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
          "TLS_RSA_WITH_AES_256_GCM_SHA384",
          "TLS_RSA_WITH_AES_128_GCM_SHA256",
          "TLS_RSA_WITH_AES_256_CBC_SHA256",
          "TLS_RSA_WITH_AES_128_CBC_SHA256",
          "TLS_RSA_WITH_AES_256_CBC_SHA",
          "TLS_RSA_WITH_AES_128_CBC_SHA"
        ],
        "minProtocolVersion": "TLSv1_2"
      },
      "type": "Microsoft.Network/ApplicationGatewayAvailableSslOptions/ApplicationGatewaySslPredefinedPolicy"
    }
  ]
}

It's easy to find out that the id.ResourceType can't match with the ResourceType, so the ctor will fail.

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'Storage:0.5870873,Service Bus:0.067569755,Tables:0.025441263'


[PUI] Enable passing of string urls to apiUrl

This PR enables passing strings (preferably URLs) to API forms so they can be used with custom URLs / in plugins.

This will weaken the existing type checking checks which have already been useful in detection of mis-typed URLs. However I am not sure if there is a better approach here

In my opinion the idea behind this function is good, but the issue with it is, that if adding an api path, I basically have to go to two different files and add something on two places. That slows down the quick development.  As the apiEndpoint function is just a huge switch case prefabricated building, why not just use an object with key: url and type the function accordingly. And then to allow strings, we add a second function that allows strings which gets called by the function which only allows ApiPaths. Because we cannot union string with choices. E.g. something like this:
export const API_PATHS = {
  "api-plugin-settings": "plugins/:plugin/settings/",
  // ...
}
export type API_PATH_TYPE = keyof typeof API_PATHS;

export function apiGenericUrl(path: string; ...) {
  // do  like before, but without the apiEndpoint call
}

export function apiUrl(path: API_PATH_TYPE, ...args) {
  return apiGenericUrl(API_PATHS[path], ...args)
}

That way we would

only need to change something at one place
only need to import the apiUrl function
have the possibility to use raw strings without mixing them

@wolflu05 I'd suggest making that as a separate issue :)


Allow custom ranges for colors

Hello love the card so much.
Will you be so kind to consider allowing us the ability to adjust the range for colors and add additional ones
For example right now there is only >0, 0, <0.
I would like to be able to adjust these per device so I can have color based on how much or how little they are generating so I can see if something is not performing correctly.
For example the ability to do

1000 = red
500 = yellow
100 = green
<-500 = yellow
<-1000 = red

THANKS

Hi there 👋
Thanks for the good suggestion.
Sadly i have a lot to do at the moment, Uni related, which is why i cannot get working on this as quickly as i normally would.
I will keep the issue open and revisit it once i have more time!
Take care! 👍

Just to collect some ideas for an editor here:

If people have additional ideas, feel free to post them here.

you might consider the way how the bar-card could be configured. There it is called severity.
I placed a bar-card as content in the power-distribution card. See below.
The bar-card hasn't been maintained for quite some time, hence similar functionality it the power-distribution card would be great.

center:   type: card   content:     type: custom:bar-card     entities:       - entity: sensor.e3dc_autarky         name: Autark         severity:           - color: Red             from: 0             to: 60           - color: Orange             from: 61             to: 80           - color: Amber             from: 81             to: 90           - color: Green             from: 91             to: 100           - color: Darkgreen             from: 95             to: 100       - entity: sensor.e3dc_own_consumption         name: Selbst         severity:           - color: Red             from: 0             to: 60           - color: Orange             from: 61             to: 80           - color: Amber             from: 81             to: 90           - color: Green             from: 91             to: 100           - color: Darkgreen             from: 95             to: 100     title: Haus 🏠     columns: '2'     direction: up     height: 200     width: 70%     positions:       icon: 'off'       name: outside       value: outside       indicator: 'off'

@nicknol Thanks for your input.
Wouldn't that be a bit different since this only allows setting values for ranges, but not for specific points?

Well, I understood the feature request that way :)
at least I would like to be able to define  different ranges of values ans associate each range with a color.
this could be used for the bars in the center, or as well for the icons and arrows.
e.g. the consumption of my house could be colored

green if it is from 0W to 300W
lime if it is from 301W to 500W
yellow if it is from 501 to 700W
red if it is from 701 10.000W (to color it red in any case above 700W)


(experiment): put distinguish singleheader json.

Sketch how this can be done in a way that

only the toplevel BUILD file is affected (with WORKSPACE dependencies, we only can provide a toplevel BUILD file). Thus we could not make a sub-package.
still is easy to read as the singleheader-name reflects what it is for
Two simple targets: :json and :singleheader/json

I guess I need to teach bant that these are valid target labels :)


Automod fix

Pull request checklist:

[x] CHANGELOG.md was updated, if applicable

Description
Automod didn't work properly but this is now fixed.
Closes #2682

The steps to reproduce the bug are discussed in the issue.
Otherwise:

Enable automod to level 4 (for simplicity)
Use some account and type something vulgur
As a moderator see that the message was held up
Click Approve or Deny
See that nothing happened to the AutoMod message that was shown when it's supposed to fade to gray

This also fixed automod pubsub messages in general.
Some notes for devs:
When I implemented it
chatterino.pubsub: moderationActionHandlers delete_blocked_term
chatterino.pubsub: moderationActionHandlers delete_permitted_term
chatterino.pubsub: channelTermsActionHandlers add_permitted_term
chatterino.pubsub: channelTermsActionHandlers add_blocked_term
chatterino.pubsub: channelTermsActionHandlers delete_blocked_term
chatterino.pubsub: channelTermsActionHandlers delete_permitted_term

Happened while allowing/denying messages and also adding and removing phrases in twitch automod gui.

so this would close #2682, right?

@apa420 thank you for your hard work into fixing this issue 💛 i appreciate it


Missing StretchDIBits from Windows GDI

I noticed a couple of missing API from GDI such as SetDIBits, SetDIBitsToDevice and StretchDIBits.
https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-stretchdibits
StretchDIBits is particularly important to me because it supports JPG. Since GDI+ is not included either, I have to rely on function like StretchDIBits to try to display JPG image to screen.
The StretchBits which is included in winsafe (winsafe::prelude::gdi_Hdc::StretchBlt) is not good enough for me.
What I'm trying to do is to decode JPG to BMP then display the image, but winsafe::HBITMAP::CreateBitmap doesn't work as expected. It broke the decoded BMP image. Then I have to use CreateCompatibleBitmap, but in order to fill the pixels data to CreateCompatibleBitmap, I have to use SetDIBits, which is again missing from winsafe.
Here is the code I use to display JPG image to screen:
fn show_img() -> Result<(), Box<dyn std::error::Error>> {

        //img_data contains the jpg file data:

    let buff = std::io::Cursor::new(img_data);
    let mut decoder = jpeg::Decoder::new(buff);
    let mut pixels = decoder.decode().expect("failed to decode image");
    let metadata = decoder.info().unwrap();
    let h_bmp = winsafe::HBITMAP::CreateBitmap(
           SIZE::new(metadata.width as i32, metadata.height as i32),
       1, 32, pixels.as_mut_ptr())?;           // bmPlanes=1, bmBitsPixel=32 (SelectObject will crush if I set he bits to 24!)

    let mut bitmap = winsafe::BITMAP{
        bmType: 0,
        bmWidth: 0,
        bmHeight: 0,
        bmWidthBytes: 0,
        bmPlanes: 0,
        bmBitsPixel: 0,
        bmBits: std::ptr::null_mut(),
    };
    h_bmp.GetObject(&mut bitmap)?;
    let h_dc = HDC::NULL.CreateCompatibleDC()?;
    let _g_bmp = h_dc.SelectObject(&*h_bmp)?;
    let dhwnd = HWND::GetDesktopWindow();  //Get the Screen and display
    let h_ddc = dhwnd.GetDC()?;
    let deskd = dhwnd.GetClientRect()?;
    h_ddc.BitBlt(POINT::new((deskd.right-bitmap.bmWidth)/2, 0),
        SIZE::new(bitmap.bmWidth, bitmap.bmHeight),
                &h_dc,POINT::new(0, 0),co::ROP::SRCCOPY)?;
    Ok(())
}

With the above GDI functions, I can successfully display pure BMP file, but not the decoded bmp data from a JPG file. So I have to try StretchDIBits (which supports JPG naturally) instead. So I hope StretchDIBits can be included in winsafe. I really don't want to bother with the winapi or windows-rs because they are unsafe. Thank you!

I understand. I ended up using Direct2d instead of Gdi, so no longer an issue for me. I can only imagine how hard it must be to make the whole API safe. Thanks for the hard work!


UI thread update

Hello,
Can you give you me some guidance on how to update WinForm controls on the projected screen? For example, I have a button in MainForm(pc screen), and after clicking that button, I want to change the text on a label in Form1(projection screen). It works if the button is in Form1, but not when it's in MainForm.
Thank you.

I've tried calling invalidate, refresh, update, begininvoke, application.doevents, but none of these fixes the problem.

 I should be doing work in ProjectorForm. For anyone who wants to update the UI on the projection screen via the pc screen (MainForm), see the following example:
In MainForm:
public event LabelTextChangedHandler LabelTextChanged;
public delegate void LabelTextChangedHandler(string text);
your button click handler
private void button_Click(object sender, EventArgs e)
{
this.LabelTextChanged("some_text");
}
In ProjectionMappingSample.cs:
foreach (ProjectorForm form in this.projectorForms)
{
MainForm mainForm = userViewForm as MainForm;
mainForm.LabelTextChanged += form.On_LabelTextChanged;
}
In ProjectorForm:
public void On_LabelTextChanged(string text)
{
this.label1.Text = text;
this.label1.Invalidate();
}


Removed magic number, made some strings that are displayed to user cl…

…earer.

Coverage remained the same at 85.349% when pulling<PHONE_NUMBER>ad5502e76e174363ca336612c30734 on ritchielq:fri into cc72d50d83b4e42285f257e1027a63e1fb784550 on CS2103AUG2017-W14-B2:master.


unable to add user

Describe the bug
I'm unable to create/add a user to podfetch (or maybe I'm trying it the wrong way).
How I tried it
docker run -it samuel19982/podfetch:dev-postgres ./podfetch users add

I get the following correct output
Debug file located at /home/rust/src/target/armv7-unknown-linux-musleabihf/release/build/podfetch-7807c2de0c7f333a/out/built.rs
Starting from command line
User management
Enter your username:

but as soon as I enter a username it errors out with
Connecting to sqlite://./db/podcast.db
thread 'tokio-runtime-worker' panicked at 'Error connecting to sqlite://./db/podcast.db with error missing "=" after "sqlite://./db/podcast.db" in connection info string
', src/config/dbconfig.rs:48:29
note: run with `RUST_BACKTRACE=1` environment variable to display a backtracethread 'main' panicked at 'TODO: panic message: JoinError::Panic(Id(3), ...)', src/main.rs:130:18

Reproduction
docker run -it samuel19982/podfetch:dev-postgres ./podfetch users add
System Info
System:
    OS: Linux 5.15 Debian GNU/Linux 11 (bullseye) 11 (bullseye)
    CPU: (4) arm ARMv7 Processor rev 5 (v7l)
    Memory: 275.34 MB / 999.02 MB
    Container: Yes
    Shell: 5.1.4 - /bin/bash
  Binaries:
    Node: 19.9.0 - /usr/local/bin/node
    npm: 9.6.3 - /usr/local/bin/npm

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
[X] The provided reproduction is a minimal reproducible of the bug.

Thanks for the bug report. If you have a Postgres instance running you can execute docker exec -it <your-container-name/container id> /app/podfetch users add
You can get the id by executing docker ps

worked perfectly.
thanks for your Help!

You're welcome. I added the command to the docs so that other users won't be confused either. Thanks for pointing that out.


Remove version: Jackett.Jackett version 0.21.950

404 - release deleted
Microsoft Reviewers: Open in CodeFlow

URL: https://github.com/Jackett/Jackett/releases/download/v0.21.950/Jackett.Installer.Windows.exe
Response Error: The remote server returned an error: (404) Not Found.
(Automated message - build 918)

URL: https://github.com/Jackett/Jackett/releases/download/v0.21.950/Jackett.Installer.Windows.exe
Response Error: The remote server returned an error: (404) Not Found.
(Automated message - build 918)


solution is not optimal - problem of rotation

Here are three cubes with the length\width\height as 210\110\180.
the container length\width\height is 400\220\220
If I input the value with L\W\H as 210\110\180, the model gives me the sub-optimal result, in which the container can only contain two cubes.

If I input the value with L\W\H sequence as 110\210\180, the model gives me the optimal result, in which the container can contain all three cubes.

The question is: why cannot the model perform the automatical rotation to accomodate all three items in order to get the optimal solution? Is this the current limitation, or we can configure it to do this work better?

This project is not optimized and uses similar expert rules. If you have doubts about this, please refer to the original repository paper.
At the moment I don't have time to modify the binning rules into optimization methods (eg genetic algorithm or particle swarm optimization), but maybe you can try.


👊 👊 🍖

Trying to get commits from https://github.com/gratipay/gratipay.com/pull/4613 into some kind of usable review pipeline. I'm in a mess with Braintree remote API creds during testing and VCR (re)recording.

We have two sets of creds, one in defaults.env, the other in tests/defaults.env (added in 6d8b0a14086348c260d1690739295f0654a8f6c1, I think just for convenience).

VCR cassettes intermingle Braintree API calls with all of the other API calls, so if we want to rerecord all of the Braintree APIs then its work to do that without rerecording the other API calls. I mean, we rerecord whenever we CI master at Travis and that appears to be green so it should work, right?

The problem I'm hitting is that the account represented by the creds currently in tests/defaults.env doesn't have the custom field I need in order to record these new API calls against it.

Why does it not work to rerecord existing tests against a new Braintree account?

Oooh! Was there some special casing for BillingHarness? A need to run that in a special way by itself or something?

$ gs
 D tests/py/fixtures/BillingHarness.yml
 D tests/py/fixtures/ConsumeChangeStreamTests.yml
 D tests/py/fixtures/TestElsewhere.yml
 D tests/py/fixtures/TestFriendFinder.yml
 D tests/py/fixtures/TestHistory.yml
 D tests/py/fixtures/TestNMassPays.yml
 D tests/py/fixtures/TestNewTeams.yml
 D tests/py/fixtures/TestPages.yml
 D tests/py/fixtures/TestPayday.yml
 D tests/py/fixtures/TestPayin.yml
 D tests/py/fixtures/TestRoutes.yml
 D tests/py/fixtures/TestTeamEdit.yml
 D tests/py/fixtures/TestTeams.yml
 D tests/py/fixtures/TestsWithBillingHarness.yml
$

Ah! Need the old custom_field, ya?

Appears that way ...
(Pdb) result
<ErrorResult 'Custom field is invalid: participant_id.' at 10ce54890>
(Pdb)

... but ...

🤔

Am I hitting the right account?

I went to check production to see how it's set there. I guess I typed the password wrong because I got "Your account is now locked out. Please wait 30 minutes and try again." For one bad password attempt? 😳

False alarm! gratipay vs. gratipay_

Production

Sandbox

Oh! Need to re-record. 😊

(Pdb) result
<SuccessfulResult {customer: <Customer {first_name: None, last_name: None, id: u'[]'} at []>} at []>
(Pdb)

💃

Okay! How many tests does that fix? 😁

Gah! Now hitting 'Gateway Rejected: duplicate', something I saw on #4613 and reported to Braintree support—don't expect that from sandbox requests.

Workaround over there is purge sandbox (takes a few minutes).

(And, helpfully, doesn't whack custom fields. 👍 )

(I've logged out of production. Better not go back in there tonight except hopefully to set the custom field!)

Aaaaaand of course my wireless interface died again. 🐭  Happened a couple days ago, too. Getting worse. Had to reboot several times and actually power down and back up. Skin of our teeth, @Gratipay!

Yeah, okay, back to these duplicates. :-/
I guess let's purge the sandbox and try again?

/me kicks that off ...

Okay, I'm back in. Rerunning ...

Skunked.
================================================== FAILURES ==================================================
_______________________________ TestsWithBillingHarness.test_capch_full_amount _______________________________
Traceback (most recent call last):
  File "/Users/whit537/personal/gratipay/gratipay.com/tests/py/test_billing_exchanges.py", line 115, in test_capch_full_amount
    assert error == ''  # sanity check
AssertionError: assert 'Gateway Rejected: duplicate' == ''
  - Gateway Rejected: duplicate
-------------------------------------------- Captured stdout call --------------------------------------------
pid-768 thread-140736820274112 (MainThread) Holding 2091 cents ($20.00 + $0.91 fee = $20.91) on Braintree for obama ... failed: Gateway Rejected: duplicate
_____________________________ TestsWithBillingHarness.test_capch_partial_amount ______________________________
Traceback (most recent call last):
  File "/Users/whit537/personal/gratipay/gratipay.com/tests/py/test_billing_exchanges.py", line 126, in test_capch_partial_amount
    assert error == ''  # sanity check
AssertionError: assert 'Gateway Rejected: duplicate' == ''
  - Gateway Rejected: duplicate
-------------------------------------------- Captured stdout call --------------------------------------------
pid-768 thread-140736820274112 (MainThread) Holding 2091 cents ($20.00 + $0.91 fee = $20.91) on Braintree for obama ... failed: Gateway Rejected: duplicate
_____________________________ TestsWithBillingHarness.test_capch_too_high_amount _____________________________
Traceback (most recent call last):
  File "/Users/whit537/personal/gratipay/gratipay.com/tests/py/test_billing_exchanges.py", line 134, in test_capch_too_high_amount
    assert error == ''  # sanity check
AssertionError: assert 'Gateway Rejected: duplicate' == ''
  - Gateway Rejected: duplicate
-------------------------------------------- Captured stdout call --------------------------------------------
pid-768 thread-140736820274112 (MainThread) Holding 2091 cents ($20.00 + $0.91 fee = $20.91) on Braintree for obama ... failed: Gateway Rejected: duplicate
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

TestPages.yml is the only file that mixes Braintree with other API requests.

Alright, I think we should re-record all of the files that have Braintree in them.

That should get me back on track to record new tests under https://github.com/gratipay/gratipay.com/pull/4613.

$ gs
 M tests/py/fixtures/TestPages.yml
?? braintree.log
$ rm `cat braintree.log `
$ gs
 D tests/py/fixtures/BillingHarness.yml
 D tests/py/fixtures/TestHistory.yml
 D tests/py/fixtures/TestNMassPays.yml
 M tests/py/fixtures/TestPages.yml
 D tests/py/fixtures/TestPayday.yml
 D tests/py/fixtures/TestPayin.yml
 D tests/py/fixtures/TestRoutes.yml
 D tests/py/fixtures/TestsWithBillingHarness.yml
?? braintree.log
$ rm braintree.log
$ ack braintree tests/py/fixtures/
$

Okay! I hand-edited TestPages.yml to remove the Braintree calls. So they're all gone from the fixtures now, and a re-run should repopulate them all. Lessee!

Hmmm ... 🤔
tests/py/test_pages.py ...............F..........F.F.................

While I wait ... I went through our production processing settings (and then logged out of production again). We actually do have duplicate checking turned on there as well. The only other discrepancy is we don't have PayPal turned on in production, so I turned that off in the sandbox as well.

I think the failures are because the cassette exists. Isn't there a mode that adds new tests to an existing cassette?
http://vcrpy.readthedocs.io/en/latest/usage.html#record-modes

Let's try new_episodes?

Yeah, that's it. Okay!
CannotOverwriteExistingCassetteException: No match for the request (<Request (POST) https://api.sandbox.braintreegateway.com:443/merchants/bk8h97tqzyqjhtfn/customers>) was found. Can't overwrite existing cassette (u'/Users/whit537/personal/gratipay/gratipay.com/tests/py/fixtures/TestPages.yml') in your current record mode (u'once').
============================= 3 failed, 992 passed, 34 xfailed in 413.22 seconds =============================

========================================= 46 passed in 41.22 seconds =========================================
$ gs
 M tests/py/fixtures/TestPages.yml
?? tests/py/fixtures/BillingHarness.yml
?? tests/py/fixtures/TestHistory.yml
?? tests/py/fixtures/TestNMassPays.yml
?? tests/py/fixtures/TestPayday.yml
?? tests/py/fixtures/TestPayin.yml
?? tests/py/fixtures/TestRoutes.yml
?? tests/py/fixtures/TestsWithBillingHarness.yml
$

Moving to PR in https://github.com/gratipay/gratipay.com/pull/4616 ...

Back to resolve Travis issue ...

Two of the tests are trying to add calls to the cassette.
test_on_the_fence_can_browse
test_new_participant_can_browse

What's the diff between local and CI envs that is causing this?

The _browse tests do a lot ... notably the anon case is fine.

on_the_fence is failing early in browse when we try to pre-pop the receipt page.
new_participant is failing in routes/credit-card.spt.

Hmm ... each fails locally when run individually ... both on routes/credit-card.spt 🤔

Run together the two fail as at Travis.
$ ARGS="tests/py/test_pages.py" t

Seems easy enough to record and add, but why didn't they get added in the first big re-record?

Re-run of all of tests/py/ fails in the same way.

Repurposing this ticket to be my verbose log for shipping https://github.com/gratipay/gratipay.com/pull/4598 in the next ... three hours?

Reviewing work to be done ...

Okay! https://github.com/gratipay/gratipay.com/pull/4616 is green! I'm going to merge #4614 and #4616, and then rebase the #4598 chain.

Done. Almost done organizing tickets ...

Alright, so that's four more PRs needed against #4598:

error checking
optional
receipt
ToS

Okay! 👊 👊 🍖

Debating whether to self-review-and-merge the four ready PRs on #4598 or start into new work and then review/merge all eight at once. Eight sounds like a lot, thinking let's get these four in now.

I mean, Travis will take half an hour to run anyway.

Which actually raises a good point: optimization is to merge the last in the chain that is ready to merge, to avoid the rebase-and-wait-for-Travis dance overhead.

Re: dance overhead: https://www.youtube.com/watch?v=ovo6zwv6DX4.

Alright, 4-chain updated, go Travis go! I know there are a couple things to fix on https://github.com/gratipay/gratipay.com/pull/4617, what about the others?

#4606 is fine, #4604 is what #4617 exists to fix. Knocking out #4617 issues ...

#4606 is green but #4604 ain't. What gives?

Probably will need to bump #4609 back off in the interest of time.

Errors, receipt, terms. Next chain!

Sup with https://github.com/gratipay/gratipay.com/pull/4604 tho?

Okay, fixed.
I can do a simpler optional rationalization (no folding, just the two sections) on #4613.

#4604 is green, almost have #4617 ready.

Alright, #4617 over to Travis, hitting #4613.

#4617 is green! I am modifying/extending functionality on #4613.

slack

Alright, squeezing out last little bit of CI floofle on #4621 and then the new three-chain is ready for final review and merge. 👍

Landed #4598!


Don't work when .git placed in parent directory

Hi! Thanks for amazing solution of hooks implementation for node.js. But could you add support for cases when .git placed in parent directory relative to package.json?

:+1:

:+1:

@Swaagie Any thoughts on this? I'm neutral about it.

:+1: I have separate parts of the project within a single repo, this will solve the issue.

I guess we could make this functionality opt-in by specifying the max depth that we can search for a .git folder.

The only complication I can see, if I have multiple projects in a repository in subfolders that use pre-commit.

@tuhoojabotti That's why I'm suggesting opt-in through a field in the package.json

Yeah, I don't see an issue with that, but would it be possible to run the pre-commit hooks of all packages in sub folders? For example if I have a package.json file for both my back-end and front-end I would like to run both pre-commit hooks before allowing commit.

:+1:

+1

+1

Happy to give it a shot and create a PR. Could I get a hint please which part of the code to start with?

@kosmotaur Probably the installation script of this module: https://github.com/observing/pre-commit/blob/master/install.js#L23-L28 as it checks if the parent folder has .git

Btw, when using git submodules there will be a file named .git in the same folder that will have a relative path to where the submodule real .git folder is.
Maybe this should be checked as well

:+1:

Hello, we suffer from the same issue here, and I would like to know if there is some kind of improvement to come (like the opt-in suggested by @3rd-Eden) ?

This would be a great feature, especially for use with mono-repo projects like Lerna. Is there any plans to merge #55, or ways we can pitch in?

+1 Has this been addressed somehow ?

+1!

We need this fix in my project with lint-staged.
I think it is very important for big projects with monorepo, when you have client/ and server/ subdirs.
@3rd-Eden how I can help with this issue?

This project sets up hooks which will work when .git is in a parent directory

👍

I have a .git that's in a parent directory and it seems it's not detected by pre-commit which siletely fails when I installed it.
I tried creating a fake .git/hooks directory in the child directory where I run the npm installation and it works then.
Reading the comments I thought this was fixed?


Update 1.0 branch for 1.0.3 release

This is a cherry-pick of commits from the v1.0.1 release to just before we merged in the working group results, and a few additional Go and CI fixes after that. The v1.0.1 release was picked because there were changes during the past 5 years that were not included in the v1.0.2 security fix.
The following should be on the list of PR's included in this update:
decdb1500673e7ef4fd912e0741f67a49e35d502 Merge pull request #951 from sudo-bmitch/pr-go-1.17
d2cc46db009a50a4677d4b287c882e5f68946a61 Merge pull request #944 from austinvazquez/remove-ioutil-dep
50b6194995ebfd16d933ce16064898d6b7f60249 Merge pull request #941 from sudo-bmitch/pr-spec-components
ff0257194e20f7fd17ca21c67a2e725f21c4d4f2 Merge pull request #934 from oci-playground/pr
d265d74f4fad249d39fe092122f53c7998afbfe9 Merge pull request #897 from vbatts/another_adopter
c27355a1c248f8a1d5971d354ae8ace3a6e795b3 Merge pull request #932 from sudo-bmitch/pr-implementation-regclient
f3096cf36396f9201c6ff730c77a8f9ce97390ac Merge pull request #911 from jdolitsky/sajay
20147710b9f272258709b92963550ce093e5c9bc Merge pull request #909 from jdolitsky/brandon
6ad7100eb087e43398e9ea8fe44fffc1501b8984 Merge pull request #919 from nishakm/912-maintainer-template
7b36cea86235157d78528944cb94c3323ee0905c Merge pull request #917 from sudo-bmitch/pr-gha-lint
868548600fee7e58654b2f71f8f5b30557eb29ca Merge pull request #915 from sudo-bmitch/pr-https
37d82a265892e0efe5deac1bc462bce5efd00b34 Merge pull request #910 from jdolitsky/old-maintainers
02efb9a75ee11e05937b535cc5f228f9343ab2f5 Merge pull request #900 from michaelb990/main
8205360b72afd0613e3823bbf978117f78274bd1 Merge pull request #885 from stevvooe/use-embed
9716dee6767f0eaaca3740b1dcb734104e3aa882 Merge pull request #898 from sudo-bmitch/pr-broken-link
bac4452888988085f263a61379c521abfd3472cf Merge pull request #826 from jonjohnsonjr/data
1f308fd27264a52f6a089202b1ff9dc15ff27398 Merge pull request #896 from vbatts/implementations
ea0209f50ae1a3707cff054cdb6b7487050487de Merge pull request #887 from sanshirookazaki/fix-readme
eacdcc10569b68a90558220b29d115363a26790c Merge pull request #871 from wyckster/patch-2
a9fdc379302f4827183c84e368e79bdfe0225803 Merge pull request #884 from vbatts/fix_lint
a5463b7f9c8451553af3adcba2cab538469df00c Merge pull request #883 from vbatts/carry_810
679348323e1d2e9d9a84191bf5ffdc0a49576739 Merge pull request #882 from bloodorangeio/why-u-pull-quay
b52c1724c3ceb54799d47952c855d508b9e967cd Merge pull request #879 from opencontainers/lint-fixes
c5a74bcca799bef045e7fbe74e1b75580fd18d4c Merge pull request #878 from opencontainers/v1.0
43a7dee1ec31e0ad091d2dc93f6ada1392fba587 Merge pull request #869 from SteveLasker/add-acr
9a7a9876500e4de43a25acde2543a4267d9a31dc Merge pull request #875 from SteveLasker/docker-distribution
54a822e528b91c8db63b873ad56daf200a2e5e61 Merge pull request #873 from jpetazzo/fix-config-example
5ad6f50d628370b78a4a8df8a041ae89a6f0dedc Merge pull request #817 from AkihiroSuda/docker-oci-diff
8e42a01fb1b7aa6f9983d5f987bcd17873f15f2e Merge pull request #822 from imjasonh/patch-1
fe0a24978a6629f4b7159928e538dda36c7cec8e Merge pull request #809 from cpuguy83/image-platform
91bc345d66e1647a5f38cb388ce5d122ba3fe436 Merge pull request #863 from vbatts/rm-pullapprove
5ced465cc63831baf25330431a428a9d9444e192 Merge pull request #856 from vsoch/patch-1
d9aa673866f5eaaf54cd036e4ea06fef305d39a2 Merge pull request #793 from vsoch/fix/descriptor-branch-comments
fe7b3949255430200eac96950e54cba088bfcb44 Merge pull request #824 from AidanDelaney/patch-1
93e69bcb362ae54a5fe8e0398da3294f890dccb4 Merge pull request #800 from zhsj/remove-go4
083f635f2b04f7f340685a1e0c4393a0feec3679 Merge pull request #860 from lucianoqueiroz/add-background-to-png-imgs
85c28d797bcf49c7aa5e3b45626df5a217dbc2d7 Merge pull request #858 from vbatts/codeowners
f18daf27c37a3e5e5f79e0d17ebcc051d8a34775 Merge pull request #855 from jonjohnsonjr/typo
81270cdee5c47c0f05168e5521830787d71aa50d Merge pull request #813 from Iduoad/master
8d2a44c9c39fb1c749ed51915aa80ce2416e178b Merge pull request #846 from vbatts/oci-container
32e130c75417b86fb31aa7b5e57b928442e46cf0 Merge pull request #848 from vsoch/add/github-workflows
daf51542d53813621913dde9bf438bd9c1fe32c8 Merge pull request #849 from jonboulle/master
269c1c5e1dca62a25c5fa94929776d758f5373ab Merge pull request #832 from ImJasonH/patch-2
859973e32ccae7b7fc76b40b762c9fff6e912f9e Merge pull request #814 from vbatts/change_image
775207bd45b6cb8153ce218cc59351799217451f Merge pull request #790 from vrothberg/add-zstd-constants
9f4348abedbe4415e6db1f08689fa7588045d982 Merge pull request #788 from giuseppe/zstd
d1109113f99146dcabbc1882f8838415971b48c8 Merge pull request #786 from estesp/meeting-ref
6943c5f4c9d29193b36596127c1efb02350b1fcc Merge pull request #757 from unasuke/fix_typo
ae1010f0bb27658e9f040391c7b20bb8aa4237aa Merge pull request #782 from odinuge/lint-issue
da296dcb1e473a9b4e2d148941d7faa9ac8fea3f Merge pull request #772 from woernfl/patch-1
243ea084a44451d27322fed02b682d99e2af3ba9 Merge pull request #759 from jzelinskie/loosen-mediatypes
09950c5fb1bb6745e72aa26ecde0d540e35f5286 Merge pull request #753 from HaraldNordgren/go_versions
b6e51fa50549ee0bd5188494912a7f4c382cb0d4 Merge pull request #740 from francescomari/fix-link
e562b04403929d582d449ae5386ff79dd7961a11 Merge pull request #716 from AkihiroSuda/index-is-required
149252121d044fddff670adcdc67f33148e16226 Merge pull request #739 from mtrmac/id-based-loader
577479e4dc273d3779f00c223c7e0dba4cd6b8b0 Merge pull request #736 from AkihiroSuda/bump-up
89b51c794e9113108a2914e38e66c826a649f2b5 Merge pull request #728 from q384566678/add-ln
Note the DCO issue will need to be ignored because it exists in our main branch today for a minor update to email addresses.
Fixes #918

Was there there a reason not to tag the next release from the main branch? I think the v1.0 branch was purely created (temporarily) to do a security release without pulling in upcoming changes from main; while it may serve purpose to backport specific critical fixes to a v1.0.x release, I would consider tagging the next release from main instead

We'd still need a branch for some Go and CI fixes that can't be tagged on main without pulling in the working group changes. Given that even v1.0.1 was released from the branch, I'm still trying to understand the normal release process.

can't be tagged on main without pulling in the working group changes

Does that work contain backward incompatible changes, or is that because it's not yet complete? Mostly wondering if there's a need to have an "LTS-like" v1.0 branch if a v1.1.0 release is being worked on. Go modules doesn't work well (or at all) with release branches (if bases any pseudo version it creates on "last semver(ish) tag on the default branch"). Tagging releases from a release branch, not from the "default" branch, will make those tags be ignored, so (e.g.) when tagging v1.1.0 from the v1 branch, the main branch will still be versioned v1.0.1-<date>-<commit>.

Given that even v1.0.1 was released from the branch

It wasn't created from the branch; https://github.com/opencontainers/image-spec/commit/d60099175f88c47cd379c4738d158884749ed235 is in main (and was merged as part of https://github.com/opencontainers/image-spec/pull/734). It probably shows up as "part of" the v1.0 branch because that branch was created later on from the v1.0.1 tag ( in preparation of v1.0.2).
If I recall correctly, the v1 branch was created specific for the security release; normal releases would come from the default branch, but as v1.0.2 was a security release, the intent was to only contain those changes, so the (temporary) branch was  created from the v1.0.1 tag. The intent at the time was to merge the security fix into the v1.0 branch, then merge the v1.0.2 tag back into main, which happened in https://github.com/opencontainers/image-spec/pull/878 (after which the v1.0 branch probably should've been deleted).
Unfortunately something went wrong in the process of publishing the advisory, as the temporary GitHub security fork contained two PR's; one targeting the v1.0 branch, and one targeting main (which should've been closed); when publishing the advisory, both PR's were merged automatically, so there were now two distinct commits with the security fix;

https://github.com/opencontainers/image-spec/commit/0126d30a90249ba624d134266b662e1d661381f5
https://github.com/opencontainers/image-spec/commit/693428a734f5bab1a84bd2f990d92ef1111cd60c

git log --grep GHSA-77vh-xpmg-72qh
commit 0126d30a90249ba624d134266b662e1d661381f5 (upstream/v1.0)
Merge: d600991 e3885ce
Author: Vincent Batts<EMAIL_ADDRESS>Date:   Wed Nov 17 13:12:56 2021 -0500

    Merge pull request from GHSA-77vh-xpmg-72qh

    Advisory fix 2

commit 693428a734f5bab1a84bd2f990d92ef1111cd60c
Merge: 9a7a987 6ced3bd
Author: Vincent Batts<EMAIL_ADDRESS>Date:   Wed Nov 17 13:12:55 2021 -0500

    Merge pull request from GHSA-77vh-xpmg-72qh

    *.md: bring mediaType out of reserved status

@sudo-bmitch can we close this PR? what's the status here?

I can think of 3 options:

Refuse #918 and close this.
Accept this and tag a v1.0.3.
Move the1.0  branch off of main rather than cherry picking into the branch. There would still be some cherry picked commits to include from after the WG additions to allow CI to pass.


feat(barchart2) new barchart with group feature

I modified the barchart to support adding multiple bars from different data set
see the the following image:

if this feature is needed, then I can continue and write some unit tests

I'm not sure how this compares to current barchart, implementation wise, but maybe it could be solved by adding a method/flag to the current barchart, instead of introducing a new widget?

true I changed the old barchart. it should be backwards compatible

I like the idea and direction - perhaps consider documenting the user's perspective a little before continuing into the code. (It's important to tell us what you want to do, so that when it's complete, it's obvious).
I notice that this adds a new "Group" feature, but "Group" only appears in the API once. How would you design the API so that it made this feature more explicitly obvious?
I think it's probably possible to keep the single data() function, and expect the user to call it multiple times rather than adding a new add_data() function which is confusingly similar.
Can you please make an issue for this to discuss the functionality of the new feature? (Would be nice to get a few more eyes on it).

I think it's probably possible to keep the single data() function, and expect the user to call it multiple times rather than adding a new add_data() function which is confusingly similar.

true. the problem with data(), that it passes always one dataset with the labels. the labels should be the same for all datasets. so if the user calls data() twice. the first time I can store the labels. and the second call should I ignore them?
possible Solutions:

remove data() and rename add_data() to data(). this is not backwards compatible solution. labels can be passed by the function labels() instead of the old data()
maybe I can modify data() to pass all datasets at once and stay backwards compatible too. I will check this possibility
keep the same data() and add new function add_data() which adds only one data set. (current solution)

the following 2 code sections produces the same result:
BarChart::default()
        .data(&[("Mar", 9), ("Apr", 12), ("May", 5), ("Jun", 8)])
        .add_data(&[1, 2, 3, 4])
        .group_gap(4);

BarChart::default()
        .add_data(&[9, 12, 5, 8])
        .add_data(&[1, 2, 3, 4])
        .group_gap(4)
        .labels(&["Mars", "Apr", "May", "Jun"]);

Can you please make an issue for this to discuss the functionality of the new feature? (Would be nice to get a few more eyes on it).

done

(disregard the second review, for some reason my review got posted twice)

Finally you have a little bug in your example where the bar colors are applied to parts of the legend's border.

this is feature not a bug :smile: .  But it is fixed. (there still is another hidden small bug in the legend :smile_cat:, but this MR is about the BarChart )
I renamed Group to BarGroup, because I think Group is too general term

The truncate approach seems more difficult to reason about as it changes fields outside of the method to communicate with other methods. (This is like Alice calling Bob on the phone to tell him something then calling Carol and asking her to ask Bob for the information just provided)

Preprocessing data before working on it, is very common approach. I don't think the Alice bob and Carol example is very accurate :smile: .

I think I can sort of see how the code landed there, but the following general approach (using a remaining area Rect to render the bar / group into) might help make this code clearer:

you are suggesting a third method, which is in my opinion worse than the truncate and filtering methods, which are both very similar. here my comparison:

Truncate method

preprocess the data once. afterwards there is no chance that you are working on the wrong data, because they simply doesn't exist. There is in total 4 places where we must filter. (in the future maybe more)

Filter method

the original code had 2 loops, we need to filter twice. if someone adds a 3. loop, the chances are high, that he will forget about filtering.
with this patch we need to filter the bars too, which makes this method a little bit harder to implement. now we need to filter 2 nested loops in 2 different functions. I can't see any reason why this method is superior then preprocesing the data first

you suggestion (general approach)

every time you draw, you need to check, if there is enough space. I see 2 drawbacks. the first one: the check logic will needs to be duplicated at least twice. when printing the bars and later when printing the labels.
the second drawback: this check will be executed  in render_bars many times (area height * number of groups * number of bars inside a group) (we have 3 nested loops)
render_labels_and_values is similar. It contains 2 nested loops.
I would rather to filter or preprocess the data, than checking in every iteration, whether there is enough space. and the problem get worse with every additional loop. (code duplication)
till now you improved the code immensely, the length of that method became very short. I think most developers will understand it.  :smile:

Preprocessing data before working on it, is very common approach. I don't think the Alice bob and Carol example is very accurate 😄 .

The concept that's at play here is https://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming).
This implementation is ok only because the widget is consumed after rendering.

you are suggesting a third method, which is in my opinion worse than the truncate and filtering methods, which are both very similar

My suggested approach seems to me like it would lead to a simpler and more obvious solution with generally shorter methods that just do one thing. The difference in my mind is doing things in batches (calculate, render bars, render labels) vs doing things one by one in a nested fashion. In the batch approach, you have to understand how each part affects the whole, whereas the individual nested approach the interaction between the pieces is right there.

every time you draw, you need to check, if there is enough space. I see 2 drawbacks. the first one: the check logic will needs to be duplicated at least twice. when printing the bars and later when printing the labels.

This is a problem only because the rendering of the bars and labels is separate - if bars and their label / value are rendered at the same time then this isn't a problem.

the second drawback: this check will be executed in render_bars many times (area height * number of groups * number of bars inside a group) (we have 3 nested loops)

This check happens already, it just happens within the delete invisible method.

Merged! Thanks for your contribution @karthago1

@joshka and @mindoodoo thank you too for your help and patience :smile: . I can't wait to switch to the crate.io ratatui version at work.
The use case we have is to show the operating hours of multiple temperature sensors in different temperature ranges:
it looks similar to the following:
          ████   ████                ████
          ████   ████                ████
     ████ ████   ████ ████           ████ ████
▄▄▄▄ ████ ████   ████ ████ ████      ████ ████ ████
████ ████ ████   ████ ████ ████ ...  ████ ████ ████
████ ████ ████   ████ ████ ████      ████ ████ ████
█50█ █60█ █90█   █90█ █60█ █50█      █90█ █60█ █50█
   -40..-31°C       -30..-21°C         150..159°C

the only think I wish to do, but I don't know if it is possible, is to write the numbers vertically. (instead of horizontally)
For now I made the bars very wide so I can print the values. but I have a lot bars and I need to scroll horizontally. I don't know if it is possible to write text horizontally with ratatui.


Preset name wasn't allowing for overide.

Preset name wasn't allowing for overide.

Scan submitted to Checkmarx

Checkmarx SAST - Scan Summary & Details
Cx-SAST Summary
Total of 13 vulnerabilities 0 High 6 Medium 7 Low 0 Info
Violation Summary
 3 Medium
View more details on Checkmarx UI
Cx-SAST Details

Lines
Severity
Category
File
Link

205 222
Medium
SSRF
internal/wrappers/client.go
Checkmarx

126
Medium
Denial_Of_Service_Resource_Exhaustion
internal/wrappers/configuration.go
Checkmarx


Option to change project title from header itself

Fixes #1808
Describe the changes you have made in this PR -

Added option to change the project tile directly from the header by using input tag instead of the span tag

Screenshots of the changes (If any) -
Initial State

On Change

(If there is a change in the project title at one place, then it changes automatically at the second place)

Coverage remained the same at 87.962% when pulling 0e1307948b58a3354444e5a8a9602c8c50f4976f on dipanshparmar:new_UI into 7b3ecb4e6141c681cebf0c1533176fc2bb7e2ce9 on CircuitVerse:new_UI.

@abstrekt Please have a look at this new PR.

I messed up branches in my localhost, so I'm closing this PR and making a new one soon.


Bug: experiment.py continuous_train_and_eval() leads to overfitting

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): YES
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 14.04
TensorFlow installed from (source or binary): Source
TensorFlow version (use command below): v1.0.1-4-gbd6743e-dirty 1.0.1
Bazel version (if compiling from source): N/A
CUDA/cuDNN version: N/A
GPU model and memory: N/A
Exact command to reproduce: N/A

Describe the problem
Our team has found what we believe is a critical bug in experiment.py continuous_train_and_eval() that pretty much guarantees any model trained with this method will lead to overfitting.
The problem is that every time it alternates from evaluating to training again, it calls self._call_train(), which eventually makes it to estimator.py _train_model().
This function first creates a brand new graph then sets up the input pipelines. This necessarily means that the input pipelines are reset from scratch on every training lap, and since a training lap is typically much shorter than an epoch, this means the model is only trained with a small portion of the whole dataset.
Originally we raised this as an issue in Google's tf-seq2seq, but as far as we can tell now the bug probably belongs into Tensorflow instead, as we can't see a simple way to modify the tf-seq2seq code to avoid this issue from arising.
Thank you for looking into this matter.
Source code / logs
N/A

@jhseu Can you comment on this?  Thanks!

Yeah, that's true. Often input_fns are defined to randomize inputs, but this does seem like an issue. @ispirmustafa @xiejw

I see. In the original issue the client was calling tf.contrib.slim.dataset.Dataset() which doesn't appear to have an option to thoroughly randomize its inputs.
I'm pretty new to TF, so I may be missing lots of things here :)

Shuffle=True for train input_fn is recommended. And also it is best to make the training steps for each iteration longer, similar to the epoch size or multiple epochs. I will fix the docstring to document this.

not familiar with the slim Dataset api, but according to the docstring, there is a provider, which support randomize.

@xiejw,
Setting shuffle=true in a tf.RandomShuffleQueue would hide the problem a bit, but not eliminate it, because the "random" part of a random queue occurs when dequeuing. Since queues have a limited size, and the state is reset on every training lap, the model would still not train with the whole dataset.
It seems like the way to fix this properly is by not regenerating the graph from scratch on every training / testing lap. The graphs should be generated only once and then reused.

Experiment has a method train_and_evaluate, which does the approach you wanted. However, it has a double memory problem, which is why continous_train_and_evaluate was introduced (as experimental). Can you try make train steps for each iteration larger (so one train iteration can process one epoch training data or multiple epoch data)?
If that does not solve the problem, you probably need to try train_and_evaluate or write a hook to do evaluation by calling train().

It has been 14 days with no activity and the awaiting tensorflower label was assigned. Please update the label and/or status accordingly.


SWARM-749: Support inclusion of modules in module-rewrite.conf

Motivation
People forget adding module dependencies in WildFly and it would be nice to have them added in the module.xml descriptor
Modifications
Support include: keyword in module-rewrite.conf
Result
The module dependency is added

Done


new(tests): extending the sinsp test framework allowing to link external files

What type of PR is this?
/kind feature
Any specific area of the project related to this PR?
/area tests
Does this PR require a change in the driver versions?
No
What this PR does / why we need it:
Extending the sinsp test framework allowing to link external files and add external includes could become very handy when using the libs repo as a submodule to implement some plugin e2e tests
Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
NONE

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, FedeDP
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97,FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 6ed03c5bfc282042c3245c70861a8ba281ff887a

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, FedeDP, leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97,FedeDP,leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


i18n(es): update rendering-modes & community-resources/content

Description (required)
updates rendering-modes & community-resources/content

Related issues & labels (optional)

Closes # N/A
Suggested label: i18n

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

es
basics/rendering-modes.mdx
Localization changed, will be marked as complete.

es
community-resources/content.mdx
Localization changed, will be marked as complete.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

Heads up we're missing this commit here: https://github.com/withastro/docs/commit/094896e2e83e90dbbfeda747976cf2975ec34cdd

Thanks for the review @yanthomasdev 😁


Error while using early_stopping

Hello
Today I tried to use early_stopping feature (as here), and I found that my current skflow cannot find the keyword early_stopping_rounds.
I tried to reinstall skflow but it cannot upgrade because the version are the same (0.0.1). I have to first uninstall skflow then install it again.
So I think it would be good to update the version of skflow to update easier.

That's only minor addition so it doesn't make sense to make a new version out of it. You'll have to uninstall it first.

Well, I have a different idea, but anyway ...
Thanks for your comment

Thanks for trying the new feature :-) We are developing fast so it's hard to do what you suggested. We'll do it soon though once the project is more stable.

Yeah, at least I think it is good to mention it somewhere for other users to know how to get the new features :-P


quit button fix

Quit button should not be interactable with if you are performing a search simulation.

Issue solved


Deprecate ExpectedException.none() in alluxio.client

ExpectedException.none() is deprecated in JUnit 4.13. It's recommended to change it to Assert.assertThrows.
package org.junit.rules;
public class ExpectedException implements TestRule {
    /**
     * Returns a {@linkplain TestRule rule} that expects no exception to
     * be thrown (identical to behavior without this rule).
     *
     * @deprecated Since 4.13
     * {@link org.junit.Assert#assertThrows(Class, org.junit.function.ThrowingRunnable)
     * Assert.assertThrows} can be used to verify that your code throws a specific
     * exception.
     */
    @Deprecated
    public static ExpectedException none() {
        return new ExpectedException();
    }

Considering the number of tests to update, I will do this module by module. This PR takes care of the client package.

@gpang We have many tests using ExpectedException.none(). If it makes sense to you, I will update the rest of usages in this PR.

@jiacheliu3 Will that take a long time? We don't have to do all of them at once if it is too many.

@jiacheliu3 Will that take a long time? We don't have to do all of them at once if it is too many.

@gpang Sounds good to me. We do have a few hundred. But that's low priority and can be done package by package anyways.

Codecov Report

Merging #12840 (8cf9d00) into master (452c9d3) will decrease coverage by 38.07%.
The diff coverage is n/a.

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

/ping @apc999

Codecov Report

Merging #12840 (829a33f) into master (5970957) will decrease coverage by 26.56%.
The diff coverage is n/a.

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

alluxio-bot, merge this please


Add "request EBI submission" button

Similar to the "request approval" button for approve the metadata. This will allow to request that with a single click, rather than contacting us. This also means a new page in the admin page

If it's private or if it's public, users should be able to submit to EBI, because the data should already be approved by an admin. Granted that the required columns are present.

Also, this should just be a "Submit to EBI" button rather than "Request EBI
Submission" button (once the study is at least private and has the
necessary columns for EBI submission)
On Wed, May 6, 2015 at 2:37 PM, Yoshiki Vázquez Baeza <
<EMAIL_ADDRESS>wrote:

If it's private or if it's public, users should be able to submit to EBI,
because the data should already be approved by an admin. Granted that the
required columns are present.
—
Reply to this email directly or view it on GitHub
https://github.com/biocore/qiita/issues/1027#issuecomment-99602035.

Superseded by https://github.com/biocore/qiita/issues/2721


PHP: fix maxOS distrib test pecl installation error

Testing to see if this works for #14760

Seems need to merge to let the macOS distrib test start running.


Deployed in the simulation environment

Hello author, I'm very interested in your research, thanks for your great job.
I see that GNM can be deployed in a simulation environment and I would like to ask you how to deploy it to the simulated environments
?

Hi,
Deploying the model in simulation should not be any different than deploying on a robot (we have tried setting up in Habitat, CARLA, and a proprietary ROS-based sim). The released code should make it particularly easy to deploy on anything that uses ROS, but you can adapt the files as needed for your simulator of choice.
The relevant files would be in the deployment subdir, more information here. You can skip the robot-specific instructions and follow from "Creating a topological graph".

@PrieureDeSion,
Speaking of deployment, is it enough to prepare image and odometry topic in rosbag file? And is the accuracy of the odometry an important factor in graph generation?

Thanks for your quick reply. This helps me a lot.


issue:test get_chunk fail

https://github.com/gdassori/spruned/blob/aacff7a30c9b834c35700d2d908befac4fc8bbdb/spruned/daemon/electrod/electrod_connection.py#L199
https://github.com/gdassori/spruned/blob/aacff7a30c9b834c35700d2d908befac4fc8bbdb/spruned/daemon/electrod/electrod_interface.py#L125
doesn't handle correctly the None result and FAIL the test.

tests was broken due peer propagation to the reactor.
peers propagation is needed to make the reactor to track peers errors.
fixed in commit 3bf464cdd2652ce75916a0a302425b186442ca71


closes #28319; closes #28262; closes #27828; closes #27611; closes #2…

…2675

@pgaudet @balhoff   any idea why my pull request did not complete?


Add quick start instructions for users on Gadi

It would be useful to have all the instructions needed to run benchcab on Gadi without having to read the full explanation of each step in the documentation as this will be clearer for users to get started (see #276).
For example, we could have the following as the first section in the README or the main documentation:
Quickstart
To launch a benchcab run, execute the following in the command line:
module use /g/data/hh5/public/modules
module load conda/analysis3-unstable
cd /scratch/$PROJECT/$USER
git clone https://github.com/CABLE-LSM/bench_example.git
cd bench_example
benchcab run

Maybe add the manual edit of the config file to the list of commands?
module use /g/data/hh5/public/modules
module load conda/analysis3-unstable
cd /scratch/$PROJECT/$USER
git clone https://github.com/CABLE-LSM/bench_example.git
cd bench_example
# Edit config.yaml to your liking
vim config.yaml
benchcab run