Gatsby can't reload changes on Windows - node-gyp

There is a project which use Gatsby site generator. I run it on my Windows computer. I've set up it according to this manual. It runs. But when I change some sources, live reload doesn't work. As far as I can see it doesn't compile project when changes appears.
If I restart the server by hands, my changes are available.
How can I fix it? Or may be there are any ways to compile changes by handls without restarting the server?

It was happen on Windows OS only.
I've found the reason why live reload didn't work on Gatsby. It didn't work when the IDE (IntelliJ IDEA) Synchronization settings contain selected "safe write" option.
According to documentation "Changed file is first saved in a temporary file. If the save operation succeeds, the file being saved is replaced with the saved file." When this option is unchecked, live reload on Gatsby works good.
I don't know why, Grunt works with "safe write" option correctly, but Gatsby doesn't.

Related

Unable to save file changes while using VS Code Remote Container due to "read-only file system"

I'm experimenting with using dev-containers for development by trying to follow along with this simple example: https://github.com/microsoft/vscode-remote-try-python
The setup works fine and I am able to build and connect to the container, and run the app just fine. However, if I try to edit anything and save it, I get an error:
Failed to save 'app.py': Unable to write file 'vscode-remote://dev-container+2f55736572732f62726164656e2e6b696e6172642f706572736f6e616c2f7673636f64652d72656d6f74652d7472792d707974686f6e/workspaces/vscode-remote-try-python/app.py' (Unknown (FileSystemError): Error: EROFS: read-only file system, open '/workspaces/vscode-remote-try-python/app.py')
If I open a secondary window with the local folder open, I can save changes and those are reflected in the remote container window. But due to the file system being set to read-only, I can't edit anything from within the remote container. Any ideas on why I am stuck in read-only?
One potentially important note is that I am using using Colima (version 0.2.2) rather than Docker Desktop, thought I haven't found anything to indicate that this would be an issue.
I found the answer to my own problem. Turns out the issue was using Colima as a runtime. I came across the discussion around issue #102 on the Colima Github page. According to the developer, the default mount "Used to be read-only, but changed to writable in version 0.3.0.". I was using v0.2.2.
I updated colima to the most recent version (v0.4.4) and it fixed the issue for me.

'clarinet integrate' quickly fails and nothing is logged to console?

Following https://docs.hiro.so/smart-contracts/devnet I can't get the command clarinet integrate to work. I have installed Docker on my mac and am running version 0.28.0 of clarinet. Running command within 'my-react-app/clarinet' where all clarity related files live (contracts, settings, tests, and Clarinet.toml).
My guess is it could be an issue with Docker?
The issue was that I downloaded my Devnet.toml file from a repo that was configured incorrectly. The configuration I needed was:
[network]
name = "devnet"
I increased the CPU and Memory in Docker as well.
There is an issue when the command attempts to spin up the stacks explorer, but I was informed that there are several existing issues with the stacks explorer from clarinet integrate at the moment.
Depending on how the last devnet was terminated, you could have some containers running. This issue should be fixed in the next incoming release, meanwhile, you'd need to terminate this stale containers manually.
Apart from Ludo's suggestions, I'd also look into your Docker resources. The default CPU/memory allocation should allow you to get started with Clarinet, but just in case, you could alter it to see if that makes a difference. Here's my settings for your reference:
Alternatively, to tease things out, you could reuse one of the samples (eg: hirosystems/stacks-billboard) instead of running your project. See if the sample comes up as expected; if it does, there could be something missing in your project.

same-site-by-default-cookies alternative for Chrome

I am writing to ask about --disable-features=SameSiteByDefaultCookies feature which was part of chrome earlier.
I am working with IT MNC and recently we promoted very important functionality to Production. We have started charging customer for this. It is legacy application .
This application can't be tested locally anymore! Earlier we could point out application to lower environment with custom settings in project's config.js file and disabling #same-site-by-default-cookies in Chrome and application could be tested locally. But now we can't!
We tried many different settings and debugged but it could not help !!
It is noted that these settings no longer work in Chrome 94+. These flags are removed entirely.
As per my analysis it is found that application still can be tested locally if we get the portable Chrome. Or older version of Chrome installed in our System. However as per the compliance policy of company and client, we can't get old or portable chrome in system. We have latest version only.
Earlier we used to perform following to run it locally:
Open CMD
cd to Chrome path ( Till Application )
Fire the following command:
chrome.exe --disable-web-security --user-data-dir=C:\XXXX\XXXX\localwlp --disable-features=SameSiteByDefaultCookies"
This would open a new window of Chrome ( Close all before firing the command) and then we could test the application locally.
Anybody is aware about the alternative for this? That would be really helpful. We can't test the application locally so for even small changes, we require to deploy on lower environments which takes a lot of time and also code will work or not can't say.
I look forward to hearing from you all guys.
Thanks,
Kailash Nirmal.

TYPO3 RealURL does not work after Backup

My RealURL path segments do not work anymore since a Backup.
I had TYPO3 7.6.10 on my Windows PC.
Then i installed TYPO3 7.6.11 on my new Mac.
I made a dump file of the database and copied all files of my TYPO3 Project.
After finishing, I could successfully login into the backend.
The only problem I have is, that my RealURL does not rewrite my paths anymore.
Actually my first page is called localhost/project/home/ instead of localhost/project/index.php?id=2.
However, the first one always ends up in a 404 - Error.
I don't know why that happens, since i also copied the _.htacces file in the project folder too. Or is that not the right way to back up?
Hope someone can help me.
EDIT
Problem solved: Since OSX is hiding some sepcial files like the .htaccess, i had to make them visible so i could copy them. Now everything is working as it shall!
Problem solved:
Since OSX is hiding some sepcial files like the .htaccess, i had to make them visible so i could copy them.
Now everything is working as it shall!

Emacs: Often switching between Emacs and my IDE's editor, how to automatically 'synch' the files?

I very often need to do some Emacs magic on some files and I need to go back and forth between my IDE (IntelliJ IDEA) and Emacs.
When a change is made under Emacs (and after I've saved the file) and I go back to IntelliJ the change appears immediately (if I recall correctly I configured IntelliJ to "always reload file when a modification is detected on disk" or something like that). I don't even need to reload: as soon as IntelliJ IDEA gains focus, it instantly reloads the file (and I hence have immediately access to the modifications I made from Emacs).
So far, so very good.
However "the other way round", it doesn't work yet.
Can I configure Emacs so that everytime a file is changed on disk it reloads it?
Or make Emacs, everytime it "gains focus", verify if any file currently opened has been modified on disk?
I know I can start modifying the buffer under Emacs and it shall instantly warn that it has been modified, but I'd rather have it do it immediately (for example if I used my IDE to do some big change, when I come back to Emacs what I see may not be at all anymore what the file contains and it's a bit weird).
Add this to your .emacs:
(global-auto-revert-mode 1)

Resources