Identifiers validation failed for dataset HBRA - Herbário do Instituto de Estudos Costeiros da Universidade Federal do Pará

Identifier validation failed for the dataset HBRA - Herbário do Instituto de Estudos Costeiros da Universidade Federal do Pará:

Crawler attempt: 454
Publishing organization: Instituto de Estudos Costeiros ( IECOS )
Publishing country: BRAZIL
Installation: speciesLink Network / INCT-HVFF IPT
Number of occurrences indexed for this dataset at the time of the issue: 15415
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 15839 total records; 15839 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/4171717/step

New IDs sample:

Old IDs sample:

BRA:IECOS:HBRA:16595
BRA:IECOS:HBRA:16596
BRA:IECOS:HBRA:16597
BRA:IECOS:HBRA:16598
BRA:IECOS:HBRA:16809
BRA:IECOS:HBRA:16599
BRA:IECOS:HBRA:16600
BRA:IECOS:HBRA:16601
BRA:IECOS:HBRA:16602
BRA:IECOS:HBRA:16603

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the HBRA - Herbário do Instituto de Estudos Costeiros da Universidade Federal do Pará : https://doi.org/10.15468/3w9k3k.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset HBRA - Herbário do Instituto de Estudos Costeiros da Universidade Federal do Pará:

Crawler attempt: 455
Publishing organization: Instituto de Estudos Costeiros ( IECOS )
Publishing country: BRAZIL
Installation: speciesLink Network / INCT-HVFF IPT
Number of occurrences indexed for this dataset at the time of the issue: 15415
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 15839 total records; 15839 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/4193666/step

New IDs sample:

Old IDs sample:

BRA:IECOS:HBRA:16595
BRA:IECOS:HBRA:16596
BRA:IECOS:HBRA:16597
BRA:IECOS:HBRA:16598
BRA:IECOS:HBRA:16809
BRA:IECOS:HBRA:16599
BRA:IECOS:HBRA:16600
BRA:IECOS:HBRA:16601
BRA:IECOS:HBRA:16602
BRA:IECOS:HBRA:16603

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the HBRA - Herbário do Instituto de Estudos Costeiros da Universidade Federal do Pará : https://doi.org/10.15468/3w9k3k.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset HBRA - Herbário do Instituto de Estudos Costeiros da Universidade Federal do Pará:

Crawler attempt: 456
Publishing organization: Instituto de Estudos Costeiros ( IECOS )
Publishing country: BRAZIL
Installation: speciesLink Network / INCT-HVFF IPT
Number of occurrences indexed for this dataset at the time of the issue: 15415
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 15839 total records; 15839 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/4212022/step

New IDs sample:

Old IDs sample:

BRA:IECOS:HBRA:16595
BRA:IECOS:HBRA:16596
BRA:IECOS:HBRA:16597
BRA:IECOS:HBRA:16598
BRA:IECOS:HBRA:16809
BRA:IECOS:HBRA:16599
BRA:IECOS:HBRA:16600
BRA:IECOS:HBRA:16601
BRA:IECOS:HBRA:16602
BRA:IECOS:HBRA:16603

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the HBRA - Herbário do Instituto de Estudos Costeiros da Universidade Federal do Pará : https://doi.org/10.15468/3w9k3k.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.


DailyNotes templater headings support

Is there a way to write the heading for a Daily Notes calendar to parse
# [[<% tp.date.now("YYYY-MM-DD dddd", -1) %>|⇚]] **<% tp.date.now("YYYY MMM DD dddd", 0) %>** [[<% tp.date.now("YYYY-MM-DD dddd", 1) %>|⇛]]
into the correct heading?
So, for example, today, new events/tasks would land under:
# [[2023-02-28 Tuesday|⇚]] **[[2023 Mar 01 Wednesday]]** [[2023-03-02 Thursday|⇛]]
rather than under a heading with the templater code?

This is not possible right now. I'll tag this as an enhancement.


Update changelog

This Pull Request updates the CHANGELOG file to reflect recent changes made to the smile-id-core SDK. The following are some of the changes made since the last update:

Implemented Business Verification with test and runnable example
Fixed bug for image-uploads and updated test and runnable examples accordingly
Added smile-ID constants (image_type_id, Job type, Image type and sid server value )
Replaced unittests with pytests. Ensure pytest mocks and fixtures are used appropriately
Code refactoring;
Add stricter mypy types, and custom types.
Docs clean-up (README and LICENSE), etc

Thanks


chore: add depguard config for linter

See https://github.com/Kong/go-kong/actions/runs/5171929210/jobs/9315785132?pr=333 for example problem.
golangci-lint version 1.53 upgraded the depguard linter from v1 to v2. AFAICT v1's behavior with no configuration to allow all packages, whereas v2 apparently denies everything but the standard library and local files (unclear--I'm not sure where the defaults actually live and the depguard change logs do not mention this, but it appears to be the case from my testing). https://github.com/golangci/golangci-lint/pull/3795#issuecomment-1576920783 agrees but doesn't indicate the cause of the default change.
The presence of a denylist will instead deny only those packages and allow all others. The tests I can find in golangci-lint appear to all use a denylist and may be missing the default behavior, and it's possible nobody noticed the issue because it was masked by some other issue where depguard was preventing the linter from running at all :|
I don't entirely agree that this is a "reasonable" default and have half a mind to just remove it, but seeing as we need to make changes to the golangci-lint config either way, we may as well list some basic packages we should never include instead.

Codecov Report
Patch and project coverage have no change.

Comparison is base (9bc15b0) 52.75% compared to head (3aa1a57) 52.75%.

:exclamation: Current head 3aa1a57 differs from pull request most recent head d796f57. Consider uploading reports for the commit d796f57 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #337   +/-   ##
=======================================
  Coverage   52.75%   52.75%
=======================================
  Files          69       69
  Lines        5093     5093
=======================================
  Hits         2687     2687
  Misses       1832     1832
  Partials      574      574

Flag
Coverage Δ

2.1.4
36.16% <ø> (ø)

<IP_ADDRESS>
46.65% <ø> (ø)

2.2.2
36.16% <ø> (ø)

2.3.3
36.32% <ø> (ø)

<IP_ADDRESS>
47.31% <ø> (ø)

2.4.1
36.40% <ø> (ø)

<IP_ADDRESS>
47.39% <ø> (ø)

<IP_ADDRESS>
47.39% <ø> (ø)

2.5.2
36.40% <ø> (ø)

2.6.1
36.40% <ø> (ø)

<IP_ADDRESS>
47.39% <ø> (ø)

2.7.2
36.40% <ø> (ø)

<IP_ADDRESS>
48.92% <ø> (ø)

2.8.3
36.40% <ø> (ø)

<IP_ADDRESS>
48.92% <ø> (ø)

3.0.2
35.85% <ø> (ø)

<IP_ADDRESS>
49.38% <ø> (ø)

3.1.1
37.34% <ø> (ø)

<IP_ADDRESS>
50.97% <ø> (ø)

3.2.2
37.40% <ø> (ø)

<IP_ADDRESS>
50.97% <ø> (ø)

community
37.95% <ø> (ø)

enterprise
51.52% <ø> (ø)

enterprise-nightly
50.97% <ø> (ø)

integration
52.75% <ø> (ø)

nightly
37.40% <ø> (ø)

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[$250] Chat - Compose box is hidden when editing multiple line break message

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: v1.4.64-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4503695
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team
Action Performed:
Pre-requisite: user must be logged in.

Go to any chat.
Send a message with 10 line breaks.
Tap and hold on the recently sent message.
Tap on "Edit comment".
Verify the compose box is partially hidden, the chat does not auto-scroll to the bottom.

Expected Result:
The page should auto-scroll to the bottom and the compose box should be fully visible without manual scroll.
Actual Result:
The page is not auto-scrolled to the bottom, the compose box is partially hidden, manual scroll is required.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[x] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/Expensify/App/assets/115492554/b77f87b4-a964-4ebe-99c5-b41fdbde7b72

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0179a22c17165154c1
Upwork Job ID:<PHONE_NUMBER>960959488
Last Price Increase: 2024-05-29

We think this issue might be related to the #vip-vsb.

I can reproduce it. Couldn't find a recent issue, looks like @kosmydel fixed it once before here in Oct 2023: https://github.com/Expensify/App/pull/24502

I can reproduce it. Couldn't find a recent issue, looks like @kosmydel fixed it once before here in Oct 2023: #24502

The mentioned issue was related to mWeb only, not native. At first glance, the root cause of this issue is different.

If  there is multi lines text, it's impossible to edit on iPhone.
https://github.com/Expensify/App/assets/23204263/ddc288c3-d9b0-44b5-8633-e7d413762a63

@rojiphil are you going to review these proposals?

@rojiphil are you going to review these proposals?

@trjExpensify Yes. Will review and share an update today.

react-native-web doesn't implement Keyboard event

@tienifr  What are your thoughts on this concern?

runAfterInteractions can not make sure the keyboard is shown totally

@suneox  And what are your thoughts on this concern?

@rojiphil any feedback on this?

I think I have pointed out the reason i'm using these attributes based on a lot of places that also use it.

Just because it is used elsewhere does not necessarily mean we can use it here too. So I am still not convinced of the reasoning here.

This issue still happens when you edit the last item has multiple lines

@suneox As I understand from your comment here, this problem happens only for the last item. So, why is this problem not observed for non-last items? Non-last items does not seem to need the support of runAfterInteractions and requestAnimationFrame to display edit box completely.

@rojiphil any feedback on the above?

Bump, @rojiphil. Can you take a look at that please?

Sure. I will check this today and provide update.

As mentioned earlier here, we can reproduce the problem for the last item even when the keyboard is not shown. I also reconfirmed this with the latest main. So, I disagree with any RCA that uses the keyboard as the main reason for this issue. Also, resolving the issue with delay is not guaranteed to work all the time. So, I am looking for a solution that resolves the issue even when the keyboard is not shown on native devices.
https://github.com/Expensify/App/assets/3004659/de736ffe-1d11-4bdb-9fd6-30cdd3afdb4f

Got it okay, so @suneox, maybe you have some other ideas on what the root cause of this is!

@rojiphil, thoughts?

In this case, this issue happens when we have multiple transitions run in the time (keyboard open, hide main composer, report item change to edit view and scroll to edit view) and my solution using runAfterInteractions and requestAnimationFrame also can handle this issue

@suneox What if any of the other transitions are initiated after the scroll operation? This would still cause our issue here. That is why resolving the issue with delay is not guaranteed always to work.
Also, what has changed recently that started causing this issue?
We still need to get to the root cause of this issue.

