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
Related
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 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.
is there a way to trace the compiler command for flash builder? I mean, I want to know the parameters and files that is compiling internally when I click "build" on FB.
Basically I moved a project to Flash Builder, and everything works fine but I have some runtime issues, and looks like the compiler is doing something wrong with some files (like using old files instead of using the one im changing, this occur only for a particular file, the rest works fine or I think that works fine). Also is different the way to embed some file, that's another reason to check what's doing internally.
I ran the game with mxmlc before, and probably I can compare what's the difference if I get the command executed by FB.
Also, I want to know how to do it if I need to research something in future.
Thanks for any help,
Regards
Flash Builder only recompiles if there has been a change to the code. So if you are changing an asset (image), for example, you won't recompile unless you also make a change to the project.
There are a few ways around this:
Easiest way is to just go into a file and press the space bar at the end of a line. It will add an extra byte to your file, but not to the project (compiler is "smart" and gets rid of unused files, classes, and characters). Since this is not a common thing, it shouldn't be an issue
Project->Clean.... That will force your workspace to rebuild and, in most cases, will also recompile your project
If #2 is failing, first delete bin-debug or whatever you are using as your debug folder, then run Project->Clean...
It's a tad bit annoying (especially when editing external libraries), but it allows for quicker re-launches of the debugger, which is the ultimate goal of that behavior.
I'm working on a project with two other developers that's built on FireBreath. So far, I've been able to get things working perfectly on my machine, but we need to coordinate our development via Mercurial. So I pushed my files to the repository and thought all was well.
Unfortunately, that doesn't work.
The various .vcproj files that make up the solution all contain hard-coded references to my local file system. This works fine for me, because I'm not moving the project around. But when you try to build the solution on another machine with a different file structure (different drive letter, different folder location, etc.) everything breaks.
I used FireBreath's standard project generation script (Python) and then the Visual Studio CMake script (prep2008.cmd) to generate the solution files. What can I do to tweak things so that other developers can use the same code base?
If your developers are not using the same build/make/project files, this could quickly become a maintenance nightmare. So you should definitively all use the same .vcproj files. (An exception to this would be if the project files were generated from some other files. In that case treat those other files in the way described above.)
there's two ways to deal with the problem of differing setups on different machines. One is to make all paths relative to the project's path. The other is to use environment variables to refer to files/tools/libraries/whatever. IME it's best to use relative paths for everything that can be checked out with the project, and use environment variables for the rest. Add a script that checks for the existence of all necessary environment variable, pointing out the meaning of any missing ones, and run this as a build prerequisite, so whoever tries to get a new build machine up and running gets hints at what to do.
To make sure that everyone caught the updated comments from sbi's answer, let me give you the "definitive" answer from the FireBreath devs.
Your build directory is disposable; you should never share .vcproj files. Instead, you should regenerate your build/ directory any time you change the project and on each new computer, just like any project that uses CMake.
For more information, see http://colonelpanic.net/2010/11/firebreath-tips-working-with-source-control/
For reference, I am the primary author of FireBreath and I wrote the article.
I'm not familiar with FireBreath, but you need to make the references relative, and then recreate that relative structure on every machine. That is, if your project sits in "c:\myprojects\thisproject" and has an additional include directory "c:\mydir\mylib\include", then the latter path needs to be replaced with "....\mydir\mylib\include".
EDIT: I rewrote my anyswer to make it clearer. When I got you correctly, your problem is that FireBreath generates those .vcproj files with absolute paths in it, and you want to use this .vcproj files on a different developer machine.
I see 3 options:
Live with it. That means, make sure, every team member has the same file structure / view to the file system, tools installed in the same place.
Ask the authors of FireBreath to change their .vcproj generator to allow relative paths, use of environment variables etc.
If 1 or 2 does not work, write a program or script for changing the absolute path to relatives in those .vcproj files. Run this script whenever you have to regenerate your FireBreath project.
What you should not do due to the FireBreath FAQ: don't change the .vcproj manually, those changes will be lost next time the project is regenerated.
EDIT: seems that "option 4." turned out to be the best solution: generating those .vcproj files for each developer individually. Hope my suggestions were helpful, either.
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