There are a lot of questions on SO about how to debug a standalone piece of Javascript - that isn't what I want. None of the previous Eclipse/javascript questions seem to be on point, which surprised me.
I am using Eclipse for Java EE (Neon, the latest version) to develop a JSP/servlet website - a full website, not just javascript, and not just java/jsp - everything together. I can compile my Java and "debug as" on an instance of Tomcat spawned by Eclipse, and the web pages show up inside of a window in Eclipse. I can set and hit Java breakpoints all day long while using "debug as" - but setting breakpoints in javascript doesn't do diddly squat. I've been having to run a standalone instance of Tomcat, deploy war files to it, wait for the war files to decompress, then debug my Javascript inside of Firefox. This is particularly annoying because I'm relatively new to javascript and am doing some complex things on the page (and truth be told, making some silly mistakes a compiler in a typed language would catch for me before letting me waste my time trying to run the code) and the "change, watch Eclipse chew deploying war, wait for Tomcat to chew uncompressing the war, test" cycle is just unacceptably long.
Isn't there an easier way to debug BOTH java and javascript from the same IDE without having to export and deploy WAR files? Is there is a setting I can toggle or something I can install in Eclipse to make it an all-in-one IDE? Ideally I would like to be able to step through, for example, an AJAX call into my servlet AND watch what happens in the javascript after it returns - within the same debugging session - so let me preemptively state that copying the changed js file(s) directly to the decompressed folder in tomcat/webapps as a faster way to continue to do split debugging is not the kind of "workaround answer" I'm looking for.
JavaScript debugging is going to be supported in Eclipse Neon 1 release (September 2016). Here is a demo video in which step-by-step process of debugging both front-end and back-end is explained - https://youtu.be/7oQz1Ja1H08 .
Basically, running Chrome / Chromium with extra parameters and tuning source mapping manually is not really user-friendly now, but we are going to improve it for Neon 1 and future releases.
Contributions of any kind are most welcome ;)
Related
Update:
It turns out that what I really wanted was to be able to do remote development on my laptop, and - if I also did something local on my robot, to have the changes show up on my main development system.
Ref:
This substantially similar question was asked about 10 months ago and has received no replies since then. As there have been a lot of improvements in VS Code since then, (and since Stack Overflow discourages "Me Too!" replies), I have decided to re-ask the question in hope that someone will notice it and reply.
Viz.: https://stackoverflow.com/questions/60034690/how-to-sync-workspace-folder-beween-host-and-remote-target
Environment:
A Windows 10 system running VS Code, both current as of this instant date.
A Raspberry Pi based robot, (a GoPiGo3) that has the remote development using SSH software installed that allows my Windows 10 system to communicate with it via VS Code.
I have made an exact copy of the workspace environment, in its entirety, including the enclosing workspace folder, from the Windows 10 system to the robot, using FileZilla.
My previous workflow was to develop on the Windows box, transfer to the robot, run on the 'bot using Thonny, note any errors and either fix them in-place, (within Thonny), and transfer back to the Win-10 machine or fix within Windows 10 and transfer back to the 'bot.
"Clumsy" is a masterpiece of understatement.
Now that I have set up Remote Development on the bot, I believe I can escape most of that.
What I notice is that within the robot's copy of the workspace, most, (if not all), of the files are now either "modified" or "untracked" and updating my GitHub repo from the 'bot will cause all kinds of confusion.
What I want is the ability to develop on either platform seamlessly. (i.e. Changes made on the one are automagically reflected on the other when next connected.) And I want to do this in such a way that the commit and/or change status is accurately reflected on both machines.
I could go into a long explanation as to why this is useful to me, but this question is long enough already.
Any help would be gratefully appreciated.
OK people, I think I have this figured out.
Lesson #1:
It turns out that my original problem was actually more about workflow and "what's the best way to do a specific something", as opposed to how to do dual-development. So, in essence, I was asking the wrong question.
Lesson #2:
You do not have to install the entire VS Code IDE on the remote device.
That's the original mistake - I misunderstood "install VS Code on the remote device" and I installed the IDE itself in both locations.
The result was that it slowed down the robot so much that it was unusable.
Having more than one instance of the VS Code IDE installed created confusion about what was happening where.
Lesson #3:
I did not realize that VS Code can install a small server module, (like a shim of sorts), and do some SSH magic on the remote device that allows VS code to use the remote device as if it were local to your main computer or laptop.
What you do is open VS Code on the local device, and then tell it you want to connect to a remote device for development.
Once you have that sorted out - this is very site specific and a web search is your friend - you can edit code and even execute code from your local computer and have it run on the remote device as if you were physically there.
In my case, (after experimenting with several different ways to work on my projects), I discovered that placing the VS Code IDE on my Windows based laptop and the "server", (shim) module on the robot, (with the appropriate extensions installed), provides an almost seamless environment that doesn't appreciably load the robot's processor - a Raspberry Pi 4.
Make sure the workspace on the local computer is fully up to date on GitHub (which is where my project repo is located).
Install the requisite VS Code remote development modules and make sure you can communicate with the remote system. Exactly how to do this is specific to your environment.
Either "sync" or "clone" the relevant GitHub repo down to the device using the remote dev tools in VS Code as if it were your local box.
Note that this is very system and site specific. VS Code does a good job of helping walk you through this, and a web-search will rapidly clear up any lingering questions or issues.
Eventually you will have a fully up-to-date version on the remote platform.
When this is done, you won't have to mess with manually syncing code as the code is already on the 'bot. All you do is edit code on your local machine, (my Windows laptop for example), and run it from VS Code.
An additional advantage is that if you have to duplicate or clone the robot's workspace, or restore the workspace from a backup, (you DO have your projects in a separate folder don't you?), all the "vscode" and "git" information is located there too and you can re-open your project after moving it with everything intact.
Additionally, if you have VS Code set up on different machines in different places, it might be possible to connect to the same server endpoint and have the same environment available.
(i.e. One installation on a desktop at work and another installation on a laptop for use on the road, (or while quarantined), both connecting to the same server endpoint.)
Note: I have not done this personally and it might require further research.
What I ended up doing, workflow wise, is that I do the lion's share of the development within VS Code,executing remotely on the robot itself.
Sometimes, if I want to try a quick and dirty fix, I'll "break the forth wall" and open an editor directly on the 'bot itself and it automatically shows up as "modified" within VS Code.
I am experiencing some weird behaviors when debugging my MVC Web Application. Some days I experience these issues, but other days everything works fine.
The breakpoints in my javascript files are not getting hit. I get the dreaded "The breakpoint will not currently be hit. No symbols have been loaded for this document." error.
The debugger will detach from the process without me clicking the Stop Debugging button.
I have tried everything I can think of including:
Refreshing the page in IE to force the browser to get the latest version of the javascript files.
Clean / Rebuild the application in Visual Studio
Close / Reopen Visual Studio
Delete all files from bin and obj folders and rebuild
Cleaned up all old sites from my IIS Express applicationhost.config file
Installed VS2013 Update 4
Deleted / Reinstalled VS2013
Removed / Added IE11
Installed VS2015. Same behavior as VS2013
Deleted all local project files and performed a "Get Latest" from TFS
I can manually attach the debugger to an iexplore process and then I'm able to debug that specific file, but it seems like there is a different iexplore instance for each javascript file. I end up having to guess which one to use for each javascript file. To top it off, the debugger keeps detaching in the middle of me trying to find the right process to attach to. It is nearly impossible, and definitely not feasible to try and debug this way.
Our solution is in TFS, we're using IS Express and the three other developers on our team have none of the problems I have. We all have the exact same hardware.
Another clue that might help is that we are using the OWIN functionality to connect to ACS for security. If I bypass authentication through OWIN / ACS I can step into the javascript. This, however, creates other problems since the code is expecting me to be authenticated. This is not an acceptable workaround and, again, the other developers on the team are using OWIN/ACS and do not have any problems.
I'm extremely frustrated and at a loss for how to go about figuring our what is wrong with my environment. Any help will be greatly appreciated.
I'm experiencing a less-than-ideal workflow at the moment. Here's the context:
The project is a hybrid native-web application
The javascript files are either local (in a .bundle) or on a http server
We have a lot of javascript tests, most of which are integration tests and must be ran in the simulator.
Although I love javascript and the idea of a reusable application, I must recognize that Xcode doesn't play fair. The main pain is that, quite often and despite the full clean / simu reset, Xcode will need to compile twice before it takes the javascript changes in account.
I've tried to touch all the javascript files before each build (as a script run build phase).
I've also tried to clear the webview cache before each run:
[[NSURLCache sharedURLCache] removeAllCachedResponses];
None of the two suffice.
tl; dr: What is your workflow when working with javascript files inside an Xcode project, do you like it and how could I improve mine?
I installed Titanium from appcelerator and built the "KitchenSink" example application.
All works well, I'm just wondering where does the javascript code ends up in a built app.
I grep-ed the Xcode project and also the result application as I found it in Library/Application Support/iPhone Simulator/....KitchenSink.app, but I can't find any function names from .js files, not even string texts used within the application.
Nearest information I found is an answer here : How Does Appcelerator Titanium Mobile Work? but I do not understand clearly how the process works.
Is the javascript code being compiled into a binary code (what compiler is used then?), or is it just transformed in some special data-format and interpreted in a running application ?
Update:
This is what I can see in a build/android directory of KitchenSink:
michal:bin mac$ find . -name table_view_layout\*
./assets/Resources/examples/table_view_layout.js
./assets/Resources/examples/table_view_layout_2.js
./assets/Resources/examples/table_view_layout_3.js
./assets/Resources/examples/table_view_layout_4.js
./assets/Resources/examples/table_view_layout_5.js
./classes/org/appcelerator/generated/examples/table_view_layout.class
./classes/org/appcelerator/generated/examples/table_view_layout_2.class
./classes/org/appcelerator/generated/examples/table_view_layout_3.class
./classes/org/appcelerator/generated/examples/table_view_layout_4.class
./classes/org/appcelerator/generated/examples/table_view_layout_5.class
michal:bin mac$ unzip -t app.apk | grep table_view_layout
testing: assets/Resources/examples/table_view_layout.js OK
testing: assets/Resources/examples/table_view_layout_2.js OK
testing: assets/Resources/examples/table_view_layout_3.js OK
testing: assets/Resources/examples/table_view_layout_4.js OK
testing: assets/Resources/examples/table_view_layout_5.js OK
I didn't look into app.apk before, all I could see were these class files corresponding to each of the javascript files. Therefore I assumed that on Android javascript is being compiled for JVM. Why can't these be found in app.apk ?
Titanium is not a wrapper around a web view as stated before (though that accurately explains how Phonegap works). Jeff's answer, linked in the question, is a technically correct explanation of how Titanium works, but here's the best version I've heard so far, from Marshall Culpepper:
It's true that Titanium Mobile used the WebView (in both Android and iOS) in the pre-1.0 days. However, this is no longer true and hasn't been since our 1.0 release is March 2010.
Since 1.0, we've shipped two separate Javascript runtimes with our apps, and we are running the Javascript code directly without a WebView. Your entire app from start to finish is now controlled by JS, and we provide a comprehensive set of Native APIs that enable this. Everything from UI widgets (yes, including WebView), Core APIs like Networking, Filesystem, Database, all the way to OS-specific things like JS Activities in Android. On the JS runtime front, we're shipping a forked version of WebKit's JavaScriptCore in iOS and a snapshot of Rhino 1.7 R3 CVS for Android. What we actually do with your javascript source is dependent on the platform, but generally it breaks up like this:
Source is statically analyzed to find references to Titanium modules
Localization strings (strings.xml), App metadata (tiapp.xml), and density specific images all generate platform specific analogs.
In iOS:
An XCode project / configuration is generated
JS Source is base64'd and inlined as a variable into a generated C file
xcodebuild is used to generate the final binaries
provisioning profiles, signing keys etc are applied
iTunes and some other glue are used to send the IPA to your iOS device
In Android:
An Android / Eclipse project is generated
In "Development" mode, JS source is packaged as APK assets
In "Distribution" (production) mode, when you're ready to ship the app, we compile the JS to Java bytecode using the Rhino JSC compiler. You can also enable this during development mode by setting "ti.android.compilejs" to "true" in tiapp.xml, see: http://developer.appcelerator.com/question/100201/enable-android-byte-code-compile
dex, aapt, and other Android SDK tools are used to build and generate the final APK
adb and keytool are used for pushing the APK out to the emulator and/or device
There are many more details that I could dive into specifically on each of these points, but the point I wanted to drive home is that we no longer use the WebView as our Javascript engine. You can however still embed WebViews, and we provide some simple integration that allows you to call Titanium APIs from an embedded WebView.
What jhaynie is saying in your linked question is that Titanium interprets your JS code and converts it into something that is almost identical to Objective-C.
In a web application, the browser reads and interprets your Javascript and runs associated native code (perhaps C++) internally. For instance, the browser might say, "This script is executing getElementById(), so I'll run my own C++ methods to accomplish that." What Titanium is doing is figuring out what that JS->C++ (or in this case, JS->Objective-C) would be in advance, and compiling that. It still leaves an interpreter open where necessary for your dynamic code, but it will convert and compile what it can.
That means you won't find anything that looks similar to what you originally wrote in your script. Anything that must be left to an interpreter is still processed and converted, and your symbols will change (e.g. a call to myTestFunction() might be converted to A(), or 10001101001101 :P).
The usual use of Javascript is to have it interpreted real-time by a running program. That's not what's going on here, and that's why you can't see any trace of your script.
Javascript is pre-processed
Titanium performs the interpretation of your script as any other program would do (such as a web browser). It figures out what dependencies your script has on the Titanium API and sets that stuff up. It then maps your symbols directly into (in the case of the iPhone) Objective-C.
A program usually would read in your script (which is a simply a String), interprets it, and runs C code to accomplish what your script asked for. Titanium does this before-hand to figure out what C code should be run, and does the conversion in advance.
Code is compiled where possible
Based on the interpretation of your code and its dependencies on the Titanium API, Titanium figures out what code can be directly compiled, and what must not be compiled in order to allow for they full dynamics of Javascript. I don't know how it chooses what does and doesn't get compiled, but you could check out the source if you want to know that much detail.
Code that must still be interpretted (left as a script) is still converted into symbols that result in more efficient mapping to native code. So it's still an interpreted script, but that doesn't mean it's still Javascript. This means that these parts of your script will still run faster than usual Javascript.
For iPhone, the compilable C is compiled with GCC to create a native binary.
You have a runnable app*
Now you have an app that you can run on your mobile device. Your compilable code has been compiled and runs at lightning speed, while the rest is converted and still interpreted in a more efficient way which runs at near lightning speed. :P
I hope this makes sense now, because it's all I've got! :D
I am trying to run a Ruby script from a cydget (cydget is a framework made by Saurik for writing lockscreens on the iPhone, using cycript, which is a mix of javascript & objc - see http://www.cycript.org/ ) The script will first check to see if a WEBrick server is running, if so it will quietly exit, if not it will start the server.
Apparently the iPhone doesn't support NSTask, and I don't know if the cycript implementation of obj-c does or not. (To be honest, I have no clue how obj-c in cycript works at all!) I'm not worried about security, because I'm running 1 specific command: "ruby server.rb", and everything else will be handled through the web server itself.
Is there any way other than NSTask in objective-c, or any way in javascript or HTML that I can run an arbitrary command on the local machine?
Thank you!
Brent
You can't fork another process on an iPhone at all (assuming we're talking about a legitimate app developed against Apple's official SDK). No NSTask, no fork()/exec(), no system(), nothing.
So it sounds like the best solution is to just wait - Saurik will be coming out with a way of directly using Ruby in a cydget, but it likely won't be out for a few months... :( I hope it will be worth the wait though!