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.
Related
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.
Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.
I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: #nativescript/schematics).
Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).
Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.
What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.
I have done some research in the topic, but I was unable to find a conclusive answer:
the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
lastly, for some odd reason, the #nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts
While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.
In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.
Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.
But of course, you may write your own schematics if you like immediate support for environment files.
I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of #types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!
I'm working with a large json file.
This json has been parsed by myself using Python, and (as a result) there are some json validation errors at different points in the file. I want to identify these errors in order to improve my Python parser.
Sublime text (2) helpfully highlights in pink formatting errors in the json, however working my way through 70,000,000 lines of json to find these errors is somewhat challenging.
Is there any way to skip to pink highlighted errors in the json?
(Note: the json file is sufficiently large that trying to use an online validator for example is not possible)
Thanks!
This can be done in a fancy way using a plugin, but for your purposes probably the best way is to just enter a command into the console. Open your JSON file with errors in it, then open the console with Ctrl`. Paste in the following code and hit Enter:
view.show_at_center(view.find_by_selector("invalid.illegal")[0])
and the view will scroll to show the first error in the file. Fix that error, click back on the console entry line, hit the up arrow to bring back the command you just ran, and hit Enter again, and it should scroll to the next error, and so on. When there are no more errors, you'll get IndexError: list index out of range printed to the console, and the view won't scroll any more.
While this will work in both Sublime Text 2 and 3, I strongly urge you to upgrade to ST3 if at all possible. ST2 has been shelved and deprecated, and there will be no more bug fixes released. Development is now focused solely on ST3 (as well as being in the planning stages for ST4!). "I don't know of any good reason to not use Sublime Text 3" - Will Bond, ST core developer.
There are a ton of new features and bug fixes in the new version, even if you're just using the public beta. (BTW, don't let the word "beta" fool you - the program is rock solid, and has been for years.) If you want more cutting-edge features, and are a registered user (which you should be if you are using the program long-term or for commercial purposes), you can download the dev builds which are updated more frequently, but run the slight chance of having an undetected bug or two.
One of the major advantages of ST3 is that it now supports a new, YAML-based sublime-syntax highlighting engine, which allows for much greater flexibility than the old .tmLanguage highlighting files (which are still supported). Related to that, the syntax files have all been open-sourced and development is proceeding very rapidly on them, even though it's been a few months since the last build was released.
Probably the biggest reason to upgrade is the plugin community. The internal Python API has been updated to Python 3 (3.3.6, to be precise), which had the side effect of making many old plugins incompatible. Except in a few rare cases, most plugins now support ST3, and many are dropping ST2 support by the wayside as it becomes too difficult to maintain two codebases, as well as trying to develop with the much more limited API ST2 provides. So, unless you absolutely depend on an old ST2-only plugin that can't be ported, upgrading is definitely the best path to take.
In a fairly large project I am working on, I have a separate source folder with .CLJC-files that are shared between the frontend (Clojurescript) and backend (Clojure).
I noticed that making a trivial change in a CLJC file (e.g., adding a blankline) causes all or most of the CLJC + Clojurescript files to be rebuilt (as listed by the compiler with :verbose to true). This causes a delay of about 45 seconds on my machine. Strange thing is that this even happens when the CLJC does not contain any functions, and is not require'd by any other CLJS/CLJC file...
Does anybody know what could cause this behaviour? My project file is quite standard, and I use the latest versions (CLJS 1.9.293, lein-cljsbuild 1.1.5 or even 1.1.6-SNAPSHOT).
Unfortunately it is not possible to even temporarily remove those pecularities from the project just to test this issue.
To answer my own question:
This problem was not caused by the specifics of my project -- it happens with every project, because it may be the case that a CLJ or CLJC file contains macros that (when changed) cause CLJS files to be implicitly modified. lein-cljsbuild therefore recompiles all CLJS files.
For some background discussion, see https://github.com/emezeske/lein-cljsbuild/issues/345
I have filed a bug report at https://github.com/emezeske/lein-cljsbuild/issues/457
Symptoms:
Successful build
"Live Issues" shows tons of errors
Autocomplete no longer works
This happened in the middle of coding, yet is unrelated to code changes. I have tried various other solutions I've found on here, including:
Clean Build Folder
Remove Derived Data
Restart xcode (in combination with other items on this list)
Restart computer
Removing then re-adding the framework (referenced below*)
Change build settings:
ALWAYS_SEARCH_USER_PATHS No -> Yes
FRAMEWORK_SEARCH_PATHS nil -> $(PROJECT_DIR) and explicit path (non-recursive) to included framework
Checkout code several changes back to ensure it's unrelated to code changes
Build for actual device instead of simulator
Changing the name of the file
None of the above works (the "Restart xcode" step was tried in combination with other steps above and in various orderings).
I am currently using xcode 7.2.1. (I couldn't upgrade to 7.3, but didn't see anything in the release notes about this issue anyway.)
*This project includes a framework that I have developed that is in a separate directory.
I've ruled out other solutions from stackoverflow, because:
This project is swift
I haven't created any precompiled headers (find /var/folders -name SharedPrecompiledHeaders yielded no results)
Again, the project builds. I can make changes and run and those changes make it out to the simulator. As far as I can tell, the Live Issues and code completion are just in a single file.
This is hardly a "real" answer. In the end, I ended up checking out a revision so old that most of the code wasn't present.
I was pushing to a remote repository, checking out each branch and pushing, one of the branches was just the initial project autogenerated by xcode before it had any real code. Checking that branch out and checking out the current dev branch seems to have made the problem go away.
...for now