Resource Landing Page Edit Mode: Required Metadata Message Persists Too Long

When I first create a resource, I am taken to the resource landing page and I get a green message at the top listing any required metadata elements that I am missing. Then, I go into edit mode.  The message at the top of the page is the same, but it turns yellow.  Then, I can specify all of the required elements in edit mode, click their respective save buttons, and I even get the green message that pops up saying my metadata are sufficient to share my resource or make it public, but the original yellow message at the top of the page stating that there are still required elements doesn't go away until I leave edit mode.
I think this message should probably be modified either: 1) each time they save an individual metadata element, or 2) it should remain until they have specified all of the required elements and should disappear at the same time the green message pops up stating that the metadata are sufficient for sharing. Otherwise the user could be confused about why the yellow message is still at the top of the page even though they have created all of the required elements.

I have experienced a related issue. I am editing an existing resource and adding/removing subject keywords. Every time I make a change, the green message appears telling me that the metadata are sufficient to share/make public. I don't need to see the message in this case nor with this frequency. Let me know if this should be posted as a separate issue.

@horsburgh Can you test on beta and see if this got fixed then close it?

I just tested on beta.hydroshare.org and this issue remains. I did the following:

Created a new generic resource with a title.
Entered edit mode
Created an abstract
Created a keyword (I get the green message stating my metadata are sufficient)

The yellow message telling me that I need an Abstract and Keywords is still shown at the top of the resource. It doesn't go away until I leave edit mode.
On a related note - I clicked the button to remove the one keyword I added and get the following error:

