Display bug of response body and line numbers

Describe the bug
Display bug. The response body is below the line numbers.
Expected behavior
The query response should be shifted a bit to the right.
Screenshots
https://i.imgur.com/mZMlnIt.png
Desktop (please complete the following information):

OS: Windows 10

Hey @devistar thanks for reporting. This is a tricky recurring problem that has been difficult to solve with codemirror without using their auto refresh plugin. I disabled that plugin because it was causing Altair to be CPU intensive, since it constantly has a timeout running in the background.
Part of why it is difficult to solve is because it appears it isn't always reproducible for me.
Maybe the solution is very straightforward but I still haven't figured out the best way to tackle it. I'm still looking into it though.

Does this still happen? I haven't experienced it in a while

It's happening to me on the desktop client, I just downloaded it for the first time

@OliverLeighC what steps caused this to appear?

v2.5.2 is the version. In terms of steps, I just typed in a query and clicked 'send request' and the results appeared like that 100% of the time.


Create manifest.json

@googlebot I signed it!

@suniltheblue can you delete the second PR (#68) and add all the commits to this one that you would like. Also, are you still interested in merging this? If I do not receive a response in 30 days I will close both requests.


Jesse: Watch (?-i:Sporview)(?#t.me)

Jesse requests the watch of the watch_keyword (?-i:Sporview)(?#t.me). See the MS search here and the Stack Exchange search in text, in URLs, and in code.

(?-i:Sporview)(?#t.me) has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Adding a pre loader to the website

Description
The website loads in a few milliseconds. While the website is loading , a pre loader can be added to the website.
Screenshots
No response
Additional Information
If you want I can also add a HTML CSS javascript loader

I am a gssoc'23 contributor

Hey @Illaf This website is built with Next.js and React.js so normal html js won't work. Files mostly have .jsx extension

Let me know if you can do it and also what type of preloader you have thought to add?

Also, this seems a duplicate issue like #133 #259


Neon.Temporal mutex deadlock

There is a deadlock occurring in Neon.Temporal.Worker.Workflow.  The deadlock is caused by the mutex lock workerMutex.  The deadlock occurs on line 266 of Neon.Temporal.Worker in the GetWorkflowRegistrationAsync() function.  The function attempts to acquire workerMutex even though it was already acquired by the function that called it (line 355 of Neon.Temporal.Worker.Workflow in the OnInvokeAsync()).  The side effect is that an invoke reply is never sent back to the executing workflow so the workflow locks up after the first decision task and times out.

Fixed


Virus detected in the Squirrel framework

VirusTotal has detected a virus/malware PUA.OSX.Adware in Squirrel inside the framework folder.
I resolved it by manually updating the Squirrel framework.

I'm not sure how to solve this. It sounds like we need to update electron-builder and do a new release?

Are you using Windows? May it be related to this https://github.com/atom/atom/issues/16986 ?

I'm using the macOS

How did you manually update Squirrel?

I downloaded the latest Squirrel.framework from https://github.com/Squirrel/Squirrel.Mac/releases
unzipped it and replaced the old one found here: /Applications/Protonmail\ Desktop.app/Contents/Frameworks/Squirrel.framework

@GalaxyHopper This seems to be fixed in our latest release; https://www.virustotal.com/#/file/6de5a01198143fea4ea9df0f52a6214bd695daa90dc86a9f137467555e06027b/detection
Can you download the new version and verify?

@kontrollanten I installed the new version and the files are clean. Thanks a lot!


Support dapps suggesting chains to be added to the user's wallet application

Overview
Inspired by EIP-3085, this design allows Solana applications ("dapps") to suggest chains to be added to the user's wallet application. The wallet application may arbitrarily refuse or accept the request. We have received a request for this feature from many dapps.
Desired Outcome
The desired outcome is for dapps that are on testnets, canary chains, or other SVM chains to be able to conveniently prompt their users to switch networks and seamlessly interact with their dapp and see their assets rather than requiring complex manual custom RPC changes. As more SVM chains spin up, this can prevent a mess with multiple standards and one-off implementations down the line.
Implementation

Solana Wallet Standard: At first glance there are some changes needed to the Solana wallet standard. There are places where the wallet is required to return all chains that it supports, so we would need some interface for the dapp to pass back a new chain to be added: https://github.com/solana-labs/wallet-standard/blob/master/packages/wallets/solflare/src/account.ts#L25 This change seems like it could be made immediately if it is done in a non-breaking way. The wallet should not be required to add a chain even if the dapp requests it.
Wallet Adapter: We would need to make some change to the wallet adapter so the dapp can specify the desired RPC network. This would need to be rolled out after the Wallet Standard change.
Dapp Support: The dapp updates their Wallet Adapter library and specify their desired RPC network. If no RPC network is specified, by default this change has no effect - the behavior is exactly the same as SVM wallets function right now (default to Solana mainnet). This is the last change to occur.

Thanks for opening discussion on this. First a few unstructured thoughts about security that come to mind --
I haven't noodled on this very hard yet, but I could imagine that allowing applications to add custom RPCs increases the possibility of signing and/or simulating transactions against malicious RPCs that may deceive the wallet user.
Unlike EVM transactions, Solana transactions don't include a chain ID in the message that gets signed, only a recent blockhash / nonce account. Wallets would likely need to check blockhashes they get back from custom RPCs against, at minimum, Solana mainnet blockhashes / nonces. This problem will become worse if users have value on multiple SVM chains that wallets aren't checking.
Will consider this some more, but how are you thinking about this?

Could we elaborate a bit on the threat of a dapp suggesting a malicious RPC? Is this threat worse than what a dapp can accomplish already?

Wallets would likely need to check blockhashes they get back from custom RPCs against, at minimum, Solana mainnet blockhashes / nonces

If a user is connected to a custom RPC, could you elaborate on the reason to check blockhashes against Solana mainnet? The user might be connected to a different cluster altogether.

the threat of a dapp suggesting a malicious RPC

A wallet that exposes a signAndSendTransaction (or signTransaction) API will typically use an RPC's simulateTransaction API. This works (in the sense that the result is somewhat trustworthy) because the RPC is chosen by the wallet. If a malicious RPC is provided by a malicious app, the RPC can lie about the result of transaction simulation, or any other state or transaction history of the chain. This can be used to induce a user into signing unsafe transactions.

the reason to check blockhashes against Solana mainnet

By extension of the above, if I'm a malicious app providing a malicious RPC, I might ask you to add an RPC for something arbitrary, let's say it's called mychain:testnet. You do this, thinking it's safe. But this RPC returns a blockhash (e.g. using getLatestBlockhash) that would be valid on solana:mainnet. You sign it and send it to the RPC, the RPC replays the transaction on Solana mainnet, you get rugged.

The simulateTransaction concern is a tricky one. To be fair even simulateTransaction under normal circumstances could lead to an unintended outcome.
On the RPC point - what if we optionally allow folks to include a restriction on the cluster name in their signed transaction? Seems to mitigate this risk.
I think without this feature there will be substantial headwinds in pushing the SVM as a standard so interested to work with y'all to address these threats!

Another possible approach is having wallets maintain a registry of approved RPCs, so a reputable dapp with an app chain can get whitelisted.

what if we optionally allow folks to include a restriction on the cluster name in their signed transaction

This cannot be done without changing the wire transaction format. If a malicious dapp is using a malicious RPC, it doesn't matter what either of them says about the cluster they are targeting. Solana needs to implement something like EIP-155 for this to work.

Some discussion about this @ https://discord.com/channels/428295358100013066/885976714646290473/1073664382011191396

Would love to see this implemented as I think making it easy for a user to switch to another chain (especially Devnet) will be crucial to allow users to explore and experiment on Devnet.
I get there's a bit of complexity here, but I think @PrasoonPratham 's whitelist suggestion is a good starting point. At a minimum, being able to at least easily switch between the hardcoded dev/test/mainnet RPCs would be a huge win imo.

I think this might be 1st good step to enable full cluster API https://github.com/anza-xyz/wallet-standard/pull/65
In later improvements, we can think about adding custom clusters.


Added getters to the points of the KeyLine class

Useful since it is often needed to have the points from the keyline directly in the cv::Point2f format.

:+1:


laravel.EMERGENCY: Log [deprecations] is not defined.

Laravel Version: 9/latest
PHP Version: 8.1
Database Driver & Version:

Description:
laravel.EMERGENCY: Unable to create configured logger.  I can't disable it or stop it regardless of what logging level I set. Seems like this issue has been posted countless times with no real fix or solution.
Steps To Reproduce:
It happens on a fresh install of laravel 9, nothing I do seems to silence it.

Setting LOG_DEPRECATIONS_CHANNEL=daily rather than the default of null seems to have shut it up.

i think we need to open it again because this happens in the default setup


Problem: ops/shell.nix doesn't work on darwin systems

Now that we've fixed the flakes.nix, use the top level shell.nix for CI.

Taking this.

@trevorbernard For me, both the ops/shell.nix (activated with nix-shell ops/shell.nix) and nix develop '.?submodules=1' result in the same build failure, on MacOS:
  error occurred: Command "clang++" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-2" "-fno-omit-frame-pointer" "--target=x86_64-apple-darwin" "-I" "rocksdb/include/" "-I" "rocksdb/" "-I" "rocksdb/third-party/gtest-1.8.1/fused-src/" "-I" "." "-Wall" "-Wextra" "-std=c++17" "-Wsign-compare" "-Wshadow" "-Wno-unused-parameter" "-Wno-unused-variable" "-Woverloaded-virtual" "-Wnon-virtual-dtor" "-Wno-missing-field-initializers" "-Wno-strict-aliasing" "-Wno-invalid-offsetof" "-msse2" "-std=c++17" "-DNDEBUG=1" "-DOS_MACOSX" "-DROCKSDB_PLATFORM_POSIX" "-DROCKSDB_LIB_IO_POSIX" "-DROCKSDB_SUPPORT_THREAD_LOCAL" "-o" "/Users/robinbb/repos/Granola-Team/mina-indexer/target/debug/build/librocksdb-sys-fa9fe77bbb653864/out/rocksdb/db/repair.o" "-c" "rocksdb/db/repair.cc" with args "clang++" did not execute successfully (status code exit status: 1).

Unfortunately, the error message does not say what went wrong, so I'm having difficulty debugging. Are we sure that rocksdb ever compiled on MacOS?
In any case, the problem is not shell.nix versus flake.nix, at present, when it comes to MacOS. However, I agree that we do not need both. So, I will continue to remove one or the other, but MacOS is broken either way for me.

Running nix build '.?submodules=1' yields the following error, for me, on MacOS:
error: builder for '/nix/store/2ah637cf1472r9hkxi1rb6cz99nm18cj-mina-indexer-0.1.1.drv' failed with exit code 101;
       last 10 log lines:
       >   exit status: 0
       >   exit status: 0
       >   exit status: 0
       >
       >   --- stderr
       >
       >
       >   error occurred: Command "/nix/store/adnfb3qi50jn2cqbp8g524rm6mxcwhz7-clang-wrapper-11.1.0/bin/c++" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-arch" "x86_64" "-I" "rocksdb/include/" "-I" "rocksdb/" "-I" "rocksdb/third-party/gtest-1.8.1/fused-src/" "-I" "." "-Wall" "-Wextra" "-std=c++17" "-Wsign-compare" "-Wshadow" "-Wno-unused-parameter" "-Wno-unused-variable" "-Woverloaded-virtual" "-Wnon-virtual-dtor" "-Wno-missing-field-initializers" "-Wno-strict-aliasing" "-Wno-invalid-offsetof" "-msse2" "-std=c++17" "-DNDEBUG=1" "-DOS_MACOSX" "-DROCKSDB_PLATFORM_POSIX" "-DROCKSDB_LIB_IO_POSIX" "-DROCKSDB_SUPPORT_THREAD_LOCAL" "-o" "/private/tmp/nix-build-mina-indexer-0.1.1.drv-0/2wjc5l4c7v0dbsil6kdbs4hf1dniqxak-source/target/x86_64-apple-darwin/release/build/librocksdb-sys-9c18cea12340aeb3/out/rocksdb/db/repair.o" "-c" "rocksdb/db/repair.cc" with args "c++" did not execute successfully (status code exit status: 1).
       >
       >
       For full logs, run 'nix-store -l /nix/store/2ah637cf1472r9hkxi1rb6cz99nm18cj-mina-indexer-0.1.1.drv'.

Anyone else getting this? Anyone else getting successful builds?

Answers arrived on Slack.


Discuss SSR API and methods

I just want to kick off a discussion to finalise our SSR API.
So API came from the comments on the #214
const { css, html } = StyleSheet.collect(() =>
  ReactDOMServer.renderToString(<App />)
);

Please feel free to suggest what the API will look like, (let the bikeshedding begin!)
Also if we're already doing de-duping in SSR level, do we even need reset()? (related issue #378)  Or would that just be a convenience function since we don't need it anymore?
cc @mxstbr / @geelen

One thing I would throw out there is that it would be very useful to be able to have separate bundles of CSS. That way, you could target styles to a style tag or to a separate stylesheet. When I worked for a publisher, we used this type of optimization to achieve very fast initial renders, with nonessential styles deferred until later.
I can ticket this separately, if that would be helpful. It would require some sort of ability to annotate at the component or CSS level where rulesets would be targeted, and an API for collecting the separate bundles (which might be a collect variant).

This happens either way @acjay. With styled-components, only the styles of components that are actually used on the initial render are injected 👍
Generating .css files for server-side rendered apps would not be complicated to add, but should not live in core. (it's more or less just a fs.write(css) away) We're going to work on a babel or webpack plugin to make this possible for non-ssr apps but that's a different issue. (see #59)

@thisguychris, reset() is great for doing testing. Considering that tagged templates have logic in them, that logic may need to be tested.

That's a great point actually @dfrankland, I hadn't even considered that use case!

We will also need to keep track of the classNames that are generated so we can rehydrate them on the client.
For example, this is how glamor does it... https://github.com/threepointone/glamor/blob/master/docs/server.md

Looks good to me

Do we also want to be able to export class names here ( in addition to CSS and HTML) like Aphrodite and Glamor does so that we can consume them on the front end to make sure things stay in sync or are just going to rely on the babel plugin to ensure deterministic class names?

Even if the names are deterministic, you still want a list of the class names, so you don't inject every rule twice.  Either that, or maybe we could have a class attribute on style and links like __styled-component-sheet__, and then just build the list from those sheets.

I don't think we need to worry about duplicate classnames after SSR; just remove the server-provided style block after the app code arrived and let S-C rebuild the styles.

I like what Aphrodite does. Just pass the classnames along with the initial state and rehydrate without rebuilding client-side. Does anyone see any cons with this approach?

@wmertens we do need to worry about duplicate class names because react will check the root elements html on its first render and see if it is the same. If it is then react will resuse it, otherwise it will blow it away and start from scratch (thus defeating the purpose of srr). If the class names are differeent the that first check won't pass.

Oh right that's a different issue, that should be handled by the Babel
plugin.
Actually, I am running v2 with the plugin and it doesn't work for me, the
generated classnames change between server and client.
I don't understand how the names can differ though; given that the entire
render result is normally the same, and the order of evaluation thus also,
shouldn't the generated names be the same as well? If you use a
deterministic naming scheme, that is?
On Wed, Feb 1, 2017 at 4:09 PM Nick Randall<EMAIL_ADDRESS>wrote:

@wmertens https://github.com/wmertens we do need to worry about
duplicate class names because react will check the root elements html on
its first render and see if it is the same. If it is then react will resuse
it, otherwise it will blow it away and start from scratch (thus defeating
the purpose of srr). If the class names are differeent the that first check
won't pass.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/386#issuecomment-276681880,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWllSu0cPLYFXjuDE-W4C8oTCmFuEMks5rYKBDgaJpZM4LnSjo
.

@wmertens I found that in order to get the names to match, I had to make sure each file was transpiled via babel once, and then the result re-used on client and server.  I was initially applying babel twice (once for the server side and once for the client side).  This was resulting in different names.
It would be cool if in the babel plugin, we could make the names deterministic (e.g. use an md5 hash of the file's source)

:( I can't do that, the Babel options for client and server differ…
Strangely, before using the plugin, the names given by S-C were fine…
On Thu, Feb 2, 2017, 1:13 AM Forbes Lindesay<EMAIL_ADDRESS>wrote:

@wmertens https://github.com/wmertens I found that in order to get the
names to match, I had to make sure each file was transpiled via babel once,
and then the result re-used on client and server. I was initially applying
babel twice (once for the server side and once for the client side). This
was resulting in different names.
It would be cool if in the babel plugin, we could make the names
deterministic (e.g. use an md5 hash of the file's source)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/386#issuecomment-276825946,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWlhmKHwxt_XPBUdHM8cSPLJI7uTz3ks5rYR-6gaJpZM4LnSjo
.

I am experiencing the same @wmertens

I think possibly the simplest option might be some kind of .styled-components-cache.json file that could map sha hashes of files + index of styled component to generated class name.  That way we could ensure they were always deterministic, without having to make them long enough to avoid collisions.
On the other hand, if they're currently just random IDs, maybe just converting them to the first few letters of the sha has would be good enough.

For SSR, all you need is "the first one, the second one, ..." since on the
client they will be encountered in the same order. So class names can just
be a prefix with a number.
Right?
On Thu, Feb 2, 2017 at 11:13 AM Forbes Lindesay<EMAIL_ADDRESS>wrote:

I think possibly the simplest option might be some kind of
.styled-components-cache.json file that could map sha hashes of files +
index of styled component to generated class name. That way we could ensure
they were always deterministic, without having to make them long enough to
avoid collisions.
On the other hand, if they're currently just random IDs, maybe just
converting them to the first few letters of the sha has would be good
enough.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/386#issuecomment-276917712,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWlk0gwUTxIXJR7AtPOo6c5__S5B1kks5rYaw_gaJpZM4LnSjo
.

@wmertens There are a lot of ways the client and server execution could be different.  And I think it's unreasonable to force that restriction on people.
e.g.
if(isBrowser) {
  styled.div``
}

could potentially break everything.

Yes, but as @xcoderzach points out, you can declare components that will be used on the second render of the client side code, but that you don't need on the server side.
The babel plugin is definitely the right approach.  I think the only possible issue is that I don't think we can rely on files always being processed in the same order by babel.  e.g. babel src --out-dir lib would be very different to browserify src/index.js -t babelify.  This is why I don't think our solution should rely on random number generation or the order in which files are processed.

@ForbesLindesay I'm on making id's deterministic.

I have been asked by @mxstbr to comment on that issue.
The block API proposed by @satya164 looks definitely simpler than the getCSS()/reset() one. The teardown is handled for you.
However, my concern with those two APIs is around request isolation and concurrency. Relying on a singleton to collect the style prevents from handling two requests concurrently.
We have been implementing a different API with JSS on the new version of Material-UI. We instantiate a style collector at each request.
This example is taken from the Server Rendering documentation.
function handleRender(req, res) {
  // Create a styleManager instance.
  const { styleManager, theme } = createStyleManager();

  // Render the component to a string.
  const html = renderToString(
    <MuiThemeProvider styleManager={styleManager} theme={theme}>
      <App />
    </MuiThemeProvider>
  )

  // Grab the CSS from our styleManager.
  const css = styleManager.sheetsToString()

  // Send the rendered page back to the client.
  res.send(renderFullPage(html, css))
}

To be fair, that API only shine when using a streaming rendering implementation that can be interrupted. When using the synchronous ReactDOMServer.renderToString() implementation, I don't think that it makes much different. Maybe, it's simpler with unit tests.

On Mon, Feb 13, 2017 at 1:32 PM Olivier Tassinari<EMAIL_ADDRESS>wrote:

To be fair, that API only shine when using a streaming rendering
https://github.com/aickin/react-dom-stream implementation that can be
interrupted. When using the synchronous ReactDOMServer.renderToString()
implementation, I don't think that it makes much different. Maybe, it's
simpler with unit tests.

I like it! Besides, people can decide to use streaming rendering with S-C,
so definitely a good thing.

Looks like asynchronous SSR is now a real thing 🎉  https://github.com/FormidableLabs/rapscallion.

I would also very much like to be able to use this in an asynchronous streaming manner.

Landed here while debugging a rapscallion + styled-components implementation.
Does anyone have a working example 🙈
@mxstbr?

I think https://github.com/FormidableLabs/rapscallion/issues/39 is probably
a better issue for that question?
On Sun, Mar 19, 2017, 11:14 PM Siddharth Kshetrapal <
<EMAIL_ADDRESS>wrote:

Landed here while debugging a rapscallion + styled-components
implementation.
Does anyone have a working example 🙈
@mxstbr https://github.com/mxstbr?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/386#issuecomment-287652271,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWltIZPYFKEX_h0V5ISSuqxQawsC2Cks5rnajCgaJpZM4LnSjo
.

nfl/react-helmet (head element side-effect component) have a single method call to handle server side rendering. Using it in a large production application with great success.
https://github.com/nfl/react-helmet#server-usage

With React v16 (Fiber) vanilla streaming SSR support is on the roadmap, so we really want an API that works with that.
The classes from the Babel plugin are now deterministic. The TL;DR of this discussion, as far as I can tell, is that we need a non-singleton for concurrency and a single method rather than two separate ones.
This doesn't have to be too different from what we already have. If we export a non-singleton that means we can still have the getCSS and reset methods, but you won't have to use reset on the server since it's not a singleton anyway. (still useful for testing though)
Taking that into account the API would look something like this:
import { getStyleSheet } from 'styled-components';

function route(req, res) {
  // Get the styleSheet for this request
  const styleSheet = getStyleSheet();

  // Render the app
  const html = renderToString(<App />);

  // Get the critical CSS
  const css = styleSheet.getCSS();

  // Send the response
  res.send(render(html, css));
}

Does this cover everything? If I'm thinking about this correctly, this is just a tiny change to add a function wrapper around our styleSheet export.

@mxstbr With that example, how would the styleSheet instance be used during renderToString if it’s not passed in anywhere? I think most solutions put the instance in the React Context, so it’s available everywhere, but I don’t see that being done in your example.

Wait… am I crazy? Where did that example that I received an email about go? 🤔

With React v16 (Fiber) vanilla streaming SSR support is on the roadmap, so we really want an API that works with that.
The classes from the Babel plugin are now deterministic. The TL;DR of this discussion, as far as I can tell, is that we need a non-singleton for concurrency and a single method rather than two separate ones.
This doesn't have to be too different from what we already have. If we export a non-singleton that means we can still have the getCSS and reset methods, but you won't have to use reset on the server since it's not a singleton anyway. (still useful for testing though)
The one thing that needs to change is that we need to keep track of which CSS was injected in that request. I quite like the API that was suggested by @oliviertassinari (thanks for chiming in btw), though I don't think the ThemeProvider should care about the style manager, that should be its own thing imo.
Taking all of those thoughts into account the API would look something like this:
import { getStyleManager } from 'styled-components';

function route(req, res) {
  // Get the styleSheet for this request
  const { StyleManager, styleSheet } = getStyleManager();

  // Render the app
  const html = renderToString(
    <StyleManager styleSheet={styleSheet}>
      <App />
    </StyleManager>
  );

  // Get the critical CSS
  const css = styleSheet.getCSS();

  // Send the response
  res.send(render(html, css));
}

Does this cover everything? The big change to the current API would be that the styleSheet can either be constructed client-side or come from context.

Aha, I guess you deleted it and added a new one that does show the instance being injected :) 👍
One question re streaming, though, it looks like with this example the full render has to be performed before sending any data to the client, how would the streaming version work?

One question re streaming, though, it looks like with this example the full render has to be performed before sending any data to the client, how would the streaming version work?

That depends on how React Fiber implements it, I have no idea! Probably something like this?
  // Render to stream
  const htmlStream = renderToStream(
    <StyleManager styleSheet={styleSheet}>
      <App />
    </StyleManager>
  );

  // Get the critical CSS
  const css = styleSheet.getCSS();

  // I have no idea how this would work?
  res.send(injectCssIntoStream(htmlStream, css));

How would one inject the CSS into a stream of HTML? Maybe we do need a different API?

To be clear, I have no idea either and no previous experience with this. Conceptually it seems tough as we'd want the styling in the head element, but the CSS isn't known until rendering is done. Maybe this can only be done with ahead of time compilation of the CSS or caching it after the first request or something?
Are there examples of other frameworks that already do this?

Conceptually it seems tough as we'd want the styling in the head element, but the CSS isn't known until rendering is done.

You are right, that is going to be a pain. At least the new API makes concurrency possible, I don't know if streaming SSR is ever going to work with css-in-js though, given we don't know which CSS to inject until everything is rendered... :confused: /cc @trueadm @gaearon

At least the new API makes concurrency possible

True 👍

I don't know if streaming SSR is ever going to work with css-in-js though

Inline styles would probably work, but frameworks that collect styles and want to inject into head seem to be impossible yeah.
Is the babel plugin still meant to be able to extract all styling and serve that as a precompiled stylesheet? I guess that might be the only way to add streaming.

Talking to @trueadm it's pretty clear for streaming rendering support we'll need to have a static CSS file. The bable/webpack plugin is going to get us pretty far, but not all the way there.
Rather, we'll need to simulate as if a real style sheet existed with the generated styles from the render. This would be done by dynamically injecting a <link> into the streamed HTML which points towards the right CSS in the cache.
Basically, it'd look something like this: (note, pseudo code)
const styleCache = {};

app.get('/stylesheet.css?:id', (req, res) => {
  // Pretend as if a style sheet exists here and send back the generated styles for this request
  res.send(styleCache[req.params.id]);
})

app.get('*', (req, res) => {
  const { StyleManager, styleSheet } = getStyleManager();
  const id = generateUniqueHash();
  renderToStream(
    // This renders a <link href=`/stylesheet.css/?${id}` />
    <StyleManager styleSheet={styleSheet} styleId={id}>
      <App />
    </StyleManager>
  ).pipe(res);
  // Cache the CSS of this request after the stream has finished rendering
  // TODO: Figure out how to do this after the stream has finished rendering, for now let's
  // assume it's synchronous
  styleCache[id] = styleSheet.getCSS();
})

As proposed above, this would be the full API extension for styled-components:
import { getStyleManager } from 'styled-components';

const { StyleManager, styleSheet } = getStyleManager();

<StyleManager styleSheet={styleSheet} />

styleSheet.getCSS();
styleSheet.reset();

Does anybody have input regarding naming or use cases this doesn't cover? (personally not a fan of the word StyleManager, maybe we can think of something better to describe it?) Otherwise I say we go ahead and start implementing a WIP of this!

Sorry, I'm a bit out of loop here

@oliviertassinari : However, my concern with those two APIs is around request isolation and concurrency. Relying on a singleton to collect the style prevents from handling two requests concurrently.

What I proposed doesn't really on a singleton, it can just manage creating new instance internally instead of exposing it.
What do you mean by handling two requests concurrently? Can you give an example?

@mxstbr

Wondering what's the advantage of the reset method as opposed to just creating a new styleSheet object if you need, also why do we need a new instance of StyleManager each time? Won't <StyleManager /> give us a new react element every time?
import { StyleManager, StyleSheet } from 'styled-components';

const styleSheet = StyleSheet.create();

<StyleManager styleSheet={styleSheet}><MyApp></StyleManager>

styleSheet.getCSS();

Though I'm wondering, what's the purpose of the styleSheet element. Where else it will be used? Am I going to use it to render multiple elements and collect css from each of them?

Wondering what's the advantage of the reset method as opposed to just creating a new styleSheet object if you need

Makes testing easier:
import { styleSheet } from 'styled-components'

beforeEach(() => {
  styleSheet.reset();
})

why do we need a new instance of StyleManager each time? Won't  give us a new react element every time?

That's a good point, I quite like your API!
The purpose of the separate styleSheet object is to avoid having two request referring to the same CSS when concurrently rendering, what @oliviertassinari said. (I have no idea is anybody is doing that or if that problem exists, I don't really do SSR, but it seems like a likely issue to come up)

@mxstbr
Aren't these almost same? I don't like extra methods xD
const styleSheet = createStyleSheet() // `StyleSheet.create()` or `getStyleManager()`

beforeEach(() => {
  styleSheet.reset();
})

vs
let styleSheet = createStyleSheet() // `StyleSheet.create()` or `getStyleManager()`

beforeEach(() => {
  styleSheet = createStyleSheet()
})

The purpose of the separate styleSheet object is to avoid having two request referring to the same CSS when concurrently rendering

Yeah, I get that. I was asking what's the purpose of making the user manually create the instance as opposed to automatically handling it internally. e.g. -
const { css, html } = StyleSheet.collect(styleSheet =>
  ReactDOMServer.renderToString(<App styleSheet={styleSheet} />)
);

Aren't these almost same?

Yeah you're right, if we go with StyleSheet.create() that does the same thing.
How would your API work with streaming SSR? (i.e. styleCache)

@mxstbr html and css could be streams instead of strings perhaps, the css gets populated as new html is rendered. Though I don't have experience with streaming rendering, so I'm not totally sure.

You would probably do something like this:
const { StyleSheet, StyleManager } = getStyleManager();

const { css } = StyleSheet.collect(styleSheet => {
  renderToStream(<StyleManager styleSheet={styleSheet}><App /></StyleManager>).pipe(res);
})

Hmm, I quite like that actually as it forces people to work concurrently...

Ok just catching up here. Let me know if I've missed anything, but it seems like this would work:
import { StyleSheet } from 'styled-components'

const { css, html } = StyleSheet.collect(withStyleSheet => (
   ReactDOMServer.renderToString(withStyleSheet(<App/>))
))

This potentially lends itself to some kind of streaming API:
import { StyleSheet } from 'styled-components'

const css = new Stream()
const html = new Stream()

StyleSheet.toStream(withStyleSheet => {
  renderToStream(withStyleSheet(<App/>)).pipe(html)
}).pipe(css)

Personally, I prefer the idea of a HOC for attaching a stream rather than a <StyleManager>.
Thoughts?

It's not HoC because it doesn't transform a component, but does something
with an element. However, I guess it works as long as the resultant React
tree is the same as on the client.
On Mon, Apr 3, 2017, 11:45 AM Glen Maddern<EMAIL_ADDRESS>wrote:

Ok just catching up here. Let me know if I've missed anything, but it
seems like this would work:
import { StyleSheet } from 'styled-components'
const { css, html } = StyleSheet.collect(withStyleSheet => (
ReactDOMServer.renderToString(withStyleSheet())
))
This potentially lends itself to some kind of streaming API:
import { StyleSheet } from 'styled-components'
const css = new Stream()const html = new Stream()
StyleSheet.toStream(withStyleSheet => {
renderToStream(withStyleSheet()).pipe(html)
}).pipe(css)
Personally, I prefer the idea of a HOC for attaching a stream rather than
a .
Thoughts?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/386#issuecomment-291096596,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWlil3YeGLioYVYAnHDPnNyh908PLzks5rsL_OgaJpZM4LnSjo
.

Frankly, I don't really see the point of streaming the css bit. It's being built up gradually as the components are rendered, and we want it to be injected at the bottom of the HTML then, I guess? So by the time we reach that bit of the HTML, the css should be complete and doesn't need to be streamed, right?

@mxstbr I don’t see how the suggested cached CSS approach would really work. The CSS would still only be complete by the end of rendering the full tree, so when streaming the HTML to the browser it would fail to fetch the CSS once it’s received the head element, no?

The babel/webpack plugin is going to get us pretty far, but not all the way there.

What would it not be able to cover?

However, I guess it works as long as the resultant React tree is the same as on the client.

The DOM will be the same, there'll only be an element more on the server. (<StyleManager />) That shouldn't be an issue, right?
I like that API @geelen, less surface area is great!
Not a fan of StyleSheet.collect(withStyleSheet) in terms of naming though, as first we're collecting a stylesheet but then adding another stylesheet? Sounds pretty confusing. What about this instead:
import { StyleSheet } from 'styled-components'

const { css, html } = StyleSheet.extract(collectStyles => (
   ReactDOMServer.renderToString(collectStyles(<App/>))
))

so when streaming the HTML to the browser it would fail to fetch the CSS once it’s received the head element, no?

Yeah, you're right, you'd need to inject the <link /> at the end of the doc.

What would it not be able to cover?

Anything dynamic will have to stay at runtime, so we can't just use the webpack plugin and be done with it.

The React tree has to be the same on client and server for rehydration.
Also, if the CSS is at the bottom of the page, there will be a FoUC unless
you have a rule that hides the page until after the CSS loaded? For a long
page (e.g. blog post with comments), that could be a long wait.
Alternative solution: embed

The React tree has to be the same on client and server for rehydration.

Are you sure? If that's the case the whole idea won't work.

embed

Ah it was https://github.com/zeit/styled-jsx#how-it-works
and yes, I'm pretty sure. The React tree has to be the same from SSR and
first client render, because otherwise the react id's don't match. So to
make withStylesheet work, you'd either need to do some internal-React-API
context hackery on the provided , or simply return it wrapped in a
 :)
On the client, you'd then also need a , at which point it is
just the same as a Provider.
On Mon, Apr 3, 2017 at 1:36 PM Max Stoiber<EMAIL_ADDRESS>wrote:

The React tree has to be the same on client and server for rehydration.
Are you sure? If that's the case the whole idea won't work.
embed

@mxstbr @wmertens another problem, courtesy of @nfcampos
Are we taking into account that 2+ renders can take place at once? Do we want to introduce a StyleSheetProvider to solve this, or something?

@philpl to clarify, 2+ renders can happen at the same time if using an asynchronous SSR solution, e.g. https://github.com/FormidableLabs/rapscallion)

@philpl @nfcampos That’s what the concurrency and getting rid of singletons parts in this thread refer to.

So to summarise, we need to:

write a <StyleManager styleSheet={styleSheet}> provider
find out how to stream the css at the same time-ish?

The streaming in parallel seems problematic to me, while the second provider should be simple
cc @nfcampos

How about giving ThemeProvider an optional styleSheet to inject? That
way, you can use existing API, and people can attach their theme at the
same time (optionally of course)
On the client, you don't inject the stylesheet, or you get the singleton
from the module, either way works. So then it would be
import { StyleSheet } from 'styled-components'
const { css, html } = StyleSheet.extract(sheet => (
ReactDOMServer.renderToString())
))
On Mon, Apr 3, 2017 at 4:52 PM Phil Plückthun<EMAIL_ADDRESS>wrote:

So to summarise, we need to:

write a  provider
find out how to stream the css at the same time-ish?

The streaming in parallel seems problematic to me, while the second
provider should be simple
cc @nfcampos https://github.com/nfcampos
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/386#issuecomment-291167362,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWlrl3w1QlmcohHz_H2_qCH2qQTDlUks5rsQe3gaJpZM4LnSjo
.

Are we taking into account that 2+ renders can take place at once?

That's exactly what this whole discussion is about, and why our current API idea doesn't work :wink:

find out how to stream the css at the same time-ish?

I don't think this is necessary for now, we can talk about this once we know what the React API looks like.

How about giving ThemeProvider an optional styleSheet to inject? That way, you can use existing API, and people can attach their theme at the same time (optionally of course)

That doesn't solve the "react tree is different on client and server"-issue though, does it?

That doesn't solve the "react tree is different on client and
server"-issue though, does it?

Yes it does, same components, same tree, only a different styleSheet is
injected in context.
On Mon, Apr 3, 2017, 6:39 PM Max Stoiber<EMAIL_ADDRESS>wrote:

Are we taking into account that 2+ renders can take place at once?
That's exactly what this whole discussion is about, and why our current
API idea doesn't work 😉
find out how to stream the css at the same time-ish?
I don't think this is necessary for now, we can talk about this once we
know what the React API looks like.
How about giving ThemeProvider an optional styleSheet to inject? That
way, you can use existing API, and people can attach their theme at the
same time (optionally of course)
That doesn't solve the "react tree is different on client and
server"-issue though, does it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/386#issuecomment-291199833,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWlu637UBOOenrlLoXIxz7MFIEjpxyks5rsSDbgaJpZM4LnSjo
.

Yes it does, same components, same tree, only a different styleSheet is injected in context.

I don't understand.
This is our client App.js that's the root element rendered on the page:
const App = () => {
  return (
    <ThemeProvider theme={x}>
      <Root />
    </ThemeProvider>
  )
}

ReactDOM.render(<App />, node);

On the server we then do this to inject the styleSheet:
renderToString(<ThemeProvider styleSheet={styleSheet}><App /></ThemeProvider>)

Wouldn't that result in two different trees?
// client:
<ThemeProvider theme={x}>
  <Root />
</ThemeProvider>

// server:
<ThemeProvider styleSheet={styleSheet}>
  <ThemeProvider theme={x}>
    <Root />
  </ThemeProvider>
</ThemeProvider>

Yeah ok I think let's ditch any discussion of streaming for now and focus on a single use-case, then we can discuss changes to better support Rapscallion/Fiber in another issue, when we have a clearer idea of their constraints.

i think i agree with glen but i think we should still consider supporting asynchronous (not streaming) rendering now (i.e. not use a singleton)

@nfcampos yep exactly. Avoiding singletons is a must.

Ah, sorry for being unclear. I meant that the ThemeProvider would be in both client and server, and probably it would look something like this:
This is our client App.js that's the root element rendered on the page:
const App = ({styleSheet}) => {
  return (
    <ThemeProvider styleSheet={styleSheet} theme={x}>
      <Root />
    </ThemeProvider>
  )
}

ReactDOM.render(<App />, node);

On the server we then do this to inject the styleSheet:
renderToString<App styleSheet={styleSheet} />)

so the trees are the same on client and server, only on the client we don't provide a styleSheet which makes it default to the module's singleton. (or we do provide one, doesn't matter)

As for the server/client differences, the way our ThemeProvider works is that it renders an only child:
  render() {
    if (!this.props.children) {
      return null
    }
    return React.Children.only(this.props.children)
  }

What does this look like after renderToString? Obviously, they're not rendering any markup, but does their presence change the checksum?
I'm actually slightly leaning away from my earlier syntax suggestion, though I'd be happy to leave it in as a shorthand:
import { StyleSheet } from 'styled-components'

// Shorthand for straightforward case
const { css, html } = StyleSheet.extract(collectStyles => (
   renderToString(collectStyles(<App/>))
))

// Longer form in case your rendering is more complex than StyleSheet.extract can handle
const sheet = StyleSheet.create()
const html = renderToString(sheet.attach(<App/>))
const css = sheet.css

But I don't like <App styleSheet={styleSheet}/> (where you have to manage it yourself) or <ThemeProvider styleSheet={styleSheet}/> (an extra layer).

I suppose you could actually do something like this:
const Sheet = StyleSheet.createInMemoryStyleSheet()
const html = renderToString(<Sheet><App/><Sheet/>)
const css = Sheet.css

Starting to feel a bit React Router-y, but you could then have:
const Sheet = StyleSheet.createStyleTagInHead()

ReactDOM.render(<Sheet><App/><Sheet/>)

on the client (optionally, of course). The good thing about this would be that we could expose stylesheet lifecycle hooks, so you could have some control over which style tags get used. Which has been asked for in #235 and would help #568, and maybe even #622?
const Sheet = StyleSheet.createInlineStyleTag()

const Comp = styled.div`
  ...
`

export default props => (
  <div>
    <textarea onChange={ () => Sheet.reset() }/>
    <Sheet>
      <Comp/>
    </Sheet>
  </div>
)

Again, my only worry is making this completely optional, so the current zero-config approach still works until you want some advanced use-case.

Argh of course you are right, only the actually emitted tree is what
counts.
That said, I like this  API you propose, and you can make it
optional by having a default singleton Sheet that gets overridden by the
wrapping Sheet.
Not so sure about the inMemoryStyleSheet, is there any other kind? :)
How about
import {Sheet} from 'styled-components'
const app =
const html = renderToString(app)
const {css} = app
?
So, the css is stored on the created Sheet element. If the Sheet is
instantiated inside a browser, it will put the style on <head>,
otherwise it will keep it on this.css.
On Tue, Apr 4, 2017 at 12:50 AM Glen Maddern<EMAIL_ADDRESS>wrote:

I suppose you could actually do something like this:
const Sheet = StyleSheet.createInMemoryStyleSheet()const html = renderToString()const css = Sheet.css
Starting to feel a bit React Router-y, but you could then have:
const Sheet = StyleSheet.createStyleTagInHead()
ReactDOM.render()
on the client (optionally, of course). The good thing about this would
be that we could expose stylesheet lifecycle hooks, so you could have some
control over which style tags get used. Which has been asked for in #235
https://github.com/styled-components/styled-components/issues/235 and
would help #568
https://github.com/styled-components/styled-components/issues/568, and
maybe even #622
https://github.com/styled-components/styled-components/issues/622?
const Sheet = StyleSheet.createInlineStyleTag()
const Comp = styled.div  ...
export default props => (

 Sheet.reset() }/>

)
Again, my only worry is making this completely optional, so the current
zero-config approach still works until you want some advanced use-case.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/386#issuecomment-291298277,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWlukCZ4TanNxS3XuqtIITtbC43Az0ks5rsXfCgaJpZM4LnSjo
.

Oh, InMemoryStyleSheet vs InBrowserStyleSheet, of course. Is it necessary
to make this distinction if the Sheet automatically does the right thing
depending on environment?
And you propose putting the css on a React component instead of on the
element, making a new component every time. That makes it easier to get the
generated CSS since you don't have to keep a reference to the created Sheet
element, but it feels a little non-React-y to me.
On Tue, Apr 4, 2017 at 7:30 AM Wout Mertens<EMAIL_ADDRESS>wrote:

Argh of course you are right, only the actually emitted tree is what
counts.
That said, I like this  API you propose, and you can make it
optional by having a default singleton Sheet that gets overridden by the
wrapping Sheet.
Not so sure about the inMemoryStyleSheet, is there any other kind? :)
How about
import {Sheet} from 'styled-components'
const app =
const html = renderToString(app)
const {css} = app
?
So, the css is stored on the created Sheet element. If the Sheet is instantiated inside a browser, it will put the style on <head>, otherwise it will keep it on this.css.
On Tue, Apr 4, 2017 at 12:50 AM Glen Maddern<EMAIL_ADDRESS>wrote:
I suppose you could actually do something like this:
const Sheet = StyleSheet.createInMemoryStyleSheet()const html = renderToString()const css = Sheet.css
Starting to feel a bit React Router-y, but you could then have:
const Sheet = StyleSheet.createStyleTagInHead()
ReactDOM.render()
on the client (optionally, of course). The good thing about this would
be that we could expose stylesheet lifecycle hooks, so you could have some
control over which style tags get used. Which has been asked for in #235
https://github.com/styled-components/styled-components/issues/235 and
would help #568
https://github.com/styled-components/styled-components/issues/568, and
maybe even #622
https://github.com/styled-components/styled-components/issues/622?
const Sheet = StyleSheet.createInlineStyleTag()
const Comp = styled.div  ...
export default props => (

 Sheet.reset() }/>

)
Again, my only worry is making this completely optional, so the current
zero-config approach still works until you want some advanced use-case.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/386#issuecomment-291298277,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWlukCZ4TanNxS3XuqtIITtbC43Az0ks5rsXfCgaJpZM4LnSjo
.

That's what I thought, so this whole discussion went in the totally wrong direction :wink:
So this API actually works out perfectly fine:
const { css, html } = StyleSheet.extract(collectStyles => (
  renderToString(collectStyles(<App />))
))

Let's go with that? It's definitely the easiest for the user, as the client-side code doesn't have to change at all.
With the StyleSheet API everything gets a bit muddy and complex, I don't think we really need that?

Overall, not sure if streaming even worth looking into it at this point.
@mxstbr looks good for me.

Ok so I think definitely a StyledComponent needs to look up the instance of StyleSheet from context (defaulting to the current singleton if it's not present). Then we can do SSR, concurrent rendering, etc, but it also makes my <Sheet> object possible too.
I'm not sold on the StyleSheet.extract(collectStyles => API though, doesn't read all that well. Imo, if we're going for a shorthand, it should be real short:
import { renderToHtmlAndCSS } from 'styled-components'

const { css, html } = renderToHtmlAndCSS(<App />)

i.e. hide ReactDOMServer.renderToString. If, for some reason, that shorthand doesn't work for people, I think a more imperative API makes more sense:
import { ServerSheet } from 'styled-components'

const sheet = new ServerSheet()
const html = ReactDOMServer.renderToString(sheet.extractStyles(<App/>))
const css = sheet.css

Alternatively, do:
import SSR from 'styled-components/ssr' // or even its own package?

/* shorthand */
const { css, html } = SSR.render(<App />)
/* imperative */
const sheet = SSR.createSheet()

I dislike hiding the renderToString, if more than a single library you use do that you're f***ed, and I don't want to ship two different APIs to do the same thing.
I like you <Sheet> component, so why don't we do this?
import { StyleSheet } from 'styled-components';

const { html, css } = StyleSheet.extract(Sheet => renderToString(<Sheet><App /></Sheet>));

I don't feel strongly between this and the collectStyles HoC that does the same thing automatically.

 There's a fundamental disconnect between Styled Components and the needs of SSR. Basically, the problem is this:
import React from 'react'
import { renderToString } from  'react-dom/server'
import styled, { ServerStyleSheet, injectGlobal } from 'styled-components'

const sheet = new ServerStyleSheet()

const Heading = styled.h1`
  color: red;
`
injectGlobal`
  body { background: papayawhip; }
`

const html = renderToString(sheet.collectStyles(<Heading>Hello SSR!</Heading>))
const css = sheet.css

The way SC works at the moment, styled.h1 and injectGlobal both generate CSS synchronously, so only the color: red; rule actually gets picked up in the output. In the case of styled.h1, it's .sc-component-id {}, which has the side-effect of preserving declaration order in the resulting CSS. I've talked about why order is of paramount importance before so I don't want to repeat myself here, so let's just focus on injectGlobal.
How can we make injectGlobal aware of the sheet that we're building up?
There's no React component hierarchy, so no context we could use. injectGlobal itself is a singleton, so we only have singleton options:
const sheet = new ServerStyleSheet()
styled.StyleSheet.instance = sheet // this would be hidden from the user in practice, probably

injectGlobal`
  body { background: papayawhip; }
`

So, we can't support concurrent SSR without making breaking changes to this API. Perhaps injectGlobal gets replaced with something that returns a component, so it has to be in the React render tree somehow?
const Heading = styled.h1`
  color: red;
`
const BaseStyles = globalCSS`
  body { background: papayawhip; }
`

const App = () => (
  <div>
    <BaseStyles/>
    <Heading>Hello SSR!</Heading>
  </div>
)

Anyway, this is a blocker, so... any suggestions welcome!

Instead of injectGlobal, how about a <GlobalStyles /> component?

Yeah something like that will be needed and seems fine to me. API-wise I’d probably like a HOC approach for this, but not sure if that’s what you’re mulling over or just how to approach the non-singleton implementation at all?
const App = () => (
  <div>
    <Heading>Hello SSR!</Heading>
  </div>
)

export globalCSS(App)`
  body { background: papayawhip; }
`

I've followed this from a distance, so I'm not sure how all the pieces fit together. It sounds like the object new ServerStyleSheet() creates holds all the state of this process. Could injectGlobal be a method on that object?

@acjay The stylesheet instance would be injected into React’s ‘context’ property, so that isn’t available until a tree is being built.

I see how context is being used to provide access to the accumulating stylesheet from the component tree, but it seems to me (naively perhaps) that the underlying state could exist outside of context and also be accessible via methods on the stylesheet instance itself, outside of its React component interface .

I don’t disagree with that, the React component interface isn’t needed at all for global CSS, it’s just the most obvious way to pass the stylesheet instance along to all the modules (by piggybacking).

I just thought of a different API for injectGlobal yesterday during showering that could solve this issue:
import { GlobalStyle } from 'styled-components';

// ...

<GlobalStyle>
  body,
  html,
  #root {
    width: 100%;
  }
</GlobalStyle>

By putting our global styles back into JSX we can use context again?

That sounds perfect @mxstbr

OTOH, maybe globalstyles can be global, as in, they get injected everywhere?
On Tue, Apr 11, 2017, 5:32 PM Satyajit Sahoo<EMAIL_ADDRESS>wrote:

That sounds perfect @mxstbr https://github.com/mxstbr
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/386#issuecomment-293301788,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWlhkQcpYwTv__teLXffNrLlItnBJ8ks5ru50pgaJpZM4LnSjo
.

That can be confusing sometimes. IMO a component feels more natural and is explicit where you want it.

The problem with that @mxstbr (and my suggestion too) is that global styles aren't components. They don't render any HTML markup, they only cause a side-effect on the whole document. There's no sense in which they could be umounted (except by deleting the CSS they injected). If you wanted to do global styles in a component-centric way, you could do:
const Root = styled.html`
  /* effectively global styles here */
`

React.render(<Root/>, document.documentElement)

But it's ok, I think I've figured out my problem. If you consider SSR breaking in to two passes, setup (where global injection happens, components are constructed in order) and render (branching down the React tree and producing CSS), then it's fine for the first step to be a singleton. Reproducing my example from before:
import React from 'react'
import { renderToString } from  'react-dom/server'
import styled, { ServerStyleSheet, injectGlobal } from 'styled-components'

/* Setup */
const Heading = styled.h1`
  color: red;
`
injectGlobal`
  body { background: papayawhip; }
`

/* Render */
const sheet = new ServerStyleSheet()
const html = renderToString(sheet.collectStyles(<Heading>Hello SSR!</Heading>))
const css = sheet.css

When you call new ServerStyleSheet(), you clone the current singleton and pass it down to the components, so each render stage is separate. But, importantly, when the app boots, by virtue of there being no global.document, the default StyleSheet.instance is an in-memory one that simply buffers all its rules into its .css property.
So, no breaking changes needed, just a bit more messing around.

What about lazy-loaded components that inject styles on second render for
data-loading SSR? Wouldn't those go into parallel singletons?
I think it's safer to require globals css to be a component without
wrapping class and treat it like all the rest, like proposed above.
On Wed, Apr 12, 2017, 2:09 AM Glen Maddern<EMAIL_ADDRESS>wrote:

The problem with that @mxstbr https://github.com/mxstbr (and my
suggestion too) is that global styles aren't components. They don't
render any HTML markup, they only cause a side-effect on the whole
document. There's no sense in which they could be umounted (except by
deleting the CSS they injected). If you wanted to do global styles in a
component-centric way, you could do:
const Root = styled.html  /* effectively global styles here */
React.render(, document.documentElement)
But it's ok, I think I've figured out my problem. If you consider SSR
breaking in to two passes, setup (where global injection happens,
components are constructed in order) and render (branching down the React
tree and producing CSS), then it's fine for the first step to be a
singleton. Reproducing my example from before:
import React from 'react'import { renderToString } from  'react-dom/server'import styled, { ServerStyleSheet, injectGlobal } from 'styled-components'
/* Setup */
const Heading = styled.h1  color: red;
injectGlobal  body { background: papayawhip; }
/* Render */
const sheet = new ServerStyleSheet()const html = renderToString(sheet.collectStyles(Hello SSR!))const css = sheet.css
When you call new ServerStyleSheet(), you clone the current singleton and
pass it down to the components, so each render stage is separate. But,
importantly, when the app boots, by virtue of there being no
global.document, the default StyleSheet.instance is an in-memory one that
simply buffers all its rules into its .css property.
So, no breaking changes needed, just a bit more messing around.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/386#issuecomment-293435507,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWllWwYIgpDjhpMd7qfB15IXfutKcuks5rvBYmgaJpZM4LnSjo
.

