Example:

[nix-shell:~/Projects/nixops]$  ./coverage-tests.py -a '!libvirtd,!gce,!ec2,!azure' -v
nose.plugins.cover: ERROR: Coverage not available: unable to import coverage module
tests.functional.test_ec2_rds_dbinstance.TestEc2RdsDbinstanceTest.test_deploy ... building all machine configurations...
unnamed> closures copied successfully
unnamed> deployment finished successfully
ok
tests.functional.test_ec2_rds_dbinstance.TestEc2RdsDbinstanceTest.test_deploy_with_sg ... building all machine configurations...
unnamed> closures copied successfully
unnamed> deployment finished successfully
ok
tests.functional.test_invalid_identifier.TestInvalidIdentifier.test_invalid_identifier_fails_evaluation ... error: --- EvalError ------------------------------------ nix-instantiate
in file: /home/wmertens/Projects/nixops/nix/eval-machine-info.nix (51:26)

attribute 'network' missing

I'm using nix (Nix) 2.4pre20200622_334e26b, perhaps that's related?

Don't forget to watch Sander present nix-processmgmt https://cfp.nixcon.org/nixcon2020/talk/TW79FU/ :)

I'm wondering if we should change the API so you always get the cursor and an additional hasMore boolean. This allows paging through future results.

The API change could coincide with the API change I propose in #9 and the transact branch

I think this should return the found result, no?

As for the naming, I'm 90% ok with it, but I wonder if something like eachUntil might be better?

2 more considerations:

• each could also do this, by passing a stop token; if you return it, processing stops: .each( (item, STOP) => item.bar && STOP)
• I want to change the current meaning of limit, it is currently used to choose the number of items per run, I think it should mean the number of items total. Instead there should be something like pageSize = 50 and workers = 5 to load results per 50 and run 5 fns in parallel

Mystery solved: The timeout was shorter than the communication interval with the SP server. I changed the interval and now the error doesn't happen any more.

So basically, the token gets refreshed automatically, but it does pass this error. Should this error not be hidden and the call retried with a fresh token?

This went away by itself it seems, but now it's back and I don't really know how to refresh the token apart from restarting the app. Any pointers on how to debug this would be greatly appreciated.

Just a minimal message to let devs know that their DEBUG_x variable couldn't be parsed

I've been using =y without realizing that doesn't work

Indeed, this is all technically possible and even desirable, and if this were JavaScript someone would probably have already done it.

I know there is a Haskell parser for Nix, perhaps that project can do the heavy lifting.

There's also nixjs written by @svanderburg but I don't know if it is at a level that it can extract dependency trees from Nix.

Even something that copies all the files that might be needed instead of only the files that are needed would be great.

@tobiasBora It's not as easy as it sounds because the configuration needs to be complete. So in fact the configuration.nix would need to set the environment to what it is on the build host, import the nixops deployment configuration and extract its host configuration, and include all its nix dependencies. Possible, but not trivial.

But indeed, adding your own cache is probably pretty easy and then what you propose would be really nice. The added bonus is being able to run nixos-rebuild on the server and it working.

Which distribution and version?: NixOS 21.03pre244932.84d74ae9c9c (Okapi)

Which desktop environment and version?: Gnome 3.36.2

Which session type?: Wayland

Which application and version?: all

IBus version?: IBus 1.5.22

Issue description: When I enter emoji picker mode (it shows e̲), and I type:

• (space), it immediately shows an emoji picker. Selecting the monkey emoji immediately gives 🐒e
• e, it takes 17 seconds before it shows ee̲e̲. Pressing enter gives ee
• a, it takes 17 seconds before it shows a. Pressing enter gives a
• monkey (with space), it takes about 10 seconds before it shows e̲🐒. Pressing enter gives 🐒
• monkey ↩️ (with space and return), it takes about 6 seconds before it shows 🐒

Can you reproduce your problem when you restart ibus-daemon? (yes / no): (Run ibus exit and ibus-daemon --xim &) yes/no:

• I can't call the emoji picker any more in Chrome (XWayland)
• The very first time I call the picker in Gnome Terminal (Wayland), it's instant. The second time, things are slow again

Do you see any errors when you run ibus-daemon with the verbose option?: (Run ibus-daemon --xim --verbose & and look at the output when you encounter your problem.) no

Can you reproduce your problem with a new user account instead of the current your account? (yes / no): didn't try yet

Explanation about the vulnerability here: https://github.com/alwentiu/COVIDSafe-CVE-2020-12856

The Australian app worked around it by forcing the use of v28 of the Bluetooth API, but that will no longer be supported for distribution of updates in November: https://developer.android.com/distribute/best-practices/develop/target-sdk

