[Mono-dev] gtk# drag and drop
hello, I wanted to drag from treeview to another control. How can i control from which treeitems of tree i can start drag ? Should i invoke EnableModelDragSource every time i change selected tree item ? Any good tutorials/examples (github urls) where i can see drag and drop in action ? regards, Tomasz Kubacki ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gtk# drag and drop
On 13/10/2010 10:00, Tomasz Kubacki wrote: I wanted to drag from treeview to another control. How can i control from which treeitems of tree i can start drag ? Should i invoke EnableModelDragSource every time i change selected tree item ? Any good tutorials/examples (github urls) where i can see drag and drop in action ? I don't know if it is a GOOD example but I implemented treeview dragdrop in my MagicWand project (a Magic: The Gathering deck organizer). Code is GPL so feel free to cut and paste if you like: git clone git://luna.dndg.it/public/magicwand Have fun, federico -- Federico Di Gregorio f...@initd.org Beh un bacio, se ben dato, non si rifiuta. -- laura ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] UnixUserInfo issues in OpenBSD
Hi all,
The following simple program fails on OpenBSD:
using System;
using Mono.Unix;
public class Info
{
public static void Main()
{
Console.WriteLine(Environment.UserName);
Console.WriteLine(new
UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
}
}
Environment.UserName retrieves the right user.
The two next calls fail saying invalid param:
Console.WriteLine(new UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
It seems the problem is the return of the native method getpwuid_r, that
returns 1 instead of 0.
I tried running as root to (suspected it could be a permissions issue)
but I get the same result.
I thought it could be related to an old issue with UnixGroupInfo which
fails if the groups are incorrectly defined (have unexisting users) but
I think this time my config files are correctly set... :O
Thanks,
pablo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono and WCF support
Hello, On 2010/10/10 18:33, Chakotey STME wrote: Hello, thanks for your answer. But I don't know in which version wcf is implemented in mono. Is it for example implemented in mono 2.4 or only in 2.6 and 2.8? You cannot identify which version of mono implements WCF as it is too huge to have implemented within a single version. and I am looking for an overview in which mono version which wcf functionality is. is there such an overview? There isn't. thanks 2010/10/8 Atsushi Enoatsushi...@veritas-vos-liberabit.com: As the immediately next sentense to Nowadays WCF is part of the core Mono. mentions, historically it used to be in different module (olive). Atsushi Eno On 2010/10/09 3:27, Chakotey STME wrote: Hi mailing list, I have a question about the wcf support in mono. at http://www.mono-project.com/Roadmap I get the information that in mono 2.6 there is wcf support. and here (http://www.mono-project.com/WCF) I get the information that Nowadays WCF is part of the core Mono. And I have to know what nowadays means. Is there wcf support in mono 2.4 for example? And is there an overview which parts of the wcf is supported by mono in which version? I hope you can answer my questions. thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Though, I can describe a rough history: - At mono 2.4, we had very primitive HTTP client and service working. And there was a lot of fragment of code such as TCP binding that partially worked. - At mono 2.6, it had polished code that served moonlight's HTTP client usage scenarios, as well as improved HTTP service and several non-WS-* stack such as NetTcp and NetPeer. Though they needed significant amount of bugfixes. WebHttpBinding was also there. - At mono 2.8, stability on lots of non-WS-* stack are in, as well as some new stuff such as WCF Routing. Actually WS-Security has been improved too, though I was stuck at .NET's hidden WS-Trust implementation (sslnego/spnego). Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] serialization not implemented
Hi My program needs to serialize a bunch of user-defined instances time to time. It runs correctly with .NET framework on Windows but throws exception with latest mono-2.8 on Linux. The exception is thrown when the program tries to write (serialize) an instance to disk, and says The requested feature is not implemented. Detailed error info is at last of the mail. I've checked the program with the latest Mono Migration Analyzer and it reports all feature in my program are supported in mono. I guess the problem is in the way I work with mono rather than mono itself. Does anyone knows how to fix the problem? Thanks very much. Exception thrown: System.NotImplementedException: The requested feature is not implemented. at System.Collections.Generic.HashSet`1[System.Int64].GetObjectData (System.Runtime.Serialization.SerializationInfo info, StreamingContext context) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.GetObjectData (System.Object obj, System.Runtime.Serialization.Formatters.Binary.TypeMetadata metadata, System.Object data) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject (System.IO.BinaryWriter writer, Int64 id, System.Object obj) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectInstance (System.IO.BinaryWriter writer, System.Object obj, Boolean isValueObject) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQueuedObjects (System.IO.BinaryWriter writer) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectGraph (System.IO.BinaryWriter writer, System.Object obj, System.Runtime.Remoting.Messaging.Header[] headers) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize (System.IO.Stream serializationStream, System.Object graph, System.Runtime.Remoting.Messaging.Header[] headers) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize (System.IO.Stream serializationStream, System.Object graph) [0x0] in filename unknown:0 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] serialization not implemented
No, it's not specific problem with your usage. It's just not implemented in Mono. http://github.com/mono/mono/blob/master/mcs/class/System.Core/System.Collect ions.Generic/HashSet.cs#L545 BTW: I don't know if the Mono Migration Analyzer is able to detect Serialization problems, but it seems it doesn't. Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] Im Auftrag von SillySnail Gesendet: Mittwoch, 13. Oktober 2010 11:52 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] serialization not implemented Hi My program needs to serialize a bunch of user-defined instances time to time. It runs correctly with .NET framework on Windows but throws exception with latest mono-2.8 on Linux. The exception is thrown when the program tries to write (serialize) an instance to disk, and says The requested feature is not implemented. Detailed error info is at last of the mail. I've checked the program with the latest Mono Migration Analyzer and it reports all feature in my program are supported in mono. I guess the problem is in the way I work with mono rather than mono itself. Does anyone knows how to fix the problem? Thanks very much. Exception thrown: System.NotImplementedException: The requested feature is not implemented. at System.Collections.Generic.HashSet`1[System.Int64].GetObjectData (System.Runtime.Serialization.SerializationInfo info, StreamingContext context) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.GetObjectDa ta (System.Object obj, System.Runtime.Serialization.Formatters.Binary.TypeMetadata metadata, System.Object data) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject (System.IO.BinaryWriter writer, Int64 id, System.Object obj) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject Instance (System.IO.BinaryWriter writer, System.Object obj, Boolean isValueObject) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQueued Objects (System.IO.BinaryWriter writer) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject Graph (System.IO.BinaryWriter writer, System.Object obj, System.Runtime.Remoting.Messaging.Header[] headers) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serializ e (System.IO.Stream serializationStream, System.Object graph, System.Runtime.Remoting.Messaging.Header[] headers) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serializ e (System.IO.Stream serializationStream, System.Object graph) [0x0] in filename unknown:0 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] F# Interactive on Mono 2.8 (DefineDynamicAssembly troubles)
Hi, thanks for the explanation! I must have missed the bugzilla entry because the original bug report was on a diffierent issue. The F# team confirmed to me that this is an issue that they are aware of (and have a fix for it already), so hopefully, it will be fixed in the new release of F#. Thanks, Tomas On Mon, Oct 11, 2010 at 2:22 PM, Rodrigo Kumpera kump...@gmail.com wrote: Hi Tomas, On Mon, Oct 11, 2010 at 9:58 AM, Tomas Petricek tomas.petri...@gmail.com wrote: Hi, Is this some kind of special flag that the F# compiler should pass to the DefineDynamicAssembly or is there another way to fix the issue (without passing magical constants as arguments)? Should I send this information to the F# team, so that they can make the next release of F# working on Mono 2.8, or is this something that can be changed in the next Mono release? CompilerContext is a special SRE mode that enables some extra features that mcs used to require. Since the 2.8 release mcs no longer requires it and this is going away for the 3.0 release. Else so, this is an internal flag that it's not meant for general use. The Operation is not supported problem is caused by F# using an instance of a TypeBuilder instead of a runtime type. Somewhere in the guts of mono' s SR(E) where doing something different from what F# expect and everything breaks. There is a bugzilla entry tracking this problem: https://bugzilla.novell.com/show_bug.cgi?id=419828 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UnixUserInfo issues in OpenBSD
I have no idea why it's failing. Sorry.
What I can do is send you a C program which closely mirrors what
Mono.Unix is doing. Could you compile and run it, and see if it fails
in the same ways? The program source is attached.
- Jon
On Wed, 2010-10-13 at 10:43 +0200, pablosantosl...@terra.es wrote:
Hi all,
The following simple program fails on OpenBSD:
using System;
using Mono.Unix;
public class Info
{
public static void Main()
{
Console.WriteLine(Environment.UserName);
Console.WriteLine(new
UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
}
}
Environment.UserName retrieves the right user.
The two next calls fail saying invalid param:
Console.WriteLine(new UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
It seems the problem is the return of the native method getpwuid_r, that
returns 1 instead of 0.
I tried running as root to (suspected it could be a permissions issue)
but I get the same result.
I thought it could be related to an old issue with UnixGroupInfo which
fails if the groups are incorrectly defined (have unexisting users) but
I think this time my config files are correctly set... :O
Thanks,
pablo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
#include stdio.h
#include stdlib.h
#include sys/types.h
#include pwd.h
#include errno.h
static inline int
recheck_range (int ret)
{
printf (# checking return value %i; errno=%i\n, ret, errno);
if (ret == ERANGE)
return 1;
if (ret == -1)
return errno == ERANGE;
return 0;
}
static void
dump_user (const char *user)
{
int r;
struct passwd p, *prev;
char *buf, *buf2;
size_t buflen;
buf = buf2 = NULL;
buflen = 2;
do {
buf2 = realloc (buf, buflen *= 2);
if (buf2 == NULL) {
printf (error: unable to allocate enough memory\n);
free (buf);
return;
}
buf = buf2;
errno = 0;
} while ((r = getpwnam_r (user, p, buf, buflen, prev)) recheck_range (r));
if (r == 0 !prev) {
printf (User '%s' was not found.\n, user);
free (buf);
return;
}
printf (User %s:\n, user);
printf (\t pw_name=%s\n, p.pw_name);
printf (\t pw_uid=%i\n, p.pw_uid);
printf (\t pw_gid=%i\n, p.pw_gid);
printf (\tpw_gecos=%s\n, p.pw_gecos);
printf (\t pw_dir=%s\n, p.pw_dir);
printf (\tpw_shell=%s\n, p.pw_shell);
free (buf);
}
int main (int argc, char **argv)
{
int i;
for (i = 1; i argc; ++i) {
dump_user (argv [i]);
}
return 0;
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problems with System.ServiceModel.Web
Hello,
thank you for your review. I tried to use the style of the existing code
but I guess I missed some spaces.
The problem with your modifications is that it defeats the purpose of my
patch. In .NET I can host a method with a definition like:
[OperationContract]
[WebInvoke(UriTemplate=set?name={name}value={value})]
void Set(string name, string value);
In Mono I couldn't. This is why I created the patch. With your
modifications the problem still exists, but now in a different place.
ValidateStyleForMessageFormatter shouldn't reject a method like the one
above. Like the modified Validate method it should consider the
UriTemplate. In the method above there is no need to wrap because
everything is passed in the URI. That works for .NET and also works for
Mono if the validation is less restrictive. I think the major problem
with my patch is that it doesn't work if the UriTemplate is null. With
only that fixed the test RejectTwoParametersWhenNotWrapped will not
break and it also works for my purpose.
I also checked the .NET behavior for WrappedRequest and WrappedResponse.
In .NET the BodyStyle WrappedRequest resolves problems with multiple
inputs and WrappedResponse with multiple outputs. That is what I
expected and it is the opposite to what is done in
ValidateStyleForMessageFormatter.
So I created a new version that hopefully resolves all issues.
On 12.10.2010 13:30, Atsushi Eno wrote:
Hello,
Thanks for the patch, I very much appreciate it. Though there were
some problems in your patch.
- your implementation had an assumptiopn that WebGetAttribute and
WebInvokeAttribute has non-null UriTemplate. They can indeed be
null.
- Your change broke RejectTwoParametersWhenNotWrapped() in
WebInvokeAttributeTest. It is because, in your
WebHttpBehavior.Validate()
change you just removed existing code that checked what this
test exactly
verifies i.e. invalid multiple arguments. You might think it is
very strange
and wrong but that's what .NET indeed does (looks like it is
done in
GetClientMessageFormatter() in current version of .NET though).
- There was a couple of coding style fixage needed. You had right
and wrong
style, so I assume you might have already known the style, but
in case you
haven't, have a look at http://mono-project.com/Coding_Guidelines
(I found this page was not linked from our Contributing page,
which was
our bad, just fixed it.)
I'm attaching the modified fix here. It includes some additional
tests. I'll commit the changes unless you have further comments.
(As a cosmetic excuse, WebMessageBodyStyle.Bare was new in 3.5 SP1
AFAIR, so it was left ignorant in our implementation from 3.5 era.)
Atsushi Eno
On 2010/10/09 18:27, Frank Wilhelm wrote:
Hello Mono devs,
I tried running my web service on Mono and ran into several issues. I
use the WebHttpBinding to create REST web services by hosting that
with the ServiceHost class. This works fine on .NET but the Mono
implementation of System.ServiceModel.Web shows very different, and
very limiting, behavior. So I decided instead of waiting for a fix I
try to track down the issues. Here is the first I discovered.
The Validation of WebHttpBehavior is very limiting. If a POST
operation has several parameters it will only host them if you define
'wrapped' body format. But this isn't required if the parameters are
passed in the UriTemplate. Also the requirements for WrappedRequest
and WrappedResponse look very strange. I have to wrap my response if
I have multiple input parameters? That looks wrong.
I looked up in the MSDN what the Validate method does for .NET, and
then I tried to make the .NET implementation fail. It just doesn't
behave like specified in the documentation, it never fails no matter
what.
I attach a patch that will make the Validate method less picky. It
will look for placeholders in the URI template and only after that
decides whether wrapping is needed or not. That is still more
restrictive than the .NET implementation but for me it looks like the
right thing to do. I also added a test that reproduces the problem.
Please accept the patch and give me some feedback on what I can
improve for further contributions.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
diff --git
a/mcs/class/System.ServiceModel.Web/System.ServiceModel.Description/WebHttpBehavior.cs
b/mcs/class/System.ServiceModel.Web/System.ServiceModel.Description/WebHttpBehavior.cs
index 38b804f..32554b9 100644
---
a/mcs/class/System.ServiceModel.Web/System.ServiceModel.Description/WebHttpBehavior.cs
+++
b/mcs/class/System.ServiceModel.Web/System.ServiceModel.Description/WebHttpBehavior.cs
@@ -222,6 +222,61 @@ namespace System.ServiceModel.Description
}
#endif
+
Re: [Mono-dev] UnixUserInfo issues in OpenBSD
Reading your C code I see once more how powerful C# is... :P
This is what I get:
$ ./a.out tester
# checking return value 1; errno=13
User tester:
pw_name=ÇEðÄ
À
¢
pw_uid=752427404
pw_gid=-809631572
pw_gecos=(null)
pw_dir=(null)
pw_shell=UåSj
$ ./a.out pablo
# checking return value 1; errno=13
User pablo:
pw_name=ÇEðÄ
À
¢
pw_uid=656871820
pw_gid=-809738964
pw_gecos=(null)
pw_dir=(null)
pw_shell=UåSj
We're getting an errno in both cases...
OpenBSD is a cool beast! :P
On 13/10/2010 15:29, Jonathan Pryor wrote:
I have no idea why it's failing. Sorry.
What I can do is send you a C program which closely mirrors what
Mono.Unix is doing. Could you compile and run it, and see if it fails
in the same ways? The program source is attached.
- Jon
On Wed, 2010-10-13 at 10:43 +0200, pablosantosl...@terra.es wrote:
Hi all,
The following simple program fails on OpenBSD:
using System;
using Mono.Unix;
public class Info
{
public static void Main()
{
Console.WriteLine(Environment.UserName);
Console.WriteLine(new
UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
}
}
Environment.UserName retrieves the right user.
The two next calls fail saying invalid param:
Console.WriteLine(new UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
It seems the problem is the return of the native method getpwuid_r, that
returns 1 instead of 0.
I tried running as root to (suspected it could be a permissions issue)
but I get the same result.
I thought it could be related to an old issue with UnixGroupInfo which
fails if the groups are incorrectly defined (have unexisting users) but
I think this time my config files are correctly set... :O
Thanks,
pablo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UnixUserInfo issues in OpenBSD
On Wed, 2010-10-13 at 16:38 +0200, pablosantosl...@terra.es wrote: This is what I get: $ ./a.out tester # checking return value 1; errno=13 That's...horribly wrong. First, what's errno=13? (i.e. what EVALUE is 13? I'm sure OpenBSD has different values than Linux does.) Regardless, OpenBSD doesn't appear to be conforming to the standard here: http://www.opengroup.org/onlinepubs/009695399/functions/getpwnam_r.html If successful, the getpwnam_r() function shall return zero; otherwise, an error number shall be returned to indicate the error. The value '1' is likely not the correct errno for ERANGE (Under Linux, EPERM has the value 1), and since the return value isn't -1 recheck_range() won't check errno against ERANGE either. However, this does point out a bug in MonoPosixHelper: if getpwnam_r() returns non-zero it should treat it as an error, which is clearly not happening here (and is why we're printing garbage data to the screen). This would only marginally help you, though, as it would result in no users being found, ever. The fundamental problem is that Mono_Posix_Syscall_getpwnam_r()'s logic for checking for ERANGE (so it'll resize the buffer and try the call again) is failing under OpenBSD, and from what I can see here the problem is within OpenBSD, not MonoPosixHelper. Patches welcome to properly support OpenBSD. :-) - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Building mono-2.8 on 64 bit systems
Hi,
I've submitted mono-2.8 to the fedora buildsys so it can go into
rawhide. However, the buildsys is coming back with the following error
sgen-cardtable.c:229:1: warning: 'collect_faulted_cards' defined but not
used
{standard input}: Assembler messages:
{standard input}:24487: Error: @TLSLDM reloc is not supported with
64-bit output format
{standard input}:24487: Error: junk `...@tlsld' after expression
make[3]: *** [libmonoruntimesgen_la-sgen-gc.lo] Error 1
Is this a problem with mono or part of our buildsys?
Paul
--
Vertraue mir, ich weiss, was ich mache...
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-list] Mono.Data.SybaseClient - Language error
Hello I am connecting to a ASE Sybase 15.5 server thru Mono.Data.SybaseClient but when I read any varchar fields with greek chars I get '???'. I have try to set the connection language in the connection string, like 'Server=xx,5000;Database=db1;User ID=sa;Password=;language=greek;', but I get the same character conversion error. In any case, the ((Mono.Data.SybaseClient.SybaseConnection)(dbcon)).Tds.Charset is always 'iso_1'. Is there any way to set the connection language in SybaseConnection(connString) or elsewhere. Thanks ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] http://go-mono.com/md/ - monodevelop repository site dead
after visiting: http://go-mono.com/md/ i get: Access forbidden! You don't have permission to access the requested directory. There is either no index document or the directory is read-protected. If you think this is a server error, please contact the webmaster. Error 403 go-mono.com Wed Oct 13 08:09:15 2010 Apache ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Passing UTF-8 to a method that takes a .Net string - not possible right?
On Tue, 2010-10-12 at 22:33 -0700, nev wrote:
So I've been using Mono.Cairo.Context.ShowText() which takes a string. On
Linux everything is good, never had a problem.
But running my assemblies on Windows with the Mono assemblies from the
Windows Mono installer everything works - except that ShowText() has issues
with accents and guillemets (and maybe other things).
...
Is this possible? It takes a .Net string
This is a bug in the binding, and appears to be present for all string
methods. For example, cairo_show_text() is declared as:
[DllImport(cairo)]
internal static extern void cairo_show_text(IntPtr cr, string
utf8);
As you note, this fails under .NET because .NET will marshal the string
as an ANSI string, and ANSI is *never* UTF-8 on Windows.
A possible fix would be to instead do:
[DllImport(cairo)]
static extern void cairo_show_text(IntPtr cr, byte[] utf8);
internal static void cairo_show_text(IntPtr cr, string utf8)
{
var e = Encoding.UTF8;
byte[] data = new byte[e.GetByteCount(utf8) + 1];
e.GetBytes (utf8, 0, utf8.Length, data, 0);
cairo_show_text (cr, data);
}
..and repeat for all other methods which require UTF-8 strings.
(The above could doubtlessly be improved some, but it demonstrates the
basics of what needs to be done.)
You should probably file a bug for this so that it can be tracked, etc.
- Jon
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Works Great
I'll admit it, this is thinly veiled self-promotion. I want to express my gratitude to the Mono team. Also, I know I always appreciate hearing about a Mono success story. So here's mine. Although the service won't be public until probably sometime next year it is almost fully functional. We hope to start beta testing in November. The service is http://tendr.me and allows a very simple and efficient way to transfer funds from one party to the next. It's sort of a prepaid debit card where the transferring of funds occurs via phones, Google Talk, and / or Twitter. AND, all transfers are free when they occur within the Tendr.me network. So you can pay someone $.10 for a candy and not have to pay a transaction fee. The candy is $.10, you pay $.10. Almost the entire suite was developed with Mono and MonoDevelop. Prior to 2.8 I had to compile Mono-specific versions of TweetSharp, jabber-net, and some other dependencies the service has. Now with 2.8 there's no conditional compilation whatsoever. I literally copy the binaries to my CentOS server and run. Tendr.me consists of a Windows service that runs via mono-service2 and an ASP.Net MVC 2 website. There's a teaser at http://tendr.me If you mash the start button you'll be invited to sign up for the announcement list. Please do. We're eager, of course, to get a feel for the interest. And although the mono-list has a large international following the service won't immediately be international. But we do have international aspirations and hope to bring that functionality as soon as we can. Thank you Mono hackers! -Abe ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Commercial redistribution/license question
Hi, We've got a product that we're experimenting with Mono for in order to share critical code between our Windows and Mac versions. The actual Mono use is quite straightforward: we're simply compiling command line executables that use regular-expression portions of the .NET 2.0 framework. We've been able to use the OS X installation binary package directly, with no need to recompile or modify any Mono source. The primary application does not use Mono at all, it simply invokes these cmd-line executables to perform certain processing. Our problem is that our product exceeds the terms of the commercial license available through purchase of the Mono Tools Ultimate package. 100K volume would be okay, but we have revenues in excess of $2M annually. And my reading of LGPLv2 makes it a non-starter: the C# code in question is extremely valuable patent-protected intellectual property. We've sent mail (multiple times) via the web form on the FAQ for licensing questions, but have received no reply. Is there anyone on the list that can put us in contact with the right people to negotiate a license? Or can clarify any way we can use/redistribute Mono runtimes legally without revealing our source? --Mark A. Gollin *VP Development* *The Neat Company* *www.neatco.com* ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Commercial redistribution/license question
On Oct 13, 2010, at 1:39 PM, Mark Gollin wrote: Hi, We've got a product that we're experimenting with Mono for in order to share critical code between our Windows and Mac versions. The actual Mono use is quite straightforward: we're simply compiling command line executables that use regular-expression portions of the .NET 2.0 framework. We've been able to use the OS X installation binary package directly, with no need to recompile or modify any Mono source. The primary application does not use Mono at all, it simply invokes these cmd-line executables to perform certain processing. Our problem is that our product exceeds the terms of the commercial license available through purchase of the Mono Tools Ultimate package. 100K volume would be okay, but we have revenues in excess of $2M annually. And my reading of LGPLv2 makes it a non-starter: the C# code in question is extremely valuable patent-protected intellectual property. We've sent mail (multiple times) via the web form on the FAQ for licensing questions, but have received no reply. Is there anyone on the list that can put us in contact with the right people to negotiate a license? Or can clarify any way we can use/redistribute Mono runtimes legally without revealing our source? --Mark A. Gollin VP Development The Neat Company www.neatco.com Hi Mark, Mono is LGPLv2 licensed, but you don't have to license your code LGPLv2 if you're just using Mono to run the executables via the standard installed framework and not recompiling or modifying Mono source. As long as users can install an updated Mono (ie. you're not locking them down to a certain Mono and not providing the necessary object code to use a newer Mono), you're not violating the LGPL license terms. Best, Bojan ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
