I think I am in a world of hurt right now. I have written a script in Eclpse. This is the first time I've used it. Because I work in ArcGIS a lot, I learned how to script using IDLE. I made the switch to Eclipse on the recommendation of a coworker and I love the environment, however, I've done something to my script that is messing up the indentation and to eb hoenst, I don't know how I did it. I get this weird behavior.
In Eclipse, I receive an error "inconsistent Indent at line....". It's weird, because that specific line appears to be in the right indented spot.
I will open the script in IDLE and the line appears to be in a different indented location than what I see in Eclipse. This would explain the error, but it doesn't explain why the line appears indented in one IDE and not in the other.
I think I learned that it has something to do with the space-tab, tab-space option under 'Source' in Eclipse and the Tabify/Untabify option under 'Format' in IDLE. I try to fix it in one IDE, but then it either tabs too much or too little in the other. I'm at a loss. I think I havea mix tab/space thing going on and I want to fix it so that isn't happening. Does this sound like what my problem is? How do I fix it? How do I set Eclipse so that when this error comes up, the line is displaying the indentation in the wrong location so that I can identify why this error is coming up?
IDEs have an option to replace tab char with spaces and another option to indent by 'n' chars per tab (whether it will be replaced by spaces or not). It sounds like your IDEs have different settings for these.
If you configure both IDEs to do the same thing for tab replacement and indent, then retabify the source once, you should be OK.
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 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.
I have a complex MS Access 2013 database with tens of forms. On one of the forms, I have button with vba procedure back to it, which returns values from MS SQL(ADODB) and puts them into the textboxes.
Problem is, whenever i click this button, it steps into compile menu as if there was a breakpoint, but in fact there is no breakpoint. Of course there are no errors / MsgBoxes and If I just click F5 or F8, it goes well.
Has anyone the Idea, what may be wrong?
Phantom Breakpoints can usually be fixed by copying the line which stops the code execution into notepad. Then delete the line from the VBEditor and insert it again from the notepad.
If this doesn't work, try decompiling the database:
Open cmd and enter the following:
<full path to your database> /decompile
example:
C:\testDB.accdb /decompile
In fact you can just re-paste it from the clipboard, you don't need to use notepad. But don't paste it back into the same line. Delete the bad line.
Phantom Breakpoints don't go away with a restart.
This issue has been around for years and yet MS won't address it. Annoying!
Phantom Breakpoint strikes again :(
This showed up in such a strange way that I feel compelled to post it somewhere. This seems like the most obvious place, but I'm glad to move these comments elsewhere as appropriate.
I have an Access 2010 ACCDE giving me this same error: "Requested type library or wizard is not a VBA project" when I click a button on the main navigation form. I try an earlier version with same references and exactly the same code (in the nav form and other areas relating to the button) and it works fine. However, when I open the ACCDB used to build the "bad" ACCDE, and click the same button, I get a different error: Error 16 - "Expression too complex".
I fixed the issue by commenting out the associated VBA lines in the nav form and duplicating the uncommented code below the original lines.
The strangest part was that it wasn't until after several debugging sessions that it started behaving as the original posting above, where the it would break to the invisible breakpoint. It displayed the misleading errors above before that.
My standard practice now is to use Clear All Breakpoints (under Debug menu) after all development sessions. Hopefully that will prevent this in the future.
The phantom breakpoint thing has been an issue for a couple of versions from what I remember. Between that, and the new thing where the code window activates just by floating over it- even if you don't click in that window- I'm not sure I can endure anymore "Improvements". Hell the the program ran pretty damned good about 3 versions ago! Honestly the new "fluff" they've added - alternate colors on report lines-or other data in tables- I don't use any of that and spend more time taking off alternative line colors when I don't want it!
Fix more bugs and spend less time on new features!!!
Ghost breakpoint within referenced accdb code library!
Had a very similar problem. While starting the application it stops highlighting a line in yellow. Unfortunately the highlighted line was in a referenced accdb library for additional code which I share between different databases. The other databases still worked fine with the identical part of code. Deleting the ghost breakpoint line didn't help (references are read only anyway), so, the source of the problem should be within the code of the calling database and not where the call runs into a ghost breakpoint.
Toggle the reference then, of course with save and restart, stopped the ghost breakpoint.
Just in case there is somebody with the same problem connected to referenced code.
OK, I've scoured the internet trying to figure out which bit I have to change in PhpStorm to make it stop doing this.
Right now when I run "reformat code" on some PHP, it also decides to optimize imports for me. While normally I'd say "gee, that's great" - in some cases PhpStorm doesn't recognize that some of the imports it thinks are unused are, in fact, actually used.
Comments as code, and all that.
Please tell me someone out there knows how to make PhpStorm stop doing this. It's driving me mad that I have to undo changes to my imports whenever I auto-format my code.
As it turns out, #LazyOne hit the nail on the head in the comments up above. Once I opened the reformat file dialog, all of my problems suddenly went away.
Very obscurely hidden setting, since it's not something easy to find in general preferences :-)
Mac users can use keyboard shortcut: ⌥⇧⌘L
This available to all Jetbrains products.
I have been using Sublime for a few months with great enjoyment until yesterday when something was corrupted and I needed to reinstall.
Since I thought I had all the packages I used memorized, I didn't keep a backup and did a full uninstall/reinstall of the app and the application support folder.
One of the features I really liked was that if I pasted in copy from another source, like Word, all the characters like curly quotes, etc. would be highlighted in hot pink.
This is no longer working and I believe it must've been a package I installed and didn't realize it. It saves a lot of time if you have to convert text to HTML content.
Does anyone know what package that is or how to get that behavior back in ST2?
I have been all over Google and cannot figure out how this was working. My mistake for throwing my settings/packages away.
I recently wrote a plugin dedicated to this exact problem: highlighting non-ascii characters.
https://github.com/TuureKaunisto/highlight-dodgy-chars
The plugin works on a whitelist principle: all non-ascii characters that are not whitelisted in the settings get highlighted.
I think the package you're after is Highlighter. It highlights a few unicode characters in that hot pink you referred to. You can add more matches via settings (example).