I previously asked How do we check whether a dynamic clay object has a property? My question assumed that an Orchard.ContentManagement.ContentPart was a dynamic Clay object. Is it a dynamic Clay object?
No. It used to be the case, but it was recently removed, and replaced with several more specialized, and faster implementations of dynamic. The Clay dependency is completely gone.
Related
I'm quite new to the Haskell stack, so I might be misunderstanding how things are intended to work here, but I have a problem that I've seen a few times and am wondering if I'm going about the wrong way.
In short, I sometimes want to use a package with a version spec that is capped at a lower version of base than what my Stack resolver includes.
For example, I can't use the lts-12.14 resolver with PSQueue-1.1, because the former includes base-4.11.1 and the latter requires base >=4 && <4.11.
The two ways I have found to resolve that has been to either
add a specific version of base to my extra-deps, making sure that the pinned version is within the range my package allows; or
choose a different resolver (using e.g. https://www.stackage.org/diff/ to figure out which one is the latest resolver with an early enough version of base)
Both of these feel suboptimal, especially since I might want to use packages which have non-overlapping ranges (e.g. one >=3 && <4.11 and one >=4.11). I realize that using such a combination toghether might fail, especially if they are locked on different major-versions of base (assuming base uses semver), but so far I'm only writing pretty small programs, so if they seem to work I'm quite happy even if there are other, non-exercised code paths that will fail on the specific combination of packages and versions. In other words: I know the risk - but I can't chance it, because I don't know how to.
Is there a way to force Stack to allow a newer version of base than the one specified in the requirements of a dependency?
I think you are looking for allow-newer - https://docs.haskellstack.org/en/stable/yaml_configuration/#allow-newer
Ignore version bounds in .cabal files. Default is false.
I will need to import and work on few databases containing parameters in bw2, ecoinvent(s) and another db exported from Simapro. While in the past I had used bw2parameters I have seen now the handling of parameters has been also included in bwdata and I am getting a bit confused. what is the workflow now? should I just rely and work with one of the two, both or what? and with which version of the two packages?
thx
Parameters (named variables and formulas stored as strings) are introduced in Brightway2-data version 3.0, which is currently a release candidate. Although we have effectively 100% test coverage and some documentation, I would like to wait a bit before the final release to improve the documentation and make sure that there aren't any bugs that pop up somewhere. That being said, I would feel completely comfortable using the release candidate (along with Brightway2-IO 0.6.RC3, which provides nice ways to specify parameters).
bw2parameters is a library for evaluating a graph of variables and formulas. bw2data is a library for storing, loading, and exporting variables and formulas, tracking when their values are obsolete. They don't compete but instead work together.
why we should not use any classes from portal-impl.jar inside your portlet?
In my case, how can I read PropsValues without adding portal-impl to maven dependencies.
I'm using Liferay 6.2
Thanks
#Origineil - in a comment to your question - gave you the alternative of what to do instead of using portal-impl.jar (e.g. use GetterUtil.getBoolean(PropsUtil.get(PropsKeys.SESSION_TIMEOUT_AUTO_EXTEND)); instead of PropsValues.SESSION_TIMEOUT_AUTO_EXTEND.
Why shouldn't you add portal-impl.jar to your project? Well, there are many reasons. First of all: It doesn't work. If you add portal-impl.jar to your plugin, there are quite a lot of spring components in there that would re-initialize - and they'd assume they're in the portal context. They'll be missing other code they're dependent on and you'd basically pull in a lot of Liferay's implementation and dependency code, making your plugin ridiculously big. And the initialization can't be done twice, so it won't even work anyways.
Plus, in portal-impl.jar you'll only find Liferay's implementation details - none of this code is ever promised to be stable. Not only will nobody care if you're depending on it, it'll most likely break your assumptions even on minor upgrades. Of course some components in there are more stable then others, but the basic assumption is a good one.
Liferay's API (that you're encouraged to use) lives in portal-service.jar. This is automatically available to all plugins and it contains the implementation mentioned above. Don't depend on someone's (Liferay's) internal implementation. Rather depend on the published API. If this means that you'll have to implement something again - so be it. It might be slightly less elegant, but a lot more future proof. And if you compare the size of portal-impl.jar to the amount of code that you'd duplicate in the case of PropsValues, you'll see that this single expansion is actually a nobrainer. Don't pull in 30M of code just because you'd rather type 30 characters than 60.
I'm using nuget (as many of you) a lot for referencing external and internal component-assemblies.
For debugging purposes, it would be nice being able to exchange the nuget-assembly for it's source-code.
Unfortunately, some "core-lib" is used pretty often by the solution itself and also some nuget-referenced packages (used by the sln). Simply removing the reference via VS and adding it's source-project often causes an ambigous relation to the "core-lib", because both (sln and package-src) use the "core-lib" - mostly in different versions.
The only way (I know) to solve that issue is to update all references to the same version (usually, the most actual one). That can be pretty annoying, especially in bigger projects.
Maybe there exists a way to make referencing more flexible - e.g. by using wildcards in the hint-path?
Thanks for all suggestions!
Did you try using symbol packages ? More details # http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-symbol-package
so that you can make your program concurrent easily in the future.
I focus on making items Immutable. Immutable objects allow you to reason about multi-threaded code a lot easier than "thread safe" objects. The object has one visible state that can be passed between threads without any synchronization. It takes the thought out of multi-threaded programming.
If you're interested, I've published a lot of my work with immutable objects, in particular immutable collections on code gallery. The name of the project is RantPack. In the collection area I have
ImmutableCollection<T>
ImmutableMap<TKey,TValue>
ImmutableAvlTree<T>
ImmutableLinkedList<T>
ImmutableArray<T>
ImmutableStack<T>
ImmutableQueue<T>
There is an additional shim layer which (CollectionUtility) which will produce wrapper objects that implement BCL interfaces such as IList<T> and ICollection<T>. They can't fully implement the interfaces since they are immutable but all possible methods are implemented.
The source code (C#) including the unit testing is also available on the site.
I program mainly in Java. I'm waiting patiently for the day where closures will be added to the language. But as I am still stuck on Java 1.4.2, even if they get added, that's not going to be for me for a long time !
That said, my main "functional" way of programming is making a lot of use of the "final" keyword. I try to have as many classes as possible completely immutable, and for the rest to have a clear distinction between what's transient and what's immutable.
Don't use member variables or global variables. Use the local stack of functions/methods. When a method uses only internally scoped variables and call parameters and returns all information using out/inout/reference parameters or return values, it is functional.
Make everything asynchronic.
Use immutable objects, messages, etc.
Communicate via queues.
Here's a talk on rubyconf 2008 about the subject, it's mostly ruby centered, but several concepts remain valid.
http://rubyconf2008.confreaks.com/better-ruby-through-functional-programming-2.html