This error seems a little misleading as it shouldn't really be an error. It should probably just be a message stating that the resource cannot be made public or published without at least one keyword.  And, it fails to actually remove the last keyword. This might have to be a new issue.
The issue referenced by @AmberSJones (see issue #484) also remains.

@pkdash - same thing here - can we just modify this error message to say something like:
"You must have at least one keyword. If you need to remove a keyword, make sure you have at least one other keyword."

@Maurier I think this is no longer an issue


Underscores escaped incorrectly

Describe the bug
Underscores are escaped in documentation, incorrectly.
variable "splunk_logs_config_file_both" {
  type        = string
  description = "splunk logs configuration file"
}

| splunk\_logs\_config\_file\_path\_s3\_both | splunk logs configuration file | `string` |

To Reproduce
Steps to reproduce the behavior:

Create a module variable with a default value which includes underscores
Generate docs

Expected behavior
Generate documentation without escaped underscores
Version information:
terraform-docs --version
terraform-docs version v0.0.0- v0.9.1 darwin/amd64 BuildDate: 2020-04-02T23:00:25+0100

Additional context
Add any other context about the problem here.

Can you elaborate a bit more on the issue? This, based on what I understood from your message, is indeed by design. Underscores are being escaped in Markdown and you can explicitly disable them by using --no-escape flag.

hi @khos2ow ,
Thank you so much for your prompt reply.  My apologies for not reading the documentation properly.  You are quite correct, that resolved the issue.  Thank you again.
Cheers,
Will


Windows Desktop Notification is Not Working

Describe the bug
When an incident or recovery happens while running Monika, desktop notification does not work in Windows
To Reproduce
Steps to reproduce the behavior:
Update your Monika to v1.6.2 first by npm install -g @hyperjumptech/monika or download the binary in the release page.

Create a configuration file called config.yml:

notifications:
  - id: desktop
    type: desktop
probes:
  - id: sample_1
    name: Sample Request
    requests:
      - method: GET
        url: https://reqres.in/api/users/23
    alerts:
      - query: response.time > 200
        message: Response time is {{ response.time }} ms, expecting less than 200ms
      - query: response.status != 200
        message: Status code is not 200. I think their service is down.
      - query: isEmpty(response.body)
        message: Response body should not be empty!
    incidentThreshold: 2
    recoveryThreshold: 2

With Monika installed, run monika -c config.yml

Expected behavior
When there is any incidents or recoveries, it should sent you the desktop notifications
Screenshots
N/A
Desktop (please complete the following information):

OS: Windows 10

Additional context

You can modify the file in ./src/components/notification/channel/desktop.ts
Please do not use external libraries such as node-notifier as it may breaks the packaging.

Can I work on this?

Hi @thisisommore of course you can! I will assign this issue to you. Let me know if you need any help :smile:


Reduce refresh indicator pull-down distance

Description
Reland of #44054
Thanks to @altherat
Related Issues
#14981
Tests
@altherat added the following tests:
RefreshIndicator - just enough: Ensures a 100 pixel drag causes a refresh, which would fail with the previous pull-down distance.
Also modified an existing test (RefreshIndicator - not enough) to pass for the reduced pull-down distance.
Checklist
Before you create this PR, confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I updated/added relevant documentation (doc comments with ///).
[ ] All existing and new tests are passing.
[ ] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.

[x] No, no existing tests failed, so this is not a breaking change.
[ ] Yes, this is a breaking change. If not, delete the remainder of this section.

[ ] I wrote a design doc: https://flutter.dev/go/template Replace this with a link to your design doc's short link
[ ] I got input from the developer relations team, specifically from: Replace with the names of who gave advice
[ ] I wrote a migration guide: https://flutter.dev/go/breaking-changes-template Replace this with a link to a pull request that adds the migration guide to https://flutter.dev/docs/release/breaking-changes

@googlebot I consent.

Apparently one way to fix the *customer-testing issue is by doing a rebase like this:
git pull --rebase upstream master followed by git push --force origin <branch>

Alternatives are creating a new branch off of the latest upstream master and just re-adding my changes as a commit on top of that. I think https://github.com/flutter/flutter/pull/69726 has the context for what's causing this problem.
Also, would you be willing to put a side-by-side comparison gif of the native and Flutter behaviors in the PR description? That would help in the future if there's ever any question about the correct native behavior, especially changes occur for Android in the future.

Ooops I think I made things worse

I will open a new pr very soon

See #69783


Update HasLoggingTrait.php

Used getTraits() instead of class_uses_recursive

Unfortunately getTraits() doesn't return recursive traits :(
https://bugs.php.net/bug.php?id=61554

nice spot


Payments | Check yookassa response

Create function check_yookassa_respone, that before payment process check that response from yookassa.

Deleted GetPaymentData all functional move into check_yookassa_response. Don't use YookassaPaymentResponse or YookassaPaymentBody because this schemas created for work with serialized data and I need firstly serialize my data if I want to use them. And I think that serialize my data and only after it compare them bad idea and too complicated.

For me everything looks fine now


Automatic redirect from http to https

Describe the enhancement you'd like to see
As a devops, I'd like Envoy to automatically redirect from http to https for some or all endpoints.
Additional context
This is the usual task/problem in any deployment, when you want your site to be instantly redirected to https when an user types www.example.com.

https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-enum-config-route-v3-virtualhost-tlsrequirementtype
require_tls


Backport stm32-rs changes to svdpatch.py

Relevant commits are:

https://github.com/stm32-rs/stm32-rs/commit/d611511cfffcca021fff6277048627cc069baa6d
https://github.com/stm32-rs/stm32-rs/commit/5d7a424839403954f3d8cc998bd36488e5527997

@jessebraham @MabezDev, for lack of current CI, can you check whether these cause you any issues?

Both master and this PR produce identical SVD's in the esp32 crate, so looks good to me :)


networkmanagerapplet: 1.8.20 -> 1.8.22

Motivation for this change
Things done

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

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

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

NEWS: https://gitlab.gnome.org/GNOME/network-manager-applet/blob/1.8.22/NEWS


Don't panic, use NotImplementedError

it is semantically incorrect
A dirty workaround has to be used, since pyo3_runtime.PanicException cannit be imported since pyo3_runtime is not a real module.

def getPanicExceptionType():
    try:
        safetensors.safetensors_rust.serialize({"tensor_name": {"dtype": "test", "shape": [0, 0], "data": b""}}, None)
    except BaseException as ex:
        return ex.__class__

PanicException = getPanicExceptionType()

Very correct !
Currently this lib outputs Exception a bit everywhere without careful consideration for the Exception type.
Anyhow, here is the fix: https://github.com/huggingface/safetensors/pull/78


Master

Backups
Removed backups from the repository. There is no reason for them to be shared and they would just clash with any backups of users using this repository
Octoeverywhere
This was an oversight on my end, I included my Octoeverywhere config with the initialization, which is a huge security risk as it includes my API keys for my printer, requiring to re-do my printer on Octoeverywhere to get a new API key.
Removed KAMP
Before using the Klipper-Macros repository, I used the well known KAMP project, but actually disabled it quickly after using it a few times. I just wanted more granular control on when to level my bed. Furthermore, if I tried to print something which was the entire bed full, the adaptive purging would sometimes go out of bounds and fail the print. Which is difficult to detect without literally just running it. Thus, I rather include purging in my slicer's start Gcode and use a skirt as purging when I have large prints.
KAMP is also replaced by some macros in Klipper-Macros and I didn't want to confuse the two or mix them.
Klipper Macros
Added Klipper-Macros and my initial config
Moonraker Secrets
This was another oversight by me initially, submitting my MQTT server passwords and usersnames, also requiring me to change all of them for security. Although, they are only on my local network, it would still have been a security issue. I also moved some of my directories and other sensitive values to moonraker.secrets for privacy and security.


[full-ci] The libregraph public link type representation added to the…

… PROPFIND response

Description

Related Issue

Fixes <issue_link>

Motivation and Context

How Has This Been Tested?

test environment:
test case 1:
test case 2:
...

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Technical debt
[ ] Tests only (no source changes)

Checklist:

[ ] Code changes
[ ] Unit tests added
[ ] Acceptance tests added
[ ] Documentation ticket raised:

@2403905 Is this still a thing?

@2403905 Is this still a thing?

Needs to rework
Here is a discussion link  https://github.com/cs3org/reva/pull/4722#discussion_r1642580118


Link to  developer documentation in README.md is wrong

✅ Prerequisites

[✅ ] Did you perform a cursory search of open issues? Is this bug already reported elsewhere?
[✅  ] Are you running the latest SDK version?
[✅  ] Are you reporting to the correct repository (@magic-sdk/admin)?

🐛 Description
Link to  developer documentation in README.md is wrong
🧩 Steps to Reproduce

Got to README.me
Click on link to "developer documentation"
Link redirects to 404

🤔 Expected behavior
Link to correct  developer documentation.
😮 Actual behavior
Not needed.
💻 Code Sample
Not needed.
🌎 Environment
Not needed.

inactive repo, closed


Allow setting RUSTDOCFLAGS somehow

It can be useful for adding some custom JS libraries like KaTeX
Relevant issues:

rust-num/num#225
libOctavo/octavo#90

Thanks for reporting.
I'll add this feature along with #29


Add support for Wii, Wii U, Ouya, and Vita

These platforms are already in the device list, and are already supported by Xelu's icon pack, so why not?
The same goes for the disconnected icon. Why not?
Additional changes:

Rearrange the device list by category -> type -> generation
Make the mapping script more D.R.Y by adding common methods for button layouts
Reformat the DOCS.md tables using IntelliJ IDEA
Rename incorrectly named icon files

Thank you for your contribution. While I initially intended to add those platforms since they were available in Xelu's pack, I actually removed them before the first release for a couple of reasons:

Some platform controllers are not plug-and-play for PC. Wii U and Vita, for example, require third-party drivers/software to be used on PC, and even if there's a more reliable solution (e.g. Steam), they usually get mapped to Xbox 360 and thus this addon cannot automatically detect them.
It's rare to see users with these controllers for PC gaming, thus it would "bloat" the addon with unnecessary assets. For those cases, the addon is designed to allow detecting those controllers and adding assets to them without any core modification.
This addon is intended for PC game development, where many different controller can be used. However, it's only useful for mostly "standardized" layouts with only small tweaks to button placement and icons. For more exotic controllers like the Wii, a 1:1 mapping is impossible, and since games would have to be designed specifically for that controller type, it would defeat the need for this addon anyways.

So, adding support for Wii, Wii U and Vita is not a good idea. With that said, OUYA does pass the above conditions, so it can be added :+1:

Actually, speaking of making the Mapper script more D.R.Y., why isn't it using dictionaries instead of if-else chains and multiple functions that do the same thing?

While dictionaries make the code cleaner and easier to read, they're less performant to use than enums. The Mapper class is called from every icon on load, and whenever a controller is plugged/unplugged, so performance is important here.

Designing an addon for a multi-platform engine, for only one platform seems kind of terrible. But hey whatever. Like I said I kind of wanted to rewrite it anyway.
Good luck, and feel free to snip my code. I'll leave the branch up for a while.

Designing an addon for a multi-platform engine, for only one platform seems kind of terrible.

There is no point in using this addon for console development, since the compatible controllers are tied to the brand (you can't use Nintendo controllers on an Xbox or PlayStation, for example). It is only useful for newer platforms that offer controller backward-compatibility (Xbox Series supporting Xbox One controller, for instance), but even then that's a weak argument. Not to mention this is all assuming Godot even runs on these suggested platforms, which it doesn't (except OUYA since it's Android based, therefore why I agree it can be added).
The other parts of your PR (code cleanup and refactoring) are valid though, so if you want to contribute those, feel free to reopen this PR or make another one with those. I don't "snip" code because that would take away credit from you, the author.

since the compatible controllers are tied to the brand (you can't use Nintendo controllers on an Xbox or PlayStation, for example)

That's a flaw in your design. It doesn't check OS.get_name() before detecting controller type. People are still designing games for multiple platforms. They're not all exclusives. In fact we're getting fewer platform-exclusive titles than ever now.

Check which platform you're on, then assume you're using a specific controller or set of controllers if you're on one with only one controller.
If you're on a platform with multiple controller configurations, you move on to detecting a subset of the controller types. (Switch has Pro, single-con, multi-con grip, handheld. Most gen-6+ consoles also support mostly-compatible gimmick controllers for Rock Band, Guitar Hero, etc.)
If you're on desktop, web, or mobile, you move on to detecting any controller type.

This reduces the amount of checking on some consoles considerably. I'm already implementing this in my library, which uses a mix of different authors' open-license prompts to fill in more support gaps.

(sorry for the late reply, got busy with other stuff these last few days)

That's a flaw in your design. It doesn't check OS.get_name() before detecting controller type. People are still designing games for multiple platforms. They're not all exclusives. In fact we're getting fewer platform-exclusive titles than ever now.

I don't see it as a design flaw, but rather a design choice. I've never worked with consoles and even if I wanted this addon to support them I have no feasible way to do that without getting access to a version of Godot designed for consoles, which would involve getting in contact with companies that offer those services. It's also likely that consoles provide specific APIs to detect what controller type is active, but again, I have no way of knowing all of this as a "hobby" project, so console support is not a priority right now.

Also, you don't need to be running detect every frame. Only once per device connection event. It doesn't actually create that much overhead if you do it right.

The addon is using a signal to detect device changes already:
https://github.com/rsubtil/controller_icons/blob/f57beb4e2da6891e823effdcb5313341a08f4a3c/addons/controller_icons/ControllerIcons.gd#L87-L88

Regarding code-snipping, I would accept a co-author tag on your commits if you'd like. It's easier for you to know exactly what you want to leave or take and just do it. :)

Alright, in that case I'll add a co-author field, but I need to know your e-mail for that (you can share the GitHub's no-reply email to avoid sharing your personal email).


Mixed mask with numbers and letters not working

Hello everyone.
I'm trying to create a TextInputMask with the following mask
[AAA]-[0000]
(this is the pattern for vehicles license plate here in brazil)
But when i type the input field behaves like this:

Here is my code:
<TextInputMask
    keyboardType='default'
    refInput={ref => { this.TEXT_INPUT_REF = ref; }}
    returnKeyType='go'
    placeholder={Texts.Placeholders.LICENSE_PLATE} /* AAA-0000 */
    style={styles.inputField}
    onChangeText={text => this.props.writeVehicle(text)}
    value={this.props.vehicle}
    autoCapitalize='characters'
    mask={Texts.Masks.LICENSE_PLATE} /* [AAA]-[0000] */
/>

Same here. Did you by any chance find a workaround yet?

@tempname11
not tried to fix this yet, i will try your workaround

I have the same issue (described in https://github.com/react-native-community/react-native-text-input-mask/issues/48). This is not due to character types.
@tempname11 could you provide a snippet of your workaround ?

Sure, try something like this:
import * as React from 'react';
import TextInputMask from 'react-native-text-input-mask';

class Example extends React.Component {
  render() {
    return (
      <TextInputMask
        refInput={ref => { this.input = ref }}
        onChangeText={someHandler}
        mask={someMask}
      />
    );
  }
  componentDidMount() {
    this.input.setNativeProps({ text: this.props.value });
  }
}

Thank you. But I have the same behaviour with this snippet.

Same issue here. Any updates on this one? :(

`
import {TextInputMask} from 'react-native-masked-text'
<TextInputMask
autoCapitalize="characters"
type={'custom'}
options={{mask: 'AAA-9999'}}
value={}
onChangeText={} />
`

import {TextInputMask} from 'react-native-masked-text'

<TextInputMask
   autoCapitalize="characters"
   type={'custom'}
   options={{mask: 'AAA-9999'}}
   value={}
   onChangeText={} />

Thanks @sterfanno , but still I am getting an error, the value is duplicating
import React, { Component } from 'react';
import { TextInputMask } from 'react-native-masked-text';
import { Item, Form, Label, Text, } from 'native-base';

class AddScreen extends Component {
    constructor(props) {
        super(props);
    this.state = {
        vehiclenumber: '',
    };
}
  componentDidMount() {
      this.input.setNativeProps({
          text: this.state.vehiclenumber
      });
  }
    onVehicleNumberChange(text) {
        this.setState({
            vehiclenumber: text,
            error: '',
        });
        this.componentDidMount();
    }
render() {
        return (
         <View style={styles.containerStyle}>
           <Form style={styles.formStyle}>
              <Item
                 stackedLabel
                 style={styles.itemStyle}
              >
                 <Label
                    style={styles.labelStyle}
                 >
                     Vehicle Number
              </Label>
              <TextInputMask
                refInput={ref => { this.input = ref; }}
                style={{
                    color: 'white',
                    flex: 1,
                    flexDirection: 'row',
                    width: '100%',
                    paddingLeft: 10,
                    fontSize: 18,
                }}
                type={'custom'}
                options={{ mask: 'AA99A-9999' }}
                onChangeText={this.onVehicleNumberChange.bind(this)}
              />
              </Item>
        </Form>
     </View>
    );
  }
}

Works fine on emulator, but this is the behaviour in real devices, don't know what causing this, thanks in advance


⚠ AnimeBytes has degraded performance

In 9747770, AnimeBytes ($AB) experienced degraded performance:

HTTP code: 200
Response time: 21624 ms

Resolved: AnimeBytes performance has improved in 04c02d7 after 6 minutes.


Problem using Mongoose.createConnection

Hi.
Maybe the problem is somewhere else, but my modest knowledge of node, express, etc. "points" to this package.
I have one middleware:
app.use(function(req, res, next){
  var db = mongoose.createConnection('localhost/uvs-dev');
  app.set('dbConnection', db);

  db.on('connected', function () {
    console.log('Mongoose connection opened');
  });

  db.on('error', console.error.bind(console, 'connection error:'));

  next();
});

And it works as expected. At least, i get 'Mongoose connection opened' message.
Next middleware uses connect-mongo:
app.use(
    session({
      secret: config.secrets.session,
      resave: true,
      saveUninitialized: true,
      store: new mongoStore({ mongoose_connection: app.get('dbConnection') })
    }));

But i get an error: Required MongoStore option "db" missing
I'm using https://github.com/DaftMonk/generator-angular-fullstack. Maybe it has some gotcha. Any help would be very appreciated.

Your first middleware is useless since connect-mongo already wait for connection.
And above all, it is badly designed.
When you declare a middleware, it will be used on each request. But when you call session() which effectively returns a middleware, the content of your first middleware has not been called yet.

Thanks, understood why this error occurs.
What i want to do is to connect do different database depending on subdomain, i.e. each of my customer will have it's own database. So i guess i need middleware which will be used on every request to detect which db to use.
Code i wrote here is very simplified and just for testing and trying to understand how things work.

Each connect-mongo deals with one db connection.
I think you should try another design, or another tool.

Thanks for info


chore: Add a note in the PR welcome announcing the summer vacation

Checklist

[x] Commits are signed with Developer Certificate of Origin (DCO - learn more)

Relates to https://github.com/kedacore/keda/issues/4773

/skip-e2e


Increasing timeout when talking to slpdb

:tada: This PR is included in version 1.46.2 :tada:
Your semantic-release bot :package::rocket:


Issue 278 - change keybinding for window reload

Hey everyone!  This is to resolve #278

Keybinding to reload window is Ctrl/Cmd-Shift-R (to mimic behavior cache ignoring keybinding in Firefox and Chrome)
Ctrl/Cmd-R now also Executes query (keeping Ctrl/Cmd-Enter)

I may be wrong, but I don't thing multiple accelerators can be assigned in the Electron menus.  To get around this, I added an event listener for browser-window-created in src/browser/app.js that adds the duplicate shortcut to execute a query.
Any thoughts or changes needed?
Thanks!

LGTM 👍 ...
and it also seems that you can't have 2 shortcut do the same thing by default in electron's menu.

@blakek Thanks for the PR. I will try to test that as soon I get a free time. @eMerzh If you have tested that already feel free to merge that.

yep, work like expected.
thanks @blakek

Thanks everyone!!


Pdfium.Net SDK

Question - Does this work with the Pdfium.Net SDK NuGet package or do you still need to compile the SDK?

I'm not sure what your asking. This library has no dependencies and the
pdfium dll is included in its nuget package and the git repository.
On Thu, Dec 17, 2015, 17:31 mslissap<EMAIL_ADDRESS>wrote:

Question - Does this work with the PdfiumNet SDK NuGet package or do you
still need to compile the SDK?
—
Reply to this email directly or view it on GitHub
https://github.com/pvginkel/PdfiumViewer/issues/51.

On the instructions, there are steps to build Pdfium. I am having trouble building it and wondered if it was still required since there is now a Nuget package for Pdfium.Net SDK. It looks like I will still need to build it.

Well, those are for when you want to build it. As I said, a pre-compiled
version is in the Git repository and in the nuget package. If you just want
to us the PdfiumViewer control, you don't need to build pdfium yourself.
On Thu, Dec 17, 2015, 19:14 mslissap<EMAIL_ADDRESS>wrote:

On the instructions, there are steps to build Pdfium. I am having trouble
building it and wondered if it was still required since there is now a
Nuget package for Pdfium.Net SDK. It looks like I will still need to build
it.
—
Reply to this email directly or view it on GitHub
https://github.com/pvginkel/PdfiumViewer/issues/51#issuecomment-165535855
.

Ok, thank you! I read it wrong.

You're welcome. Not a problem.
On Thu, Dec 17, 2015, 19:48 mslissap<EMAIL_ADDRESS>wrote:

Ok, thank you! I read it wrong.
—
Reply to this email directly or view it on GitHub
https://github.com/pvginkel/PdfiumViewer/issues/51#issuecomment-165545450
.


Use app-internal organization for TC

Split TC into proxy and auth packages
Rename auth.New (was accessLogger.New) to auth.NewAccessLogger
Move startOutgoingProxy function to method on traffic controller
Extract shared gRPC connector and pool into plumbing since the rlp
also uses it.
Remove useless negative test in log_access_authorizer_test that
checked for extraneous goroutines.
Update bosh package specs for rlp and loggregator_trafficcontroller

@jasonkeene The profiler may not belong in the app, but this PR here is solely about the organization of files. I'd prefer to fix the TC app and improve its factoring in another PR, if that's alright with you.

Sure thing I will merge then.


Embedded doesn't support from

We may be incorrectly using the the embedded syntax, but we can't use the from: option when passing in a mapper when using embedded (and some others).
embedded :cats, from: 'CatDetails', mapper: CatMapper

We expected that syntax to work in conjunction with a CatMapper:
class CatMapper
  model Cat
  attribute :name, from: 'sillyCateKeyName'
end

The following code seems to work, but we would prefer to pass mapper instead of always nesting in a block.
    embedded :cats, from: 'CatDetails' do
      model Cat
      attribute :name, from: 'sillyCateKeyName'
    end

It just seems that the from: isn't being passed through in the embedded dsl method.
Is this intended usage, or have I completely missed something obvious?

Ugh, silly me. Looks like you guys have already fixed this in f46e4f9e415c5606fc0e39c2474aeec83a912d16.

Sorry you've been affected by this :) We're pushing 0.8.0 tomorrow (unless some unexpected blockers are found).

No worries, cheers for that!

I do have a quick question @solnic if you have a spare second. I'm trying to grok the usage of Mapping and how they relate to, well, Relations.
I will try and use the examples from the tests that I have been seeing lately, and maybe once I figure it out I'll write up a quick wiki on this repo to help explain it to the next person.
Let's say I have a list like this:
response = {
  task_list: 1,
  tasks: [
    { user: 'jacob', task_id: 1, title: 'do something' },
    { user: 'jacob', task_id: 2, title: 'do something else' },
] }

I want to map the data in a way that isn't a 1:1 translation of Hash into ruby models. Let's say this is a legacy mapping of data and translated into the Model of Users and Tasks.
# Models
class TaskList
  attribute :id
  attribute :user
end

class User
  attribute :name
  attribute :tasks
end

class Task
  attribute :user
  attribute :title
  attribute :id
end

class TaskListMapper < ROM::Mapper
  model TaskList
  register_as :task_list # Not 100% sure what this does as it isn't listed in the generators?

  attribute :id, from: :task_list
  embedded :user, from: :tasks do
    model User
    attribute :name, from: :user
    group :tasks, on: { name: :name } do
      attribute :title
    end
  end
end

I'm missing something that helps me grok all this together, any chance you could push me in the right direction?

In 0.8.0 to convert tuple:
{
  task_list: 1,
  tasks: [
    { user: 'jacob', task_id: 1, title: 'do something' },
    { user: 'jacob', task_id: 2, title: 'do something else' },
  ]
}

into the output:
{
  id: 1,
  user: {
    name:  "jacob",
    tasks: [
      { title: "do something",      id: 1 },
      { title: "do something else", id: 2 }
    ]
  }
}

you could do this mapper:
class UserMapper < ROM::Mapper
  relation :users
  register_as :users

  attribute :id, from: :task_list

  wrap :user do
    attribute :user
    group :tasks do
      attribute :id, from: :task_id
      attribute :title
    end
  end
end

The only difference from your example is that while grouping into tasks, the mapper will extract the :user from the list.
This is not a bug, but a sort of a policy IMHO. ROM mapper doesn't create the data, only rearranges the existing ones.
I think, populating tasks with the name of a user they relates to could be the responcibility of your domain model, not the ROM.

Thanks for the reply @nepalez, the requirement of having user duplicated is unnecessary and I guess I understand the principle of never duplicating data.
I did try your example on 0.8.0 and it doesn't seem to be able to infer the grouping on users.
require 'rom'
require 'virtus'

Entity = Virtus.model(coerce: false)

class User
  include Entity

  attribute :id
  attribute :name
  attribute :tasks
end

class Task
  include Entity

  attribute :id
  attribute :name
  attribute :user
end

class UserMapper < ROM::Mapper
  relation :users
  register_as :users

  attribute :id, from: :task_list

  wrap :user do
    attribute :name, from: :user
    group :tasks do
      attribute :id, from: :task_id
      attribute :title, from: :task
    end
  end
end

response = {
  task_list: 1,
  tasks: [
    { user: 'jacob', task_id: 1, task: 'do something' },
    { user: 'jacob', task_id: 2, task: 'do something else' },
    { user: 'steve', task_id: 2, task: 'do something else' },
    { user: 'steve', task_id: 1, task: 'do something' },
] }

mapper = UserMapper.build
prop = mapper.call [ response ]
#=> [{:tasks=>
#   [{:user=>"jacob", :task_id=>1, :task=>"do something"},
#    {:user=>"jacob", :task_id=>2, :task=>"do something else"},
#    {:user=>"steve", :task_id=>2, :task=>"do something else"},
#    {:user=>"steve", :task_id=>1, :task=>"do something"}],
#  :id=>1,
#  :user=>{:name=>nil, :tasks=>[]}}]

Is the syntax missing a parameter that tells ROM how or what to group on?

This one's tricky. I don't have time now but I'll take a look later today and try to figure it out :)

D'oh, sorry, this was my fault. I turn you to the wrong path.
The problem is that there's no way to group users after wrapping, because it groups mapped items, that are already different. Yes, this is tricky, i need some time to sort it out.

@dekz This would work:
require "rom"

ROM.setup :memory

class Users < ROM::Relation[:memory]
  dataset :users
  register_as :users
end

class FirstMapper < ROM::Mapper
  register_as :first
  relation :users

  attribute :id, from: :task_list
  unfold :tasks
end

class SecondMapper < ROM::Mapper
  register_as :second
  relation :users

  attribute :id
  unwrap :tasks do
    attribute :user
    attribute :task_id
    attribute :title
  end
end

class ThirdMapper < ROM::Mapper
  register_as :third
  relation :users

  group :tasks do
    attribute :id, from: :task_id
    attribute :title
  end
end

class ForthMapper < ROM::Mapper
  register_as :forth
  relation :users

  wrap :user do
    attribute :name
    attribute :tasks
  end
end

rom = ROM.finalize.env

rom.relations.users.insert(
  task_list: 1,
  tasks: [
    { user: 'jacob', task_id: 1, title: 'do something'      },
    { user: 'jacob', task_id: 2, title: 'do something else' }
  ]
)

rom.relation(:users).as(:first, :second, :third, :forth).to_a

Results step-by-step:
# => [{:tasks=>{:user=>"jacob", :task_id=>1, :title=>"do something"}, :id=>1}, {:tasks=>{:user=>"jacob", :task_id=>2, :title=>"do something else"}, :id=>1}]

rom.relation(:users).as(:first, :second).to_a
# => [{:id=>1, :user=>"jacob", :task_id=>1, :title=>"do something"}, {:id=>1, :user=>"jacob", :task_id=>2, :title=>"do something else"}]

rom.relation(:users).as(:first, :second, :third).to_a
# => [{:id=>1, :user=>"jacob", :tasks=>[{:id=>1, :title=>"do something"}, {:id=>2, :title=>"do something else"}]}]

rom.relation(:users).as(:first, :second, :third, :forth).to_a
# => [{:id=>1, :user=>{:tasks=>[{:id=>1, :title=>"do something"}, {:id=>2, :title=>"do something else"}]}}]

@solnic In the example above we could not use 4 (!) mappers. Instead we could use a sequence of commands within the only mapper:
class FirstMapper < ROM::Mapper
  register_as :first
  relation :users

  attribute :id, from: :task_list

  unfold :tasks

  unwrap :tasks do
    attribute :user
    attribute :id, from: :task_id
    attribute :title
  end

  group :tasks do
    attribute :id, from: :task_id
    attribute :title
  end

  wrap :user do
    attribute :name
    attribute :tasks
  end
end

The only thing why this doesn't work is that mapper is too lazy. It doesn't remembers that attributes were renamed. I wonder, whether we could do something here?

haha! I thought today "well, we need to have a way to specify a sequence of transformations in a single mapper to avoid having to use multiple mappers"
so I guess we should just do it, question is: how the dsl should look like?
class SequenceMapper < ROM::Mapper
  sequence do
    # stuff defined here will be executed one-by-one
  end
end

??

The wonderful part of all of this is my last example is already works (well, except for renaming attributes).

Maybe this would more "natural":
class FirstMapper < ROM::Mapper
  register_as :first
  relation :users

  step do
    attribute :id, from: :task_list
    unfold :tasks
  end

  step do
    unwrap :tasks do
      attribute :user
      attribute :task_id
      attribute :title
    end
  end

  step do
    group :tasks do
      attribute :id, from: :task_id
      attribute :title
    end
  end

  step do
    wrap :user do
      attribute :name, from: :user
      attribute :tasks
    end
  end
end

On every step the sequence compose --> preprocess --> process primitives --> postprocess would be done, so at the first of the next step we could do the same data as it were mapped before.

hmm yeah I think I like that

@nepalez thanks for that mate, it looks really good. Having those steps or sequences would also be a really good idea I feel. I am willing to try and help implement this if you like.

@dekz that would be awesome; it should be a simple addition as underlaying pieces are reusable. The contract should be that if there are steps, we only build up a mapper from those, if there are steps + top-level definition, we raise an error. step block would simply use AttributeDSL to gather attributes and store them in "steps" array and then you just build up each step using transproc compiler and compose into a single transformer and :tada:

@solnic should this step to be included to the next release?

I want to push 0.8.0 later today but I think I won’t make it > - <. Steps
could be added in 0.8.1 or 0.8.0 if we can make it.
On Wed, Jun 3, 2015 at 10:09 AM Andrew Kozin<EMAIL_ADDRESS>wrote:

@solnic https://github.com/solnic should this step to be included to
the next release?
—
Reply to this email directly or view it on GitHub
https://github.com/rom-rb/rom/issues/263#issuecomment-108238159.


Not receiving all OSC Strings

Every once in a while some OSC strings are not received to route. Receiving from EOS Ti sending to QLab. The string to fire a cue is not displayed in the log, but shows the updated pending next cue. This causes QLab to "miss fire" a cue as it is not sent the OSC string.
This is inconsistent.

I've written my own OSC application and I see the same result from EOS consoles. The best advice is to just setup TCP on the EOS console and have OSCRouter connect over TCP. Don't use UDP.


Incompatibility with compose-cli 2.0.0-rc1

Hello,
after upgrading compose-cli 2.0.0 from beta6 to rc1 I started to get the following error:
* 'Deploy.Resources.Reservations.cpus' expected type 'string', got unconvertible type 'float64', value: '0.25'

So I changed my .yml by replacing:
services:
  myservice:
    deploy:
      resources:
        reservations:
          cpus: 0.25

with:
services:
  myservice:
    deploy:
      resources:
        reservations:
          cpus: "0.25"

This silenced the error on compose-cli, but now is python on whales that is complaining about the expected type:
pydantic.error_wrappers.ValidationError: 18 validation errors for ComposeConfig
services -> myservice -> deploy -> resources -> reservations -> cpus
  value is not a valid float (type=type_error.float)

I didn't find any reference to this type change in the changelog of compose-cli rc1 so I'm not totally sure if this is a feature that should be supported by python on whales or a bug that should be reported on compose cli

Strange, could you give me the json output?

This morning I did some additional tests and the problem is mostly related to the use of variables, here an example:
$ cat docker-compose.yml

services:
  myservice:
    image: alpine
    deploy:
      resources:
        reservations:
          cpus: ${MYCPUS}

$ cat .env

MYCPUS="0.25"

This example works with compose 2 beta6 AND python on whales
With compose rc1 fails because:
* 'Deploy.Resources.Reservations.cpus' expected type 'string', got unconvertible type 'float64', value: '0.25'
The same with cpus: "${MYCPUS}"
With an additional single quote in docker-compose.yml (cpus: "'${MYCPUS}'") the configuration works with compose, but not with python on whales:
pydantic.error_wrappers.ValidationError: 1 validation error for ComposeConfig
services -> myservice -> deploy -> resources -> reservations -> cpus
  value is not a valid float (type=type_error.float)

Here the corresponding json:
>>> docker.compose.config(return_json=True)
{'services': {'myservice': {'deploy': {'resources': {'reservations': {'cpus': "'0.25'"}}, 'placement': {}}, 'image': 'alpine', 'networks': {'default': None}}}, 'networks': {'default': {'name': 'tmp_default', 'ipam': {}, 'external': False}}}

I found a workaround by moving the single quote from the docker-compose.yml to the .env:
=> docker-compose.yml -> cpus: "${MYCPUS}"
and .env = MYCPUS="'0.25'"
This combination works for both compose and python on whales
But still I don't know if compose side this is a feature (and the type change is wanted and should be supported by python on whales) or if it is a bug
Here an issue for a similar problem, I just added a comment there
https://github.com/docker/compose-cli/issues/2014

Thank you for the detailed bug report. I've read the issue you are linking. It seems that the right fix would be to follow the compose specs and allow a float AND a string in the pydantic model. I'll do this this afternoon


Review doc flow for usability and standard construction

Doers the doc have appropriate landing and flow.

@thothmoses I think we can close this issue now, correct?


Inaccurate LFG channel name for TBCC in french

Hey there, I'm french and since I downloaded the addon I noticied I kept joining a channel named RechercheGroupe, which is basically LookingForGroup.
The thing is, while it was the accurate name for the channel in french during Classic vanilla, it was renamed with Burning Crusade to RechercheDeGroupe. So I keep joining this dead channel and it takes the /1 slot, making General becoming /2, Trade is now /3 etc... quite annoying!
I tried to change it in the localization settings, but after /reload the addon breaks and doesn't load at all.

This should be fixed in the latest version 2.54


fix links in docs by adding file extension

- Summary
Several links in the docs were broken, sending readers to 404 pages when clicking through. This has been fixed by adding the .md extension to their paths.
- Test plan
No tests necessary, though I clicked the links (they worked)
- Description for the changelog
Fixed some broken links between docs pages.
- A picture of a cute animal (not mandatory but encouraged)

@joestrouth1 thanks for this! Unfortunately, this issue is a little more complex than it seems - our docs on netlifycms.org are generated from this source, so the links are formatted to work there. This change would break the site.
The proper fix is to make the change you're suggesting once we're able to remove the extension when generating the docs site, which is covered by #511.

@erquhart ah, my apologies. Should have continued with a more thorough search!


[WIP][SPARK-47265][SQL][TESTS] Use createTable(..., schema: StructType, ...) instead of createTable(..., columns: Array[Column], ...) in UT

What changes were proposed in this pull request?
The pr aims to use createTable(..., schema: StructType, ...) instead of createTable(..., columns: Array[Column], ...) in UT.
Why are the changes needed?
Because the TableCatalog#createTable(..., schema: StructType, ...) method has been marked as deprecated after version 3.4.0.
Does this PR introduce any user-facing change?
No.
How was this patch tested?

Pass GA.
Update existed UT.

Was this patch authored or co-authored using generative AI tooling?
No.

hmm.... Is the substitution relationship written in reverse...

[error] /home/runner/work/spark/spark/sql/core/src/test/scala/org/apache/spark/sql/connector/KeyGroupedPartitioningSuite.scala:26:48: Unused import
[error] Applicable -Wconf / @nowarn filters for this fatal warning: msg=<part of the message>, cat=unused-imports, site=org.apache.spark.sql.connector
[error] import org.apache.spark.sql.connector.catalog.{CatalogV2Util, Column, Identifier, InMemoryTableCatalog}
[error]

cc @cloud-fan

thanks, merging to master!


dupe

https://youtu.be/djdmlV4wlmM
not working in global region, region to which there is access, as well as in the regions where the '/ct all' flag is set.

[GP] Running GriefPrevention 1.12.2-<IP_ADDRESS>6
[GP] Running SpongeForge 1.12.2-2611-7.1.0-BETA-3016
[GP] Running luckperms 4.1.91

Upgrade to latest GP, SF, and LP. Outdated versions are not supported.


Fix a bunch of issues with dependencies in SDL.

SDL was very sensitive to definition order to the point where simple
linear dependencies caused failures. Generally, "using" something
(function, annotation, constraint, etc.) before declaring it caused
errors when tring to create an SDL migration. Dependencies on other
modules were similarly broken.
Schema migration tests now attempt to dump the schema into SDL (using
the same code-path as used by DESCRIBE). Then the schema produced by
the generated SDL is compared to the original to check correctness of
generated SDL syntax and semantics.
The current version fixes many dependency issues, however, it also
highlighted a couple of deficiencies in other areas, which should be
fixed independently:

SDL for index does not support fields, so there's no equivalent to a
valid SET origexpr := ... in SDL.
There are some cases where exclusive constraints get resolved as
default::std::exclusive instead of std::exclusive. This seems to
happen after the step that deals with SDL conversion to DDL and
dependency resolution. The issue is intermittent given the same input
SDL.

I don't understand from the description: does it allow use before definition? Is it a goal?

Yes, the goal is to make SDL order-independent or at least more so than it was. There are cases where entities may reference each other and a re-arranging is impossible within SDL:
# should fail in the current master
module default {
    type Foo {
        link bar := (
            SELECT Bar FILTER .name = 'foo'
        );
        property name -> str;
    }

    type Bar {
        link foo := (
            SELECT Foo FILTER .name = 'bar'
        );
        property name -> str;
    }
}

But the main point is that in a declarative language the order shouldn't matter.

Oooh, I see tests that didn't fail for me locally failed in CI. I'll look at them tomorrow.

1. SDL for index does not support fields, so there's no equivalent to a
   valid `SET origexpr := ...` in SDL.

2. There are some cases where `exclusive` constraints get resolved as
   `default::std::exclusive` instead of `std::exclusive`. This seems to
   happen after the step that deals with SDL conversion to DDL and
   dependency resolution. The issue is intermittent given the same input
   SDL.

These don't seem terribly complicated.  Please fix as part of this PR rather than xfailing a whole lot of existing tests.


Looping and reloading question pages

Timeouts are taking the users to the first page because of caching.
This was resolved by adding a caching limit and this limit is not long enough, therefore this issue
still persists, therefore the caching limit has been increased to 15.
Migrating the application to AWS will solve this issue without the need
for caching.

Trello: https://trello.com/c/cg8UDuJU

Looks like this has changed on master

@MahmudH Is there a reason why 15 minutes was chosen? Perhaps we should err on the side of doubling the cache time to 10 mins and see what the effect is.
It looks like the controller has some changes so this needs PR a rebase.

We now cache all content store requests from finder frontend for 5 minutes.  There's only been one 5xx error today on the qa controller (and four yesterday).  I'm not sure you'll get much better than that with a 15 minute cache.  Could it be worth trying to redirect people directly to the finder if the page number in the URL doesn't match the rendered page (as that would indicate you're on the mirror)?

Closing this as we don't think increasing from 5 - 15 minutes will improve things


maximum-coverage-location package

I just came across this repo for solving the MCLP. We may (or may not) want to add it to README as a related project (if we include a Related Projects section as some point).

Agreed with Martin. But I think we can point it as a related project.

Greetings @jGaboardi @martinfleis @gegen07  - I thought I would hijack this thread. We didn't know about spopt until a a few days ago. We built a separate open source library to solve location allocation problems which you can find here. With pysal-spopt however around, we don't think it is the best idea to maintain it (I just made it public for you to be able to view it). We built logic for few different problems which we derived from ESRI's location allocation suite. The first one being basically the same as you found above, however rewritten to be able to use python-mip (which they actually all do). The "Maximize Capacitated Coverage" problem may be interesting for spopt as it considers the capacity of a facility. "Maximize Coverage and Minimize Cost" is probably very similar to P-Median and "Maximize Coverage and Minimize Facilities" similar to LCSP. They are however less intuitive to use as there are not very transparent weights which have to be passed in. I'd love to hear your thoughts on this.

Maximize Coverage: This problem is used to site facilities from candidate facilites covering the largest amount of demand points within a cost cutoff value.
Maximize Capacitated Coverage: This problem is used to site facilities from candidate capacity bound facilites covering the largest amount of demand points within a cost cutoff value.
Maximize Coverage and Minimize Cost: This problem is used to site facilities from candidate facilites covering the largest amount of demand points and minimizing the overall cost within a cost cutoff value.
Maximize Coverage and Minimize Facilities: This problem is used to site facilities from candidate facilites covering the largest amount of demand points within a cost cutoff value. The difference to maximize coverage is that the number of facilities to be sited does not have to be specified.

Very true, but it is a related project. My only motivation here was make a record of it; not suggest that we use it.

Agree here with James and Germano. Good to have a record of related projects. The content itself is quite simple as well.

Greetings @jGaboardi @martinfleis @gegen07 - I thought I would hijack this thread. We didn't know about spopt until a a few days ago. We built a separate open source library to solve location allocation problems which you can find here. With pysal-spopt however around, we don't think it is the best idea to maintain it (I just made it public for you to be able to view it). We built logic for few different problems which we derived from ESRI's location allocation suite. The first one being basically the same as you found above, however rewritten to be able to use python-mip (which they actually all do). The "Maximize Capacitated Coverage" problem may be interesting for spopt as it considers the capacity of a facility. "Maximize Coverage and Minimize Cost" is probably very similar to P-Median and "Maximize Coverage and Minimize Facilities" similar to LCSP. They are however less intuitive to use as there are not very transparent weights which have to be passed in. I'd love to hear your thoughts on this.

Maximize Coverage: This problem is used to site facilities from candidate facilites covering the largest amount of demand points within a cost cutoff value.
Maximize Capacitated Coverage: This problem is used to site facilities from candidate capacity bound facilites covering the largest amount of demand points within a cost cutoff value.
Maximize Coverage and Minimize Cost: This problem is used to site facilities from candidate facilites covering the largest amount of demand points and minimizing the overall cost within a cost cutoff value.
Maximize Coverage and Minimize Facilities: This problem is used to site facilities from candidate facilites covering the largest amount of demand points within a cost cutoff value. The difference to maximize coverage is that the number of facilities to be sited does not have to be specified.

Hi Tim,
Thanks for hijack us! I would say thanks for sharing your repo and we are certainly keen to further improve our package. The next step of the development will certainly focus on adding the capacity measures in the model and also increasing the availability of other location modelling methods, such as the dispersion models.
Best,
Qunshan

Thanks @qszhao - appreciated. Would you generally be interested in some additional jupyter notebooks making it easier for GIS users to understand who are not savvy with matplotlib? Here is one example I wrote the other day - https://nbviewer.org/github/gis-ops/tutorials/blob/master/location-allocation/mclp/fossgiss22-marburg-spopt-demo.ipynb
I would be happy to contribute some of these to this repository.

@TimMcCauley, very cool example notebook!
@gegen07 @qszhao @ljwolf @martinfleis @xf37, maybe we should think about adding something like an External Examples section to the docs?

@TimMcCauley Would you be willing to give that notebook a bit of comments, translate variables into English and contribute it to spopt/notebooks?
@jGaboardi I guess we could have a section on external resources but if it is a single notebook, I'd be more keen to have it as a contribution to our docs.

I think either option would be nice, so I suppose it may come down to whether @TimMcCauley wants to contribute the example to become part of spopt or simply provide a link to where the notebook/gist is located. In a similar vein, the facility location tutorial in spaghetti was (is) featured as an external example in the docs for python-mip prior to our creation of spopt.

Thanks - I am happy to contribute. I will update the notebook with comments and also add 3 more for the remaining models LSCP, P-Median and P-Center over the next few weeks.

Very nice to have your contribution @TimMcCauley!

xref #221

I think we start either a bullet list or table in the README as was to address this for now. I'll get to that soon.

Resolve in #288


Versions filter menu in Analytics section is sorted in random order

What App Center service does this affect?
Website
Describe the bug
The dropdown menu of app versions in the Analytics section is in random (incorrect) order.  Note that the version filter in the Diagnostic section is sorted correctly.
To Reproduce
Steps to reproduce the behavior:

Go to Analytics and view the VERSIONS Dropdown
See completely random order  of versos.

Expected behavior

Versions are ordered in ascending or descending order, and match the order in the Diagnostic section.

Screenshots
Analytics (random):

Diagnostics (correct):

Desktop (please complete the following information):
macOS 10.14.4, Safari 12.1

We allow custom formats, however the use of version number in this case with a combination of numbers and letters has created this order.
We recommend to use numbers , and if done in that manner, we can guarantee the right sorting.

What order is it in? Look at the top screenshot.

On Apr 1, 2019, at 8:40 PM, Hamsa<EMAIL_ADDRESS>wrote:
We allow custom formats, however the use of version number in this case with a combination of numbers and letters has created this order.
We recommend to use numbers , and if done in that manner, we can guarantee the right sorting.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

From the screenshot I see that for Analytics - I see versions like 3.0.2a1, 3.1b1a etc which is throwing the order off, but for diagnostics even though you are using combination of letter and number it is not the sample apples to apples comparison as I do not see the same 3.1.b1a etc versions used.

To clarify, what's not a proper semantic version is not guaranteed to be sorted properly. Closing.


[Request] Huber function, concomitant scale estimation

The Matlab version of CVX [1,2] offers the options of calling the Huber function with either huber(x,M) or huber(x,M,t). The latter computes t+t*huber(x/t,M), which is useful for concomitant scale estimation [3]. It would be nice to have the same option with cvxpy.
1 - https://github.com/cvxr/CVX/blob/master/functions/huber.m
2 - https://github.com/cvxr/CVX/blob/master/functions/huber_pos.m
3 - https://statweb.stanford.edu/~owen/reports/hhu.pdf

I noticed that cxvpy relies on scipy for the huber function. Would this make it harder to implement this feature?

It seems that the version of the Huber function with three parameters is just the (shifted) perspective transform of the Huber function with two parameters. In principle, it's not hard for us to accommodate perspective functions, but this isn't something that we've gotten around to yet. See #420 and #833.

This is a great opportunity for someone who wants to contribute a new atom.

We are going to try to tackle this issue with other students !

For the canonicalization of the huber function, we don't really understand what is the DCPtoCone reduction. Would anyone have a written example of what would be this reduction for the 2 arguments-huber function :
h(M,x) = 1/2*x^2 if abs(x)<= M
h(M,x) = M(abs(x) - 1/2M) else
Thanks !

@CSHugoM you need to implement the perspective of the Huber function. Here's some information on implementing perspective transforms: https://docs.mosek.com/modeling-cookbook/practical.html?highlight=huber#perspective-functions. Here's information on implementing the basic Huber function: Example 7.4: https://docs.mosek.com/modeling-cookbook/practical.html?highlight=huber#convex-univariate-piecewise-defined-functions.

@rileyjmurray Thanks for this ! Sorry for not answering earlier, I was busy during the week end.
I'll try to implement that, just so you know that I enter an exam period so I might be less active than I was last week

Hi, since there has not been activity since last year I started implementing a solution. However, I have been having trouble with the reductions. I think the canonicalization are the same however I don't get what is the specific optimization problem I have to translate in qp2quad_form and dcp2cone.

In dcp2cone it should be exactly the same as what is done in cvx. In qp2quad_form you don't have to reduce quadratic terms in the objective. Not sure if that helps... Reach out on discord to discuss more in depth: https://discord.com/invite/4urRQeGBCr


Fix atty security vuln

Shouldn't actually affect anything. It's used by grass for it's command line, but we're only using grass as a library.
Dependabot alert
Waiting on #connorskees/grass/issues/84

grass updated. Silkenweb no longer depends on atty.


Removed restangular from CacheGroupService

What does this PR (Pull Request) do?
Removes a dependency on Restangular from the "CacheGroupService"

[x] This PR partially addresses #3571

Which Traffic Control components are affected by this PR?

Traffic Portal

Traffic Portal dependencies are not individually documented, and so no documentation changes are necessary.
What is the best way to verify this PR?
No functionality should have changed (except that errors will now be logged instead of ignored in many cases), so the existing tests should all pass.
Jeremy: actually, the only way to truly verify that the functionality did not change is to:

run the UI tests (which is a very small subset of all TP functionality)
manually verify the functionality associated with ALL the services functions that changed just to be sure all is well.

The following criteria are ALL met by this PR

[x] This PR includes tests OR I have explained why tests are unnecessary
[x] I have explained why documentation is unnecessary
[x] This PR includes an update to CHANGELOG.md OR such an update is not necessary
[x] This PR includes any and all required license headers
[x] This PR does not include a database migration
[x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/3744/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/3809/
Test PASSed.


add scenarios to feature file

dog: added the cucumber scenarios to the digital register frontend feature file.

Closing this since we're going to work into not having mentions of private individuals in there? also concerns that some things still need product ownership validation (do we want that in there? probably don't want the build breaking when we do add those features in :( )


dnf_package doesn't handle multiarch properly

Description
Given two arches, it gets confused
Example:
dnf_package 'glib2' do
  package_name ['glib2'] * 2
  arch ['x86_64', 'i686']
  action :upgrade
end

What you will find is that it will always try to install glib2-${version}.x86_64 and glib2-${version}.i686 because it compares both to the string it gets back from the helper which doesn't include the arch.
Output:
[2017-12-08T17:32:33-08:00] INFO: Processing dnf_package[glib2] action install (... line 47)
[2017-12-08T17:32:33-08:00] DEBUG: Providers for generic dnf_package resource enabled on node include: [Chef::Provider::Package::Dnf]
[2017-12-08T17:32:33-08:00] DEBUG: Provider for action install on resource dnf_package[glib2] is Chef::Provider::Package::Dnf
[2017-12-08T17:32:35-08:00] DEBUG: sending '{"action":"whatinstalled","provides":"glib2","release":"4.el7","version":"2.46.2","arch":"x86_64"}' to python helper
[2017-12-08T17:32:36-08:00] DEBUG: got 'glib2 0:2.46.2-4.el7 x86_64' from python helper
[2017-12-08T17:32:36-08:00] DEBUG: parsed glib2-0:2.46.2-4.el7.x86_64 from python helper
[2017-12-08T17:32:36-08:00] DEBUG: discarding output on stderr from python helper: No handlers could be found for logger "dnf"
[2017-12-08T17:32:36-08:00] DEBUG: sending '{"action":"whatinstalled","provides":"glib2","release":"4.el7","version":"2.46.2","arch":"i686"}' to python helper
[2017-12-08T17:32:36-08:00] DEBUG: got 'glib2 nil nil' from python helper
[2017-12-08T17:32:36-08:00] DEBUG: parsed glib2-. from python helper
[2017-12-08T17:32:36-08:00] DEBUG: sending '{"action":"whatavailable","provides":"glib2","release":"4.el7","version":"2.46.2","arch":"x86_64"}' to python helper
[2017-12-08T17:32:36-08:00] DEBUG: got 'glib2 0:2.46.2-4.el7 x86_64' from python helper
[2017-12-08T17:32:36-08:00] DEBUG: parsed glib2-0:2.46.2-4.el7.x86_64 from python helper
[2017-12-08T17:32:36-08:00] DEBUG: sending '{"action":"whatavailable","provides":"glib2","release":"4.el7","version":"2.46.2","arch":"i686"}' to python helper
[2017-12-08T17:32:36-08:00] DEBUG: got 'glib2 0:2.46.2-4.el7 i686' from python helper
[2017-12-08T17:32:36-08:00] DEBUG: parsed glib2-0:2.46.2-4.el7.i686 from python helper
[2017-12-08T17:32:36-08:00] DEBUG: dnf_package[glib2] glib2 0:2.46.2-4.el7.x86_64 needs updating to 2.46.2-4.el7
[2017-12-08T17:32:36-08:00] DEBUG: dnf_package[glib2] glib2  needs updating to 2.46.2-4.el7
[2017-12-08T17:32:56-08:00] INFO: dnf_package[glib2] installed ["glib2", "glib2"] at ["2.46.2-4.el7", "2.46.2-4.el7"]

Note here: glib2 0:2.46.2-4.el7.x86_64 needs updating to 2.46.2-4.el7
Chef Version
12.21.16
Platform Version
CentOS7
Replication Case
See above
Client Output
See above
Stacktrace
NOTE: CHEF CLIENT BUGS ONLY
This issue tracker is for the code contained within this repo -- chef-client, base knife functionality (not
plugins), chef-apply, chef-solo, chef-client -z, etc.

Requests for new or alternative functionality should be made to feedback.chef.io
Chef Server issues
ChefDK issues
Cookbook Issues (see the https://github.com/chef-cookbooks repos or search Supermarket or GitHub/Google)

so x86_64 is installed and i686 isn't, but it still thinks that " glib2 0:2.46.2-4.el7.x86_64 needs updating to 2.46.2-4.el7"

Yup. And on the next run it'll think both need to be upgraded even though they don't.

this is fixed in the yum provider rewrite in #6540
[root@default-centos-72]/home/vagrant/chef# rpm -e glib2.i686
[root@default-centos-72]/home/vagrant/chef# bundle exec ./multiarch.rb
Recipe: (chef-apply cookbook)::(chef-apply recipe)

yum_package[glib2] action upgrade

upgrade package glib2 from uninstalled to 0:2.50.3-3.el7.i686
[root@default-centos-72]/home/vagrant/chef# bundle exec ./multiarch.rb
Recipe: (chef-apply cookbook)::(chef-apply recipe)

yum_package[glib2] action upgrade (up to date)
[root@default-centos-72]/home/vagrant/chef#

need to backport all the fixes there back into the dnf provider code.

closing as it needs to get fixed in the process of #9013


Tracking/Phone Home/Upgrade notification

Addresses https://github.com/torchbox/wagtail/issues/863

[ ] Awaiting setup of https://releases.wagtail.io/latest.txt

Expected payload:
{
    'version' :'1.2.3'    // Version number. Can only contain numbers and decimal point.
    'url' : 'https://wagtail.io'  // Absolute URL to page/file containing release notes or actual package. It's up to you.
}

cloudfront setup done: https://releases.wagtail.io/latest.txt

@tomdyson: "XMLHttpRequest cannot load https://releases.wagtail.io/latest.txt. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8111' is therefore not allowed access."

@tomdyson I guess you'd be best place to add steps to the release checklist https://github.com/torchbox/wagtail/wiki/Creating-a-new-Wagtail-release

Could you rebase/squash this?

@davecranwell added notes for the release. Anything else left to do?

One thing that popped in my mind when adding the latest.txt notes to https://github.com/torchbox/wagtail/wiki/Creating-a-new-Wagtail-release is that we have the LTS branch (0.8.x) and the latest stable.
Should we concern ourselves with LTS at all? If so, what is the recommended approach? There are concerns about identifying which version to compare against.
The PyPi JSON has a stable_version key, yet I could not find anything suggesting how that can be set.
Feedback is welcome.

Having two latest.txt files (one "latest" one "stable") is one option. As is having both versions listed in a single file, however procedurally knowing which one to compare against is the main issue. Perhaps in addition to __version__, wagtailcore/__init__.py could also state whether it was a stable version or not?
Alternatively, latest.txt could itself dictated what the stable version was, which would allow us to change it on the fly without repackaging wagtail:
{
  "latest":"1.0.0",
  "stable_latest":"0.8.6",
  "stable_version_stub":"0.8"
}

Firstly, let's avoid using "stable" as a synonym for LTS - in all other contexts (such as git branch names) "stable" means any non-beta release. 1.0 final will be a "stable" release, but not (necessarily) a LTS one.
If we're going to cater for users following the LTS path, then I think we have to have something in the settings to indicate which upgrade path they want to follow - there's no way to do it just by comparing versions. Suppose the upgrade notification existed already in 0.8 - when 1.0 comes out, we can't automatically tell the difference between someone who should be offered an upgrade (because they want the latest and greatest) and someone who shouldn't (because they want to stick with 0.8 until the next LTS release).

How long does Cloudfront cache the file for? Would be good to mention that in the release checklist, so that we know when to start worrying if it hasn't updated yet... :-)

A day by default, but you can purge it through the horrible AWS interface.

Had a chat with @gasman earlier today. The LTS issue can be tackled as part of work on 1.1 or 1.2.

https://releases.wagtail.io/latest.txt is showing access denied again. This appears to happen whenever someone touches the file so clearly the instructions are missing a step related to permissions,

Updated the instructions.

Thanks, @zerolab. @ftarnell, any chance you could script this  - https://github.com/torchbox/wagtail/wiki/Creating-a-new-Wagtail-release#releaseswagtailio - up for us in Fabric / bash?

Wouldn't it be easier to host this ourselves...?
But yes, a shell script to upload a single file shouldn't be a problem.

Spec:
tom: something like `update_wagtail_release.sh --url="http://docs.wagtail.io/“ —version=1.1`
tom: should set public perms and send a purge request to the cloudfront cache

Please could you squash your commits then rebase it onto the latest master?

Just wrote this: https://gist.github.com/kaedroho/64b4ba554f650ec572f4
Feel free to stick it on a server somewhere run with a cron task (would be nicer than having to manually update this file on every single release)

Merged in c18bab66c61c7766deecb049af3d178edda39601


[SPARK-38949][SQL][3.3] Wrap SQL statements by double quotes in error messages

What changes were proposed in this pull request?
In the PR, I propose to wrap any SQL statement in error messages by double quotes "", and apply new implementation of QueryErrorsBase.toSQLStmt() to all exceptions in Query.*Errors w/ error classes. Also this PR modifies all affected tests, see the list in the section "How was this patch tested?".
Why are the changes needed?
To improve user experience with Spark SQL by highlighting SQL statements in error massage and make them more visible to users.
Does this PR introduce any user-facing change?
Yes. The changes might influence on error messages that are visible to users.
Before:
The operation DESC PARTITION is not allowed

After:
The operation "DESC PARTITION" is not allowed

How was this patch tested?
By running affected test suites:
$ build/sbt "sql/testOnly *QueryExecutionErrorsSuite"
$ build/sbt "sql/testOnly *QueryParsingErrorsSuite"
$ build/sbt "sql/testOnly *QueryCompilationErrorsSuite"
$ build/sbt "test:testOnly *QueryCompilationErrorsDSv2Suite"
$ build/sbt "test:testOnly *ExtractPythonUDFFromJoinConditionSuite"
$ build/sbt "testOnly *PlanParserSuite"
$ build/sbt "sql/testOnly *SQLQueryTestSuite -- -z transform.sql"
$ build/sbt "sql/testOnly *SQLQueryTestSuite -- -z join-lateral.sql"
$ build/sbt "sql/testOnly *SQLQueryTestSuite -- -z describe.sql"

Authored-by: Max Gekk<EMAIL_ADDRESS>Signed-off-by: Max Gekk<EMAIL_ADDRESS>(cherry picked from commit 5aba2b38beae6e1baf6f0c6f9eb3b65cf607fe77)
Signed-off-by: Max Gekk<EMAIL_ADDRESS>

@cloud-fan @HyukjinKwon @gengliangwang Could you approve the backport, please.

GAs passed. Merging to 3.3.
Thank you, @gengliangwang and @cloud-fan for review.

@HyukjinKwon After offline discussion w/ @srielau, I reverted the changes by https://github.com/apache/spark/pull/36363


(#320) Unit test cases in HR

#320
Changes include:

Removed stubs and added basic unit test cases for entities in HR.

Checked this PR :

[ ] For duplication.
[ ] For performance.
[ ] Usage of recursive methods, loops and algorithms.
[ ] For readability and understanding.
[ ] For functions with multiple responsibilities.
[ ] For scope of refactoring.
[ ] For coupling
[ ] For alternative approaches to the implementation.
[ ] For how the change impacts other parts of the system.
[ ] For validations. client side and server side validations are present.

For more insights on code reviews checkout our guidelines.


wire-transfer to Audi kirkwood

$70,000.00@ETs-Alien-Organizations/dev-ops
Originally posted by @MasterOwnerETcorps in https://github.com/ETs-Alien-Organizations/SQL.Bankbridge/issues/19#issuecomment-1902068959

https://github.com/BMO-Financial-Inc/.github/issues/66#issue-2092016482


Gear presets

🐛 Bug Report
Gear presets are currently unable to be edited since to the transition to slash commands, this is a necessary feature that needs to be fixed.
With all the new gear recently added everyone’s presets are going to change slightly and shouldn’t have to be remade.

I have been frustrated with this myself having to delete and create everytime I wanna update a preset.
otherwise it'll just remove all the gear in the preset or remove all except the change you made.
in order to use /gearpresets edit we have to type everything including what's already equipped

I have been frustrated with this myself having to delete and create everytime I wanna update a preset.
otherwise it'll just remove all the gear in the preset or remove all except the change you made.
in order to use /gearpresets edit we have to type everything including what's already equipped

I'm with you on this one man I have even said something but look a year later no change smh

/gearpresets edit gear_preset:


add profile for Roborock S6 MaxV

Device information
https://global.roborock.com/pages/roborock-s6-maxv
Home Assistant Device information
Via Roborock integration (it's also possible to use this Robot via Xiaomi Cloud, with fewer features and non-local control):
roborock.vacuum.a10 (roborock.vacuum.a10)
by Roborock
Firmware: 02.62.46

Checklist

[x] I have created a single PR per device. When you have multiple submissions please create separate PR's.
[x] For lights - I have only included the gzipped files (*.gz), not the raw CSV files.
[x] For lights - I have provided a CSV file per supported color mode. Look that up in Developer Tools -> States

Additional info

Ok let's merge the first vacuum 🥇

Awesome work! Thanks!

Guess I have to wait for the next update then ;)


can't compile

gcc-8.4.1-1.el8.x86_64
libgcc-8.4.1-1.el8.x86_64
gcc-c++-8.4.1-1.el8.x86_64
cmake-filesystem-3.18.2-9.el8.x86_64
cmake-3.18.2-9.el8.x86_64
cmake-data-3.18.2-9.el8.noarch
make-4.2.1-10.el8.x86_64
cmake-rpm-macros-3.18.2-9.el8.noarch
glibc-2.28-151.el8.x86_64
glibc-all-langpacks-2.28-151.el8.x86_64
glibc-devel-2.28-151.el8.x86_64
glibc-headers-2.28-151.el8.x86_64
glibc-common-2.28-151.el8.x86_64

[ 96%] Built target test_disk_sort
[ 96%] Linking CXX executable runbench
[ 96%] Built target runbench
[ 97%] Linking CXX executable test_phase_4
[ 97%] Built target test_phase_4
[ 97%] Linking CXX executable test_phase_2
[ 97%] Built target test_phase_2
[ 98%] Linking CXX executable test_phase_3
[ 98%] Built target test_phase_3
[ 98%] Linking CXX executable test_phase_1
[ 98%] Built target test_phase_1
[ 98%] Linking CXX executable runtest
[ 98%] Built target runtest
make: *** [Makefile:149: all] Error 2

Run Build Command(s):/usr/bin/gmake cmTC_d89bc/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_d89bc.dir/build.make CMakeFiles/cmTC_d89bc.dir/build
gmake[1]: Entering directory '/root/chia-plotter/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_d89bc.dir/CheckFunctionExists.c.o
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=pthread_create -fPIE -o CMakeFiles/cmTC_d89bc.dir/CheckFunctionExists.c.o -c /usr/share/cmake/Modules/CheckFunctionExists.c
Linking C executable cmTC_d89bc
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_d89bc.dir/link.txt --verbose=1
/usr/bin/cc  -DCHECK_FUNCTION_EXISTS=pthread_create -rdynamic CMakeFiles/cmTC_d89bc.dir/CheckFunctionExists.c.o -o cmTC_d89bc  -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_d89bc.dir/build.make:106: cmTC_d89bc] Error 1
gmake[1]: Leaving directory '/root/chia-plotter/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:140: cmTC_d89bc/fast] Error 2

what is the output of: ldconfig -p | grep pthread  ?

can you try now? latest master

what is the output of: ldconfig -p | grep pthread ?

libpthread.so.0 (libc6,x86-64, OS ABI: Linux 3.2.0) => /lib64/libpthread.so.0
libpthread.so (libc6,x86-64, OS ABI: Linux 3.2.0) => /lib64/libpthread.so
libevent_pthreads-2.1.so.6 (libc6,x86-64) => /lib64/libevent_pthreads-2.1.so.6
libOpenIPMIpthread.so.0 (libc6,x86-64) => /lib64/libOpenIPMIpthread.so.0

can you try now? latest master

[ 97%] Building CXX object lib/bls-signatures/src/CMakeFiles/runtest.dir/test.cpp.o
/usr/bin/ar: /usr/lib64/libgmp.so: File format not recognized
make[2]: *** [lib/bls-signatures/src/CMakeFiles/combined_custom.dir/build.make:79: lib/bls-signatures/src/CMakeFiles/combined_custom] Error 1
make[1]: *** [CMakeFiles/Makefile2:537: lib/bls-signatures/src/CMakeFiles/combined_custom.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 97%] Linking CXX executable runbench
[ 97%] Built target runbench
[ 98%] Linking CXX executable test_phase_3
[ 98%] Built target test_phase_3
[ 98%] Linking CXX executable test_phase_1
[ 98%] Built target test_phase_1
[ 98%] Linking CXX executable runtest
[ 98%] Built target runtest
make: *** [Makefile:149: all] Error 2

Performing C SOURCE FILE Test CMAKE_HAVE_LIBC_PTHREAD failed with the following output:
Change Dir: /root/chia-plotter/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/gmake cmTC_05cb4/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_05cb4.dir/build.make CMakeFiles/cmTC_05cb4.dir/build
gmake[1]: Entering directory '/root/chia-plotter/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_05cb4.dir/src.c.o
/usr/bin/cc   -DCMAKE_HAVE_LIBC_PTHREAD -fPIE -o CMakeFiles/cmTC_05cb4.dir/src.c.o -c /root/chia-plotter/build/CMakeFiles/CMakeTmp/src.c
Linking C executable cmTC_05cb4
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_05cb4.dir/link.txt --verbose=1
/usr/bin/cc  -DCMAKE_HAVE_LIBC_PTHREAD -rdynamic CMakeFiles/cmTC_05cb4.dir/src.c.o -o cmTC_05cb4
CMakeFiles/cmTC_05cb4.dir/src.c.o: In function `main':
src.c:(.text+0x2f): undefined reference to `pthread_create'
src.c:(.text+0x3b): undefined reference to `pthread_detach'
src.c:(.text+0x47): undefined reference to `pthread_cancel'
src.c:(.text+0x58): undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_05cb4.dir/build.make:106: cmTC_05cb4] Error 1
gmake[1]: Leaving directory '/root/chia-plotter/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:140: cmTC_05cb4/fast] Error 2

Source file was:
#include <pthread.h>

void* test_func(void* data)
{
  return data;
}

int main(void)
{
  pthread_t thread;
  pthread_create(&thread, NULL, test_func, NULL);
  pthread_detach(thread);
  pthread_cancel(thread);
  pthread_join(thread, NULL);
  pthread_atfork(NULL, NULL, NULL);
  pthread_exit(NULL);

  return 0;
}

Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /root/chia-plotter/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/gmake cmTC_30eff/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_30eff.dir/build.make CMakeFiles/cmTC_30eff.dir/build
gmake[1]: Entering directory '/root/chia-plotter/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_30eff.dir/CheckFunctionExists.c.o
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=pthread_create -fPIE -o CMakeFiles/cmTC_30eff.dir/CheckFunctionExists.c.o -c /usr/share/cmake/Modules/CheckFunctionExists.c
Linking C executable cmTC_30eff
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_30eff.dir/link.txt --verbose=1
/usr/bin/cc  -DCHECK_FUNCTION_EXISTS=pthread_create -rdynamic CMakeFiles/cmTC_30eff.dir/CheckFunctionExists.c.o -o cmTC_30eff  -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_30eff.dir/build.make:106: cmTC_30eff] Error 1
gmake[1]: Leaving directory '/root/chia-plotter/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:140: cmTC_30eff/fast] Error 2

still not working

/usr/bin/ar: /usr/lib64/libgmp.so: File format not recognized
I think there is something wrong with your system...

/usr/bin/ar: /usr/lib64/libgmp.so: File format not recognized
I think there is something wrong with your system...

Freshly installed centos8

It's an issue with this submodule: https://github.com/Chia-Network/bls-signatures
They need to fix it... it's trying to use an *.so file as a static library.

Maybe try now, I disabled building BLS tests, seems like that's where it was failing.

Maybe try now, I disabled building BLS tests, seems like that's where it was failing.

failed
[ 94%] Building C object _deps/relic-build/src/CMakeFiles/relic_s.dir/low/easy/relic_fb_mul_low.c.o
[ 94%] Building C object _deps/relic-build/src/CMakeFiles/relic_s.dir/low/easy/relic_fb_rdc_low.c.o
[ 94%] Building C object _deps/relic-build/src/CMakeFiles/relic_s.dir/low/gmp/relic_fb_shift_low.c.o
[ 95%] Building C object _deps/relic-build/src/CMakeFiles/relic_s.dir/low/easy/relic_fb_slv_low.c.o
[ 95%] Building C object _deps/relic-build/src/CMakeFiles/relic_s.dir/low/easy/relic_fb_sqr_low.c.o
[ 95%] Building C object _deps/relic-build/src/CMakeFiles/relic_s.dir/low/easy/relic_fb_srt_low.c.o
[ 96%] Building C object _deps/relic-build/src/CMakeFiles/relic_s.dir/low/easy/relic_fb_trc_low.c.o
[ 96%] Linking C static library ../lib/librelic_s.a
[ 96%] Built target relic_s
Scanning dependencies of target combined_custom
Scanning dependencies of target runbench
[ 96%] Linking CXX executable test_phase_2
[ 97%] Building CXX object lib/bls-signatures/src/CMakeFiles/runbench.dir/test-bench.cpp.o
/usr/bin/ar: /usr/lib64/libgmp.so: File format not recognized
make[2]: *** [lib/bls-signatures/src/CMakeFiles/combined_custom.dir/build.make:79: lib/bls-signatures/src/CMakeFiles/combined_custom] Error 1
make[1]: *** [CMakeFiles/Makefile2:537: lib/bls-signatures/src/CMakeFiles/combined_custom.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 97%] Built target test_phase_2
[ 97%] Linking CXX executable runbench
[ 97%] Built target runbench
[ 98%] Linking CXX executable test_phase_3
[ 98%] Built target test_phase_3
[ 98%] Linking CXX executable test_phase_1
[ 98%] Built target test_phase_1
make: *** [Makefile:149: all] Error 2

(venv) [root@bdp-core chia-plotter]# cat build/CMakeFiles/CMakeError.log
Performing C SOURCE FILE Test CMAKE_HAVE_LIBC_PTHREAD failed with the following output:
Change Dir: /root/chia-plotter/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/gmake cmTC_a9fb8/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_a9fb8.dir/build.make CMakeFiles/cmTC_a9fb8.dir/build
gmake[1]: Entering directory '/root/chia-plotter/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_a9fb8.dir/src.c.o
/usr/bin/cc   -DCMAKE_HAVE_LIBC_PTHREAD -fPIE -o CMakeFiles/cmTC_a9fb8.dir/src.c.o -c /root/chia-plotter/build/CMakeFiles/CMakeTmp/src.c
Linking C executable cmTC_a9fb8
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_a9fb8.dir/link.txt --verbose=1
/usr/bin/cc  -DCMAKE_HAVE_LIBC_PTHREAD -rdynamic CMakeFiles/cmTC_a9fb8.dir/src.c.o -o cmTC_a9fb8
CMakeFiles/cmTC_a9fb8.dir/src.c.o: In function `main':
src.c:(.text+0x2f): undefined reference to `pthread_create'
src.c:(.text+0x3b): undefined reference to `pthread_detach'
src.c:(.text+0x47): undefined reference to `pthread_cancel'
src.c:(.text+0x58): undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_a9fb8.dir/build.make:106: cmTC_a9fb8] Error 1
gmake[1]: Leaving directory '/root/chia-plotter/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:140: cmTC_a9fb8/fast] Error 2

Source file was:
#include <pthread.h>

void* test_func(void* data)
{
  return data;
}

int main(void)
{
  pthread_t thread;
  pthread_create(&thread, NULL, test_func, NULL);
  pthread_detach(thread);
  pthread_cancel(thread);
  pthread_join(thread, NULL);
  pthread_atfork(NULL, NULL, NULL);
  pthread_exit(NULL);

  return 0;
}

Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /root/chia-plotter/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/gmake cmTC_8c458/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_8c458.dir/build.make CMakeFiles/cmTC_8c458.dir/build
gmake[1]: Entering directory '/root/chia-plotter/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_8c458.dir/CheckFunctionExists.c.o
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=pthread_create -fPIE -o CMakeFiles/cmTC_8c458.dir/CheckFunctionExists.c.o -c /usr/share/cmake/Modules/CheckFunctionExists.c
Linking C executable cmTC_8c458
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_8c458.dir/link.txt --verbose=1
/usr/bin/cc  -DCHECK_FUNCTION_EXISTS=pthread_create -rdynamic CMakeFiles/cmTC_8c458.dir/CheckFunctionExists.c.o -o cmTC_8c458  -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_8c458.dir/build.make:106: cmTC_8c458] Error 1
gmake[1]: Leaving directory '/root/chia-plotter/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:140: cmTC_8c458/fast] Error 2

it seems some different  between libpthreads and libpthread ?

Centos Stream fails:
[ 96%] Linking C static library ../lib/librelic_s.a
[ 96%] Built target relic_s
Scanning dependencies of target combined_custom
Scanning dependencies of target runbench
/bin/ar: /usr/lib64/libgmp.so: File format not recognized
make[2]: *** [lib/bls-signatures/src/CMakeFiles/combined_custom.dir/build.make:79: lib/bls-signatures/src/CMakeFiles/combined_custom] Error 1
make[1]: *** [CMakeFiles/Makefile2:537: lib/bls-signatures/src/CMakeFiles/combined_custom.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 97%] Building CXX object lib/bls-signatures/src/CMakeFiles/runbench.dir/test-bench.cpp.o
[ 97%] Linking CXX executable runbench
[ 97%] Built target runbench
[ 98%] Linking CXX executable test_phase_3
[ 98%] Built target test_phase_3
[ 98%] Linking CXX executable test_phase_1
[ 98%] Built target test_phase_1
make: *** [Makefile:149: all] Error 2
UBUNTU 20.04 fails here:
[ 94%] Building C object _deps/relic-build/src/CMakeFiles/relic_s.dir/low/easy/relic_fb_trc_low.c.o
[ 94%] Linking C static library ../lib/librelic_s.a
[ 94%] Built target relic_s
make: *** [Makefile:130: all] Error 2
UBUNTU 16.04 w/updated CMAKE 3.20.3 fails:
[ 94%] Building C object _deps/relic-build/src/CMakeFiles/relic_s.dir/low/easy/relic_fb_trc_low.c.o
[ 94%] Linking CXX executable check_phase_1
[ 94%] Linking C static library ../lib/librelic_s.a
[ 94%] Built target relic_s
[ 94%] Built target check_phase_1
Makefile:135: recipe for target 'all' failed
make: *** [all] Error 2
Hmmm....

Centos Stream fails:
[ 96%] Linking C static library ../lib/librelic_s.a
[ 96%] Built target relic_s
Scanning dependencies of target combined_custom
Scanning dependencies of target runbench
/bin/ar: /usr/lib64/libgmp.so: File format not recognized
make[2]: *** [lib/bls-signatures/src/CMakeFiles/combined_custom.dir/build.make:79: lib/bls-signatures/src/CMakeFiles/combined_custom] Error 1
make[1]: *** [CMakeFiles/Makefile2:537: lib/bls-signatures/src/CMakeFiles/combined_custom.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 97%] Building CXX object lib/bls-signatures/src/CMakeFiles/runbench.dir/test-bench.cpp.o
[ 97%] Linking CXX executable runbench
[ 97%] Built target runbench
[ 98%] Linking CXX executable test_phase_3
[ 98%] Built target test_phase_3
[ 98%] Linking CXX executable test_phase_1
[ 98%] Built target test_phase_1
make: *** [Makefile:149: all] Error 2
UBUNTU 20.04 fails here:
[ 94%] Building C object _deps/relic-build/src/CMakeFiles/relic_s.dir/low/easy/relic_fb_trc_low.c.o
[ 94%] Linking C static library ../lib/librelic_s.a
[ 94%] Built target relic_s
make: *** [Makefile:130: all] Error 2
UBUNTU 16.04 w/updated CMAKE 3.20.3 fails:
[ 94%] Building C object _deps/relic-build/src/CMakeFiles/relic_s.dir/low/easy/relic_fb_trc_low.c.o
[ 94%] Linking CXX executable check_phase_1
[ 94%] Linking C static library ../lib/librelic_s.a
[ 94%] Built target relic_s
[ 94%] Built target check_phase_1
Makefile:135: recipe for target 'all' failed
make: *** [all] Error 2
Hmmm....

cat your errlogs at build/CMakeFiles/CMakeError.log

UBUNTU 20.02:
[anna-i3] (jade):  ldconfig -p | grep pthread
libpthread.so.0 (libc6,x86-64, OS ABI: Linux 3.2.0) => /lib/x86_64-linux-gnu/libpthread.so.0
libpthread.so.0 (libc6, OS ABI: Linux 3.2.0) => /lib/i386-linux-gnu/libpthread.so.0
libpthread.so.0 (libc6, OS ABI: Linux 3.2.0) => /lib32/libpthread.so.0
libpthread.so (libc6,x86-64, OS ABI: Linux 3.2.0) => /lib/x86_64-linux-gnu/libpthread.so
libevent_pthreads-2.1.so.7 (libc6,x86-64) => /lib/x86_64-linux-gnu/libevent_pthreads-2.1.so.7
libOpenIPMIpthread.so.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libOpenIPMIpthread.so.0
(/home/jade/chia-plotter)
[anna-i3] (jade): cat build/CMakeFiles/CMakeError.log
Performing C SOURCE FILE Test CMAKE_HAVE_LIBC_PTHREAD failed with the following output:
Change Dir: /home/jade/chia-plotter/build/CMakeFiles/CMakeTmp
Run Build Command(s):/bin/make cmTC_e108e/fast && /bin/make -f CMakeFiles/cmTC_e108e.dir/build.make CMakeFiles/cmTC_e108e.dir/build
make[1]: Entering directory '/home/jade/chia-plotter/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_e108e.dir/src.c.o
/bin/cc   -DCMAKE_HAVE_LIBC_PTHREAD -fPIE   -o CMakeFiles/cmTC_e108e.dir/src.c.o   -c /home/jade/chia-plotter/build/CMakeFiles/CMakeTmp/src.c
Linking C executable cmTC_e108e
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_e108e.dir/link.txt --verbose=1
/bin/cc  -DCMAKE_HAVE_LIBC_PTHREAD    -rdynamic CMakeFiles/cmTC_e108e.dir/src.c.o  -o cmTC_e108e
/bin/ld: CMakeFiles/cmTC_e108e.dir/src.c.o: in function main': src.c:(.text+0x3e): undefined reference to pthread_create'
/bin/ld: src.c:(.text+0x4a): undefined reference to pthread_detach' /bin/ld: src.c:(.text+0x5b): undefined reference to pthread_join'
collect2: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_e108e.dir/build.make:87: cmTC_e108e] Error 1
make[1]: Leaving directory '/home/jade/chia-plotter/build/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_e108e/fast] Error 2
Source file was:
#include <pthread.h>
void* test_func(void* data)
{
return data;
}
int main(void)
{
pthread_t thread;
pthread_create(&thread, NULL, test_func, NULL);
pthread_detach(thread);
pthread_join(thread, NULL);
pthread_atfork(NULL, NULL, NULL);
pthread_exit(NULL);
return 0;
}
Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /home/jade/chia-plotter/build/CMakeFiles/CMakeTmp
Run Build Command(s):/bin/make cmTC_b3005/fast && /bin/make -f CMakeFiles/cmTC_b3005.dir/build.make CMakeFiles/cmTC_b3005.dir/build
make[1]: Entering directory '/home/jade/chia-plotter/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_b3005.dir/CheckFunctionExists.c.o
/bin/cc   -DCHECK_FUNCTION_EXISTS=pthread_create -fPIE   -o CMakeFiles/cmTC_b3005.dir/CheckFunctionExists.c.o   -c /usr/share/cmake-3.16/Modules/CheckFunctionExists.c
Linking C executable cmTC_b3005
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_b3005.dir/link.txt --verbose=1
/bin/cc  -DCHECK_FUNCTION_EXISTS=pthread_create    -rdynamic CMakeFiles/cmTC_b3005.dir/CheckFunctionExists.c.o  -o cmTC_b3005  -lpthreads
/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_b3005.dir/build.make:87: cmTC_b3005] Error 1
make[1]: Leaving directory '/home/jade/chia-plotter/build/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_b3005/fast] Error 2

