In Xcode 4.3, now you can enable using LLDB as the debugger for iOS targets.
What advantages does it have over using the good old GDB? GDB still works with LLVM and I cannot see any obvious differences in "everyday" debugging tasks.
The most notable advantage is that LLDB understands dot syntax in properties:
po self.property
A quote from LLVM project blog:
LLDB supports basic command line debugging scenarios on the Mac, is scriptable, and has great support for multithreaded debugging. LLDB is already much faster than GDB when debugging large programs, and has the promise to provide a much better user experience (particularly for C++ programmers). We are excited to see the new platforms, new features, and enhancements that the broader LLVM community is interested in.
Another quote from LLDB homepage:
LLDB is a next generation, high-performance debugger. It is built as a set of reusable components which highly leverage existing libraries in the larger LLVM Project, such as the Clang expression parser and LLVM disassembler.
Why a new debugger
In order to achieve our goals we decided to start with a fresh architecture that would support modern multi-threaded programs, handle debugging symbols in an efficient manner, use compiler based code knowledge and have plug-in support for functionality and extensions. Additionally we want the debugger capabilities to be available to other analysis tools, be they scripts or compiled programs, without requiring them to be GPL.
Related
Background
In AOT compiling Dart for iOS Android (Dart Developer Summit 2016):
iOS restriction: Can't JIT
And also, from reading an article from the dart team: Flutter: Don’t Fear the Garbage Collector, I read:
In debug mode, most of Dart’s plumbing is shipped to the device: the
Dart runtime, the just-in-time compiler/interpreter (JIT for Android
and interpreter for iOS), debugging and profiling services.
Question
I wonder what the differences are between these 2 concepts, for dart specifically. Why can't iOS support JIT compilation but it can support a Dart interpreter?
Non-question
This is not about AOT vs JIT compilation, which is the more common question. You can find out about that here.
I also already know the difference between an Interpreter and a Compiler: Interpreter executes the code step by step in a higher level form, instead of compiling it to machine code, like JIT and AOT execution.
There aren't any technical reasons for iOS not to support the Dart JIT compiler, it's due to a security policy by Apple. Also this limitation is not Dart specific, it affects every JIT compiler out there.
A JIT compiler needs to create new machine code on the fly and write it to executable pages, but on iOS that can only be done by apps with the "dynamic-codesigning" entitlement. This entitlement is granted for example to 1st party apps using JavaScriptCore, but not 3rd party apps.
This means App Store apps cannot write to executable memory, and so a JIT cannot be embedded in them. You can run JIT accelerated JavaScript using a WKWebView (which runs in a separate process with 1st party entitlements) but you cannot run your own JIT compiler on iOS.
An interpreter w/o a JIT on the other hand never generates new machine code so it can run without problems on iOS (though the App Store review process still imposes restrictions on what scripts it is allowed to run.)
Over the years there have been several exploits to get a JIT working, allowing for example to switch pages from +w to +x and back, but never both at the same time, but it seems currently none of those work and using a JIT in a 3rd party app is simply not possible. Even if exploits are still available, the Dart team wouldn't rely on iOS vulnerabilities that could be fixed at any time, or worse, cause apps to be flagged as malicious.
Note you'll find articles online talking about how iOS 14 allows 3rd-party apps to use a JIT compiler, but that seems to be limited to apps sideloaded via developer tools so it's not relevant for Dart / Flutter, which target devs who want to distribute their apps via the App Store.
What are the (architectural) differences in implementing a programming language on the GraalVM architecture – in particular between Graal, Truffle, and LLVM using Sulong?
I plan to reimplement an existing statically typed programming language on the GraalVM architecture, so that I can use it from Java without much of a hassle.
There are at moment three options:
Emit JVM bytecode
Write a Truffle interpreter
Emit LLVM bitcode, use Sulong to run it on GraalVM
Emitting JVM bytecode is the traditional option. You will have to work at the bytecode level, and you'll have to optimise your code your before emitting bytecode as the options that the JVM has for optimising it after it has been emitted are limited. To get good performance you may have to use invokedynamic.
Using Truffle is I'd say the easy option. You only have to write an AST interpreter and then code generation is all done for you. It's also the high performance option - in all languages where there is a Truffle version and a bytecode version, the Truffle version confidently outperforms the bytecode version as well as being simpler due to no bytecode generation stage.
Emitting LLVM bitcode and running on Sulong is an option, but it's not one I would recommend unless you have other constraints that lead you towards that option. Again you have to do that bitcode generation yourself, and you'll have to optimise yourself before emitting the bitcode as optimisations are limited after the bitcode is set.
Ruby is good for comparing these options - because there is a version that emits JVM bytecode (JRuby), a version using Truffle (TruffleRuby) and a version that emits LLVM bitcode (Rubinius, but it doesn't then run that bitcode on Sulong). I'd say that TruffleRuby is both faster and simpler in implementation than Rubinius or JRuby. (I work on TruffleRuby.)
I wouldn't worry about the fact that your language is statically typed. Truffle can work with static types, and it can use profiling specialisation to detect more fine-grained types again at runtime than are expressed statically.
I understand that there could be many reasons but when the developer community has already adopted ES6 and is working hard to make it better then why dart and not JS?
Is there anything special which makes dart such a good fit for Flutter?
That's an FAQ and already answered extensively
https://flutter.io/faq/#why-did-flutter-choose-to-use-dart
https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf
I'm not sure why you wrote ES6 and "dart js".
Flutter has nothing to do with JavaScript.
While Dart can be compiled to JavaScript, Flutter doesn't use this feature.
For Flutter Dart is compiled to native binary code.
I did a little research after being asked the question by a couple of colleagues and thought it would help by summarising what I have read and thought about (it's a very important question for my colleagues)
Language requirements for Flutter
AOT and JIT compilation for fast reload and fast released code
A good garbage collector to clean up after creating and destroying many objects
Single threaded to avoid locks and therefore jank
An arm compiler to avoid having another engine running the code on the device (aka React Native)
Dart meets all these requirements. JS (I think) meets all the above pretty closely too, apart from the AOT and JIT compiler part.
Why didn't Flutter choose JS and build a JIT and AOT compiler? (initially they did choose JS but they switched) I could guess at the following...
Dart was built with to-binary compilation in mind from the beginning
Dart already had a to-binary JIT compiler, it added the AOT compiler later
Dart is more structured and simpler (it is type safe and has no eval)
JS could implement new language features that might jeopardise flutter dev
Dart can be optimized for Flutter without needing to worry about other uses of JS
Historically long wait times for new JS functionality (last 3 years has been better)
The Dart and Flutter teams can work together closely
Saying all of that I can imagine that a JS solution could happen but it might be costly and a more complicated solution. Dart is pretty good and Dart2 has really improved things with inherent type safety.
Dart has a declarative and programmable layout that is easy to read and visualize. Hence, Flutter doesn't require a separate declarative layout language like XML. It is easy for Flutter to provide advanced tooling since all the layout in one language and in a central place
Dart is much faster than JavaScript, as it can be compiled both AOT and JIT which helps building apps in several ways as using JIT compilation can speed up development and AOT compilation can be used during the release process for better optimization. This technique has been used in Flutter.
follow the link
https://medium.com/hackernoon/why-flutter-uses-dart-dd635a054ebf
https://insights.daffodilsw.com/blog/why-flutter-uses-dart
What does LLDB ,debugger in xcode, stand for?
Is it something like "low level debugger"?
Googled it, however couldn't find an answer.
As per the Xcode Debugging course on Udacity, LLDB stands for Low Level Debugger
Link to the course - https://www.udacity.com/course/xcode-debugging--ud774
(Mentioned in the 2nd slide of Lesson 3)
LLDB is the debugger component of the Clang/LLVM compiler toolchain.
Check here: http://lldb.llvm.org/
LLDB (low-level debugger) is part of LLVM
The LLVM compiler (low level virtual machine) creates programming languages. LLDB is Apple’s “from the ground up” replacement for GDB.
The LLDB debugger is analogous to GDB: (The GNU Project Debugger).
Both work on many Unix-like systems and works for many programming languages
Each below support debugging programs written in the languages below
GDB: Ada, C, C++, Objective-C, Free Pascal, Fortran, Go, and partially others
LLDB: C, Objective-C, and C++. Also, the Swift community maintains a version which adds support for the language.
I apologize if this question is out of topic, but it's a matter of accessibility for C++14 programmers.
Today i've updated Qt v5.4 on my PC (Windows 8.1/64bit/x86) and it support now the gcc compiler v4.9.2. But i've seen that constexpr relaxation (which really interest me) is available since gcc v5.1.
A search on google shows that :
clang is the better compiler for C++14 latest features (v3.6 is even dealing with experimental C++17)
clang is not easily suitable with Qt libraries
both gcc and clang "datas" are downloadable but i'm not an expert...
So i'm asking how to get a free IDE on Windows 8.1 with an adequate compiler.
If i dismiss Qt for my C++14 experiments, is Codeblocks a better solution ?
Does any else IDE already include an adequate compiler during the installation ?
Where can i find help to install such a compiler ?
Your question is poorly phrased -- for the most part, ide's and compilers are decoupled -- the exception that comes to mind is visual studio, which is an ide that is tightly coupled to microsoft's compiler.
Whether you chose codeblocks, or eclipse, or use a simple text editor, you should be able to choose your compiler fairly easily, and independently of your ide. So you have two independent questions: Where can you get a free compiler for windows with high standards compliance, and what's a good IDE with which to use that compiler.
I'm not a windows person, but very simple, one-file projects, you might actually find it easy to use a gnu-linux environment, which you can do under windows by using cygwin:
http://preshing.com/20141108/how-to-install-the-latest-gcc-on-windows/
This may seem daunting at first, but let me tell you the benefits:
you'll learn the difference between your compiler and editor.
As long as you are only experimenting with the standard, you may find it simpler to get set up than using an ide.
You'll have to learn about the c++ compile process (compiling, linking, possibly preprocessing), not about ide specific stuff.
This will prevent you from conflating ide-specific stuff with c++ stuff, as you have done in your question. As you begin working with projects you'll probably find an ide an advantage, but in the beginning staying close to the raw tools may give you the fastest learning return on investment.
After install cygwin, all you have to do is write your code (using a syntax highlighting editor like gedit or emacs is suggested), and then run
g++ -std=c++14 filename.cpp
to compile your code.
You should be able to use clang under cygwin as well.