func populatePageValues can't handle API's returning 'since'

API's such as the Organization ListAll can return many pages of Organizations. The pagination value is called since and holds the id of the last Org returned. A simple change to populatePageValues appears, so far, to be able to support this. Not sure if this a fault or a improvement! I'm new to golang so please forgive.
Old code in populatePageValues:
		page := q.Get("page")
		if page == "" {
			continue
		}

proposed change to populatePageValues
		page := q.Get("page")
		since := q.Get("since")
		if page == "" && since == "" {
			continue
		}

		if since != "" {
			page = since
		}

I see that orgs ListAll uses a since parameter to control getting the next group of results here:
https://docs.github.com/en/rest/reference/orgs#list-organizations
but the link then points here:
https://docs.github.com/en/rest/overview/resources-in-the-rest-api#link-header
which makes no mention of receiving since in the header.
Additionally, the only pagination documentation I could find is here:
<EMAIL_ADDRESS>which also does not include since.
Can you please show an example header response that includes the since value?
I believe you, but would like to have it documented in this issue, please.

Here is a slightly formatted and sanitised copy of our header - we are using GHE not github.com
net/http.Header ["Content-Type": ["application/json; charset=utf-8"],
"Cache-Control": ["private, max-age=60, s-maxage=60"],
"Vary": ["Accept, Authorization, Cookie, X-GitHub-OTP"],
"X-Accepted-Oauth-Scopes": [""],
"Strict-Transport-Security": ["max-age=31536000; includeSubdomains"],
"Referrer-Policy": ["origin-when-cross-origin, strict-origin-when-cross-origin"],
"X-Oauth-Scopes": ["admin:gpg_key, admin:org, admin:org_hook, admin:pre_receive_hook, admin:public_key, admin:repo_hook, delete_repo, gist, notifications, repo, site_admin, user, write:discussion"],
"X-Github-Media-Type": ["github.v3; format=json"],
"Link": ["https://ourserver/api/v3/organizations?since=296; rel="next", https://ourserver/api/v3/organizations{?since}; rel="first""],
"Access-Control-Expose-Headers": ["ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, Deprecation, Sunset"],
"Access-Control-Allow-Origin": ["*"],
"Content-Security-Policy": ["default-src 'none'"],
"Server": ["GitHub.com"],
"X-Github-Request-Id": ["XYZ long hex number XYZ"],
"X-Xss-Protection": ["1; mode=block"],
"X-Runtime-Rack": ["0.132278"],
"Date": ["Thu, 30 Sep 2021 12:20:54 GMT"],
"Etag": ["W/"XYZ long hex number XYZ""],
"X-Github-Enterprise-Version": ["3.0.13"], "X-Frame-Options": ["deny"], "X-Content-Type-Options": ["nosniff"], ]
The func is parsing the Link entry

OK, thank you, @brianlangdon !
Would you like to create a PR or would you like me to open up this issue for one of our other amazing contributors to address this issue?

Hi @gmlewis, I'll give it a go, although I'm not sure how I'd create tests for it.

Hi @gmlewis, I'll give it a go, although I'm not sure how I'd create tests for it.

OK, cool.  It's yours, @brianlangdon .
As for a test, check out this example, and create a new test based upon it (possibly even right after it):
https://github.com/google/go-github/blob/master/github/github_test.go#L622-L649

As reported here: https://github.com/google/go-github/pull/2135#issuecomment-986255780
it turns out that both since and page can be returned in the header of the response, which causes the regular pagination to break.
I tested this myself with the following test program:
package main

import (
	"context"
	"log"
	"time"

	"github.com/google/go-github/v41/github"
)

func main() {
	client := github.NewClient(nil)
	ctx := context.Background()

	since, err := time.Parse(time.RFC3339, "2021-12-04T10:43:42Z")
	if err != nil {
		log.Fatal(err)
	}

	opts := &github.CommitsListOptions{Since: since}
	d, resp, err := client.Repositories.ListCommits(ctx, "Homebrew", "homebrew-cask", opts)
	if err != nil {
		log.Fatal(err)
	}

	log.Printf("len(d)=%v", len(d))
	log.Printf("resp.Header=%#v", resp.Header)
	log.Printf("resp.NextPage=%v", resp.NextPage)
	log.Printf("resp.PrevPage=%v", resp.PrevPage)
	log.Printf("resp.FirstPage=%v", resp.FirstPage)
	log.Printf("resp.LastPage=%v", resp.LastPage)
	log.Printf("resp.NextPageToken=%v", resp.NextPageToken)
	log.Printf("resp.Cursor=%v", resp.Cursor)
	log.Printf("resp.Before=%v", resp.Before)
	log.Printf("resp.After=%v", resp.After)
}

which returned:
$ go run main.go
2021/12/05 12:25:24 len(d)=30
2021/12/05 12:25:24 resp.Header=http.Header{...
"Link":[]string{"<https://api.github.com/repositories/3623050/commits?since=2021-12-04T10%3A43%3A42Z&page=2>; rel=\"next\", <https://api.github.com/repositories/3623050/commits?since=2021-12-04T10%3A43%3A42Z&page=2>; rel=\"last\""},
...}
2021/12/05 12:25:24 resp.NextPage=0
2021/12/05 12:25:24 resp.PrevPage=0
2021/12/05 12:25:24 resp.FirstPage=0
2021/12/05 12:25:24 resp.LastPage=0
2021/12/05 12:25:24 resp.NextPageToken=2021-12-04T10:43:42Z
2021/12/05 12:25:24 resp.Cursor=
2021/12/05 12:25:24 resp.Before=
2021/12/05 12:25:24 resp.After=

This should say: resp.NextPage=2 (see the header Link).


get_log is broken for impala (the same issue is fixed already in impyla)

Hi!
get_log() is already fixed in impyla to use FetchResults: https://github.com/cloudera/impyla/blob/6ff1794c9c9858ebbd7f59f5075857a63b698a61/impala/hiveserver2.py#L1115-L1130, while in hue, it's still GetLog only, which does not work for impala: https://github.com/cloudera/hue/blob/c1b79cd74b29cddab5511c615cd7013fbb5f2969/apps/beeswax/src/beeswax/server/hive_server2_lib.py#L973-L981.
Could that patch also be applied here?
thanks for looking at this!
dalia

Looks like we should just remove 'or self.query_server['server_name'] == 'impala''?
https://github.com/cloudera/hue/blob/35876d414745831c012210bdde417faad25f4e5d/apps/beeswax/src/beeswax/server/hive_server2_lib.py#L1219


Add Postgres read/write adapter

Adds functionality to interact with Postgres databases.
Reading

For initial table dumps, uses SELECT * FROM {table}.  It can probably be optimized, but works effectively for the 2GB dataset I had.
For tailing future changes, uses logical decoding and the test_decoding plugin.  This plugin ships with all Postgres 9.4: http://www.postgresql.org/docs/9.4/static/logicaldecoding-example.html

Writing
Schema on any destination Postgres is expected to be correct.  If incorrect, write commands will have unexpected behaviors -- some fail and some succeed based on the incoming fields.

For inserts, a simple INSERT statement is built based on the values provided.
For updates, the process is:

find the primary keys for a table
build update commands based on those primary keys

For deletes, the process is:

find the primary keys for a table
build command to delete row with those primary keys

When updating / deleting a table with composite primary keys, if all primary keys are not provide, the action will fail.
Errors
Errors when writing are logged to standard out.
Potential changes
With the upcoming Postgres 9.5, upsert behavior will be built-in.  I would change all INSERT / UPDATE to use the upcoming upsert pattern.

is anyone reviewing this pull request? Would like to see transporter get Postgres support.

thanks @Winslett ! i've integrated this PR into the experimental branch here https://github.com/compose/transporter/commit/e81d5f0847efaabf2d548a0a2b526412344d139b will push another experimental binary release soon.


Switch from turndown-plugin-gfm to joplin-turndown-plugin-gfm (or any other maintained fork)