@suneox do you have any further insight on the root cause?

And could you please try my proposal?

I tested the solution and it seems to work.
However, I am still on the fence if we want to use delay (via use of runAfterInteractions and requestAnimationFrame) as an approach to resolve this issue and as proposed in @sunnex proposal.
On one hand, theoretically,  there is always a faint chance for scroll to be initiated before other animations in which case this issue can get reproduced.
Whereas, on the other hand, we have used the delay pattern to address scroll issues here and here and also in other situations like here and here.
So, curious to know the thoughts of internal engineer too on this before we move ahead.
🎀👀🎀

Thanks for the review, given the fact that this delay pattern seems to work fine in these other locations, I think we can also use it here as well

👋 checklist time, please!

[x]  [@rojiphil] The PR that introduced the bug has been identified. Link to the PR: Offending PR
[x]  [@rojiphil] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: Added comment
[x]  [@rojiphil] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: Not Required. Existing checklist is good enough to capture such issues.
[x]  [@rojiphil] Determine if we should create a regression test for this bug. :  Given the spooky nature of this issue, it is better to have a regression test case to ensure this does not occur again.
[x]  [@rojiphil] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Go to any chat.
Send a message with 10 line breaks.
Tap and hold on the recently sent message.
Tap on "Edit comment".
Verify that the page auto-scrolls to the bottom and the compose box is fully visible without manual scroll.

👋 checklist time, please!

@trjExpensify Completed BZ checklist and accepted the offer too. Thanks.

Thanks! Regression test issue created for Applause.
Payment summary as follows:

$250 to @suneox for the fix
$250 to @rojiphil for the C+ review

Paid you both, closing!


(question) how can i change texture of material to my texture loaded from .png file

What is the game you are using with IL2CPP Resolver?
SCP:SL
Details:
how can i change texture of material to my texture loaded from .png file, i tried before but i get black texture
Screenshots/Video:
No response
Minimal, Complete and Verifiable Example code:
No response

this question not related to this library, you should search in google for example "how to load texture in unity"
then you reimplement with il2cppresolver.

I would do this with pleasure, but there is very little information in the documentation, for example, I did not understand which method performs the equivalent of this C# code new Texture2D(50,50);

il2cpp_new_object with il2cppclass

I'll try not to ask any more questions like this and put everything in this comment. I don't understand how to pass arguments (50,50) and if they can be passed at all, I don't understand how to call methods in a new object to change fields, etc. I don't understand how I can assign this new object to an existing material.

auto c = (Unity::CComponent*)Unity::Object::New(your_class);
auto c1 = (Unity::CComponent*)Unity::Object::New(your_class1);

// constructor
c->CallFunction<>(".ctor");

c->SetMemberValue<your_type>("your_field", field_data);
c1->SetMemberValue<your_type1>("your_field", c);

pseducode btw dont paste that, the documentation of the library isnt even proper, but its not hard to do anything. almost everything here is just some pointer-like bullshit. you new with that cast to component and set field then put in another field... just stacking them.
constructor is like .ctor() or .cctor iirc, i dont really remember, since long time without doing new thing.


Upgrade @snowpack/plugin-webpack to Webpack 5

Is @snowpack/plugin-webpack planned to be updated to Webpack 5?

Yes! We’d love a PR if anyone is able to provide one.

@drwpow - I could try to tackle this. Feel free to assign this issue to me given you agree with the following caveat.
This plugin uses webpack-manifest-plugin which currently is not compatible with webpack 5. If we want to update to webpack 5, the plugin's manifest option would have to fallback to false internally until the manifest plugin offers webpack 5 support (see migration plan).

Bah, that's a shame. We may just want to wait, then

Update: https://github.com/shellscape/webpack-manifest-plugin/issues/222#issuecomment-730409884

An update for you all here: https://github.com/shellscape/webpack-manifest-plugin/issues/222#issuecomment-736969974

Thanks @shellscape! I'm going to close this issue on our end for now, since we use our issue tracker for prioritized tasks only and it sounds like the Webpack v5 ecosystem (and webpack core, to an extent) needs a bit more time to settle. Will reopen when we have the time & when it feels safe to upgrade (probably post Snowpack v3 launch).
In the meantime, I believe that there is a discussion in our discussion forum where we can continue to track this.


Dataset labeling issues

Dear author, hello, about the production of dataset labels I would like to ask you, 1. Do you already mark the target with an area greater than 2000 pixels as ignore when you use labelimg to label the image, or after marking all the targets in 9 categories, and then change all the categories with the target box greater than 2000 to ignore through the code? 2. Are the target boxes within 1024 pixels or 2000 pixels for the 9 categories you marked?We look forward to hearing from you.

Yes, any instances who belong to 9 fore-ground categories but wtith an area larger than 2000 pixels are labeled as ignore
Yes, instances with an area smaller than 2000 pixels are labeled, but only those within 1024 pixels will be evaluated during testing.
All these details can be found in our paper, please refer to it.

Hello author, the first question I think you may have misunderstood meant, I want to ask you, you are the first case when you use labelimg to label the ignore category. Or is it the second case, only 9 categories are labeled during the tagging process, and finally the category with a target box area greater than 2000 pixels is uniformly changed to ignore using the script code written by yourself?


proposal: net/http: configurable Server.WriteBufferSize

Hi, in our most cases, the http written bytes more than 4<<10, so we need set bufio Read/Write buffer size and connection  SNDBUF/RCVBUF ?
Also we think this change is appropriate, does go plan to support this?

Can you report any performance numbers with different buffer sizes?

yeah, there are sample test result below, we written 10kb bytes.
env: Debian GNU/Linux 8.2  4core 4g ram
test code
func BenchmarkBigWrite(b *testing.B) {
	s := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		w.Write(bigBs) // bigBs is 10kb bytes
	}))
	defer s.Close()
	b.SetParallelism(100)
	b.ResetTimer()
	b.RunParallel(func(pb *testing.PB) {
		for pb.Next() {
			res, err := http.Get(s.URL)
			if err != nil {
				log.Fatal(err)
			}
			_, err = ioutil.ReadAll(res.Body)
			res.Body.Close()
			if err != nil {
				log.Fatal(err)
			}
		}
	})
}

standard net/http, three times
go test -test.bench=".*" -benchmem -benchtime=5s
BenchmarkBigWrite-4	  100000	     79756 ns/op	   37929 B/op	      72 allocs/op
ok  	mytest/httpbuf	8.857s
BenchmarkBigWrite-4	  100000	     78570 ns/op	   37948 B/op	      72 allocs/op
ok  	mytest/httpbuf	8.665s
BenchmarkBigWrite-4	  100000	     79072 ns/op	   37876 B/op	      72 allocs/op
ok  	mytest/httpbuf	8.718s

change http/server.go 479L
bw := newBufioWriterSize(checkConnErrorWriter{c}, 4<<10)

to
bw := newBufioWriterSize(checkConnErrorWriter{c}, 10<<10)

go test -test.bench=".*" -benchmem -benchtime=5s
BenchmarkBigWrite-4	  100000	     69645 ns/op	   39890 B/op	      73 allocs/op
ok  	mytest/httpbuf	7.692s
BenchmarkBigWrite-4	  100000	     69816 ns/op	   39961 B/op	      73 allocs/op
ok  	mytest/httpbuf	7.702s
BenchmarkBigWrite-4	  100000	     67768 ns/op	   39856 B/op	      73 allocs/op
ok  	mytest/httpbuf	7.516s

Related: https://github.com/golang/go/issues/22618

You could also just wrap the response writer with your own bufio.Writer. More allocation but less exposed API which I think is a fair tradeoff.

Hello! I'm the implementor of a server that tunnels remote desktop connections over websocket (in this case Gorilla). I was facing some performance challenges particularly when high latency high bandwidth connections were involved.
I fired up Wireshark to see on which end the data flow was restricted. It turned out that

the bandwidth of each connection was quite steady

there was no significant amount of dropped packets / retries, so probably not limited by congestion control

the advertised window in the ACK packets coming back from a client was sufficiently generous (around 300KB)

however, when sending there were always just around ~4kB of data in flight. Given the high latency to the clients, the server spent most of the time waiting for data to be ACKed by clients, and then immediately sent out a burst of new packets, then proceeded to wait again for enough outstanding bytes to be ACKed.

This very likely is due to a small TCP send buffer, since this would limit the ammount of outstanding bytes that the TCP stack could keep track of.
For high bandwidth high latency connections it is extremely beneficial to have a large(r) TCP recv buffer on the OS level that I need to be able to set per client (i.e. in case it is not a high latency). Wrapping it in bufio as was suggested is not sufficient as the OS will just do as it wants.
So the need is to be able to set the OS level receive buffer / send buffer (not the internal buffer with bufio) per connection which is not exposed in the API

For TCP high-throughput, you must set large-enough TCP buffers before the socket connects, because the relevant TCP parameters (window scale) are set once on the initial TCP handshake and immutable afterwards.
It should be possible nowadays in Go without resorting to hackish, hideous workarounds.  But I am sorry I can't point you do documentation on how to best do it.

Hello 👋
I have made a patch that adds a configurable WriteBufferSize option to the http.Server struct. This should solve this issue for now
Feel free to check it out at https://github.com/oddmario/go-http-server-custom-write-buffer-patch :)

I tried reproducing the benchmark results from https://github.com/golang/go/issues/13870#issuecomment-170223288, but in my test changing the write buffer size had no observable impact:
$ benchstat /tmp/bench.[01]
goos: linux
goarch: amd64
pkg: _
cpu: AMD EPYC 7B12
           │ /tmp/bench.0 │         /tmp/bench.1         │
           │    sec/op    │   sec/op     vs base         │
BigWrite-8    59.48µ ± 7%   57.11µ ± 3%  ~ (p=0.065 n=8)

A bufio.Writer will skip the buffer entirely and pass through the write when writing a large chunk of data. As such, I'd expect the impact of changing the buffer size to be minimal when making a single large write from a handler, as in this benchmark.
Of course, that's just my test system; maybe there's a more observable difference elsewhere or with a different test. But I'd like to better understand when changing the write buffer size has an impact and why.

I tried reproducing the benchmark results from #13870 (comment), but in my test changing the write buffer size had no observable impact:
$ benchstat /tmp/bench.[01]
goos: linux
goarch: amd64
pkg: _
cpu: AMD EPYC 7B12
           │ /tmp/bench.0 │         /tmp/bench.1         │
           │    sec/op    │   sec/op     vs base         │
