I have used the MongoDB driver more or less in C++ only. But now I need it also in C#.
For one of my functionalities I use the function "getFieldDotted" of class BSONObj to get a BSONElement is a deeper tree of the BSONObj.
It seems that an equiqalent functionality does not exits in C# driver!? All tries to use an "dotted" element name result in an exception "KeyNotFoundException" even if the key exist.
Any ideas?
From what I found out, there is no equivalent to the C++ driver "getFieldDotted" function.
The C# driver is able to use "array indices":
value=BsonDoc["Element"]["AnOtherElement"];
I used this. It is the best for my requirements accessing specific elements that are at fixed positions in the BSON object without looping or searching.
Related
I have a school project which aims to statically type some Ruby code. So, my input is simply a .rb file, and I should be able to type every variable that is assigned in the program.
Right now, what I'm planning to do is :
get the file's AST with the Parser library
put each kind of nodes in container objects
implement the visitor pattern to recursively go through the program
try to infer something from there (I was thinking of somehow creating a table of possible input and output types from the core's methods)
I only accept some very basic Ruby as input ( = no call to external library, just the core of ruby + defined-in-the-file methods)
My question is : what do you think of my approach? Is there any gem/existing programs that could help me?
Your approach is technically correct, but it sounds very strange how you put it. This:
Right now, what I'm planning to do is :
get the file's AST with the Parser library
put each kind of nodes in container objects
implement the visitor pattern to recursively go through the program
try to infer something from there (I was thinking of somehow creating a table of possible input and output types from the core's methods)
sounds a little bit like you wanted to go to Mars like this:
Right now, what I'm planning to do is :
get a pencil
get a piece of paper
get a desk
sit down at the desk and use my pen and paper to design a space launch system and Mars lander
In other words, you list three completely trivial points that are maybe an hour of work for an experienced programmer, and then a fourth, that is multiple years of work and worth a PhD.
The most advanced work I know regarding static type inference for Ruby was Diamondback Ruby (DRuby) (not to be confused with the Distributed Ruby standard library aka dRb / dRuby). However, Diamondback Ruby is now abandoned, since the authors gave up on static type inference for Ruby.
One of the principal researchers behind Diamondback Ruby is now working on a new project called RDL. The main differences between Diamondback Ruby and RDL are:
RDL performs dynamic checking, not static checking
RDL relies on explicit annotations, not implicit inference
Steep is another similar project. It, too, relies on dynamic checking and annotations, and in addition does not actually strive for type-correctness.
Ruby Type Inference for IDEA is a complete re-think of how JetBrains plans to approach type inference for Ruby in their IDEA / RubyMine IDE. This does use type inference, but it uses dynamic type inference, not static.
So, as you can see, static type inference for Ruby is so hard that nobody is even trying it, and the guys who did try gave up on it and are now doing dynamic type checking with explicit type annotations instead.
Ruby Type Checking Roundup on Robert Mosolgo's blog is a good overview about the current state-of-the-art in Ruby typing.
I am trying to see if there is a way to get the contents of a datagridview that is inside a top level window using Windows API's. I am using Visual Basic for this, but could also use C.
I doubt you could use the WinAPI to drill into a .NET app's DGV to get any meaningful information. But you might be able to using Reflection which enables you to obtain information about assemblies and the types defined within them, such as classes, interfaces, and value types. The ops are contained in the System.Reflection namespace.
Its fairly slow, so it is often a last resort, and the methods and such are pretty dense (convoluted) because you are getting at the information the 'long way around' by examining the Types and then asking the type for information.
This project shows how to access information in a different executing assembly. Given enough time and work and study, it should give you an idea how to do what you are asking.
Come across an issue when doing a string compare as part of the where section of a linq expression against LINQ for NHibernate.
from x in NhibernateObject
where x.StringCol = "value"
select x
When it runs it retrns a runtime error about casting to an integer. I found a nice post about the issue and the solution at http://jason.pettys.name/archive/2009/09/28/nhibernate-with-linq-error-with-string-comparisons-in-vb.net.aspx
But my question is what is a "visitor" and what code would I write to achive the solution highlighted in the above post - missing the link here !!!
Visitor is a design pattern. You can find a description of it here http://www.dofactory.com/Patterns/PatternVisitor.aspx or here http://en.wikipedia.org/wiki/Visitor_pattern
If I correctly understand the article you linked to (haven't read it fully), then it is required to change NHibernate to work around this problem.
The definition of the visitor pattern is: "Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new
operation without changing the classes of the elements on which it operates."
The namespace of the visitor(s) you want to change is NHibernate.Linq.Visitors. You will probably have more difficulties using VB instead of C# with NHibernate.Linq, because VB3 does not support everything c#3 does. Those problems will be solved if you use .Net 4.0 (or c# of course)
I have a scenario where I have custom configured column names, associated operators like < > = between etc. and then a value associated.
I'm trying to determine if it is possible to build up a LINQ query with a dynamic (string) where clause?
I've noticed the Predicate.OR Preditcate.AND stuff, but that is not quite what I'm talking about.
Any suggestions?
If you are talking about a string Where clause (rather than building the expression etc yourself) - then the Dynamic LINQ Library (in the 3.5 samples, IIRC) should suffice.
Note that the example below is for database usage; but you can use it with LINQ-to-Objects by calling .AsQueryable() on your in-memory data.
Actually, there is a specific library from Microsoft (System.Linq.Dynamic) that comes with the C# VS2008 samples that supports this. Get it from here (Microsoft Download)
The library is included in the \LinqSamples\DynamicQuery directory of the samples of above download.
For extensive usage examples check this page: http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx
Also you can use expression trees to created dynamic queries. See:
http://msdn.microsoft.com/en-us/library/bb397951.aspx
http://www.interact-sw.co.uk/iangblog/2005/09/30/expressiontrees
http://blogs.msdn.com/charlie/archive/2008/01/31/expression-tree-basics.aspx
I'm looking into writing an addin (or package, if necessary) for Visual Studio 2005 that needs watch window type functionality -- evaluation of expressions and examination of the types. The automation facilities provide
Debugger::GetExpression, which is useful enough, but the information
provided is a bit crude.
From looking through the docs, it sounds like an
IDebugExpressionContext2 would be more useful. With one of these it
looks as if I can get more information from an expression -- detailed
information about the type and any members and so on and so forth, without having everything come through as strings.
I can't find any way of actually getting a IDebugExpressionContext2,
though! IDebugProgramProvider2 sort of looks relevant, in that I
could start with IDebugProgramProvider2::GetProviderProcessData and
then slowly drill down until reaching something that can supply my
expression context -- but I'll need to supply a port to this, and it's
not clear how to retrieve the port corresponding to the current debug
session. (Even if I tried every port, it's not obvious how to tell
which port is the right one...)
I'm becoming suspicious that this simply isn't a supported use case, but with any luck I've simply missed something crashingly obvious.
Can anybody help?
By using IDebugExpressionContext you'll ultamitely end up getting ahold of an instance of IDebugProperty. This interface is implemented by the Expression Evaluator service. This is, typically, a language specific service. It's designed to abstract out the language specific details of evaluating an expression. It understands much higher level commands like "Evaluate", and inspection.
I don't think you're going to get what you're looking for though because you can't get ahold of any kind of type object this way. Nearly all of the inspection methods return their results in String form. For example you won't get the type Int32 but instead the string "int". This makes type inspection next to impossible.
I don't believe what you're trying is a supported case. The type system being evaluated doesn't exist in the current process. It exists in the debuggee process and is fairly difficult to get access to.
There's a hack you could do to get more information about the type of a variable you've evaluated using Debugger::GetExpression method.
You could evaluate "AppDomain.CurrentDomain.GetAssemblies()" to get all the assemblies loaded into the debugee, and cache them in your add-in. You may also need to listen for new assemblies being loaded onto the AppDomain.
Then, run the following:
Expression myExpression = Debugger.GetExpression(...);
Expression typeRefExpression = Debugger.GetExpression("typeof(" + myExpression.Type + ").FullName"
once you have the TypeFullName, you can search inside your assemblies cache for a matching System.Type, and once you have that, you can dig into it all you want using the standart Reflection API.
Note that this will only work in C#, because of its "typeof" keyword. You'll have to use a different keyword for VB.Net, for example.