The original plug-in is not maintained (last patch is from 3 years ago and PRs for bugfixes aren't merged) and it's not able to convert tables properly (see this or this).
But it seems that forks like joplin-turndown-plugin-gfm are well maintained and contain the bugfixes.
Maybe there's a better fork but CGUs switched to this one as well.
PS: As always thank you so much for copy-selection-as-markdown. I'm using it every day! :+1:

@alexanderadam Thank you for the suggestion. Really glad your feedback and it's totally my pleasure. The plugin you mentioned is really promising. I'll test it and get back to you (hopefully sooner but I have recently have limited bandwidth).

I'll test it and get back to you (hopefully sooner but I have recently have limited bandwidth).

No pressure.  Maintaining FOSS is no obligation. :wink:

Now there's also another fork.
I don't know which one might be better, though. :man_shrugging:
It'd probably be easier to have fixes in a single fork than distributed over many, but I'm not making the rules. :disappointed:

@alexanderadam Thanks for your patience and update for the issue. Newer fork looks good to me, as it might have a chance to merge into the original one. I'll compare these.

@alexanderadam it might have a chance to merge into the original one.

What makes you think that? :thinking:
The old fork also has a PR ongoing… since 2018.
But the maintainer of the original project never merged it. I also asked the maintainer to explicitly mention at least, that the package isn't maintained.

Ah I didn't know the https://github.com/domchristie/turndown-plugin-gfm/pull/10. Now it's difficult to compare 🤔

Just wondered if this is still on the radar. Not sure how big of an effort it would be to switch.


Setting color temp and brightness with light.turn_on sends two conflicting brightness settings

Describe the bug
When calling light.turn_on with both a brightness and color temperature, line 213 appends a second brightness code setting the brightness back to its original value with this code on line 213:
            # brightness
            ha_brightness = self.brightness
            new_range = self._tuya_brightness_range()
            tuya_brightness = self.remap(
                ha_brightness, 0, 255, new_range[0], new_range[1]
            )
            commands += [{"code": self.dp_code_bright, "value": int(tuya_brightness)}]

Expected behavior
Needs to only add a brightness command if it's not in the kwargs:
        if ATTR_BRIGHTNESS not in kwargs:
            # brightness
            ha_brightness = self.brightness
            new_range = self._tuya_brightness_range()
            tuya_brightness = self.remap(
                ha_brightness, 0, 255, new_range[0], new_range[1]
            )
            commands += [{"code": self.dp_code_bright, "value": int(tuya_brightness)}]

Home Assistant Version

2021.8.0

I had a similar issue but did not diagnose it deep enough to say whether it is the same bug.

Example DEBUG - Json POST Body showing duplicate bright_value_v2:
DEBUG (SyncWorker_0) [tuya iot] Request: method = POST, url = https://openapi.tuyaeu.com/v1.0/devices/xxxx/commands, params = None, body = {'commands': [{'code': 'switch_led', 'value': True}, {'code': 'bright_value_v2', 'value': 899}, {'code': 'temp_value_v2', 'value': 922}, {'code': 'bright_value_v2', 'value': 76}]}, t = xxxx

Further investigation. When using a lovelace color picker, all works ok because a single KWARG is provided.
When activating a scene, two KWARGs are provided - 'brightness' and either hs_color or color_temp., The logic gives unexpected results when two parameters are provided.

Disclaimer: I am not a coder/python expert... but managed to hack this together which works in all the combinations I could think of.

Only handled ATTR_BRIGHTNESS if ATTR_HS_COLOR not in kwargs.
Replaced:

        if ATTR_BRIGHTNESS in kwargs

With:
        if (
            ATTR_BRIGHTNESS in kwargs
            and ATTR_HS_COLOR not in kwargs
        ):

For ATTR_HS_COLOR, I handled ATTR_BRIGHTNESS dependant on if it was in kwargs or not.

            # hsv v
            if ATTR_BRIGHTNESS not in kwargs:
                ha_v = self.brightness
                v_range = self._tuya_hsv_v_range()
                colour_data["v"] = int(self.remap(ha_v, 0, 255, v_range[0], v_range[1]))

                commands += [
                    {"code": self.dp_code_colour, "value": json.dumps(colour_data)}
                ]

            if ATTR_BRIGHTNESS in kwargs:
                new_range = self._tuya_brightness_range()
                colour_data["v"] = int(
                    self.remap(
                        kwargs[ATTR_BRIGHTNESS], 0, 255, new_range[0], new_range[1]
                    )
                )
                commands += [
                    {"code": self.dp_code_colour, "value": json.dumps(colour_data)}
                ]

For ATTR_COLOR_TEMP, I added as per the recommendation in the original bug submission:

            if ATTR_BRIGHTNESS not in kwargs:
                # brightness
                ha_brightness = self.brightness
                new_range = self._tuya_brightness_range()
                tuya_brightness = self.remap(
                    ha_brightness, 0, 255, new_range[0], new_range[1]
                )
                commands += [{"code": self.dp_code_bright, "value": int(tuya_brightness)}]

I am sure there are far more elegant ways to do this in Python... but the logic seems to work.

Same here:
2021-08-17 16:42:27 DEBUG (SyncWorker_1) [tuya iot] Request: method = POST, url = https://openapi.tuyaus.com/v1.0/devices/xxxxx/commands, params = None, body = {'commands': [{'code': 'switch_led', 'value': True}, {'code': 'bright_value_v2', 'value': 110}, {'code': 'temp_value_v2', 'value': 0}, {'code': 'bright_value_v2', 'value': 1000}]}, t = xxxxxxxx

@amanzie Thank you for your suggestion, we will track the problem.

I've had significant problems with scenes mixing color, white, and brightness not working, or working only after being activated multiple times.  With #486 those problems have disappeared.  Please review and let me know if you find any problems.

Nice! I currently have it installed via HACS, so I need to do some work to try it out. It should take care of #314 , also. You might want to look at #315 , since it’s in the same area.


ptrdiff_t needs to be int, not long

Fixes the definition of _PDCLIB_ptrdiff to be int instead of long, as it should be. Using the incorrect type breaks libc++ compilation because of mismatched types when instantiating a template in streambuf.

NevolutionX still builds fine with this change, runs like before. Probably no pointer subtraction going on there though. :thinking:


Added a new quote with a image.

Signed-off-by:Terry Kang Terry@localhost

Add a change log! Don't forget to add the change log!!!


Documentation

expose ethic and usage, peace and love.
@sweetdifficult

thanks :3 i love you :heart:

:heart:

[x] Ethic

[ ] Usage

[ ] Version

[ ] Concept

[ ] Developer

[ ] Dependency

@sweetdifficult there is so much to write :imp:


Update README.md to reference the Bob example when talking about test…

Update README.md to reference the Bob example when talking about test generators. BobTestGenerator is a much more simple example. And, BobTestGenerator is based off of TestSuiteBuilder which is the preferred method for creating the generators.

Thanks @ErikSchierboom . I had to fix two other references to all-your-base as well.

Thanks @ricemery!


Return ExternalID from the AWS integration resource

What does this PR do?
In order to create AWS integration together with a role as a part of a CloudFormation stack we need to know the ExternalID.
Closes #71.
Description of the Change
The python API response contains external_id, so as I understand it's only necessary to make it available to CloudFormation.
Alternate Designs
None
Possible Drawbacks
None
Verification Process
Not verified
Additional Notes
None
Release Notes
None
Review checklist (to be filled by reviewers)

[ ] Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
[x] PR title must be written as a CHANGELOG entry (see why)
[x] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
[x] PR should not have do-not-merge/ label attached.
[ ] If Applicable, issue must have kind/ and severity/ labels attached at least.

This probably won't work because the ExternalID is not available in the read_handler.


dev-dependencies

Could you please clarify what exactly this issue is?

Hey @supremestdoggo,
Thanks for taking an interest in my project. This issue intends that Poac needs supporting dev-dependencies for development only such as testing tools and linters. Cargo implements the dev-dependency feature as well, and so many package managers do. The issue name so no sense that I will fix it.


Can't build dependencies with native code

I'm working on a new built-in component for Home Assistant, and one of its dependencies is the netifaces module, which has some C code in it. Loading the component as a custom component into Hass.io fails to build that module, I think because Hass.io is missing things like gcc, python3-dev, and libc-dev. I was able to work around for testing by apk adding those items in the ssh add-on and manually pip3 installing netifaces to /config/deps. However, f I want my component to be built-in, Hass.io needs to be able to build its dependencies.
Would you accept a change (presumably in hassio-build) that adds the necessary things to the Docker image, or is there some other way that I should solve this problem?
Thanks in advance for your advice.

Use https://github.com/home-assistant/hassio-addons/tree/master/custom_deps for you custom component. After it is in upstream it will be build automatic correct with all the other components.


Marathon missing configuration

Thansk! wercker build is failing, otherwise lgtm

Closing this as https://github.com/Capgemini/Apollo/pull/338 got in.


Can fescar work without fescar-server?

Why you need it?
I want to integrate fescar into my project, but I don't want to start fescar-server.
How it could be?
It would be better to have a LocalServer like RpcServer.
Other related information

@TenzeTseng Currently not supported, but it is actually supported

[Another decentralization question] When I used fescar-server in my business project . If the fescar-server service group is down , how can
I ensure the business project  run well  temporarily ?

Distributed transactions cannot be executed if all servers in the cluster are hung. Distributed transaction degradation is automatically done by the number of errors in the time period. For an implementation without a server, the business database is also required to hold the transaction record and lock state of the transaction. Similarly, the distributed transaction of the database does not work properly.

@TenzeTseng have a look at EasyTransaction, there's something you want

because of no update for a long time, I will close the issue, if you have other questions, please reopen it or create a new one


Queries?

more a feature request than a issue.
but wouldn't you want to put in a query so you can see the info?

@PFC-developer can you elaborate, query of what info?

The ownership structure.
Wouldn't it be useful to also have a query to show the new & pending owner in contracts that can be added in a similar way to how you add the exec types ?

I did not include a query method initially because for my own use case, I have a config query instead which includes both the ownership info and other stuff, and this "other stuff" varies by contracts.
But yeah a query method can be useful. I will add it.


the change to the encrypt option resulted in 3 entries in OE for the same target databases

the first one is the connection prior to upgrading to the latest insider.
the second is with Encrypt on.
the third is with Encrypt off.
IMO, this option shouldn't be an identity option, that means, there should be only 1 connection in the OE entry.

Same issue as https://github.com/microsoft/azuredatastudio/issues/20972 - see comments there for explanation of where the problem is exactly


can not find bluetooth devices

the example run in Ipad, but only list some devices like randomly, can not find the nearby bluetooth devices.  screen shots attached.
Any one could help find the problems?
Thanks

I have the same problem
the following listener  - flutterBlue.scanResults.listen((results)

Is it because this is Low enarge Bluetooth?

I have the same issue.


Fibonacci sequence

Implement Fibonacci sequence in any language. Recursive is appreciated.

I would love to work on this, can u assign it to me?

since it is a part of hacktoberfest. should I put a PR in October?

Hey! Iet me know if I can do this one. Thank you.

why don't you PR this

I would love to work on this, can u assign it to me?

Then do it.

Hey! Iet me know if I can do this one. Thank you.

You can work on it by implementing it in many language.

@ephremdeme just a quick question, will PRs from both of us will be counted for hacktoberfest ?

@ephremdeme just a quick question, will PRs from both of us be counted for hacktoberfest ?

Yeah, why not.

Hey :)
I would like to do in c#.
GoodRegards

I would like to do this in java.Plz assign me

Hey @ephremdeme
Could you please check implementation in JS https://github.com/ephremdeme/data-structure-and-algorithms/pull/117

@ephremdeme Just opened the PR for implementation in c++, pls do check

I would like to contribute to this. Fibonacci using recursion.

Hi, Can I contribute to this in Python?

I have a question. Should I have to do something to make the pull request for the hacktoberfest count?
My PR for this Repo shows "Ineligible Repository "
Good Regards

#151
I would like do it in  C and Python.

hello! I'd like to work on this!:)


Fix double entry in authors

spotted this in my last PR, so let's fix it before I forget :smile:

LGTM :wink:

oh! you're fast :smile:


hacktoberfest-2022

please merge my pull request and mark it as hacktoberfest-2022.

Star the repo this is mandatory and you can also follow me.


Cover more tests with leak tracking.

@polina-c It seems that you faced the issue described here: https://github.com/flutter/flutter/issues/134205.
Unfortunately, simple disposal of _routeInformation does not work on the web.
Most probably, it happens because of a scheduled _reportRouteInformation that tries to use _routeInformation, which is already disposed.
  void _scheduleRouteInformationReportingTask() {
    if (_routeInformationReportingTaskScheduled || widget.routeInformationProvider == null) {
      return;
    }
    assert(_currentIntentionToReport != null);
    _routeInformationReportingTaskScheduled = true;
    SchedulerBinding.instance.addPostFrameCallback(_reportRouteInformation);
  }

@polina-c It seems that you faced the issue described here: #134205.

Thanks. Will exclude the change for now.


Convert frontend assets into dedicated typescript-based npm workspace

This is a bit experimental! Is it even a good idea to convert frontend scripts to typescript… probably?
Changes:

frontend script assets have been converted to typescript to benefit from the same type-checking as the rest of the application (slightly-simplified type definitions have been added to describe govuk-frontend’s public interface)
/assets/ is an npm workspace and specifies the dependencies it requires separately from the main application (which, for instance, does not use jquery)
all npm scripts in the root package delegate to child workspaces where the same script exists.

for instance, npm run clean called from the root package will clean all child workspaces as well, npm run build in the root will also build assets (but not CLI package as it’s never built), npm run start will only run code within the root package.
no root scripts have been removed, but some directly delegate to assets workspace
npm run typecheck no longer emits javascript into [workspace]/dist/ folders (npm run build is used to do that)

assets workspace does not have any tests yet, because it does not actually have any scripts with logic in them (yet?)

Next step: use a frontend compiler like webpack or esbuild to package up scripts into bundles rather than serve sources

No changes since last review; just rebasing…


chore(doc-gen): Removing versionInfo which is now in dgeni-packages

Once angular/dgeni-packages#117 is merged, gitData will already be included in the ngdoc services, and can be removed as a dependency.

This has landed at https://github.com/angular/angular.js/commit/0c1fbdd2424379c3f0557bb4bb0c7089f2414681


Makespan in scheduling problem

What language and solver does this apply to?
, C++
Hi! I'm having some troubles calculating the makespan in a scheduling problem. The problem is Rm|Sijk|Cmax, that is to say I have to schedule n jobs on m independant unrelated machines, where the set up times are not symmetric and depend on the machine (for all jobs i,j and all machine k, Sijk =! Sjik). Moreover, each job can only be processed on a subset of the m machines. There is no preemption. The objective is to minimize the makespan

Please use the mailing list.

duplicate of #1963 ...


Accessing validator-engine-console with ADNL client

I am trying to use ConnectionPool for accessing validator-engine-console with more or less the following code:
tl.Register(ValidatorStats{}, "engine.validator.getStats = engine.validator.Stats")
...
client := liteclient.NewConnectionPool()

// Read key files etc...

err = client.AddConnection(
	context.Background(),
	"NODE_IP:PORT",
	serverKeyPubB64,
	clinetKeyFull,
)
if err != nil {
	panic(err)
}
fmt.Println("Connected to server")

var resp tl.Serializable
err = client.QueryADNL(context.Background(), ValidatorStats{}, &resp)
if err != nil {
	panic(err)
}
...

What I am getting in response is engine.validator.ControlQueryError with Code:602 Message:forbidden.
Running validator-engine-console against the same host with the same keys works fine.
So my question is if it is possible to use the library to access validator-engine-console, or is it strictly specific to lite server? If so if you could point me to some resources to understand the specificity I would be very grateful (I am not proficient enough in c++ to figure it out quickly from Ton codebase).

Hi, it is possible to use with any ADNL client/server. Regarding the forbidden error, see this node's method  it also checks source ADNL key and some port, try to compare port and client key with what you have for validator-engine-console, maybe it is different?

Also maybe you need to use your client key in NewConnectionPoolWithAuth as auth, instead of using NewConnectionPool


Mutations breaks on partially invalid IDs for 3.1

I want to merge this change because it is port of changes from #8780 and also #9908
(#9908 is just an added testcase, i decided to add it together because it is connected to those changes and I wanted to make sure that this testcase is also handled here).
In this port changes in files:
saleor/graphql/core/utils/__init__.py
saleor/plugins/webhook/shipping.py
Are different than in original PR from 3.0 (due to changes , so those are files that needt to be reviewed

Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations
[ ] Documentation needs to be updated

Pull Request Checklist

[ ] Privileged queries and mutations are guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migration files are up to date
[ ] The changes are tested
[ ] GraphQL schema and type definitions are up to date
[ ] Changes are mentioned in the changelog

Task linked: SALEOR-4506 Mutations breaks on partially invalid ID


Import does what you need

I just had the same issue as the original post and decided the instructions were a little more than I was willing to try.
I just did an import in place instead and it just worked perfectly.  It may be that Hyper-V has been upgraded since this article was written.  I was using Hyper-V manager 10.0.19041.1.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: acc00093-1f29-7e3b-ab30-9e6966598390
Version Independent ID: bd281aaf-4e09-73a4-95a0-873ab4cc5de2
Content: Export and import virtual machines
Content Source: WindowsServerDocs/virtualization/hyper-v/deploy/Export-and-import-virtual-machines.md
Product: windows-server
Technology: hyper-v
GitHub Login: @KBDAzure
Microsoft Alias: kathydav

When you say "had the same issue as the original post", are you referring to issue ticket #3848 (What happens when it won't find the files?) ?

Sorry - my first time posting here.  Attempted to reply to a post about adding a virtual machine to a different computer after the first one died (not the link you found).  Someone had found a really complicated way to do it but I found the import function worked fine.  My new computer is faster with a better cpu butt he VM is still on an external SSD.

Fair enough. Interesting scenario. Would you say, based on your findings, that the document can be improved upon, or is this mostly a technical discussion?

#assign:xelu86

Thanks again for contacting Microsoft. We value your feedback. As your comment doesn't seem to be tied to any specific issue(s) within this documentation, we will be closing this thread. Please feel free to reopen this if changes do need to be made in order to better support your needs. #please-close


Bar width not calculated effectively for "value" type axis

Version
4.3.0
Reproduction link
https://jsfiddle.net/1wvhf4x2/2/
Steps to reproduce
Use "value" as x axis type and have big gaps in x axis values in the data. Example setup to reproduce:
option = {
    "xAxis": {
        "show": true,
        "type": "value",
        "scale": true,
    },
    "yAxis": {
        "show": true,
    },
    "series": [{
        "type": "bar",
        "data": [
            ["2019", "600"],
            ["2020", "600"],
            ["2032", "600"],
        ]
    }]
};

What is expected?
Bars should not be too wide and they must not overlap.
What is actually happening?
Bars are too wide and they overlap.

This issue does not occur for "time" and "cateogry" axis types. In the above example, just change "value" to "category" and in the result, bar width is nicely adjusted. See https://jsfiddle.net/1wvhf4x2/3/

This may be the same or similar issue to #11145, which is scheduled to be fixed in v4.5.0.
I will leave this issue open and check when #11145 is fixed.

Yes, it looks like they are the same. I'll follow both issues. Thanks very much.
PS: I was wrong in the OP when I said this doesn't happen with "time" axis. In fact this happens for both "time" and "value" axises. OP edited to reflect this.

I can confirm this is fixed as of v4.6.0. Thanks very much.
I only have one question. Currently there may happen some overlapping with the first bar and the y axis. Do you think this should be fixed with better defaults or it's expected and I should use some other config (e.g. xAxis.boundaryGap) to fix it? JSFiddle: https://jsfiddle.net/bwez36hs/


sta: report_checks clock reconvergence pessimism bug

Running the same report_checks gives different results after calling another report_checks between them:
report_checks .... -through mprj/wrapped_quad_pwm_fet_drivers_5   >>> -0.69    clock reconvergence pessimism
report_checks .... -through mprj/wrapped_quad_pwm_fet_drivers_5/_3655_   >>> -0.69    clock reconvergence pessimism
report_checks .... -through mprj/wrapped_quad_pwm_fet_drivers_5   >>> 0.00    clock reconvergence pessimism
Test case:
https://videogamo.com/tmp/asic/sta_crpr_issue.zip
running sta sta_script.tcl you can see the different cprp results

The variable $::env(PDK_ROOT) is not set in the script and the pdk data is not in the test case.

@mbalestrini it is best to use https://github.com/The-OpenROAD-Project/OpenLane/blob/master/docs/source/using_or_issue.md to package the test case.

Didn't know about or_issue.py
I'll use it and upload the result test case

I think this or_issue.py script is oriented to an openlane flow error. This error came up running a custom sta script with the results from different flows (caravel, user_project_wrapper), and doesn't use .def files
I made a new zip the includes the pdk files needed: https://videogamo.com/tmp/asic/sta_crpr_issue_with_pdk.zip

This is really an opensta issue and has nothing to do with openroad.
Fixed by
e6d5e2d7d Merge pull request #1527 from jjcherry56/sta_report_thru


add retry mechanism to downloads

Why
Sometimes downloads can fail due to temporary issues. When this happens in the middle of a build that requires this plugin, the whole build will fail, and restarting it can be time costly.
What
Adding a retry mechanism with a max count of 3.
Note
This could and should probably be configurable. As a first step, let's make this a conventional default before allowing to change the retry policy.

Hi @thebignet,
Thank you for the feature proposal and this PR!

Are the temporary issues you are facing connectivity issues and/or HTTP error responses?
In the latter case, can you provide status code of HTTP responses?

Actually, I will add some improvements on some points about the feature and the code itself:

As you noticed, the number of retry attempts will be configurable and defaults to 1 for backward compatibility.
Retries will be applicable to connectivity issues and a subset of 5xx HTTP status codes only. This would prevent retrying when there's nothing else to expect (e.g. some 4xx status codes). Retriable HTTP status codes will be configurable.
I may provide some custom algorithm (exponential backoff, etc.) for the retry behaviour since I'm not sure retrying immediately is enough in most situations.
I will also fix some minor issues with code conventions (as explained in the contributing notes).

To proceed, I will register a feature request in an issue and merge your PR in a development branch so as I can implement these improvements.
Thanks again for your work!
BR


tfsec: 0.55.0 -> 0.55.1

Motivation for this change
Update to latest upstream release 0.55.1
Change log: https://github.com/aquasecurity/tfsec/releases/tag/v0.55.1
Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

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

1 package built:

tfsec


Latest release planning simulator autonomous control not available

Checklist

[x] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] I'm convinced that this is not my fault but a bug.

Description
Update: seems like that was an temporary issue. Pulling the latest repo a few hours later and rebuild resolves the issue. But I am still interested in if anyone knows the cause or was aware of the problem.
I installed the latest autoware following the official guide. However, I was unable to run the planning simulation following the steps from here. The AUTO button just greyed out but planning seemed fine. It I try to force it to using service request I get status False. There was no error message except a warning of no traffic light, as shown in the terminal. Publishing the traffic light info solves the warning. I have used the simulation quite extensively in the past and had no problems. However, something is not working with the latest update. Please help thanks!

Expected behavior
Planning simulation to work
Actual behavior
Planning simulation not working
Steps to reproduce

Install Autoware
Launch planning simulation
Set an initial pose and goal pose
AUTO button greyed out

Versions
No response
Possible causes
No response
Additional context
No response

For me even the path is not created after the latest update.


support for .scala files

Hi,
first of all thanks for this plugin , is it possible support for .scala files ? . I am using relay with scala.js
val query = gql"""
  query Test {
   viewer {
    ...
    }
  }
"""

try to use this
//language=GraphQL

example: https://github.com/entria/graphql-dataloader-boilerplate/issues/28#issuecomment-296406367


Access tables not created through gorm with gorm model

Your Question
I want to have more granular control of my migrations, so I'm writing separate sql files and I run those through gorm. The question I have is whether I can access these tables created this way (adding, updating, deleting rows) using gorm. I've created a matching model class that I verified matches the sql (I ran the auto migrate to see what it would produce with the model for testing this out). When I go to test the table out I get the following error: panic: reflect: reflect.Value.Set using unaddressable value when attempting to a new row to the table. Now I'm not sure if this is a bug and if it is I'll put in a full issue report with reproducible steps. Before that, I wanted to verify this was something that was possible with the library.

The document you expected this should be explained
https://gorm.io/docs/sql_builder.html#Raw-SQL

Expected answer
Whether this is possible or not and if so what extra precautions need to be accounted for.

 Nothing was wrong. I was not checking against the error field.


content not available for commentary VachanGo 1.3.8-alpha_1

In commentary only references are available contents are missing .

@JesniJ please change the version to 1.3.8_alpha dot 1 as this is the format we are following

Version number is corrected.

Testing completed and verified that contents are available . Thus moving this issue to done.


Fix download link for Dex <IP_ADDRESS>

http://dexvis.com/doku.php?id=Download
download link for Dex <IP_ADDRESS> is
http://dexvis.com/downloads/Dex-<IP_ADDRESS>.zip
wonderful tool, thank you~:)

Fixed, thanks for the feedback, and you're quite welcome :-)


Chart scales are not adjusted with annotations

The automatic scale does not account for the annotations. If I set an annotation with value greater than the data scale the annotation is drawn outside the chart area.

At the moment, this is as designed. The chart fits to data, and annotations are not data. You can use the max option to set the scale to something above your annotation

Thank you for the quick reply.
The problem is that, as is, annotations overlap with the legend and scales. Shouldn't they be restrict to the chart area?
Regards

They probably should be, or at least not drawn if outside the chart area


SHA1.hash is not a function with validation-cache plugin

Describe the bug
Hi. I had recently upgraded all dependencies in my server to latest including yoga, envelop plugins, etc. and came up with this error in validation-cache plugin which used to work fine before which is visible just when you open GraphiQL.

Using the defaults useValidationCache() without passing any config.
Currently, I have disabled validationCache plugin because of this issue.
To Reproduce
Steps to reproduce the behavior: Use latest deps of envelop, validation-cache, graphql, yoga, etc. and you get this error.
Expected behavior
validationCache doesn't throw error like seen above
Environment:

NodeJS: 19.6.1

"@envelop/core": "^3.0.6",
"@envelop/depth-limit": "^2.0.6",
"@envelop/graphql-modules": "^4.0.6",
"@envelop/parser-cache": "^5.0.6",
"@envelop/prometheus": "^7.0.6",
"@envelop/response-cache": "^4.0.7",
"@envelop/validation-cache": "^5.1.2",
"@graphql-yoga/render-graphiql": "^3.7.0",
"graphql": "^16.6.0",
"graphql-modules": "^2.1.0",
"graphql-yoga": "^3.7.0",

This seems to be a bug
However I don't think you need validation cache plugin since it is builtin in Yoga. Now it uses cached documents from the parser cache with a Yoga specific parser/validation cache plugin.

Introduced in<EMAIL_ADDRESS>by https://github.com/n1ru4l/envelop/pull/1727 -
import SHA1 from 'sha1-es' does not work in ESM environments. This does work -
import SHA1module from 'sha1-es';
const SHA1=SHA1module.default;

@eugene1g Can you send a PR for inlining the dependency?

@n1ru4l Not a fan of inlining code nobody will ever understand. Can I recommend an alternative library for generating the hash: https://github.com/planttheidea/hash-it It's well-maintained, works in all environments targeted by Envelope, and run 5-10 times faster than sha1-es?

@eugene1g fine with me


Icons in the panel without a background

Hello. Can you please tell me why the icons have a background - should it be so?
I would like them to be transparent, as in the screenshots in README

As now

As it should be

when selecting text in the code editor - the selected text is not visible because of the color of the selection
the same when selecting other text - it is badly visible.
I propose to weaken the transparency of the selection, as well as to change the color

Screenshot

@Pushkin31 I will fix it soon. and thanks for being a tester for me, if it is really fixed i will let you know as soon as possible.

[ ] text_edit_selection_background: https://github.com/dracula/mixplorer/issues/4#issuecomment-968925140
[ ] notification_server: https://github.com/dracula/mixplorer/issues/4#issuecomment-952234665

health. Have you thought about fixing the bugs?)