BigWrite-8    59.48µ ± 7%   57.11µ ± 3%  ~ (p=0.065 n=8)

A bufio.Writer will skip the buffer entirely and pass through the write when writing a large chunk of data. As such, I'd expect the impact of changing the buffer size to be minimal when making a single large write from a handler, as in this benchmark.
Of course, that's just my test system; maybe there's a more observable difference elsewhere or with a different test. But I'd like to better understand when changing the write buffer size has an impact and why.

@neild - What was the TCP write buffer size on your system when you conducted this test?


⚠ Bofrost.be has degraded performance

In e38c02b, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1621 ms

Resolved: Bofrost.be performance has improved in 8944ac7.


SOA & MINFO compression length mismatch

The following two newly created test cases fail:
func TestMsgCompressMINFO(t *testing.T) {
	msg := new(Msg)
	msg.Compress = true
	msg.SetQuestion("www.example.com.", TypeSRV)
	msg.Answer = append(msg.Answer, &MINFO{
		Hdr:   RR_Header{Name: "www.example.com.", Class: 1, Rrtype: TypeSRV, Ttl: 0x3c},
		Rmail: "mail.example.org.",
		Email: "mail.example.org.",
	})

	predicted := msg.Len()
	buf, err := msg.Pack()
	if err != nil {
		t.Error(err)
	}
	if predicted != len(buf) {
		t.Fatalf("predicted compressed length is wrong: predicted %d, actual %d", predicted, len(buf))
	}
}

func TestMsgCompressSOA(t *testing.T) {
	msg := new(Msg)
	msg.Compress = true
	msg.SetQuestion("www.example.com.", TypeSRV)
	msg.Answer = append(msg.Answer, &SOA{
		Hdr:  RR_Header{Name: "www.example.com.", Class: 1, Rrtype: TypeSRV, Ttl: 0x3c},
		Ns:   "ns.example.org.",
		Mbox: "mail.example.org.",
	})

	predicted := msg.Len()
	buf, err := msg.Pack()
	if err != nil {
		t.Error(err)
	}
	if predicted != len(buf) {
		t.Fatalf("predicted compressed length is wrong: predicted %d, actual %d", predicted, len(buf))
	}
}

with:
--- FAIL: TestMsgCompressMINFO (0.00s)
    length_test.go:402: predicted compressed length is wrong: predicted 81, actual 65
--- FAIL: TestMsgCompressSOA (0.00s)
    length_test.go:422: predicted compressed length is wrong: predicted 99, actual 88

I believe the compressedLen code isn't handling matches between the two compressed domains properly, whereas the PackDomainName code is.
/cc @miekg

In the first test, the second "mail.example.org." isn't being compressed into the first. While in the second test, "example.org." from "mail.example.org." isn't being compressed into "ns.example.org.".
I think they're both the same bug and honestly I don't understand what's wrong with the current code. I have managed to fix it in rewriting the compressed length code which I'll upload shortly.


[bug] cursive input ending up in 2x vi in different terminal

When testing a change to an application using Cursive (the application is tupm of david simmons), I found the input that I put into the dialogs in my vi files (that were still open) between the rest of the code. As a terminal emulator I use terminator. I had two terminator windows open and the window1 contained two sub windows, each with one vi open on my code. Window2 was just one terminal window and was where I compiled and executed tupm.
After testing my change, which was entering a new account, canceling and then entering a new account and saving, I found that the exact data I had input in the dialog, was in both of my vi sessions right in between the code! Plus the status line revealed a weird status "I-C-X" and a remark pertaining to a search of some sort.
I have included screenprints here of both terminals. The code I was editing I will include in my github repo under gbonnema/tupm and branch separation.
I have not repeated it yet, but I will after this issue and I will report on the result of it. You see my input for the dialogs in the vi windows in the lines with "gort x x x x" and the next one "madeup me thatissecret myown I just want to add an entry to the database.". The weird(er) thing is that the left vi session has the character "Add" prepended while the right vi session has the characters "impl" prepended to the second line (madeup).

My question for now is: is this a cursive thing, a ncurses thing or a terminator thing? I suspect the code in tupm has nothing to do with it, but I will commit the change to the separation branch.
I hope you have some idea of what is going on here.
Kind regards, Guus Bonnema.

It probably has nothing to do with cursive. All commands I input following the test, also appeared in vi.
It looks like a terminator thing, not an ncurses or cursive thing.
I will leave it open for now, and include the resolution should I find one. If I don't I will close it (with comment).
Sorry for the noise.

Hmm, it is weird indeed.
Do you have steps to reproduce it consistently? Are you starting vi (or vim?) in the same window as the cursive app? In a separate tab?
If you can reproduce it, can you try with the termion backend to see if it is also affected?

I am pretty sure it is a terminator problem.
I had one terminator window with split screen and 2 vi sessions. Then I had a second terminator session where I conducted tests (executing cargo run) and did the compilations. After testing tupm, everything I did in one of the 3 terminator sessions was broadcast to the other 2.
The only thing I can imagine is that while testing the tupm application, I must have used a shortcut that terminator intercepted and interpreted it as being a command to broadcast from that point on. It may have something to do with it's usage of the bus-system of gnome.
And it's not repeatable, until I know which shortcut caused this behavior. I have entered an issue at ubuntu launchpad for terminator and pointed to this issue for the screenprints and clarification.
For that reason I don't think it is a Cursive problem. Until I get response of terminator I will leave it open. Lacking response I will close it in a week or so. Only if terminator claims they do not cause this behaviour, I will continue testing trying to reproduce it also with termion.
I have notified the

Ok, I found the trigger. it is in a keybind that terminator keeps (alt-a) that means, broadcast everything from now on to all terminals. Using tupm I sometimes use the keybind to access a menu option. Alt-a I used to get to the menu option account. When it didn't seem to work I ignored it and just used alt-f (for File) and navigated to account. however, from that moment on, all my input on dialogs was being recorded and transmitted to the other sessions of terminator. Problem solved.
However, is there a way to prevent the alt-keybinds of terminator to activate if we are using ncurses/Cursive? If anyone would know, it would be you.
P.S. I suspect you cannot prevent events from seeping through the cracks to the terminal emulator.

I want to test the problem using termion backend. I just wonder how I make Cursive chose termion.
I tried doing cursive install termion which lead to an error message specified package has no binaries.
Do you have the incantations necessary to switch from ncurses to termion?
P.S. When trying to use my system's package system (dnf) I also have switch to the system's version of cargo and rust, so I would prefer doing all using cargo and maybe rustup.

Wow! Good investigation!

Ok, I found the trigger. it is in a keybind that terminator keeps (alt-a) that means, broadcast everything from now on to all terminals.

Sounds quite risky! Good thing you didn't end up broadcasting your password to a irc client or something.

I want to test the problem using termion backend. I just wonder how I make Cursive chose termion.

This is done in 2 ways: first, you need to "enable" other backends in Cursive; then, you need to select the correct backend when creating cursive.
For the first step, this is done by enabling extra features for cursive: https://github.com/gyscos/Cursive/wiki/Backends
For tupm, you would need to edit Cargo.toml:
[dependencies]
cursive = { version = "0.10", features = ["termion-backend"] }

For the second step, there are multiple ways to create a Cursive instance:

Cursive::default(): this one selects the first enabled backend from a list. termion is higher up in this list than ncuses, so if both termion and ncurses are enabled, termion will be picked. This is what tupm seems to be using, so if you enable a backend in the first step, it should be used automatically.
Alternatively, Cursive::termion() or Cursive::ncurses() can be used to explicitly select the backend used.

I checked the trait Backend, but could not find a way to identify the backend. Is there a way that is hidden elsewhere? Or should we add a function to the trait to identify the currently running backend?
I want to do this, so I can see (on screen) which backend I am working with. At the moment I haven't the foggiest because it depends on the features that are active.

I just pushed Cursive::backend_name(&self) -> &str to get the name of the current backend for debugging purposes.

Thank you. I appreciate it.

I would like to run something by you. I had to upgrade to 0.11.1 in order to get to the newly pushed backend_name, which also has some other changes. Specifically find_id only needs 1 parameter in stead of 2.
I got the code to compile this bit, but I am not confident that it is really the best solution. Would you kindly check and improve on the following? The code that is commented out was the original code.
 402     /// Handle the CTRL-R "reveal password" feature.
 403     fn reveal_password(&mut self) {
 404         let id = format!("{}_{}", VIEW_ID_EDIT, FIELD_PASSWORD);
 405         let view: &mut EditView = &mut self.find_id(&id).unwrap();
 406         view.set_secret(false);
 407         //        self.find_id(&id, |edit_view: &mut EditView| {
 408         //            edit_view.set_secret(false);
 409         //        });
 410     }

Kind regards, Guus Bonnema.

It was renamed to call_on_id to better match the one defined on Cursive itself.

I changed the code from find_id to call_on_id and got an unexpected side effect.
Since this change (from 0.10 to 0.11 plus call_on_id) I get an empty screen, where I have to enter an arbitrary character before the screen starts. I suspect I am testing with termion, but I will need to make sure.
Do you know if anything concerning the reading of characters has changed between 0.10 and 0.11?
P.S. I created the patch in gbonnema/tupm on branch cursive-0.11. You can see the diff between that branch and master which includes the Cargo.toml change to 0.11 and the code replacements.

I now tested with both ncurses and termion (verified on screen with display of backend_name() ) and it turns out both need the extra character to get started. Termion does not show an empty page, just waits for input. Ncurses shows an empty page while waiting for input.

Ah, tupm seems to be manually handling the event loop instead of using Cursive::run(). In this case, it'll need to call Cursive::refresh() once before stepping, like in Cursive::run().

Yes, that was the remedy thank you.
So apparantly, both termion and ncurses suffer from the alt-a shortcut that terminator snatches from them followed by transmitting it to all terminator sessions presumably withing one user logon.
Better not be using sending any sensitive commands at that time!
Should I close this issue? I don't think we can change any of this as the terminal emulator can do what it wants?