But that's a different issue, see: https://stackoverflow.com/questions/64514666/what-does-performing-test-cmake-have-libc-pthread-failed-actually-mean

This output is common for Unix-like systems. Despite "Failed" and "not found" words, this is perfectly good output.

Maybe now? I disabled building BLS benchmarks too.

Failing to understand how to correct the "undefined reference to pthread_create'
and  pthread_detach'" errors, I just built it on ubuntu 18.04.
Trying on other systems now...  Cheers madmax, looks brilliant :-)

Maybe now? I disabled building BLS benchmarks too.

not work
Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /root/chia-plotter/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/gmake cmTC_6829b/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_6829b.dir/build.make CMakeFiles/cmTC_6829b.dir/build
gmake[1]: Entering directory '/root/chia-plotter/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_6829b.dir/CheckFunctionExists.c.o
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=pthread_create -fPIE -o CMakeFiles/cmTC_6829b.dir/CheckFunctionExists.c.o -c /usr/share/cmake/Modules/CheckFunctionExists.c
Linking C executable cmTC_6829b
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_6829b.dir/link.txt --verbose=1
/usr/bin/cc  -DCHECK_FUNCTION_EXISTS=pthread_create -rdynamic CMakeFiles/cmTC_6829b.dir/CheckFunctionExists.c.o -o cmTC_6829b  -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_6829b.dir/build.make:106: cmTC_6829b] Error 1
gmake[1]: Leaving directory '/root/chia-plotter/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:140: cmTC_6829b/fast] Error 2