No, that's fine. The point is that injectGlobal will always use the singleton under the hood. So, if you have lazy-loaded components injecting global styles, they'll always just keep adding to the singleton's buffer of global styles. The same way they would lazily apply if you used bundle-splitting on the client and had global styles spread around. On the server, any render calls after that file is lazy-loaded will have these new styles included.
Obviously, side-effects in lazy-loaded files, particularly ones that have global effects (rather than just adding more animation keyframes, for example), is a bad idea. But we don't need to make the API more cumbersome, and less consistent, by trying to shoehorn global styles into a component, when it really isn't.
My styled.html example above already works, and it would work just as well with a styled.div at the root of your project. If you want to attach your "global" styles using a component, then use one of those. Imo, truly global styles are something different.

Ok fair enough - I only use global styles to reset css and stretch the body
to the screen size, can't imagine legit uses outside of that…
On Wed, Apr 12, 2017 at 12:02 PM Glen Maddern<EMAIL_ADDRESS>wrote:

No, that's fine. The point is that injectGlobal will always use the
singleton under the hood. So, if you have lazy-loaded components injecting
global styles, they'll always just keep adding to the singleton's buffer of
global styles. The same way they would lazily apply if you used
bundle-splitting on the client and had global styles spread around. On the
server, any render calls after that file is lazy-loaded will have these
new styles included.
Obviously, side-effects in lazy-loaded files, particularly ones that have
global effects (rather than just adding more animation keyframes, for
example), is a bad idea. But we don't need to make the API more cumbersome,
and less consistent, by trying to shoehorn global styles into a component,
when it really isn't.
My styled.html example above already works, and it would work just as
well with a styled.div at the root of your project. If you want to attach
your "global" styles using a component, then use one of those. Imo, truly
global styles are something different.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/386#issuecomment-293531484,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWlnQUageBpQTO1FgM2DGhfDCxgXlvks5rvKFDgaJpZM4LnSjo
.