Yes, I think it's outside of the scope for Cursive.
I can imagine cases where this broadcasting is useful across multiple cursive applications, so disabling it entirely (if it's even possible!) doesn't sound like the right thing to do.
At this point it's much like the other terminal shortcuts: it's entirely user-specific. This does mean it's hard to rely on a specific key combination being available, but that's the hard life of terminal interfaces :(
The usual solution is to let user re-map shortcuts, so even if the terminal catches Alt+A, the application could be configured to expect Alt+B instead, or something like that.

Yep: that sums it up! I will close this issue now. Thank you for your consideration and time!


Add support for backgroundImage key to Adaptive Card in addition to the existing backgroundImageUrl key

Fixes #572

@riarenas,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

Android and iOS CI are not ready. Failures are expected.


Move ruff to dev dependencies

This shouldn't be a real dependency. It ends up conflicting with people's ruff versions when they try to install via pypi.
This might be a good time to move other dependencies into the dev closure as well. I just don't know which of the current dependencies are actually required.

Ruff is not a dev dependency, it's needed to produce nice-looking code. See #998


Inconsistency in model for cards

In GitLab by @erdzan on Dec 25, 2020, 12:35

Location: Data for cards provided and used by backend api
Description: When fetching cards for a lecture by using request we get following data for a cards in a lecture:

{
    "cards": [
        {
            "tags": [],
            "_id": "5e406f300a1adf0479e627f8",
            "vorlesung": "BuK",
            "thema": "Satz von Rice",
            "content": "Es sei R die Menge der von TMen berechenbaren partiellen Funktionen. \nEs sei S eine Teilmenge von R mit $∅ ⊂ S ⊂ R$ mit S != ∅ und S != R. \nDann ist die SpracheL(S) = {⟨M⟩ | M berechnet eine Funktion aus S} nicht entscheidbar.",
            "img": "QnVLIA==",
            "id": "36",
            "__v": 0,
            "learned": 0,
            "relevant": [
                "5e41ed1013f9d7034fec8205",
                "5e4069fc0a1adf0479e627ee",
                "5e4011e32aca8b03de20188f"
            ],
            "latex": 1
        }
    ]
}

However, when creating a new card in the lecture BuK, following model is used
{card: {thema: "Buk", content: "2020", tags: [], abrv: "BuK", latex: 0}}

Expected behaviour: Model for card should be consistent. Currently, when creating a card abrv is used for vorlesung
Steps to reproduce: Get data with: https://rwth-aachen.tk/api/cards/a?abrv=BuK , post card in same lecture.

In GitLab by @erdzan on Dec 25, 2020, 12:35
changed the description

In GitLab by @erdzan on Dec 25, 2020, 12:35
changed the description

In GitLab by @erdzan on Dec 25, 2020, 12:36
changed the description


Panel loses maximized state after toggling sidebar visibility

VS Code Version: stable
OS Version:

It was working fine in 1.81, after update to latest is broken
Steps to Reproduce:

Make sure sidebar is visible, e.g. explorer view
Maximize panel
Click on explorer icon in sidebar to hide sidebar
:bug: editor gets focused and panel size is restored

PR fixing it https://github.com/microsoft/vscode/pull/200585

duplicate of https://github.com/microsoft/vscode/issues/195119


patch: Add node v20 as supported version

Add node v20 as supported version and change node versions to reflect what nodejs contract currently builds

@vipulgupta2048 @thgreasi Just noticed that node 14 and 16 has been removed from the node contract but they exist in the balenalib hub.I think it would be helpful to mark them as deprecated/EOL in the docs and reflect that these versions of sw.stack will not get rebuild for example with newer sw.os releases.

That indeed sounds correct @Iznogohul .
I recently actually removed a number of EOL sw/oses from the contracts, which means that base images will no longer be built, but back then thought that those changes would propagate to the docs automatically
https://github.com/balena-io/contracts/pull/421
https://github.com/balena-io/contracts/pull/422
https://github.com/balena-io/contracts/pull/423
We will probably try to make that automation work, but I wouldn't block any PR doing those changes manually in the mean time.

Indeed docs, at the moment don't generate this page automatically and we are figuring out an strategy to automate all balena-base images docs to reflect the right information out there.

@thgreasi Will try to open these PRs if I find some spare time.

Thank you @Iznogohul


Data Removed from JSON

Data for Active, Recovered, and Deaths are removed from JSON file after last update.

Hi, This is by design. Since we don't know which patient recovered exactly when the state bulletins give out the information, the current logic won't work to calculate the recovered and deceased patients.
We are working on a way to get this information. Will update here once that is live.


[New chain]: SKALE Europa Hub Testnet

Chain Name
SKALE Europa Hub Testnet
RPC URL
https://testnet.skalenodes.com/v1/juicy-low-small-testnet
The chain must be added to https://chainlist.org/

[X] I confirm that the chain is added to chainlist

After creating the issue, a bot will estimate the required pre-fund and post it in the comments. Please check this checkbox after you send the pre-fund.

[x] I sent the pre-fund in accordance with Github Action's comment

Relevant information
No response

The RPC doesn't support contract deployment simulations:
curl -s $RPC -H 'content-type: application/json' --data '{"
jsonrpc":"2.0","id":0,"method":"eth_call","params":[{"data":"0x604580600e600039806000f350fe7ffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffe03601600081602082378035828234f58015156039578182fd5b8082525050506014600cf3"},
"latest"]}'

Returns:
{
  "id": 0,
  "jsonrpc": "2.0",
  "result": "0x"
}


Bump fontdb to 0.16

We were getting duplicate ttf-parser dependencies because of rustybuzz releasing its ttf-parser 0.20 upgrade out of sync with fontdb 0.16, whose update just got published.

Looks like some new crate releases fixed the indexmap/hashbrown duplicate.
Note though that this only checks the core cosmic-text crate (probably intended), but I get a whole bunch of errors when running cargo deny --workspace check.


docs: add import to server-side cookies example

🔗 Linked issue

❓ Type of change

[x] 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Docs currently do not specify where appendHeader comes from. This lead to me being confused for quite some time.
📝 Checklist

[ ] I have linked an issue or discussion.
[x] I have updated the documentation accordingly.

Thank you!


Bug in TimeSeriesKMeans using metric 'softdtw'

Hello @rtavenar ,
I was trying out the TimeSeriesKMeans model with variable length time series.
Unfortunately the model seems to fail using "softdtw" as a metric.
Code I tried out.
import numpy
import random

from tslearn.clustering import TimeSeriesKMeans

seed = 0
numpy.random.seed(seed)

ts = list()

# random time series of variable length
ts.append(random.sample(range(1, 1000), 100))
ts.append(random.sample(range(1, 1000), 99))
ts.append(random.sample(range(1, 1000), 98))

# Soft-DTW-k-means
print("Soft-DTW k-means")
sdtw_km = TimeSeriesKMeans(
    n_clusters=2, metric="softdtw", verbose=True, random_state=seed)
y_pred = sdtw_km.fit_predict(ts)

ValueError: Input contains NaN, infinity or a value too large for dtype('float64').
Any help would be appreciated, thanks.

Hi @nikhilRP , and thanks for this very precise bug report.
I'll try to investigate on this as soon as I can. This is definitely a bug, but I have no idea at the moment how difficult it would be to solve it.
I'll let you know.

@nikhilRP
I have just pushed a version that fixes the issue on my side. Coud you confirm that it's OK for you? If so, I'll add a doctest to ensure that we do not have the same bug in later versions.
Best,
Romain

Thanks for taking time and fixing it. I did test the fix and it works fine, very much appreciated.

Great! By the way, I guess this fix is a step forward regarding Issue #16 :)


Important keywords

Create a collection of relevant  (for this course) keywords and give a short explanation + example

this deserves its own page I think 😂

totally agree 😂


Reduce time for TestRunTwoConcurrentContainers

Signed-off-by: John Howard<EMAIL_ADDRESS>Cuts another 20+ seconds off the windowsTP5 CI runtime, and 2 seconds off the Linux CI runtime. No need for the container to sleep. Just exit immediately.

The purpose of the test seems to be running two containers at once. I would think that without the sleep, there's no guarantee that the containers are acutually running at the same time.
That said, it seems like the test could poll docker ps instead of waiting for the containers to finish their sleeps.

I had misinterpreted as start two containers simultaneously. I'll put back in the sleep, but keep it to 2. 20 is excessively expensive.

@aaronlehmann Updated.

LGTM

LGTM

@tiborvass win2lin just seems to be having a horrible time - I can't get any passes across multiple PRs. Have rebooted all nodes, both Windows and Linux. Everything I've seen seems to point to problems on the Linux boxes - apparent out of memory, going offline during a CI run, ....

I think we can merge this. win2lin problem is deeper than just this PR


Versions malformed?

When I run asdf list all flutter, I see:
.17.0-3.2.pre-beta
.17.0-dev.0.0-dev
.17.0-dev.1.0-dev
.17.0-dev.2.0-dev
.17.0-dev.3.0-dev
.17.0-dev.3.1-beta
.17.0-dev.4.0-dev
.17.0-dev.5.0-dev
.18.0-6.0.pre-dev
.18.0-dev.0.0-dev
.18.0-dev.1.0-dev
.18.0-dev.2.0-dev
.18.0-dev.3.0-dev
.18.0-dev.4.0-dev
.18.0-dev.5.0-dev

