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
Related
How to download the exact source code of a specific LineageOS Android build?
For example this one:
https://download.lineageos.org/FP3
sha256 039a65b5365acd4d570fab1c034f450f32f04ca6f5371602adc6a9736bffe015
lineage-19.1-20221031-nightly-FP3-signed.zip
Goal: being able to manually inspect the (Open Source) source code and verify that no arbitrary code has been manipulated in this specific build.
Preamble
When I download an app like Termux from F-Droid I can:
verify the PGP signature (verifying package authority and integrity)
inspect the build log (checking for controversial passages from unusual libraries)
download the original source tarball and inspect the source code (most important for me)
How to do the last verification step on a specific LineageOS build?
Notes
https://security.stackexchange.com/q/266348/ - this question migrated from the Information Security network
https://wiki.lineageos.org/verifying-builds - page describing how to verify digital signature (not how to download the sources of a specific version)
https://download.lineageos.org/FP3 - downloads for the Fairphone 3 where there is not the possibility to neither download the exact source code neither see the exact commit hash)
https://wiki.lineageos.org/devices/FP3/build - how to build your own version (now about how to inspect the source code of an exact already-existing build)
https://wiki.lineageos.org/signing_builds - how to sign my builds (same problem as above)
https://mirrorbits.lineageos.org/full/FP3/20221114/lineage-19.1-20221114-nightly-FP3-signed.zip this is the URL of a specific build, but its parent directory cannot be visited https://mirrorbits.lineageos.org/full/FP3/20221114/ so I can't tell if there are any other files (like the source code tarball of that exact version)
https://github.com/LineageOS/android_device_fairphone_FP3 AFAIK this is the repository of the Fairphone 3 (but I see no reference between the specific image in the download page, and its specific git tag or git hash etc.)
At the moment it seems to me that I have to take the date from the download page (e.g. 20221114) and manually guess the exact commit hash from the official repository. This seems to me an unscientific way to proceed.
Thank you for the clarification about how to download the exact source code of whatever specific official LineageOS build.
Short answer, you can't.
Long answer: you could, but in this way you won't ever get the same precise package. And (imho) you'll waste a ton of time and resources, too.
LineageOS has tons of repos, it's not just one repo. You could still sync the entire source from their manifest and checkout everything at a specific date, in your case at the test build's date.
After that, you could build an unofficial build by yourself, using the LineageOS building guide. Though, it won't match precisely the official build because, among other factors, you're missing the signing key used to sign the official builds, which is private (as it should be). This is what differentiates an official build from an unofficial one.
Regarding the checkout part, you can check here regarding the latest commits added in that specific build.
Good luck!
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.
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
So after switching over to Sublime Text last year, it has become my editor of choice, and I have installed several different packages via the excellent Package Control and basically customized it all to my liking. After a couple months of infrequent use, I jumped back into a code-intensive project and fired up ST2 only to find that none of my packages are working.
After some digging, it finally occurred to me to open my preferences file, only to find all of my installed packages in the "ignored_packages" list. WTF?
Has anyone else experienced this or know what would have caused this? I do some funny things in my sleep sometimes, but not this!
My earlier comment notwithstanding, I think I've figured out what's going on. The issue seems to be Package Control, most likely the new version update to 2.0. I just restarted ST2 after having it open for the past few days, and happened to have the console (Ctrl`) open, and saw that several of my packages, including Tag, Terminal, and SublimeREPL, were added to the ignored packages list. This typically happens when a package is being updated or removed, and is done so it can't be used halfway through the operation before everything is synced. At any rate, for me there was some sort of error, and I had to force quit Sublime and restart it. I immediately checked my preferences, and sure enough several packages were in the "ignored_packages" array.
So, I'm guessing something like this happened to you, and for whatever reason the packages weren't removed from the ignored list, possibly because the system update didn't complete normally. Hopefully this won't happen again, but if it does you'll know where to look. Additionally, if it does happen again, I'd submit an issue on Github, as this may be a bug.
Update
My issue on Github has been merged into this one, and if you scroll all the way down to the bottom wbond has a fix for now: Download Package Control 2.0.1-beta, put it in your Installed Packages folder (removing the one that's already there), and adding the repository https://sublime.wbond.net/prerelease/packages.json by selecting Preferences -> Package Control -> Add Repository. Restart ST2, and see what happens, especially after restarting multiple times. If you still have bugs or odd behavior, please add to the issue.
I am adding this even if it's an old thread because the answer did not solved my problem, but it pointed me in the right direction.
Since it was a problem due to Package Control trying to update packages and I didn't want to mess with repos and stuff, first I tried to upgrade the packages "manually" using Package Control and I noticed that there was a 1-to-1 match between the items in the ignored_packages array and the packages that needed to be upgraded.
After updating, just remove the packages from the array and restart ST2: no more weird ignored packages in the array.
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.