I haven’t used it yet, so pretty naive on the topic of injectGlobal, but are there no valid reasons to use injectGlobal for “global rules within a page”?
i.e. I wouldn’t want to share global styling for one page with another, which is the case when you don’t have a SPA.

For that, simply make a styled component for the page with all the rules
you want in the page. You can use any selectors you like.
On Wed, Apr 12, 2017 at 12:16 PM Eloy Durán<EMAIL_ADDRESS>wrote:

I haven’t used it yet, so pretty naive on the topic of injectGlobal, but
are there no valid reasons to use injectGlobal for “global rules within
a page”?
i.e. I wouldn’t want to share global styling for one page with another,
which is the case when you don’t have a SPA.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/386#issuecomment-293534549,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWllN3Yjlhpfu3WbC9iHDHHkraWjMDks5rvKSDgaJpZM4LnSjo
.

Given that most SSR React setups I've seen involve a document frame (either as a template literal or separately rendered React component) with a stub element on which to mount the application, I'm a little confused on why one wouldn't just render a vanilla <style> tag into their document frame for global styles. Why should the dynamic component tree need to modify those styles? Maybe styled-components "reaching out" of their own component tree isn't the best approach for that.

At least in the projects I worked on, I have a single root component for the document. Any pages rendered will use the document component, but since they are different pages, they have different styles.