(truncated, full list: https://gist.github.com/mrienstra/52e68246ecf15ed02e20b137c5a924d4 )
Notable I do not see any of the 1.17.* or 1.18.* versions, instead I see .17.* or .18.*.
 Presumably because Flutter recently changed their version number format -- used to always start with a v, but they dropped the v as of 1.17.0.
https://github.com/oae/asdf-flutter/blob/master/bin/list-all#L17
has gsub("^v"; "") but that should only strip the first character if it is a v...

Last week, I have merged a pull request about this. It should be fixed not if you update the plugin itself. Can you update the plugin and try it again?
asdf plugin-update flutter
asdf list all flutter

Will do! Sorry, I think I forgot to attempt that before opening this issue. 🤦

Yup, my bad, I didn't have the latest version. Thanks for the quick response.
Resolved by https://github.com/oae/asdf-flutter/pull/4


Update dependencies and workflows

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (a1ee0af) 100.00% compared to head (9ed7353) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #501   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           19        19
  Lines         1714      1714
  Branches       260       260
=========================================
  Hits          1714      1714

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Ellipsis then space, not space then ellipsis

We have word ...number, but the proper result should be words... number. Ellipsis then space, not space then ellipsis.
cat ellipsis.csv
long_text,double
jaywalker-swear-popcorn-opacity-nuttiness-roster,5.89
unspoiled-treachery-yearning-deputize-stimuli-coexist,2.34
conflict-yield-sulphate-grumpily-vagrantly-subsiding,7.89

Current results
> cat ellipsis.csv | tv

      tv dim: 3 x 2
      long_text            double
1     jaywalker-swear-pop …5.89
2     unspoiled-treachery …2.34
3     conflict-yield-sulp …7.89

Desired results
> cat ellipsis.csv | tv

      tv dim: 3 x 2
      long_text            double
1     jaywalker-swear-pop… 5.89
2     unspoiled-treachery… 2.34
3     conflict-yield-sulp… 7.89

Closed with #61


MKLDNN LSTM Regression in MKLDNN 0.17

We noticed that after the MKLDNN 0.17 update on 11/7 that our lstm models have lower throughput than before. https://www.dropbox.com/s/ifglj7lqcv4fw1q/Screenshot 2018-11-21 17.41.30.png?dl=0
For Q & A and discussion, please start a discussion thread at https://discuss.mxnet.io
Description
(Brief description of the problem in no more than 2 sentences.)
Environment info (Required)
What to do:
1. Download the diagnosis script from https://raw.githubusercontent.com/apache/incubator-mxnet/master/tools/diagnose.py
2. Run the script using `python diagnose.py` and paste its output here.

Package used (Python/R/Scala/Julia):
(I'm using ...)
For Scala user, please provide:

Java version: (java -version)
Maven version: (mvn -version)
Scala runtime if applicable: (scala -version)

For R user, please provide R sessionInfo():
Build info (Required if built from source)
Compiler (gcc/clang/mingw/visual studio):
MXNet commit hash:
(Paste the output of git rev-parse HEAD here.)
Build config:
(Paste the content of config.mk, or the build command.)
Error Message:
(Paste the complete error message, including stack trace.)
Minimum reproducible example
(If you are using your own code, please provide a short script that reproduces the error. Otherwise, please provide link to the existing example.)
Steps to reproduce
(Paste the commands you ran that produced the error.)

Clone repo at git@github.com:mseth10/deeplearning-benchmark.git
Run the following script python word_language_model/lstm_bucketing.py --num-hidden 650 --num-embed 650 --gpus 0 --epochs 30 --kv-store local

@pengzhao-intel  created this issue to track progress

Thanks to create the issue and we will submit PR to fix soon.

@mxnet-label-bot add [MKLDNN, Performance]

@pengzhao-intel - added this issue to tracker of open issues for release 1.4.0. Appreciate resolution before code freeze on November 27, 2018.

@srochel I am working with MKL-DNN team to fix the issue and will back the ETA to you.

Performance pre-mkldnn 0.17 (commit: 498e03da7ce420a48050fcd363aacb8dec2516f7)
2018-11-27 19:46:30,234 Epoch[0] Batch [0-50]	Speed: 31.46 samples/sec	perplexity=5543.863167
2018-11-27 19:47:14,732 Epoch[0] Batch [0-100]	Speed: 35.96 samples/sec	perplexity=3904.193633
2018-11-27 19:47:59,995 Epoch[0] Batch [0-150]	Speed: 35.35 samples/sec	perplexity=3247.239610
2018-11-27 19:48:49,773 Epoch[0] Batch [0-200]	Speed: 32.14 samples/sec	perplexity=2776.427683
2018-11-27 19:49:35,590 Epoch[0] Batch [0-250]	Speed: 34.92 samples/sec	perplexity=2494.544111
2018-11-27 19:50:23,366 Epoch[0] Batch [0-300]	Speed: 33.49 samples/sec	perplexity=2257.146195

Performance on current master (with regression) - consistent with with chart
Avg: 211.5
2018-11-27 20:56:41,348 Epoch[0] Batch [0-50]	Speed: 196.48 samples/sec	perplexity=7615.827994
2018-11-27 20:56:49,490 Epoch[0] Batch [0-100]	Speed: 196.51 samples/sec	perplexity=4302.516596
2018-11-27 20:56:55,812 Epoch[0] Batch [0-150]	Speed: 253.12 samples/sec	perplexity=3541.693082
2018-11-27 20:57:03,411 Epoch[0] Batch [0-200]	Speed: 210.55 samples/sec	perplexity=3087.250013

@azai91 please try the patch I sent to you by email. The final fix will go into MKL-DNN 0.17.1 and I will update to this release for MXNet.

@pengzhao-intel is the patch the latest version of mkldnn (84b2a5ae025c2730bb02e41b2fbf2f7b132f655c)

| Pre-0.17 (498e03da7ce420a48050fcd363aacb8dec2516f7) | Master | Patch
-- | -- | -- | --
  | 267.69 | 190.68 | 275.22
  | 279.78 | 176.55 | 267.68
  | 320.43 | 194.2 | 267.94
  | 285.07 | 201.84 | 310.52
  | 295.73 | 232.32 | 289.49
  |   |   |
  |   |   |
  |   |   |
  |   |   |
  |   |   |
Average | 289.74 | 199.118 | 282.17

Thanks, @azai91 I am working with MKL-DNN team to make the patch release out.

@azai91 done, ping the v0.17.1

@azai91 looks like this issue has been fixed? Can you verify and close the issue accordingly?

closing.


Updates JS reference classes to have js-app-view namespace

What
Any classes referenced by the JS should be updated to have a js-app-view namespace.
Why
This will keep it consistent with our GOVUK standards and also ensure that developers are obvious the changing a class may have effects on the JS functionality.
https://trello.com/c/tUuuK8IG/842-review-js-modules
https://trello.com/c/kkAfG0WV/1044-updates-js-reference-classes-to-have-js-app-view-namespace
⚠ This repo is Continuously Deployed: make sure you follow the guidance ⚠
Follow these steps if you are doing a Rails upgrade.

@theseanything - Is the precompiling assets working as expected? I've run it locally, and it works fine, but on CI, it fails:

@DilwoarH it might not - I've been having issues with compilation caches. I'll clear them now and see if that fixes it

@DilwoarH it might not - I've been having issues with compilation caches. I'll clear them now and see if that fixes it

This is how we compile it in Whitehall (if it helps):
RAILS_ENV=test bundle exec rails assets:clobber assets:precompile

@ollietreend - Could you have a look, I've added another commit for the unpublish page.
Note: JS tests failing on Github CI due to some pre-compiling issue that is being investigated (not related to PR)


Feature website

http://thewhitetulip.github.io/
This is actually the front end of the Omni Notes webapplication, the code for the final app is at https://github.com/plyrs/onweb

http://thewhitetulip.github.io/ cannot be found.
Did you mean http://thewhitetulip.github.io/omninotesweb/?

Yes, my apologies for the incorrect link.


add daily bonus claiming option

hey guys.
as you know in pocketFi there is no daily bonus claiming options.
i add a function to do this, can you check this out why this is not working ???
i check every xpath and it's correct

@Wellynounet will confirm, but I think this is the game where the final step is in the footer of a separate iFrame. We tried to add before but failed.

Tnx @Wellynounet
maybe problem is in wait time.
between 2 to 5 second is needed to load task tab and see daily bonus
wait.until maybe it's the solution.
can you add this changes

Thanks for the new add, I'll push an update I'm testing for another issue later today, or tomorrow, then merge your updates :)


md-autocomplete list doesn't stick on it's position when scrolling on iOS

Bug
What is the expected behavior?
md-autocomplete list should stick on it's position when scrolling on iOS
What is the current behavior?
md-autocomplete list doesn't stick on it's position when scrolling on iOS
What are the steps to reproduce?

What is the use-case or motivation for changing an existing behavior?
Current behavior avoids using this component, because in specific circumstances list gets out of the view rectangle.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Angular - 4.1.3
OS - iOS 10.2.1
Is there anything else we should know?

Possible duplicate of #4557

+1

This should be working in beta.7. Can you give it another shot?

I'm using @angular/material: 2.0.0-beta.7 and it doesn't work yet.

No more chance on https://material.angular.io/components/autocomplete/examples

Hi @molcik, did beta 7 solve your issue? I'm facing the same one.

Still having the issue with beta 8

#3745 should have fixed repositioning while scrolling. I however noticed myself that it did not reposition in my project. This is because my autocomplete is inside an element with scroll.
My site is separated into 3 sections. sidenav, toolbar and content. Only content scrolls.
If I add a scrollbar to the entire site it works. But I only want the scrollbar on the content element (ie, not stretching over the toolbar).

Also have this issue. Tested in your docs and in our own project.

See #5797 and see if that helps you. Not sure if it's the same issue or not.

@grizzm0 thx for the info :)

but it sadly didn't solve my issue.
So since the issue is also in the docs - I think the issue is still valid.

Here's my Plunker where i added some <br> above the input to better test the scrolling behaviour on iOS.
The scrolling also gets triggered when the virtual keyboard slides from below.

@PhilipSultanescu thanks

Any update on this issue? If you open the angular material2 website on the mobile safari, this issue still exists.