/usr/bin/ld: cannot find -lpthreads

why use -lpthreads , maybe -lpthread is correct?

Ignore the pthreads errors in CMakeError.log, those are normal.
The issue is with libgmp.so being used as a static library, which of course won't work.
The cultprint is in: https://github.com/Chia-Network/bls-signatures/blob/4e21aa6742d67562920ac67507e90b722116b14b/src/CMakeLists.txt#L56

Failing to understand how to correct the "undefined reference to pthread_create'
and pthread_detach'" errors, I just built it on ubuntu 18.04.
Trying on other systems now... Cheers madmax, looks brilliant :-)

try upgrade your libc6 ,
and
apt install libgmp3-dev libsodium-dev

Yeah I already caught the sodium missing, and upgrading 20.04 to current didn't help. Centos is stuck on the linking, ubuntu 20.04 still doesn't build...

I submitted a bug report: https://github.com/Chia-Network/bls-signatures/issues/225

Ubuntu 20.04 should work, using it myself. x86_64?

Yes, 20.04 x86_64, it's not fully current, upgrading and will report back :-)

After dist-upgrade on 20.04, it still fails:
[anna-i3] (root): cat build/CMakeFiles/CMakeError.log
Performing C SOURCE FILE Test CMAKE_HAVE_LIBC_PTHREAD failed with the following output:
Change Dir: /home/chia/chia-plotter/build/CMakeFiles/CMakeTmp
Run Build Command(s):/bin/make cmTC_5cbe6/fast && /bin/make -f CMakeFiles/cmTC_5cbe6.dir/build.make CMakeFiles/cmTC_5cbe6.dir/build
make[1]: Entering directory '/home/chia/chia-plotter/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_5cbe6.dir/src.c.o
/bin/cc   -DCMAKE_HAVE_LIBC_PTHREAD -fPIE   -o CMakeFiles/cmTC_5cbe6.dir/src.c.o   -c /home/chia/chia-plotter/build/CMakeFiles/CMakeTmp/src.c
Linking C executable cmTC_5cbe6
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_5cbe6.dir/link.txt --verbose=1
/bin/cc  -DCMAKE_HAVE_LIBC_PTHREAD    -rdynamic CMakeFiles/cmTC_5cbe6.dir/src.c.o  -o cmTC_5cbe6
/bin/ld: CMakeFiles/cmTC_5cbe6.dir/src.c.o: in function main': src.c:(.text+0x3e): undefined reference to pthread_create'
/bin/ld: src.c:(.text+0x4a): undefined reference to pthread_detach' /bin/ld: src.c:(.text+0x5b): undefined reference to pthread_join'
collect2: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_5cbe6.dir/build.make:87: cmTC_5cbe6] Error 1
make[1]: Leaving directory '/home/chia/chia-plotter/build/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_5cbe6/fast] Error 2
Clearly something is different on my system Vs. your build system. I'm not super familiar with Ubuntu or how to dump the overall config, but it's pretty standard, with /etc/apt/sources.list.d having these:
4 -rw-r--r-- 1 root root 132 Mar 16 21:17 bitcoin-ubuntu-bitcoin-focal.list.save
4 -rw-r--r-- 1 root root 136 Mar 16 21:17 ethereum-ubuntu-ethereum-focal.list
4 -rw-r--r-- 1 root root 142 Mar 16 21:17 graphics-drivers-ubuntu-ppa-focal.list
4 -rw-r--r-- 1 root root 146 Mar 16 21:17 oibaf-ubuntu-graphics-drivers-focal.list
apt-cache madison cmake says:
cmake | 3.16.3-1ubuntu1 | http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages
Sorry I'm not much more help, but willing to test across Centos systems (7 and stream) and 16/18/20 Ubuntu...