So, if this app does the same, it won't be possible to distribute updates any more.

Thank you kindly! Closing.

Explanation about the vulnerability here: https://github.com/alwentiu/COVIDSafe-CVE-2020-12856

The Australian app worked around it by forcing the use of v28 of the Bluetooth API, but that will no longer be supported for distribution of updates in November: https://developer.android.com/distribute/best-practices/develop/target-sdk

So, if this app does the same, it won't be possible to distribute updates any more.

I think this fixes some hangs for me with some remote shells expecting stdin somehow; I'm just not sure if it's always ok to close the channel. Perhaps there should be an option to keep the channel open, or perhaps it shouldn't be closed if onChannel is passed and that should be the responsibility of the caller?

@abathur I hadn't seen that, it looks impressive! Seem like @svanderburg found a nice middle ground between service-specific and service-agnostic.

I wonder how far along this is to be able to boot e.g. nixos-minimal with a different service manager.

I'm experiencing the same thing from time to time. I don't think it's the file descriptors, /proc/$PID/limits shows Max open files 524288 524288 files, and lsof -p shows it using 26 fds.

This is happening via node-fetch, which is just using http(s).request, which just uses dns.lookup, which goes to the Linux nscd, which is almost certainly beyond reproach. The lookups are for a very small set of names that are used in a bunch, every few minutes, so caching should be perfect.

I never see these issues with other programs, only Node.js.

Would it not be an option to have Node.js perform an automatic retry when busy?

Are there other failure conditions that could cause this error?

Great idea IMHO - doesn't this also need some API to enumerate discovered tests and to run them?

@apples so beforeAll is almost what you want but it needs better error behavior?

Except that you would also want test.essential to apply halfway in a file; I wonder if that would not be better expressed by beforeAll in a describe block (not sure if possible but sounds nice)

A practical proposal to store build products under their output hash instead of their input hash.

Very well, closing for now. I'm about 50% into a rewrite.

@gera2ld That actually involves more clicking, because you can only have one selection: Select something, move to buttons, click "patch", repeat.

Great ideas! In fact, I'd like to see indirect dependencies in a different background color, so you can see without highlighting how much is actually used by direct imports.

And when you hover on a dependency, highlighting all its dependencies (all the way to the leaves) would indeed be great

It may read a little bit weird, but that's exactly what beforeAll does - if it fails, none of the tests run.

@foisonocean can you try building with webpack 5?

@apples would your use-case not be served already with beforeAll? With perhaps a test on a global that beforeAll sets up?

Would it be possible as a quick win to add a button for toggling all? Just an idea, not worth blocking this over.

Any change is an improvement here :)

@rnhmjoj indeed, this fixes the problem. I'd make a PR, but I can't find any other examples of X-RestartIfChanged being used in modules :-/

• Operating System: Linux 5
• Node.js version: 12
• fs-extra version: latest

As you can see in https://github.com/jprichardson/node-fs-extra/blob/6bffcd81881ae474d3d1765be7dd389b5edfd0e0/lib/move/move.js#L34-L37, when overwriting, the target is first removed.

However, the rename call already removes the target, and this is an atomic operation.