Hy @Pushkin31 , I have fixed it just a few obstacles on my PC so I will immediately push later.

@kybo15 I decided to figure it out myself and realized that I just need to delete the file "notification_server.png", so that mix uses its own icon :)


Fix spammer not working after IOTA updates

No reason to spam currently, transactions are a lot faster than before.

Fixed in cb53bb7562cd774904467b529ae6b368b23fa03e


don't assume home is in /home/$USER

Adjustment of original fix by @abdullahibnnadjo

Thank you very much  :)


Enhancing Hardware Command Responses with Detailed Asynchronous Status Updates

What's needed?
We need a more informative way to get responses from hardware components after issuing commands to them.
Currently, the response is merely an acknowledgement and does not reflect the actual state or events at the component. Ideally, responses should include the statuses of all activities our stack performs on the component.
For example, the backend might increase power to 100kW in a 3-step ramp of 10kW, 50kW, and 100kW. Currently, the response would only acknowledge the 100kW command. If the 50kW command fails when sent to the inverter (e.g., due to sudden bounds change or communication errors), the client remains unaware and has to rely solely on the power value in the component data stream. This is suboptimal.
This may involve exposing more low-level information to the clients, so we need to make this optional. Clients who do not want this information should not be required to receive it.
Proposed solution
There are two ways of addressing this:
Proposal 1
Update the set-power command RPCs to return a stream of responses.
Proposal 2
Have a separate RPC that streams command response statuses. In this case, each command should be provided a unique ID from the service, and the streamed response status should contain this ID. (although one client should not get response for commands from another client).
Both proposals are technically feasible from the service's perspective. However, we need feedback from current users to determine their preferences and reasons.
Use cases
With the proposed changes, the client would receive a stream of real-time status updates for each command.
For example, after issuing the command to increase power, the client would receive updates indicating the progress and success or failure of each step in the process. If the command to write to the Modbus register succeeds but the component fails to respond within the expected timeframe, the client would be immediately informed of the issue, allowing for timely corrective actions such as retrying the command, diagnosing the communication problem, or adjusting their operational strategy based on the current status of the component.
Alternatives and workarounds
No response
Additional context
No response

