Mini-RFC: --no-pack flag

Feature Description
when calling wasm-pack build a user can optionally pass --no-pack and wasm-pack will build your wasm, generate js, and not build a package.json
Example
wasm-pack build --target no-modules --no-pack

Outstanding Questions

Mode? should we stick this in as a mode? or should it be toplevel? docs for mode:
https://rustwasm.github.io/docs/wasm-pack/commands/build.html#mode
the default outdir is called pkg.. i'd... probably keep this the default for --no-pack but it will certainly be Weird

cc @Pauan https://github.com/rustwasm/wasm-bindgen/issues/1674#issuecomment-513604257

@Pauan can you elaborate a bit more on the motivation here as well? Are you worried about some diagnostics coming out about package.json that may be easily run into when they shouldn't?
I personally would agree that we should keep the same output folder, although it seems reasonable to restructure it slightly. For example we may not need to add a .gitignore, but just check if the top-level .gitignore ignores pkg (or something like that)

@ashleygwilliams Mode? should we stick this in as a mode?

I don't think it should use --mode, since that's orthogonal.
As for whether it should have a "mode style" flag or not, personally, I think --no-pack or --no-package is fine, but I don't have strong feelings about it.

the default outdir is called pkg.. i'd... probably keep this the default for --no-pack

I agree that pkg should still be the default. It can be changed with --out-dir, so that's not an issue.

@alexcrichton can you elaborate a bit more on the motivation here as well? Are you worried about some diagnostics coming out about package.json that may be easily run into when they shouldn't?

The motivations are:

Avoid doing unnecessary checks and unnecessary work.
As an example, it wouldn't need to handle npm packages at all, it wouldn't need to merge package.json, it wouldn't need to output the extra files, etc. This improves performance.

Avoid unnecessary warnings (e.g. warnings for missing README, warnings for missing LICENSE, etc.)

For example we may not need to add a .gitignore, but just check if the top-level .gitignore ignores pkg (or something like that)

After looking into it, I don't have much of an opinion about .gitignore: it's a small file that just contains *, and it doesn't require much extra work, so I'm fine with continuing to output it.

