I attempting to edit Windows Terminal's JSON config file:
When I save, the document is minified:
I only have two extensions (I have removed others and restarted vscode). How do I find out where the minification is occuring? How do I stop it?
This is a bug in Windows Terminal. It's now fixed in the current Preview release. Mike Griese from Microsoft answered this via GitHub:
The profiles.json thing is a temporary thing. Unfortunately, Windows.Data.Json always writes out json as a single line, without the ability to pretty-print it, and we re-write the profiles.json to make sure that it stays up to date with the schema of the app. So currently, it'll keep re-writing it. But that's a huge pain point that we want to fix ASAP.
Related
I am using
METEOR#1.4.4.2
WebStorm#2017.1.1
Chrome#58.0.3029.110 (64-bit)
macOS Sierra 10.12.5
ecmascript#0.7.3
ecmascript-runtime#0.3.15
Recently, the debugger started to stop at wrong lines but only visually, mostly it is like 8-14 lines behind the actual breakpoint.
e.g.
*the orange bar indicates the breakpoint in google chrome
console output:
Also, as you can see, some lines are darkened, which means that I can not set a breakpoint there from the browser.
The behavior is the same within the WebStorm internal debugger. So I think it is not Chrome's fault. It looks like the source mapping is broken. I do not know if it is WebStorm, or Meteor that is the cause. Under this conditions it is very hard to debug...
It is difficult to say for sure, but it seems that the issue that you are experiencing is related to a bug that causes Meteor to generate incorrect source maps.
source maps
This is not your browser's "fault". It simply displays the code and the position that is delivered to it by the source maps in your project.
The app.js file and the source map (app.js.map) are generated by the Meteor build process and are served from the .meteor/local/build/programs/web.browser/app directory.
The .map file is responsible of telling the browser how to display the original source, and which segments in the generated app.js file are mapped to which segments in the original source code.
A great explanation about the technical aspects of source maps can be found here.
You can visualize your source maps online and see what maps where using this tool (choose custom... and drag/drop both .js and .map files.
the suspected bug
As a part of the build process, Meteor uses the babel-compiler Meteor package. At some point, a bug caused invalid maps to be produced after babel transformations.
The bug is currently tracked on GitHub and the Meteor folks seem to be closing in on the cause.
what can you do?
At the moment, there is no quick and easy fix.
You can either:
Watch the bug thread and wait for it to be resolved and debug without source maps for now (probably best, if the bug will be fixed soon).
Hack away with local clones of the relevant Meteor packages (could work, I haven't dug into the dependency issues and don't really recommend it, but here's a way of doing it).
Run Meteor from a git checkout in a known good state until a fix is released.
The last option is what #hwilson did in order to begin pinpointing the bug via a git bisect.
You can refer to the Meteor developer document for detailed information regarding the method of running the meteor tool from checkout, but the gist of the things is as follows:
First, make sure that your code, including the .meteor/versions and .meteor/packages are checked out into source control, as you will likely need to mess them up temporarily and will want to restore them once the bug is fixed.
git clone --recursive https://github.com/meteor/meteor.git to a directory of your choosing (e.g, /home/yourname/src/remote.
cd meteor.
git checkout 25a89b5 to get the last known good commit.
git submodule update --init --recursive to make sure everything is still golden after the checkout.
./meteor --help to have the checked out version start
In your project, remove the version info from the .meteor/packages file, as they will likely be incompatible with the ones offered by your checkout.
In your project dir, run /home/yourname/src/remote/meteor/meteor run.
This will run the checked out Meteor version. You may need to do a meteor reset (warning: this clears the local mongo database) or at least clean some of .meteor/local, (e.g, the source maps) for this to work, but this may be unnecessary.
This is quite a lot of effort for a bug which I assume will be resolved in the near future, but I decided to include this info partly in order to be used as documentation for future sourcemap-related issues.
It's hard to say for certain. On a cursory google search it would appear you're not the only one seeing this. As #MasterAM mentioned, it's probably because of source maps from transpilation. I don't think you can do a whole lot about it, but you can try clearing the browser and IDE caches which appears to have worked for some.
Javascript Stops at a line without a breakpoint in remote debug mode
Clearing Webstorm's cache
It is three years too late, but if somebody steel has this problem.
The problem is in the different interpretation of line separators by IDE and compiler, which generates .map files.
For example on the windows in the WebStorm and Angular-Project - the TypeScript compiler ignores line separators, if they are Unix-Style (only LF).
In this case if code formatter transforms too long line to couple of shorter lines and splits these lines by only LF, then in .map file this originally single line will be interpreted as single line, but WebStorm displays by LF separated lines as different lines.
Solution - change line separator to CR+LF and problem will be solved!
P.S. I thin this is a bug in TypeScript compiler
Not sure about this scenario but have faced a similar situation while debugging java with eclipse. It happens when the source code and the compiled/interpreted code that is being debugged - differ.
Try debugging a simple js code to validate if there is something wrong with chrome's js debugger itself. If it works, then an explanation for the lines of code not 'debug-enabled' would be that they are all on the same line (till statement that logs '7'). This could have also offset the line number in the browser.
This is one possible explanation.
I will add that sometimes the Pretty-print of the minified js file add offset in debugging mode between the real line in your code and the shifted line(do to Pretty-print).
So Avoid Pretty-print in mode debug and you will hang to the right line.
I'm considering to move one of the company internal wikis (very basic wiki with few/no extensions and not so many pages) to another machine and wondering if at the same time I can upgrade the mediawiki version, passing from 1.6 to the current latest 1.25 (in order to use extensions only available for the latest versions)
The Upgrade guide
https://www.mediawiki.org/wiki/Manual:Upgrading
seems to omit the scenario in which an upgrade of the underlying software (apache,mysql) is also required for setting up the target version.
and the Moving guide
https://www.mediawiki.org/wiki/Manual:Moving_a_wiki
strictly recommends that source and target wikis share the same software level.
So I'm a bit stuck. I would attempt an export/import of an xml dump, but I'm not confident for the above reason (there is a huge version gap in source and target wikis)
Or is there a better way to approach the problem? Thx
Edit after some tests
I consider Florian's answer the most safe and advisable, but I would share the final solution I came up with.
Install the new wiki (blank)
Export an xml dump of the original wiki
php maintenance\dumpBackup.php --full > dump.xml
I first encountered a "Cannot connect to database" error. So i had to add in the LocalSettings.php the lines
$wgDBadminuser=...
$wgDBadminpassword=...
Import the xml dump in the new wiki (first try in dry-run mode)
php maintenance\importDump.php --dry-run < dump.xml
php maintenance\importDump.php < dump.xml
Then I was prompted to run
php maintenance\rebuildrecentchanges.php
Copy the physical files from the old to the new wiki, in the same path(for common wikis they should be in the "images" folder. That was not my case).
Re-create the users (manually) in the new wiki
Last edited the LocalSettings.php with the most essential settings I wanted to preserve (groups, restrictions,...) .
And the moving was done! The new wiki is ok and already usable at this stage: pages are there, links are working..
In fact, it should work, if you move the wiki from one server to another and after that upgrade it on the new server. Like you may already know, it's important to backup all files and data you have for the wiki in the "old" environment, so you can easily restore it from there.
If I would want to do, what you want to do, I would first follow the "Moving a wiki" guide except the "Test" section. After that I would upgrade the wiki to the newest version. Now I can test the wiki intensively to see, if anything worked well.
If you don't want to do that, you really need to upgrade the wiki in the "old" source and move it after that. If I understand you correctly, that would require an update of the server software (I expect php and mysql?).
I am using PhpStorm for few months now and I have just noticed something really weird about language injections in the version 9.0.
Sometimes I have to declare that some strings in my PHP are Javascript instructions. When I do so and save my file (with auto-upload on), it looks like PhpStorm is doing a lot of remote checks, file moves and transfers, I dont really understand why... and I'm afraid that it may overwrite files that I didn't modifie. I'm working directly on a production server with other people, I know it's dangerous but we have no choice for the moment.
In the file transfer logs, I have something like that :
[18/09/2015 10:47] Automatic upload completed in less than a minute: 2 items deleted, 50 items moved, 4 files transferred (4 Kb/s)
Can someone help understand what is going on ?
I have found a way to do what I want, but didn't find the reason of theses uploads that PhpStorm does without asking anything...
The problem is that, until now, I didn't found a way to save files one by one. It looks like PhpStorm has only a "Save all" option that uploads every files changed since last save (if you ask for auto-upload). And in the case of a language injection PhpStorm seems to change a something in the opened files that forces it re-upload them all.
So I disabled auto-upload and bound a shortcut to "Upload to default server". This option uploads only your current file but it saves it before. So it's a kind of auto-upload but a little less agressive and it gives me the possibility to just save my files (with "save all") or to save only the current one and upload it instantly.
This is the way I used to work before using PhpStorm, I find it more convenient and less violent than this automatic upload process that Phpstorm uses.
If someones find something better I'm opened to any advice.
Yesterday I tried updating from MATE 1.4 to MATE 1.6. I didn't like some things about it, and I decided to switch back, at least for now. One of the changes was a switch from the mateconf configuration system to GNOME 3's GSettings. As I understand this is a frontend to a system called dconf (or connected some other way).
This rendered many of my settings viod. I figured I could try to migrate them, but unlike gconf and mateconf, which created convenient folders in my home directory and filled them with XML I could edit or copy, I wasn't able to find any trace of dconf's settings storage.
A new Control Center is provided (and mandatory to install) but I don't want to be clicking through dozens of dialogs just to restore settings I already have. The Configuration Editor utility might be okay, but it only works with mateconf.
So what I want to know is where I can find the files created by dconf and how I can modify them directly, without relying on special tools.
I almost forgot that I asked this, until abo-abo commented on it. I now see that this is a SuperUser question, but for some reason I can't flag it. I would if I was able to.
The best solution I found was to install dconf-tools, which is like the old conf-editors.
As for the actual location of the data on disk, it seems to be stored in /var/etc/dconf as Gzipped text files, but I'm not entirely sure because I'm not using Mate 1.6 right now. I wouldn't advise editing them directly.
I've been having another issue with dconf, and I checked the folder that I mentioned above. It doesn't even exist. There now seems to be a single configuration file at ~/.config/dconf/[USERNAME]. It isn't in text format, so special tools are required to edit it.
This might be the result to an update to dconf.
I had a similar problem (was trying to back up keyboard custom shortcuts). The path for that was:
dconf dump /org/gnome/desktop/wm/keybindings/ > wm-keybindings.dconf.bak
dconf dump /org/gnome/settings-daemon/plugins/media-keys/ > media-keys-keybindings.dconf.bak
This thanks to redionb's answer on Reddit.
In the company I am I was asked to write an autoupdate function a la chrome. I.e. It should check periodically whether a new version is available, download the new version and apply it silently the next time the application starts.
I already have something up and running but it is more like a dirty hack than something I feel happy about it. So, I would like to know how to design and implement such a solution. My horrible hack works as this:
Have a mechanism to check whether a new version exists (a database query or a web service)
Download a full zip with the whole new version.
Check file signature. If everything went alright, set a registry value: must update to true.
When the application restarts, if the must update value is true, launch an update program and exist.
The update deletes the contents of the application folder, unzips the update and replaces the old contents, launches the application and exits.
Now, I would like to change it, so it works cleaner. I am planning to send the update as a bsdiff file. It gets downloaded. But the question is, what happens next?
When do apply the update?
Who is in charge of applying the patch? is it the program itself or is it a third program, as I did, which is in charge of applying the patch and relaunch the application?
If your going down the C++ route you can go to chromium and download the Chrome source code and dig around to see how the update is done, this might give you a better idea on how to approach it. Here's an article that might help.
If your familiar with .NET the recently release nuget also has an auto update feature that might be useful to look at, you can get the source code from here. David Ebbo has a blog about how its done here.
I'm not up to date on Delphi but you might be able to use either of the above options.
The workflow you proposed is more or less like it should work, but there's no need to re-invent the wheel - there are plenty libraries out there that will do this for you. Using a 3rd party library has the benefit of keeping your code cleaner while making sure the dirty process of auto-update is contained and working flawlessly.
Trust me, I know. I'm the author of NAppUpdate, an app update framework for .NET (which you might want to try out or learn from).
So, after giving it a lot of though, this is what I came with (for active directory I will refer to the directory where the main program lies, active program is the main program and update program is the one that replaces the active program and its resource files):
The active program checks if there is a new version every certain amount of time. If so, download it
Prepare new version in a separate folder (this can be done by copying the contents of the directory with the program to a subdirectory and applying a binary patch, or simply unziping the new version).
Set a flag that indicates that a new version is ready.
When a program is exiting (and one has to control for different interrupts here):
The active program checks the new version ready flag. Launch the update program and exit.
The update program checks if it can write in the active directory. If so, replaces the contents with the prepared version.
The update program has to recheck links and update them accordingly.
So guys, if you have a better workflow, please tell me.
You could literally use the Google Chrome update workflow by using the Google Chrome updater:
http://code.google.com/p/omaha/
They open sourced it Feb 2009.