So IMHO, move should only check if the target exists when not overwriting, it should not delete the file itself. (and if the source and target have the same inode, it should not count as already existing, #801)

@enriqu3l I don't like the test.essential because it's extra information you need to provide and maintain.

With test.result, you enforce a dependency when you need it and only when you need it, and as you stop needing it the dependency will be removed as well. You can even wait for multiple tests in a single test.

How about a select strip: when you use the mouse you need to click and drag to toggle lines. For touch, you simly need to touch and drag. The first state you toggle is the one that is repeated across the drag. That seems very fast to me.

It needs to be a strip because otherwise you can't scroll any more on touch surfaces.

I have this in my config:

  i18n.inputMethod.enabled = "ibus";
  i18n.inputMethod.ibus.engines = with pkgs.ibus-engines; [
    typing-booster
    uniemoji
  ];

When I use the ctrl-shift-e shortcut, it behaves very erratically, doesn't show a dropdown, laggy etc. When I use the uniemoji input method, everything is fine.

cc @ericsagnes

I would love this too, it is quite annoying to select a branch and then go hunt for the checkout button. Double-click is very natural.

Ideally, you'd simply select a bunch of lines and then there's a popup to select/deselect. This works easily with touch, too.

Also, a toggle all lines button would be great.

Running nixops as regular user id 1000 with these specs:

$ df -hl
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         50M     0   50M   0% /dev
tmpfs           494M     0  494M   0% /dev/shm
tmpfs           247M  4.2M  243M   2% /run
tmpfs           494M  336K  494M   1% /run/wrappers
/dev/vda2        23G   12G   11G  52% /
/dev/vda2        23G   12G   11G  52% /nix/store
tmpfs           494M     0  494M   0% /sys/fs/cgroup
tmpfs            99M   16K   99M   1% /run/user/1000
tmpfs            99M     0   99M   0% /run/user/1003
tmpfs            99M     0   99M   0% /run/user/0

causes the opaque error tar: no space left on device

The reason is that nixops uses TMPDIR which points to /run and is limited to 100M.

What would be a good way to tell the user about this problem?

@mengdonglin I had a look at the PR but couldn't see any documentation. Is there somewhere an explanation of how to use this? Thanks :)

@colemickens Is the ozone build somewhat usable? Would you mind pointing me to how I can get a nixpkgs-wayland setup working?

Ah - originally I did break it out but then we agreed not to do that after all https://github.com/NixOS/nixpkgs/pull/2482#issuecomment-42113475

Ah cool. As for (2), until the replacement is ready, an option would be to unlink() the temp files as soon as all parties have a handle to the inode. Then they are pre-cleaned up. This won't work on Windows of course.

So wouldn't it be easier to just rename the file and pass any errors to the user instead?

... And in that case, just call rename(). I can't think of a case where it would fail

But wouldn't you have to do that for every directory you access?

perhaps better to simply not test for this. If the stat() result is the same, it's the same file.

Linux also has case-insensitive filesystems, and it can network mount CIFS which is also case-insensitive. So the only way to test this is to see if you can access a file on the filesystem you want to work with via another casing that doesn't exist yet.

I updated #10077 with a new API which I've been using for a while and works great:

const result = test.result('test name')

It doesn't need any big changes, it is robust when you move tests around, it's easy to read, it can do sync and async results etc. I really like it.

@ProTip FYI based on your piping magic I did https://stackoverflow.com/a/63793635/124416, thanks!

which is why I had to use .connection.shell in https://stackoverflow.com/a/63793635/124416

Thanks! What webpack version is this?

I also don't think subscription-transport-ws should be taken as a role model. It has to implement a separate server whereas the approach above should only provide a resolver for subscriptions (in theory). The SSE channel can be managed by an apollo-link, which could probably create the channel just before a subscription request is sent.

SSE is better than websockets:

• no extra port needed
• works with http2
• less resources
• very good browser support

The only disadvantage is that to send something to the browser, you have to go via HTTP instead of on an existing channel so you have a little more lag when sending. But with http2 that's not a problem.

I took a look at these, the commit only converts from executionIterable to executionPromise, a small change. The scivisum fork doesn't seem to include anything that would make it compatible with Apollo again, and it adds the requirement that requests are passed via the url.

I'd prefer a system where you set up an SSE stream (or multiple) for getting results, and when you post the subscription query, you start getting the results in the stream. To know which stream to post to, you can use a secret token that you receive when opening the stream and then pass it to the server via a cookie (technical cookie excempt from cookie law), a header or even an unused query variable.

not necessarily - it's been a while, but I believe it just keeps its own dependencies in its own tree and it builds them too. Adding an overlay seems like a lot of extra work.

Oh wow sorry I missed this. Actually I recently did an upgrade without encountering issues :thinking: I'll try to reproduce the problem and then I'll apply this change.

For the edge between two colors I'd love to see a gradient, which is different from the solid color edges at almost every point

For the overlapping, I think that the only problem would arise when two edges are fully on the same trajectory. Then it would be important to paint the edges together with their nodes, so that overlapping edges would also overlap nodes and make the overlap more obvious.

Either way, wouldn't it already be an improvement on the current situation, even if it may not be perfect yet?

It seems that the only script tag supported is one with a src.

It would be nice if <Helmet><script>window.foo=5</script></Helmet> would also work.

You're probably right - https://github.com/staylor/react-helmet-async/blob/23a15037d90ab26a5ad5680d4cf194698bbbf0a1/src/client.js#L18-L19

I'll close this - it doesn't execute the script unless it is loading the page via SSR but that's another issue

Agreed, it's my fault, sorry. This was the first thing I did for nixpkgs and I split handbrake into the component packages because I thought it was cleaner. In reality many of those libraries are abandoned and applying the handbrake patches might not necessarily be a good idea.

I just had this thought so I'm just writing it here: How about implementing the ssh by calling shelljs on the remote? This requires Node on the remote of course, but it would greatly improve the reliability versus calling ssh.

There's node-ssh which provides a native, and then the api could look like this:

const rsh = await shell.ssh(ssh2ConnectOptions) 
const files = await rsh.ls('**/*.js')
if ((await rsh.exec('echo hello')).code) throw "argh"
await rsh.cat('*.txt').toRemote('combined.txt')
rsh.dispose()

So the advantage would be that shelljs has access to the real data on the remote, and not just strings, and the result of exec etc can be transformed to ShellString which is nice to work with.

I can't think of a way to make the async functions sync though.

well this is ominous, and it's still open? How can shelljs have a security vulnerability when it's just wrapping system methods and not providing any privilege escalation?

<!-- Please don't delete this template because we'll close your issue --> <!-- Before creating an issue please make sure you are using the latest version of webpack. -->

Bug report

<!-- Please ask questions on StackOverflow or the webpack Gitter. --> <!-- https://stackoverflow.com/questions/ask?tags=webpack --> <!-- https://gitter.im/webpack/webpack --> <!-- Issues which contain questions or support requests will be closed. -->

What is the current behavior?

During development, webpack.hot is an object with members like accept. In a production build, webpack.hot gets replaced by false. If you use webpack.hot?.accept(), this will get replaced by false?.accept(), which breaks.

If the current behavior is a bug, please provide the steps to reproduce.

Use hot module replacement and call module.hot?.accept(), then build a production build.

<!-- A great way to do this is to provide your configuration via a GitHub repository --> <!-- The most helpful is a minimal reproduction with instructions on how to reproduce --> <!-- Repositories with too many files or large webpack.config.js files are not suitable --> <!-- Please only add small code snippets directly into this issue --> <!-- https://gist.github.com is a good place for longer code snippets --> <!-- If your issue is caused by a plugin or loader, please create an issue on the loader/plugin repository instead -->

What is the expected behavior?

In production builds, module.hot should be replaced with undefined

<!-- "It should work" is not a helpful explanation --> <!-- Explain exactly how it should behave -->

Other relevant information: webpack version: 4.44.1 Node.js version: 12.18 Operating System: Linux Additional tools: n/a

nevermind, I see that there are tests for this in v5. https://github.com/webpack/webpack/commit/13b417f27df0adeb4f71c1d305c137c8d33c8ab7

<!-- Please don't delete this template because we'll close your issue --> <!-- Before creating an issue please make sure you are using the latest version of webpack. -->

Bug report

<!-- Please ask questions on StackOverflow or the webpack Gitter. --> <!-- https://stackoverflow.com/questions/ask?tags=webpack --> <!-- https://gitter.im/webpack/webpack --> <!-- Issues which contain questions or support requests will be closed. -->

What is the current behavior?

During development, webpack.hot is an object with members like accept. In a production build, webpack.hot gets replaced by false. If you use webpack.hot?.accept(), this will get replaced by false?.accept(), which breaks.

If the current behavior is a bug, please provide the steps to reproduce.

Use hot module replacement and call module.hot?.accept(), then build a production build.

<!-- A great way to do this is to provide your configuration via a GitHub repository --> <!-- The most helpful is a minimal reproduction with instructions on how to reproduce --> <!-- Repositories with too many files or large webpack.config.js files are not suitable --> <!-- Please only add small code snippets directly into this issue --> <!-- https://gist.github.com is a good place for longer code snippets --> <!-- If your issue is caused by a plugin or loader, please create an issue on the loader/plugin repository instead -->

What is the expected behavior?

In production builds, module.hot should be replaced with undefined

<!-- "It should work" is not a helpful explanation --> <!-- Explain exactly how it should behave -->

Other relevant information: webpack version: 4.44.1 Node.js version: 12.18 Operating System: Linux Additional tools: n/a

This is a polyfill for IE:

		Element.prototype.closest = function (s) {
			let el = this
			if (!document.documentElement.contains(el)) return null
			do {
				if (el.matches(s)) return el
				el = el.parentElement || el.parentNode
			} while (el !== null && el.nodeType === 1)
			return null
		}

it needs access to this and function-component-definition complains about it.

these Darwin/Linux comments are confusing, neither line looks at the platform, so other platforms presumably get the Nix libxml2 as well?

This is great :) now how to test it...

...ok, but they are indistinguishable in code?

function Foo({bar}) { return <span>{bar}</span/> }
function renderFoo({bar}) { return <span>{bar}</span/> }

They might, and in #2771 the examples actually do

This would be a render function, which is passed to a component and gets called as part of the render phase

@ljharb no, they weren't ignored before this PR, this PR only adds being part of an object

Just registering my WiP PR for an ignore option. Would fix #93 by way of fixing #96

Ignore the prettier changes, I'll reduce that to the essentials

#101 is a better approach