This is slightly off-topic, but we should also start thinking about how to handle npm dependencies with applications.
Right now wasm-pack generates a pkg/package.json file which contains the "dependencies" for all of the Rust crates (well, at least that's the intention).
That works fine if you just publish that package.json, but not if you are creating an application (such as with the rust-webpack-template).
The issue is that there are now two package.jsons: the top-level package.json for the app, and the pkg/package.json which contains the Rust dependencies.
That means that the pkg/package.json dependencies aren't installed, so the developer has to manually install them.
So we need to somehow fix that so the pkg/package.json dependencies are automatically installed.
This is another reason for the --no-package flag: since we will need to handle npm dependencies differently, it makes sense that --no-package should trigger that special handling.
This should probably be filed as a different issue, but it is related to --no-package.
Come to think of it, given the above, maybe we should call the flag --application instead, that seems closer to the intent.

I don't really personally buy the argument about performance in the sense that you're not wrong but we're talking about a handful of milliseconds at most here. I do think it's compelling to cater to the use case of removing extraneous warnings or extraneous checks that users could stumble over (such as generating an error or a warning that doesn't make sense in the "no pack" context).
I'm wondering if we could perhaps change a few defaults and basically cater to your use case @Pauan. I suspect we could continue to just go ahead and generate package.json by default (with a flag to turn it off), and wasm-pack would likely be already adequate minus it generating an extra file.

I don't really personally buy the argument about performance in the sense that you're not wrong but we're talking about a handful of milliseconds at most here.

I have tried modifying my loader to use wasm-pack, and it has a significant performance cost:

with wasm-pack: 2100ms
with wasm-bindgen only: 1630ms

The above is only for a single crate. It will naturally scale linearly with the number of crates (I have some projects which have 6 crates, so I expect wasm-pack will take 12600ms compared to 9780ms, a difference of 2820ms).
Now, you might be right that the package.json handling itself isn't slow (I have to do some profiling to find out), but it seems to me that all of the checks and processing that wasm-pack does is indeed slow, and will only get slower in the future (when #606 is implemented).

I suspect we could continue to just go ahead and generate package.json by default (with a flag to turn it off), and wasm-pack would likely be already adequate minus it generating an extra file.

I'm confused: my argument is that there should be a flag to prevent it from generating package.json, and you argue against that, but then you say that there should be a flag to prevent it from generating package.json?

Er ok so lemme explain a bit on the performance part. I've worked extensively on Cargo, rustc, etc, and I've worked quite a lot on those with respect to performance. When I say wasm-pack should take a handful of milliseconds, I mean it. I know disk I/O can be slow but the fact of the matter is that it basically isn't. Cargo does orders of magnitude more I/O than wasm-pack and wasm-bindgen (like, multiple orders), so there's absolutely no reason that wasm-pack/wasm-bindgen should be slow.
If you're seeing 1500ms in wasm-bindgen for a hello world crate, that's bad! If you're seeing a 500ms performance overhead using wasm-pack, that's bad! What I'm asserting above is obviously modulo bugs and such, but I really want to drive home that this is something we care about and a 500ms performance difference is not acceptable. It's something that needs to be diagnosed, fixed, and upstreamed.
Can you provide a sample project with reproduction steps to see the discrepancy? If wasm-bindgen takes 1500ms that almost sounds like you're doing a debug build. If wasm-pack takes 500ms extra then I have no idea where that time is going but we need to profile, figure out where it's going, and figure out how to solve it.
These are all surmountable issues and we have so much to benefit by staying consistent on the same toolchain (e.g. like Cargo for Rust) so we need to not be distracted by small bugs which make it seem like the whole toolchain needs to be updated.

I'm confused: my argument is that there should be a flag to prevent it from generating package.json, and you argue against that, but then you say that there should be a flag to prevent it from generating package.json?

Sorry what I mean is that I don't believe there's a reason to avoid generating package.json for performance. If performance is the only reason, there's no reason that flag should exist. For functionality, however, it seems like a reasonable thing to add.

I really want to drive home that this is something we care about and a 500ms performance difference is not acceptable. It's something that needs to be diagnosed, fixed, and upstreamed.

Great to hear! I agree that if the performance issues can be fixed, then that is ideal.

Can you provide a sample project with reproduction steps to see the discrepancy? If wasm-bindgen takes 1500ms that almost sounds like you're doing a debug build.

Hold on, I need to put it somewhere public, right now it's just sitting on my harddrive.
It is doing a --release build, I never do debug builds when testing anything performance or size related.

we need to profile, figure out where it's going, and figure out how to solve it.

Yes, that was my next plan.

we need to not be distracted by small bugs which make it seem like the whole toolchain needs to be updated

Sure, part of the reason for this feature request was so that I would be able to use wasm-pack instead of wasm-bindgen-cli.

If performance is the only reason, there's no reason that flag should exist.

Ah, okay, I understand now. Assuming the performance issues can be fixed, then I agree.
But performance isn't the only reason for the flag: the handling of npm dependencies for applications is another. I think we should explore that (though it's not a blocker for me using wasm-pack).

Okay, I created a time test repo: https://github.com/Pauan/wasm-pack-perf-test
After cloning it, do yarn install and then yarn run time. I get these results:
- cargo build  : 221.22448 ms
- wasm-pack    : 703.04304 ms
- wasm-bindgen : 244.175827 ms

So wasm-bindgen is only adding ~23ms over cargo build, which isn't bad at all.
But wasm-pack is adding ~459ms over wasm-bindgen, which is quite bad.
Now I'll do some profiling to see where the issue is.

I tried turning off the build steps and turning them on one at a time, and this is the result:
no steps             = ~208ms
check_rustc_version  = ~106ms
check_crate_config   = ~128ms
build_wasm           = ~237ms
install_wasm_bindgen =  ~34ms
run_wasm_bindgen     =  ~15ms
run_wasm_opt         =  ~33ms

(I didn't list some build steps, because they took a negligible amount of time, less than 1ms)
Even when it's not running any build steps at all, it still takes ~208ms.
Checking the rustc version takes an additional ~106ms, and checking the crate config takes an additional ~128ms on top of that.
Building wasm takes ~237ms, which is to be expected (as shown in my previous post). And the rest do take up some time, but only ~88ms in total.
So now I need to figure out why checking the rustc version and crate config take so long, and why wasm-pack takes ~208ms even when it does nothing at all.

I found that cargo metadata --format-version 1 --no-deps is taking up a whopping 100ms, even though it's only outputting a small amount of JSON:
{
    "packages": [{
        "name": "wasm-pack-perf-test",
        "version": "0.1.0",
        "id": "wasm-pack-perf-test 0.1.0 (path+file:///C:/Users/Pauan/Shared%20Folders/NixOS/wasm-pack-perf-test)",
        "license": null,
        "license_file": null,
        "description": null,
        "source": null,
        "dependencies": [{
            "name": "wasm-bindgen",
            "source": "registry+https://github.com/rust-lang/crates.io-index",
            "req": "^0.2.48",
            "kind": null,
            "rename": null,
            "optional": false,
            "uses_default_features": true,
            "features": [],
            "target": null,
            "registry": null
        }, {
            "name": "web-sys",
            "source": "registry+https://github.com/rust-lang/crates.io-index",
            "req": "^0.3.25",
            "kind": null,
            "rename": null,
            "optional": false,
            "uses_default_features": true,
            "features": ["console"],
            "target": null,
            "registry": null
        }],
        "targets": [{
            "kind": ["cdylib"],
            "crate_types": ["cdylib"],
            "name": "wasm-pack-perf-test",
            "src_path": "C:\\Users\\Pauan\\Shared Folders\\NixOS\\wasm-pack-perf-test\\src\\lib.rs",
            "edition": "2018"
        }],
        "features": {},
        "manifest_path": "C:\\Users\\Pauan\\Shared Folders\\NixOS\\wasm-pack-perf-test\\Cargo.toml",
        "metadata": null,
        "authors": ["Pauan<EMAIL_ADDRESS>        "categories": [],
        "keywords": [],
        "readme": null,
        "repository": null,
        "edition": "2018",
        "links": null
    }],
    "workspace_members": ["wasm-pack-perf-test 0.1.0 (path+file:///C:/Users/Pauan/Shared%20Folders/NixOS/wasm-pack-perf-test)"],
    "resolve": null,
    "target_directory": "C:\\Users\\Pauan\\Shared Folders\\NixOS\\wasm-pack-perf-test\\target",
    "version": 1,
    "workspace_root": "C:\\Users\\Pauan\\Shared Folders\\NixOS\\wasm-pack-perf-test"
}

I believe we only really need cargo metadata to find the target_directory and the workspace_root, the rest we can get from just parsing Cargo.toml (which it already does anyways).
I also found that rustc --print sysroot takes an additional ~100ms. So between these two commands that's already ~200ms.
Even rustc --version takes ~100ms, so it sounds like there's something really wrong going on here, either with the Rust tools or with my system.

Hm yeah so I'm trying to get reproducible timings locally for me and what I get get with your time script is on Linux:
- cargo build  : 46.175042999999995 ms
- wasm-pack    : 199.431287 ms
- wasm-bindgen : 71.298745 ms

on macOS:
- cargo build  : 77.952 ms
- wasm-pack    : 159.001 ms
- wasm-bindgen : 78.443 ms

and on Windows
- cargo build  : 101.396599 ms
- wasm-pack    :<PHONE_NUMBER>9999998 ms
- wasm-bindgen : 120.255201 ms

Overall except on Linux wasm-pack has a miniscule overhead (and times are relatively variable), and even on Linux it's a pretty small overhead.
Note that Cargo has mechanisms for caching rustc --print sysroot and we could basically try similar mechanisms with wasm-pack as well. For example wasm-pack probably doesn't need to check more than once a day per system that you've got wasm32-unknown-unknown installed.
If cargo metadata is taking so long that's also pretty worrisome. Long-term we could switch wasm-pack to invoke Cargo with JSON messages and rerender them in wasm-pack, but that's still aways out.
Overall it does seem like you have a particularly slow system unfortunately. What OS are you on? Do you know if there's like antivirus software or something like that which would slow things down?

I ran wasm-pack build --target web in dodrio's Todo MVC example once to get a warm cache, and then profiled running it again to measure just the overhead of a no-op build. It took about 1.4 seconds, and perf breaks it down like this:
$ perf report --sort comm --stdio --max-stack 0
[...]
# Children      Self  Command
# ........  ........  ............
#
    48.82%    48.82%  wasm-opt
    47.27%    47.27%  wasm-bindgen
     2.71%     2.71%  cargo
     0.61%     0.61%  rustc
     0.60%     0.60%  wasm-pack

I don't think we want to turn it off by default, but I could imagine that not running wasm-opt could be useful in development scenarios.
I think it makes sense to invest some time looking into wasm-bindgen CLI's performance.
wasm-pack is not a contributor to overhead, at least on my machine and test case.

@alexcrichton Overall it does seem like you have a particularly slow system unfortunately.

But everything except the Rust tooling is fast: it's extremely weird that running wasm-bindgen --version takes 18ms, but running rustc --version takes 100ms. That doesn't sound like a "generally slow system" problem.

What OS are you on?

Windows 10 Home 64-bit (version 1803)

Do you know if there's like antivirus software or something like that which would slow things down?

A while ago I had completely turned off all anti-virus, including the built-in Windows Defender anti-virus, so that isn't the issue.

@fitzgen I'm curious what times you get when running my perf test. I just updated it to include the timings for various simple commands, this is my result:
- cargo metadata : 101.264974 ms
- rustc sysroot :<PHONE_NUMBER>9999999 ms
- rustc version : 95.10274899999999 ms
- wasm-bindgen version : 18.190192 ms
- wasm-pack version : 22.479826 ms

- cargo build  :<PHONE_NUMBER>9999998 ms
- wasm-pack    : 731.461546 ms
- wasm-bindgen :<PHONE_NUMBER>9999998 ms

This option would make wasm-pack usable for me.
I'm trying to build a site which I can deploy with GitHub Pages. The current, unconfigurable, behavior is to deploy a whole lot of extra, unnecessary stuff, including a .gitignore which ignores everything in the directory, which completely breaks every single git-push-based workflow.
In contrast, if --no-pack was provided, presumably this would exclude the unnecessary, overzealous gitignore, as well as all the other unnecessary files (the README and package.json), while still outputting the WASM, JS glue, and TypeScript definitions. This would now work with GitHub Pages.

Just trying to understand this feature a bit... currently I manually run these commands (with additional flags that aren't relevant to the discussion):
In dev mode:

cargo +nightly build --target wasm32-unknown-unknown
wasm-bindgen --target web

In release mode:

cargo +nightly build --target wasm32-unknown-unknown --release
wasm-bindgen --target web
wasm-opt -Os

Is there a way to get this functionality, and nothing else, via 2 wasm-pack commands (i.e. one for dev and one for release) ?

@Pauan I'm curious, can you try running the non-rustup wrappers and see if rustup is where the slowdown is being introduced? You'll have to poke around to find the binaries themselves but I'm basically curious what the difference between these two are:
$ time rustc --version
$ time `rustup which rustc` --version

@nic-hartley @dakom I think y'all's use cases are covered by the functionality changes that --no-pack is being proposed (and PR'd at https://github.com/rustwasm/wasm-pack/pull/695). The discussion w/ @Pauan is largely about performance, which I think is orthogonal to the --no-pack flag itself.

@alexcrichton Yeah, it's a lot faster when using the raw path:
- rustc version : 89.755366 ms
- rustc version (raw) : 24.897281 ms
- wasm-bindgen version : 18.166887 ms
- wasm-pack version : 18.284311 ms

Using the raw path to the rustc binary isn't quite as fast as wasm-bindgen --version, but it's close, and it's ~3.5x faster than normal rustc --version.
If this discrepancy were fixed, I predict it would improve wasm-pack's performance by ~256ms, which is quite significant.

@alexcrichton - from looking at the two discussions I'm still not really clear on whether or not wasm-pack --no-pack is doing additional steps besides cargo build, wasm-bindgen, and (optionally) wasm-opt.
But it seems overall the documentation is a work in progress, for example the docs at https://rustwasm.github.io/docs/wasm-pack/cargo-toml-configuration.html haven't been updated to the repo's docs/src/cargo-toml-configuration.md
So maybe it's better if I just hang tight and wait for the dust to settle....

@fitzgen I'm curious what times you get when running my perf test.

I'm not on the machine I was on earlier, but here is my linux laptop's timings:
- cargo metadata : 13.274993 ms
- rustc sysroot : 42.191570999999996 ms
- rustc version : 10.153625 ms
- wasm-bindgen version : 4.476614 ms
- wasm-pack version : 2.9216539999999998 ms

- cargo build  : 47.960446999999995 ms
- wasm-pack    : 132.383768 ms
- wasm-bindgen : 65.844551 ms

@fitzgen Thanks! rustc --version is a lot slower than wasm-bindgen --version, which is also what I see. It's interesting that rustc --print sysroot is so slow.

@Pauan hm do you have experience profiling applications on Windows? A 60ms performance overhead from executing rustup is pretty huge, that should be more along the the lines of 2-5ms at most. I'd be curious to learn more about what rustup is doing that's taking so long.
@Pauan also I'm curious, what version of Rust are you using? The stable version right now has a zillion dynamic libraries it needs to load where beta/nightly have a much smaller number of dynamic libraries to load, so I'm curious if that helps the performance at all.

@alexcrichton hm do you have experience profiling applications on Windows?

None at all. I had taken a look at some tools for Windows, but they tend to be proprietary, and none of them seem similar to Linux's perf.

what version of Rust are you using?

Latest stable, rustc 1.36.0 (a53f9df32 2019-07-03), though I get similar results with nightly rustc 1.38.0-nightly (dddb7fca0 2019-07-30):
- cargo metadata : 92.637771 ms
- rustc sysroot : 92.810626 ms
- rustc version : 83.76966399999999 ms
- rustc version (raw) : 19.204386 ms
- wasm-bindgen version : 17.115178 ms
- wasm-pack version : 19.787862 ms

- cargo build  : 183.779291 ms
- wasm-pack    : 594.6442 ms
- wasm-bindgen : 205.279656 ms

My Rustup also seems to be up to date: rustup 1.18.3 (435397f48 2019-05-22)


scipy.odr how to get optional output attributes for class output

Hi there,
I am running a code which uses scipy.odr to estimate 2 parameters. Everythings works well for the usual outputs, but in the class output  I want to receive the optional attributes, particularly these ones:
res_var	                (float, optional) Residual variance.
sum_sqare	        (float, optional) Sum of squares error.
rel_error	                (float, optional) Relative error in function values computed within fcn_.
when I run the program I got the following error: 'Output' object has no attribute 'rel_err'
For what I read, I need to use the run odr (the low level function of ODR) with the option full_output=1
But in the package I cannot find the way how to use that function, always that I try I found myself with other silly errors that I am sure refers to the way I use it.
Sending you the hole code doesn't make sense becuase it is too bit, I attached a small part of my code as example, it runs and at the same time it reproduces my error, there is also a small comment where I show how I am trying to use the function odr.odr before I call the output attributes (off course is a wrong way of using it)
hope you can help me to find the correct procedure.
Thanks
odr_full_output_ex.py.zip

Your code crashes before already for me:
     46 odr_model = odr.Model(fcn = f_phi_cw_raytest)
     47 odr_opti = odr.ODR(odr_data,odr_model,
---> 48                    np.array([phi_0,cw_0]),maxit=10)
     49 odr_opti.set_job(fit_type = 0, deriv = 1, var_calc = 2)
     50

/home/rgommers/Code/scipy/scipy/odr/odrpack.py in __init__(self, data, model, beta0, delta0, ifixb, ifixx, job, iprint, errfile, rptfile, ndigit, taufac, sstol, partol, maxit, stpb, stpd, sclb, scld, work, iwork)
    766         self.output = None
    767
--> 768         self._check()
    769
    770     def _check(self):

/home/rgommers/Code/scipy/scipy/odr/odrpack.py in _check(self)
    787
    788         if x_s[-1] != y_s[-1]:
--> 789             raise OdrError("number of observations do not match")
    790
    791         n = x_s[-1]

OdrError: number of observations do not match

And in run() the full_output keyword is hardcoded to 1, so the optional outputs should already be present.
Can you please fix your example and put it in actual code here (not as a zip file) so it can be copy-pasted into the terminal?

I will have another look if you follow up, but I'm going to close this because it's not an issue. Note that StackOverflow or the scipy-user mailing list are more appropriate places to ask this kind of thing.

Dear Ralf,
I fix the problem thanks to your suggestion, as you said above, the ODR class gives me all the attributes I check it as you said in the source code. I missunderstood the instructions of the ODR package on the website as they say in the output class: "...The attributes listed as “optional” above are only present if odr was run with full_output=1...:".  Now I got everything to run it. I really appreciate your help and contribution.
When I got this problem, this was the only place I found. Can you give me this mail address for ODR users you said before?  Now that I got all the attributes I found that my sd_betas are always zero for two different experiments, I wanna know if that is normal for my experiment set up or if I need to activate anything in particular to get the real sd_betas.
Thanks.

Hi, I suppose the scipy mailing lists are the one you are referring to. They can be found here. In particular, scipy user list is discussions for various users while scipy dev is regarding the development of the package. Hope it helps.


Trying to query for "extendedAttributeInfo"

Just a question: has anyone tried (and succeeded) in extracting the attribute "extendedAttributeInfo" from AD?

Worked around by explicitely naming the extendedAttributes by their index number, e.g. "extensionAttribute15".


WIP: New Colors 2: move files from root to /app

This is me moving the root files into /app. It's kinda messy at a top level having main/nav/etc (also what is main vs what is nav is a little confusing). This also means things like tab-bar, which are only used by nav are in the root also which feels weird. Instead we have /app for all the app stuff (further cleaning tbd) which is a sibling to large sections of the app like folders/search/chat etc

The commits 972c87dddbf6...0c81650958b3 introduce visual changes on linux. :mag_right: 1 changed

Changed: Tracker-New_user_Scroll_1 (before) (after)


Restore dns configuration before restoring of thirdparties

Our current approach with restoration of resolv.conf is not correct. We need to restore dns configuration before working with internet resources, i. e. do it before restore.thirdparties task. Probably we can even change the order of tasks but this should be carefully investigated.
Originally posted by @ilia1243 in https://github.com/Netcracker/KubeMarine/issues/401#issuecomment-1519568900

Now we have 3 processing tasks in restore procedure:

restore.thirdparties
import.nodes
import.etcd

I think, that those tasks should run in following order: import.nodes -> restore.thirdparties -> import.etcd`.

import.nodes should be the first, because it restores different nodes configuration files and doesn't relate to thirdparties or etcd snapshot. Cluster is stopped at that moment;
restore.thirdparties should be next, because it requires actual resolv.conf to load thirdparties by link;
import.etcd should be the last, because it requires actual etcdctl thirdparty and nodes configuration (docker/containerd config, resolv.conf, etc.);

Unfortunately, we can't easy fix tasks order, because import.nodes and import.etcd have common prefix and they can't be splitted. For this reason, they should be renamed.
I suggest to use the following changes: import_nodes and import_etcd. This approach has no logical difference for user, but, e.g.  they can't be filtered using --tasks import option.
And looks like I found a little gap: we don't include podman configuration to backup-restore procedure. For this reason, if there are some critical changes in those files, etcd image can't be run fusing podman and import.etcd task fails.
We have already had PR to replace podman to ctr, but we also have special configuration for ctr and it should be included to backup-restore as podman.

We also forgot about /etc/apt/sources.list.d/. https://github.com/Netcracker/KubeMarine/issues/282


[BUG] If nsq broker subscribe with three queues, message will run 3*3=9 times handlers

go-micro 1.18.0
go-plugins  1.5.1
go version: 1.13
I use nsq as broker,  register one subscribe with one topic and multiple queue.
      micro.RegisterSubscriber(
          models.TopicDevice,
          service.Server(),
          device.Test1,
          server.SubscriberQueue("test1"),
      )
      micro.RegisterSubscriber(
          models.TopicDevice,
          service.Server(),
          device.Test2,
          server.SubscriberQueue("test2"),
      )
      micro.RegisterSubscriber(
          models.TopicDevice,
          service.Server(),
          device.Test3,
          server.SubscriberQueue("test3"),
      )

So i had three different channel.
When i publish one message to this topic, every subscriber channel should receive one message only.
But when go-micro receive message from nsq, every subscriber channel and every message will run three times handlers.
Run 3*3=9 times  handlers in total .
I found code at go-micro/server/rpc_router.go, func ProcessMessage()
Every channel will register a subscribe, one topic will register three subscribe.
func (router *router) Subscribe(s Subscriber) error {
    sub, ok := s.(*subscriber)
    if !ok {
        return fmt.Errorf("invalid subscriber: expected *subscriber")
    }
    if len(sub.handlers) == 0 {
        return fmt.Errorf("invalid subscriber: no handler functions")
    }

    if err := validateSubscriber(sub); err != nil {
        return err
    }

    router.su.Lock()
    defer router.su.Unlock()

    // append to subscribers
    subs := router.subscribers[sub.Topic()]
    subs = append(subs, sub)
    router.subscribers[sub.Topic()] = subs

    return nil
}

func (router *router) ProcessMessage(ctx context.Context, msg Message) error {
   ......

    // get the subscribers by topic
    subs, ok := router.subscribers[msg.Topic()]
    if !ok {
        router.su.RUnlock()
        return nil
    }

    // unlock since we only need to get the subs
    router.su.RUnlock()

    var errResults []string

    // we may have multiple subscribers for the topic
    for _, sub := range subs {
        // we may have multiple handlers per subscriber
        for i := 0; i < len(sub.handlers); i++ {
            // get the handler
            handler := sub.handlers[i]
......

I try add this code, it worked
diff --git a/broker/nsq/nsq.go b/broker/nsq/nsq.go
index 93404c1..ef6393d 100644
--- a/broker/nsq/nsq.go
+++ b/broker/nsq/nsq.go
@@ -264,6 +264,7 @@ func (n *nsqBroker) Subscribe(topic string, handler broker.Handler, opts ...brok
                if err := n.opts.Codec.Unmarshal(nm.Body, &m); err != nil {
                        return err
                }
+               m.Header["queue"] = channel

                return handler(&publication{
                        topic: topic,

index 19f672f..b60c2dd 100644
--- a/server/rpc_router.go
+++ b/server/rpc_router.go
@@ -534,6 +534,10 @@ func (router *router) ProcessMessage(ctx context.Context, msg Message) error {

        // we may have multiple subscribers for the topic
        for _, sub := range subs {
+               if sub.opts.Queue != msg.Header()["queue"] {
+                       continue
+               }
+
                // we may have multiple handlers per subscriber
                for i := 0; i < len(sub.handlers); i++ {
                        // get the handler

i'll take a look thanks

Ok i'm dig into it and have questions - as i understand this is nsq specific problem, or multiple brokers affected?
How you get  channel in this line: m.Header["queue"] = channel  ?
@asim this is uncommon use-case to connect from one service to single topic with multiple subscribers with different queue. So we likely don't see such issue. What you think? Does we need to add additional headers for message to signal queue name?

Ok i'm dig into it and have questions - as i understand this is nsq specific problem, or multiple brokers affected?
How you get channel in this line: m.Header["queue"] = channel ?
@asim this is uncommon use-case to connect from one service to single topic with multiple subscribers with different queue. So we likely don't see such issue. What you think? Does we need to add additional headers for message to signal queue name?

Sorry, i tested nsq only.
The m.Header["queue"] = channel is from here:
https://github.com/micro/go-plugins/blob/2e4950c6154da845efaad61dd27b243a52073f70/broker/nsq/nsq.go#L245


Add Member#getEffectiveNickname()

Pull Request Etiquette

[x] I have checked the PRs for upcoming features/bug fixes.
[x] I have read the contributing guidelines.

Changes

[x] Internal code
[x] Library interface (affecting end-user code)
[ ] Documentation
[ ] Other: _____

Closes Issue: NaN
Description

Change the current Member#getEffectiveName() to Member#getEffectiveNickname().
Add Member#getEffectiveName() which works just as same as User#getEffectiveName().
Use ternary operator in Member#getTimeJoined() because why not.

I also can't see the logic behind this... A Member can't have more than 1 nickname. And getEffectiveName() does iirc this logic:
Member has Nickname? -- Yes --> Return Nickname
  |
  |
  V
Member has global Displayname? -- Yes --> Return global display name
  |
  |
  V
Return username/identifier

What is the use-case for this?

Because I think the getEffectiveName() method in both User and Member should return the same thing, which is the global name if present or the name, in order to prevent misuse.
On the other hand, Member#getEffectiveNickname() can provide the replaced function of the original Member#getEffectiveName().

Because I think the getEffectiveName() method in both User and Member should return the same thing, which is the global name if present or the name, in order to prevent misuse. On the other hand, Member#getEffectiveNickname() can provide the replaced function of the original Member#getEffectiveName().

I think you missunderstand the logic of getEffectiveName() here.
Imagine it as what the bot would "see" when either looking at a User in DMs or a User on a Server.
After all, if a user has a nickname on the server do you see that and not their nickname right? That's the "effective" name they have here.

The point of getEffectiveName is to return the visible name. In the context of a user this is the globally visible name (what you see in DMs) and in the context of a member this is the guild name (visible in the member list of a guild). As such, the returned names are consistent between the two contexts.
Adding another name getter is only adding more confusion and should be avoided. Delegating getters from User into Member is a non-goal. To use the user getters, use getUser().getXYZ() instead.


no main manifest attribute, in /usr/share/java/guice.jar

Hi!
I'm stacked on the last line.  I executed following command:
java -Dapplication.properties.file=/opt/act-platform/executable/application.properties.localhost -jar /usr/share/java/guice.jar module=no.mnemonic.act.platform.rest.RestModule module=no.mnemonic.act.platform.service.ServiceModule
no main manifest attribute, in /usr/share/java/guice.jar
Do I need to point other jar file, instead of '/usr/share/java/guice.jar'?
Please have a look the find result here:

Kind regards,
Yuki

Hi!
The correct command to start the application should be:
java -Dapplication.properties.file=/opt/act-platform/executable/application.properties.localhost -jar /opt/act-platform/executable/target/act-platform-0.0.1-SNAPSHOT.jar guice module=no.mnemonic.act.platform.rest.RestModule module=no.mnemonic.act.platform.service.ServiceModule
You might need to change the path after the -jar switch depending on where the compiled jar is on you file system. It should be in the /executable/target folder. The compiled jar contains Guice and the correct startup class will be picked up automatically. You probably need to start the application from the /executable folder, otherwise it won't find some of the other configuration files (or change the paths in application.properties.localhost).
Kind regards,
Konstantin

Hi!
Thanks for your prompt answer.
root@kali2018:/opt/act-platform/executable# java -Dapplication.properties.file=/opt/act-platform/executable/application.properties.localhost -jar /opt/act-platform/executable/target/act-platform-0.0.1-SNAPSHOT.jar guice module=no.mnemonic.act.platform.rest.RestModule module=no.mnemonic.act.platform.service.ServiceModule

Bootstrap 0.0.1-SNAPSHOT

no.mnemonic.commons.component.ComponentException: java.lang.RuntimeException: Could not perform request to create index.
at no.mnemonic.commons.container.ComponentContainer.activate(ComponentContainer.java:337)
at no.mnemonic.commons.container.ComponentContainer.initialize(ComponentContainer.java:165)
at no.mnemonic.commons.container.BootStrap.bootContainer(BootStrap.java:181)
at no.mnemonic.commons.container.BootStrap.guiceBoot(BootStrap.java:163)
at no.mnemonic.commons.container.BootStrap.boot(BootStrap.java:109)
at no.mnemonic.commons.container.BootStrap.main(BootStrap.java:65)
Caused by: java.lang.RuntimeException: Could not perform request to create index.
at no.mnemonic.act.platform.dao.elastic.FactSearchManager.logAndExit(FactSearchManager.java:920)
at no.mnemonic.act.platform.dao.elastic.FactSearchManager.createIndex(FactSearchManager.java:383)
at no.mnemonic.act.platform.dao.elastic.FactSearchManager.startComponent(FactSearchManager.java:112)
at no.mnemonic.commons.container.plugins.impl.ComponentLifecycleAspectHandler.startComponent(ComponentLifecycleAspectHandler.java:18)
at no.mnemonic.commons.container.ComponentContainer.startNode(ComponentContainer.java:359)
at java.util.concurrent.ConcurrentHashMap$ValuesView.forEach(ConcurrentHashMap.java:4707)
at no.mnemonic.commons.container.ComponentContainer.activate(ComponentContainer.java:332)
... 5 more
Caused by: org.elasticsearch.client.ResponseException: PUT http://localhost:9200act: HTTP/1.1 400 Bad Request
{"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"unknown setting [index.mapping.single_type] please check that any required plugins are installed, or check the breaking changes documentation for removed settings"}],"type":"illegal_argument_exception","reason":"unknown setting [index.mapping.single_type] please check that any required plugins are installed, or check the breaking changes documentation for removed settings"},"status":400}
at org.elasticsearch.client.RestClient$1.completed(RestClient.java:354)
at org.elasticsearch.client.RestClient$1.completed(RestClient.java:343)
at org.apache.http.concurrent.BasicFuture.completed(BasicFuture.java:119)
at org.apache.http.impl.nio.client.DefaultClientExchangeHandlerImpl.responseCompleted(DefaultClientExchangeHandlerImpl.java:177)
at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.processResponse(HttpAsyncRequestExecutor.java:436)
at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.inputReady(HttpAsyncRequestExecutor.java:326)
at org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:265)
at org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:81)
at org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:39)
at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:114)
at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:276)
at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588)
at java.lang.Thread.run(Thread.java:748)

Gee, I've got above error, I'm sure Elasticsearch is working as following:

docker ps command result is here:

In order to investigate the error, I'll get any information you'd like to know. So, please let me know. I'm willing to fix this.
Many thanks,
Yuki

Hi!
The reason for this error is that you are using Elasticsearch 6.6 but the platform requires Elasticsearch 5.6 right now. It should mostly work with 6.6 but I haven't tested it properly and I need to upgrade the client driver as well. The upgrade is on my roadmap but I just didn't had the time yet. For now I suggest to downgrade Elasticsearch to version 5.6.
Kind regards,
Konstantin

Hi!
Thank you for your big help.  :)
I downgraded Elasticsearch 5.6.15, then previous error has gone.
And also, downgrade Cassandra 2.2.14.
Then, I executed following command:
# java -Dapplication.properties.file=/opt/act-platform/executable/application.properties.localhost -jar /opt/act-platform/executable/target/act-platform-0.0.1-SNAPSHOT.jar guice module=no.mnemonic.act.platform.rest.RestModule module=no.mnemonic.act.platform.service.ServiceModule
But, I'm afraid I couldn't see any messages as following:

I'm wondering about docker port 2375. I didn't configure anything about port 2375.
Do I need to do something for docker port 2375?
Any advices will be helpful.
Kind regards,
Yuki

Hi!
You don't need to downgrade Cassandra, the newest version should be fine. The code has never be tested with such an old version of Cassandra. Port 2375 is the port to communicate with the Docker daemon. If you can start/stop containers it works correctly.
If you don't see any messages in the console it hopefully means that the application has started correctly. You can check the logs/service.log file for any error messages. Regular application logs go into this file.
Kind regards,
Konstantin

Hi!
Fortunately, I didn't find any error messages at ./logs/service.log file.
Kind regards,
Yuki


Do not log in production (closes #235)

Checklist

[x] Test your changes as thoroughly as possible before you commit them. Preferably, automate your test by unit/integration tests.
[x] If this PR comes from a fork, please Allow edits from maintainers
[x] Set a speaking title. Format: {task_name} (closes #{issue_number}). For example: Use logger (closes # 41)
[x] Link your Pull Request to an issue (if applicable)
[ ] Create Work In Progress [WIP] pull requests only if you need clarification or an explicit review before you can continue your work item.
[x] Make sure that your PR is not introducing unnecessary reformatting (e.g., introduced by on-save hooks in your IDE)

Description

Closes #235 by using ProGuard rules

Closing this in favor of the Timber solution (see https://github.com/corona-warn-app/cwa-app-android/issues/235#issuecomment-640505651) which i think @jakobmoellersap is working on


'formControl' isnt't a known property of 'search-select'

Hi
Angular version 6.1.0
I'm get this error when try to build an App with your demo-3-real-api example.
Some idea?
Thank's

First thing to try: make sure you include FormsModule and/or ReactiveFormsModule in your app module.

Yes, sorry. I just read the answer # 4.
Now everything work fine, thanks


💲[Native Checkout] Login/Signup design pass

📲 What
Updated the designs of the signup/login screen.
This included:

updated button colors/styles
updated fonts
dynamically setting the font of the context label based on whether it's shown with a header or not

As part of this work, I converted LoginToutViewController.swift to use programmatic UI, and deleted the corresponding scene from the Login.storyboard.
🛠 How

removed the LoginTout scene from the Login storyboard and converted all relevant UI to programmatic views
updated the necessary styles both in ButtonStyles.swift and in Styles.swift
regenerated all the necessary screenshots

Note that because a lot of these button styles are shared, it resulted in changes to several login-related views including the sign up VC, login VC, forgot password VC, facebook signup confirmation VC and rewards collection VC. These changes are purely visual and should not impact the functionality of these views. Please examine updated screenshots carefully :)
👀 See
Trello, screenshots, external resources?

Before 🐛
After 🦋

Also see:

LoginViewController
SignUpViewController
FacebookConfirmationViewController

♿ Accessibility

[ ] Tap targets use minimum of 44x44 pts dimensions

✅ Acceptance criteria
Please see all updated screenshots.
Testing login/signup screen:
Logged out, tap "Signup or login" from the discovery screen.
You you should see the login/signup screen with the new button/font designs.
Tap "Sign up with email" and you should be taken to the sign up screen.
Tap "Log in" and you should be taken to the login screen.
Tap "Log in with Facebook" and you should be prompted to accept the facebook login terms.
Tap the disclaimer text below the "Log in" button and you should see an action sheet with various privacy/terms disclaimer options.

 Design updates for signup/login screen


Windows: The system cannot find the path specified

Satchmo@DESKTOP-3IDR5U5 MINGW64 ~/Desktop
$ ./paymail.exe whois satchmo
Error connecting to database: Error Creating Dir: "C:\\Users\\Satchmo\\paymail\\database": mkdir C:\Users\Satchmo\paymail\database: The system cannot find the path specified.
Error: open C:\Users\Satchmo\paymail\config.yaml: The system cannot find the path specified.
Satchmo@DESKTOP-3IDR5U5 MINGW64 ~/Desktop

Closed with 0.1.7


Inaccuracy of Benefits&Observations #2

First off: thank you for having this discussion and planning in such an open space. This is an extremely important change and it looks like the process of making it is off to a really great start!
To continue in that vein, I think that we should be very clear about the realities of paper submission and publication in our field. Namely, the following statement in Benefits and Observations is a bit removed from reality:
If you measure between completion of the research and publication, the improvement
is even more dramatic, since in the current system, any idea completed after mid-November
must wait up to 12 months just for submission.

As we all know, this is not the case. There are other top-tier conferences, and I feel that ignoring their existence in this process will decrease the quality of the final result. IMO, an analogous benefit that could be put in this slot is a discussion on the improvement of the proposed method over the two-week resubmission cycle that occurs currently (where authors have around two weeks between the notifications of one conference and submission deadline of the next).
If you're ok with that, I can make a PR with some proposed wording in that direction.

Sure, we can add something to clarify that the comment above is specific to Oakland and note that waiting until USENIX is shorter, but typically still a three month delay.
I agree that we can also note the downsides to the current gap of two weeks between rejection notification and resubmissions at the next conference.  Feel free to create a PR about this.

PR opened!

Closed by b20b8124c49f5261458df28e976d7d30a9cfd01a


change checkJs to allowJs for file expansion

closer to the intent and won't unnecessarily force users to configure typescript in a way they may not want to

Thanks for the PR. It should be allowJs || checkJs, I believe.
allowJs is false by default in tsconfig, so I don't see why users would expect this plugin to support non-TypeScript files by default. Let's revert https://github.com/aleclarson/vite-tsconfig-paths/pull/16/commits/24f2f95296dc0a3be0236222c78b06429ea1fe63 please.

Good call , it should definitely be allowJs || checkJs.
Even though tsc is false by default, I still think users expect their js to be resolved and bundled, just not ran through the typescript compiler. There are 4 distinct separate responsibilities all trying to map the tsc config to their use: typechecking, codegen, resolution, and bundling. Your stance is also valid though and its your code ;) making both changes now.

Released in v2.5.1


subdirectories

Still debugging this one but the template doesn't seem to work for installing WordPress in a subdirectory (e.g. www.foo.com/blog instead of www.foo.com) even after making many adjustments to the handler paths in app.yaml.
This part of wp-config.php may be at issue:
define('WP_SITEURL', $protocol_to_use . HTTP_HOST);
define('WP_HOME', $protocol_to_use . HTTP_HOST);

Yep, that was part of it. After updating those variable sin wp-config it mostly works. However, my logs still show a lot of 404s like this for wp-cron.php specifically:
<IP_ADDRESS> - - [25/Nov/2017:09:06:00 -0500] "GET /wp-cron.php HTTP/1.1" 404 25 - "AppEngine-Google; (+http://code.google.com/appengine)" "mokka-186616.appspot.com" ms=5 cpu_ms=1 cpm_usd=2.7929999999999998e-9 loading_request=0 instance=00c61b117caa844846733adf0d766001db4976bf0dfed4d2a7572fa6a2a0c20a04fb3c20755585 app_engine_release=1.9.54 trace_id=9151fc256c377df4e0424446249a4c7f
I'm not sure what to make of that. Apparently some external App Engine service is talking to my blog but not using the right URL?
I'm also having trouble uploading new images, though that may not be related.


Improvement in Manage State Locally First module

Describe the Issue
As a part of Manage State Locally First module, the user is supposed to add a button element which is supposed to trigger a certain method when it gets clicked.
Though instructions in this module mention about the action which that button element should be performing, but it doesn't mention anything regarding the text which should be getting displayed on that button element. Considering that, currently, the user can simply complete this module without adding any text to the button element which I think is not appropriate because all the button elements are supposed to have some text or probably some symbol ( related to the functionality they perform ) on them.
Keeping that in mind, I think the instructions ( and related test cases ) in this module, should be modified in order to accommodate this particular requirement where the user is expected to add some text on the button element.
Affected Page
https://www.freecodecamp.org/learn/front-end-development-libraries/react-and-redux/manage-state-locally-first
Expected behavior
The instructions ( and related test cases ) in Manage State Locally First module, should be modified in order to accommodate a new requirement where the user is expected to add some text on the button element.
Screenshots

I can start taking a look at this bug!

can you please assign this to me i want to work on this

Hello there,
I have removed bug from the type, because it does not aim to teach HTML and accessibility.
Personally, I would not recommend adding any more tests/description about the button. The description is already lengthy, and the extra requirement would not be related to the learning outcome.

That said, I am open to other options such as just adding any button to the seed code already populated with text.


translate js to ts

https://www.qiushiyan.dev/posts/htmlwidgets-ts/

The linked docs also discuss having webpack manage deps. This is a good idea as we'd like to bring in lots of other components.

just would like to keep in mind that maintaining as minimal dependencies as possible is a goal here. ppl should as much as possible be able to install and use this as they would any other r package


OTT-1397: Fix a bug that it did not correctly parse db_type and db_version for aurora mysql

LGTM but I'll defer to the others.

oh looks like we haven't cut a release yet for the latest version with changes that Bohan landed, can maybe roll together


Base r updates

This fixes two issues:

the reticulate package wasn't working because R couldn't find the Python install
The packages installed in the start script weren't in a location that RStudio user accounts know to look

Not related to this PR, but if we are rebuilding all the images, I think we should set an upper limit on setuptools.

Not related to this PR, but if we are rebuilding all the images, I think we should set an upper limit on setuptools.

I was only planning on rebuilding this one for 11.10, but we could do the rest as well, if you want to get that in.

If you are not rebuilding them then it they are fine, but if you are rebuilding then you need the pin. I'll just get it in now to be on the safe side.

Ok I put that change in https://github.com/saturncloud/images/pull/292

I have 1-2 other new R images that would be nice to put in at the same time we roll out this one (but not as critical)

I have 1-2 other new R images that would be nice to put in at the same time we roll out this one (but not as critical)

We can roll those out whenever - can be after this. (Image builds are easy)


time-box the docker client to avoid ever getting stuck

It seems that we can get into an odd state when contacting the docker daemon. Even with the appropriate timeouts (default apache client in this case) set, we can still get into a situation where we try to contact the docker daemon then hang there forever. While the root problem lies in the docker daemon, it shouldn't stop the executor from being able to shut down properly.
This optionally creates a time limit for all calls using the docker daemon to avoid things hanging and causing an executor process that will simply wait forever doing nothing.

Would you still have a stuck thread? If so, doesn't this just hide a resource leak and eventually you could run out of threads or HTTP connections?

From my testing while things were in the stuck state, interrupting the thread / killing the process will still stop it correctly. Maybe stuck was a bad word, the docker daemon call just never returns and never times out

Interesting, maybe we should PR the spotify docker client if it's not respecting timeouts

spotify docker client is just using apache http client underneath, default timeouts for connect and read get set to 5 and 30 seconds. I think the current bug with the docker daemon is that it keeps the connection open in such a way that the timeouts do no get hit, thus the usage of TimeLimiter here instead (docker cli calls and calls to docker daemon from any source/client hang as well)
The bug is a rare case and the purpose of the PR is more to limit our executor from being pinned by it. If we can't launch something because docker is in a bad state, call it failed and move on.


OSError when image file is missing

If an image entry exists within Wagtail for which the cosponsoring filesystem path does not exist an OSError is thrown.
Traceback (most recent call last):
  File "/srv/django/site/env/lib/python2.7/site-packages/django/core/handlers/base.py", line 111, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/contrib/auth/decorators.py", line 21, in _wrapped_view
    return view_func(request, *args, **kwargs)
  File "/srv/django/site/env/lib/python2.7/site-packages/wagtail/wagtailimages/views/images.py", line 126, in edit
    'url_generator_enabled': url_generator_enabled,
  File "/srv/django/site/env/lib/python2.7/site-packages/django/shortcuts.py", line 50, in render
    return HttpResponse(loader.render_to_string(*args, **kwargs),
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/loader.py", line 178, in render_to_string
    return t.render(context_instance)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 148, in render
    return self._render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 142, in _render
    return self.nodelist.render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 844, in render
    bit = self.render_node(node, context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 858, in render_node
    return node.render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/loader_tags.py", line 126, in render
    return compiled_parent._render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 142, in _render
    return self.nodelist.render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 844, in render
    bit = self.render_node(node, context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 858, in render_node
    return node.render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/loader_tags.py", line 126, in render
    return compiled_parent._render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 142, in _render
    return self.nodelist.render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 844, in render
    bit = self.render_node(node, context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 858, in render_node
    return node.render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/loader_tags.py", line 126, in render
    return compiled_parent._render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 142, in _render
    return self.nodelist.render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 844, in render
    bit = self.render_node(node, context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 858, in render_node
    return node.render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/loader_tags.py", line 65, in render
    result = block.nodelist.render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 844, in render
    bit = self.render_node(node, context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 858, in render_node
    return node.render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/loader_tags.py", line 65, in render
    result = block.nodelist.render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 844, in render
    bit = self.render_node(node, context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 858, in render_node
    return node.render(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 898, in render
    output = self.filter_expression.resolve(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 596, in resolve
    obj = self.var.resolve(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 734, in resolve
    value = self._resolve_lookup(context)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/template/base.py", line 770, in _resolve_lookup
    current = getattr(current, bit)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/db/models/fields/files.py", line 74, in _get_size
    return self.storage.size(self.name)
  File "/srv/django/site/env/lib/python2.7/site-packages/django/core/files/storage.py", line 285, in size
    return os.path.getsize(self.path(name))
  File "/srv/django/site/env/lib/python2.7/genericpath.py", line 49, in getsize
    return os.stat(filename).st_size
OSError: [Errno 2] No such file or directory: '/srv/django/site/media/original_images/img-17686908.jpg'

We fixed a similar issue in 0.8.3. Are you using the latest version?

I'm on the master branch as the MySQL migration fix hasn't made it to pypi yet.

Just had a closer look at your traceback and I think I've spotted the problem.
It looks like you're not using Wagtails {% image %} tag for rendering the image which would usually silence this exception.
If you'd like to show your image at it's original size, I'd recommend using the original filter like so: {% image myimage original %}. (http://docs.wagtail.io/en/latest/core_components/images/index.html#using-images-in-templates)

I should have been more explicit in my bug report. This occurs in the Wagtail backend when the file system path to the uploaded original image doesn't exist any more.
Steps to reproduce

Upload an image in the wagtail backend
rm the file
View the file page in the Wagtail backend

This prevents deletion of the related db entries via the Wagtail interface without re-adding a file at that path.

Ohh, apologies for the confusion.
I'll look into this further

I can confirm that this is a bug introduced in Wagtail 0.9.
It appears that we are now reading the file to check its size but are not checking that it exists first. This commit introduces the issue: https://github.com/torchbox/wagtail/commit/9fe6f04d7b11a0d3c7fc6c850e290b94bd29f126

Is this a meaningful bug? I'm not particularly convinced :-) We have fallback behaviour on front-end templates for missing image files, as a convenience to developers - so that they can pull down live database snapshots to their local development version and still be able to render templates. But if you're going in to the image admin area and editing actual image records, there's a reasonable expectation that the image ought to exist, and it's not unreasonable for Wagtail to throw an error if it doesn't.

I think it's a bug.

Wagtail 0.8.x didn't do it and Wagtail 0.9.x does it due to an unintended side effect of getting the filesize.

If we want Wagtail to crash in this case, I think we should be telling Wagtail to crash explicity instead of relying on file.size to crash it for us. And add a test for it.

It's a bug for sure but not a major one. It would just be more convenient to be able to delete the image entry via the wagtail UI in the case of a missing file rather than either having to resort to ./manage.py shell, direct database access or putting a dummy file in place.

@kaedroho Well, that's just the nature of undefined behaviour... just because something worked by chance in the past doesn't mean that we should commit to it continuing to work, or failing in a predictable way. And I think there's merit in leaving behaviour undefined sometimes, providing it doesn't interfere with normal use of the system - it means there's one fewer edge case to account for when we refactor the code in future.
Having said that - if you're willing to fix this and commit to maintaining a particular behaviour in future, go ahead!

@gasman I think it depends on whether you want to program defensively or not. Generally my principle with regards to I/O is always presume it's going to fail in some edge cases and be as defensive as possible.


pdf created by react native html to pdf is not showing in IOS 15 version but can be seen in IOS 14

pdf created by react native html to pdf is not showing in IOS 15 version but can be seen in IOS 14.
Any workaround for this issue?

Hi did you manage to fix it?


Remove the hardcoded reference to us-east-1 region

Description
Remove the hardcoded reference to us-east-1 region
we don't have to hardcode it. Go can read this from the env var AWS_REGION.

@erikvanbrakel any update on this? (^-^)/


npm install issue

Hi, when I run npm install -g gulp I get this, any clues?
npm ERR! Linux 4.1.18-boot2docker
npm ERR! argv "/usr/bin/node" "/usr/bin/npm" "install" "-g" "gulp"
npm ERR! node v5.7.1
npm ERR! npm  v3.7.5
npm ERR! code EAI_AGAIN
npm ERR! errno EAI_AGAIN
npm ERR! syscall getaddrinfo

npm ERR! getaddrinfo EAI_AGAIN registry.npmjs.org:80
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /root/app/npm-debug.log

I thought it was a SSL issue, so I tried running npm config set strict-ssl false && npm config set registry http://registry.npmjs.org, and I'm getting the same error.

Are you able to post the contents of /root/app/npm-debug.log?

getaddrinfo errors are usually name resolution problems due to VirtualBox DNS proxy. Are you on Mac OS X using Docker Machine by any chance? See if https://github.com/boot2docker/boot2docker/issues/451#issuecomment-65432123 helps.

It seems it's a boot2docker issue, I rebooted the vm and it went fine!
Thank you!


country_icons component as extra repo?

Move country_less component files to extra repository (which already exists just for icons)

nope nope nope
Icons wont be probably updated anytime soon, unless there is world war 3 or something like that :O


Show progress while syncing hidden games

Is your enhancement request related to a problem? Please describe.
Syncing hidden games can take quite some time if you have a few thousand games hidden (I've 4k but some have much more: https://www.steamgifts.com/discussion/or2zV/). To make it more clear that the sync is working it would be nice to see the progress.
Describe the solution you'd like.
E.g. showing something like "page xxx/yyy synced" or "zz% done" or similar to how you've done it for won games.
Describe alternatives you've considered.
It's now possible to see the progress in the new "SteamGifts Request Log" however I would prefer if it is shown directly.

Will add it, but are you aware of https://www.steamgifts.com/account/settings/profile?esgst=settings&id=updateHiddenGames? With this option enabled, whenever you add/remove a game from the hidden list, it automatically updates the data, so you don't have to keep syncing those 4K games every time.

Thanks, I'm already using https://www.steamgifts.com/account/settings/profile?esgst=settings&id=updateHiddenGames which is great especially now that sg has the rate limits but once a month I like to make a complete sync.

IMHO you should also add a warning in the syncing options that syncing hidden games can make a huge number of requests if you have a lot of hidden games.

Will add it, but are you aware of https://www.steamgifts.com/account/settings/profile?

I wasn't aware. Activated that and also the same feature for new blacklist entries. Are there other known features that would result in large numbers of requests which could be avoided by using other features I'm not aware of?
I'm asking because such automatic features (that partially sync on the side) reduce the risk of running into the limits. So a user can go for longer at "full speed" (once user adjustable request limitation is added) before limits are hit.
(Again, just so user experience is more fluent without waiting a second for each single GA while looking at only a few pages anyways and thus not likely to run into issues.)
I'm not using any of the two much but I'd suggest to make this the standard way to handle things and remove the features from the sync. (Or instead of removing add a confirm checkmark for users to acknowledge that activating this feature will have an effect on their remaining requests to the page, similar to what at46 suggested above).


Failed to connect duckdb to Go

I am using duckdb+Python.
I followed the manual to connect to Go,
but I cannot connect duckdb to Go.
The OS is Windows and the Go version is go1.22.4.
I was able to create a mod file and run/compile it to connect Go to Sqlite3 and postgresql,
but Go + duckDb is not working.
Can someone tell me how to solve this?
The Go code is available on the official website.

What error are you getting?


Doc: Add a new Extention Feature(extention15.kt)

Description:

add a new extention15.kt

PR Instruction:

Issue will be assigned on a first come first serve basis.
If you are thinking to make a pr then at first be sure to get assigned.
before pushing your PR please make sure to fetch upstream.
your pr should be pushed on the develop branch only.
try to complete your assigned task within 3 to 5 days and if you need more time then please let me know. As the program has limited time only so please try to complete as fast as you can.
With your PR try to send a screenshot or screen recording of your work

I am interested to work on it


How to compile system_monitor.c file?

How to compile system_monitor.c file?

Any help?

Hey @liusy58
We use BCC, more specifically gobpf/bcc to load and use this file at runtime. Relevant Code.
BCC compiler provides it with the necessary header files and flags to compile the program.
I don't think this is a bug.

Yeah, U R right, very happy to see your reply. But I want to get the bytecode of the file system_monitor.c, could you please give me some advice?

I am honestly not sure how we can do that with BCC 🤔
But we have a PR migrating away from BCC,

https://github.com/kubearmor/KubeArmor/pull/677

There's updated code and a makefile under BPF/ which should help generate the bytecode for you.
You can connect with us on Slack as well if needed.
Hope it helps ✌🏽

Yeah, I follow your instruction and successfully get the binary, another question is why there are three binaries?
system_monitor.bpf.o
system_monitor.container.bpf.o
system_monitor.host.bpf.o

Any difference between them?
Much thank!

They are compiled with different flags for different usecases, and decided by the Userspace which one to load based on configuration.
Also out of curiosity, what's the endgoal for the bytecode?

Haha~ I'm learning eBPF for fun and want to learn something about bytecode.
I cannot thank you more for your general help. But are there any other eBPF kernel programs in KubeArmor?

I'm learning eBPF for fun and want to learn something about bytecode. ;-)

Nice!! Enjoy 😄

any other eBPF kernel programs in KubeArmor?

Not as of now. Some WIP as part of #484.


Added hover effect on pagination buttons. #1796

Fixes Issue🛠
Closes #1796
Description👨💻
I've added hover effect on the pagination buttons i.e. 'Previous' and 'Next' matching the UI.
Type of Change📄

[x] New feature (non-breaking change which adds functionality)
[x] Style (non-breaking change which improves website style or formatting)

Checklist✅

[x] I am an Open Source contributor
[x] I have performed a self-review of my code
[x] My code follows the style guidelines of this project

Screenshots/GIF📷

@Rakesh9100 I've added the hover effect, kindly review the PR.

@Rakesh9100 Please review the PR.

@Rakesh9100 This PR is reviewed  & can be merged.

@sharmi4590 Please merge the PR.

@sharmi4590 Please merge the PR.

@TaeMochi12 I am not the PA


How to use this?

Maybe I missed something but I don't see a mention of how to use this in the README.
It does mention "you might want to just install docs application" but I think it would be good to have just a short mention of how this is meant to be used.
Or maybe a link to more general information about this project - I landed here by search for "AEM Exceptional Experiences" on the web, maybe I should have landed elsewhere ;-)

Salut Bertrand!
You know how it is, you write in some descriptions what you want your project to be, Sling has not always brought the fun ;-)
This project is used by us, but on hold in its progress waiting for some internal product performance issues on heavy dialogs to be solved.
However your point is valid thought, and we'll work on a better "first glance" experience


Allow for access to imageData on L.ImageOverlay

This implements the changes in https://github.com/Leaflet/Leaflet/pull/2621 for cross origin tiles for L.ImageOverlay so that the image data can be accessed in canvas and saved.

Thanks! Squash into one commit and I'll merge :)

:shipit:


akash-node: add new snapshot provider - snapshots.akash.network

zblocker64 pinged me about new snapshot URL's
mainnet snapshots - https://snapshots.akash.network/akashnet-2/akashnet-2_latest.tar.lz4
sandbox snapshots - https://snapshots.akash.network/sandbox-1/sandbox-1_latest.tar.lz4
Both are updated every hour and testnet support is coming soon.
We should add these to the Akash Provider.
Relevant code path:
https://github.com/akash-network/helm-charts/blob/provider-11.0.2/charts/akash-node/scripts/init.sh#L41

Dimokus will be working on this one.

https://github.com/akash-network/helm-charts/pull/293


Adding new dataset

I greatly appreciate your contributions and the time you've dedicated to this project. I plan to use this code in my work, as I have conducted experiments similar to the Palestinian dataset and now wish to include the dataset named "ind." I’ve already added a subfolder named "ind" within the data folder and made the necessary changes to the code.
While I managed to simulate the code successfully—Streamlit launches, and it displays the data and animations—the issue arises with the fundamental diagrams. Specifically, I encounter an error message stating "something went south." Additionally, the ind.pkl file in the app_data folder is empty, and the proximity_analysis_results_euc.csv file does not include the "ind" data.
I suspect the issue might lie in the code being restricted to the provided countries, or there may be a specific part of the code that I need to modify but haven’t understood. Could you kindly guide me on what changes are needed to resolve this issue? Thank you for your support.

To Calculate "proximity_analysis_results_euc.csv" we don't use the app, since the calculation takes some time.
There is this script that has to run before to calculate the proximity results as csv file.

Thank you so much. I was confused about the output CSV file. When I run the code, I got proximity_analysis_results_arc, and when I run it using Streamlit, I got proximity_analysis_results_euc. I hope both are the same?

Nice that you made progress.
Actually, "Arc" and "Euc" are two different methods to calculate the distances between neighbors.
In the first tab of the app, you can see a short explanation:

Notice also the title of the plot: It shows both distances. It's a small difference, depending on the density.
According to this line
the file name reflects the used method, which you define in this line.
If you have other questions, please do let me know. We are happy that you find this work useful and helpful for your own research.

Why do we have only one CSV saving option for proximity_analysis_results_arc, and how can we save the Euclidean analysis results without using Streamlit?...Thank you sir

Because these calculations take some time. So, we decided to do it in the script this way, without need to use the app.
(streamlit is slow).
If you need the file for the Euclidean distances, then:
method = Method.VECT

For arc distances
method = Method.ARC

If you use the script as is, without changes, then you should get EUC-distances.


Seperated CLI actions from study_parser

This PR makes the following changes:

Moves the logic of the various CLI actions into their own files

Light refactoring to make actions functional rather than class based

renamed a lot of vars to more explictly indicate what things are parsing a manifest specifically

Checklist

[X] Consider if documentation (like in docs/) needs to be updated
[X] Consider if tests should be added
[X] Update template repo if there are changes to study configuration

Actions is fine! In an argparse sense, they are "subcommands" - in the ETL I usually use the word "command" for this kind of thing.

I thought about reusing subcommands, but since the CLI subcommands -> actions mapping is not exactly 1-1 (some clean is invoked before a build), i liked a little seperation.


As a website owner, I want to measure automated test times, so that I can identify areas  for improvement and optimize the testing process.

Acceptance Criteria

The system should allow the user to initiate automated tests and record the
start time and end time of each test.
The system should calculate the total time taken for each automated test.
The system should provide a report showing the time taken for each automated
test and the total time taken for all tests.
The system should allow the user to initiate automated tests and record the
start time and end time of each test.
The system should calculate the total time taken for each automated test.
The system should provide a report showing the time taken for each automated
test and the total time taken for all tests.
The system should allow the user to initiate automated tests and record the
start time and end time of each test.
The system should calculate the total time taken for each automated test.
The system should provide a report showing the time taken for each automated
test and the total time taken for all tests.

Story Points: 2
Estimation: 1-2 days
Resources: testing tools, analytics tools, automated testing frameworks.
Estimation: 1-2 days


the target "nextInLine([5,6,7,8,9], 1) could return 5 by this code, but it still shows error. Is it bug?

Challenge Stand in Line has an issue.
User Agent is: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
 Please visit the HelpJS Room for assistance with the challenge.

Hi @jimmyyang886! Thank you for reporting this issue.
This is a standard message notifying you that this issue seems to be a request for help. Instead of asking for help here, please click the "help" button on the challenge on freeCodeCamp, which will take you to the help chatroom for that specific challenge. You can also view our full list of official chatrooms.
I would agree that this is a confusing issue, it took me longer to spot than it should have 😅
If you think I'm wrong in closing this issue, please reopen it and add further clarification. Thank you, and happy coding.

Thank you very much, I will use help if I meet other issues in the future.


Add ability to run external binary modules

Til now, RVS runs only modules that are compiled as part of RVS code as shared objects , this module enables us to run pre compiled external binaries via conf file .
Can run one module at once via conf now. can modify test-path and test-args .

Add new module details in rvs/src/rvsexec.cpp and rvs/src/rvs_interface.cpp as well.


Nan loss with Unet baseline model

Hi,
I keep getting Nan loss at around 40 epochs. Was this something you also experienced ? I haven't changed anything in the code yet and just run everything out of the box. And if not could you tell me what was the learning rate that you might have used then ?
but before the Nan loss I was able to get a model with Dice loss of 0.6328.

Hi @mylifeasazucchini ,
We didn't experience this issue, but we would recommend using the swinuneter, which can obtain better performance than U-Net.

Using the swinunetr baseline I have  the same problem（the loss is nan), but I didn't  find the problem when I use other data.

I have same issue

@hasukmin12 @good-demo I think it would be good to open a new issue coz according to github rules, I can't reopen issues closed by the author :( so I am not sure he will notice them if you comment on a closed issue. (but also link it back to this issue for context!)

@mylifeasazucchini @good-demo @hasukmin12  Please make sure that the monai version is 0.9.


OAuthService RefreshUserTokenRestRequest GuzzleHttp Exception

Getting this uncaught exception if the refresh token goes bad:
PHP Fatal error:  Uncaught GuzzleHttp\Exception\ClientException: Client error: 'POST https://api.ebay.com/identity/v1/oauth2/token' resulted in a '400 Bad Request' response:
{"error":"invalid_grant","error_description":"the provided authorization refresh token is invalid or was issued to anoth (truncated...)
 in vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113
Stack trace:
#0 vendor/guzzlehttp/guzzle/src/Middleware.php(65): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response))
#1 vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response))
#2 vendor/guzzlehttp/promises/src/Promise.php(156): GuzzleHttp\Promise\Promise::callHandler(1, Object(GuzzleHttp\Psr7\Response), Array)
#3 vendor/guzzlehttp/promises/src/TaskQueue.php(47 in vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113

As a work-around, I set httpOptions => http_errors = FALSE and used this to catch the error $response->getStatusCode() == 400 && $response->error == 'invalid_grant'. It seems like this should be the default setting since eBay is returning a valid response object.


Add files via upload

Montgomery college, Maryland added

@gochristo I am sorry, the domain montgomerycollege.edu is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Program. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).


.nth changes as you click things

What is your Test Scenario?
  When you click these buttons they are replaced w/ a different button showing the quantity in your cart.  I'd like to click 3 of these buttons in order w/ test code like this:
const buttons = Selector("button").withText("Add to cart");

await t
  .click(buttons.nth(0))
  .click(buttons.nth(1))
  .click(buttons.nth(2))

What is the Current behavior?
Currently this will click the 1st button then the 3rd and then nothing (because there are only 3 on the screen).
I did some experimenting and if I always use .nth(0) it will work, or if i do it in reverse order (2, 1, 0) it will work as well.
What is the Expected behavior?
I would expect to be able to do it in the order the user would probably do it (from left to right - 0, 1, 2)
What is your web application and your TestCafe test code?

const buttons = Selector("button").withText("Add to cart");

await t
  .click(buttons.nth(0))
  .click(buttons.nth(1))
  .click(buttons.nth(2))

Your website URL (or attach your complete example):

Your complete test code (or attach your test files):

Your complete configuration file (if any):

Your complete test report:

Screenshots:

Steps to Reproduce:

Go to my website ...
Execute this command...
See the error...

Your Environment details:

testcafe version:   1.8.3
node.js version:   12.x
command-line arguments:
browser name and version: chrome 81
platform and version:   mac
other:

Thank you for submitting this issue. TestCafe does not monitor what happens on your web page with the buttons and clicks the existing buttons in the order you specified. I recommend that you modify the button selectors so that they correspond to your current page behavior.

@AlexSkorkin there should at least be a note about this in the documentation.  I think you can see how it might confuse people no?

Something that says that ".nth" is calculated in real time and not ahead of time.  Something to that effect

Thank you for your idea. I passed it to our technical writers.

Fixed in https://github.com/DevExpress/testcafe/pull/5386


Shader Material First Rendering Is Black

Tested versions

Reproducible in: 4.3.rc1.mono

System information
Godot v4.3.rc1.mono - Windows 10.0.19045 - Vulkan (Mobile) - dedicated Intel(R) Iris(R) Xe Graphics (Intel Corporation; <IP_ADDRESS>92)
Issue description
No shader:

If you add a ShaderMaterial to it and set a shader (the code can be viewed below):

To make it not render as black, just change the filter parameter:

Then change it back to 1.0: (Desired Rendering Results)

Steps to reproduce

Create a shader:

shader_type canvas_item;

uniform float filter: hint_range(1.0, 2.0, 0.1);

void fragment() {
	 vec4 tex = texture(TEXTURE, UV);
	 COLOR = vec4(tex.rgb * filter, tex;)
}

Select a control and add a ShaderMaterial, while setting the shader to the one you just created.
Your control will be rendered in black.
change the parameter called filter to another value and change it back to 1.0. You will notice that although the filter parameter was also 1.0 when you added the shader, it does not appear black this time.

Minimal reproduction project (MRP)
N/A

If I had to guess, I would say that the default value is 0, but the editor clamps the displayed value to 1 because the range is 1-2.
Following your reproduction steps then checking the resulting .tscn file, I can see the filter value is indeed defaulting to null
[sub_resource type="ShaderMaterial" id="ShaderMaterial_aqsde"]
shader = ExtResource("1_dplo5")
shader_parameter/filter = null

After searching existing issues, it turns out that this is a duplicate of a known issue, https://github.com/godotengine/godot/issues/44454
Accordingly, I will close this issue in favour of https://github.com/godotengine/godot/issues/44454 so that we can track the problem in one place


bug report

VSCode Version: Code 1.14.0 (b8cd5b9556d8b70ea560d35b903422363f6c5c40, 2017-07-10T18:24:22.120Z)
OS Version: Darwin x64 15.4.0
Extensions:

Extension
Author (truncated)
Version

velocity
sod
0.1.0

Steps to Reproduce:

Reproduces without extensions: Yes/No

Missing details.


Remove Oxygen-specific fetch workaround

This is no longer relevant https://github.com/Shopify/hydrogen/blob/main/packages/hydrogen/src/utilities/fetch.ts#L24-L42
I think we can revert this and pass in body/headers/etc normally now, since Oxygen supports more of the Fetch spec.
PRs to "revert" (for Shopifolk):

https://github.com/Shopify/hydrogen-archive/pull/730/
https://github.com/Shopify/hydrogen-archive/pull/773

cc @maxshirshin

@nishit-g sounds good! Thanks for contributing.
FYI the resulting code should essentially be:
const response = await fetch(request.url, request);
const data = await response.json();

😄


Fibaro covers doesn't report state after update to 1.13.1

After updating to 1.13.1 my fibaro covers doesn't report the state.
I can see in the zwave log that the covers are sending the update, but in HA there is no change in the state.

Hi there @memphi2 👋
Add-ons wrap existing software in a way they are easy to use and install with a Home Assistant instance. In this case, it wraps Z-Wave JS UI. The issue you are reporting is with the upstream software packaged, not the add-on itself.
Please report this issue upstream with the Z-Wave JS project. Once they address the issue and release a fix for it, the add-on will be updated.
Thanks 👍
../Frenck


[FLINK-9594][E2E tests] Improve docs for new test runner

What is the purpose of the change
Improve documentation for end-to-end tests with the new test runner pattern introduced in FLINK-9257
Brief change log

Add more docs

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

@tzulitai or @zentol Can you skim over this if you have some time?

Thanks for proof-reading! I addressed your comments and squashed the PR


fit-textareas broken

Description
#7011
How to replicate the issue + URL
This issue
Extension version
23.10.5
Browser(s) used
Firefox 119.0

Hmm, actually it works here now...

Maybe it's rather caused by #6554.

Maybe it's rather caused by #6554.

That is only related to files/folder at the moment, because the entire UI including navigation is a single app that spans across multiple pages/urls.

Ah, I see. Let's close this issue then until I can reproduce it reliably.