@acjay you're spot on, actually. The only issue is that React makes it hard to define a <style> tag inline since you need the syntax to pass through unescaped. But you could definitely do that if you preferred...

I'm a bit confused by your comment @satya164. If you have components right down to the document root, why do you need global styles? And, this is about SSR, so there are no browser APIs available.
I think, fundamentally, global styles break encapsulation. Every other React component only deals with itself and its children, but global styles are by definition outside your component hierarchy. For example:
import reset from 'css-wipe/js'

injectGlobal`
  ${ reset }
  html { font-size: 16px; }
  @font-face {
    font-family: Gibson;
    src: url(...);
  }
`

const Root = styled.div`
  font-family: Gibson, Avenir Next, sans-serif;
  line-height: 1.15;
  font-size: 1rem;
`

Fonts are a good example. Declaring the font-face is a global concern, but using the font is component-specific. I'm going to push ahead with the singleton + cloning approach since it handles the specific problems with injectGlobal and the ones with component ordering. But yep, some good alternatives in these last few replies as to why you might not want to use injectGlobal at all.

And, this is about SSR, so there are no browser APIs available

Sure, you can just use a string if it's truly global, no APIs needed, but that's not what I want

If you have components right down to the document root, why do you need global styles?

Because the styles can be global styles for a single page, not global styles for the all pages. Different pages reuse the same document component. I can't just set global styles on the document because that will insert the styles to all the pages, and not specific pages

