[BI-445] Support standard Maven settings to retrieve publisher credentials

Add a serverId parameter used to lookup credentials in maven settings if not specified by the user in pom.xml
I've already accept the JFrog CLA (adobe sign)

How about this PR?

Sorry for the late response @Alemoratoa and thanks for this PR.
We like this new addition and would like to merge it.
For some reason we cannot find your signed CLA. Would you mind signing it again and let us know after signing it?
Thanks

@Alemorato,
This functionality did get merged, because we couldn't find your signed CLA. Please let us know if you'd like us to merge your code.
Thanks

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Alessandro Morato seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Send text messages

We will not implement this now since we need to:

[ ] Identity a SMS provider (such as Twilio) and understand how it works and how we could integrate it into the Portal.
[ ] Refactor senders to allow Phone senders.
[ ] User email is required when sending an email message, phone is required when sending a SMS message.
[ ] Can we send a SMS message from an HTML template?


Proposal navbar

Hey 👋🏻
Just proposing to rename label Issues in navbar by Reports
And to only display the underline on Hover to be consistent with the mobile view.
Up to you to accept or not ;)
Might be worth only moving the /issues to /reports but that would also ask probably some changes with the table name, and api routes. -- So for now, it's alright to just keep it that way.
Best

It's good, I anyway like it more without the underline so totally agree on that front. For the reports rather than issues I have no preference so if you like reports more let's keep that.


Revert "Revert "Release notes review""

Reverts harness/developer-hub#190

Preview environment: https://ci.pr.harness.io/pr-191


Feature/magic desc mime type

This change set adds the magic description and mime type to the classifier result.
To support easier test writing the artifacts have been augmented with a .json file which contains the expected classification result. Makes for much easier test case writing.

Hi,
adding MIME type to headers seems like a nice addition that could work as an alternative to current conventions (kind, type headers).
However, using libmagic output doesn't seem to be a good fit for headers. In some cases, its too specific (timestamps, size).
For example:

Microsoft Cabinet archive data, Windows 2000/XP setup, 235156 bytes...

gzip compressed data, was "Order 002_PDF.exe", last modified: Thu Apr 30 23:25:26 2020, ....

When writing a karton service, you'd have basically no way to listen for such tasks - you can't use wildcards in headers.
Do you have any specific usecase for this? Maybe moving magic to payload would be a better idea?

Sounds like moving magic to a payload is the way to go. What do you think about the mime? That seems reasonable, since that can be used for routing.

Yup, mime in headers sounds good :)

Superseded by #23


Disable Omnibus git cache for Windows builds

What does this PR do?
Disables the Omnibus git cache for Windows.
Motivation
#incident-33348: Windows builds broken by unexpected caching behavior.
Describe how you validated your changes

Possible Drawbacks / Trade-offs
Additional Notes

/merge


chore(EditorConfig): enable insert_final_newline

This change is

@homu r+

:pushpin: Commit f464a4f has been approved by saneyuki


Delay after Click cross button on Powershell window

Environment data
PS version: 5.1.14409.1012
PSReadline version: 2.0.0
os: 6.1.7601.17514 (win7sp1_rtm.101119-1850)
PS file version: 10.0.14409.1005 (rs1_srvoob.161208-1155)
Steps to reproduce or exception report

start Powershell -noprofile
PSReadLine autoloaded
Close PS window by mouse pressing cross button
PS Window closes after 5-7 seconds

when exit typed, PS closes fast
when old version (v1.2) of PSReaLine used, PS closes fast

Thanks for the detailed bug report - it was a bit of a pain to track down because:

it didn't reproduce on Win10
this was an old problem and there were recent code changes near the original fix - leading me in the wrong direction for a bit
you can't debug this problem, the OS kills the process before you really get a chance to debug
I didn't believe git bisect - because it was such a small commit that seemed harmless

At any rate, I believe it's fixed now.


Initial support for android

I'm interested to use client from the native code on Android. Haven't tried it yet on real device, but it compiles.

Thank you for your offer of android support.
However, one of my aims is to keep the library small and simple.
Adding a 1688 line file just to support the android tool chain, certainly does not meet that aim!


Fill out section on modifying document

Taken from Jupyter and removed BDFL, jupyter->pangeo-data

I would say that the public comment period should be proportional to the size of the change. Major changes should be left open for comment for at least two weeks.

Updated.


Question: Close bot when finished i.e. .quit()

Question:
Is there a method to close / quit a bot once it has been started up? i.e. to send a one-shot message.

Agree here. I was trying to use this in a CLI tool and, with the open websocket connection, just hangs forever after my one shot attempt to postMessage.


Consider:
$ cat go.mod
module example.com/m
$ cat p.go
package p; import "cmp"; var _ = cmp.Less(1, 2)