FYI @shsms

So seem to be leaning more towards option 2. Some advantages over option 1:

It should be less resources intensive
Not that we need to right now, but it is more backwards compatible if we keep the old rpc intact and users that need more/better replies can subscribe to the new stream.
If it is more convenient for the client to provide a reply stream per every request, we can still do it at the client level and create a python channel for every request instead of a rpc stream for every request.

leaning more towards option 2.

That sounds good to me.

If it is more convenient for the client to provide a reply stream per every request, we can still do it at the client level and create a python channel for every request instead of a rpc stream for every request.

This is not required for the SDK use cases.  A single stream is easier.

Thanks @shsms
We will go for option 2 then.

In the past weeks, I was working on similar problem in our proprietary stack, and I discovered that having a global response stream with request IDs leads to a few issues.
The first issue is about complications on the server side - it needs to maintain a map of output streams to client, and response objects from for one client should not go into the output stream for another. This is additional overhead that could be avoided if each request just returns its own response stream.
The second issue is with request ID tracking on the client side - managing request IDs for multiple requests is not trivial. If the client has to care about the responses, then it needs code to track request IDs through timeouts and mix-ups, which is evidently complicated. With a response stream per request, clients have the option to use them straightaway, or to stream them to a global response stream if they need to.
So, I am inclining towards option 1.

I can't think of why the SDK would need to track the request ID.  I think we just need the component ID for which a request failed, and the SDK can take action with just that.  So from the SDK side, I think option 2 is easier to use.
With option 1 we'd probably need more code, but I don't think there would be any performance cost.  So AFAICS, going with option 1 shouldn't be too bad either.

I think we just need the component ID for which a request failed, and the SDK can take action with just that.

The SDK would need more, I imagine. Say discharge commands were sent for 5 inverters. It would need to track the request IDs for each of these 5 discharge commands, otherwise it cannot know for which inverter the command failed.

Say discharge commands were sent for 5 inverters. It would need to track the request IDs for each of these 5 discharge commands, otherwise it cannot know for which inverter the command failed.

Not if the status update contains the component ID of the inverter for which something failed.  That should always be there, right?

But never mind, option 1 does sound cleaner, modular, etc.  So we can do that.

Not if the status update contains the component ID of the inverter for which something failed. That should always be there, right?

It will, but the caller won't know for which command until the request ID is used. E.g., it could be that the response the caller just got was a response to an older command, which it had stopped caring about after a timeout. So the request ID cannot be ignored in general. We have seen similar usage patterns elsewhere as well. This is also where things start getting more rabbit-hole-ish and complicated with option2.

But never mind, option 1 does sound cleaner, modular, etc. So we can do that.

Will submit a PR soon!

If an inverter had an issue, it shouldn't matter which request it was for, it should be the same action - block the inverter temporarily.  This would be the implementation if we use option 1 as well because otherwise, option 1 would also lead to the same problem on the client side, of tracking whether to take action for the responses for a certain request ID.

Well not if you receive first a successful telephone from a latest command and then a failure for an old final, I guess in that case we can consider the component is ok, but it would be a very weird edge case I guess


[StepButton] Text should be aligned left in vertical mode

When you use the StepButton in a vertically oriented Stepper, the text is set to text-align: center, as those are the default styles for buttons.
When you set orientation: "vertical", the text in the button should instead be aligned left: https://stackblitz.com/edit/bbqaek

Hi there @oliviertassinari! If no one is working on this issue yet, could I take a stab at a PR? Thank you.

go ahead!