Every other React component only deals with itself and its children

Portals don't

Yeah I think the best way around that then is to really just render a <style> tag inline in your component hierarchy somewhere. It has the correct semantics (it has no effect once unmounted) and will be handled by React's rehydration just fine.

Is it recommended to start using this api if you're already on v2.0.0-15, or should I expect breaking changes? Because I'd like to start implementing ssr with v2.

@ismay npm i --save styled-components@rc, use the API from #679 and you're good. I doubt we'll change it again!

I'll thusly also close this issue.

For anyone who ends up here and is searching for some documentation. There's some text explaining it briefly on the upcoming docs: https://sc-next-docs.philpl.com/docs/advanced#server-side-rendering

I believe the documentation was shortly updated afterwards and was live on the main site:
https://www.styled-components.com/docs/advanced#server-side-rendering
p.s. Hiii phillll & been wanting for ssr for so long & it's so exciting & thanks for creating styled component

@philpl @wmertens Wanted to check about the FoUC part mentioned in the above discussion - is that to be expected in development mode? Or is there a way around that?

@oyeanuj as long as you render your styles server side, there won't be any FoUC, in development or production.

@oyeanuj no, there shouldn't be any FOUC. Mind opening a new issue about that?

@mxstbr @GGAlanSmithee thanks for the quick response. It turned out to be an issue in which I had set up SC, so false alarm. Sorry for the noise!