Can you show terminal output? cmake error log is not very helpful here.

log.txt
Here ya go, this is Ubuntu 20.04

Wow, that's a strict compiler. Should be fixed now.

https://github.com/madMAx43v3r/chia-plotter/issues/52#issuecomment-857239757

In arch you just need to install libgmp-static and libsodium-static.

For the record, libgmp-static and libsodium-static are not provided by the default Arch package manager (pacman), so, you need to use a package manager to interact with AUR packages (such as yay, yaourt, and others)
In my case that was easy as running yay -S libgmp-static libsodium-static

Because all the cool chicks run Gentoo ;-)
Fails on libsodium:
[ 96%] Building C object _deps/relic-build/src/CMakeFiles/relic_s.dir/low/easy/relic_fb_trc_low.c.o
[ 97%] Linking C static library ../lib/librelic_s.a
[ 97%] Built target relic_s
Scanning dependencies of target combined_custom
/usr/bin/ar: /usr/lib64/libsodium.so: file format not recognized
make[2]: *** [lib/bls-signatures/src/CMakeFiles/combined_custom.dir/build.make:79: lib/bls-signatures/src/CMakeFiles/combined_custom] Error 1
make[1]: *** [CMakeFiles/Makefile2:481: lib/bls-signatures/src/CMakeFiles/combined_custom.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 97%] Linking CXX executable test_phase_2
[ 97%] Built target test_phase_2
[ 98%] Linking CXX executable test_phase_3
[ 98%] Built target test_phase_3
[ 98%] Linking CXX executable test_phase_1
[ 98%] Built target test_phase_1
make: *** [Makefile:149: all] Error 2
(/home/chia/chia-plotter)
[gentoo] (root): equery b /usr/lib64/libsodium.so

Searching for /usr/lib64/libsodium.so ...
dev-libs/libsodium-1.0.18 (/usr/lib64/libsodium.so.23.3.0)
dev-libs/libsodium-1.0.18 (/usr/lib64/libsodium.so -> libsodium.so.23.3.0)

On Fedora 33 Server I installed static versions of the libs sodium and gmp:
sudo yum install libsodium-static gmp-static
After that the project compiled without errors.

On Fedora 33 Server I installed static versions of the libs sodium and gmp:
sudo yum install libsodium-static gmp-static
After that the project compiled without errors. I think this might work for any RHEL derivate

gmp-static   <-   centos do not have such package