This was answered once, but the download site has since changed (apparently) since then. I cannot find Castle.MicroKernel at all. 2.51 can no longer be downloaded and its not in 2.52. or 2.53.
There is no Castle.MicroKernel.dll anymore, it was merged into Castle.Windsor.dll.
The namespaces are all the same though, i.e. the Castle.MicroKernel namespace and all its types now live in Castle.Windsor.dll
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!
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
I'm using PhpStorm 10 to work on a craftCMS project, and I'd like to register *.html as a pattern for Twig files as discussed here.
My question: Is there a way to do this in a manner that it will only affect this particular project, allowing my other projects to still use that pattern to identify HTML files?
...that it will only affect this particular project...
Unfortunately no.
https://youtrack.jetbrains.com/issue/IDEABKL-6335 -- watch this and related tickets (star/vote/comment) to get notified on any progress.
Right now this ticket is located in "IDEA Backlog" project .. which means that it's quite unlikely that it will be implemented any time soon. Plus, developers clearly stated (comment 1 & comment 2) that they do not really plan to implement such stuff.
That being said, it is something that could be written into a plugin (an example).
To use twig in PHPStorm for CraftCMS one can simply rename those .html files to .twig and Craft will load them fine.
We've been using jquery/globalize in our web application with the CLDR 29 data in JSON format without any problems. Just recently, Unicode released CLDR 30 (and shortly after, version 30.0.1 with some fixes).
When we upgrade to the CLDR 30(.0.1) data, our client-side currency-formatting tests are failing because, for many cultures, the "currencySpacing" information in numbers.json is no longer there. For example, assuming the culture ar-AE, the Globalize library tries to load CLDR data at the path...
/main/ar-AE/numbers/currencyFormats-numberSystem-arab/currencySpacing/beforeCurrency
...which doesn't exist in the latest CLDR 30 numbers.json data for this (and many other) cultures.
We've been trying to traverse the stack to see what's causing this problem. We started with the DTD. The DTD for CLDR 30 (along with that for CLDR 29) includes the line...
<!ELEMENT currencyFormats ( alias | ( default*, currencySpacing*, currencyFormatLength*, unitPattern*, special* ) ) >
...which implies that the currencySpacing is an optional element. That said, we can't find anything in the CLDR 30 release notes or Delta that suggests that this information was changed for a large number of cultures.
In the XML data (the "ground truth") we see that the currencySpacing element is only used in main/root.xml in both CLDR 29 and CLDR 30, i.e. apparently no significant changes in this respect in the XML.
This makes us wonder if it's a problem in the tool that's used for generating the JSON data from the XML data. The tool is called ldml2json and is also used by the cldr-json project. To rule out a bug in the cldr-json project, we built the tool ourselves and generated the JSON data ourselves. This generated data was then also missing the "currencySpacing" information in the numbers.json files. So it doesn't seem to be an issue with the cldr-json project.
If we understand correctly, this means that the problem is either:
The ldml2json tool has a bug
jquery/globalize is incorrect to assume that this information always exists
If the latter is true, then I guess this should be raised as a jquery/globalize bug. Investigating the former would require us to debug from source presumably. Before we go investing time in either, we wanted to ask: Is anybody else seeing this problem, and is there any known solution? Our hope is that there's someone out there who's a bit more experienced in the CLDR+JSON+Globalize stack that can help us out!
This was caused by this change: http://unicode.org/cldr/trac/changeset/12636/trunk/common/main/root.xml
Before this change, the root locale's currencySpacing information for the arab number system was inherited by all the other locales. Now it's no longer there.
I'm not sure how the missing currencySpacing should be handled, but the java and C documentation both state that the data can be null.
Both appear to use a hard-coded default in that case: http://bugs.icu-project.org/trac/browser/icu4j/trunk/main/classes/core/src/com/ibm/icu/impl/CurrencyData.java#L86
So this is probably a bug in globalize.
Update: Bug report and pull request.
The recent CLDR 30.0.2 patch fixed this bug, so no updates needed for Globalize.
By the way, follow the UTS#35 specification for deeper investigation :)
http://www.unicode.org/reports/tr35/tr35-numbers.html#Currencies
Why is changing lines in configuration file considered an anti-pattern in Chef or Puppet?
It's something like bad habit, as I understood. I assume that this file-editing is done in some idempotent way and with advanced tools (augeas for example).
Why is deploying the whole files, with ERB templates, considered a preferred method?
You can find a lot of examples where dev-ops are suggesting usage of templates instead of file-editing. For example here, here, here, etc.
Actually there is a large part of the DevOps community that sees accepting system/package defaults for config files and only modifying what you need through augeas as the preferred method, Github devops would be one of them(if you happened to catch them at Puppet Conf 2012).
I think having a default pattern of always using templates creates too high of a maintenance load and almost always requires you lock in specific versions for everything across your stack or you risk having an incompatible template against a newer version of that resource.
There's use cases for both options but in general I favor the "own as little as possible" practice vs the "own everything even if you don't have to" practice.
In terms of setting the your system to a known state, deploying whole files is better than editing, because you are sure the file is exactly as intended when you are done.
If you are tinkering around finding potential solutions to a problem and hand edit some configuration file, you don't have to worry about the hand edit you made staying around as an uncontrolled part of your environment. The next time you run chef-client, you know that the state will be exactly as specified in the Chef recipe, and won't include your edit.
Also, it is just in general harder and more complicated to robustly edit a file than it is to just generate one. You might write something that is idempotent in the basic case, but if the file contains a syntax error or something invalid, than your editing no longer works.
As always though, sometimes you don't have a choice, and editing is the only way to go.