High GC pressure causing slowdowns (was: gzip awfully slow)

1. What version of Caddy are you running (caddy -version)?
Caddy 0.8.2
2. What are you trying to do?
Simply running a comparison between my own, simple Go web server and Caddy in various modes.
My tests were run with https://github.com/rakyll/boom:
boom -n 10000 -c 100 http://mysite/index.html

3. What is your entire Caddyfile?
<IP_ADDRESS>:8080
root /somewhere
log /var/log/caddy.log
gzip

4.  What did you expect to see?
A total execution time of the test somewhere around 12s±5%, which is the speed it takes for my own Go server to respond to the test when set up to serve from disk with gzip enabled (which SHA256 and gzips the content on every request).
6. What did you see instead (give full error messages and/or log)?
A total execution time of 39.6s±5%. That's a lot. The same run against Caddy without gzip enabled on the server takes 6.8s±5% in comparison. That's 3 times slower than my server, and while I suspected that my server would be faster, I had thought a few percent, not factor 3.
I don't use Caddy myself, but I thought I'd give you a heads up about my findings. I have not investigated why Caddy is so slow in this case, but it should be possible to get similar speeds to my server, which isn't magic when serving data from disk.

Can you run your test again without the log directive? I feel like that's going to add noise to your tests.

A single run with gzip, but without access logs: 37.72s. Also note that the non-gzip run at ~6.5s also included access logs.

