Re: [Mono-list] P/Invoke question
--- Kelly Leahy <[EMAIL PROTECTED]> wrote: > However, I don't think this is right either. I > think > perhaps your C declaration is either wrong, or the > caller has to preallocate the array of CvPoint2D32f > elements before calling this function. Looking at the documentation for this function at: http://www.cs.bham.ac.uk/resources/courses/robotics/doc/opencvdocs/ref/OpenCVRef_3dReconstruction.htm#decl_cvFindChessBoardCornerGuesses I was correct. The caller is responsible for preallocating the array of CvPoint2D32f records. For the purposes of building a nice C# wrapper, you could either take a "length" argument or use the array length to determine how many points to handle. I think taking a length argument is cleaner, (and allows the caller to use a subset of the array), but either solution is possible. For instance, you could declare the P/Invoke function to take an array of CvPoint2D32f elements, then construct this array in the code that calls this function (the wrapper) with the appropriate size. Perhaps, if you know CvPoint2D32f to be of type float, you could even pass this array to the Marshal.Copy function directly. Kelly ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] P/Invoke question
Just looking at your code, I can say this looks a little wierd: << CvPoint2D32f* crs = null; cvFindChessBoardCornerGuesses( image.ImageHandle, thresh.ImageHandle, System.IntPtr.Zero, etalonSize, crs, &cornerCount); >> You are probably more interested in doing something like: CvPoint2D32f crs; cvFindChessBoardCornerGuesses(..., &crs, ...); since unless you pass a reference to crs, it cannot be filled by the code. However, I don't think this is right either. I think perhaps your C declaration is either wrong, or the caller has to preallocate the array of CvPoint2D32f elements before calling this function. The reason I believe this to be true is that in order for the C function to allocate this block of memory and pass back the pointer (of type CvPoint2D32f*) it would have to be passed a value of type CvPoint2D32f** or a reference variable of type CvPoint2D32f*, neither of which is done in the declaration you gave here. << int cvFindChessBoardCornerGuesses( const CvArr* image, CvArr* thresh, CvMemStorage* storage, CvSize board_size, CvPoint2D32f* corners, int* corner_count=NULL ); >> best of luck, Kelly ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Problem with datetime format and oracle...
--- Daniel Morgan <[EMAIL PROTECTED]> wrote: > The Oracle dictionary view NLS_SESSION_PARAMETERS is > helpful too. I > know this available on Oracle 9i, but I don't know > if it's available on > Oracle 8i. Oracle 8i docs are not available on OTN > because its not > supported by Oracle anymore. I believe NLS_SESSION_PARAMETERS is available as far back as 7.3, but I'm sure its at least available in 8i (of course if the permissions are ok for you to view it). Kelly ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Error message
This doesn't look right to me. Shouldn't there be a
current code block here? The code you pasted seems to
have the += statement right in the middle of the class
decl, rather than inside some method or a static class
initializer.
Kelly
--- Julien Sobrier <[EMAIL PROTECTED]> wrote:
> Hello,
> what does this error message means when I compile my
> code:
> syntax error, got token `OP_ADD_ASSIGN', expecting
> ABSTRACT EXTERN
> INTERNAL NEW OPERATOR OVERRIDE PRIVATE PROTECTED
> PUBLIC READONLY SEALED
> STATIC THIS UNSAFE VIRTUAL VOLATILE OPEN_BRACKET
> OPEN_PARENS DOT STAR
> IDENTIFIER
>
> It happens for this line:
> PluginListen += new EventListen(EventListenHandler);
>
>
> The code is :
> class Plugin: PluginInterface
> {
> [...]
> public event EventListen PluginListen;
>
> PluginListen += new
> EventListen(EventListenHandler);
>
> private void EventListenHandler(string
> pluginName, string
> eventName, Session userSession, Hashtable
> parameters)
> {
> //
>
> }
>
> }
>
> Where EventListen is defined in another file:
> public delegate void EventListen(string pluginName,
> string eventName,
> Session userSession, Hashtable parameters);
>
> interface PluginInterface
> {
> [...]
> event EventListen PluginListen;
> }
>
> Thanks
> Julien
> ___
> Mono-list maillist - Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and sqllite on OS X
Niklas, This is done with a .config file in the path to the .dll (the .NET class library assembly). Create a file called xxx.dll.config where xxx is the base name of the .dll file (I think it was SqlLiteClient, I already deleted the other email, so I don't know). This should be an xml file that has a dllmap element under the configuration element with the attributes dll="...old dll name..." and target="...full path to new dll..." see http://developerland.com/CSharpGeneral/COMInterop/198.aspx the section on Library Names refers to this functionality. Kelly --- Niklas Saers <[EMAIL PROTECTED]> wrote: > Hi Thomas, > is there any way I can make it search /sw instead of > /usr/src? Any > environment variables, perhaps? And is there any way > that I can make it > use the dylib version or the aout version of the > file as those are the > only ones made on OS X? > > Cheers > > Nik > > Thomas Zoechling wrote: > > > I suppose the problem here is that libsqlite is > not a native mono > > library. > > Mono.Data.Sqlite... is just a wrapper around > libsqlite.so , which has > > to remain in /usr/lib. > ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
--- Colin JN Breame <[EMAIL PROTECTED]> wrote: > Michal Moskal wrote: > > > > Not that I'm an expert, but the 'common' parts would > probably be > something like: > - a shared symbol table > - shared intermediate representation (does mcs or > the vb compiler use an > intermediate representation? how about ironpython > and nemerle?) > - shared error reporting mechnism > All sounds very good to me. Again, however, my question has to be this: Are we trying to build a better compiler system for .NET compatible languages than the one MS has, or are we trying to build a cross-platform compiler that has similar (hopefully the same) features as the MS compilers? I assert the latter. If we want to build a compiler that has all kinds of neat features that the MS compiler doesn't have, that's fine, but I think it should be separate from mcs proper, as mcs proper should "act like" the MS compiler insofar as that is possible. Kelly ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
--- Colin JN Breame <[EMAIL PROTECTED]> wrote: > Kelly Leahy wrote: > > > (very silly thought indeed for mainstream > langauges > > like C# and VB.NET) we should not expect such > support > > to be useful in "real-world" applications. > > > Not sure which "real-world" you are referring > to...:) > > Some languages are more suited to particular tasks > than others, with > specialised syntax that makes life easy. e.g. I > personally wouldn't use > C for a task where Perl is more suited. > I agree completely. One must use the best tool for the job. I'm referring the the world in which we are trying to match as closely as possible the functionality of a system over which we have no control (MS .NET C# and VB.Net compilers). In this case, it doesn't really make sense to discuss adding features to our compilers that are not going to appear in the MS compilers. If our true goal is to support cross-platform development, then IMHO the only features we should have in our compiler that are not in MS's compiler should be those features that allow access to platform specific items - not new language features that have nothing to do with platform whatsoever. Kelly ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
> The problem is cross references -- that is if part > in language A needs > part in language B and vice versa. Then the > compilers need to agree > much more -- upon some internal APIs, which seems > quite difficult in > general. I understand that in general, it would certainly be possible to build a set of compilers that are aware of each other to the extent that they support nested code. However, this was the problem I was most concerned with when discussing such a design, and again - I don't believe this should or ever could be done with the .NET platform and C#, without a huge effort by MS to make such a thing possible, or a very non-standard implementation of the compilers. In any case, even if we could build such a thing, why would we? Unless MS is going to do the same, or we have plans to eclipse MS in the .NET compiler business (very silly thought indeed for mainstream langauges like C# and VB.NET) we should not expect such support to be useful in "real-world" applications. After all, at the end of the day, our goal is to build a platform that allows for cross-platform compatibility with MS's .NET implementation, right? Perhaps this means they have features we don't (Win-specific features that cannot be implemented on other platforms) and perhaps this means we have features they don't, but I don't think we should make the source files incompatible. Here, I think features == run-time library stuff, not features == language functionality. If we start going a completely different direction with the language altogether, we suddenly become as obscure as MS would probably like to think we are. Kelly ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mixing languages within
Yes, its true that any .NET language should be able to
use any other .NET language (in separate assemblies).
This IS supported by the standard and is one of the
major motivations for the CTS (common type system), a
significant part of the CLI (common language
infrastructure).
However, it should even be possible to support
multiple languages in the same assembly, assuming the
compilers could agree on an intermediate target or
some method for merging the assemblies. I don't
believe this has been done, but I think its certainly
possible (not sure it buys anything though).
That being said, the question was about mixing code in
a single source file. I don't think this should be or
would ever be possible.
Kelly
--- Kirk Marple <[EMAIL PROTECTED]>
wrote:
> It makes sense if both languages (C# and HSPL)
> compiled to IL, and were both
> processed by the CLR.
>
> You'd have to make separate assemblies which
> referenced each other, you
> couldn't do it inline in the same class.
>
> Look at how IronPython compiles to IL, but it usable
> from any other .NET
> assembly.
>
> http://ironpython.com/
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Colin JN Breame
> Sent: Thursday, December 09, 2004 3:19 PM
> To: [EMAIL PROTECTED]
> Subject: [Mono-list] Mixing languages within
>
> I don't know what the .Net standard would have to
> say about this
>
> I would like to mix C# and (say) Hypothetical String
> Processing Language
> (HSPL) and (say) Hypothetical Data Processing
> Language (HDPL) within the
> same source code file. e.g.
>
> class mixed {
> string normal_c_sharp_method() {
>string ret = null;
>
>
> some HSPL...modifying ret
>
>
>
> some HDPL...modifying ret
>
>
>return ret
> }
> }
>
> Is this a crazy idea?
>
>
> ___
> Mono-list maillist - [EMAIL PROTECTED]
> http://lists.ximian.com/mailman/listinfo/mono-list
>
> ___
> Mono-list maillist - [EMAIL PROTECTED]
> http://lists.ximian.com/mailman/listinfo/mono-list
>
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
> I don't know what the .Net standard would have to > say about this > > I would like to mix C# and (say) Hypothetical String > Processing Language > (HSPL) and (say) Hypothetical Data Processing > Language (HDPL) within the > same source code file. e.g. > > Is this a crazy idea? > I think so. I'm not sure what someone else might say, but my problem with this is that every compiler would have to know about every other compiler and there would have to be some standard for how to shift around from one compiler to the next and pass type / symbol information and IL code around as well. I don't think it's feasible, and I'm pretty sure it's not even close to being supported by the standard. I doubt it's prohibited directly by the standard (because, after all, you could argue that this wouldn't be C#, but some variant of C# and so wouldn't be bound by the standard at all), but I surely wouldn't want to try to build the compiler for it. Kelly ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