Hi @xiongemi.
Correct, it seems to be the same issue :(

Hi, FYI I solved that issue by using custom MD_AUTOCOMPLETE_SCROLL_STRATEGY
import {
    MdAutocompleteModule,
    MD_AUTOCOMPLETE_SCROLL_STRATEGY,
    Overlay, Platform,
   ...
} from '@angular/material';

export function MD_AUTOCOMPLETE_SCROLL_STRATEGY_FACTORY(overlay: Overlay, platform: Platform) {
    return () => platform.IOS ? overlay.scrollStrategies.block() : overlay.scrollStrategies.reposition();
}

@NgModule({
    imports: [
        MdAutocompleteModule,
        ...
    ],
    providers: [
        ...
        {
            provide: MD_AUTOCOMPLETE_SCROLL_STRATEGY,
            deps: [Overlay, Platform],
            useFactory: MD_AUTOCOMPLETE_SCROLL_STRATEGY_FACTORY,
        },
    ],
})

@aitboudad I get
'"node_modules/@angular/material/material"' has no exported member 'MD_AUTOCOMPLETE_SCROLL_STRATEGY'
when I try that. Any idea why? I'm on 2.0.0-beta.8

@kevinaud MD_AUTOCOMPLETE_SCROLL_STRATEGY will be landed in beta.9 in the meantime you can use the build snapshots for angular/material
// package.json
"@angular/cdk": "angular/cdk-builds",
"@angular/material": "angular/material-builds",

Oh okay, thanks for the help.
I've got that all working and the behavior is as expected on my computer, it won't allow scrolling while the autocomplete is open, but its still messed up on my iphone for some reason... As soon as I focus on the autocomplete and the keyboard opens up it moves my view down so the autocomplete is no longer visible.

@aitboudad Thank you for your solution! Autocomplete works "somehow" on iOS when scrolling (it still does not scroll with body, but does not show over the input), but when i start filtering options it returns to reposition strategy. Any advice?

Closing as duplicate of #4557

@aitboudad Thank you very much.
I've just used your code and it seems to be a real improvement so far.
I'm using @angular/cdk: 2.0.0-beta.12 so I needed to swap Md selector to Mat but that's fine.
I've just pasted this in my root module (app.module.ts):
In the imports:
import {MAT_AUTOCOMPLETE_SCROLL_STRATEGY} from '@angular/material'; import { Platform } from '@angular/cdk/platform'; import { Overlay } from '@angular/cdk/overlay';
Before @NgModule annotation:
export function MAT_AUTOCOMPLETE_SCROLL_STRATEGY_FACTORY(overlay: Overlay, platform: Platform) {   return () => platform.IOS ? overlay.scrollStrategies.block() : overlay.scrollStrategies.reposition(); }
And then the providers array of the module:
{       provide: MAT_AUTOCOMPLETE_SCROLL_STRATEGY,       deps: [Overlay, Platform],       useFactory: MAT_AUTOCOMPLETE_SCROLL_STRATEGY_FACTORY,     }
I would tell the autocomplete overlay is fixed under the input and is not floading all over the screen when I scroll (that was a real mess) but it seems to be still possible to hide the input field scrolling on the top. I mean that the overlay is not really fixed to the input.
I've checked the CDK, there are directives but I don't believe we can use them on the pre-build component.
I've also tested the cdkScrollable directive... doesn't solve the issue :(

Obviously, this component doesn't work well on iOS (using Safari, Firefox and Chrome).
Furthermore, I've tested on Chrome running on Android 7 and this is exactly the same.
So, I don't believe it's an issue due to a strange behavior on iOS because I've the same thing on Android.
Hope it will be fixed soon.

Having the same issue here!! Hope this fix soon!!

Faced with this issue,  provided solution with custom MAT_AUTOCOMPLETE_SCROLL_STRATEGY_FACTORY not worked for me due

error TS2345: Argument of type '{ imports: (typeof CommonModule | typeof Overlay | InjectionToken<() => ScrollStrategy>)[]; decla...' is not assignable to parameter of type 'NgModule'.
Types of property 'imports' are incompatible.
Type '(typeof CommonModule | typeof Overlay | InjectionToken<() => ScrollStrategy>)[]' is not assignable to type '(any[] | Type | ModuleWithProviders)[]'.
Type 'typeof CommonModule | typeof Overlay | InjectionToken<() => ScrollStrategy>' is not assignable to type 'any[] | Type | ModuleWithProviders'.
Type 'InjectionToken<() => ScrollStrategy>' is not assignable to type 'any[] | Type | ModuleWithProviders'.
Type 'InjectionToken<() => ScrollStrategy>' is not assignable to type 'ModuleWithProviders'.
Property 'ngModule' is missing in type 'InjectionToken<() => ScrollStrategy>'.

Angular - 5.1.0

Is this fixed? the samples on the site are fixed, I still experience it.

I have the same issue!
Anybody with a workaround solution??


FYI - WebSocket server may not respond on Android L dev release

Android L release on Nexus 7 seems to not respond on Websocket server hosting. Identical code on Android 4.4.4 and 4.3 releases do not seem to have this same problem.
For reference, https://github.com/koush/AndroidAsync Websocket Server does not seem to have this behavioral difference - works fine on all the same versions.  Tested clients: Firefox and Chrome.

duplicate of #424


allow specifying geometry color

Maybe one line of HTML5 color code sets the color of everything following it?

Closing in favor of #46


update Dropdown docs

Please make sure these boxes are checked before submitting your PR, thank you!

[ x ] Make sure you follow Element's contributing guide (中文 | English | Español | Français).
[ x ] Make sure you are merging your commits to dev branch.
[ x ] Add some descriptions and refer relative issues for you PR.

PR without descriptions and refer relative issues  will be closed directly.

提供一个单独的例子来展示 Dropdown 的 icon 配置是不是更合适一些？至少用分割线隔开一下。

现在的例子中有这个的介绍。http://element.eleme.io/#/zh-CN/component/dropdown#hong-fa-fang-shi
不必再添加了。


Help Menu Update

Hi 0xVavaldi
Please could the help menu (ruleprocessorY.exe -h) be updated to show all the new features?
Thank you.

This should already be the case if you built from source. The 'release' is slightly outdated


Inital setup of docusaurus

#3161
Added inital setup of docusaurus.
Missing files in docs:

README.md
PATRONS.md
CHANGELOG.md

Docusaurus requires docs to be placed in /docs. Should we move these files?
Also, since docusaurus currently does not support nested sidebars, I moved Structuring Reducers one level up in the sidebar.

Hmm.  Well, we can't move the actual README, because that's gotta stay at the root of the repo. PATRONS could be moved, and tbh CHANGELOG is kinda pointless.
Tell you what.  Let's not include PATRONS or CHANGELOG in the actual published docs.  Leave the files there for historical purposes, but no point in publishing them.
For the README... do we even want the entire README as a docs page itself?  I'm not sure we do.  Perhaps we should have a cut-down version of it in the docs.

Should we create an issue to cover what needs to be done?

Looks like Docusaurus just merged in the nested categories feature in https://github.com/facebook/Docusaurus/pull/892, and v1.4.1 should be out with that in the next few days.

What a great god damn effort @sveinpg :clap: :clap: :clap:

The only thing I don't like about this site so far: The sidebar position resets after navigating to a new page. If I'm way down at the API reference and click over from createStore to the Store, the sidebar is back at the top.
Also, for the "README", I'd like to see that be a "Getting Started" page that can replace the "Core Concepts" button on the front page. And that should contain just the bare minimum to make a store and dispatch actions. Simple and straightforward for those that don't want to read through many pages of docs 😄

@timdorr
There is a workaround for the sidebar scroll position
https://github.com/facebook/Docusaurus/issues/823#issuecomment-421152269

@sveinpg Hi there, Docusaurus maintainer here. We managed to get the subcategories feature shipped in https://github.com/facebook/Docusaurus/pull/1026 and you should be able to keep the subcategories for "Structuring Reducers". Could you point your Docusaurus version to trunk for the moment? If there are things that Redux needs but Docusaurus doesn't support we could do it over the weekend. Else if all is good, I'll release Docusaurus 1.5.0 over the weekend which will include the subcategories feature.
Let me know what you think! We're here to support Redux's migration to Docusaurus 😄

@yangshun How do I point my docusaurus version to trunk?

Docusaurus v1.5.0 has been released - https://github.com/facebook/Docusaurus/blob/master/CHANGELOG.md#150---2018-10-13
@sveinpg was trying out the trunk version yesterday and he showed me that the subcategories worked ok!

Thanks for your patience!
cc @markerikson @timdorr

Okay, I just took a look at the current contents.  It looks great!
I think this is more than sufficient to merge into the docs-rebuild branch, and we can open up some more issues to figure out what else actually needs to be done.
@sveinpg , thank you VERY much for some excellent work!


Lib ruamel.yaml version 0.15.55 will cause typing.Sequence[str] unsupported in option.

Based on release note of recent version 0.15.55  ruamel.yaml, it unmade CommentedSeq a subclass of list.
This will cause the sequence parsed from yaml file cannot be set to option whose type is typing.Sequence[str].

Thanks for the PR - I think this should already be fixed with ruamel.yaml 0.15.57.
Can you verify that?

Thank you for your info and sorry for giving feedback late.
I upgrade ruamel.yaml to version 0.15.64 which is the latest version when I add this comment. I found that the list option about ignore_host still cannot be loaded from yaml file which looks like:
ignore_hosts:
    - sample.com
    - sample1.com
BUT if version 0.15.54 is used, above option can be loaded as expected.

@guangchao0831 is right. This is tracked in #3321.


Improve Default Macros

Improve Default Macros
Description

Cleaned, organized and added documentation to both IPTraceMacroDefaults.h & FreeRTOSIPConfigDefaults.h.
Removed a few macros that were duplicated in FreeRTOSIPConfigDefaults.h.
Delete FreeRTOS_errno_TCP.h as all but pdFREERTOS_ERRNO_EAFNOSUPPORT have been included in projdefs.h for quite some time. A PR has been created in FreeRTOS-Kernel to add the last remaining macro. Until then, it resides in FreeRTOSIPConfigDefaults.h.
Created a new file, FreeRTOSIPDeprecatedDefinitions.h, that contains the checks for usage of deprecated macros. This is similar to FreeRTOS-Kernel's deprecated_definitions.h.
Added a few missing deprecated macro checks to FreeRTOSIPDeprecatedDefinitions.h.
Include IPTraceMacroDefaults.h in FreeRTOSIPConfigDefaults.h below the tracing enabling macros and removed all inclusions of IPTraceMacroDefaults.h elsewhere. This ensures the tracing enabling macros are always defined before including the tracing implementation macros.
Removed some unused deprecated macros (i.e. ipconfigRAND32) from the tests' FreeRTOSIPConfig.h files.

Test Steps

N/A
Checklist:

[x] I have tested my changes. No regression in existing tests.
[x] I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

N/A
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/bot run uncrustify

I've decided to reduce some of the redundant wording of some documentation and add checks for the values that are expected for each macro. I've done about half of it so far.

@holden-zenith : thank you for merging and editing my suggestions.

add checks for the values that are expected for each macro

Good idea, thank you

Hi @holden-zenith
Can you please let us know if you are still working on updating the PR.

@moninom1 I had intended to go back to account for all the other code changes but I just haven't had the time to get to it.

@holden-zenith Thank you for the Update.
Can we help in some way to bring this to completion? We have added build separation recently and hence this PR has a lot of conflict. I tried rebasing your change over latest tip but seems like there were a lot more compilation issue. Wanted to check with you first if there are any pending change you are planning to do on this PR, it yes can we move it to draft for now?
Also i see other PR804 , PR747 and PR435 in draft, do you need any help from our side on to review these PRs?

@moninom1 I've finally gotten to a point where I might have some time available to bring this PR up to date. 804 I'm waiting for some hardware to come in to finish. 747 I'm not sure of how you guys feel about this one but I personally felt it beneficial to merge the files into one and just have a config macro change the method used. Seems beneficial to know which method the user is using and eliminates duplicate code that will fall out of sync.

Hi @holden-zenith
Thank you for the update.
We would also like to let you know We will be closing the merging window for dev/IPv6_Integration branch by the end of this month. This is for starting all the verification and testing for the RC3 release and further GA release.
Can you please let us know if you will be able to update the change before the freezing windows?

@holden-zenith Its great to know. Thank You so much for the update.

@moninom1 so here's a question, I had originally defined all macros related to functionality only if that functionality was enabled. For example, ipconfigDNS_CACHE_ENTRIES is only defined if ipconfigUSE_DNS_CACHE is enabled. I did this to help find usage of these macros that aren't guarded by an enabling macro (as they shouldn't need to be checked if the functionality isn't even enabled), but these are what are causing the build errors. Should all macros just be defined regardless or should I go back and define out the areas that shouldn't be/aren't used when certain functionalities are disabled?

HI @holden-zenith

I had originally defined all macros related to functionality only if that functionality was enabled
Ideally this is the right way.
Regarding ipconfigDNS_CACHE_ENTRIES i can see it is only used in FreeRTOS_DNS_Cache.c which is guarded by both the flags

if ( ( ipconfigUSE_DNS != 0 ) && ( ipconfigUSE_DNS_CACHE == 1 ) )

Rest it is only at FreeRTOSIPConfig files. Where is this error coming from for you?
Is ipconfigUSE_DNS_CACHE the only macro giving error? Or there are more such issues?

@moninom1 I only gave that as an example, I don't think that was one of the ones giving issues. There were a couple related to DHCP, but I'll check again tomorrow.
Also I tried testing using the added cmake tests but they don't compile due to multiple issues unrelated to my PR so I've gone back to the manual way. Is it just me with this issue?

HI @holden-zenith
Is there any update on the changes? FYI we have merged the dev/IPv6_integration branch back to main so we can update the change to merge to main.
Thank you

Hi @holden-zenith
Is there any update on the above PR, we are working on GA release prerequisite and would like to know if the change can be merged for GA. Thank you.

@moninom1 Considering this is the type of PR that is best merged after all major changes have been made and all required macros are used/defined, if there are no other major changes planned then I can attempt to resolve the issue with the macros I had mentioned earlier. I worry doing it the 'proper way' could get a little more convoluted than I had planned for this PR as I didn't really want to make any non-trivial code changes outside of the config files but I can check it out and see what will be required now.

Hi @holden-zenith
The Major changes are completed and we are working on bug fixes, We are planning to close the merge window by next Tuesday and as the release is previously committed we are strictly following the dates. We will merge the changes if it is ready by then. Thank you

/bot run uncrustify

I didn't want to touch too many files in this one PR, so I have reverted unnecessary changes that can be handled at a later time.

/bot run uncrustify

Hi @holden-zenith , Thank you for the update, would you please help in moving the changes to main instead of dev/IPv6_Integration as we have merged the branch back to main, We can also contribute to help fix issues as @ActoryOu  suggested once it is moved to main.

@ActoryOu @moninom1 Something that I think is beyond the scope of this PR but has become very noticeable because of it is the widely varying data-types that are used for the same macros that creates the need to cast in many areas. While I think it is unnecessary to make a macro definition for the data-type of each, some effort should probably be made to consolidate this throughout the codebase.

Super appreciate your help!

it is the widely varying data-types that are used for the same macros that creates the need to cast in many areas.

I can't understand the first point completely.
Could you help to provide an example of it?

There's also the issue of not being able to run checks on macros that are casted in the definition via the compiler, so perhaps it would be better to move all checks to vPreCheckConfigs?

If the macros are not able to check during compilation, then we can move them to vPreCheckConfigs. Is it possible to list them down?

Hi @holden-zenith,
Thanks for explaination.
For the first part, I believe the original code should have casted it, so that we can pass compilation without warnings.
So I suggest that we don't need to handle that in this PR.
For the second part, no worries about the xMPU_SETTINGS issues for now, either. We're skipping those part by /* LCOV_EXCL_BR_START */ and /* LCOV_EXCL_BR_STOP */.
Thanks for the update. I'll try to look into it this week.

Thanks, I believe the last issue is just the proofs. I temporarily disabled the FreeRTOS_TCP_Utils_IPV6_ConfigLowTCPMSS_utest because it shouldn't be necessary if a low value is handled by a compile error now, and the FreeRTOS_Sockets_DiffConfig1 tests which use test_FreeRTOS_socket_TCPv6SocketLowMSS.
Also, in regards to the first part in the last comment, I was just mentioning that the down-casting would produce unforeseen issues if the config values were not limited to that data-type size. But I'll just let someone else handle that later on.

Hi @holden-zenith,
I've fixed unit-test and proof_ci in your repo.
Here is the summary of my change:

Remove length check in FreeRTOS_Sockets.c and FreeRTOS_TCP_Utils_IPv6.c.

ipconfigTCP_MSS is guaranteed to be not less than 586 in FreeRTOSIPConfigDefault.h, so it's unnecessary to check that in runtime.

Remove redundant unit test cases. (Since ipconfigTCP_MSS is guaranteed to be not less than 586)
Set ipconfigTCP_MSS to minimum in some proof_ci test cases.

proof_ci is the test to test code with any possible input, it's fine to set ipconfigTCP_MSS greater than network MTU size in this test.

Yeah checked it seems fine. Good cleanup of UTs - FreeRTOS_Sockets_DiffConfig1  and FreeRTOS_socket_TCPv6SocketLowMSS test

Hi @holden-zenith
I have left some comments, will you be updating accordingly? If you are fine with the comments let us know, i can create a patch for it. Thank you

Hi @holden-zenith , I have reviewed and updated a commit for some updates in MACRO comments. I will now work on running coverity as pushing if any change needed accordingly.
Meanwhile can you please you please cross check the change and help in rebasing your tip to main. Thank you

@moninom1 I am on vacation for the next couple of weeks but I will do whatever is needed afterwards.

Hi @holden-zenith
I tried rebasing the PR to main, but as a lot of changes have merged from the last rebase, it has become a bit complex to rebase. Also there are a lot of whitespace changes in most of the c files which i do not think are needed now. It would be much easier to create a new patch on the latest tip with just the required changes {Skipping all the whitespace changes}. I can help you with that, but if you want to do that so that the commits are under your name we are fine with it.
Let us know what do you think about it.

@moninom1 uncrustify ran for some reason without being intentionally triggered. Just need to revert that. I never really made any changes to the source files.

Hi @holden-zenith
I tried to rebase this branch in my repo .
But as a lot of changes have went in already [mainly this PR ] the change is becoming very big, i would prefer we add the commits over current tip to reduce the amount of changes and keep the PR clean and to the point. Please let me know what do you think.

I removed some stuff, it should be easy to rebase now

Yes i think cleaner solution would be to create a new PR. Let me know if you need any help. Thank you

Hi @holden-zenith
I see the PR is closed. Are you working on the new PR?

Sorry yes, I will get to it soon.

Hi @holden-zenith
I have updated the changes according to Hein's comment, can you please take a look?

Hi @holden-zenith , I do not understand the reason of dismissing the review request? It was just rebased. Do you see any issue?

@moninom1 Seems like that is due to a new change in github here

Hi @holden-zenith,
Do you have any clue to solve this? It seems like system dismisses our approvals automatically.
Or could you help to re-create PR?
Thanks.

Seems other people are experiencing the same issue here, I tried one of their solutions so let's see if it works.

Hi All, Please do not merge the change, i am seeing issue in Jenkins run, will check them and update in a while. Thanks

The above change is merged, so merging this as well. Thank you


hdl-dump: init at 20202807

Motivation for this change
Things done

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

[ ] 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/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

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

1 package marked as broken and skipped:

hdl-dump

@AndersonTorres  Thanks for picking up my contribution, i didn't have had much time to fix my PRs so i am glad you did :+1:


chore: jsonfmt redis

Ran jsonfmt -w "specification/redis/**/*.json"

Automation for azure-sdk-for-python

Automation for azure-sdk-for-java

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-go

Can one of the admins verify this patch?

Automation for azure-sdk-for-js


support optionally adding attributes

[x] implement in rsx macro
[x] update docs

#530

Thinking about this some more...
It might be better to allow creating attributes from a impl IntoIterator<(Attribute, Value)>. This would allow optionally adding props and make it more ergonomic to dynamically create many different attributes. You could have a single &'static [(Attribute, Value)] array and insert it into a element to get a style. Or use a Vec<(Attribute, Value)> to more easily integrate with a library that generates html.

With the changes in #600 we can do one of two things

allow all Option in attribute positions without the custom syntax
Use the question mark syntax to use the same code pathways as #1 but be explicit about it

I kinda think #1 is better than #2 since the parsing is more consistent. We have a new attribute type called "None" - and could even have a list of attributes as you mentioned above. I'm not sure if None is wired up to properly remove the attribute from the dom, so if we revisit this PR, then we might need to add that.

Closing this in favor of a new PR after the rewrite of core.
Option 1 is implemented in #708


Rename existing solvers

General description of task

Class names of solvers are not following a consistent convection, e.g., minimize and LS
Unit tests for several solvers are missing

Definition of Done (Feature/change)

[x] Rename relevant solvers

L_BFGS_B -> ScipyLBFGSB
minimize -> ScipyMinimizer
maximize -> ScipyMaximizer
LS -> ScipyLeastSquares

[x] Any calls on relevant solvers are updated
[x] Add unit tests for solvers

Definition of Done (Mandatory)

[x] Documentation added (docstrings on all public methods/classes)
[x] Unit tests added/updated (and passing!)
[ ] Code reviewed and approved by 2 CUQI-maintainers
[x] Online documentation is rendered correctly (esp. math)

Defintion of Done (Optional)

[ ] HowTo/tutorial added

Hi @jakobsj, could you review the DoD here?

Thanks @chaozg I think everything makes sense, would like one addition namely to go through existing code base and make sure to update any calls to solvers to use the new names. May be covered by the "Rename" task but better to be explicit so that it is clear it has been done. If you agree, then with that DoD is approved.

Thank @jakobsj . All calls to the relevant solvers have been updated and I just made it clear in the DoD.


Game crashes when invalid 'map.txt' set

if map size in 'map.txt' is bigger than game map size, game will crash

fixed in latest release


Test/nav 49 more test circulating overlapping self intersecting routes

Added more test cases for raptor class.

Closed because also part of NAV-59 pull request.


RFC: Overhaul Cargo's build command support

This RFC is targeted at overhauling the build command in Cargo manifests to be
more robust and fully functional for building and linking native code. While
largely targeted at Cargo, this RFC includes a few minor changes to the compiler
itself, hence posting this RFC in this repository.
The high level summary of this RFC is:

Instead of having the build command be some form of script, it will be a
rust command instead
Establish a namespace of foo-sys packages which represent the native
library foo. These packages will have Cargo-based dependencies between
*-sys packages to express dependencies among C packages themselves.
Establish a set of standard environment variables for build commands which
will instruct how foo-sys packages should be built in terms of dynamic or
static linkage, as well as providing the ability to override where a package
comes from via environment variables.

Rendered

0507-release-channels.zip
rustup-init.zip
0507-release-channels 2.zip


Daily Debrief for monday

Here it is
day 1 slides  2.zip

I can't open this file, please resend as a .pdf,
thanks

day 1 slides  2.pdf


Better customizability of Prop Fields/Sections

It would be great to have better control/flexibility of the styling of the prop field sections without having to reimplement them from scratch. I'm passing along some feedback from one of our designers for what she's looking to do.
I know there are already some issues in this realm that this would probably encompass - https://github.com/measuredco/puck/issues/686
https://github.com/measuredco/puck/issues/666
// comments

// alternate design as an idea for how we'd want to customize the style

Hey @mkilpatrick - those spacing irregularities look like implementation issues rather than Puck issues. Happy to help debug them if you can share the code.
The designs you're sharing are pretty different from the OOTB fields, and as such I'd expect them to be reimplemented. However, I'm definitely open to the idea of a more streamlined props field design baked into Puck in the future.


Lack of Examples

Could you give examples such as getting games from dota2 with certain heroes?
Or just more examples in general?

I know this is really late, but just in case someone new sees this:
You can find the whole list of api calls here: https://github.com/jonbo/node-steam-webapi/blob/master/api_method_list.md

Yeah another year later, but be warned the examples on the front lie. You must do Steam.INTERFACES[interface].func(), not Steam.func(). Best to log out Steam to see the interface.


Pass through the architecture on OS X

This allows nox to test on both 32-bit and 64-bit architectures.
With a Python script that is architecture aware (check.py) it's possible to write a nox config that sends along the "correct" arch -32 prefix for commands. (Unfortunately prepending arch -32 to a command doesn't show up in sys.argv.)

Running it with my magic trick turned on does the right thing:
$ /Library/Frameworks/Python.framework/Versions/3.6/bin/nox -s 'check(do_hack=True)'
nox > Running session check(do_hack=True)
nox > /Library/Frameworks/Python.framework/Versions/3.6/bin/python -m virtualenv ...
nox > chdir ${HOME}/nox-bug-report
nox > arch -64 python check.py
Architecture: 64-bit
      Prefix: ${HOME}/nox-bug-report/.nox/check-do_hack-true/bin/..
 Real prefix: /Library/Frameworks/Python.framework/Versions/3.6
nox > Session check(do_hack=True) was successful.
$
$ # Re-use
$ arch -32 \
>   /Library/Frameworks/Python.framework/Versions/3.6/bin/nox -s 'check(do_hack=True)' -r
nox > Running session check(do_hack=True)
nox > Re-using existing virtualenv at ${HOME}/nox-bug-report/.nox/check-do_hack-true.
nox > chdir ${HOME}/nox-bug-report
nox > arch -32 python check.py
Architecture: 32-bit
      Prefix: ${HOME}/nox-bug-report/.nox/check-do_hack-true/bin/..
 Real prefix: /Library/Frameworks/Python.framework/Versions/3.6
nox > Session check(do_hack=True) was successful.

Running it in the default mode for nox doesn't pass through the architecture
$ /Library/Frameworks/Python.framework/Versions/3.6/bin/nox -s 'check(do_hack=False)'
nox > Running session check(do_hack=False)
nox > /Library/Frameworks/Python.framework/Versions/3.6/bin/python -m virtualenv ...
nox > chdir ${HOME}/nox-bug-report
nox > python check.py
Architecture: 64-bit
      Prefix: ${HOME}/nox-bug-report/.nox/check-do_hack-false/bin/..
 Real prefix: /Library/Frameworks/Python.framework/Versions/3.6
nox > Session check(do_hack=False) was successful.
$
$ # Re-use
$ arch -32 \
>   /Library/Frameworks/Python.framework/Versions/3.6/bin/nox -s 'check(do_hack=False)' -r
nox > Running session check(do_hack=False)
nox > Re-using existing virtualenv at ${HOME}/nox-bug-report/.nox/check-do_hack-false.
nox > chdir ${HOME}/nox-bug-report
nox > python check.py
Architecture: 64-bit
      Prefix: ${HOME}/nox-bug-report/.nox/check-do_hack-false/bin/..
 Real prefix: /Library/Frameworks/Python.framework/Versions/3.6
nox > Session check(do_hack=False) was successful.

Running this with the wrong Python binary is a "not gonna happen":
$ arch -32 ${HOME}/.pyenv/versions/3.6.2/bin/nox -s check
arch: posix_spawnp: ${HOME}/.pyenv/versions/3.6.2/bin/nox: Bad CPU type in executable

This is relevant because it might mean you don't have to check if the Python binary is_dual_architecture().

I think the idea of preserving the arch through all commands is the right thing to do, but what's the right way to do it?

I think the "right" way is:
$ arch -32 ...
$ arch -i386 ...  # Synonym for -32
$ arch -64 ...
$ arch -x86_64 ...  # Synonym for -64

as a prefix to literally everything we execute?

Only on OS X, but maybe? It's possible there is a way to "inherit"?

It's possible there is a way to "inherit"?

That would be ideal. It seems weird to me that a 32bit process is able to create a 64bit subprocess (considering exec is forking).

It turns out a similar feature might be relevant on Windows:
C:\Users\dhermes\Desktop>py -2.7-32 info.py
exe: C:\Python27-32\python.exe
sys.maxsize == 2**(31) - 1

C:\Users\dhermes\Desktop>py -2.7 info.py
exe: C:\Python27\python.exe
sys.maxsize == 2**(63) - 1

C:\Users\dhermes\Desktop>py -3.5-32 info.py
exe: C:\Users\dhermes\AppData\Local\Programs\Python\Python35-32\python.exe
sys.maxsize == 2**(31) - 1

C:\Users\dhermes\Desktop>py -3.5 info.py
exe: C:\Users\dhermes\AppData\Local\Programs\Python\Python35\python.exe
sys.maxsize == 2**(63) - 1

C:\Users\dhermes\Desktop>py -3.6-32 info.py
exe: C:\Users\dhermes\AppData\Local\Programs\Python\Python36-32\python.exe
sys.maxsize == 2**(31) - 1

C:\Users\dhermes\Desktop>py -3.6 info.py
exe: C:\Users\dhermes\AppData\Local\Programs\Python\Python36\python.exe
sys.maxsize == 2**(63) - 1

@dhermes it seems with #100 this is no longer relevant, am I missing something?

So what needs to be done for OS X? Is 32bit even relevant for OS X?

I don't really think so. NumPy has dropped support for 32-bit binaries on OS X.

I'm going to close this, then.


Wisher: Remove the condition question from the intake workflow

Remove condition question in the intake workflow
Currently, it is:
Hi CHILD_NAME, I have a few questions for you before we can make your wish come true!
Where are you from?
Tell us about your condition
Tell us more about your wish!

@alex-hall can you edit the issue to provide more context of what this is?

I've made this code change, but the current application asks what the child's condition is. We should talk to the make a wish folks, but they mentioned not capturing that information in the app, but rather offline with the parents

Note: The condition question doesn't require an answer (can just skip by clicking Next)

@alex-hall had some conversations with @hellonoosh about this. We are thinking about making it either "what hurts?" or just skip it all together, and let the parents/guardians add this information later.

Can I work on this ?

Please do! Our contributing guidelines are here: https://github.com/homedepot/infinite-wish-board/blob/master/CONTRIBUTING.md

Resolved via #117.


cubic spline is not smooth

The following code results in a very jagged plot of the interpolated spline:
using Interpolations
using PyPlot
x = 1:5
y = sin(2*x)
itp = interpolate(y, BSpline(Cubic(Natural())), OnCell())
xi = linspace(1,5,200)
yi = Float64[itp[t] for t in xi]
plot(x,y,"ro")  # Plot the knots as red circles
plot(xi,yi)  # Plot the interpolated cubic spline

I understand that I'm under-sampling the sine function, but nevertheless I expected to get a smooth interpolant.  Plot is shown below.  Am I misunderstanding something or is this a bug?
Thanks,
--Peter

What happens with OnGrid? In general, the most natural formulation is OnCell for even orders and OnGrid for odd orders.
I wonder if we should make this the default, since I doubt we systematically support both OnCell and OnGrid for all possible combinations of orders and boundary conditions.

Here is the result for OnGrid:  The curve no longer interpolates the knots.

very odd. I thought it might have to do with too few interpolatino points and an poorly-conditioned matrix. but with 20 points, the same.

This is a bug, probably in the implementation of prefiltering_system(::Type{T}, n, ::Cubic{Natural}, ::GT). I might be able to take a look at it this weekend, but you're very welcome to submit a patch if you find it before me :)
Re: OnCell vs OnGrid, the distinction is only relevant to quadratic and higher for anything else than bounds-checking, and I don't think it's unrealistic to support both for the boundary conditions we implement. (We still need to improve the test suite, obviously...)

What does @which Interpolations.define_indices(BSpline{Cubic{Natural}}, 1,1) say on your machine? What about macroexpand(:( Interpolations.define_indices(BSpline{Cubic{Natural}}, 1,1)))?

@simonp0420, @floswald Also, if you do Pkg.update(), what does Pkg.status() say after that? Does it still reproduce?
On latest master, I can't reproduce this; my plots look fine both for OnCell and OnGrid. I wonder if this is just the problems hinted at in #99 which have been fixed on master but maybe not on your local copy.

julia> using Interpolations

julia> @which Interpolations.define_indices(BSpline{Cubic{Natural}}, 1,1)
define_indices{IT}(::Type{IT}, N, pad) at c:\home\simonp\.julia\v0.4\Interpolations\src\b-splines\indexing.jl:7

julia> macroexpand(:( Interpolations.define_indices(BSpline{Cubic{Natural}}, 1,1)))
:(Interpolations.define_indices(BSpline{Cubic{Natural}},1,1))

After a Pkg.update() there are no changes to anything but NaNMath.  Pkg.status() gives
...
 - Interpolations                0.3.4
...

and the problem persists.

After doing Pkg.checkout("Interpolations") the problem is gone for both OnCell and OnGrid :-)  Thanks for the tip.

Time to tag a version, then :) Thanks for reporting back!

:+1:
On Sunday, 13 March 2016, Tomas Lycken<EMAIL_ADDRESS>wrote:

Time to tag a version, then :) Thanks for reporting back!
—
Reply to this email directly or view it on GitHub
https://github.com/tlycken/Interpolations.jl/issues/108#issuecomment-196021001
.