(But as a performance test against my own server, I wanted it to include access logs. Otherwise, it wasn't comparing real setups.)

Something I just noticed: Caddy uses level 9 by default, not the gzip packages default. For the 10KB input file, Caddy outputs 4498 bytes, while the default level my own server uses output 4563, which is quite an almost unnoticeable difference. I'll try to run with Caddy set to a lower level, although the docs don't seem to state exactly what the default level is...

Thanks for trying a few things. We'll look into this soon, unless somebody wants to dive deeper sooner. (I haven't spent a lot of time in optimizations yet since I'm still trying to get the code base stable.)
I agree we probably don't need the highest compression level; could someone do some profiling (pprof?) and see where the CPU time is spent?

ISTR that gzip level 5 or 6 was where it was tuned for speed vs. content
size tradeoff.  At level 9, it's going to be a lot slower.
-Toby.
On Sat, Apr 9, 2016 at 12:49 PM, Matt Holt<EMAIL_ADDRESS>wrote:

Thanks for trying a few things. We'll look into this soon, unless somebody
wants to dive deeper sooner. (I haven't spent a lot of time in
optimizations yet since I'm still trying to get the code base stable.)
I agree we probably don't need the highest compression level; could
someone do some profiling (pprof?) and see where the CPU time is spent?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/mholt/caddy/issues/735#issuecomment-207843261

@joushou What was the payload you used to get those 30 seconds?

@xenolf: my index.html (from https://kl.wtf/). 10KB html, gzips to about 4.5KB. Nothing special.
@weingart: I tried 6 in a config mention in a prior comment, which I found to be the Go default, which is what I use in my own server. I didn't see a change in time nor filesize, so maybe the setting is broken?

@joushou I used the caddyfile you provided as well as your index.html to run several test using the boom settings you supplied.
I failed however to come anywhere near the numbers you are reporting at all. Not even when enabling CPU profiling. The numbers are stable at around 12 seconds.
The tests were executed using Go 1.6 on a 4 core x64 debian 8.2 machine with an allocated 8 GB of ram with caddy 8.2 as well as the latest master.

@joushou Levels 6 and 10 are known to have ~equivalent compression ratios for most things. Also, 10 KB is hardly large enough of a file to see much of a difference in compression time by using a benchmark done over the network.

I think there is something else going on here.  Possibly boom is not reading the whole body, and ends up doing a re-connect with gzip, but not without it?

@weingart boom does not have this behaviour when running against my own server when it serves gzipped content from memory (which is its normal operating mode), where the test completes in ~3.5s. This is not a fair comparison with Caddy, so I used a from-disk folder on my server, which causes it to read the file and gzip on every request, to compare similar workloads. In this case, my server completed the test in 12s yesterday.
@mholt Yes, but there is a slight difference in the compression from caddy set to level 6 and my own server at Go's default, which is level 6. Not big, the downloaded file should be exactly the same, no?
@xenolf now that is peculiar.
I set up another Linode 1024 in frankfurt, which is identical to the server I used initially. One peculiar thing is that they behave quite differently. Tested today against both boxes:
Old box:
   minihttp: 16.3s (was 12s over several runs yesterday)
   Caddy:    26.7s (was 37s over several runs yesterday)

New box:
   minihttp: 20s
   Caddy:   25s

Same VPS type and dist, and apart from a bit user configuration, the servers are identical with nothing else running on them. I suppose the loads the host is seeing is different, but I cannot quite explain why the gap is consistently lower on the new box. it runs the same binaries, serving the same file, after all.
I'd like to provide you with the address for both, as well as login for the new box in case you would like to verify against my test conditions. Any place I can send you the info in private?

With the odd way these numbers behave, I would lean to say that this is a user error, but the numbers are at the same time consistently slower for the old box, even if the numbers seem to change from day to day. I'm not sure what to make of this.

@joushou Sure, you could message me on gitter if that's fine with you.

Ah, I made a small mistake in the new server configuration: I pointed Caddy at a non-existing directory. The 25s was therefore the time to serve a 13 byte error message, not the gzipped response. I'd say that this is still a LONG time to serve an error message, but that's an issue for another day!
Pointing Caddy to the proper directory replicates the >30s response times.
@xenolf Yup, fine by me.

I used the box provided by @joushou to run a profile on. The profile showed that the problem has nothing to do with the GZIP code at all. The GZIP code performs comparable between the two.
The underlying issue seems to be high GC pressure caddy is generating under these circumstances which shows especially on a low end box. I will investigate further.

The difference in behavior between these two servers comes from the way how both handle files internally.
Caddy streams files using FileServer from disk. This causes many small reads / copies as it is reading chunks of data from disk and then GZIPing those chunks which increases GC pressure due to small allocations.
minihttp on the other side reads the whole file in one go and is then GZIPing the whole buffer.
The second approach will indeed perform much better overall while handling small files and especially so in a low performance environment as it is less punishing on resources.
However, the more you increase file size, the more this approach suffers in both raw performance as well as in memory consumption and response time. The approach of minihttp has by definition a much higher time to the first byte sent while caddy is able to respond right after the first chunk was gzipped.
To conclude my thoughts... The approach minihttp takes shows that it vastly outperforms chunk based streaming for small files where caddy is using the better option for larger files. The optimal solution to this would involve taking a middle way where we implement our own "FileServer" and set a certain size threshold for the chunk based file serving and files smaller then this threshold get read into memory and GZIPed as a whole.
Now on to some charts...
Please keep in mind that the following graphs and numbers are coming from a microbenchmark which in no way is representative of actual application performance but are here to illustrate the difference in implementations.
The machine used was a dual core x64 archlinux box with 16GB of RAM as well as the following configurations for caddy / minihttp:
Caddyfile
<IP_ADDRESS>:8080
root root/
log caddy.log
gzip

minihttp.toml
root = "./web"
logFile = "minihttp.log"
logLines = 16384

[http]
        address = ":9090"

For minihttp, the "fancy folder" feature was used to reload the file from disk on every request to get a near even playingfield.
1MB File
Increasing the file size to 1MB already shows this in caddy outpacing minihttp in req/s as well as memory consumption. Please keep in mind that req/s here mean HTTP 200 responses from the server, not a fully received file.
Caddy used ~150MB of ram while doing ~300 req/s

⇒  ./wrk -H "Accept-Encoding: gzip" -t 100 -c 100 -d 60s http://<IP_ADDRESS>:8080/index.html
Running 1m test @ http://<IP_ADDRESS>:8080/index.html
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   349.55ms  240.02ms   1.89s    73.74%
    Req/Sec     4.03      3.47    50.00     83.07%
  18142 requests in 1.00m, 101.62MB read
  Socket errors: connect 0, read 0, write 0, timeout 5
Requests/sec:    301.87
Transfer/sec:      1.69MB

while minihttp goes up to ~200MB while doing ~163 req/s.

⇒  ./wrk -H "Accept-Encoding: gzip" -t 100 -c 100 -d 60s http://<IP_ADDRESS>:9090/f/index.html
Running 1m test @ http://<IP_ADDRESS>:9090/f/index.html
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   617.89ms  359.71ms   1.99s    67.67%
    Req/Sec     2.00      2.27    20.00     87.98%
  9805 requests in 1.00m, 55.45MB read
  Socket errors: connect 0, read 0, write 0, timeout 25
Requests/sec:    163.14
Transfer/sec:      0.92MB

2MB File:
Caddy:

minihttp:

Excellent analysis, @xenolf. Thanks for diving into that while my local copy of Caddy is all gutted out :smile:
I think our current approach is probably best for the general case: Caddy won't crash with high memory usage because it remains fairly constant thanks to streaming. As noted, it does increase allocations significantly with lots of little gzipping going on. A caching plugin could be written which stores small files in memory. There is discussion about that in #10 that we need not duplicate here.
With that properly implemented, we can achieve a good balance of both scenarios: judicious memory use and higher speeds.
@joushou Thanks for bringing this up; would love to have help with your expertise in implementing such a middleware. Again, issue 10 is a good place to take that discussion.

@xenolf thanks for your analysis. I had not put much thought into the fact that I zip in one go at all. I do so mainly because I'd like better Etags (sha256), as well as to partially reuse the mechanics for from-memory serving. The fancy folder from-disk thing was a hack I made when I had to upload a 20MB fil - I never intended to do anything from disk. :)
One note: would the microbenchmark be affected by the additional work involved with the SHA I run on those 1/2MB tests? They're done up front for in-memory payloads, but recalculated constantly for from-disk... If a benchmark of the file reading technique, not the server is of interest, the call to sha256.Sum256 in resource.updateAll could be killed. I suspect it artificially increases the time-to-first-byte noticably, and that for a few MB size files, that the main issue becomes high memory consumption.
If not mistaken, writing a fileserver that just used larger chunks would fix this without having multiple pathways. Say, reading into a 512k slice, sending it along the chain when full or io.EOF. It is, of course, just an implicit threshold. Maybe a middleware that pauses to increase chunk sizes would even so the trick, albeit not as optimally.
I take it that my server for testing is no longer needed?

@mholt I'll take a look. It won't be as simple as minihttp, as minihttp is essentially a cache with infinite cache time, wheras a middleware might have to act more like a full caching proxy (just a very close one) to not mess with lower layers, which would require them to state their cachiness properly. Either that, or something more custom with a few knobs in the caddyfile that can easily be set very wrong...
There are only 3 hard problems in computer science: Cache invalidation and naming things. :)

@mholt another note while on the train: I suspect that this is not really isolated to gzip. I have not seen the profile, but I suspect that gzip jus magnified the issue enough that my small test machine could not keep up. The smaller the chunks the higher the overhead - more object allocations, more middleware roundtrips that might allocate on their own, net/http runs and syscalls. The larger chunks the better, up to some magic threshold. There's a big dfference between 4K chunk writes and 256/512K chunk writes, and I believe that this issue should be considered seperate from lack of cache, despite that a cache will hide it.

@joushou It's possible. Best I can tell so far, the buffer size is 32 KB (http.ServeContent calls io.CopyN which calls io.Copy which calls copyBuffer) -- although a custom-sized buffer can be used, I'm not sure how to change it at a level as high as gzip or net/http. Anyone know how to do this?
Also, not sure about the SHA performance; you'd have to profile/bench that.

Changing that chunk-size requires opening an issue against http.ServeContent to use io.CopyBuffer directly, in order to permit custom buffer sizes. The fix from Caddy's side is not to use http.ServeContent, which is the solution @xenolf mentioned: A custom file server. I believe the issues will show with any middleware that must process content, and is likely to also cause issues in the future with other middlewares and high-load scenarios.
An important aspect to note, however, is that a too big chunk size will cause high memory consumption and CPU time for people trying a DoS, but having it too low will cause even greater CPU time through excessive GC time. One must balance the thing. I would consider high GC pressure a problem, but the priority is entirely up to you.
As for SHA256, I was misreading some of @xenolfs numbers. I had erroneously seen the difference as being much smaller, so ignore that. SHA256 might not be the fastest hash in the world, but it's certainly not slow enough to compensate for huffman encoding over 992KB more data than Caddy does to get the first byte out the door. :)
Anyway, I'll experiment a bit with some techniques and chunk sizes inside minihttp for from-disk file delivery and report back with my findings. As for the cache, I might take a look at #10.

Okay, I have played with different things in minihttp. I suspect that the only difference in GZIP handling was that mine was terrible, causing poor performance overall. I have now implemented from-disk gzip serving using an io.Copy from the bare os.File into a gzip.Writer, which is the same as Caddy does inside of http.ServeContent. I do, however, not experience the same GC pressure on the tiny test machine @xenolf used for testing as Caddy does, but have instead gained a performance boost it seems.
Here are some tests with my new, Caddy-like handling (minihttp: 73d471a5fa19a814dae080a5544ffdd35fddacdf, Caddy: c21ff8343c8bb5d290002057c9ec322df59c18cf). The test is performed over a home internet connection to a VPS, but the numbers are stable. One thing of note is that I have twice the maximum latency for some reason, yet still a third lower average latency. Not sure of that is of any importance.
minihttp (10KB input):
wrk -H "Accept-Encoding: gzip" -t 100 -c 100 -d30s http://.../f/index2.html
Running 30s test @ http://.../f/index2.html
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   219.80ms  125.27ms 790.48ms   72.60%
    Req/Sec     5.62      3.41    30.00     74.78%
  14040 requests in 30.10s, 56.77MB read
Requests/sec:    466.42
Transfer/sec:      1.89MB

Caddy (10KB input):
wrk -H "Accept-Encoding: gzip" -t 100 -c 100 -d30s http://...f/index2.html
Running 30s test @ http://.../f/index2.html
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   328.92ms   82.95ms 449.60ms   83.36%
    Req/Sec     3.06      1.86    20.00     92.27%
  9067 requests in 30.10s, 36.99MB read
Requests/sec:    301.26
Transfer/sec:      1.23MB

minihttp (1MB input):
wrk -H "Accept-Encoding: gzip" -t 100 -c 100 -d30s --timeout 20s  http://<IP_ADDRESS>:80/f/blob
Running 30s test @ http://<IP_ADDRESS>:80/f/blob
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     6.70s     1.85s   12.58s    67.26%
    Req/Sec     0.00      0.00     0.00    100.00%
  394 requests in 30.11s, 444.35MB read
Requests/sec:     13.09
Transfer/sec:     14.76MB

Caddy (1MB input):
wrk -H "Accept-Encoding: gzip" -t 100 -c 100 -d30s --timeout 20s  http://<IP_ADDRESS>:81/f/blob
Running 30s test @ http://<IP_ADDRESS>:81/f/blob
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     8.36s   838.61ms  10.85s    66.23%
    Req/Sec     0.00      0.00     0.00    100.00%
  305 requests in 30.11s, 361.90MB read
Requests/sec:     10.13
Transfer/sec:     12.02MB

So, I don't think we have found the issue quite yet, but thanks for the hint to make my own from-disk file handling better. :)

I confirm a catastrophic performance loss (10x times compared with disabled gzip) in a setup with small (0.5k) files on very low-end machine (32 bit 4-core ARM Marvell Armada 370/XP, 2GB RAM). go version 1.7.4 linux/arm. Hope it will be fixed soon. Apart from that, thanks for great work!

It seems this doesn't affect everyone -- if this is affecting you right now, a decent workaround would be to pre-compress your static files and put them in your site with .gz extensions; Caddy will serve them automatically (no gzip directive required; placing the files there is enough).

It seems this doesn't affect everyone -- if this is affecting you right now, a decent workaround would be to pre-compress your static files and put them in your site with .gz extensions; Caddy will serve them automatically (no gzip directive required; placing the files there is enough).

Hey,
We encounter the same issue.
With caddy 0.9.5, we tried to serve a simple javascript (17Ko).
Caddyfile :
lc.iadvize.com:80 {
  root /space/iadvize.com/livechat/
  gzip {
    level 6
  }
  log off
  tls off

With gzip level 6 enabled
root@iadvizeweb01:~# hey -n 10000 -c 10  "http://localhost/iadvize.js"
684 requests done.
1370 requests done.
2068 requests done.
2776 requests done.
3488 requests done.
4185 requests done.
4881 requests done.
5567 requests done.
6259 requests done.
6954 requests done.
7657 requests done.
8352 requests done.
9040 requests done.
9737 requests done.
All requests done.

Summary:
  Total:	7.2252 secs
  Slowest:	0.0225 secs
  Fastest:	0.0016 secs
  Average:	0.0071 secs
  Requests/sec:	1384.0541

Status code distribution:
  [200]	10000 responses

Response time histogram:
  0.002 [1]	|
  0.004 [653]	|∎∎∎∎∎∎∎∎
  0.006 [2779]	|∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.008 [3076]	|∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.010 [2041]	|∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.012 [975]	|∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.014 [341]	|∎∎∎∎
  0.016 [106]	|∎
  0.018 [20]	|
  0.020 [7]	|
  0.022 [1]	|

Latency distribution:
  10% in 0.0041 secs
  25% in 0.0052 secs
  50% in 0.0068 secs
  75% in 0.0087 secs
  90% in 0.0107 secs
  95% in 0.0120 secs
  99% in 0.0147 secs

Without :
root@iadvizeweb01:~# hey -n 10000 -c 10  "http://localhost/iadvize.js"
6714 requests done.
All requests done.

Summary:
  Total:	0.7422 secs
  Slowest:	0.0107 secs
  Fastest:	0.0002 secs
  Average:	0.0007 secs
  Requests/sec:	13473.0568
  Total data:	168580000 bytes
  Size/request:	16858 bytes

Status code distribution:
  [200]	10000 responses

Response time histogram:
  0.000 [1]	|
  0.001 [8919]	|∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.002 [974]	|∎∎∎∎
  0.003 [65]	|
  0.004 [17]	|
  0.005 [14]	|
  0.006 [0]	|
  0.008 [1]	|
  0.009 [3]	|
  0.010 [3]	|
  0.011 [3]	|

Latency distribution:
  10% in 0.0003 secs
  25% in 0.0004 secs
  50% in 0.0006 secs
  75% in 0.0009 secs
  90% in 0.0013 secs
  95% in 0.0016 secs
  99% in 0.0023 secs

The ratio is huge, 10x between gzip enable or not.

@commarla I suggest using pre-gzipped/pre-brottlied files (https://github.com/mholt/caddy/pull/1289)

See #1618 - my best guess is that will mostly resolve most of the GC issue.


Add support for switch on string

See DimensionGeneratorSettings for an example, which currently looks like this:
      switch(s4.hashCode()) {
      case -1100099890:
         if (s4.equals("largebiomes")) {
            b0 = 3;
         }
         break;
      case 3145593:
         if (s4.equals("flat")) {
            b0 = 0;
         }
         break;
      case<PHONE_NUMBER>:
         if (s4.equals("debug_all_block_states")) {
            b0 = 1;
         }
         break;
      case<PHONE_NUMBER>:
         if (s4.equals("amplified")) {
            b0 = 2;
         }
      }

      switch(b0) {

The whole upper switch can be removed, and the lower switch should switch on the string.

The problem is that it affects the operation of Native Java and not the Forge API

What? This is clearly a decompiler artifact. This isn't Forge.. This issue tracker is for Decompiler artifacts.

Yes, cleaning up string switches like we do enum switches would be nice. Just not something i've looked into.
Looks like a simple pattern tho, two switched, 1st over var.hashCode with all cases setting var2. Then 2nd immediately after being over var2.

Added in 5132d2b6fe04a661ffa2d84df53a25ab13e78e62


Addition of dependabot.yml file

We need to add dependabot.yml file as it helps us to keep our dependencies up to date. Every day, it checks your dependency files for outdated requirements and opens individual PRs for any it finds.
@agamjotsingh18  please assign me this issue under gssoc'23.

@DivyanshiNarang currently the project is being shifted from cra to vite #167 only after this is finished we can add dependabot


[Task]: Add burning native token activity and burning direction

Task description
We should add a burning native token activity now that we can burn native tokens. This should also adapting the direction of activities to include a burn option.
Requirements
Add burn to direction of activities.
Add burn activity generation based on comparing inputs and outputs
Add burn activity generation directly from the burn transaction
Add burn to basic activity tile and popup
Creation checklist

[ ] I have assigned this task to the correct people
[X] I have added the most appropriate labels
[X] I have linked the correct milestone and/or project

Blocked until wallet.rs returns transactions with inputs AND outputs.


Add test for macos

See what happens when running on MacOS. refs #87

memo:
Because of .net7, the build task don't work.


Fix parent/child out of order mapping pushes

Addresses issue...
https://github.com/taskrabbit/elasticsearch-dump/issues/226
This is a pretty dirty hack and realistically I won't have time to clean this up, so this is more for visibility.
Is there a reason async isn't being used in this file already?

Hey! This isn't that dirty of a hack at all!  I'm going to merge it in here https://github.com/taskrabbit/elasticsearch-dump/pull/317

Thanks!


Log origin trial metadata

The blanket rule for all meta[http-equiv] tags is to put them first, but there's more nuance than that. Some origin trials alter the behavior or feature support of the page and their meta tags really would benefit from coming first. Other origin trials are less consequential.
To help differentiate between them and for developers to get a better sense of urgency if a super important OT is too low in the head, include some metadata logging.
@samdutton created this excellent OT debug tool, which includes a decoder function for the OT token:
function decodeToken(token) {
    const buf = base64decode(token);
    const view = new DataView(buf.buffer)
    const version = view.getUint8()
    const signature = buf.slice(1, 65)
    const length = view.getUint32(65, false)
    const payload = JSON.parse((new TextDecoder()).decode(buf.slice(69, 69 + length)))
    return {payload, version, length, signature}
}

It doesn't look like there would be any licensing incompatibilities if we integrated that into the tool with proper attribution.

Proof of concept


Align patterns and gradients to a grid

This changes improves alignment of canvas patterns and gradients, especially when working with vector tiles.
Before

After

This is achieved by aligning pattern origins to a grid of 512 css pixels, which is anchored to map coordinate [0, 0].

very nice!


Web form elements missing from Darwin Core Identification History mapping interface

Upon upgrading an old resource to 2.3.2 that has existing Darwin Core Identification History data mapped, the mapping interface for this extension is visually truncated (all mappings + save/delete/back buttons) with the exception of occurrenceID and filter are not visible), but these are all apparently present in the DOM. It seems terms discovered to be "redundant" (also present in the core) is preventing the display of these terms & it is unclear what would happen if this resource were now republished. Are we now expected to put identification history in the occurrence core? If so, this a significant mistake, imho and will be exceptionally difficult to do now that we already have a workflow that retains these 1:many relations in an extension.

Hi David,
I suspect I know what the problem is. Click the "Show all classes" filter in the sidebar. Hiding redundant classes is a feature added in v2.3. More information about the new filters on the mapping page can be found here: https://github.com/gbif/ipt/wiki/IPT2ManualNotes.wiki#data-mapping-detail-page
Please open a new issue, if you'd like to suggest an enhancement to this feature. I understand it is more bothersome to you than beneficial with this extension. Thanks.

D'oh! Apologies; turns out it was my own css/js/ftl customizations that caused my inability to show/hide these redundant mappings. I elected to not show the sidebar and as a consequence, this option was not visible to me. I'll know better next time...


#289 Update examples

Coverage remained the same at 86.809% when pulling 0c129200d0e1cfba51ca6fdb304ad1f3faf6f2dd on TPWDCEE-1206 into 6f427117857162c4b60457f175309faf5a9e75bf on master.


feat(pie-assistive-text): DSW-1590 added boilerplate code using the generator

Describe your changes (can list changeset entries if preferable)
[Added] - New pie-assistive-text component with boilerplate code

@LTurns please create a new label in Github for pie-assistive-text and add it to this PR before merging? :)

@jamieomaguire I believe Lizzie already added to .github/project-labeler.yml and that will only apply once we merge the PR.


RNIQ implementation

RNIQ (Random Noise Injection Quantization) method proposes novel approach to quantization, by modulating quantization noise during training process in order to achieve granular quantization.

#6


feat: ImageResize: total number of pixels as alternative to size

The first thing I would like to say is: Thank you very much for your work, the nodes are very useful
Is it possible to add the total number of pixels to the ImageResize node as an alternative to width and height?
The situation is as follows: we have an upscaler workflow on Suprim, we need to downscale if the image is larger than a certain size.
Using width and height in this case is less convenient than the total number of pixels - it greatly cuts images in 16:9 format, when based on the total number of pixels such images would pass without resizing.

can you use "only if bigger/smaller" option?

can you use "only if bigger/smaller" option?

yes, we use the “only if bigger” option and for 1:1 aspect images it works great, but for 16:9 images (1280x720) it will take the larger of the sides and apply scaling, and we have a limit on the total number of pixels, and 1280x720 fit in that number and should not be downscaled in out case.
but 1100x1100 resolution does not fit and should be downscaled.

I added a condition by "area" I think this is what you needed


Use options supported by OS X.

Fixes FLOC-1184

My Ubuntu 14.10 machine no longer appears to have the slow SSH issue present in older versions, so not sure what to say.

I am unable to review this in any particularly useful way.

Okay.  I'm going to say this is sufficiently self-contained (and therefore ... I hope ... simple) yet important and time-sensitive (we can't do a release until this is fixed) that the testing I've done so far is sufficient (checking that the different SSH options causes flocker-deploy to not fail with the "Bad configuration option: IgnoreUnknown" SSH error).  If it somehow ends up introducing a performance regression on Ubuntu (which I don't think it does but I also can't reliably reproduce the environment that necessitated this fix) then we'll deal with that when it shows up (hopefully with a better understanding of and more documentation explaining the cause).  Meanwhile, at least it will be possible to use flocker-deploy on OS X again.


tf.estimator.export.ServingInputReceiver very rigid implementation

System information

I have written custom code.
OS Platform and Distribution: Ubuntu 16.04
TensorFlow installed from:  binary
TensorFlow version: tensorflow-1.12.0
Python version: 3.6
CUDA/cuDNN version: 9.0
GPU model and memory: GeForce MX150 2GB

Describe the current behavior
Very rigid implementation for tf.estimator.export.ServingInputReceiver. I use nested dictionaries for train and eval features, such as: features={}; features['static'] = tf.Tensor(); features['dynamic']['a'] = tf.Tensor(); features['dynamic']['b'] = tf.Tensor(), which works fine for train and eval input fns but it is not supported for tf.estimator.export.ServingInputReceiver. It raises value_error at _check_tensor:
ValueError: feature dynamic must be a Tensor or SparseTensor.
Since the function _wrap_and_check_input_tensors only allows plain dictionaries containing string keys and tensor values.
Describe the expected behavior
At least one should be able to disable the option check_tensors. Actually, tf.estimator is expected to provide a more flexible implementation.
Other info / logs
File "/home/edu/.local/lib/python3.6/site-packages/tensorflow/python/estimator/export/export.py", line 137, in new
features = _wrap_and_check_input_tensors(features, 'feature')
File "/home/edu/.local/lib/python3.6/site-packages/tensorflow/python/estimator/export/export.py", line 73, in _wrap_and_check_input_tensors
_check_tensor(tensor, name, error_label=field_name)
File "/home/edu/.local/lib/python3.6/site-packages/tensorflow/python/estimator/export/export.py", line 97, in _check_tensor
raise value_error
ValueError: feature dynamic must be a Tensor or SparseTensor.

ServingInputReceivers have strict requirements to comply with serving infrastructure (ie tf-serving). As a workaround, you could unroll your dictionaries and key each separately.

It has been 14 days with no activity and the awaiting response label was assigned. Is this still an issue?

It is not, this is the expected behaviour as @karmel pointed out. I unrolled my dictionary as suggested with no further issues.


Fix typo in custom parser docs

For the example to compile, the ProcessorsType needs to be passed though to the custom perser's template params?

Thanks for the contribution. You are right, of course.

Thanks for merging @liuzicheng1987!
I also suspect the documentation on anonymous fields might be out of date, as it appears the default behaviour now picks up the field names? Is it worth opening an issue for? My follow-on question is, with the new behaviour, is there a way to force a field to become anonymous? Thanks, loving the library so far!


Add support for "fast" hyperbolic functions

Hej,
The support of functions such as tanh_fast or sigmoid_fast is missing. I tried to add it but it seems not that easy (could it be possible to overload tanh_fast == tanh on a symbolic?
Would it be somehow possible to support all activation functions in NNlib?

You can add add these methods in TaylorDiffNNlibExt or NNlibTaylorDiffExt like here:
https://github.com/YichengDWu/Sophon.jl/blob/main/ext/SophonTaylorDiffExt.jl#L16-L24

Hi @vpuri3 @mBarreau , activation unctions from NNlib have been added to TaylorDiff at #67

Good job!


Is it possible to set the datetime in language other than English?

I have reviewed the datetime instructions; would there be any way that I can somehow make the DateTime in a different language? I am not sure if this is supported by the Unicode standard
I am looking for something like
'E' == 'Mon' ? '월요일' : 'E' == 'Tue' ? '화요일' : ...

Of course, it could be any method, I just want to display the DateTime in different language.

I think if you go to System Preferences > Language & Region and choose Korean or whatever other language you like as your Primary language, it will show that in the menu bar.

Can you confirm if this is the only way to do it? I see that Itsycal does not support additional languages, and therefore would not have any effect.

I'm not sure what you're looking at, but the menu bar date/time is drawn by macOS, not Itsycal. So it can show whatever language macOS supports. The date and time translations within Itsycal work this way too. It's just the UI elements where I had to provide translations that are limited to certain languages.

@sfsam, Got it. Thank you so much for your help. Closing this issue.


DRILL-8078: Add WEEK to Date Extract

DRILL-8078: Add WEEK to Date Extract
Description
This PR adds the possibility of extracting the WEEK from a date EXTRACT function.
Documentation
See above.  WEEK is now an option for date extract.
Testing
Manually tested and added UT.

@cgivre The commit header is not correct.


Update zio, zio-test, zio-test-sbt to 2.0.8

Updates

dev.zio:zio
dev.zio:zio-test
dev.zio:zio-test-sbt

from 2.0.6 to 2.0.8.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (2.0.6).
You might want to review and update them manually.
project/Librairies.scala

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "dev.zio" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, old-version-remains, commit-count:1

Superseded by #291.


Compatibility with ngrx 4

Given the changes with ngrx 4, is typescript-fsa-reducers still compatible? There are changes with Actions (for example, there is no payload property). How does this impact on this package?
See migration guide at https://github.com/ngrx/platform/blob/master/MIGRATION.md
Thanks

Hi st-clair-clarke,
I'm not familiar with ngrx so I may be misinterpreting, but my understanding of what they are saying is that the parent interface Action no longer has a payload field on it, but specific subtypes of it will. In the example in the migration guide, UserActions.Login, which I assume is a subtype of Action, still has a payload field. If this is indeed the case, then this library should continue to be perfectly compatible, as there is no circumstance where it is necessary to access a payload field without first being sure of what specific action subtype an object is an instance.
Let me know if this is wrong for some reason, but my understanding is that the ngrx change should not affect the usage of this library.

Closed for inactivity. Feel free to reopen if you have additional comments.


minimum and maximum constraints (exclusive or not) that use $data references are improperly validated

What version of Ajv are you using? Does the issue happen if you use the latest version?
8.10.0
Ajv options object

const Ajv2020 = require("ajv/dist/2020")
const ajv = new Ajv2020({$data: true, allErrors:true})

JSON Schema

{
    "$id": "rangeList",
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type": "array",
    "prefixItems": [
      {
        "type": "number",
        "minimum": 0,
        "exclusiveMaximum": { "$data":  "1/prefixItems/1" }
      },
      {
        "type": "number",
        "exclusiveMinimum": { "$data":  "1/prefixItems/0" },
        "maximum": 100
      }
    ],
    "minItems": 2,
    "items": false
}

Sample data

[ 50, 50 ]

Your code

const Ajv2020 = require("ajv/dist/2020")

const ajv = new Ajv2020({$data: true, allErrors:true})

const schema = {
    "$id": "rangeList",
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type": "array",
    "prefixItems": [
      {
        "type": "number",
        "minimum": 0,
        "exclusiveMaximum": { "$data":  "1/prefixItems/1" }
      },
      {
        "type": "number",
        "exclusiveMinimum": { "$data":  "1/prefixItems/0" },
        "maximum": 100
      }
    ],
    "minItems": 2,
    "items": false
}

const validate = ajv.compile(schema)

const data = [ 50, 50 ]

const valid = validate(data)
if (!valid) {
    console.log(validate.errors)
} else {
    console.log("should not be valid")
}

RunKit example: https://runkit.com/jimklo/ajv-range-list-validation
Validation result, data AFTER validation, error messages
true

What results did you expect?
I expected validation of [50, 50] to fail as the exclusiveMinimum constraint for index 1 should not permit the value of index 1 to equal the value of index 0; as well as the exclusiveMaximum constraint for index 0 should not permit the value of index 0 to equal the value of index 1.
Are you going to resolve the issue?
Not sure how to resolve.

your schema is incorrect - the references should point to the locations in the data (they are data references!), not in the schema.
The correct references would be "1/1" and "1/0" respectively - see the examples here: https://runkit.com/esp/622e4e1ada0cfa00087c4fb6


Example code in http-server readme is inaccurate

Describe the bug
The example code for starting an HTTP server is not working for us. (https://github.com/stoplightio/prism/tree/master/packages/http-server/README.md)
Expected behavior
Here is our code that successfully created the HTTP server:
const { createServer } = require("@stoplight/prism-http-server");
const { getHttpOperationsFromResource } = require("@stoplight/prism-http");
const { createLogger } = require("@stoplight/prism-core");

async function createPrismServer(){
  const operations = await getHttpOperationsFromResource("YOUR-URL");

  const server = createServer(operations, {
    components: {
      logger: createLogger("TestLogger")
    },
    cors: true,
    config: {
      checkSecurity: true,
      validateRequest: true,
      validateResponse: true,
      mock: { dynamic: false },
      errors: false
    }
  });
  await server.listen(4010);

  return {
    close: server.close.bind(server)
  };
}

describe("Contract Test", () => {
  let prismServer;

  before(async () => {
      prismServer = await createPrismServer();
      console.log("server is listening!");
    });

  after(() => {
    prismServer.close();
   });
});

Can you provide some more details? What is not working? Is the code crashing? Are you receiving an incorrect response? Is the port listening?

Hi, thanks for your quick reply! I've annotated the existing readme with some things we had to change:
import { createServer } from '@stoplight/prism-http-server';

// getHttpOperationsFromResource was never imported
const operations = await getHttpOperationsFromResource('./api.oas2.json');
// server doesn't take a single object, it takes 2 arguments
const server = createServer({
  operations,
// createLoggerInstance was never imported. Also, this object should be in another object with the key 'components'
  { logger: createLoggerInstance() }
});

server.listen(3000).then(() => {
  console.log('server is listening!');
});

This example code also is missing an example of how to close the server.

Ah ok nice! Do you want to open a PR to fix that?


Transition project discussions from internal Slack instances to instruct-lab.slack.com

We're all merrily talking over in the InstructLab public Slack now.


Example hard to unrstand

Hi:
How did you get the 600RU/s needed per partition in the last example? It is not helping to understand if you drop a number without specifying how was it selected.
Thanks.

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

ID: 3d8ba849-dc38-c6ff-0b8d-e6d539d3b21c
Version Independent ID: a7cd7f7a-2836-fd5d-8f79-1ee0f1ec2d48
Content: Best practices for scaling provisioned throughput (RU/s)
Content Source: articles/cosmos-db/scaling-provisioned-throughput-best-practices.md
Service: cosmos-db
Sub-service: nosql
GitHub Login: @deborahc
Microsoft Alias: dech

@vmh32, the 6,000 RU/s in this article is arbitrarily selected to help illustrate the example. The point is that you want 6,000 RUs per physical partition, you calculate that you need 25 physical partitions, and then decide to allocate 150,000 RU/s for ingest.
The article will be updated shortly to reflect that these values are arbitrary.


allow users to add custom information to the settle up banner

Reasoning: I live in Brazil and the biggest payment method here is PIX.
PIX has a payment key (SSN, phone number, uuid... you get the idea). One of my main gripes with Splitwise was never being able to finish payments directly from the app, or people have to ask for the key so the transaction can be completed.
I'm not sure how it could be added, but I think in the Settle Up screen it could should a "Pay now" button or something like that, and somehow it gets some information the original user registered in the app.
Not sure if you already thought about something like that, just bringing the issue.
(By the way, love the "Why" section in the readme)

@brenol  was thinking about this for some time, it's really hard to implement neatly coz, every country has different things. But adding and showing custom info can be done, users can take that to their payment provider

Closing this for now as it's out of scope


Correction for raw affiliation DIADE Unit, University of Montpellier, CIRAD, IRD – Montpellier Cedex 5, France; IFB - South Green Bioinformatics Platform, Bioversity, CIRAD, INRAE, IRD – Montpellier, France; PHIM Plant Health Institute, University of Montpellier, CIRAD, INRAE, Institut Agro, IRD – Montpellier, France

Correction needed for raw affiliation DIADE Unit, University of Montpellier, CIRAD, IRD – Montpellier Cedex 5, France; IFB - South Green Bioinformatics Platform, Bioversity, CIRAD, INRAE, IRD – Montpellier, France; PHIM Plant Health Institute, University of Montpellier, CIRAD, INRAE, Institut Agro, IRD – Montpellier, France
raw_affiliation_name: DIADE Unit, University of Montpellier, CIRAD, IRD – Montpellier Cedex 5, France; IFB - South Green Bioinformatics Platform, Bioversity, CIRAD, INRAE, IRD – Montpellier, France; PHIM Plant Health Institute, University of Montpellier, CIRAD, INRAE, Institut Agro, IRD – Montpellier, France
new_rors: 02banhz78;05kpkpg04;05q3vnk25;051escj72;03fkrcm40;03rnk6m14;003vg9w96;05y5s3h28
previous_rors: 02banhz78;05kpkpg04;05q3vnk25;051escj72;03fkrcm40;03rnk6m14;003vg9w96
works_examples: W3185853800
contact: b1546b7c98d4f81280ccdf03c5edbf12:1a0f0410bae2a071069148fb5035c13fbddd @ inrae.fr

This issue was accepted and ingested by the OpenAlex team on 2024-10-09. The new affiliations should be visible within the next 7 days.


Additional modifiers are sent

I tried to use keyd to send some ascii escape sequences to the terminal, here is my configuration file

[ids]
*

[main]
escape = capslock
#capslock = overload(capslock{warpd}, escape)
capslock = overload(capslock{alacritty}, escape)
#F29 - F28
leftcontrol = overload(leftcontrol{alacritty}, macro(esc [15;5~))
leftalt = overload(leftalt{alacritty}, macro(esc [1;5S))
leftshift = layer(leftshift{alacritty})

[capslock{warpd}]
#F13 - F16
h = f13
j = f13
k = f13
l = f13
n = f14
m = f15
; = f16

[capslock{alacritty}]
#F63 - F53
h = macro(esc [1;4R)
j = macro(esc [1;4Q)
k = macro(esc [1;4P)
l = macro(esc [24;3~)
u = macro(esc [23;3~)
= = macro(esc [21;3~)
- = macro(esc [20;3~)
0 = macro(esc [19;3~)
enter = macro(esc [18;3~)
. = macro(esc [17;3~)
o = macro(esc [15;3~)

[capslock{alacritty}+alt]
#F52 - F46
h = macro(esc [1;3S)
j = macro(esc [1;3R)
k = macro(esc [1;3Q)
l = macro(esc [1;3P)
= = macro(esc [24;6~)
- = macro(esc [23;6~)
enter = macro(esc [21;6~)

[leftcontrol{alacritty}:C]
#F45 - F40
; = macro(esc [20;6~)
, = macro(esc [19;6~)
enter = macro(esc [18;6~)
. = macro(esc [17;6~)
[ = macro(esc [15;6~)
' = macro(esc [1;6S)

[leftcontrol{alacritty}+shift]
#F39 - F38
; = macro(esc [1;6R)
, = macro(esc [1;6Q)

[leftalt{alacritty}:A]
#F37 - F33
; = macro(esc [1;6P)
, = macro(esc [24;5~)
enter = macro(esc [23;5~)
. = macro(esc [21;5~)
' = macro(esc [20;5~)

[leftalt{alacritty}+shift]
#F32 - F31
; = macro(esc [19;5~)
, = macro(esc [18;5~)

[leftshift{alacritty}:S]
#F30
enter = macro(esc [17;5~)

#F27 - ...
#macro(esc [1;5R)
#macro(esc [1;5Q)
#macro(esc [1;5P)
#macro(esc [24;2~)
#macro(esc [23;2~)
#macro(esc [21;2~)
#macro(esc [20;2~)
#macro(esc [19;2~)
#macro(esc [18;2~)
#macro(esc [17;2~)
#macro(esc [15;2~)
#macro(esc [1;2S)
#macro(esc [1;2R)
#macro(esc [1;2Q)
#macro(esc [1;2P)

When I press ctrl-enter, I get the following keystroke event(Captured by xev).
As you can see, keyd sends 4 additional control_l and 2 shift_l

KeyPress event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593701, (636,176), root:(637,229),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
    XLookupString gives 1 bytes: (1b) "
mbLookupString gives 1 bytes: (1b) "
FilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
    XLookupString gives 1 bytes: (1b) "
FilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 34 (keysym 0x5b, bracketleft), same_screen YES,
    XLookupString gives 1 bytes: (5b) "["
    XmbLookupString gives 1 bytes: (5b) "["
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 34 (keysym 0x5b, bracketleft), same_screen YES,
    XLookupString gives 1 bytes: (5b) "["
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 10 (keysym 0x31, 1), same_screen YES,
    XLookupString gives 1 bytes: (31) "1"
    XmbLookupString gives 1 bytes: (31) "1"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 10 (keysym 0x31, 1), same_screen YES,
    XLookupString gives 1 bytes: (31) "1"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 17 (keysym 0x38, 8), same_screen YES,
    XLookupString gives 1 bytes: (38) "8"
    XmbLookupString gives 1 bytes: (38) "8"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 17 (keysym 0x38, 8), same_screen YES,
    XLookupString gives 1 bytes: (38) "8"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 47 (keysym 0x3b, semicolon), same_screen YES,
    XLookupString gives 1 bytes: (3b) ";"
    XmbLookupString gives 1 bytes: (3b) ";"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 47 (keysym 0x3b, semicolon), same_screen YES,
    XLookupString gives 1 bytes: (3b) ";"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 15 (keysym 0x36, 6), same_screen YES,
    XLookupString gives 1 bytes: (36) "6"
    XmbLookupString gives 1 bytes: (36) "6"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 15 (keysym 0x36, 6), same_screen YES,
    XLookupString gives 1 bytes: (36) "6"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x1, keycode 49 (keysym 0x7e, asciitilde), same_screen YES,
    XLookupString gives 1 bytes: (7e) "~"
    XmbLookupString gives 1 bytes: (7e) "~"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x1, keycode 49 (keysym 0x7e, asciitilde), same_screen YES,
    XLookupString gives 1 bytes: (7e) "~"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 593789, (636,176), root:(637,229),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1c00001,
    root 0x579, subw 0x0, time 594021, (636,176), root:(637,229),
    state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

When I press ctrl-shift-;, The transfer sequence esc [1;6R was not sent correctly

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1722927, (748,201), root:(749,254),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1722967, (748,201), root:(749,254),
    state 0x4, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x5, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
    XLookupString gives 1 bytes: (1b) "
mbLookupString gives 1 bytes: (1b) "
FilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
    XLookupString gives 1 bytes: (1b) "
FilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 34 (keysym 0x7b, braceleft), same_screen YES,
    XLookupString gives 1 bytes: (7b) "{"
    XmbLookupString gives 1 bytes: (7b) "{"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 34 (keysym 0x7b, braceleft), same_screen YES,
    XLookupString gives 1 bytes: (7b) "{"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 11 (keysym 0x40, at), same_screen YES,
    XLookupString gives 1 bytes: (40) "@"
    XmbLookupString gives 1 bytes: (40) "@"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 11 (keysym 0x40, at), same_screen YES,
    XLookupString gives 1 bytes: (40) "@"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 19 (keysym 0x29, parenright), same_screen YES,
    XKeysymToKeycode returns keycode: 188
    XLookupString gives 1 bytes: (29) ")"
    XmbLookupString gives 1 bytes: (29) ")"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 19 (keysym 0x29, parenright), same_screen YES,
    XKeysymToKeycode returns keycode: 188
    XLookupString gives 1 bytes: (29) ")"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 47 (keysym 0x3a, colon), same_screen YES,
    XLookupString gives 1 bytes: (3a) ":"
    XmbLookupString gives 1 bytes: (3a) ":"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 47 (keysym 0x3a, colon), same_screen YES,
    XLookupString gives 1 bytes: (3a) ":"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 15 (keysym 0x5e, asciicircum), same_screen YES,
    XLookupString gives 1 bytes: (5e) "^"
    XmbLookupString gives 1 bytes: (5e) "^"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 15 (keysym 0x5e, asciicircum), same_screen YES,
    XLookupString gives 1 bytes: (5e) "^"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 49 (keysym 0x7e, asciitilde), same_screen YES,
    XLookupString gives 1 bytes: (7e) "~"
    XmbLookupString gives 1 bytes: (7e) "~"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 49 (keysym 0x7e, asciitilde), same_screen YES,
    XLookupString gives 1 bytes: (7e) "~"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723007, (748,201), root:(749,254),
    state 0x1, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723327, (748,201), root:(749,254),
    state 0x5, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 1723327, (748,201), root:(749,254),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

When I press shift-enter, 4 extra shift_l are sent,

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310809, (636,176), root:(637,229),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x0, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
    XLookupString gives 1 bytes: (1b) "
mbLookupString gives 1 bytes: (1b) "
FilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x0, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
    XLookupString gives 1 bytes: (1b) "
FilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x0, keycode 34 (keysym 0x5b, bracketleft), same_screen YES,
    XLookupString gives 1 bytes: (5b) "["
    XmbLookupString gives 1 bytes: (5b) "["
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x0, keycode 34 (keysym 0x5b, bracketleft), same_screen YES,
    XLookupString gives 1 bytes: (5b) "["
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x0, keycode 10 (keysym 0x31, 1), same_screen YES,
    XLookupString gives 1 bytes: (31) "1"
    XmbLookupString gives 1 bytes: (31) "1"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x0, keycode 10 (keysym 0x31, 1), same_screen YES,
    XLookupString gives 1 bytes: (31) "1"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x0, keycode 16 (keysym 0x37, 7), same_screen YES,
    XLookupString gives 1 bytes: (37) "7"
    XmbLookupString gives 1 bytes: (37) "7"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x0, keycode 16 (keysym 0x37, 7), same_screen YES,
    XLookupString gives 1 bytes: (37) "7"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x0, keycode 47 (keysym 0x3b, semicolon), same_screen YES,
    XLookupString gives 1 bytes: (3b) ";"
    XmbLookupString gives 1 bytes: (3b) ";"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x0, keycode 47 (keysym 0x3b, semicolon), same_screen YES,
    XLookupString gives 1 bytes: (3b) ";"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x0, keycode 14 (keysym 0x35, 5), same_screen YES,
    XLookupString gives 1 bytes: (35) "5"
    XmbLookupString gives 1 bytes: (35) "5"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x0, keycode 14 (keysym 0x35, 5), same_screen YES,
    XLookupString gives 1 bytes: (35) "5"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x1, keycode 49 (keysym 0x7e, asciitilde), same_screen YES,
    XLookupString gives 1 bytes: (7e) "~"
    XmbLookupString gives 1 bytes: (7e) "~"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 310889, (636,176), root:(637,229),
    state 0x1, keycode 49 (keysym 0x7e, asciitilde), same_screen YES,
    XLookupString gives 1 bytes: (7e) "~"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x1000001,
    root 0x579, subw 0x0, time 311105, (636,176), root:(637,229),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

When I press ctrl-enter, I get the following keystroke event(Captured by xev).
[...]

In the future please post the output of keyd -m, it is much more concise. It would also help if you could only post the relevant portion of the config.

As you can see, keyd sends 4 additional control_l and 2 shift_l

To summarize, the problematic portion of your config is equivalent to
[customControl:C]
enter = macro(esc [18;6~)

and the output is
Control_L down
Control_L up
Escape down
Escape up
bracketleft down
bracketleft up
1 down
1 up
8 down
8 up
semicolon down
semicolon up
6 down
6 up
Shift_L down
asciitilde down
asciitilde up
Shift_L up
Control_L down
Control_L up

The output is precisely what you should expect. I'm not sure what the 'additional shift' you're referring to is.  Your macro contains ~ which necessarily produces the only shift key in the output. The control down/up events are present because you have bound the macro within a control layer, they should not affect the output.
I think part of your problem might stem from some misapprehensions about terminal input. ANSI sequences need to be written to the TTY, input from your keyboard is generated by your terminal emulator as output from the TTY, you can't directly input special characters from your keyboard and expect the terminal to act on them.  If you want an escaped statement suitable for use in things like printf then you probably want something like macro(\\033[31m) instead.

When I press ctrl-enter, I get the following keystroke event(Captured by xev).
[...]

In the future please post the output of keyd -m, it is much more concise. It would also help if you could only post the relevant portion of the config.

As you can see, keyd sends 4 additional control_l and 2 shift_l

To summarize, the problematic portion of your config is equivalent to:
[customControl:C]
enter = macro(esc [18;6~)

and the output is:
Control_L down
Control_L up
Escape down
Escape up
bracketleft down
bracketleft up
1 down
1 up
8 down
8 up
semicolon down
semicolon up
6 down
6 up
Shift_L down
asciitilde down
asciitilde up
Shift_L up
Control_L down
Control_L up

The output is precisely what you should expect. I'm not sure what the 'additional shift' you're referring to is. Your macro contains ~ which necessarily produces the only shift key in the output. The control down/up events are present because you have bound the macro within a control layer, they should not affect the output.
I think part of your problem might stem from some misapprehensions about terminal input. ANSI sequences need to be written to the TTY. Input from your keyboard is generated by your terminal emulator as output from the TTY. You can't directly input special characters from your keyboard and expect the terminal to act on them. If you want an escaped statement suitable for use in things like printf then you probably want something like macro(\\033[31m) instead.

For example, this part of my configuration

[main]
leftshift = layer(leftshift{alacritty})

[leftshift{alacritty}:S]
enter = macro(esc [17;5~)

When I press shift-enter, the event I detect is this, but I think the first line of leftshift up and the second line of leftshift down should not exist

leftshift down
leftshift up
esc down
esc up
[ down
[ up
1 down
1 up
7 down
7 up
; down
; up
5 down
5 up
leftshift down
` down
` up
leftshift up

:S makes leftshift{alacritty} (incidentally you really should be using keyd-application-mapper) behave like shift. This means as soon as you press it shift down is emitted. It is a feature (not a bug). It should not have any effect on what you are trying to achieve in this instance.

I am using fcitx input method and bound shift to activate/disable it, the first and second events are detected by fcitx, so it is always activated or disabled every time I press shift-enter.
I think I may do some configuration in awesome wm, use different layout for different application by keyd ipc, not that keyd-application-mapper is bad, I just want to run as few things as possible, my computer performance is relatively low

:S makes leftshift{alacritty} (incidentally you really should be using keyd-application-mapper) behave like shift. This means as soon as you press it shift down is emitted. It is a feature (not a bug). It should not have any effect on what you are trying to achieve in this instance.

I found that my composite layer configuration is also not working properly, for example, the following configuration

[capslock{alacritty}+alt]
h = macro(esc [1;3S)

When I press capslock+alt+h, I get the following event,esc [1;3S become esc [1;4R,And there are two more events leftalt down and leftalt up

leftalt down
esc down
esc up
[ down
[ up
1 down
1 up
; down
; up
4 down
4 up
leftshift down
r down
r up
leftshift up
leftalt up

I am using fcitx input method and bound shift to activate/disable it, the first and second events are detected by fcitx, so it is always activated or disabled every time I press shift-enter.

Then there is an inherent conflict in your bindings. You either want to avoid :S or (better) remap your fcitx key and then use overload within keyd to remap your left shift key to produce it on tap.

I think I may do some configuration in awesome wm, use different layout for different application by keyd ipc, not that keyd-application-mapper is bad, I just want to run as few things as possible, my computer performance is relatively low

Unless you are trying to avoid installing python, you are better off using the shipped option. The script is interrupt driven and spends most of its time waiting for X events (like awesome), using the awesome's IPC functionality doesn't avoid this (it just adds another socket between you and the X server).

When I press capslock+alt+h, I get the following event,which esc [1;3S

That is the expected output given your config. Please reread the man page (hint: you've rebound leftalt).
I am going to close this for now, since it involves several different issues and is not a bug.

I am using fcitx input method and bound shift to activate/disable it, the first and second events are detected by fcitx, so it is always activated or disabled every time I press shift-enter.

Then there is an inherent conflict in your bindings. You either want to avoid :S or (better) remap your fcitx key and then use overload within keyd to remap your left shift key to produce it on tap.

I think I may do some configuration in awesome wm, use different layout for different application by keyd ipc, not that keyd-application-mapper is bad, I just want to run as few things as possible, my computer performance is relatively low

Unless you are trying to avoid installing python, you are better off using the shipped option. The script is interrupt driven and spends most of its time waiting for X events (like awesome), using the awesome's IPC functionality doesn't avoid this (it just adds another socket between you and the X server).

When I press capslock+alt+h, I get the following event,which esc [1;3S

That is the expected output given your config. Please reread the man page (hint: you've rebound leftalt).
I am going to close this for now, since it involves several different issues and is not a bug.
Thank you for your help and I will try your suggestions


GEODE-7347: Guarding CacheImpl during Cache move to avoid race condition

@steve-sienk @vfordpivotal


ERROR: Slack notification failed. See Jenkins logs for details. After Recent Update

I updated to latest version of the plugin last week, and ever since then, no notifications are going through to our slack channel.
Anyone else having this issue?
Here is the error I am seeing in my job log.
Slack Send Pipeline step running, values are - baseUrl: <empty>, teamDomain: ourdomain, channel: #product_engineering, color: #00FF00, botUser: false, tokenCredentialId: token
ERROR: Slack notification failed. See Jenkins logs for details.

could you check the jenkins logs please

Here is what the jenkins logs are returning:
Feb 22, 2019 12:28:24 AM WARNING jenkins.plugins.slack.StandardSlackService publish
Slack post may have failed. Response: null
Feb 22, 2019 12:28:24 AM WARNING jenkins.plugins.slack.StandardSlackService publish
Response Code: 404

is your jenkins credential saved at the GLOBAL level? there's an option issue where it only looks at that level

yes it is.

I think it may have something to do with a firewall we just implemented. I am working with our IT guy to see if that is the problem.  Will let you know.

This started happening to us on Tuesday.

This is how we send -- this was working until Tuesday.
      slackSend (         channel: "#eng_builds",         attachments: """[{"fallback": "*django*: <${env.JOB_URL}/${env.BUILD_NUMBER}|${branch}> has a new build available.", "author_link": "${env.JOB_URL}/${env.BUILD_NUMBER}", "author_name": "django: ${branch} has a new build available.", "author_icon": "${notificationThumb}", "color": "good"}]"""       )
Now we get the exact failures above, and no notifications to the channel.

That is when it started happening to us as well.

Actually -- we have NOT updated the plugin. This behavior exists in 2.15
I will try upgrading to 2.18, but, given that it seems to be version agnostic, this could be a slack thing.

Does it log the response from the Slack API call?

404 with no body -- trying to figure out the url -- upping logging

URL is sending ?token=null -- you can see it under FINE logging.

What probably happened is there was a bug in 2.15 that meant if you were previously using the 'integration token text' in your global config, it didn't save the credential when it was migrated, it was only there in memory and lost on a restart,
if you check your global config your credential is probably empty / check your credentials to see if its actually saved
its easy to fix by creating a new credential and updating your config.
IT

But, I had the behavior in 2.15 first.
I upgraded to 2.18 to try to mitigate the failure.
The slack creds DID disappear from my configuration, so I know how to fix my install now, but, I'm still concerned that I was seeing identical behavior in 2.15.  And that behavior started Tuesday evening.
Did anything else happen to things Tuesday evening?

2.15 is where the problem is. Upgrading doesn't fix it, its too late the token is gone
You need to re setup the credential
Anyone new who upgrades from 2.14 to >2.16 is fine

Confirmed. Re-adding the token fixes the integration.

@CodeMonk Sorry, I am not following, Is it just re-adding the token in jenkins or recreate the token and then re-adding in jenkins ?
I had to re-create a token(new) and the re-adding the token in jenkins fixed the issue.
Plugin Version: 2.17

I re-copied the token from the slack integration, and then added it as a Secret Text, per the instructions.

After re-setup of the credential, the slack notifications are working again for me.

Thanks, closing, the issue is fixed with 2.17, but if you migrated to 2.15 or 16 there's no fix other than recreating the credential

Has anyone seem this where it works sometimes?  For example, we notify slack at the start and end of the job.
It will fail on one of them but not both, and not always one or the other.  It was right after a Jenkins upgrade.


Implement node_modules support.

This PR is needed to discus some aspects. For now, it is working good with files from npm like 'backbone' or 'react', also, it ignores brunch plugins, but there is some problems when we have packages which require node's native modules like fs or path (ex. express) . I solved this by adding /^express/ to conventions.ignored. My proposition is to create separate branch for this implementation (maybe for collective polishing).

Why not browserify for packaging and shimming the native modules?

I agree to use browserify. It more stable then deppack.
But:

It uses streams, instead of callbacks (like brunch), so data reading will be smthing like

b = browserify().add(fileName)
stream = b.bundle()
allData = ''
stream.on 'data', (data) -> allData += data
stream.on 'end', -> compile allData #...

Deppack is simpler.
Not such stable as browserify, but its temporarily.
Bundling time is the same.
Deppack is flexible for our needs.
The single drawback of deppack is throwing error when loading native modules, but i'm going to fix this.

Ok sounds good, but as you suggested we should not land this in master until it is more mature.

@es128 Yes! I think @paulmillr will share his thoughts soon. Also, I need to fix shimming the native modules and we need to solve the problem of loading backend packages. Maybe it's viable to put backend scripts to peerDependencies or devDependencies. :/

Use detective on app code to figure out which node_modules are being required

@es128 :+1: We used it in deppack, nice stuff, but the native modules can be used in children dependencies, so I think we need to rollback all parents in this cases. Not bad

Or pull in the browserify shims as needed

Is deppack reading the app code from the brunch project? Or just using detective to figure out the dep graph?
If the former, then what's the issue with stuff like express? As long as the user didn't try to require('express') in their web app code.

wait for my review on monday please!

Landed. Works only when Brunch was ran through brunch.coffee dev binary though. So, we can safely make a new release.

./node_modules/brunch/bin/brunch.coffee build works fine, but ./node_modules/brunch/bin/brunch.coffee watch fails as follows:
/myapp/node_modules/brunch/node_modules/source-map/lib/source-map/source-node.js:100
            var code = nextLine.substr(0, mapping.generatedColumn -
                                ^
TypeError: Cannot call method 'substr' of undefined
  at Function.<anonymous> (/myapp/node_modules/brunch/node_modules/source-map/lib/source-map/source-node.js:100:33)
  at Array.forEach (native)
  at SourceMapConsumer_eachMapping [as eachMapping] (/myapp/node_modules/brunch/node_modules/source-map/lib/source-map/source-map-consumer.js:167:10)
  at Function.SourceNode_fromStringWithSourceMap [as fromStringWithSourceMap] (/myapp/node_modules/brunch/node_modules/source-map/lib/source-map/source-node.js:84:26)
  at updateMap (/myapp/node_modules/brunch/src/fs_utils/source_file.coffee:29:16)
  at updateCache (/myapp/node_modules/brunch/src/fs_utils/source_file.coffee:58:16)
  at /myapp/node_modules/brunch/src/fs_utils/source_file.coffee:69:7
  at /myapp/node_modules/brunch/src/fs_utils/pipeline.coffee:64:7
  at getDependencies (/myapp/node_modules/brunch/src/fs_utils/pipeline.coffee:36:5)
  at /myapp/node_modules/brunch/src/fs_utils/pipeline.coffee:62:5
  at JavaScriptCompiler.compile (/myapp/node_modules/javascript-brunch/lib/index.js:23:10)
  at /myapp/node_modules/brunch/src/fs_utils/pipeline.coffee:66:20
  at fn (/myapp/node_modules/brunch/node_modules/async-waterfall/index.js:19:24)
  at Object._onImmediate (/myapp/node_modules/brunch/node_modules/async-waterfall/index.js:58:22)
  at processImmediate [as _immediateCallback] (timers.js:330:15)


TH16 with DS18B20 temperature sensor is displaying 0% humidity value

What issue do you have? Please be as thorough and explicit as possible.
The TH16 equipped with the sensor DS18B20 is displaying a 0% humidity value. This sensor is a temperature sensor only and it does not measure relative humidity. In versions of this plugin previous to 5.0.0 there was no humidity value displayed in Apple Home.
Details of your setup.

Do you use (1) Homebridge (+ config-ui), (2) Homebridge (CLI) or (3) HOOBS?
(1) Homebridge (+ config-ui)

Which version of Homebridge/HOOBS do you have?
Homebridge v1.3.4

Which platform do you run Homebridge/HOOBS on (e.g. Raspberry Pi/Windows/HOOBS Box)? Please also mention your version of Node.js/NPM if known.
Raspbian GNU/Linux Buster (10)
Node.js Version v14.16.1
Npm Version v6.14.12

Which version of this plugin (homebridge-ewelink) do you have? Has the issue started since upgrading from a previous version?
homebridge-ewelink v6.1.1
Issue started from v5.0.0

Which eWeLink devices do you have that are causing issues? Please include product models if applicable.
Sonoff TH16R2 (PSA-BHA-GL) (firmware 3.4.1) + temperature sensor DS18B20

Please paste any relevant logs below.
[14/04/2021, 08:24:28] [eWeLink] [v6.1.1] initialised. Syncing with eWeLink.
[14/04/2021, 08:24:29] [eWeLink] Sending HTTP login() request.
[14/04/2021, 08:24:32] [eWeLink] Web socket host received [eu-pconnect5.coolkit.cc].
[14/04/2021, 08:24:34] [eWeLink] LAN discovery starting.
[14/04/2021, 08:24:34] [eWeLink] Sending WS login request.
[14/04/2021, 08:24:34] [eWeLink] WS login successful.
[[14/04/2021, 08:24:37] [eWeLink] LAN discovery complete.
[14/04/2021, 08:24:37] [eWeLink] LAN monitoring started.
[14/04/2021, 08:24:37] [eWeLink] [Pool Temperature] initialising with options {"disableDeviceLogging":false,"hideSwitch":true,"offset":0}.
[14/04/2021, 08:24:39] [eWeLink] [Pool Temperature] initialised and found locally with IP [<IP_ADDRESS>].
[14/04/2021, 08:24:39] [eWeLink] ✓ Setup complete. Don't forget to ☆ this plugin on GitHub if you're finding it useful!
[14/04/2021, 08:28:36] [eWeLink] [Pool Temperature] receiving update {"switch":"off","sensorType":"DS18B20","humidity":0,"temperature":18.61,"online":true,"updateSource":"LAN"}.
[14/04/2021, 08:28:36] [eWeLink] [Pool Temperature] receiving update {"switch":"off","mainSwitch":"off","online":true,"updateSource":"WS"}.

Hi @cristian5th
Are you available on Discord? Could I message you on there about a couple of things?
https://discord.gg/cMGhNtZ3tW
This would be super helpful if so!

v6.1.2 of the plugin will now check for this sensor type and remove any existing humidity sensors!


Filters: make sure that number filters have dials while allowing different decimals to be entered

Is your feature request related to a problem? Please describe.
Before update 8.7.0 we could click on arrows to increase or lower numbers for filters. E.g. for the level filter, you could type in a number, save the filter and click on the arrows to adjust the number  temporary to meet current needs.
After the update we cannot do that anymore. We have to take the hand off the mouse to type in the number. Which is inconvenient.
Describe the solution you'd like.
Bring back the arrows to dail the numbers up and down.

This is because the dial is limited and prevents the user from entering any decimal value they want (#1547).  The reason why I removed it from integers was because I wanted the filters to look consistent.

Actually, I think I found a way to solve it for both cases.

That's good news!


kore-exec: Function in configuration is not evaluated

Using kore-exec for symbolic execution (not using --prove), a function with partial arguments is not evaluated. The backend should infer that the arguments are defined because they appear in the configuration.
To reproduce:
# Unpack attached files, then:
kore-exec definition.kore --module C --pattern uninitialized-0072.kore --output result.kore --depth 0
# result.kore will be the same as uninitialized-0072.kore,
# indicating that the function at the top of the <k> cell was not evaluated.

Files: uninitialized.tar.gz

In https://github.com/runtimeverification/haskell-backend/blob/9ea642db346c529b75cc1f7963360064c5092860/kore/src/Kore/Rewrite.hs#L200 we should use simplify...Defined. We need to see if anything breaks.

This change doesn't significantly alter performance. The numbers are the following:
New Ceil: https://github.com/runtimeverification/haskell-backend/pull/3209
Master vs Master with modif
anapantilie@Anas-MBP: ~/RV/haskell-backend/test/regression-c fix-exec-definedness!
$ env GHCRTS='-s' make test-smoke100.sh.out                                                                                [18:31:27]
>>> /Users/anapantilie/RV/haskell-backend/test/regression-c test-smoke100.sh
rm -f test-smoke100.sh.out
./test-smoke100.sh > test-smoke100.sh.out || true
kore-exec: [332516832] Warning (WarnIfLowProductivity):
    Productivity dropped to: 89%
    Relevant K files include:
        /home/dwightguth/c-semantics/semantics/c.k
    Poor productivity may indicate a performance bug.
    Please file a bug report: https://github.com/runtimeverification/haskell-backend/issues
 556,204,124,112 bytes allocated in the heap
  11,882,859,224 bytes copied during GC
   1,072,200,800 bytes maximum residency (9 sample(s))
     131,107,760 bytes maximum slop
            3368 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0      1188 colls,  1188 par   31.933s   3.247s     0.0027s    0.1516s
  Gen  1         9 colls,     8 par    6.844s   2.542s     0.2824s    1.0913s

  Parallel GC work balance: 31.02% (serial 0%, perfect 100%)

  TASKS: 34 (1 bound, 33 peak workers (33 total), using -N16)

  SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)

  INIT    time    0.003s  (  0.109s elapsed)
  MUT     time  304.259s  (326.761s elapsed)
  GC      time   38.777s  (  5.789s elapsed)
  EXIT    time    0.000s  (  0.003s elapsed)
  Total   time  343.039s  (332.662s elapsed)

  Alloc rate    1,828,058,449 bytes per MUT second

  Productivity  88.7% of total user, 98.2% of total elapsed

diff -u test-smoke100.sh.out.golden test-smoke100.sh.out || ( mv test-smoke100.sh.out test-smoke100.sh.out.fail && false )

anapantilie@Anas-MBP: ~/RV/haskell-backend/test/regression-c fix-exec-definedness!
$ env GHCRTS='-s' make test-smoke100.sh.out                                                                                [18:40:00]
>>> /Users/anapantilie/RV/haskell-backend/test/regression-c test-smoke100.sh
rm -f test-smoke100.sh.out
./test-smoke100.sh > test-smoke100.sh.out || true
kore-exec: [343732199] Warning (WarnIfLowProductivity):
    Productivity dropped to: 89%
    Relevant K files include:
        /home/dwightguth/c-semantics/semantics/c.k
    Poor productivity may indicate a performance bug.
    Please file a bug report: https://github.com/runtimeverification/haskell-backend/issues
 560,412,101,088 bytes allocated in the heap
  12,955,388,768 bytes copied during GC
   1,072,203,936 bytes maximum residency (9 sample(s))
     131,117,200 bytes maximum slop
            3368 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0      1196 colls,  1196 par   35.608s   3.305s     0.0028s    0.1627s
  Gen  1         9 colls,     8 par    6.598s   2.467s     0.2741s    1.1520s

  Parallel GC work balance: 28.01% (serial 0%, perfect 100%)

  TASKS: 34 (1 bound, 33 peak workers (33 total), using -N16)

  SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)

  INIT    time    0.002s  (  0.108s elapsed)
  MUT     time  311.238s  (337.971s elapsed)
  GC      time   42.206s  (  5.772s elapsed)
  EXIT    time    0.000s  (  0.008s elapsed)
  Total   time  353.447s  (343.859s elapsed)

  Alloc rate    1,800,589,960 bytes per MUT second

  Productivity  88.1% of total user, 98.3% of total elapsed

diff -u test-smoke100.sh.out.golden test-smoke100.sh.out || ( mv test-smoke100.sh.out test-smoke100.sh.out.fail && false )

anapantilie@Anas-MBP: ~/RV/haskell-backend/test/regression-c fix-exec-definedness!

New Ceil vs New Ceil with modif
anapantilie@Anas-MBP: ~/RV/haskell-backend/test/regression-c fix-ceil-performance!
$ env GHCRTS='-s' make test-smoke100.sh.out                                                                                [18:58:15]
>>> /Users/anapantilie/RV/haskell-backend/test/regression-c test-smoke100.sh
rm -f test-smoke100.sh.out
./test-smoke100.sh > test-smoke100.sh.out || true
kore-exec: [302167272] Warning (WarnIfLowProductivity):
    Productivity dropped to: 84%
    Relevant K files include:
        /home/dwightguth/c-semantics/semantics/c.k
    Poor productivity may indicate a performance bug.
    Please file a bug report: https://github.com/runtimeverification/haskell-backend/issues
 501,550,433,992 bytes allocated in the heap
  13,085,926,064 bytes copied during GC
   1,072,203,984 bytes maximum residency (9 sample(s))
     131,113,056 bytes maximum slop
            3367 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0      1071 colls,  1071 par   44.044s   3.145s     0.0029s    0.1605s
  Gen  1         9 colls,     8 par    6.276s   2.066s     0.2296s    1.2028s

  Parallel GC work balance: 29.11% (serial 0%, perfect 100%)

  TASKS: 34 (1 bound, 33 peak workers (33 total), using -N16)

  SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)

  INIT    time    0.002s  (  0.095s elapsed)
  MUT     time  261.758s  (296.965s elapsed)
  GC      time   50.320s  (  5.212s elapsed)
  EXIT    time    0.000s  (  0.010s elapsed)
  Total   time  312.081s  (302.281s elapsed)

  Alloc rate    1,916,084,210 bytes per MUT second

  Productivity  83.9% of total user, 98.2% of total elapsed

diff -u test-smoke100.sh.out.golden test-smoke100.sh.out || ( mv test-smoke100.sh.out test-smoke100.sh.out.fail && false )

anapantilie@Anas-MBP: ~/RV/haskell-backend/test/regression-c fix-ceil-performance!
$ env GHCRTS='-s' make test-smoke100.sh.out                                                                                [19:06:20]
>>> /Users/anapantilie/RV/haskell-backend/test/regression-c test-smoke100.sh
rm -f test-smoke100.sh.out
./test-smoke100.sh > test-smoke100.sh.out || true
kore-exec: [307732536] Warning (WarnIfLowProductivity):
    Productivity dropped to: 89%
    Relevant K files include:
        /home/dwightguth/c-semantics/semantics/c.k
    Poor productivity may indicate a performance bug.
    Please file a bug report: https://github.com/runtimeverification/haskell-backend/issues
 510,066,481,936 bytes allocated in the heap
  11,427,908,080 bytes copied during GC
   1,072,203,936 bytes maximum residency (9 sample(s))
     131,113,104 bytes maximum slop
            3368 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0      1089 colls,  1089 par   31.145s   3.360s     0.0031s    0.2212s
  Gen  1         9 colls,     8 par    6.312s   2.360s     0.2623s    1.1178s

  Parallel GC work balance: 27.15% (serial 0%, perfect 100%)

  TASKS: 34 (1 bound, 33 peak workers (33 total), using -N16)

  SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)

  INIT    time    0.003s  (  0.145s elapsed)
  MUT     time  279.584s  (302.021s elapsed)
  GC      time   37.457s  (  5.721s elapsed)
  EXIT    time    0.000s  (  0.006s elapsed)
  Total   time  317.044s  (307.892s elapsed)

  Alloc rate    1,824,378,793 bytes per MUT second

  Productivity  88.2% of total user, 98.1% of total elapsed

diff -u test-smoke100.sh.out.golden test-smoke100.sh.out || ( mv test-smoke100.sh.out test-smoke100.sh.out.fail && false )


{AzureRESTAPISpecs} Broken link in Getting started with OpenAPI specifications content

Fixes Azure/azure-rest-api-specs#25243
Reference docs: https://github.com/Azure/azure-rest-api-specs/blob/main/documentation/Getting started with OpenAPI specifications.md
Azure REST API guidelines hyper link is incorrect.
Incorrect Link: https://github.com/microsoft/api-guidelines/blob/vNext/Azure/Guidelines.md
Correct Link: https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md
Choose a PR Template
Switch to "Preview" on this description then select one of the choices below.
Click here to open a PR for a Data Plane API.
Click here to open a PR for a Control Plane (ARM) API.

@mikekistler Your suggestions have been incorporated and committed. Could you please review and merge once you get a chance ?


Restart program ignores changes in .vscode/launch.json parameters

VSCode Version: 1.47.1 (user setup)
OS Version: Windows_NT x64 10.0.18362

Steps to Reproduce:

Add launch configuration (tested only "type":"node")
Add some env variable to launch configuration
Start program and log env value
Edit launch.json - set previously created env variable to any other value
Restart program with restart button or shortcut
See old env variable value being logged

Does this issue occur when all extensions are disabled?: Yes

@isidorn I can reproduce this

The issue is the following:
js-debug sets the supportsRestartRequest capability. Because we detect that capability we simply send the restart request to the session and it is up to the session to restart like it wants. Thus ignoring any changes in the launch.json.
I see two potential solutions:

We define supportsRestartRequest to only be respected if the user did not make changes to the launch.json. However there is an additional problem here, since the js-debug created a child session, and the user is actually restarting a child session we do not have an exact correlation between a child session and a changed launch configuration. We would have to introduce a heuristic: if the launch configuration is changed of a child session or any of it's parent sessions do not respect supportsRestartRequest. This would have as a consequence that if there are two child sessions, user changes the launch.json of the parent and restarts one of the child sessions, we would stop the parent and start everything again
js-debug handles this in the restart request by re-reading the launch configuration

@weinand @connor4312 let me know what you think

I see the issue with (1)
I think (2) is reasonable, but I'm not sure the best way to do it. I would have to figure out where the launch config exists on disk and resolve variables myself, which gets rather complex when dealing with workspace configurations.
I could stop terminate the session and invoke vscode.startDebugging again, but there's still the problem that I need to determine where the launch config exists in order to figure out whether a restart is needed!
Maybe the best solution is to provide some hint in DAP restart request that the launch config changed so that the debugger can react appropriately.

@connor4312 I believe you could use the getConfiguration('launch') api to get the launch.json and then you could see if the launch config with the right name exists. But I agree it is not very nice.
Introducing a hint in the DAP restart request sounds like a good idea to me.
When you see that I sent you that flag you could terminate the session and invoke vscode.startDebugging as you suggested.
However I would still have the problem when detecting if there was a change due to the parent child sessions. So I would have to say I send that flag if the child configuraiton changed or if the parent configuration changed. Maybe we should specify that as part of the comment of the flag.

I didn't know I could get the launch config using that method. I'll try that out (during debt week next month) and see if I can get something working without requiring dap/vscode changes.

Also assigning to you @connor4312

This is not very practical for me to do in js-debug. I have a version 'working' in the linked commit, but the big missing part I cannot do is resolution of variables used in the configuration. ${workspaceFolder}, I can take care of, but things like inputs are not practical to re-implement. That is, to resolve those I actually need to start a fresh debugging session.
Also, even with that solved, there's currently state that is stored for the session tree which I would need to build wiring to rework.
Changing the launch config is not something that happens super often (and if it is, then they might want to use something else like ${input: variables). I think having to stop and start the debug session in these cases is okay, and perhaps even intuitive.


Admin analytics - "filterby" option doesn't work at the API availability stats page

Description:
As $subject see attached.
Suggested Labels:
APIM-2.2.0
Type/bug
Priority/high
Severity/major
Affected Product Version:
2.1.0-update5
OS, DB, other environment details and versions:
enabled apim analytics (apim-analytic-2.1.0-update3)
Steps to reproduce:

Crate some APIs in publisher
Goto admin dashboard -> Analytics
Click on availability of API section
Try with filterby optin to search api name

Latest APIM 3.2.0 has changed to Analytics dashboard. Please reopen if you still encounter this issue with the latest version.


Turns Oreberry into Oreberries

In vanilla Minecraft it's Sweet Berries not Sweet Berry. Using that logic I changed the 12 Oreberries to say Oreberries instead of Oreberry.

This mod is not based on sweet berries. The concept existed before those were added


Props as and render are not compatible

Hi there :wave:
I'm upgrading from react-hook-form v5 to v6 following migration guide, and I think that I have found a possible issue with as and render props.
In v5, when render prop was children, if both are present, both was applied (as as wrapper component and children for rendering message. Here is a CodeSandbox (forked from v5 docs) that demostrates that it works like a charm:

But now, in v6, after moving children to render, it seems that render and as are mutually exclusive. If as prop is present, render prop won't be applied. Here is another CodeSandbox (forked from v6 docs) that should work like in the other but sadly not:

Is this an expected behaviour or an issue?
Thanks a lot, you are really awesome 🎉

yes, you are right @sergiohgz we are trying to align with Controller, so it's either now, you can't use them together.

Thanks for the fast response, awesome.
I'm really new with this library, I'm learning by upgrading 😅.  I have found that I could bypass it by wrapping component in render prop with the one defined in as prop, like in this CodeSandbox:

Is this approach what we would see in the near future?
Thanks again 😄

Yes correct :) it's either as or render. as is the lazy one, render give you the full props to assign.

Perfect, this information should be in v5 to v6 migration guide. I will write it down later and make a PR.
Another time, thanks for your time @bluebill1049

Thanks mate, PR welcome.


face-detect: implement scale up

The server component is now twisted based
Define number of cores to use using AUTOBAHN_DEMO_CPU_COUNT environment var
Updated example client.py

perfect! this will be a cool thing. scale up, scale out, both with only a few tweaks;)


Create an intro

Add an intro about yourself: who are you, what is your strength, why are you here.

I am Nikita, 22 years old. My main strength is that I have a keen eye for details and edge cases of a particular problem (at least I think so 😊) also I love challenges and the process of overcoming them. I am here to become an almighty full-stack developer, meet interesting and inspired people, and gain a lot of hands-on experience.


Sourcedata

Resolves #158 and #132
Insures /code, /derivatives and /sourcedata directories are completed ignored from validation checks. They are still included in the summary file count and total file size, but are excluded from all other summary checks.

Yep, I can confirm that it fixes #158 - number of subjects is correct in all of the cases where it was previously incorrect. Thanks!