Hey :) , I have integrated this with (https://github.com/reactjs/react-rails). Actually is not working.
Can you provider some solution?
Thanks,

@wilfredonoyola can you please start a thread on Spectrum or open a new issue, as this one is unrelated, stale, and closed 🙂


React project

Reference from @harrysolovay: https://github.com/harrysolovay/react-templates-are-evil

Resolved by #229


128 GB of ram (110 ramdisk) is suddenly not enough

So, I've been plotting on a 8c/8t machine using 110GB ramdisk (out of 128GB total) just fine. But now, when I use a very similar setup but with 24c/48t CPU, suddenly during the creation of table 3 on phase 1 entire ram gets used and the whole machine freezes until the process quits. Is it the number of cores that makes it to use more ram now?

I can't take a screenshot right before the rig freezes but it's something like 25GB. I don't think that's a normal ram usage for the plotter is it?

Actually I could manage to take some screenshots this time

it's a parallel plotter......
you use more cores , it uses more ram....
i'd track the size of your swap file as you run the plotter......
bet its eating the  swap... then killing the system.

Ugh...  It says right there on the main page - 0.5GB per thread. Case closed.


Attempt to fix error in Build and Push Images

We currently have an error in Build and Push Images.
@dave-tucker suggested that using the non-slim variant of Rust may fix it.
Signed-off-by: Andre Fredette<EMAIL_ADDRESS>

/lgtm


MB-2820 [wip] Clean up yaml for service items

Description

Removes unnecessary reServiceID for service items from prime.yaml and support.yaml
Makes reServiceName, rejectionReason and eTag readOnly in the yaml

Setup
make server_run

Use the createMTOServiceItem endpoint to verify

Code Review Verification Steps

[ ] Have the Jira acceptance criteria been met for this change?

References

Jira story for this change

Messages

:book:
:link: MB-2820

  Generated by :no_entry_sign: dangerJS against 5b9d046aa37f92aab41e46f99d833558575ec582


How do I set up an ios project to use novocaine via cocoapods?

Hey guys, I have been trying to understand how to use novocaine in my project and is biting a bing chunk of my will to include it at all.
Here is the list of steps I have done to use this library:

Create a single view application.
In my terminal typed

$ pod init```
This creates my Podfile.
3. Edit the podfile to include `pod 'novocaine'`
4. On my terminal `$ pod install` then `open novocaineSample.xcworkspace`
5. Added Audiotoolkit and CoreAudio to the linker (Target > Build Phases).
6. Try to build. Failing with the following errors:

Undefined symbols for architecture x86_64:
"operator delete(void*)", referenced from:
-[AudioFileReader dealloc] in libPods-novocaine-Novocaine.a(AudioFileReader.o)
-[AudioFileReader initWithAudioFileURL:samplingRate:numChannels:] in libPods-novocaine-Novocaine.a(AudioFileReader.o)
"operator new(unsigned long)", referenced from:
-[AudioFileReader initWithAudioFileURL:samplingRate:numChannels:] in libPods-novocaine-Novocaine.a(AudioFileReader.o)
"___gxx_personality_v0", referenced from:
Dwarf Exception Unwind Info (__eh_frame) in libPods-novocaine-Novocaine.a(AudioFileReader.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-novocaine-Novocaine.a(Novocaine.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I have been looking around the other issues and I tried to change the `compile source as` to objective c++ and still nothing.

By the way, I am on xcode 6.1.1 (and 6.3) coding on swift for iOS 8.3... don't know if that is a big contributing factor.

I was receiving the same error so what I did was download the source files from Github and put them into my project manually without pods. Only way I managed to get them to work. Funnily enough using pods for Novocaine on Xcode 6.0 for iOS7 was fine but their seems to be some sort of conflict with their last update of Xcode and Novocaine's framework.

Hi,
I have the same errors, but only when trying to launch my unit test target.
When I run in debug mode it works well.
I installed NVDSP through cocoapods.
Does anyone find a solution?

I wouldnt suggest using cocoapods for novocaine. It used to work fine on Xcode 6.0 for iOS 7.0, however with apple latest version of Xcode there seems to be some sort of conflict. I would suggest you download the source code and add the files to your project the old fashioned way. Drag and drop. Then go to the build phases tab of your project and disable arc using "-fno-objc-arc". It should work! Let me know how things turn out !

Yes, adding Nocaine manually in the project solves the problem.
It's a bit strange. If someone know why this error occured and how to prevent it while using cocoapods should be great.
Thanks @zammitjames for your patch


Revert "add CodiMD helm chart to helm/hub"

Reverts helm/hub#297

This change is

I fixed it in 17a8109b5f019774d5f03a2e36c39edcd8bace1d


[Bug]: v1.0.4 generates wrong source maps in development

System Info
System:
OS: Windows 11 10.0.22631
CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
Memory: 18.35 GB / 31.69 GB
Binaries:
Node: 20.14.0 - ~\AppData\Local\Volta\tools\image\node\20.14.0\node.EXE
Yarn: 3.6.1 - ~\AppData\Local\Volta\tools\image\yarn\3.6.1\bin\yarn.CMD
npm: 10.7.0 - ~\AppData\Local\Volta\tools\image\node\20.14.0\npm.CMD
pnpm: 9.10.0 - ~\AppData\Local\Volta\bin\pnpm.EXE
bun: 1.1.24 - ~.bun\bin\bun.EXE
Browsers:
Edge: Chromium (127.0.2651.98)
Internet Explorer: 11.0.22621.3527
npmPackages:
@rspack/core: ^1.0.4 => 1.0.4
Details
Since<EMAIL_ADDRESS>broken sourceMaps are created
Similar bug as #7535
output:

Reproduce link
No response
Reproduce Steps

create project with pnpm create rsbuild@latest

pnpm run dev
broken source maps

create project with pnpm create<EMAIL_ADDRESS>or downgrade to<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

pnpm run dev
works

enabling source-map in config works in build mode but not in dev
import { defineConfig } from '@rsbuild/core';
import { pluginReact } from '@rsbuild/plugin-react';

export default defineConfig({
  output: {
    sourceMap: {
      js: 'source-map',
    }
  },
  // OR
  // tools: {
  //   rspack: {
  //     devtool: 'source-map',
  //   },
  // },
  plugins: [pluginReact()],
});

@h-a-n-a builtin:swc-loader in development, the result does not include a source map. I have set devtool to 'source-map' and debugged swc-loader, which returns the source map correctly. However, the result from run_loaders does not return the source map.
Notably, this issue does not occur in production.


Hi all,
when I create a websocket, close it and create again, no data will come as the manager thread will get stopped after the last socket is closed. Python thread can't be restarted, so I can't start it again. Moreover when I create new SocketManager, new socket and start the new manager, no data will come too.
Thanks for checking!
Jan

I have simillar issue.
Maybe I think maybe the problem is comes from library 'Twisted'.

I have this issue with the user socket on macOS... although the same problem is not happening on Windows.

This is happening to me for user sockets. It just stops after some time and I can't start it again.

Has anyone managed to solve this? This problem is bothering me for many months now. Both of the suggestions of @K-Kit are not working for me. After much debugging I am not really closer to any solution. There is never any message coming in from Autobahn/Twisted after the socket restart.

Any workaround about this issue? Keeping always one socket open mitigates the issue, but the websocket still freezes at some time.


Fix URLs in Header

ONS logo links to ONS homepage ("/") rather than Census Maps homepage.
New link added to ons.gov.uk/census from Census 2021 logo.
What
The ONS logo link was pointing to Census Maps. It now points to "/"
The Census 2021 logo didn't have an <a> tag. It now points to ons.gov.uk/census
How to review
Check that the links are correct and that I haven't changed the layout or accessibility.
Who can review
Anyone.

I'm going to re-do this PR without using a fork.


Documenting CONTRIBUTING.md

Write a document for detailed steps involved while contributing to this project.
Resource: https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors

Hey would you assign this to me , this is my first open source scouting so far everything went above the brain ; (
This may boost me to do more
If you assign it to me , please mention on what points should i write the contributing.md document
Thank You !

Ok, i am giving this issue to you,
Make sure the doc has

Setup of the project
The file structure and
Procudure to contribute (PRs)

You can reference available GitHub repos for the content of CONTRIBUTING.md


Magefile docs

Codecov Report
Base: 94.21% // Head: 45.04% // Decreases project coverage by -49.17% :warning:

Coverage data is based on head (90c21a0) compared to base (d63c3c1).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff             @@
##           master    #1954       +/-   ##
===========================================
- Coverage   94.21%   45.04%   -49.18%
===========================================
  Files           9      187      +178
  Lines         346    26976    +26630
===========================================
+ Hits          326    12151    +11825
- Misses         20    13955    +13935
- Partials        0      870      +870

Impacted Files
Coverage Δ

client/python/armada_client/permissions.py

client/python/tests/unit/test_gen.py

client/python/tests/unit/server_mock.py

client/python/armada_client/event.py

client/python/tests/unit/test_client.py

client/python/armada_client/gen/event_typings.py

client/python/tests/unit/test_permissions.py

client/python/tests/unit/test_event.py

client/python/armada_client/client.py

internal/common/armadaerrors/errors.go
39.26% <0.00%> (ø)

... and 186 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


Give PATH input more functionality

PATH now supports paths to single files within the application to be downloaded. PATH also supports globs at the base of the file path. Multiple paths can be given as input.

Kind of a general question: Are there any golang formatting guidelines for line length? I know that the compiler doesn't enforce any, but I do find it harder to read code that gets as long as this. It would be nice to truncate lines at the 120-char point, if not at 80. Just a thought though.


⚠ File access has degraded performance

In 5e11476, File access (https://fyle.uk/file/fish) experienced degraded performance:

HTTP code: 200
Response time: 7109 ms

Resolved: File access performance has improved in 631e5f8 after 11 minutes.


Minor fixes to typo and consistency

SAP is repeated incorrectly, and the word sub-set where previously (and repeatedly) the word subset is used.

Approved

Why wasn't this PR merged?

Sorry, I was too quick. I forgot to merge.


Fuzzy JSON decoding should try to unpack timestamps as time.Time

User Story
As a Go programmer I want the data types extracted using incite.Unmarshal to be useful Go types wherever possible.
Specifically, if I use the fuzzy JSON decoding by providing a []map[string]interface{}, I would like the standard CloudWatch Logs Insights timestamp fields @timestamp and @ingestionTime to be extracted into time.Time.
Comments
This should ideally be a simple local edit to the decodeColAsJSONFuzzy function.

Implemented it in commit f98c1022.
This will be part of the v1.1.0 release, coming soon.


Remove long-dead dependency.

Changes proposed in this PR

Remove a long-dead dependency

Why are we making these changes?
This dependency has been dead since 2016 when federation was removed. Its serialization code.

Waiting on green build and appropriate label.


Migrate frontity.cloud to now 2.0

Prepare frontity/cloud to work with now 2.0

:tada: This issue has been resolved in version 1.1.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Updated attractors.ipynb to use hvplot and Panel

As an exercise in our new hvPlot-centric approach to using our tools, I've updated attractors.ipynb to use  hvplot and Panel instead of hv and DynamicMap. The goal isn't necessarily to make the code shorter, though it did reduce it slightly, it's to make the concepts easier to convey given what people already know about Pandas and how widgets work.
I think it's succeeded at that?  Certainly the first couple of .hvplot calls are straightforward; there is data in a df, and we call hvplot on it.
The last example is less of a clear win. We can't use .interactive here because we're generating a new DataFrame each time, so I've used Panel and pn.bind. The old one only relied on HoloViews concepts throughout, from hv.Points to DynamicMap, which means that there was one place to go for reference, but even so the ideas were quite esoteric and surprising to people.  The new one adds Panel widgets and pn.bind as concepts, which they do have to figure out, but I think they are easier to convey and it's also much, much clearer where to go from here. The user can see that if they wanted to put anything else on a widget, they can just define one and hook it in, whereas with DynamicMap it was unclear how to add a Boolean, Selector, etc.
The new code in that last cell is also somewhat dense, but I can't think of any easy way to simplify it without making it much, much more verbose.

This PR #381 aims to complete this PR. Maybe this one can be closed?

@Azaya89, let us know if there's anything in this PR that should be added to https://github.com/holoviz-topics/examples/pull/381 (which I have merged too quickly, just assume it's still open :) ). If you say no, we are going to close it.


Use a better cross-platform atomic lock file.

This branch isn't working for me, either in my host Ubuntu 18.04 LTS or in a Docker 20.04 container:
$ target/release/krill-sync -vv https://rrdp.ripe.net/notification.xml --pid-file /tmp/t
Failed to create lock file "/tmp/t": No such file or directory (os error 2) (tip: use --pid-file to change the location of the lock file)

Yet:
$ touch /tmp/t
$ ll /tmp/t
-rw-rw-r-- 1 ximon ximon 0 jun 21 12:18 /tmp/t

Or inside a Docker Ubuntu 20.04 container:
root@388b93a6046b:/# krill-sync -vv https://rrdp.ripe.net/notification.xml
Failed to create lock file "/var/run/krill-sync.pid": No such file or directory (os error 2) (tip: use --pid-file to change the location of the lock file)

Yet:
root@388b93a6046b:/# touch /var/run/blah
root@388b93a6046b:/# ll /run/
total 20
drwxr-xr-x 1 root root 4096 Jun 21 12:14 ./
drwxr-xr-x 1 root root 4096 Jun 21 11:40 ../
-rw-r--r-- 1 root root    0 Jun 21 12:14 blah

And:
root@388b93a6046b:/# krill-sync -vv https://rrdp.ripe.net/notification.xml --pid-file /tmp/t
Failed to create lock file "/tmp/t": No such file or directory (os error 2) (tip: use --pid-file to change the location of the lock file)

Oops.. I thought I had tested this, but no... pushed too soon.
The issue you saw happened because the lockfile is stored in the state_dir and that dir did not exist yet. Pushed fixes for this, as well as the clean up of the pid file. Doing an explicit unlock before exit, but no handler is added to remove the lock file on ctrl-c. This should not be needed as it unlocks when it goes out of scope. (a panic will leave it in place, but this may be feature - there is no known reason why anything should panic).


Error when running python examples/rllib/stabilizing_the_ring.py

hi, i am sorry to trouble you again.
when i run the python examples/rllib/stabilizing_the_ring.py, i met the problem DeprecationWarning: The redirect_output argument is deprecated.
(flow) sean@ubuntu:~/flow$ python examples/rllib/stabilizing_the_ring.py
Traceback (most recent call last):
  File "examples/rllib/stabilizing_the_ring.py", line 128, in <module>
    ray.init(num_cpus=N_CPUS + 1, redirect_output=False)
  File "/home/sean/Downloads/enter/envs/flow/lib/python3.5/site-packages/ray/worker.py", line 1387, in init
    _internal_config=_internal_config,
  File "/home/sean/Downloads/enter/envs/flow/lib/python3.5/site-packages/ray/parameter.py", line 147, in __init__
    self._check_usage()
  File "/home/sean/Downloads/enter/envs/flow/lib/python3.5/site-packages/ray/parameter.py", line 197, in _check_usage
    "The redirect_output argument is deprecated.")
DeprecationWarning: The redirect_output argument is deprecated.

@eugenevinitsky

If the argument is deprecated, then remove it.
ray.init(num_cpus=N_CPUS + 1)
It means that you have installed a version of ray more recent that the one Flow uses (i.e. 0.6.1 as mentioned in requirements.txt).

@nathanlct thank you very much,
When I run this program, the following is the content displayed by the terminal, but it is constantly refreshed, there is no sumo animation effect like " examples/sumo/sugiyama.py", I want to know if this is correct?
(pid=8866) 2019-07-10 18:49:50,725	INFO rollout_worker.py:428 -- Generating sample batch of size 200
(pid=8866)
(pid=8866) -----------------------
(pid=8866) ring length: 240
(pid=8866) v_max: 4.189299083856172
(pid=8866) -----------------------
(pid=9088)
(pid=9088) -----------------------
(pid=9088) ring length: 252
(pid=9088) v_max: 4.759762049824181
(pid=9088) -----------------------
(pid=8866) Loading configuration... done.
(pid=9088) Loading configuration... done.
(pid=8866) Success.
(pid=9088) Success.
(pid=8866) Loading configuration... done.
(pid=9088) Loading configuration... done.
(pid=8866) 2019-07-10 18:50:02,364
......
......
(pid=8866) Success.
(pid=9088) Success.
(pid=8866) Loading configuration...
(pid=9088) Loading configuration...
(pid=8866) done.
(pid=9088) done.
(pid=8866)
(pid=8866) -----------------------
(pid=8866) ring length: 251
(pid=8866) v_max: 4.71224180704279
(pid=8866) -----------------------
(pid=8866) Loading configuration... done.
(pid=8866) Success.
(pid=8866) Loading configuration...
(pid=8866) done.
(pid=9088)
(pid=9088) -----------------------
(pid=9088) ring length: 229
(pid=9088) v_max: 3.666034803266416
(pid=9088) -----------------------
(pid=9088) Loading configuration... done.
(pid=9088) Success.
(pid=9088) Loading configuration... done.

@jingyanping You are training a policy, there is nothing to see. If you look in the parameters, you will see render=False, that is why no GUI opens. This significantly speeds up the simulation during the training. If you want to see how your training is doing, please refer to tutorial 5 about visualization.
If you have other questions, please post them on StackOverflow using the tag flow-project, we will help you from there!

@nathanlct hi,
Thank you very much for your reply, i will follow what you said.  i still have a question ask you，when i run“python examples/rllab/stabilizing_the_ring.py”，i met the problem with “TypeError: unorderable types: tuple() <= int()”
/home/sean/Downloads/enter/envs/flow/lib/python3.5/site-packages/theano/tensor/signal/downsample.py:6: UserWarning: downsample module has been moved to the theano.tensor.signal.pool module.
"downsample module has been moved to the theano.tensor.signal.pool module.")
python /home/sean/rllab-multiagent/scripts/run_experiment_lite.py  --use_cloudpickle 'True'  --variant_data 'gAN9cQBYCAAAAGV4cF9uYW1lcQFYLQAAAHN0YWJpbGl6aW5nLXRoZS1yaW5nXzIwMTlfMDdfMTBfMTlfNTBfNTlfMDAwMXECcy4='  --log_dir '/home/sean/rllab-multiagent/data/local/stabilizing-the-ring/stabilizing-the-ring_2019_07_10_19_50_59_0001'  --snapshot_mode 'all'  --args_data 'gASVrQkAAAAAAACMF2Nsb3VkcGlja2xlLmNsb3VkcGlja2xllIwOX2ZpbGxfZnVuY3Rpb26Uk5QoaACMD19tYWtlX3NrZWxfZnVuY5STlGgAjA1fYnVpbHRpbl90eXBllJOUjAhDb2RlVHlwZZSFlFKUKEsASwBLEEsPS0dC4gEAAHQAAGQBAGQCAGQDAGQEAGQFAGQGAIMAA30BAHQBAIMAAH0CAHwCAGoCAGQHAGQIAGQJAHQDAGkAAGYCAGQKAHQEAGkAAGYCAGQLAGQMAIMABAF8AgBqAgBkBwBkDQBkCQB0BQBpAABmAgBkCgB0BABpAABmAgBkCwBkDgCDAAQBZA8AZBAAZBEAZwIAZBIAZAwAZBMAZAwAaQMAfQMAdAYAZBQAdAcAZBUAfAMAZBYAZBcAZBgAZAQAgwAEfQQAZBkAZBoAZBsAZAwAZBwAZB0AZB4AZB8AaQQAfQUAdAgAZBUAfAUAgwABfQYAdAkAZCAAZCEAZCIAZCMAgwACfQcAdAoAZCQAdAsAgwIAAXQMAHQLAHwCAHwGAGQlAHwHAIMDAX0IAGQmAH0JAHwJAHwBAHwCAHwEAHwGAHwHAHwIAGYHAH0KAHQNAHwJAGQnAGQEAGQoAHwKAIMBAn0LAHwLAGoOAH0MAHQPAHwLAIMBAH0LAHQQAGQpAHwLAGoRAGQqAGQ3AIMAAn0NAHQSAGQpAHwLAGoRAIMAAX0OAHQTAGQsAHwLAGQtAHwNAGQuAHwOAGQvAGQwAGQxAHwMAGQyAGQzAGQ0AGQ1AIMAB30PAHwPAGoUAIMAAGYBAAFkNgBTlCiMQ0ltcGxlbWVudCB0aGUgcnVuX3Rhc2sgbWV0aG9kIG5lZWRlZCB0byBydW4gZXhwZXJpbWVudHMgd2l0aCBybGxhYi6UjAhzaW1fc3RlcJRHP7mZmZmZmZqMBnJlbmRlcpSJjARzZWVklEsAjAZ2ZWhfaWSUjAJybJSMF2FjY2VsZXJhdGlvbl9jb250cm9sbGVylIwScm91dGluZ19jb250cm9sbGVylIwMbnVtX3ZlaGljbGVzlEsBjANpZG2USxWMC3JpbmdfbGVuZ3RolEvcTQ4BjAltYXhfYWNjZWyUjAltYXhfZGVjZWyUjAdob3Jpem9ulIwRYWRkaXRpb25hbF9wYXJhbXOUjAx3YXJtdXBfc3RlcHOUTe4CjAxjbGlwX2FjdGlvbnOUjAZsZW5ndGiUTQQBjAVsYW5lc5SMC3NwZWVkX2xpbWl0lEsejApyZXNvbHV0aW9ulEsojAdzcGFjaW5nlIwHdW5pZm9ybZSMCGJ1bmNoaW5nlEsyjAhYWFggbmFtZZSMDmluaXRpYWxfY29uZmlnlIwUV2F2ZUF0dGVudWF0aW9uUE9FbnaUjAxyZWNvcmRfdmlkZW+UjA9yZWdpc3Rlcl9wYXJhbXOUjAhlbnZfc3BlY5SMDGhpZGRlbl9zaXplc5RLBYwDZW52lIwGcG9saWN5lIwIYmFzZWxpbmWUjApiYXRjaF9zaXpllE1g6owPbWF4X3BhdGhfbGVuZ3RolIwFbl9pdHKUTfQBjAhkaXNjb3VudJRHP+/3ztkWhytOSwWFlHSUKIwKU3Vtb1BhcmFtc5SMDVZlaGljbGVQYXJhbXOUjANhZGSUjAxSTENvbnRyb2xsZXKUjBBDb250aW51b3VzUm91dGVylIwNSURNQ29udHJvbGxlcpSMCUVudlBhcmFtc5SMB0hPUklaT06UjAlOZXRQYXJhbXOUjA1Jbml0aWFsQ29uZmlnlIwFcHJpbnSUjAdleHBfdGFnlIwMTG9vcFNjZW5hcmlvlIwGR3ltRW52lGgYjAlub3JtYWxpemWUjBFHYXVzc2lhbkdSVVBvbGljeZSMBHNwZWOUjBVMaW5lYXJGZWF0dXJlQmFzZWxpbmWUjARUUlBPlIwFdHJhaW6UdJQojAFflIwKc2ltX3BhcmFtc5SMCHZlaGljbGVzlIwVYWRkaXRpb25hbF9lbnZfcGFyYW1zlIwKZW52X3BhcmFtc5SMFWFkZGl0aW9uYWxfbmV0X3BhcmFtc5SMCm5ldF9wYXJhbXOUaCSMCHNjZW5hcmlvlIwIZW52X25hbWWUjAtwYXNzX3BhcmFtc5RoKmgYaCtoLIwEYWxnb5R0lIwmZXhhbXBsZXMvcmxsYWIvc3RhYmlsaXppbmdfdGhlX3JpbmcucHmUjAhydW5fdGFza5RLEkNmAAIbAgkBCQEGAQwBDAEHAQkBBgEMAQwBBwMMAQYBDAIGAQYBBgEGAQkEBgEGAQYBDAIPAhUCDQEDAQMBAwEGAQkCBgEPAQwCGAEJAQwCBgEJAQkDEgIGAQYBBgEGAQYBBgEGAgkDlCkpdJRSlEr/////fZQojAhfX2ZpbGVfX5SMJmV4YW1wbGVzL3JsbGFiL3N0YWJpbGl6aW5nX3RoZV9yaW5nLnB5lIwIX19uYW1lX1+UjAhfX21haW5fX5SMC19fcGFja2FnZV9flE51h5RSlH2UKIwEZGljdJR9lIwEbmFtZZRoVYwKa3dkZWZhdWx0c5ROjAhkZWZhdWx0c5ROjBdfY2xvdWRwaWNrbGVfc3VibW9kdWxlc5RdlIwHZ2xvYmFsc5R9lChoN4wkZmxvdy5jb250cm9sbGVycy5yb3V0aW5nX2NvbnRyb2xsZXJzlGg3k5RoPIwQZmxvdy5jb3JlLnBhcmFtc5RoPJOUaEKMInJsbGFiLnBvbGljaWVzLmdhdXNzaWFuX2dydV9wb2xpY3mUaEKTlGg4jCVmbG93LmNvbnRyb2xsZXJzLmNhcl9mb2xsb3dpbmdfbW9kZWxzlGg4k5RoM2htaDOTlGg7aG1oO5OUaEWMEHJsbGFiLmFsZ29zLnRycG+UaEWTlGg/jBNmbG93LnNjZW5hcmlvcy5sb29wlGg/k5RoQYwZcmxsYWIuZW52cy5ub3JtYWxpemVkX2VudpSMDU5vcm1hbGl6ZWRFbnaUk5RoOk24C2g0aG1oNJOUaDaMHWZsb3cuY29udHJvbGxlcnMucmxjb250cm9sbGVylGg2k5RoRIwncmxsYWIuYmFzZWxpbmVzLmxpbmVhcl9mZWF0dXJlX2Jhc2VsaW5llGhEk5RoQIwScmxsYWIuZW52cy5neW1fZW52lGhAk5RoOWhtaDmTlGg+jBRzdGFiaWxpemluZy10aGUtcmluZ5R1jAthbm5vdGF0aW9uc5R9lIwOY2xvc3VyZV92YWx1ZXOUTowDZG9jlGgLjAZtb2R1bGWUaF2MCHF1YWxuYW1llGhVdXRSLg=='  --exp_name 'stabilizing-the-ring_2019_07_10_19_50_59_0001'  --seed '5'  --n_parallel '1'
/home/sean/Downloads/enter/envs/flow/lib/python3.5/site-packages/theano/tensor/signal/downsample.py:6: UserWarning: downsample module has been moved to the theano.tensor.signal.pool module.
"downsample module has been moved to the theano.tensor.signal.pool module.")
using seed 5
2019-07-10 19:51:03.188182 PDT | Setting seed to 5
using seed 5
XXX name stabilizing-the-ring
Loading configuration... done.
Success.
Loading configuration... done.
2019-07-10 19:51:06.435119 PDT | [stabilizing-the-ring_2019_07_10_19_50_59_0001] observation space: Box(3,)
2019-07-10 19:51:06.435715 PDT | [stabilizing-the-ring_2019_07_10_19_50_59_0001] action space: Box(1,)
Traceback (most recent call last):
File "/home/sean/rllab-multiagent/scripts/run_experiment_lite.py", line 137, in
run_experiment(sys.argv)
File "/home/sean/rllab-multiagent/scripts/run_experiment_lite.py", line 121, in run_experiment
method_call(variant_data)
File "examples/rllab/stabilizing_the_ring.py", line 73, in run_task
hidden_sizes=(5, ),
File "/home/sean/rllab-multiagent/rllab/policies/gaussian_gru_policy.py", line 50, in init
output_nonlinearity=output_nonlinearity,
File "/home/sean/rllab-multiagent/rllab/core/network.py", line 228, in init
b=l_output_flat.b,
File "/home/sean/Downloads/enter/envs/flow/lib/python3.5/site-packages/lasagne/layers/dense.py", line 64, in init
super(DenseLayer, self).init(incoming, **kwargs)
File "/home/sean/Downloads/enter/envs/flow/lib/python3.5/site-packages/lasagne/layers/base.py", line 44, in init
if any(d is not None and d <= 0 for d in self.input_shape):
File "/home/sean/Downloads/enter/envs/flow/lib/python3.5/site-packages/lasagne/layers/base.py", line 44, in
if any(d is not None and d <= 0 for d in self.input_shape):
TypeError: unorderable types: tuple() <= int() @nathanlct

As I said, please post your other questions on StackOverflow using the tag flow-project, one question per post, I and the other contributors will be happy to help you there.
As a side note, please wrap your logs into triple backquotes like this, here and on Stackoverflow:
` ` `
logs here (remove the spaces between the backquotes)
` ` `

It will make it much easier for us to read them.


Comments and hints in Dynamo are hidden due to method duplicates.

No xml-file was generated during build.


UnhandledPromiseRejectionWarning: TypeError: Cannot convert undefined or null to object     at Function.from (native)

Cannot convert the following text to okurigana. But if I remove "・" from the sentence, the error disappear.
await kuroshiro.convert(' 次にあげる「ブラック・ユーモア」の例を見れば、自分で判断を下すことができるだろう。', {mode:'okurigana', to:'hiragana'});
I'm using
"kuroshiro": {
  "version": "1.1.2",
  "resolved": "https://registry.npmjs.org/kuroshiro/-/kuroshiro-1.1.2.tgz",
  "integrity": "sha512-kM8OjYancYcr6awdfZum02tKR+p6+MheW+DojRHg71QunMdLPaXqY8sMP/FLsInioEiGs1T13zNyxjOG65K0KQ==",
  "requires": {
    "babel-runtime": "^6.26.0"
  }
},
"kuroshiro-analyzer-kuromoji": {
  "version": "1.1.0",
  "resolved": "https://registry.npmjs.org/kuroshiro-analyzer-kuromoji/-/kuroshiro-analyzer-kuromoji-1.1.0.tgz",
  "integrity": "sha512-BSJFhpsQdPwfFLfjKxfLA9iL+/PC6LCR9vgwgb5Jc7jZwk9ilX8SAV6CwhAQZY611tiuhbB52ONYKDO8hgY1bA==",
  "requires": {
    "kuromoji": "^0.1.1"
  }

Hello thuraucsy. I gave a try with you test sentence but nothing error happened and the result was right.  What error message did you get?

@hexenq
I got the following error.

UnhandledPromiseRejectionWarning: TypeError: Cannot convert undefined or null to object at Function.from (native)

@thuraucsy
Still cannot reproduce the error. I think full error stacks or a runnable demo (such as jsbin) might be helpful.