Alright after poking around a bit, it looks like the proposed solution offers slightly different behavior than the original request.
diff --git a/packages/material-ui/src/StepLabel/StepLabel.js b/packages/material-ui/src/StepLabel/StepLabel.js
index af2b4a9ff..0effb49a9 100644
--- a/packages/material-ui/src/StepLabel/StepLabel.js
+++ b/packages/material-ui/src/StepLabel/StepLabel.js
@@ -20,10 +20,11 @@ export const styles = (theme) => ({
   /* Styles applied to the root element if `orientation="horizontal"`. */
   horizontal: {},
   /* Styles applied to the root element if `orientation="vertical"`. */
-  vertical: {},
+  vertical: {
+    textAlign: 'left',
+  },
   /* Styles applied to the `Typography` component which wraps `children`. */
   label: {
-    color: theme.palette.text.secondary,
     '&$active': {
       color: theme.palette.text.primary,
       fontWeight: 500,
@@ -61,6 +62,7 @@ export const styles = (theme) => ({
   alternativeLabel: {},
   /* Styles applied to the container element which wraps `Typography` and `optional`. */
   labelContainer: {
+    color: theme.palette.text.secondary,
     width: '100%',
   },
 });

@oliviertassinari is this an acceptable solution, or was the intention for textAlign: 'left' to always be applied to the root element regardless of orientation?

I think that it can work either way. We tend to groupe style when possible to make overrides simpler.

no problem, i'll keep it as it was then (applied to root). Would a change like this warrant a new unit test? The only reason I'm wondering is it is a relatively minor style change.

For the test, we could update an existing demo to include an optional label. The visual regression test infrastructure will take care of the rest.


Can't merge user_target_xcconfig for pod targets: ["react-native-bignumber", "react-native-quick-crypto"]

Hi! 👋
Firstly, thanks for your work on this project!
Today I used patch-package to patch<EMAIL_ADDRESS>for the project I'm working on.
Upon running 'pod install', we encountered the following warning message:
[!] Can't merge user_target_xcconfig for pod targets: ["react-native-bignumber", "react-native-quick-crypto"]. Singular build setting CLANG_CXX_LANGUAGE_STANDARD has different values.
To resolve this, I patched the package and set the CLANG_CXX_LANGUAGE_STANDARD to "c++17" for the 'react-native-bignumber' pod. This adjustment successfully addressed the conflict and allowed the 'pod install' command to complete without any further issues.
Here is the diff that solved my problem:
diff --git a/node_modules/react-native-bignumber/react-native-bignumber.podspec b/node_modules/react-native-bignumber/react-native-bignumber.podspec
index d9fbaea..d8e6d38 100644
--- a/node_modules/react-native-bignumber/react-native-bignumber.podspec
+++ b/node_modules/react-native-bignumber/react-native-bignumber.podspec
@@ -32,7 +32,7 @@ Pod::Spec.new do |s|
     "HEADER_SEARCH_PATHS" => "\"$(PODS_TARGET_SRCROOT)/ReactCommon\" \"$(PODS_TARGET_SRCROOT)\"  \"$(PODS_ROOT)/boost\" \"$(PODS_ROOT)/boost-for-react-native\" \"$(PODS_ROOT)/DoubleConversion\" \"$(PODS_ROOT)/Headers/Private/React-Core\" "
   }
   s.xcconfig               = {
-    "CLANG_CXX_LANGUAGE_STANDARD" => "c++14",
+    "CLANG_CXX_LANGUAGE_STANDARD" => "c++17",
     "HEADER_SEARCH_PATHS" => "\"$(PODS_ROOT)/boost\" \"$(PODS_ROOT)/boost-for-react-native\" \"$(PODS_ROOT)/glog\"  \"${PODS_ROOT}/Headers/Public/React-hermes\" \"${PODS_ROOT}/Headers/Public/hermes-engine\""
   }

This issue body was partially generated by patch-package.

Fixed by #64 as soon as it's released and @boorad also fixed this in quick crypto
I believe modifying xcconfig files is simply the culprit here. I think these modifications are unnecessary.
So while "CLANG_CXX_LANGUAGE_STANDARD" => "c++17" does fix the issue temporarily, ultimately removing the whole line will stop these conflicts from happening in the future.


WIP AI code prompt

Further inspiration: https://roc.zulipchat.com/#narrow/stream/304641-ideas/topic/Official.20LLM.20context/near/469538739


请问可否给出调用webapi的demo

Hi there. You can simply use OpenAI SDK to make use of the webapi. Here is an example using Deno and OpenAI SDK for Node.js.
import OpenAI from<EMAIL_ADDRESS>
const openai = new OpenAI({
  apiKey: "YOUR_AUTH_TOKEN",
  baseURL: "YOUR_DEPLOYMENT_URL/v1",
});

const reply = await openai.chat.completions.create({
  model: "gpt-4",
  messages: [
    { role: "user", content: "Hello, who are you?" },
  ],
  stream: true,
});

const img = await openai.images.generate({
  prompt: "A painting of cat with a hat",
});

Also, I've developed an alternative front-end which is meant to be used the webapi. You can find details on how it interacts with the webapi here.

THX, but I tried the api with python, but it's always respionsing with code 500 as I code as following:
cookie_path = pathlib.Path('cookies.json')
cookies = None
if cookie_path.exists():
cookies = json.loads(cookie_path.read_text(encoding='utf-8'))
headers = {
"Content-Type": "application/json",
}
body = {
"prompt": "",
"context": "Hello, this is Bing.",
"conversation": "CreateConversationResponse",
"cookies": str(cookies),
"noSearch": False,
"conversationStyle": "Creative",
"locale": "zh-CN",
"gpt4turbo": True
}
response = requests.post("http://localhost:8080/chat/stream", headers=headers, json=body, stream=True)

There are several issues with how you call the API. First, the cookies should be obtained using document.cookie on the official website. Second, the conversation field should not be a string, but an object, whose structure is CreateConversationResponse, which is returned by /conversation/new. But the better solution is just to omit the conversation field, because if it will be created automatically if omitted.

I've tried with postman:
{
"prompt": "",
"context": "Hello, this is Bing.",
"noSearch": false,
"conversationStyle": "Creative",
"locale": "zh-CN",
"gpt4turbo": true
}
And the response was as following:
error creating conversation: unexpected end of JSON input

Hi, the issue you encountered may be caused by missing cookies. Ensure that you have passed DEFAULT_COOKIES env to webapi or you may provide your own cookies in the payload. If you are in China, please make sure you have correctly configured the proxy. Also, the prompt must not be empty, and the context should follow internal template of Microsoft Copilot to perform prompt injection.
curl -X POST "$BASE_URL/chat/stream" -d '{"prompt":"Who are you?","context":"None","cookie":"YOUR_COOKIES_HERE"}'

THX, can I provide cookies as this:
cookie_path = pathlib.Path('cookies.json')
cookies = None
if cookie_path.exists():
cookies = json.loads(cookie_path.read_text(encoding='utf-8'))

THX, can I provide cookies as this:
cookie_path = pathlib.Path('cookies.json') cookies = None if cookie_path.exists(): cookies = json.loads(cookie_path.read_text(encoding='utf-8'))

No, you can't. You should go to official website, open the browser console, type document.cookie, and copy the result string.

So it's different from the program:
Put your cookies.json in the same folder as the executable file:
Install the Cookie-Editor extension for Chrome or Firefox
Go to bing.com
Open the extension
Grant permission for All sites
Click Export on the bottom right, then Export as JSON (This saves your cookies to clipboard)
Paste your cookies into a file cookies.json, created in the same directory as the executable file.
Note: make sure you can use the web chat before exporting the cookie.
Run the program.

Yes, it is different from other parts of the program.

THX, you helped a lot


Printer simulator!!!

Is there any way to simulate printer? I mean test sdk without real printer

I don’t really know but if there is one it would be awesome. I don’t have access to printers to test this library anymore so it is difficult to develop for it 😕

Is there any way to simulate printer? I mean test sdk without real printer

Hi, I work for the Star EMEA office. Sorry there is no publicly available simulator available from us. But most Star regional offices have schemes to provide loan product or special pricing for development purposes. Please get in touch with them.

Is there any way to simulate printer? I mean test sdk without real printer

Hi, I work for the Star EMEA office. Sorry there is no publicly available simulator available from us. But most Star regional offices have schemes to provide loan product or special pricing for development purposes. Please get in touch with them.

Going to throw this out there, Star make a React Native bridge?

Going to throw this out there, Star make a React Native bridge?

I couldn't possibly comment ;-)
It's on our radar for sure, but I think that this wrapper already does well. Just people seem to be struggling with our bit-image only printer models. I don't know React Native at all right now so I'm not sure if it lacks a canvas style API that could be used to build graphical jobs or if maybe that exists but doesn't map to this wrapper well. Anyway, for now I'll keep an eye on this project, take note of the common difficulties people have and support where I can.


Without the change, schema are not appended where available, for exam…

…ple DB.MY_SCHEMA.TABLE, instead you get DB.TABLE which falls over in a heap

Hey Tom, can you do as a pull request on Calcite? We should do changes there and then backport to Drill.

Have done I've just got to tidy it up.  I'll let you know when it's done
On 28 Oct 2015 17:57, "Jacques Nadeau"<EMAIL_ADDRESS>wrote:

Hey Tom, can you do as a pull request on Calcite? We should do changes
there and then backport to Drill.
—
Reply to this email directly or view it on GitHub
https://github.com/mapr/incubator-calcite/pull/3#issuecomment-151932556.


[BUG] outlineProperties does not exist on type ' WorksheetProperties'

🐛 Bug Report
The outLinePropierties  does not exist on the WorksheetProperties in combination with Angular and Typescript.
Lib version: 4.0.1
Steps To Reproduce
    const workbook = new ExcelJS.Workbook();
    const worksheet = workbook.addWorksheet('sheetName', { pageSetup: { paperSize: 9, orientation: 'landscape', fitToPage: true }});
      worksheet.properties.outlineProperties = null;

The expected behaviour:
To have outlineProperties  exist one WorksheetProperties  like tabColor, outlineLeveCol ect. do.
Thank you very much in advance.

My workaround for now, which I do not prefer.
worksheet.properties['outlineProperties'] = null;

Any updates on this? The suggested workaround doesn't work for me either. I am using 4.2.0


Add neuron coloring

Thanks for PR. Can you add unit test to the parsing of the color?

Thanks for PR. Can you add unit test to the parsing of the color?

Sure

I will take a look at adding unit tests


Differences in probe relaxation between the C++ and OpenCL code

I was noticing that the scans look slightly different between the C++ and OpenCL versions of the code. I thought before that this is just a difference from using some faster approximations for the force field calculation in the OpenCL version, but the difference is also there when the force fields are not any different.
I did some testing with the graphene example where I loaded the force field calculated by the regular run script into the OpenCL force field buffer and then doing just the relaxation on the GPU. I get images that look something like this:

They look very close, but not identical.
I noticed that the default time step parameters are different. In the C++ code it's hard-coded to 0.1 here: https://github.com/Probe-Particle/ppafm/blob/47cb4684bdbf6fab907109d3240764a62fe5ecaa/ppafm/cpp/ProbeParticle.cpp#L72
whereas in the OpenCL code it's set to 0.5 here: https://github.com/Probe-Particle/ppafm/blob/47cb4684bdbf6fab907109d3240764a62fe5ecaa/ppafm/ocl/AFMulator.py#L65
I tried changing the time step in the OpenCL to test if it would converge to the C++ result. This is the result for a line scan over the horizontal direction in the middle:

Far from converging, there is actually a significant jump when the time step is the same 0.1. There might also be some different prefactor, since the C++ values are consistently smaller.
@ProkopHapala Do you know if there is some other difference in the relaxation algorithms between the two versions the way you implemented them? I don't expect them to return the exact same answer, but it would be nice to know where the difference comes from.

The script that produces those plots is this:
#!/usr/bin/env python3

import time
import numpy as np
import pyopencl as cl
import matplotlib.pyplot as plt

import ppafm.ocl.oclUtils  as oclu
from ppafm.ocl.AFMulator import AFMulator
from ppafm import PPPlot, io

q = -0.05
afmulator = AFMulator(
    scan_dim=(201, 201, 80),
    scan_window=((0, 0, 6), (20, 20, 14)),
    rho={'s': q},
    tipR0=[0, 0, 4],
    tipStiffness=[0.5, 0.5, 0.0, 20.0],
    npbc=(1, 1, 1),
    df_steps=20
)

xyzs, Zs, qs, _ = io.loadXYZ('Gr6x6N3hole.xyz')

Fx, lvec_, _, _ = io.loadXSF('FFLJ_x.xsf', xyz_order=True)
Fy, lvec, _, _ = io.loadXSF('FFLJ_y.xsf', xyz_order=True)
Fz, lvec, _, _ = io.loadXSF('FFLJ_z.xsf', xyz_order=True)
FFLJ = np.zeros((4,) + Fx.shape, dtype=np.float32, order='F')
FFLJ[0] = Fx
FFLJ[1] = Fy
FFLJ[2] = Fz

Fx, lvec_, _, _ = io.loadXSF('FFel_x.xsf', xyz_order=True)
Fy, lvec, _, _ = io.loadXSF('FFel_y.xsf', xyz_order=True)
Fz, lvec, _, _ = io.loadXSF('FFel_z.xsf', xyz_order=True)
FFel = np.zeros((4,) + Fx.shape, dtype=np.float32, order='F')
FFel[0] = Fx
FFel[1] = Fy
FFel[2] = Fz

FF = FFLJ + q * FFel

afmulator.setLvec(lvec, pixPerAngstrome=10)
afmulator.forcefield.cl_FE = cl.Buffer(afmulator.forcefield.ctx, cl.mem_flags.READ_ONLY | cl.mem_flags.COPY_HOST_PTR, hostbuf=FF)
afmulator.prepareScanner()

df_cpp, _, _, _ = io.loadXSF('Q-0.05K0.50/Amp2.00/df.xsf')

y, z = 100, 50
for dt in np.linspace(0.1, 0.5, 5, endpoint=True):
    afmulator.scanner.relax_params = np.array([dt, 0.1, 0.1*0.2,0.1*5.0], dtype=np.float32)
    t0 = time.perf_counter()
    X = afmulator.evalAFM()
    print(f'Time taken (dt = {dt:.2f}): {time.perf_counter() - t0}')
    plt.plot(X[:, y, z], label=f'dt={dt:.2f}')
    # afmulator.plot_images(X, outdir=f'afm_ocl_dt{dt:.2f}')

plt.plot(df_cpp[-z-1, y, :], 'r', label='C++')

plt.ylabel('df')
plt.xlabel('x (Å)')
plt.legend(loc='upper left')
plt.savefig('df.png')
plt.close()

fig, (ax1, ax2) = plt.subplots(1, 2, figsize=(12, 5))
ax1.imshow(X[:, :, z].T, cmap='gray')
ax2.imshow(df_cpp[-z-1], cmap='gray')
ax1.set_title('OpenCL')
ax2.set_title('C++')
plt.savefig('df_comp.png')
plt.close()

# FF = afmulator.forcefield.downloadFF()
# io.saveXSF('FF_test_z.xsf', FF[..., 2].T, lvec)

@NikoOinonen it is great that you do this systematic testing. In principle I think the FIRE relaxation algorithms should be the same, I don't remember I would intentionaly modify it for GPU, but the not sure I would have to look at it in detail.
I see you are comparing df which depend on the choice of Convolution mask in Giessible formula, there are some prefactors which may have changed over time. Maybe it would be good to compare the force Fz rather than df so that you can eliminate one unknown. (Sure if the difference is really due to convolution mask, we shooud make it consistent).

What about the other parameters? Especially 1) convergence criterium , 2) maximum number of relaation steps
On CPU I see this ( not sure if we modify these settings when we run the simulation )
def setRelax( maxIters  = 1000, convF2 = 1.0e-4, dt = 0.1, damping = 0.1 ):
    lib.setRelax( maxIters, convF*convF, dt, damping )

... btw is seems there is an error should be convF=1e-4 not convF2 = 1.0e-4
On GPU I see this
#define N_RELAX_STEP_MAX  128
#define F2CONV  1e-8f

The algorithm put side-by-side seems exactly the same
CPU/C++ side
    inline void move( const Vec3d& f, Vec3d& r, Vec3d& v ){
        double ff = f.norm2();
        double vv = v.norm2();
        double vf = f.dot(v);
        if( vf < 0 ){ // if velocity along direction of force
            v.set( 0.0 );
            dt    = dt * fdec;
              acoef = acoef0;
        }else{       // if velocity against direction of force
            double cf  =     acoef * sqrt(vv/ff);
            double cv  = 1 - acoef;
            v.mul    ( cv );
            v.add_mul( f, cf );	// v = cV * v  + cF * F
            dt     = fmin( dt * finc, dtmax );
            acoef  = acoef * falpha;
        }
        // normal leap-frog times step
        v.add_mul( f , dt );
        r.add_mul( v , dt );
    }

GPU/OpenCL side:
    float ff = dot(f,f);
    float vv = dot(v,v);
    float vf = dot(v,f);
    if( vf < 0 ){ // if velocity along direction of force
        v      *= 0;
        (*dt)   = fmax( dtmin, (*dt) * FTDEC );
        (*damp) = damp0;
    }else{       // if velocity against direction of force
        // v = cV * v  + cF * F
        v       *= (1 - (*damp));
        v       +=  f * ( (*damp) * sqrt( vv / (ff + F2SAFE ) ) );
        (*dt)    = fmin( dtmax, (*dt) * FTINC );
        (*damp) *= FDAMP;
    }
    return v;

The maximum steps was important. If I set it to 1000 also on the OpenCL side, then there is no difference in the time step:

But there is still a difference to the C++ result. I will try looking at the Fz force next.
Also interestingly, the execution time increases significantly even for the long time step when I increase the maximum number of steps, which would indicate that it does not actually ever converge within the criterion. The solution is the same by eye though, so the converge criterion might unnecessarily tight.

The Fz curve shows a similar difference:

But now when I'm looking at it, it looks like the C++ curve maybe has the peaks and valleys a little bit offset to the left. I'm now doubting whether the two grids are actually aligned.

I think I figured it out. The problem was with the coordinate transform in the force field interpolation in the OpenCL code. I actually ran into this thing before while figuring out how to interpolate the Hartree potentials etc. into a new grid. Thing is that this built-in function in OpenCL read_imagef seems to use a convention where the voxel coordinates are offset by half a grid step in each dimension, so the force was being calculated in the wrong spot. I modified the interpolation function like this:
float4 interpFE( float3 pos, float3 dinvA, float3 dinvB, float3 dinvC, __read_only image3d_t imgIn ){
    float4 offset = (float4)(
        0.5f / (float) get_image_width(imgIn),
        0.5f / (float) get_image_height(imgIn),
        0.5f / (float) get_image_depth(imgIn),
        0.0f
    );
    const float4 coord = (float4)( dot(pos,dinvA),dot(pos,dinvB),dot(pos,dinvC), 0.0f ) + offset;
    return read_imagef( imgIn, sampler_1, coord );
}

Now it seems to return the same answer as the C++ code:

And the scans look more-or-less identical as well:

There's a couple of outlier pixels over the sharp lines, but that's probably some random numerical noise.

seems to use a convention where the voxel coordinates are offset by half a grid step in each dimension
yes, I also figured this out at some point (then forgot), it is implemented in my other  project, but I fogort to update it here

    #if 0
        coord +=(float3){0.5f,0.5f,0.5f,0.0f}; // shift 0.5 voxel when using native texture interpolation
        const float4 fe_Paul = read_imagef( FE_Paul, sampler_gff, coord );

https://github.com/ProkopHapala/FireCore/blob/3df8cd1755bc59b91ec29b73217f65aadba379e1/cpp/common_resources/cl/relax.cl#L1179
But I wonder that you get so precise results using just GPU native hardware interpolation. I think when I was testing the error was quite large  ~1-4%, that is why I made also the software interpolator read_imagef_trilin()
https://stackoverflow.com/questions/52261669/numerical-precision-of-linear-3d-texture-interpolation-on-gpu-opencl

I don't think it even is that precise. If you take the difference of the curves between the GPU and CPU computed values, you see that the maximum difference is in that range of ~1%:

Might also depend on the specific device.
Actually I also implemented a trilinear interpolator before to use in the force field calculation because of the accuracy issue as well as I needed it to work with buffer datatype instead of the image datatype: https://github.com/Probe-Particle/ppafm/blob/47cb4684bdbf6fab907109d3240764a62fe5ecaa/ppafm/ocl/cl/FF.cl#L25-L28

This is an other topic, but I think it would be nice to try cubic interpolation. On one hand it would require 64 (4x4x4) reads from memory, but the advantage is that it would not need to save forces (smooth forces can be calculated analytically from the cubic spline), therefore the arrays would be smaller, and probably less dense sampling would be sufficient.
Maybe the cost of global memory read can be reduced if we read together all the values which are in the same cashe-line. Using buffer it would look something like this:
int yz = nx*(ix+ny*iz);
float4 vals = (float4){ grid[ix+yz], grid[ix+1+yz],grid[ix+2+yz],grid[ix+3+yz] };

but I'm not sure if it is really better to use buffer rather than image, because I have feeling texture reads are faster than buffer reads.
I was asking about this topic on stackoverflow, but did not get any uselful answer yet.
https://stackoverflow.com/questions/75966359/efficient-tricubic-interpolation-of-3d-image-on-gpu-using-opencl


Error ImageZoom: Cannot read property 'startsWith' of undefined

Got error while starting volto:
`TypeError: Cannot read property 'startsWith' of undefined
29 |     <ImageZoom
30 |       image={{

31 |         src: data.url.startsWith(settings.apiPath)
32 |           ? ${flattenToAppURL(data.url)}/@@images/image
33 |           : data.url,
34 |         alt: '',

at View (/Applications/Plone/installertest/volto/src/components/manage/Tiles/Image/View.jsx:31:1)
at processChild (/Applications/Plone/installertest/volto/node_modules/react-dom/cjs/react-dom-server.node.development.js:2888:14)
at resolve (/Applications/Plone/installertest/volto/node_modules/react-dom/cjs/react-dom-server.node.development.js:2812:5)
at ReactDOMServerRenderer.render (/Applications/Plone/installertest/volto/node_modules/react-dom/cjs/react-dom-server.node.development.js:3202:22)
at ReactDOMServerRenderer.read (/Applications/Plone/installertest/volto/node_modules/react-dom/cjs/react-dom-server.node.development.js:3161:29)
at renderToString (/Applications/Plone/installertest/volto/node_modules/react-dom/cjs/react-dom-server.node.development.js:3646:27)
at /Applications/Plone/installertest/volto/build/webpack:/src/server.jsx:106:1
at process._tickCallback (internal/process/next_tick.js:68:7)`

I think, this is a new function from the commit "image-zoom added" in march?

Oha.. sorry. Totally my fault


Strip fields of leading and trailing whitespaces

Copying and pasting a seller address into the field with leading and trailing whitespaces will cause a failure of the swap command. Simple fix scheduled for next major release.

Fixed in https://github.com/xmrswapme/swapfe/commit/66e2837f6e1f60287f8f60caaec896bfc10f439b


Multiple containers serving websockets in docker swarm not working

Do you want to request a feature or report a bug?
Bug
Did you try using a 1.7.x configuration for the version 2.0?

[ ] Yes
[x] No

What did you do?
Having one container using websockets under Traefik works as expected. But when I add another container that also uses websockets under the same traefik stack, then neither of websockets work. Once I remove either one from these containers, then websocket connectivity works.
These containers also serve http but there is no problem with http.
What did you expect to see?
When just one container using websocket e.g. web1 is active in Traefik

WS
HTTP

wss://mydomain.com/web1/socket.io/?transport=websocket
101 Switching protocols

When both containers - web1, web2 - are active in Traefik

WS
HTTP Response

wss://mydomain.com/web1/socket.io/?transport=websocket
101 Switching protocols

wss://mydomain.com/web2/socket.io/?transport=websocket
101 Switching protocols

What did you see instead?
When just one container using websocket e.g. web1 is active in Traefik

WS
HTTP Response

wss://mydomain.com/web1/socket.io/?transport=websocket
101 Switching protocols

When both containers - web1, web2 - are active in Traefik

WS
HTTP Response

wss://mydomain.com/web1/socket.io/?transport=websocket
500 Internal Server Error

wss://mydomain.com/web2/socket.io/?transport=websocket
500 Internal Server Error

Output of traefik version: (What version of Traefik are you using?)
traefik:1.7.9-alpine

What is your environment & configuration (arguments, toml, provider, platform, ...)?
debug = true
logLevel = "DEBUG"

defaultEntryPoints = ["http", "https", "ws", "wss"]

[entryPoints]
  [entryPoints.http]
  address = "<IP_ADDRESS>:80"
    [entryPoints.http.redirect]
      entryPoint = "https"
    [entryPoints.https]
    address = "<IP_ADDRESS>:443"
    compress = true
      [entryPoints.https.tls]

[acme]
email =<EMAIL_ADDRESS>storage = "acme.json"
entryPoint = "https"
onHostRule = true
[acme.httpChallenge]
entryPoint = "http"

[[acme.domains]]
main = "mydomain.com"

[api]
entryPoint = "traefik"
dashboard = true

[ping]
entryPoint = "traefik"

[docker]
endpoint = "unix:///var/run/docker.sock"
domain = "docker.localhost"
exposedByDefault = false
watch = true

Docker version 18.06.1, build e68fc7a

  web1:
    depends_on:
      - redis
    image: node:11.12.0-alpine
    command: ["npm", "start"]
    working_dir: /home/node/app
    labels:
      - "traefik.backend.loadbalancer.swarm=true"
      - "traefik.backend.loadbalancer.method=drr"
      - "traefik.socket.frontend.rule=Query: transport=websocket; PathPrefix: /web1; Host: mydomain.com, www.mydomain.com;"
      - "traefik.spa.frontend.rule=PathPrefixStrip: /web1; Host: mydomain.com, www.mydomain.com;"
      - "traefik.port=80"
      - "traefik.frontend.headers.SSLRedirect=true"
      - "traefik.frontend.headers.SSLProxyHeaders=X-Forwarded-Proto:https"
      - "traefik.enable=true"
      - "traefik.frontend.priority=1000"
    volumes:
      - /root/data/node/web1:/home/node/app
...

  web2:
    depends_on:
      - redis
    image: node:11.12.0-alpine
    command: ["npm", "start"]
    working_dir: /home/node/app
    labels:
      - "traefik.backend.loadbalancer.swarm=true"
      - "traefik.backend.loadbalancer.method=drr"
      - "traefik.socket.frontend.rule=Query: transport=websocket; PathPrefix: /web2; Host: mydomain.com, www.mydomain.com;"
      - "traefik.spa.frontend.rule=PathPrefixStrip: /web2; Host: mydomain.com, www.mydomain.com;"
      - "traefik.port=80"
      - "traefik.frontend.headers.SSLRedirect=true"
      - "traefik.frontend.headers.SSLProxyHeaders=X-Forwarded-Proto:https"
      - "traefik.enable=true"
      - "traefik.frontend.priority=1000"
    volumes:
      - /root/data/node/web2:/home/node/app
...

If applicable, please paste the log output in DEBUG level (--logLevel=DEBUG switch)
(paste your output here)

Hello and thank you for taking the time to fill this issue.
Maybe I'm wrong, but I think that you're misconfiguring Traefik here, declaring segments where you only need a classic frontend rule.
I think you're looking for
traefik.frontend.rule=Query: transport=websocket; PathPrefix: /web2; Host: mydomain.com, www.mydomain.com;"

Instead of
      - "traefik.socket.frontend.rule=Query: transport=websocket; PathPrefix: /web2; Host: mydomain.com, www.mydomain.com;"
      - "traefik.spa.frontend.rule=PathPrefixStrip: /web2; Host: mydomain.com, www.mydomain.com;"

If I'm wrong, please come discuss your problem on our slack support channel!

Thanks, but both of my web1, web2 backends each serve their own SPA and Websocket. Hence, the .spa segment, and .socket segment.
To reiterate, the setup works for spa, socket when only web1 or web2 is present, but when both web1, web2 are enabled then .socket rule doesn't work anymore for either of them . Maybe it's irrelevant, but I do have other containers serving php, java under the same traefik stack using PathPrefix on subfolders but have no clashes with them.
For spa, the subfolder path web1 is not needed, hence I PathPrefixStrip that one out. For socket, the subfolder PathPrefix path is needed - thus I use 2 label segments. The same applies for web2. Both are served out of the same traefik stack but they are separate independent containers that I need to route to.
I'll reach out on the slack support channel for further help.

Hello and thank you for taking the time to fill this issue.
Maybe I'm wrong, but I think that you're misconfiguring Traefik here, declaring segments where you only need a classic frontend rule.
I think you're looking for
traefik.frontend.rule=PathPrefix: /web2; Host: mydomain.com, www.mydomain.com"

Instead of
      - "traefik.socket.frontend.rule=Query: transport=websocket; PathPrefix: /web2; Host: mydomain.com, www.mydomain.com;"
      - "traefik.spa.frontend.rule=PathPrefixStrip: /web2; Host: mydomain.com, www.mydomain.com;"

If I'm wrong, please come discuss your problem on our slack support channel!

Thanks to prompt help on slack from @ldez, I solved it by making following changes

Changed traefik.toml to remove ws, wss from defaultEntryPoints  since they are not entrypoints explicitly defined under [entrypoints]. I mistook them as entrypoints to be protocols which is not the case.

-defaultEntryPoints = ["http", "https", "ws", "wss"]
+defaultEntryPoints = ["http", "https"]

Moved SSLRedirect, SSLProxyHeaders to spa segment label, and explicitly specified a higher priority for socket segment label over spa segment.

  web1:
   ...
    labels:
      ...
      - "traefik.spa.frontend.headers.SSLRedirect=true"
      - "traefik.spa.frontend.headers.SSLProxyHeaders=X-Forwarded-Proto:https"
      - "traefik.spa.frontend.priority=1000"
      - "traefik.socket.frontend.priority=1001"
      ...
    volumes:
      ...
...

Both web1, web2 now work correctly serving spa and websockets on traefik!
Thanks traefik team for a wonderful project, and I'll continue happy traefiking.

Thanks for the update! Glad you fixed the issue 👍


scipy.cluster.hierarchy.linkage() redundant distance matrix is mistreated

Accordind to the documentation scipy.cluster.hierarchy.linkage() can take a redundant distance matrix as an input:

y : ndarray
A condensed or redundant distance matrix. ...

In fact redundant matrix is treated as a collection of observation vectors.
Example code to reproduce the problem:
import scipy.cluster as cluster
from scipy.spatial.distance import squareform

condensed=[1.0,2.0,3.0,1.5,2.7,0.15]
full=squareform(condensed)

Z_c=cluster.hierarchy.complete(condensed)
Z_f=cluster.hierarchy.complete(full)

print("distance matrix condensed: {}".format(condensed))
print("distance matrix full:\n{}".format(full))
print("Z condensed:\n{}".format(Z_c))
print("Z full:\n{}".format(Z_f))

gives:

distance matrix condensed: [1.0, 2.0, 3.0, 1.5, 2.7, 0.15]
distance matrix full:
[[ 0.    1.    2.    3.  ]
[ 1.    0.    1.5   2.7 ]
[ 2.    1.5   0.    0.15]
[ 3.    2.7   0.15  0.  ]]
Z condensed:
[[ 2.    3.    0.15  2.  ]
[ 0.    1.    1.    2.  ]
[ 4.    5.    3.    4.  ]]
Z full:
[[ 0.          1.          1.52970585  2.        ]
[ 2.          3.          1.57638828  2.        ]
[ 4.          5.          4.93077073  4.        ]]

This reminds me of https://github.com/scipy/scipy/issues/2614. I'd thought a PR was merged to fix this, but I guess not.

closed by gh-6342


Please add C++/WinRT Examples

This code worked at one point:
    TextBlock tb;
    tb.Text(L"Hello, Windows 10!");
    tb.FontFamily(FontFamily(L"Times New Roman"));
    tb.FontSize(216);
    tb.FontStyle(FontStyle::Italic);
    tb.Foreground(SolidColorBrush(Color::Red()));
    tb.HorizontalAlignment(HorizontalAlignment::Center);
    tb.VerticalAlignment(VerticalAlignment::Center);

It no longer works, at least in a WinUI 3 UWP project.  Please give an example of C++/WinRT code that does work.  Thanks.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 27ad25f2-d06e-135c-240c-99c8a0cfa728
Version Independent ID: eccc6b3a-5607-158c-2ed6-949293923f2d
Content: TextBlock Class (Windows.UI.Xaml.Controls) - Windows UWP applications
Content Source: winrt-api-build/xml/Windows.UI.Xaml.Controls/TextBlock.xml
Product: uwp
Technology: winui
GitHub Login: @jwmsft
Microsoft Alias: jimwalk

Hi, @dr-eck,
Note that there is a Windows::UI::Colors class (Colors, plural), which has member functions such as Red(). But the Windows::UI::Color struct (Color, single) doesn't have member functions such as Red(). You can construct a red Windows::UI::Color from ARGB values. So changing the use of Color in your example to Colors, gives the following.
Assuming this StackPanel in your markup:

And assuming you've included everything you need to (here are some examples that we use):
#include <winrt/Windows.UI.Text.h>
#include <winrt/Windows.UI.Xaml.Controls.h>
#include <winrt/Windows.UI.Xaml.Media.h>
Then this builds and runs (you could include it in a click handler, to test it):
Windows::UI::Xaml::Controls::TextBlock tb;
tb.Text(L"Hello, Windows 10!");
tb.FontFamily(Windows::UI::Xaml::Media::FontFamily(L"Times New Roman"));
tb.FontSize(36);
tb.FontStyle(Windows::UI::Text::FontStyle::Italic);
tb.Foreground(Windows::UI::Xaml::Media::SolidColorBrush(Windows::UI::Colors::Red()));
tb.HorizontalAlignment(HorizontalAlignment::Center);
tb.VerticalAlignment(VerticalAlignment::Center);
myStackPanel().Children().Append(tb);
Thanks!
-Steve

Hi Steve,
Thanks for responding.  I figured out that the Windows namespace has the required functions.  With some help from Stack Overflow, I figured out that what caused my code to fail was that I had switched from the Windows namespace to the Microsoft namespace, and the "FontStyle", "Colors" and "HorizontalAlignment" had not yet been implemented in that.  Switching back to the Windows namespace fixed all that.
The only remaining issue was that I had started the project using WinUI 3 code, so the Grid defined in XAML was based on the Microsoft namespace, and when I tried to append a Windows::UI::Xaml::Controls::TextBlock to a Microsoft::UI::Xaml::Controls::Grid, the compiler found them to be incompatible.  Sigh.  I'm hoping the required pieces will be added to the Microsoft namespace in the November release.


Fix saving large pipelines

Before submitting (must do checklist)

[x] Did you read the contribution guide?
[x] Did you update the docs? We use Numpy format for all the methods and classes.
[x] Did you write any new necessary tests?
[x] Did you update the CHANGELOG?

Proposed Changes
Add option force_zip64 during writing to archive.
Closing issues
Closes #1318.

Codecov Report

Merging #1335 (3535dfc) into master (aac0fe1) will decrease coverage by 31.99%.
The diff coverage is 50.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@             Coverage Diff             @@
##           master    #1335       +/-   ##
===========================================
- Coverage   88.95%   56.96%   -31.99%
===========================================
  Files         204      204
  Lines       12641    12635        -6
===========================================
- Hits        11245     7198     -4047
- Misses       1396     5437     +4041

Files Changed
Coverage Δ

etna/models/mixins.py
69.15% <0.00%> (-27.11%)
:arrow_down:

etna/core/mixins.py
55.55% <100.00%> (-40.36%)
:arrow_down:

... and 129 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Updating the project to compliant with Unity 2017.2

All changes followed the code from MixedRealityToolkit-Unity. Will have new changes to integrate latest MixedRealityToolkit into this project.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: XinliZ sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@NeerajW Could you please review this change? Currently project is really behind and won't work with new Unity without these minor fixes for the version updates.

Addressed with https://github.com/Microsoft/MixedRealityCompanionKit/commit/12c4bba41d92242f4c9e709bfbeb66b08798ed4c


[FEAT]: parent flashcard tags include all child flashcard tags

In the settings dialog flashcard tags, I have to insert all my different kind of flashcard tags, which - each of them - represent one flashcard deck.
All of my decks are tagged with the parent tag #flashcards/ (for example my work flashcards are tagged #flashcards/work, my flashcards concerning health-issues are tagged #flashcards/health and so on)
=> it would be nice, if I just could insert here "#flashcards/" once and automatically all related child-tags are concidered as own decks and I don't had to insert all different kind of child-tags.

Hi
Can you please explain more.
In the settings I only have #flashcards specified.
In my notes I have all kinds of tags, e.g.  #flashcards/science/physics and  #flashcards/ml. They are all recognized by OSR.
Are you saying that doesn't work for you?
Regards
Ronny

Hi @SiliasGH
We haven't heard back from you, and I can't reproduce the issue.
I'll close this now, but feel free to reopen if this is still an issue.
Cheers
Ronny


SPRINT 3 Feature Implementation - Openexchangerate component

Breaking change

Proposed change

Type of change

[ ] Dependency upgrade
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New integration (thank you!)
[ ] New feature (which adds functionality to an existing integration)
[ ] Deprecation (breaking change to happen in the future)
[ ] Breaking change (fix/feature causing existing functionality to break)
[ ] Code quality improvements to existing code or addition of tests

Additional information

This PR fixes or closes issue: fixes #
This PR is related to issue:
Link to documentation pull request:

Checklist

[ ] The code change is tested and works locally.
[ ] Local tests pass. Your PR cannot be merged unless tests pass
[ ] There is no commented out code in this PR.
[ ] I have followed the development checklist
[ ] I have followed the perfect PR recommendations
[ ] The code has been formatted using Black (black --fast homeassistant tests)
[ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] The manifest file has all fields filled out correctly.
Updated and included derived files by running: python3 -m script.hassfest.
[ ] New or updated dependencies have been added to requirements_all.txt.
Updated by running python3 -m script.gen_requirements_all.
[ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
[ ] Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

[ ] I have reviewed two other open pull requests in this repository.

Description:
The Integration we have modified is Openexchangerates.
we have added a currency conversion calculator feature to the Openexchangerates integration.
This calculator will allow users to convert desired amount between different currencies
Ignore commit -  "Merge remote-tracking branch 'origin' into dev"

The following code must be replaced with the original configuration.yaml file to create entites:
#configuration.yaml
Loads default set of integrations. Do not remove.
default_config:
Load frontend themes from the themes folder
frontend:
themes: !include_dir_merge_named themes
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
logger:
default: info
logs:
homeassistant.components.cloud: debug
input_number:
amount:
name: Amount
initial: 1
min: 0.01
max: 10000
step: 0.01
mode: box
input_select:
from_currency:
name: from currency
options:
- AED
- AFN
- ALL
- AMD
- ANG
- AOA
- ARS
- AUD
- AWG
- AZN
- BAM
- BBD
- BDT
- BGN
- BHD
- BIF
- BMD
- BND
- BOB
- BRL
- BSD
- BTC
- BTN
- BWP
- BYN
- BYR
- BZD
- CAD
- CDF
- CHF
- CLF
- CLP
- CNY
- COP
- CRC
- CUC
- CUP
- CVE
- CZK
- DJF
- DKK
- DOP
- DZD
- EGP
- ERN
- ETB
- EUR
- FJD
- FKP
- GBP
- GEL
- GGP
- GHS
- GIP
- GMD
- GNF
- GTQ
- GYD
- HKD
- HNL
- HRK
- HTG
- HUF
- IDR
- ILS
- IMP
- INR
- IQD
- IRR
- ISK
- JEP
- JMD
- JOD
- JPY
- KES
- KGS
- KHR
- KMF
- KPW
- KRW
- KWD
- KYD
- KZT
- LAK
- LBP
- LKR
- LRD
- LSL
- LTL
- LVL
- LYD
- MAD
- MDL
- MGA
- MKD
- MMK
- MNT
- MOP
- MRO
- MUR
- MVR
- MWK
- MXN
- MYR
- MZN
- NAD
- NGN
- NIO
- NOK
- NPR
- NZD
- OMR
- PAB
- PEN
- PGK
- PHP
- PKR
- PLN
- PYG
- QAR
- RON
- RSD
- RUB
- RWF
- SAR
- SBD
- SCR
- SDG
- SEK
- SGD
- SHP
- SLL
- SOS
- SRD
- SSP
- STD
- SVC
- SYP
- SZL
- THB
- TJS
- TMT
- TND
- TOP
- TRY
- TTD
- TWD
- TZS
- UAH
- UGX
- USD
- UYU
- UZS
- VEF
- VND
- VUV
- WST
- XAF
- XAG
- XAU
- XCD
- XDR
- XOF
- XPF
- YER
- ZAR
- ZMK
- ZMW
- ZWL
to_currency:
name: to currency
options:
- AED
- AFN
- ALL
- AMD
- ANG
- AOA
- ARS
- AUD
- AWG
- AZN
- BAM
- BBD
- BDT
- BGN
- BHD
- BIF
- BMD
- BND
- BOB
- BRL
- BSD
- BTC
- BTN
- BWP
- BYN
- BYR
- BZD
- CAD
- CDF
- CHF
- CLF
- CLP
- CNY
- COP
- CRC
- CUC
- CUP
- CVE
- CZK
- DJF
- DKK
- DOP
- DZD
- EGP
- ERN
- ETB
- EUR
- FJD
- FKP
- GBP
- GEL
- GGP
- GHS
- GIP
- GMD
- GNF
- GTQ
- GYD
- HKD
- HNL
- HRK
- HTG
- HUF
- IDR
- ILS
- IMP
- INR
- IQD
- IRR
- ISK
- JEP
- JMD
- JOD
- JPY
- KES
- KGS
- KHR
- KMF
- KPW
- KRW
- KWD
- KYD
- KZT
- LAK
- LBP
- LKR
- LRD
- LSL
- LTL
- LVL
- LYD
- MAD
- MDL
- MGA
- MKD
- MMK
- MNT
- MOP
- MRO
- MUR
- MVR
- MWK
- MXN
- MYR
- MZN
- NAD
- NGN
- NIO
- NOK
- NPR
- NZD
- OMR
- PAB
- PEN
- PGK
- PHP
- PKR
- PLN
- PYG
- QAR
- RON
- RSD
- RUB
- RWF
- SAR
- SBD
- SCR
- SDG
- SEK
- SGD
- SHP
- SLL
- SOS
- SRD
- SSP
- STD
- SVC
- SYP
- SZL
- THB
- TJS
- TMT
- TND
- TOP
- TRY
- TTD
- TWD
- TZS
- UAH
- UGX
- USD
- UYU
- UZS
- VEF
- VND
- VUV
- WST
- XAF
- XAG
- XAU
- XCD
- XDR
- XOF
- XPF
- YER
- ZAR
- ZMK
- ZMW
- ZWL

Code looks good. Modified an existing integration, which is good. Nice that you "trick" the restrictive API (free access only USD as base currency) into converting any currency, using USD as an intermediate currency.
Screenshots ok
Tests ok


alt+7, alt+8, alt+9 does not work in Chrome & Safari (swedish keyboard layout)

Hi,
Thanks for an awesome library. I am having issues with support in Chrome and Safari on OSX for alt+7, alt+8 and alt+9,  even though all other alt and number combinations work. Tested on a Swedish keyboard layout (not sure if that matters).
http://codepen.io/hannesjohansson/pen/zqreRQ
Kind regards,
Hannes

I use Spanish-ISO keyboard layout and alt+7, alt+8 and alt+9 work, but alt+1 doesn't.


[Cognitive] - Remove azure_c_shared_utility_xlogging_wrapper

Replace/Update the logging layer using the Azure SDK core log support.

Functional gaps in Azure logging:

Azure Logging only has Log::Write(Level, std::string), it does not have:

printf style logging support,
LogBinary - logs binary data in same fashion as windbg.
LogLastError (and LogErrorWinHTTPWithGetLastErrorAsString - we have this somewhat in the HTTP exception handler)
Logging with call stack traces.

It's not clear which of these (if any) are required by Cognitive Services.

Closing for now because it's not clear this will be an issue moving forward.