In the newer examples (seeds, angular.io,..) there is another import for the bootstrapping process: #angular/platform-browser-dynamic.
Could someone explain what the differences are between that and #angular/platform-browser?
There is no information on the official angular.io website yet.
The difference between platform-browser-dynamic and platform-browser is the way your Angular app will be compiled.
Using the dynamic platform makes Angular send the just-in-time compiler to the front-end along with your application. Which means your application is being compiled client-side.
On the other hand, using platform-browser leads to an ahead-of-time pre-compiled version of your application being sent to the browser. Which usually means a significantly smaller package is sent to the browser.
The documentation for bootstrapping explains it in more detail.
platform-browser contains code shared for browser execution (DOM thread, WebWorker)
platform-browser-dynamic contains the client side code that processes templates (bindings, components, ...) and reflective dependency injection
When the offline template compiler is used, platform-browser-dynamic isn't necessary anymore because all reflective access and metadata are converted to generated code.
If you still want to dynamically generate components like shown in https://stackoverflow.com/a/36017067/217408 then you need the dynamic stuff.
If you look closely at the history of the angular2 then you will find there are two version 1) beta version 2) release candidate version. At present it is r.c 3 (release candidate 3). Release candidate version means bug fix releases before the final release. So when angular2 moves to first release candidate version(rc1) from beta version then it make some directory change... for example
angular2/core---->#angular/core
angular2/platform/browser------>#angular/platform-browser-dynamic
I add a snape here
for more information please visit
https://github.com/angular/angular/blob/master/CHANGELOG.md
i Hope you will find your answer. Thanks
Related
Wanted to play around with Bloc (basic minimum: create a BlElement), followed the basic instructions to fetch the packages here:
Metacello new
baseline: 'Bloc';
repository: 'github://pharo-graphics/Bloc/src';
load
I see the Fetching... being performed and succeed, and then see the Loading baseline... and Loading Bloc progress bars, but then I get thrown into an error:
This package depends on the following classes:
Key
You must resolve these dependencies before you will be able to load these definitions:
Key>>#a
Key>>#arrowDown
Key>>#arrowLeft
Key>>#arrowRight
Key>>#arrowUp
Key>>#b
Key>>#backspace
Key>>#c
Key>>#character:
Any clues?
Update #1:
As it turns out, I should have really read the README, which states pretty clearly that the repo is discontinued.
As Leandro pointed out below, the repo relies on classes (such as Key) that were deprecated after 7.0 (and I can verify that the above worked for me in 7.0)
OTOH, the following, recommended at "the new repo" in 8.0, fails for me with the same problem.
Metacello new
baseline: 'Bloc';
repository: 'github://feenkcom/Bloc/src';
load
Update #2:
After loading a fresh version of Pharo 8.0, the Metacello ... load works for me (my previous image was clearly ... put into a bad state by trying to load the older, invalid version, and now I have to figure out how to undo that damage, but that is a problem for another day).
So, all good now, but I hope the Bloc "booklet" is modified to represent these new version constraints.
Not sure whether this helps but the problem is that the class Key belongs to a deprecated package, namely DeprecatedFileStream.
I was able to load Bloc on Pharo 7.0, where the deprecated classes were still available. Note that in 8.0+ those classes are no longer available.
I'm not a Pharo user, so I cannot provide you with a solution.
That is not the only thing you need. You'll need a different vm and the skia library. It is easier to start with gtoolkit.com to see what you need and how it is built. The vm has some modifications that are not atm in the Pharo vm, for headless usage and no morphic event loop. Skia is used for rendering. In the different github repositories of feenkcom you can find the details. The rendering of bloc to morphic is deprecated.
In traditional model, when program does dynamic linking of shared library, than - as one of side effects - it, usually does not have to care about updates, as when new version (let's say with security or performance fix) comes, it's updated (by some kind of package manager on some Uhix or sth equivalent on Windows), and application can benefit on next run from new version.
In such process, application maintainer does not have to perform any steps, in order for his/her users to benefit from new , fixed library.
How does it work in Native Client?
Are those libraries packed in package, so developer has to repackage every time new version of library comes,
or is there some mechanism, either to benefit from some way or sharing libraries, or getting this package repacked automatically (for example by Chrome Web Store) ?
I've eye-balled:
Distributing Your Application
Building
Application Structure
and couldn't find answer. (It does not mean it's not there, I could miss sth).
Based on my experience with NaCl, your app is responsible for updating any libraries it depends on, as those libraries are necessarily distributed with your NaCl application. The exception would be any libraries/APIs that the browser provides to the application, which would be updated along with the browser.
It turns out, there night be a way of structuring application, so app can download new shared libraries via some bootstrap executable and than run, desired one with freshly downloaded shared libraries:
http://developer.chrome.com/native-client/devguide/devcycle/dynamic-loading (please note
that it's different page than this one earlier mentioned )
search for "libreverse.so" example.
Anyhow, if you have better structured answer and/or more detailed, please let know.
At Latest API documentation NodaTime.Serialization.JsonNet is shown as a part of NodaTime library.
But I can't find it anywhere. Here's the NodeTime in ObjectBrowser in my VisualStudio.
I even looked into NodeTime.Testing and haven't found it.
I don't know where to look for it anymore. These two (NodeTime and NodeTime.Testing) are only packages available over NuGet.
From the page you linked to:
Code in this namespace is not currently included in Noda Time NuGet packages; it is still deemed "experimental". To use these serializers, please download and build the Noda Time source code from the project home page.
For 1.2, we'll be distributing a separate pre-built assembly and NuGet package, but that's not quite ready yet, so for now you'll have to build your own.
I am experimenting with ServiceStack's JSON engine. I grabbed the MonoTouch binary build, v2.20. Works fine from simulator, but from the iOS device (iPad2, iOS5) I get an exception thrown by the type initializer for JsonWriter (and not much other than that). I am using MonoTouch 5, MonoDevelop 2.8.1, and targeting iOS 5. I have disabled library linking because I am getting an error when enabled.
I created a sample and uploaded to https://github.com/t9mike/ServiceStack-JSON1.
I'm trying to determine whether the issue is my compilation options, Service Stack, or MonoTouch. Thanks in advance.
A quick partial answer that might help:
I have disabled library linking because I am getting an error when enabled.
The current (5.0) managed linker can eliminate some unused (from a static analysis point of view) code from your application. This generally occurs when using Link all option, i.e. where user code gets processed by the linker.
One alternative is using the Link SDK assemblies only that won't touch the user code (only the code shipped with MonoTouch itself will be processed by the linker).
Another alternative is adding [Preserve] attributes on your code to ensure the serializer requirements are still met after the linker has processed your code. More information about the linker and [Preserve] attributes can be found here.
The next (5.2) release of MonoTouch will include a bit more sophisticated step in the linker to ensure the basic XML serialization and DataContract requirements are not broken. Not sure if this will solve this specific case (ServiceStack JSON) but I'll have a look into it.
As for the rest of your question I'll try to build this myself and duplicate your issue.
I ended up grabbing the ServiceStack.Text sources from GitHub, version 3.0.3. I created a new MonoTouch library project. I had to tweak ServiceStack.Text/JsConfig.cs slightly to conditionalize away the System.Drawing.Color bits. I'll send a patch and MT csproj to the authors.
After using this new assembly, my sample MT app ran fine on the device. I have updated my sample at https://github.com/t9mike/ServiceStack-JSON1 with the new ServiceStack.Text dll.
If you have a project, that releases a library and an application, how you handle version-numbers between the two.
Example: Your project delivers a library, that convert different file-formats into each other. The library is released for inclusion into other applications. But you also release a command-line-application, that uses this library and implements an interface to the functionality.
New releases of the library lead to new releases of the application (to make use of all new features), but new releases of the application may not trigger new releases of the library. Now how are the versions numbers handled: Completely independent or should library- and application-version be dependent in some way?
Completely independent version numbers, but the command line (or any other dependent) app should say which version of the library it was compiled against in the help section or a banner.
That way you will be able to tell which functionality will the apps have and reduce potential confusion, especially given that somebody could compile a newer app version against an old library for any reason. Also, you decouple them and can add features on the library without depending on release of a new app version and so on.
If you are sure you will always want all the apps and library to go in lockstep then you could use same numbers, but that's adding a constraint for not a strong reason.
I'd say use separate version numbers, and of course document what minimum library version is required for each release of the app. If they always have the same version number, and you only ever test the app against the equal-numbered library version, then they aren't really separate components, so don't say they are. Release the whole lot as one lump.
If you make them separate, you can still give them the same version number when it's appropriate - for example after a major compatibility break you might release Version 2.0 of both simultaneously.
The following example illustrates: xsltproc (a command-line app) is released as part of libxslt (a library), so doesn't have its own version number. But libxslt depends on two other libraries, and the version numbers of those are independent.
$ xsltproc --version
Using libxml 20628, libxslt 10120 and libexslt 813
xsltproc was compiled against libxml 20628, libxslt 10120 and libexslt 813
libxslt 10120 was compiled against libxml 20628
libexslt 813 was compiled against libxml 20628
We built an application that uses a framework. We keep separate version numbers for both.
This works well, especially that now the framework and application have grown large enough to be developed by different teams.
So my opinion... keep the version numbers separate.