I messed up in my code - I create lots of short-lifetime objects and use MEF to resolve dependencies. As anyone with some MEF experience knows, MEF holds onto a reference on these guys. The result is the short lifetime turns into LOOONNNGGG lifetime. So, this is easy enough to fix - use SatisfysImportsOnce on CompositionContainer.
But I'd like to make this x-check part of my unit tests now so that I don't accidently add an incorrect part into the container (or perhaps I missed one in the code search I just did). Sooo... how to do this?
My code, a bit abstracted, looks something like this:
_catalog = new AggregateCatalog();
_container = new CompositionContainer(_catalog);
_batch = new CompositionBatch();
I then add parts to a batch, and call _container.Compose(_batch). I thought perhaps something like the following would work to get a count, but it always returns zero:
int nParts1 = _container.Parts.Count();
int nParts2 = _container.Catalogs.Sum(c => c.Parts.Count());
However, both of those return zero. How can I get this count for tests? It is ok if perf isn't fantastic - this is part of the test, not the running app. Many thanks in advance!
There's not a simple way to do this. You'll need to go digging around in the internal implementation of MEF to find this information. Since the source code is available (mef.codeplex.com) this is quite possible, but still not too simple.
Related
Cache2k looks like a very promising caching implementation. Unfortunately the documentation is very limited, which is why I need some help with the following issue. I am using the latest version 0.26-BETA.
According to the documentation the cache is supposed to be created like this:
Cache<String,String> c =
CacheBuilder.newCache(String.class, String.class).build();
String val = c.peek("something");
assertNull(val);
c.put("something", "hello");
val = c.get("something");
assertNotNull(val);
c.destroy();
Unfortunately at least 2 of these methods are deprecated, including the CacheBuilder class itself. I therefore tried creating the cache like this:
org.cache2k.Cache<String, Object> newCache = Cache2kBuilder.of(String.class, Object.class)
.name(cacheKey.toString())
.entryCapacity(100000)
.eternal(true)
.build();
This however throws the "java.lang.UnsupportedOperationException: loader not set" exception.
The question therefore is: how am I supposed to build the cache so that I do not get this exception?
EDIT:
This gives me the same exception:
org.cache2k.Cache<Object, Object> newCache =
CacheBuilder.newCache(Object.class, Object.class)
.eternal(true)
.build();
EDIT #2:
Just one more note: When I copy&paste the code from the wiki page I get an error - as can be seen in the image below.
With what jdk version are you testing? I'll try just removing the <> that are causing the problem for now.
Thanks very much in advance!
Michael
Cache2k looks like a very promising caching implementation.
Thanks :)
According to the documentation the cache is supposed to be created like this
There are new interfaces in place. The deprecated one is still there to support users of old cache2k versions. That will get cleared up in the next weeks. Sorry for the confusion.
Please take a look here for the latest getting started information:
https://github.com/cache2k/cache2k/blob/master/doc/src/docs/asciidoc/user-guide/sections/_start.adoc
This however throws the "java.lang.UnsupportedOperationException: loader not set" exception.
The question therefore is: how am I supposed to build the cache so that I do not get this exception?
Short answer: Either use cache.peek() or wait for 0.27, since then it is working with cache.get() transparently.
Longer answer: In our own applications I use cache.get() only when a loader is defined and cache.peek() when no loader is defined or when I want to inspect the cache only. Reserving cache.get() only for the read through usage, seemed like a good idea. However, I reasoned that it might be a caveat for new users, so I change that behavior and align it to other cache solutions.
Answer to Edit 2:
For an untyped cache use the factory method Cache2kBuilder.forUnkownTypes(). Constructing the anonymous class is only needed for specific types.
I'm using the current version of the TypeSafe Scala/eclipse IDE. I have an object (which I called PositionObj to give it a unique name). PositionObj contains a main method. Yet when I try Run as > Scala application I get a pop-up message saying:
PositionObj needs to be an 'object' (it is currently a 'class').
In fact it's not a class, and there is no class with that name. Any thoughts about why this is happening and how I can get around it?
Here is the relevant code.
object PositionObj { ...
def main(args: Array[String] = Array[String]()): Unit = {
// This is just to see if anything happens.
println(position(3).p1Rqmts.keys.head)
}
...
Thanks.
Based on your answered-to code, try removing the default argument, since this might be creating a different code signature
I should have done this before, but now I notice that there is a compiler error message that says that the compiler couldn't handle the code because it was too big for a method. That's consistent with my experience with the problem. When I comment out a large table of data, everything works fine. So I'm now convinced that the problem was simply that the program was organized in a way that pieces of it were too large to be handled by the compiler.
I got around the problem by chopping my data table into multiple parts and including each one in a separate object. That worked even though all the objects were then included in the overall program. It was not the size of the program overall; it was the size of large chunks.
The compiler error message was somewhat misleading in that it said the problem was that a method was too large. In fact, my data table was a val in an object and not within a method. But as I said, chopping it up into separate objects and combing them with software solved the problem.
...and why has the package this misleading name (I assumed it had something to do with JavaME or mobile/smart phones)?
I found no references on the internet about scala.mobile.Code or scala.mobile.Location at all nor did I manage to do anything with those classes except getting ClassCastExcetions or NoSuchMethodErrors.
Actually there is not even a single test against scala.mobile in the Scala's test tree which could help understanding that code.
The classes really smell like they were forgotten in the source tree a long time ago and got accidentally released since that.
Maybe I just missed something about them?
Update:
scala.mobile was removed in Scala 2.9.
I just checked the source code.
When Scala changed the name mangling of class files a few years ago and it seems people forgot to update these classes accordingly.
So my answer would be:
At least Location has no purpose, because it is not possible to get anything sensible out of it (except exceptions) and Code without Location is severely limited. It works though if you pass the class literal to Code directly:
import scala.mobile._
val c = new Code(classOf[scala.collection.mutable.StringBuilder])
c.apply[StringBuilder, String]("append")("Foo")
c.apply[String]("toString")() // returns "Foo"
c.apply[Int]("length")() // returns 3
Looks like yet-another implementation in the standard library of reflection-slightly-nicer.
The description of Location pretty much explains what that is about:
The class Location provides a create method to instantiate objects
from a network location by specifying the URL address of the jar/class file.
It might be used by remote actors. Maybe.
As for why it has this misleading name? Well, back in 2004 smart phones had really low penetration, so maybe the association wasn't all that strong.
I searched the web for how to enforce srictfp in Scala but could not find any hint of it. There are some people complaining about it, but real solutions cannot be found. There is a bugtracker entry about it which is almost two years old. As it seems there is no elegant fix for it on the way I'm looking for workarounds.
My current idea is to set the appropiate method flag ACC_STRICT in the generated bytecode by myself somehow but I have no idea what would be the best solution to do so. A Scala Compiler Plugin comes to mind or just hacking flags in a hex editor. Maybe someone faced the same challenge and can tell me his or her solution?
You could add a post-processor in your build process that would add the strictfp modifier to the generated class (i.e. setting the ACC_STRICT flag as you say).
You can implement such a post-processor using Javassist for example. This could look like this:
CtClass clazz = ClassPool.getDefault().makeClass(
new FileInputStream("old/HelloWorld.class"));
CtMethod method = clazz.getDeclaredMethod("testMethod");
method.setModifiers(method.getModifiers() | Modifier.STRICT);
clazz.detach();
clazz.toBytecode(new DataOutputStream(new FileOutputStream(
"new/HelloWorld.class")));
You would then have to find a way to configure which classes/method need to be modified this way.
Scala has a strictfp annotation now:
#strictfp
def f() = …
Do you use table-of-contents for listing all the functions (and maybe variables) of a class in the beginning of big source code file? I know that alternative to that kind of listing would be to split up big files into smaller classes/files, so that their class declaration would be self-explanatory enough.. but some complex tasks require a lot of code. I'm not sure is it really worth it spending your time subdividing implementation into multiple of files? Or is it ok to create an index-listing additionally to the class/interface declaration?
EDIT:
To better illustrate how I use table-of-contents this is an example from my hobby project. It's actually not listing functions, but code blocks inside a function.. but you can probably get the idea anyway..
/*
CONTENTS
Order_mouse_from_to_points
Lines_intersecting_with_upper_point
Lines_intersecting_with_both_points
Lines_not_intersecting
Lines_intersecting_bottom_points
Update_intersection_range_indices
Rough_method
Normal_method
First_selected_item
Last_selected_item
Other_selected_item
*/
void SelectionManager::FindSelection()
{
// Order_mouse_from_to_points
...
// Lines_intersecting_with_upper_point
...
// Lines_intersecting_with_both_points
...
// Lines_not_intersecting
...
// Lines_intersecting_bottom_points
...
// Update_intersection_range_indices
for(...)
{
// Rough_method
....
// Normal_method
if(...)
{
// First_selected_item
...
// Last_selected_item
...
// Other_selected_item
...
}
}
}
Notice that index-items don't have spaces. Because of this I can click on one them and press F4 to jump to the item-usage, and F2 to jump back (simple visual studio find-next/prevous-shortcuts).
EDIT:
Another alternative solution to this indexing is using collapsed c# regions. You can configure visual studio to show only region names and hide all the code. Of course keyboard support for that source code navigation is pretty cumbersome...
I know that alternative to that kind of listing would be to split up big files into smaller classes/files, so that their class declaration would be self-explanatory enough.
Correct.
but some complex tasks require a lot of code
Incorrect. While a "lot" of code be required, long runs of code (over 25 lines) are a really bad idea.
actually not listing functions, but code blocks inside a function
Worse. A function that needs a table of contents must be decomposed into smaller functions.
I'm not sure is it really worth it spending your time subdividing implementation into multiple of files?
It is absolutely mandatory that you split things into smaller files. The folks that maintain, adapt and reuse your code need all the help they can get.
is it ok to create an index-listing additionally to the class/interface declaration?
No.
If you have to resort to this kind of trick, it's too big.
Also, many languages have tools to generate API docs from the code. Java, Python, C, C++ have documentation tools. Even with Javadoc, epydoc or Doxygen you still have to design things so that they are broken into intellectually manageable pieces.
Make things simpler.
Use a tool to create an index.
If you create a big index you'll have to maintain it as you change your code. Most modern IDEs create list of class members anyway. it seems like a waste of time to create such index.
I would never ever do this sort of busy-work in my code. The most I would do manually is insert a few lines at the top of the file/class explaining what this module did and how it is intended to be used.
If a list of methods and their interfaces would be useful, I generate them automatically, through a tool such as Doxygen.
I've done things like this. Not whole tables of contents, but a similar principle -- just ad-hoc links between comments and the exact piece of code in question. Also to link pieces of code that make the same simplifying assumptions that I suspect may need fixing up later.
You can use Visual Studio's task list to get a listing of certain types of comment. The format of the comments can be configured in Tools|Options, Environment\Task List. This isn't something I ended up using myself but it looks like it might help with navigating the code if you use this system a lot.
If you can split your method like that, you should probably write more methods. After this is done, you can use an IDE to give you the static call stack from the initial method.
EDIT: You can use Eclipse's 'Show Call Hierarchy' feature while programming.