The error message that go test prints is consistent with that (provided it's not due to #63489):
$ go test
# example.com/m
./p.go:1:34: implicit function instantiation requires go1.18 or later (-lang was set to go1.16; check go.mod)

But when doing something like go get<EMAIL_ADDRESS>(or go mod tidy), the module appears to behave as if it implicitly had the go command's version instead of 1.16.
What did you expect to see?
$ go get<EMAIL_ADDRESS>go: upgraded go 1.16 => 1.20
go: added toolchain go1.21.3

What did you see instead?
$ go get<EMAIL_ADDRESS>go: downgraded go 1.21.3 => 1.20
go: added toolchain go1.21.3

CC @rsc, @bcmills.

The downgraded message is definitely misleading, and we should definitely fix that. 😅
The asymmetric behavior is intentional, though. When we first introduced the go directive we had the property that commands that add it always add the current version, not an old version. But we also have compatibility to contend with, meaning that a go command in a very old repo should use the semantics appropriate to that repo.
Those two goals are in tension, and the way we resolved that tension is: if we are going to write out a go version in a module that did not have one, we write the current version, but if we are not going to write it out we assume an old (and very widely compatible) version.


Fixes #377 | resolve_function_from_operation_id hides cause of import…

Fixes #377 by extending the log message if there's an ImportError.

Coverage remained the same at 100.0% when pulling f995208c68b75886082dd6cc87043adb7f869f4e on danballance:show-cause-of-import-error into 476fc691ff80167c3e4a66f782ce259bb2a7ccb3 on zalando:master.

Coverage remained the same at 100.0% when pulling f995208c68b75886082dd6cc87043adb7f869f4e on danballance:show-cause-of-import-error into 476fc691ff80167c3e4a66f782ce259bb2a7ccb3 on zalando:master.

Coverage remained the same at 100.0% when pulling 35a4c7be279c4841e2b248716062eafcff35a314 on danballance:show-cause-of-import-error into 476fc691ff80167c3e4a66f782ce259bb2a7ccb3 on zalando:master.

Coverage remained the same at 100.0% when pulling 35a4c7be279c4841e2b248716062eafcff35a314 on danballance:show-cause-of-import-error into 476fc691ff80167c3e4a66f782ce259bb2a7ccb3 on zalando:master.

Coverage remained the same at 100.0% when pulling 35a4c7be279c4841e2b248716062eafcff35a314 on danballance:show-cause-of-import-error into 476fc691ff80167c3e4a66f782ce259bb2a7ccb3 on zalando:master.

Coverage remained the same at 100.0% when pulling 5f3b55016c63ea12335c2978a1902f559afbd61b on danballance:show-cause-of-import-error into 476fc691ff80167c3e4a66f782ce259bb2a7ccb3 on zalando:master.

:+1:


Article on Height of Binary Search Tree

🚀 Feature
I would like to add an article for finding height of BST
Have you read the Contributing Guidelines on Pull Requests?
(Yes)

Please assign me this issue sir @HarshCasper @iamrajiv @ankitaggarwal23 @atarax665 @gat786


rebuild i18n

The i18n sheets are pretty nasty. I'll be rebuilding these shortly.

After your update of sep 27 I could not startup the application, got an error: No such function i18n. I'm using Meteor <IP_ADDRESS>


102 update backend points

fix icon log errors
update code to take in .env variables

closing pr. changes made in another branch.


Initial frame publish support.

With the "frame" family tags, you can publish still images from the edit by tagging frames in the sequence.
We use this for outputting promotional stills at the end of the project.

Happy to merge now. will leave opened for a littler while just while we convert to 3.0 as well

Sorry, just slipped in some improvements.


Implement key range tracker.

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[ ] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[ ] Make sure tests pass via mvn clean verify. (Even better, enable
Travis-CI on your fork and ensure the whole test matrix passes).
[ ] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[ ] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

This will be useful for Bigtable and other key-based sources.

R: @chamikaramj

R: @jkff

I refactored this into a (reusable) class to deal with rangetracking on ordered positions, and the key <-> fraction functionality, as well as adding more tests, documentation, and comments. PTAL.

LGTM


difference between fonts and webfonts

What is the difference between these?
https://github.com/matcornic/hugo-theme-learn/tree/master/static/webfonts
https://github.com/matcornic/hugo-theme-learn/tree/master/static/fonts

cc @McShelby

The webfonts directory is a requirement for the fontawesome fonts (hard coded in the fontawescome.css).
All other theme fonts reside in fonts which is okay for me.


Docs: View recipe list as yaml

So people can add and exclude recipes from pre-built bundles.
Point to https://docs.openrewrite.org/tutorials/authoring-declarative-yaml-recipes and https://docs.openrewrite.org/reference/yaml-format-reference to help users activate the recipe they will produce.
For example, ability to get this recipe list in the Spring Boot 2.x migration as yaml

Done in https://github.com/openrewrite/rewrite-docs/commit/62ee4f2f98d7989196cf8b806bace39e85cbc740


Fix Windows 10 support for nearby font loading

By replacing IDWriteFontSetBuilder2::AddFontFile with
IDWriteFactory5::CreateFontFileReference and
IDWriteFontSetBuilder1::AddFontFile we add nearby
font loading support for Windows 10, build 15021.
This commit also fixes font fallback for AtlasEngine,
which was crashing during testing.
Finally it fixes a bug in DxEngine, where we only created a "nearby" font
collection if we couldn't find the font in the system collection. This doesn't
fix the bug, if the font is locked or broken in the system collection.
PR Checklist

[x] Closes #12420
[x] I work here
[x] Tests added/passed

Validation Steps Performed

Build a Debug version of Windows Terminal
Put Jetbrains Mono into the writeable AppX directory
Jetbrains Mono is present in the settings UI ✅
DxEngine works with Jetbrains Mono ✅
AtlasEngine works with Jetbrains Mono ✅

What if the font exists in the system set, but is unreadable due to a permission error? Would we find a "nearby" version of the same font and load it? That is the core of the issue with Cascadia on upgrade.

With the Windows Font Cache Service enabled I can't get my system in a state where Jetbrains Mono isn't available since it remains cached even after the .ttf file had its ACLs changed. If I disable that service, DirectWrite properly won't support the font at all. In short: I can't get my system to replicate the issue even after changing the ACLs.
In theory this approach should fix the issue, because we append the "nearby fonts" last to the collection, due to which they should take priority over the system fonts. I suspect that the people for whom this doesn't work, mostly used Windows 10, where this fix didn't work.

FYI I made the following changes to the PR:

No more caching of the font collection (ergo no invalidation required)
DxEngine now always creates a nearby font collection, so that we never try to use the installed Cascadia font
Added feature flagging to remove the nearby font loading from conhost, if we ever decide to ship Atlas/DxEngine with conhost
We should do the same with OpenConsole, however we don't have a macro to control that just yet.


Scheduling With Time-Zoned DateTime

Alarm plugin version
1.1.5
Describe the bug
Hello, I've got a problem setting up an alarm with a notification at a specific time-zoned DateTime. There's a difference between alarm and notification scheduled time (see screenshot below). I assume there's a problem with scheduling the time with a specific time zone.
Screenshots

Device info
Android Emulator (Pixel_3a_API_33_arm64-v8a)

Closed. The issue was in mine. Sorry


⚠ Secret Website 1 has degraded performance

In 0b3af2e, Secret Website 1 ($SECRET_WEBSITE_1) experienced degraded performance:

HTTP code: 200
Response time: 11892 ms

Resolved: Secret Website 1 performance has improved in 7330e2a.


mqtt: add tests for MQTT log limiting

This PR adds some tests related to the upcoming MQTT message log limiting functionality.
Redmine ticket: https://redmine.openinfosecfoundation.org/issues/6984

I personally prefer to see these tests red before the PR gets merged

I see. Interesting, my approach so far was to only run the tests if the tested feature is available in the tested suricata version/code tree. Would you always like to have tests from s-v PRs only succeed if the corresponding suricata PR is merged?

New PR upcoming.

Would you always like to have tests from s-v PRs only succeed if the corresponding suricata PR is merged?

Personnaly yes, so we see that the suricata PR brings an improvement.

Would you always like to have tests from s-v PRs only succeed if the corresponding suricata PR is merged?

Personnaly yes, so we see that the suricata PR brings an improvement.

I see, good to know. I always expected these branches here to be a bit polymorphic:

when run here with a Suricata version without support for the new features to be tested, the tests should be skipped -> test green here
when run in the context of a Suricata PR with support for the new features to be tested, run the tests and hopefully -> test green in Suricata PR

I assumed that's what the requirement definition functionality in the test.yaml was for.

This is a detail, but if we want to dive into it :
There are 2 things here :

you are right for the requirement, for example, that is meant to run only tests if I have my suricata compiled with lib magic for instance
for PRs, I like to see that we go from red to green, as it is more visible than going from skipped to passed (where I need to recompile and check locally)

Got it, thanks!


Splat redux with es6-ish syntax

This PR includes and improves upon the first splat PR (#1128) based on discussions within #1050. Specifically, this PR provides (or will provide):

ES6-ish ...-based splatting syntax
splatting for hashes
splatting for positional params
splatting subexpressions e.g. ...(wat)

@kpdecker @nathanhammond @BenjaminHorn this is ready for review now; just got splatting positional params and subexpressions to work.
Notes:

I haven't figured out how to de-dupe the new grammar; I tried SPLAT? but it yielded grammar conflicts, even though to my eyes that's functionally equivalent to the grammar I explicitly specify
positional param splatting works as follows: if there's no splats, there's no change to how helpers are called today; if there's at least one splat, instead doing a .call on the helper, we first invoke a new runtime function splatArgs and then .apply those to the helper function.
I didn't implement splatting the various helper method missing methods; I'm not sure it's worth the bloat?

@machty Generally this looks really good, had a few minor comments. Responding to your notes:

I've seen similar issues when trying to do the same. Sometimes Jison gives ambiguous productions for things that to me seem like they should be unambiguous and are the same as the duplicated listing. Since it's in the compiler I'm not too worried about it not being completely DRY.
Perfect
For blockHelperMissing, that code is only run if the template has no args or hash, so you are correct that no changes are needed.

Pong?

We've been holding off on pulling the trigger on this while we flesh out some remaining semantics on the Ember side of things, particularly related to how splatting will work for so-called angle-bracket components.

when do you think this will get in? im desperately waiting for this :)

@machty I want http://s3-ak.buzzfed.com/static/2014-07/10/20/enhanced/webdr10/anigif_enhanced-16641-1405037819-19.gif

I like this!!

While we're waiting spread and splat to come out in 5.0.0 handlebars, I wrote up a small Ember addon that handles spreading for Ember's component helper here: https://github.com/foxnewsnetwork/ember-component-helpers
That can be used by users of Ember2.0 and above like this:
Ember.Controller.extend({
  arrayArgs: ["admin.posts.post", 33, {class: "mdl-navigation__link", tagName: "li"}]
});

{{#component-apply "link-to" arrayArgs}}
  Your Link Text
{{/component-apply}}

You know, in case anyone else is particularly hungry for the spread after 1 year of waiting for it to come out like 2 straight months of looking at @rtablada 's animated gif of butter being spread on bread

Just curious if there is any update on this. We could badly use this in our app. :)

+1

What's the status on this?

For anyone looking for another option while waiting https://github.com/ciena-blueplanet/ember-spread is mixin based, but works with dynamic hashes

On another note, splats might work better as Element Modifiers (https://github.com/emberjs/rfcs/pull/112), e.g. {{my-comp (splat params)}} or <my-comp {{splat params}}/>

Any updates on this? How can people help to get this merged?

Still nothing on this? I keep coming back to needing this about once a month. And every time I have to make compromises in my architecture design because of this. If there's anything on which help is needed, I'd be happy to try and help.

I'd like to get a sense of how many people would use this feature/syntax for splatting arrays, spreading a hash of options. or both? This may or may not impact the future of this feature, I'm mostly just curious as to the real world use cases people expect this to address.
Personally, 99% of the time I'd be using this to spread a hash of options, since I do a lot of work in Ember with components and it's a common desire to be able to create a wrapper component that might introduce additional KV pairs into the options hash but otherwise forward the hash to the wrapped component. I don't think I'd ever use array splatting.

I'd use it exactly as you describe @machty
I currently have situations with a wrapper component like this, but then with 5 or 6 attributes that are being passed.
index/template.hbs
{{wrapper-component arg1=arg1 arg2=arg2 arg3=arg3}}
wrapper-component/template.hbs
{{wrapped-component arg1=arg1 arg2=arg2 arg3=arg3}}
it would be nice to not have to duplicate the passing of arguments in the wrapper-component's template

👍  on a hash of options (named args). Probably wouldn't use the array much.

@machty From my personal experience, this is mostly an issue when trying to build a component to wrap {{link-to}} components (as oppose to extending LinkComponent). For example, if I were to create a {{my-fancy-link-to}} component that looks something like:
app/components/templates/my-fancy-link-to.hbs
{{yield}}
{{#link-to ...args }}

...

{{/link-to}}

  {{#link-to "somewhere.else"}}
    ...
  {{/link-to}}

I would need to "splat" the ...args to properly emulate the functionality, but at the same time, I have no easy way of doing the splat

I too have always looked for something like this for spreading a hash of options. And I also wanted to know that it's not just to avoid duplicating the enumeration of options in the component and the wrapper. It's also to make the wrapper component agnostic of the component it is wrapping. I've had use cases with components that could conceivably wrap totally different inner components, with largely different sets of possible options. The wrapper component need not know about these kind of stuff.

Confession time: when I was first learning Ember, I resorted to some shameful hacking to get around the exact case of having to pass a zillion variables through a wrapper component. I eventually gave in and started doing things the proper way, but being able to splat the hash (eww) would really save both my past and present self a few brain cells.

I'd also like to see this for the use-case of wrapper components. Right now I'm using ember-spread to do this:
http://blog.firstiwaslike.com/clean-ember-addon-component-customization-with-ember-spread/
but it would be great if that was built-in functionality.

I have another potential use-case for this. I have a pagination-controls component that builds up a list of pages, then does
{{#each pages as |page|}}
  {{#link-to (query-params page=page.number)}}page.number{{/link-to}}
{{/each}}

I'd like to make the name of the query-param configurable:
{{my-pagination param='foosPage'}}

I can think of two ways of doing that, both of which require new syntax
// interpolate hash key:
{{#link-to (query-params [param]=page.number)}}

// hash-splat:
{{#link-to (query-params ...page.queryParamsHash)}}

Also the array splat is pretty important for positional params, {{#link-to dynamicRouteName ...routeParams}}. Currently, you cannot use link-to with dynamic params.

Is this only going to work for components, or will this also work for passing params to helpers? In practice, helpers seem to take positional params far more frequently than components do

Cannot wait to see this get merged.

I thought it was called "spread" in ES2015.

@machty Thanks for this awesome PR. I'm wondering how comes this has not been merged yet.
3 questions:

Is there some blocker at the moment?
What workarounds are you using for handling dynamic options passing between component?
How can I help to see this merged?

Just pushed a rebase to fix merge conflicts.
@jbescoyez

Basically the issue is that a large enough threshold of people are wanting this for Ember, but even if we land this feature, the implementation for template data-binding on the Ember/Glimmer side of things still needs to happen, and particularly with Glimmer there are performance constraints that need to be considered before we ship a syntax that everyone might like but is unfortunately doomed to be untenably slow.
See these comments from this thread: https://github.com/wycats/handlebars.js/pull/1149#issuecomment-217692299 and https://github.com/ciena-blueplanet/ember-spread
I'm not sure, it's really mostly blocked on Glimmer, which is developing quite rapidly (though admittedly this feature's been on the backburner). I've pinged the Ember/Glimmer team as to how to proceed with this PR. I'm thinking though that it probably makes sense for there to be an official Ember/Glimmer RFC with some backing from the core team, like we did with Named Blocks.

Basically @wycats has to say that it should get merged. I promised only to fix bug and not add new features, when I asked for push access.
He wants a spec first, have a look at #1277

Are there any plans on merging this (or implementing something similar)? Any news?

Any updates or news on this PR? Thanks!

There is no update and for the last 2 years, no one has made a serious attempt to write a spec. I'm thinking about it from time to time, but it's a lot of work, I have different obligations and for me, it would be just for the fun of it. I have actually started an attempt here but it has been unchanged for a long time.
I doubt that anything will change here unless somebody (other than me) gets invested in this an starts writing.

Hi @machty. This PR is now open for 4 years and I feel pity that you have put ao much work in a PR that has then been ignored for so long. I haven't really looked at it until now because it was before my time, and @wycats asked me to only fix bugs while this is clearly a feature. That hasn't changed in principal and after talking to @wycats I think that development will go into another direction.
But I can ask @wycats to have a look and give his approval for merging this. I will do this only if you say you still need it.
The reason why I'm asking this is: I want to change some tooling and use "prettier" as a code formatter. This will make development much easier in the future, but it will make merging this request much more difficult.
I could just discard it, but I don't want to do that without asking first.

Is love to see this make it in.

I'm not going to be bothered at all if this ends up getting closed. Even if it does, it'll still leave a blueprint for what needs to happen to get this over the finish line.
I don't have the bandwidth to be a champion of this feature, but I believe one of the main blockers was that it wasn't clear whether implementing a "splat/spread" operator was going to be an easily-optimizable feature in Glimmer. But regardless of efficiency, it seems like an obvious win for component composition (and proven by React and others) to be able to forward all the args to a child component without enumerating all of them.
So I'd say close it for now so you can evolve the codebase and start using Prettier, but I wouldn't expect the debate to stop.

I have some concerns that templates using this feature will become more difficult to understand, when trying to track the current evaluation context.
I'll gladly close it for now. I just didn't want to upset you.


Questions about running commands

Hi，Ziyao
I found that there is a problem with the running command in section 4.1 and section 4.2.
I don't know wether the problem I found is correct or wrong.
In addition, I would like to ask, which graphics card is needed for training, can A100 + CUDA11.4 be trained, thank you.
Here I would like to thank dptech for its contributions to this field.

Can you please provide the console logs, the command, and potentially the output of the code so that we can locate the problem? thanks.

A100 + CUDA11.4 is promising for training. We tested for V100 and A100. The CUDA version seems to have little impact. However,  we would also like to remind that the whole process needed to reproduce the training is time-costly (~10d  times 128 A100 cards).


Wallet - check blocks version

resolves #853
To check the correctness of the saved blocks, the wallet makes a call to a POST REST API, passing as parameters:

the last block number
the json of the last synchronized timber block
the development environment
The API interacts with a lambda, which checks whether the block sent by the wallet matches the one saved in dynamodb.
If the block does not match, the wallet synchronizes the entire database all over again

Closing PR. Implemented functionality in #861


Config file for manager template script

Allow a custom configuration file for the queue manager templates so that a user does not need to copy canonical values between files.

Closed in #177.


Macro for generating signals() and emit_/connect_ functions for subclass

When defining a GObject type in Rust, it is necessary to define a ObjectImpl::signals() function, and useful to define the emit_ and connect_ functions like the ones generated by gir.
Considering a few things, this seems like a reasonable API for it, which I think would work:
glib::wrapper! {
    signals {
        fn signal_without_params();
        fn signal_with_params(i32, String);
        fn signal_with_params_and_return(i32, String) -> bool;
    }
    pub struct FooObject(ObjectSubclass<FooObjectInner>);
}

I guess it would be necessary for the caller to define ObjectImpl::signals() to call a function generated by the macro. Kind of similar to the boilerplate required with composite templates. I can't think of a way to avoid a slight complication like this.
Alternately to making this part of glib::wrapper!, it could be a separate macro, or an attribute macro on something. Given glib::wrapper! is necessary, it seems cleaner to add it here. It could also generate the connect_/emit_ functions for types other than ObjectSubclass (code currently generated in gir).
Properties should be handled in a similar way, but that's more complicated since it would be good for it to automatically store a value if there is no custom getter/setter, while also supporting custom getters and setters. And then there's a need to define nick, blurb, and default value.

Kind of similar to the boilerplate required with composite templates. I can't think of a way to avoid a slight complication like this.

Or maybe that's not a problem. signals() could be a method of ObjectSubclassIs (the trait implemented when glib::wrapper! is used with ObjectSubclass<...>).
ObjectImpl::signals() could have a default implementation calling Self::Type::signals() (or a different function name). Or alternately it could be removed (making this a breaking change) if a manual implementation of signals isn't really useful.

I have implemented a (very WIP) version of this in another repo: gobject-impl
But let's wait until we figure out what is going on with #546 first before I try to port it upstream

I think the macro should take inspiration from the existing gtk4::template_callbacks and glib::properties macros to keep the developer experience consistent.
From gtk4::template_callbacks:

use a proc-macro on an impl block and generate code for all functions tagged with #[signal(...)]

From glib::Properties:

the macro should be defined for the ObjectSubclassImpl type (e.g. FooObjectInner above)
take a wrapper_type = ... parameter, that is used to generate the emit and connect functions
generate a function on the ObjectSubclassImpl type that returns the list of signals, similar to derived_properties
provide simple meta attributed for setting a well-typed accumulator function

I was thinking of something like this.
glib::wrapper! {
    pub struct FooObject(ObjectSubclass<imp::FooObject>);
}

mod imp {
    #[derive(Default)]
    struct FooObject;

    #[glib::object_subclass]
    impl ObjectSubclass for FooObject {
        const NAME: &str = "FooObject";
        type Type = super::FooObject;
    }

    #[glib::signals(wrapper_type = super::FooObject)]
    impl FooObject {
        #[signal(run_first)]
        fn signal_without_params(&self) {
        }

        #[signal]
        fn signal_with_params(&self, a: i32, b: String) {
            // class handler
        }

        #[signal(accumulator = |_hint, acc: &mut bool, val: &bool| acc && value)]
        fn signal_with_params_and_return(&self, a: i32, b: String) -> bool {}
    }

    impl ObjectImpl for FooObject {
        fn signals() -> &'static [glib::subclass::Signal] {
            Self::generated_signals()
        }
    }
}

This should then generate something like:
mod imp {
    // ...

    impl FooObject {
        // all the #[signal] functions

        fn generated_signals() -> &'static [glib::subclass::Signal] {
            static SIGNALS: std::sync::OnceLock<[glib::subclass::Signal; 3 /* statically known count */]> = std::sync::OnceLock::new();
            SIGNALS.get_or_init(|| [
                glib::subclass::Signal::builder("signal-without-params")
                    .run_first()
                    .class_handler(|_token, params| {
                        let wrapper: super::FooObject = params[0].get().unwrap();
                        wrapper.imp().signal_without_params();
                        None
                    })
                    .build(),
                    ...
            ])
        }
    }

    // ...
}

I don't quite understand the need for the SignalClassHandlerToken in the arguments to the class handler. As far as I understand this token should only be needed in an overridden class handler. Is it even possible to override a class handler from a parent in the array returned from ObjectImpl::signals?

Is it even possible to override a class handler from a parent in the array returned from ObjectImpl::signals?

No, you'd call class.override_signal_class_handler() from inside ObjectSubclass::class_init().
I think you're right that the token is only needed for the closure of that function, not for the main class handler. This should probably also get a test.
Let's fix that :)

See https://github.com/gtk-rs/gtk-rs-core/pull/1575


Add a command for recurring expense

Command /add_recurring is added. It asks for Category, Amount and Duration (number of months) from the use and adds that particular recurring expense to the JSON file


Fix edit post input text selection

Summary
In the post edit input box was being blocked by an invisible view that rendered on top of the input capturing the events before the input was able to do so blocking the text selection.
That view was added by the emoji autocomplete which had a different issue resolved by https://github.com/mattermost/mattermost-mobile/pull/4512. That PR in fact fixed the ability to scroll the emoji autocomplete list but created this bug as a side effect.
This PR prevents the emoji autocomplete picker from being rendered if there is no need as well as repositions the autocomplete element in the edit post screen fixing both issues at once.
Ticket Link
https://mattermost.atlassian.net/browse/MM-27488
Affected Areas
All Autocompletes (channel, users, slash commands, emojis) available in the following screens: Channel, Thread, Edit Post, Edit Channel (header) & Search

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/9075
https://circleci.com/gh/mattermost/mattermost-mobile/9073

Artifact links:
https://9075-70265724-gh.circle-artifacts.com/0/~/mattermost-mobile/Mattermost_Beta.ipa
https://9073-70265724-gh.circle-artifacts.com/0/~/mattermost-mobile/Mattermost_Beta.apk

@enahum
Error trying doing the automated Cherry picking. Please do this manually
+++ Updating remotes...
Fetching upstream
Fetching origin
+++ Updating remotes done...
+++ Creating local branch automated-cherry-pick-of-mattermost-mobile-#4647-upstream-release-1.34-1596746787
Branch 'automated-cherry-pick-of-mattermost-mobile-#4647-upstream-release-1.34-1596746787' set up to track remote branch 'release-1.34' from 'upstream'.

+++ About to attempt cherry pick of PR #4647 with merge commit 4c8e2e8ea4507fa33cb4cc4b13f80f70ad1b24f3.

+++ Conflicts detected:

UU app/components/edit_channel_info/__snapshots__/edit_channel_info.test.js.snap
UU app/components/edit_channel_info/edit_channel_info.js

+++ Aborting in-progress git cherry-pick.

+++ Returning you to the master branch and cleaning up.

cherry-pick done manually


Disable failing test cases

Purpose

Disable failing test cases

Codecov Report

Merging #23117 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #23117   +/-   ##
=======================================
  Coverage   14.59%   14.59%
=======================================
  Files          51       51
  Lines        1411     1411
  Branches      219      219
=======================================
  Hits          206      206
  Misses       1189     1189
  Partials       16       16

Continue to review full report at Codecov.

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

@keizer619 I have merged the PR since there are some other PRs pending due to this.


[idea] Introduce statefulFunctionComponent?

Is this an interesting pattern to introduce? Makes stateful components syntactically a lot more similar to stateless function components. But maybe another syntax is just confusing
demo: http://jsbin.com/camuzip/edit?html,js,output
also needs beter name
const {observable} = mobx;

const Counter = statefulFunctionComponent(
  // initial state function (props, context) => state
  ({start}) => ({ counter: start }),
  // new props function (props, state, context) => render function
  ({color}, state) => {
    function inc() {
      state.counter++
    }

    function dec() {
      state.counter++
    }

    return () => (

        <button onClick={dec}>-</button>
        <button onClick={inc}>+</button>
        {state.counter}

    )
  }
)

const Parent = statefulFunctionComponent(
  () => ({ color: "red" }),
  (props, state) => {
    const toggle = () => state.color = (state.color === "blue" ? "red" : "blue")

    return () => (

        <Counter start={10} color={state.color} />
        <Counter start={5} color={state.color} />
        <button onClick={toggle}>Color toggle {state.color}</button>

    )
  }
)

React.render(
  <Parent />,
  document.body
)

function statefulFunctionComponent(initialStateFunc, renderFunc) {
  return React.createClass({
    componentWillMount: function() {
      this._state = observable(initialStateFunc(this.props))
      this._renderer = renderFunc(this.props, this._state, this.context)
    },
    componentWillReceiveProps: function(nextProps) {
      this._renderer = renderFunc(nextProps, this._state, this.context)
    },
    render: function() {
      return <mobxReact.Observer>{this._renderer}</mobxReact.Observer>
    }
  })
}

The point of functional components is not the possibility to write a class as a function, but a realization, that stateless component is so simple that it needs only single method, so it's unneccessary to introduce a class.
In other words the component expressed as a function is a consequence, not the initial goal.
However, what you have presented is complex enought to be rather expressed by class. It actually is a class, you have just changed the class syntax into something much less readable.
If there is some heavy lifting done by Mobx (aside from constructing a class), let me extend some Mobx.Component or provide Mobx.createClass analogy to React.createClass for ES5 users.

I agree with you largely, especially and extensible ObserverComponent or something like that would be convenient to have (although it composes badly, I don't like it when other libs require you to extend something other than Components, that leads to inheritance classes sooner or later).
But while using and playing with the above pattern, one thing I found much clearer than with normal react classes; the interaction between props and state. Somehow knowing that when receiving new props the second function is called again, but the first one isn't, made it much simpler to reason about then using componentWillReceiveProps etc. It might just work only for me, but knowing "everything stored in the second closure will be lost when receiving new props, so store stuff in state if needed" felt much more straight forward then thinking about "what properties should I merge, how does state need to be updated in cWRP"? Of course, it is just sugar, in the end the problem is exactly the same, but for me it was surprising that this pattern made it easier to reason about.


clasless css

https://github.com/dbohdan/classless-css
see here:
https://discordapp.com/channels/501836936584101899/510527519066161193/568456604836691978
this would be a nice addition to theme, so people could use classless css on the fly

Oh my god.  This is perfect for this theme, great find!  Let me give this a read and see if I can build it into v2.

This is big enough that it'd need to go into the next numerical version of Hypertext.  It'll involve deep semantic changes to the DOM that will wreck anyone who's been writing CSS against this current structure.
But it's worth it.  Building in these one-click wonders would be really beautiful and worthwhile.  Give me a couple weeks to noodle on this.  :D

is there a chance to select different themes via frontend demo of theme?

Absolutely!  You can test it with the URL parameter, e.g. http://hypertext.artofthesmart.com/typography?theme=marx, http://hypertext.artofthesmart.com/typography?theme=yorha, or even http://hypertext.artofthesmart.com/typography?theme=12.
I find numbers the easiest for quickly leafing through available options.  :D

excellent! thanks! 👍 💯

Sorry, closed too early.  This is built into the recently launched v2.  Enjoy!

maybe if you put links to css in typography page?
ideally we could select themes on frontend from dropdown menu

I'd like that, but even with semantic-only CSS, there's a surprising difference between the themes and most users will write content targeting only one or two.  I can add links to the hypetext microsite to demo each of the different kinds.
For now, you can see examples in the Styles Table of the reference guide and leaf through them even on the live website that's there.


feat!: Added log-stream module, updated versions to 0.13+

New feature:

Added log-stream module.

Breaking Changes:

Upgraded minimum Terraform version to 0.13
Updated type of outputs in modules/metric-alarms-by-multiple-dimensions from list to map

This PR is included in version 3.0.0 :tada:


Code to run Web and App test in a single session.

Changes approved

Changes were not merged to the develop branch.


First controller

Oops, I accidentally compared and pulled to the team repo instead of the develop branch of my own repo. Spoke to you in the lab and you said to write a comment so you don't dock marks. Thanks!


Spurious hover-related warnings

I have no IntelliSense extensions loaded yet. While stopped at a breakpoint in my C program, if I move the mouse over various words in the program, I get warning messages in the debug console. Notice for example that the word "negative" was from a /* comment */, so it shouldn't try to get its value!
Hovering over a variable name that has a value does seem to work - it (Code or code-debug) shows the value in a hover message.

Code tells code-debug to get some value and code-debug just always prints the error messages. I should make it so code-debug doesn't show error messages for hovers


CMake Update

If ascent is installed to the default path it should now be usable by other CMake projects using the  following:
cmake_minimum_required(VERSION 3.12)
project("example")

find_package(ascent REQUIRED)

add_executable(${PROJECT_NAME} src/main.cpp)
target_link_libraries(${PROJECT_NAME} ascent::ascent)

This should fix issue #3

Addresses #3


[dbus] dbus-daemon, dbus-launch,... are first class artifacts

dbus-daemon, dbus-launch and the other executables in the dbus port are integral components of the D-Bus system. libdbus-1 is of no utility in itself without dbus-daemon. A case could be made that libdbus-1 in Vcpkg could be used on Linux against the distro-provided dbus-daemon, but this is not true on Windows and other platforms where the dbus package is also available (and usefully so). Therefore these executables must be treated as first-class artifacts in the vcpkg port that can be installed along with shared libraries to a prefix by consuming applications.
The release version of the dbus-* executables are available in the tools folder, but that leaves a hole for dynamically linked debug builds. These cannot install the dbus-* executables from the tools folder as they are release binaries that are not (necessarily) compatible with the installed libdbus-1.so/dll and other shared library dependencies. To properly support debug builds with dynamic linking the debug variant of these executables must also be preserved. They cannot be moved to tools//debug as that change of directory layout is not compatible with the RUNPATH in the executables [$ORIGIN:$ORIGIN/../../lib]. Instead all dbus-* executables are left in the bin and bin/debug layout.
Fixes #37625

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[x] The "supports" clause reflects platforms that may be fixed by this new version.
[x] Any fixed CI baseline entries are removed from that file.
[x] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

CI fails with "warning: The following EXEs were found in /bin or /debug/bin. EXEs are not valid distribution targets." I understand the drive not to become a general package manager, but libdbus is not of much use without dbus-daemon.

Executables must be moved to tools with vcpkg_copy_tools(...).

Put the debug executables into tools/${PORT}/debug.

They cannot be moved to tools//debug as that change of directory layout is not compatible with the RUNPATH in the executables [$ORIGIN:$ORIGIN/../../lib].

This must be handled correctly in z_vcpkg_fixup_rpath.cmake.

They cannot be moved to tools//debug as that change of directory layout is not compatible with the RUNPATH in the executables [$ORIGIN:$ORIGIN/../../lib].

This must be handled correctly in z_vcpkg_fixup_rpath.cmake.

Would it be acceptable to install the debug executables to debug/tools/<port>? That would collect all debug content in the debug/ folder and that, very importantly, would give a consistent layout. This matters especially for dynamically linked code on linux with z_vcpkg_fixup_rpath.cmake.

change of directory layout is not compatible with the RUNPATH in the executables [$ORIGIN:$ORIGIN/../../lib]

Since nobody directly said it. Ignore the message the port prints after the portfile has executed. z_vcpkg_fixup_rpath.cmake will take care of it and adjust the RPATH accordingly if the location contains debug/.

Put the debug executables into tools/${PORT}/debug.

I've pushed an update that puts them in debug/tools/${PORT} rather than tools/${PORT}/debug. That way the debug layout is identical to the release layout. That makes a lot more sense to me. It also means that I my project can install the dbus-* executables directly without having to patch the RUNPATH.

@dg0yt, why the "thumbs down" to installing in debug/tools/${PORT}? The CI system appears to accept it?

@dg0yt, why the "thumbs down" to installing in debug/tools/${PORT}? The CI system appears to accept it?

CI accepts a lot which shouldn't go in... I could only give a quick reaction at that moment. But the right locations was already noted in previous comments. And the debug prefix isn't standalone anyways: no share, no  etc, no include. I don't say I like it that way.

I don't say I like it that way.

That’s how I feel, so I’m just going to see if I get a bit more engagement from vcpkg maintainers, before accepting a solution that requires me to use patchelf to fixup the executables when my project copies them to an install prefix

I think it might be useful to elaborate on why I think debug/tools/${PORT} is much superior to tools/${PORT}/debug. First, it is consistent that all the debug items are in one folder that has the same layout as the release folder. That's just nice. Second is when an application wants to install the dependencies to CMAKE_INSTALL_PREFIX. This is what it will look like with debug/tools/${PORT} assuming the application uses the same <prefix>/bin/, <prefix>/lib/ layout on Linux:
if (UNIX)
    set(MY_VCPKG_INSTALLED_DIR ${VCPKG_INSTALLED_DIR}/${VCPKG_TARGET_TRIPLET}$<$<CONFIG:Debug>:/debug>)
    install(PROGRAMS
            ${MY_VCPKG_INSTALLED_TOOLS_DIR}/dbus/dbus-daemon
            ${MY_VCPKG_INSTALLED_TOOLS_DIR}/dbus/dbus-launch
            DESTINATION bin)
endif()

if instead dbus-daemon and dbus-launch are installed in a different relative folder layout between the binary and the lib/ directory, then a consuming application will need to fixup the RUNPATH on installation, which would look something like this:
if (UNIX)
    set(MY_VCPKG_INSTALLED_DIR ${VCPKG_INSTALLED_DIR}/${VCPKG_TARGET_TRIPLET})
    install(CODE "
            execute_process(
                COMMAND install ${MY_VCPKG_INSTALLED_TOOLS_DIR}/dbus$<$<CONFIG:Debug>:/debug>/dbus-daemon ${CMAKE_INSTALL_PREFIX}/bin/dbus-daemon
            )
            execute_process(
                COMMAND patchelf --set-rpath $ORIGIN/../${CMAKE_INSTALL_LIBDIR} ${CMAKE_INSTALL_PREFIX}/bin/dbus-daemon
            )
            ")
    install(CODE "
            execute_process(
                COMMAND install ${MY_VCPKG_INSTALLED_TOOLS_DIR}/dbus$<$<CONFIG:Debug>:/debug>/dbus-launch ${CMAKE_INSTALL_PREFIX}/bin/dbus-launch
            )
            execute_process(
                COMMAND patchelf --set-rpath $ORIGIN/../${CMAKE_INSTALL_LIBDIR} ${CMAKE_INSTALL_PREFIX}/bin/dbus-launch
            )
           ")
endif()

As you can see this is way more clumsy.

Oups, I think I’m wrong above. In my head I was think that the relative path from bin/ to lib/ was the same as tools/ to lib/, ie $ORIGIN/../lib, but with installation into tools/<port> the RUNPATH has to be $ORIGIN/../../lib. Drat. That means I need to patchelf the RUNPATH regardless. Only way to avoid patchelf is installation in a patch where RUNPATH can be $ORIGIN/../lib. That could be keep it in bin/ which CI and established rules (strangely, imho) prohibits or install directly in tools/ which, I believe is not encouraged either.

I think debug tools should go in debug/tools/${PORT}. The other debug folders are debug/lib and debug/bin and everything debug would live in the same directory. @BillyONeal any thoughts?

I think debug tools should go in debug/tools/${PORT}.

@data-queue These are the issues where your team is asked to clarify the installation layout for tools:
https://github.com/microsoft/vcpkg/issues/17607 (May 2021)
https://github.com/microsoft/vcpkg/issues/13649 (Sep 2020)
Answers to the open questions are not less urgent just because the issues are getting old...

This 3 year old comment on #13649 by @ras0219-msft says debug tools go in debug/tools. Is that still the policy? Next question is whether all executables are tools. dbus-daemon and dbus-launch are intended for runtime use, they are not build-time tools.

I believe the status quo is that because vcpkg is explicitly not intended to be a runtime deployment system, we do not have a canonical location for these components.

I understand the drive not to become a general package manager, but libdbus is not of much use without dbus-daemon.

I believe that means that the status quo is that we don't have a means of delivering libdbus in a way consistent with what libdbus customers want.
However, it also seems like these dbus components are of the kind where someone trying to provide them from 'outside the system' like this are always going to result in pain, since the version you select in vcpkg is unlikely to match versions on the system.

but this is not true on Windows and other platforms where the dbus package is also available (and usefully so)

What happens if 2 windows programs do this and choose totally different versions of dbus?

FTR another per-config vcpkg port particularity which may interfer with deployments.
NOTE: system bus listens on /<VCPKG_ROOT>/packages/dbus_x64-linux-dynamic/debug/var/run/dbus/system_bus_socket
| This build of dbus will not interoperate with the well-known
| system bus socket, /var/run/dbus/system_bus_socket.

FTR another per-config vcpkg port particularity which may interfer with deployments.
NOTE: system bus listens on /<VCPKG_ROOT>/packages/dbus_x64-linux-dynamic/debug/var/run/dbus/system_bus_socket
| This build of dbus will not interoperate with the well-known
| system bus socket, /var/run/dbus/system_bus_socket.

This is a separate issue and only relevant if you will be using the system bus. I'm only using session busses.

I believe the status quo is that because vcpkg is explicitly not intended to be a runtime deployment system, we do not have a canonical location for these components.

I understand the drive not to become a general package manager, but libdbus is not of much use without dbus-daemon.

I believe that means that the status quo is that we don't have a means of delivering libdbus in a way consistent with what libdbus customers want.
However, it also seems like these dbus components are of the kind where someone trying to provide them from 'outside the system' like this are always going to result in pain, since the version you select in vcpkg is unlikely to match versions on the system.

This PR settles just installs the dbus-* executables in debug/tools/dbus. That should be okay, should it not? See https://github.com/microsoft/vcpkg/pull/37736#issuecomment-2026900349

but this is not true on Windows and other platforms where the dbus package is also available (and usefully so)

What happens if 2 windows programs do this and choose totally different versions of dbus?

dbus is very uncommon on Windows. If you use autolaunch: they would (try to) use the same bus. I don't know what compatibility guarantees libdbus has.

They cannot be moved to tools//debug as that change of directory layout is not compatible with the RUNPATH in the executables [$ORIGIN:$ORIGIN/../../lib].

This must be handled correctly in z_vcpkg_fixup_rpath.cmake.

z_vcpkg_fixup_rpath.cmake seem to be incorrect: It determines the debug type by matching the executable's directory against debug/. This works for

debug/bin (not allowed)
debug/libs
debug/plugins/...
debug/tools/... (12 matches in x64-linux CI)
tools/.../debug/bin (210 matches in x64-linux CI)

but not for

tools/.../debug (a few matches in vcpkg CI).

but not for

tools/.../debug (a few matches in vcpkg CI).

https://github.com/microsoft/vcpkg/pull/37964

From the vcpkg team:

The debug tools for dbus should be copied over to debug/tools.
We are not saying that debug/tools is the accepted location for debug tools for all ports. They might need to go in other locations such as tools/.../debug/bin. And debug tools, in the general case, should not be copied over.

We are accepting this PR, and I will leave it open for a day or so before merging.

From the vcpkg team:

The debug tools for dbus should be copied over to debug/tools.

We are not saying that debug/tools is the accepted location for debug tools for all ports. They might need to go in other locations such as tools/.../debug/bin.

IMO this is a disappointing outcome. No reliable guideline for anything but dbus/now. No convergence. No perspective. In fact, little but our fading memories holding us back from moving the debug tools to another location in the next PR.

Reminder, the location was proposed due to workaround a defect in z_vcpkg_fixup_rpath. A fix is available.

Congrats. dbus won a free entry in the hall of shame at https://github.com/microsoft/vcpkg/issues/17607.


Add exercises from the "Functional Programming in Scala" book?

The Functional Programming in Scala book teaches FP in Scala from first principles, challenging readers with plenty of exercises that help build their understanding. We could add the exercises from the book (if the authors agree) to a library in Scala Exercises so readers of the book can track their progress and have their answers automatically checked.
I think this can be a very natural next step for people introduced to Scala through the Standard Library exercises, as well as building a solid foundation to tackle the Cats and Shapeless exercises.

Nice. @raulraja Could you ask Runar if they agree, please?

I got positive word from Runar but we need to ask O'Reilly if they'd be ok with it. Ultimately we would drive traffic and sales back to them so I don't foresee a problem. Perhaps @nickelsberry can reach out to them.

Exercises included in this PR https://github.com/scala-exercises/scala-exercises/pull/578


Show the license that is banned.

If you now ban someone that wasn't online it just shows BANNED license so I have no clue who got banned. Maybe a was to show details if you click on it or show a license number.

I know its not ideal, but clicking on every ban to find which one to unban is also not very good UX.
Because of that, if you already have an identifier (like license), you can just paste it in the search box and let txAdmin do the magic for you.


RESEVOIR_QUANTILE and APPROX_QUANTILE crash on GROUP BY

import duckdb

conn = duckdb.connect()

conn.execute(
    """
    SELECT RESERVOIR_QUANTILE(b, 0.5)
    FROM (SELECT 'a' AS a, 1.0 AS b) y
    GROUP BY a
    """
).fetchdf()

Running this kills my jupyter labs kernel
APPROX_QUANTILE also crashes when I add another key.
import duckdb

conn = duckdb.connect()

conn.execute(
    """
    SELECT APPROX_QUANTILE(b, 0.5)
    FROM (
        SELECT 'a' AS a, 1.0 AS b
        UNION ALL SELECT 'a' AS a, 1.0 AS b
        UNION ALL SELECT 'b' AS a, 1.0 AS b
    ) y
    GROUP BY a
    """
).fetchdf()

Note I have tested these on larger data sets which is why I started to investigate this crash.

Maybe @pdet can have a look


export: Fix RealmAuditLog queries (and other cleanup)

This lgtm aside from the one issue noted above.

Merged, after adding a docstring for the custom fetch method:
diff --git a/zerver/lib/export.py b/zerver/lib/export.py
index 0fa04b3fae..8151c71cc2 100644
--- a/zerver/lib/export.py
+++ b/zerver/lib/export.py
@@ -1024,6 +1024,10 @@ def fetch_attachment_data(response: TableData, realm_id: int, message_ids: Set[i

 def custom_fetch_realm_audit_logs_for_user(response: TableData, context: Context) -> None:
+    """To be expansive, we include audit log entries for events that
+    either modified the target user or where the target user modified
+    something (E.g. if they changed the settings for a stream).
+    """
     user = context["user"]
     query = RealmAuditLog.objects.filter(Q(modified_user_id=user.id) | Q(acting_user_id=user.id))
     rows = make_raw(list(query))
@@ -1973,6 +1977,7 @@ def get_single_user_config() -> Config:
         table="zerver_realmauditlog",
         model=RealmAuditLog,
         virtual_parent=user_profile_config,
+        # See the docstring for why we use a custom fetch here.
         custom_fetch=custom_fetch_realm_audit_logs_for_user,
     )


[Bug]: activity tab no longer shows witnesses

What happened?
the latest update has stopped us easily seeing the Activity tab and witnesses.
You have to click into each one to view them which is not good.
I k is it was done to speed up the website, but now you are hiding the vital information.
please roll it back or update to do it shows the number of witnesses in the Activity tab.
URL
https://explorer.helium.com/hotspots/112n4XciwTW3WraNBtXgc83g2t5zLtL1o12HQPLsuohed2zdVFbS/activity
What browsers are you seeing the problem on?
Chrome
Do you see the issue on Mobile or Desktop?
Mobile
Relevant log output
No response

please bring back the small icons and the number of witnesses

Take a look at the Helium Discord. A lot of people are not happy and want this rolled back or fixed so we can easily see witnesses.

feel free to test out a preview of a fix for this here: https://helium-explorer-pr-834.herokuapp.com/

I

feel free to test out a preview of a fix for this here: https://helium-explorer-pr-834.herokuapp.com/

Wow that looks great. It’s nice to be able to see how many Witnesses at a glance. Thanks.


Error:  Protocol "https" not supported or disabled in libcurl

What platform/OS are you using?
ARM-IMX-61 arm_a9hf Linux BSP 4.1.15
uname -m =
armv7l
Which version of the SDK?
aws sdk 1.7.11
with
libcurl/7.65.1 OpenSSL/1.0.2s zlib/1.2.8 nghttp2/1.39.1
curl -V =
curl 7.65.1 (arm-navico-linux-gnueabi) libcurl/7.65.1 OpenSSL/1.0.2s zlib/1.2.8 nghttp2/1.39.1
Release-Date: 2019-06-05
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL TLS-SRP UnixSockets
What compiler are you using? what version?
x86 (32-bit) to arm_a9
arm-navico-linux-gnueabi-gcc (GCC) 5.3.0
What are your CMake arguments?
export CMAKE_PREFIX_PATH="${SYSROOT}/usr"
cmake ..
-DCMAKE_TOOLCHAIN_FILE="${SYSROOT}/Toolchain.cmake"
-DCMAKE_INSTALL_PREFIX="${PKG}/usr"
-DCMAKE_BUILD_TYPE=RelWithDebInfo
-DCURL_HAS_H2_EXITCODE=0
-DCURL_HAS_H2_EXITCODE__TRYRUN_OUTPUT=""
-DCURL_HAS_TLS_PROXY_EXITCODE=0
-DCURL_HAS_TLS_PROXY_EXITCODE__TRYRUN_OUTPUT=""
-DBUILD_SHARED_LIBS="OFF"
-DBUILD_DEPS="OFF"
-DENABLE_CURL_LOGGING="ON"
-DBUILD_ONLY="core;s3;transfer"
// AWS C Common
export CMAKE_PREFIX_PATH="${SYSROOT}/usr"
cmake ..
-DCMAKE_TOOLCHAIN_FILE="${SYSROOT}/Toolchain.cmake"
-DCMAKE_INSTALL_PREFIX="${PKG}/usr"
-DCMAKE_BUILD_TYPE=RelWithDebInfo
// AWS Checksums
export CMAKE_PREFIX_PATH="${SYSROOT}/usr"
cmake ..
-DCMAKE_TOOLCHAIN_FILE="${SYSROOT}/Toolchain.cmake"
-DCMAKE_INSTALL_PREFIX="${PKG}/usr"
-DCMAKE_BUILD_TYPE=RelWithDebInfo
// AWS C Event Stream
export CMAKE_PREFIX_PATH="${SYSROOT}/usr"
cmake ..
-DCMAKE_TOOLCHAIN_FILE="${SYSROOT}/Toolchain.cmake"
-DCMAKE_INSTALL_PREFIX="${PKG}/usr"
-DCMAKE_BUILD_TYPE=RelWithDebInfo
-DCMAKE_MODULE_PATH="${SYSROOT}/usr/lib/cmake"
// Contents of the Toolchain.cmake file
==> /Toolchain.cmake <==
set(CMAKE_SYSTEM_PROCESSOR arm_a9hf)
set(TOOLCHAIN_HAS_GLIB True)
set(TOOLCHAIN_HAS_GSTREAMER_1.0 True)
set(TOOLCHAIN_HAS_GSTREAMER_1.0_IMX_COMMUNITY True)
set(TOOLCHAIN_HAS_ALSA True)
set(TOOLCHAIN_HAS_LIBUSB True)
set(TOOLCHAIN_HAS_SOCKETCAN True)
set(TOOLCHAIN_HAS_OPENSSL True)
set(TOOLCHAIN_HAS_NAVICOFB True)
set(TOOLCHAIN_HAS_GPU True)
//  These should be maintained in the fsl-gpu package.
add_compile_definitions(LINUX=1 EGL_API_FB=1)
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_VERSION 1)
// Careful: CMAKE_CURRENT_LIST_DIR has caveats
set(CMAKE_SYSROOT "/usr/local/arm_a9")
set(CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH} ${CMAKE_SYSROOT}/usr/lib/qt)
find_program(CCACHE_PROGRAM ccache)
if(CCACHE_PROGRAM)
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE "${CCACHE_PROGRAM}")
endif()
// Specify the cross compiler
set(CMAKE_C_COMPILER ${CMAKE_SYSROOT}/bin/arm-navico-linux-gnueabi-gcc)
set(CMAKE_CXX_COMPILER ${CMAKE_SYSROOT}/bin/arm-navico-linux-gnueabi-g++)
set(CMAKE_OBJCOPY ${CMAKE_SYSROOT}/bin/arm-navico-linux-gnueabi-objcopy)
set(CMAKE_CXX_COMPILER_ID "GNU")
set(CMAKE_CXX_FLAGS "-march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard")
// QT_USE_QSTRINGBUILDER, BOOST_SP_USE_PTHREADS and the forced cache
// setting of CMAKE_BUILD_TYPE should probably be maintained in NOS, not
// the toolchain.
add_compile_definitions(QT_USE_QSTRINGBUILDER BOOST_SP_USE_PTHREADS)
if(NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "Options: Debug Release RelWithDebInfo MinSizeRel" FORCE)
endif(NOT CMAKE_BUILD_TYPE)
Can you provide a TRACE level log? (sanitize any sensitive information)
DEBUG] 2019-07-04 12:01:16.807 AWSAuthV4Signer [2297607168] Signed Headers value:content-length;content-type;host;x-amz-content-sha256;x-amz-date;x-amz-meta-brand;x-amz-meta-model;x-amz-me
ta-serialnumber;x-amz-meta-time;x-amz-meta-version
[DEBUG] 2019-07-04 12:01:16.807 AWSAuthV4Signer [2297607168] Canonical Request String: PUT
/filename
content-length:1177502
content-type:binary/octet-stream
host:bucket.s3.amazonaws.com
x-amz-content-sha256:UNSIGNED-PAYLOAD
x-amz-date:20190704T120116Z
x-amz-meta-brand:brand
x-amz-meta-model:model
x-amz-meta-serialnumber:sn
x-amz-meta-time:2019-07-04T12:00:43Z
x-amz-meta-version:1
content-length;content-type;host;x-amz-content-sha256;x-amz-date;x-amz-meta-brand;x-amz-meta-model;x-amz-meta-serialnumber;x-amz-meta-time;x-amz-meta-version
UNSIGNED-PAYLOAD
[DEBUG] 2019-07-04 12:01:16.807 AWSAuthV4Signer [2297607168] Final String to sign: AWS4-HMAC-SHA256
20190704T120116Z
20190704/us-east-1/s3/aws4_request
ab947873daa83b746dae8b2e979fea34378eafd816f749c09b33a23e97f7e928
[DEBUG] 2019-07-04 12:01:16.807 AWSAuthV4Signer [2297607168] Final computed signing hash: a26bd7b5cc9f175e693a590da9bd628a02a034bd8891e9d906ad542887e46df4
[DEBUG] 2019-07-04 12:01:16.808 AWSAuthV4Signer [2297607168] Signing request with: AWS4-HMAC-SHA256 Credential=accesskey/20190704/us-east-1/s3/aws4_request, SignedHeaders=content
-length;content-type;host;x-amz-content-sha256;x-amz-date;x-amz-meta-brand;x-amz-meta-model;x-amz-meta-serialnumber;x-amz-meta-time;x-amz-meta-version, Signature=a26bd7b5cc9f175e693a590da9b
d628a02a034bd8891e9d906ad542887e46df4
[DEBUG] 2019-07-04 12:01:16.808 AWSClient [2297607168] Request Successfully signed
[TRACE] 2019-07-04 12:01:16.808 CurlHttpClient [2297607168] Making request to https://bucket.s3.amazonaws.com/file
[TRACE] 2019-07-04 12:01:16.808 CurlHttpClient [2297607168] Including headers:
[TRACE] 2019-07-04 12:01:16.808 CurlHttpClient [2297607168] authorization: AWS4-HMAC-SHA256 Credential=accesskey/20190704/us-east-1/s3/aws4_request, SignedHeaders=content-length;
content-type;host;x-amz-content-sha256;x-amz-date;x-amz-meta-brand;x-amz-meta-model;x-amz-meta-serialnumber;x-amz-meta-time;x-amz-meta-version, Signature=a26bd7b5cc9f175e693a590da9bd628a02a
034bd8891e9d906ad542887e46df4
[TRACE] 2019-07-04 12:01:16.808 CurlHttpClient [2297607168] content-length: 1177502
[TRACE] 2019-07-04 12:01:16.808 CurlHttpClient [2297607168] content-type: binary/octet-stream
[TRACE] 2019-07-04 12:01:16.808 CurlHttpClient [2297607168] host: bucket.s3.amazonaws.com
[TRACE] 2019-07-04 12:01:16.808 CurlHttpClient [2297607168] user-agent: aws-sdk-cpp/1.7.132 Linux/4.1.15 armv7l GCC/5.3.0
[TRACE] 2019-07-04 12:01:16.808 CurlHttpClient [2297607168] x-amz-content-sha256: UNSIGNED-PAYLOAD
[TRACE] 2019-07-04 12:01:16.809 CurlHttpClient [2297607168] x-amz-date: 20190704T120116Z
[TRACE] 2019-07-04 12:01:16.809 CurlHttpClient [2297607168] x-amz-meta-brand: brand
[TRACE] 2019-07-04 12:01:16.809 CurlHttpClient [2297607168] x-amz-meta-model: model
[TRACE] 2019-07-04 12:01:16.809 CurlHttpClient [2297607168] x-amz-meta-serialnumber: sn
[TRACE] 2019-07-04 12:01:16.809 CurlHttpClient [2297607168] x-amz-meta-time: 2019-07-04T12:00:43Z
[TRACE] 2019-07-04 12:01:16.809 CurlHttpClient [2297607168] x-amz-meta-version: 1
[DEBUG] 2019-07-04 12:01:16.809 CurlHandleContainer [2297607168] Attempting to acquire curl connection.
[INFO] 2019-07-04 12:01:16.809 CurlHandleContainer [2297607168] Connection has been released. Continuing.
[DEBUG] 2019-07-04 12:01:16.809 CurlHandleContainer [2297607168] Returning connection handle 0x965738f0
[DEBUG] 2019-07-04 12:01:16.809 CurlHttpClient [2297607168] Obtained connection handle 0x965738f0
[DEBUG] 2019-07-04 12:01:16.810 CURL [2297607168] (Text) Protocol "https" not supported or disabled in libcurl
[DEBUG] 2019-07-04 12:01:16.810 CURL [2297607168] (Text) Closing connection -1
[ERROR] 2019-07-04 12:01:16.810 CurlHttpClient [2297607168] Curl returned error code 1 - Unsupported protocol
[DEBUG] 2019-07-04 12:01:16.810 CurlHandleContainer [2297607168] Releasing curl handle 0x965738f0
[DEBUG] 2019-07-04 12:01:16.810 CurlHandleContainer [2297607168] Notified waiting threads.
[DEBUG] 2019-07-04 12:01:16.810 AWSClient [2297607168] Request returned error. Attempting to generate appropriate error codes from response
[ERROR] 2019-07-04 12:01:16.810 AWSClient [2297607168] HTTP response code: -1
Exception name:
Error message: Unable to connect to endpoint
/////////////////////////////////
Code
/////////////////////////////////
``
Aws::SDKOptions options;
options.loggingOptions.logLevel = Aws::Utils::Logging::LogLevel::Trace;
Aws::InitAPI(options);
Aws::Client::ClientConfiguration clientConfig;

clientConfig.region = "us-east-1";
{
    auto s3Client = Aws::MakeShared<Aws::S3::S3Client>(
        ALLOC_TAG,
        Aws::Auth::AWSCredentials(m_AccesKeyId, m_SecretAccessKey),
        clientConfig);
    {
        auto executor = Aws::MakeShared<Aws::Utils::Threading::PooledThreadExecutor>(ALLOC_TAG, 4);
        Aws::Transfer::TransferManagerConfiguration transferConfig(executor.get());
        transferConfig.s3Client = s3Client;

        transferConfig.transferStatusUpdatedCallback =
            [this](const Aws::Transfer::TransferManager*, const std::shared_ptr<const Aws::Transfer::TransferHandle>& handle) {

                const Aws::Transfer::TransferStatus status = handle->GetStatus();
                switch (status)
                {
                case Aws::Transfer::TransferStatus::COMPLETED:
                {
                    OnUploadComplete();
                }
                break;

                case Aws::Transfer::TransferStatus::CANCELED:
                case Aws::Transfer::TransferStatus::FAILED:
                case Aws::Transfer::TransferStatus::ABORTED:
                {
                    int error = static_cast<int>(handle->GetLastError().GetResponseCode());
                    OnUploadError(error);
                }
                break;

                case Aws::Transfer::TransferStatus::EXACT_OBJECT_ALREADY_EXISTS:
                case Aws::Transfer::TransferStatus::NOT_STARTED:
                case Aws::Transfer::TransferStatus::IN_PROGRESS:
                    break;
                }
            };

        transferConfig.uploadProgressCallback =
            [this](const Aws::Transfer::TransferManager*, const std::shared_ptr<const Aws::Transfer::TransferHandle>& handle) {
                OnUploadProgress(handle->GetBytesTransferred());
            };

        {
            std::shared_ptr<Aws::Transfer::TransferManager> transferManager = Aws::Transfer::TransferManager::Create(transferConfig);
            {

                const std::shared_ptr<Aws::Transfer::TransferHandle> transferHandle = transferManager->UploadFile(
                    m_FilePath.toStdString().c_str(),   // fileName
                    m_BucketName.toStdString().c_str(), // bucketName
                    m_Name.toStdString().c_str(),       // keyName
                    "binary/octet-stream",              // contentType
                    awsMetaData);                       // metaData

                transferHandle->WaitUntilFinished();
            }
        }
    }
}

Aws::ShutdownAPI(options);

}
``

Changing the scheme to http, I was able to upload a file successfully to s3 bucket.
Is anyone able to provide assistance with what might be wrong or how to debug what is happening in curl in more detail.

When compiling sdk, what's the curl version found from the cmake output?

This from the CMakeCache.txt file for aws-sdk-cpp
//Details about finding CURL
FIND_PACKAGE_MESSAGE_DETAILS_CURL:INTERNAL=[/usr/local/arm_a9/usr/lib/libcurl.so][/usr/local/arm_a9/usr/include][v7.65.1()]
//Details about finding OpenSSL
FIND_PACKAGE_MESSAGE_DETAILS_OpenSSL:INTERNAL=[/usr/local/arm_a9/usr/lib/libcrypto.so][/usr/local/arm_a9/usr/include][c ][v1.0.2s()]
//Details about finding ZLIB
FIND_PACKAGE_MESSAGE_DETAILS_ZLIB:INTERNAL=[/usr/local/arm_a9/usr/lib/libz.so][/usr/local/arm_a9/usr/include][v1.2.8()]

Based on curl's FAQ https://curl.haxx.se/docs/faq.html
Https is not supported usually when SSL is disabled or not found during build CURL.
But based on you curl -v output and the CMake output, they are the same version.
Could you please also run ldd /path/to/curl binary see if the curl library is the same as the one found in CMake when building SDK?

The dates and file sizes on the target device are consistent with the stripped versions of the files that our build system is creating.
# ldd /usr/bin/***app***

libcurl.so.4 => /usr/lib/libcurl.so.4 (0xb12c1000)

libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0xb125f000)

# ll /usr/lib/libcurl*
lrwxrwxrwx    1 root     root            16 Jul  4 01:16 /usr/lib/libcurl.so -> libcurl.so.4.5.0*
lrwxrwxrwx    1 root     root            16 Jul  4 01:16 /usr/lib/libcurl.so.4 -> libcurl.so.4.5.0*
-rwxr-xr-x    1 root     root        368712 Jul  3 22:11 /usr/lib/libcurl.so.4.5.0*

# ll /usr/lib/libssl*
lrwxrwxrwx    1 root     root            15 Jul  4 01:16 /usr/lib/libssl.so -> libssl.so.1.0.0*
-r-xr-xr-x    1 root     root        351332 Jul  3 21:58 /usr/lib/libssl.so.1.0.0*

[/usr/local/arm_a9/usr/lib/libcurl.so] is the one found by cmake to compile sdk, which is not the one from above ldd cmd

For clarity on the build machine
/usr/local/arm_a9/ is the CMAKE_SYSROOT so it's removed from the full path to get /usr/lib/libcurl.so
and libcurl.so and libcurl.so.4 are symlinks to the real library libcurl.so.4.5.0
On the target device we have installed a stripped version of libcurl.so.4.5.0 with the same symlinks.
We have confirmed end to end the file sizes and checksums of the library and there are no differences.
Is there anything else we can do we can do to increase the trace output to help identify what is going on?

The issue was another 3rd party library was statically linking an older version of curl that wasn't configured to support https. and this was then being used.
Linking the correct version resolved the issue.


How to detect map unload

I want to save selected overlay layers on layers control to local storage so that I can preselect them when the user reloads the map next time.
I tried using leafletMap.on('overlayremove') and overlayadd methods to cache the selected layers, however, the same methods are been called when the map unloads so I end up with an empty list at the end.
Is there a way to detect leaflet map is about to be unloaded, so that I can grab selected layers before they are been removed. (ngOnDestroy is called after all layers have been removed)

Stack Overflow is probably a better place to ask this question. Tagged with leaflet and ngx-leaflet. This is more specifically a Leaflet question.
Since I don't have a ton of bandwidth to provide general support, I try to keep issues reported here limited to bugs, defects, and enhancement requests.
I'm not sure what other events you might be able to use for this. Maybe a combination of Angular component lifecycle handlers and leaflet map events to differentiate between when the map is being unloaded and when it's legitimately a user selecting/unselecting the overlays. I'll be curious to hear about the solution you find, though.

Closing as per the last comment.


audioplayers v0.16.x

I setup android studio recently.. and try to learn flutter via online tutorial...
I see, they use audioplayers v0.10.0, but i use v0.16.0.. 'cause of latest branch
but i face some problem in Android version.

I run flutter build apk & it's finished his task.
I add audioplayers ^0.16.1 & it's give me error 'path-provider:compileReleaseAidl'
Failed to find build-tools : 28.0.3

I use build-tools : 30.0.2
I think.. i see 'cause of Buildtool version.. & I reInstall Android Studio.. and again same problem..
Then I remove package audioplayers ^0.16.1 and install ^0.16.0(same problem)

I remove audioplayers package from my app.. & again flutter build my package easily.. using build tool v30 ..

Config
Android Studio : v4.0
Api level : 30
build-tools : 30.0.2
Platform : Android
OS : Windows

Have you tried lowering you api level?? both path provider and audio players show 28 as the compiled level?

Path Provider use API 29 & Audioplayers use 28..
I readthe code on Github.. tomorrow i make audioplayers for API 30

You need to install build-tools 28.0.3. Run ~/Android/Sdk/tools/bin/sdkmanager or use the visual interface on your android studio to install any missing packages. You also need to accept the licenses. This is a flutter question, nothing to do with AudioPlayers.

This isn't a Flutter issue.. I read the code.. You're using Build-tools 28.. Why should I use API 28. If i hv API level 30 phone..
Also if i install build tools 28, so platforms version 28 is compulsory.. So upgrade your build tools.. not me.

If you use API level 30 in your code.. then everyone use it.. your pub.


Examples may use chain nominal diameter

Garrett pointed out the values we are using here. These look to be the nominal rather than volume-equivalent diameter for these chains. We should check all our examples and correct to volume-equivalent if needed.
https://github.com/WISDEM/RAFT/blob/7781903e8a798840eee808e97113a0fa2ce344ef/examples/VolturnUS-S_example.yaml#L1234

This has been corrected in this commit: https://github.com/WISDEM/RAFT/commit/b220780da593610cebd6026e9469f62232de5c51
Yes, the previous values for diameter in the RAFT designs for the VolturnUS platform were using the nominal diameter of 185mm, when it needed to use the volumetric diameter. The VolturnUS design description states that it uses R3 grade studless chain. It has been derived that for R4 grade studless chain, the volumetric diameter = 1.8 * nominal diameter. It is also shown in the manufacturer catalogs that the mass (and buoyancy) properties of chain line do not change for different grades of chain, meaning that we can multiply the nominal diameters by 1.8 to produce the correct volumetric diameter.
These changes were made in all RAFT design yamls that were based on the VolturnUS design. For the OC3 spar and OC4 semi designs, those values were already given as volumetric diameters. Their design description PDFs do not state whether that value is nominal or volumetric, but the value used in the MoorDyn file for those designs is the same as what is listed in the PDFs, meaning that we can assume it is the volumetric diameter, and we do not need to update these design yamls.
The RM1 design is also using the correct diameter.


Minor UI glitch: Sparrow displays uncompressed pubkeys as signatures.

Most public keys stored in Bitcoin transaction inputs are stored in "compressed form". However some UTXOs may have hashed a public key in uncompressed form, where these pubkeys start with 04 instead of 02 or 03 and are twice as long.
Possibly because these public keys are longer than the usual 33 bytes, Sparrow mistakes them for signatures.
Here's a recent example seen in the wild (neither of the following TXs are mine).
https://mempool.space/tx/b2a34a14f1f2887e5606a690df527dc44308b1910e9475cfc65c209c3089a7fb

For comparison, this other P2PKH transaction spends from a compressed public key (2nd element of the ScriptSig is the usual 33 bytes instead of 65). That one is correctly displayed as <pubkey1> in Sparrow: https://mempool.space/tx/632f1a62553a66a4a7c4c29cbbb06288d0f7331cc6b9b256a0c6a02e6f3124b5

Thanks for the bug report, fixed in f3c44e6f.


Update reqs to support Django 4 and remove Django 2.2

This removes the top end version restriction on Django and bumps the lowest version to 3.0. There are also updates to a couple of other libraries (Djoser, social-auth) as they were out of date and causing issues, and a small update to the testapp/utils.py as the middleware API has changed slightly in 4.0.
What are the relevant tickets?
Required for https://github.com/mitodl/hq/issues/3158 - Unified Ecommerce is a Django 4 app and I need some of this there.
Description (What does it do?)
Changes the requirements globally to eliminate support for Django < 3 and remove the top-end limit so that it works with the Django 4 series. (Should also work with 5, too.) This includes updating to the latest versions of social-auth-core, social-auth-app-django, and djoser so that things worked in test.
The only code change is a minor change to a test utility function - SessionMiddleware requires a response since Django 4.0 (it used to default to None), so this has changed to use an empty string instead. (It just needs a response of some sort, and given the use of this function, that seemed workable). No code changes were made to any other part of any of the apps.
How can this be tested?
Automated tests should pass. As there are no code changes, there should be no changes in operation in any application that uses an ol-django app.

I was expecting pants ol-project changelog check (which is run during ci) to complain but it seems to overlook dependency changes. Not sure if that is intended or a bug, I'll try to remember to ask Nathan when he gets back.

So, that was actually for a reason - I had changelogs in for everything, but the check complained about that because there weren't any code changes, so I pulled all of them so it would pass checks. I'll poke at it though; the linked PR also has no real code changes so there should be a way to get that to work.

Requesting a quick re-review to check my work in the changelog command - it should now treat changes to the requirements as a code change. (Otherwise, it sees that there's a changelog but no code change and then denies you - in this case, none of the code actually needed changing.)


8.0 + Model Changes not updating form

Code is the same in these two examples:
8.0.3 : http://jsbin.com/holiro/2/edit?html,css,js,output
7.5.1 : http://jsbin.com/jivojo/3/edit?html,css,js,output
Notice that when the model changes in 7.5.1 the form updates but when the model changes in 8.0.3 the form no longer changes

+1 same problem here

Saw the same thing and reverted back.

@kwypchlo, are you able to look into this? I'm assuming it's related to the breaking change that was introduced in #639. It may be that it just needs to be documented a little more.

Are there any other breaking changes with 8.0?

I have the same problem. What can i do to resolve or workaround the problem ? I am using v8.0.3 and all my application is now broken. Resolution is very urgent. Thanks in advance.

@melnac until this get's sorted you'll have to use a version before 8.0.0

thanks for reply. Where i can get a version before 8.0.0. I use formly via cdn...

According to @TheMcMurder jsbin above, it's available at<EMAIL_ADDRESS>

many thanks, i will try

I prepared pull request #657 that fixes that issue, sorry for the inconvenience.
@BarryThePenguin could you take a look?

+1 same problem here

This looks good now in 8.0.4. Thanks for your quick assistance @kwypchlo :runner: :dash:

Ah great!! Thanks guys!!

Thanks @kwypchlo!