RE: [Mono-dev] COM Interop, or something like it

[Ring, Kevin]

Thank you to everyone who responded!

I hadn't found cilc in my searching before - it certainly makes the
Embedded Mono approach seem less intimidating.

In playing with it some today, I was able to get some simple unmanaged
-> managed calls working on my Linux machine.  I haven't had much luck
on Windows, though, because of the dependency on glib.  I know I can set
up a whole Cygwin environment complete with glib and build my
application there... but is there a way to embed Mono in an application
built with Visual C++?  I apologize if this is a stupid question.

The purpose of all of this is to enable a large C++ application, which
has been ported to Linux and other Unix platforms with the aid of
MainWin, to continue to be portable as some of its components begin to
be implemented in C#.  So eventually, I'd like to have something that
can generate real C++ interfaces in order to better approximate COM
interop, which I suspect is what we'll be using on the Windows side.  It
sounds like it might not be terribly difficult to do this using an
approach similar to the one used by cilc.  I may be able to convince my
company to sponsor a developer closer to the Mono project to develop
such a thing, if that sounds at all interesting to anyone...just a
thought.

Thanks,
Kevin Ring


> -Original Message-
> From: Jonathan Pryor [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 25, 2005 9:21 PM
> To: Ring, Kevin
> Cc: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] COM Interop, or something like it
> 
> On Thu, 2005-08-25 at 16:27 -0400, Ring, Kevin wrote:
> > In Microsoft's implementation of .NET, it is possible to expose a
> > class written in C# via a COM interface.  This makes it possible
> > (perhaps even easy!) to instantiate C# objects and call methods on
> > them from, say, a native C++ application.
> >
> > Does Mono have a capability like this?
> 
> Yes.  Mono provides an embedding API which allows an unmanaged
> application to create and use managed objects:
> 
>   http://www.mono-project.com/Embedding_Mono
> 
> This isn't terribly ideal, as it's a string-based API.  There is a
> program called cilc which will take a managed class and generate a
bunch
> of C wrappers for each method exposed by the class.  This makes it
easy
> to use a managed class from C (and thus C++, if not perfectly from
C++).
> 
>
http://lists.ximian.com/pipermail/mono-list/2003-April/013529.html
> 
> > I'd just like an easy way to instantiate managed objects and
interact
> > with them from a native C++ application.  I know I can embed Mono,
and
> > call methods that way, but it seems very cumbersome compared to COM
> > interop.  Is there a better way?
> 
> Let cilc handle the cumbersome unmanaged->managed invocation layer.
> 
>  - Jon
> 

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] COM Interop, or something like it

[Kornél Pál]

Remoting itself is compatible but the internal structure of classes has to
be the same on both runtimes to allow object remoting. This means that you
may want use classes that are not compatible with .NET. (It's easy to notice
as you will get exceptions when receiving the object.) Then you can file a
bug report or you may want to fix it and contribute it to Mono.

But I (and others on the list) suggest to use web services instead as it is
a much more standardized interop (and remoting) layer as remoting may change
version to version but web services are guaranteed to work.

Kornél

- Original Message -
From: "Agustin.PHP Casiva" <[EMAIL PROTECTED]>
To: 
Sent: Friday, August 26, 2005 10:30 PM
Subject: Re: [Mono-dev] COM Interop, or something like it


Its compatible the Microsoft implementation of Remoting with the Mono
implementation???.

--
Casiva Agustin, Desarrollador de Sistemas
Cel: 03722-15554267
WebPage: www.casivaagustin.com.ar 
MSN: [EMAIL PROTECTED]







___
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

[Mono-dev] Authentication with WebRequest?

[knocte]

Does anybody know if I can use WebRequest or other class to generate 
this RAW tcp socket headers when making a request to a HTTP server?:


GET /resource.xxx HTTP/1.0\r\n
User-Agent: MyUAstring\r\n
Host: example.com\r\n
Authorization: Basic example-password\r\n\r\n

Thanks in advance,

Andrew  [ knocte ]

--



___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Authentication with WebRequest?

[Kornél Pál]

If you don't want to do any special then you can simply use
HttpWebRequest.Credentials to sepcify user name and password.

Kornél

- Original Message -
From: "Kornél Pál" <[EMAIL PROTECTED]>
To: "knocte" <[EMAIL PROTECTED]>; 
Sent: Friday, August 26, 2005 11:11 PM
Subject: Re: [Mono-dev] Authentication with WebRequest?



You can use HttpWebRequest.Headers to specify HTTP headers.

Note that you are actually talking about HTTP headers not TCP headers. TCP
is a lower level layer than HTTP that you cannot manipulate using sockets.

If you want to send the whole request as raw data you have to use sockets
but you will have to process the response as well because you will get it
as
raw data. If you need the functionality of HTTP you can use HttpWebRequest
as it exposes a lot of options through properties.

Kornél

- Original Message -
From: "knocte" <[EMAIL PROTECTED]>
To: 
Sent: Friday, August 26, 2005 11:01 PM
Subject: [Mono-dev] Authentication with WebRequest?



Does anybody know if I can use WebRequest or other class to generate
this RAW tcp socket headers when making a request to a HTTP server?:

GET /resource.xxx HTTP/1.0\r\n
User-Agent: MyUAstring\r\n
Host: example.com\r\n
Authorization: Basic example-password\r\n\r\n

Thanks in advance,

Andrew [ knocte ]

--



___
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



___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Authentication with WebRequest?

[Kornél Pál]

You can use HttpWebRequest.Headers to specify HTTP headers.

Note that you are actually talking about HTTP headers not TCP headers. TCP
is a lower level layer than HTTP that you cannot manipulate using sockets.

If you want to send the whole request as raw data you have to use sockets
but you will have to process the response as well because you will get it as
raw data. If you need the functionality of HTTP you can use HttpWebRequest
as it exposes a lot of options through properties.

Kornél

- Original Message -
From: "knocte" <[EMAIL PROTECTED]>
To: 
Sent: Friday, August 26, 2005 11:01 PM
Subject: [Mono-dev] Authentication with WebRequest?



Does anybody know if I can use WebRequest or other class to generate
this RAW tcp socket headers when making a request to a HTTP server?:

GET /resource.xxx HTTP/1.0\r\n
User-Agent: MyUAstring\r\n
Host: example.com\r\n
Authorization: Basic example-password\r\n\r\n

Thanks in advance,

Andrew [ knocte ]

--



___
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

AW: [Mono-dev] the c# compiler code

[Eduard Ralph]

Hi,

Let me point out, that moving the class per file thing was only one ever
several things that I suggested. As I mostly use VS I don't mind the issue
that much anyway. My suggestion was more along the lines of cleaning up the
code in general. The first step could be cleaning up the names of Variables
and maybe restructuring of some classes without adding files, etc. 
I can understand Miguels desire not to fool around on the base of the system
now that it is working and something like that should be done slowly and
carefully. My question was more basic in nature. I wanted to know if there
was any point in going through the motions and if there was any desire for
something like that because I'm working on the compiler from something else.
>From the short and direct answer I received I take that is not wished and I
think we should just leave it at that. Obviously the feeling is that other
things are more important right now which is fine with me just as well.

Greets,
Eduard Ralph 


Eduard Ralph  
www.eduard-ralph.de

 All programmers are optimists -- Frederick P. Brooks, Jr. 

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Miguel de
Icaza
Gesendet: Freitag, 26. August 2005 22:13
An: Kornél P?l
Cc: Eduard Ralph; mono-devel-list@lists.ximian.com
Betreff: Re: [Mono-dev] the c# compiler code

Hello,

> The following does not specific to mcs code it's my opinion about
splitting
> files:
> 
> I think having a clean and well organized source code is required for
> efficient development.
> 
> When splitting is done by copying files using SVN then removing
unnecessary
> parts from each file SVN history will remain. Then as a different revision
> modifications can be made to the files. This way modifications can be
> tracked.
> 
> Don't you think this solution is acceptable?

No, it is not acceptable.

History is more valuable to those hacking on the compiler than having a
source code that does not have a file-per-class.

An acceptable hack is: modify MonoDevelop to support class-based
browsing of your source code.

Miguel
___
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] the c# compiler code

[John Luke]

Hello,
On Fri, 2005-08-26 at 16:12 -0400, Miguel de Icaza wrote:

> History is more valuable to those hacking on the compiler than having a
> source code that does not have a file-per-class.
> 
> An acceptable hack is: modify MonoDevelop to support class-based
> browsing of your source code.
> 
Just so people know, MonoDevelop has this already so no need to modify
it.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] COM Interop, or something like it

[Agustin.PHP Casiva]

Its compatible the Microsoft implementation of Remoting with the Mono implementation???.
-- Casiva Agustin, Desarrollador de Sistemas Cel: 03722-15554267   WebPage: www.casivaagustin.com.arMSN: 
[EMAIL PROTECTED]
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] the c# compiler code

[Miguel de Icaza]

Hello,

> The following does not specific to mcs code it's my opinion about splitting
> files:
> 
> I think having a clean and well organized source code is required for
> efficient development.
> 
> When splitting is done by copying files using SVN then removing unnecessary
> parts from each file SVN history will remain. Then as a different revision
> modifications can be made to the files. This way modifications can be
> tracked.
> 
> Don't you think this solution is acceptable?

No, it is not acceptable.

History is more valuable to those hacking on the compiler than having a
source code that does not have a file-per-class.

An acceptable hack is: modify MonoDevelop to support class-based
browsing of your source code.

Miguel
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] the c# compiler code

[Kornél P?l]

The following does not specific to mcs code it's my opinion about splitting
files:

I think having a clean and well organized source code is required for
efficient development.

When splitting is done by copying files using SVN then removing unnecessary
parts from each file SVN history will remain. Then as a different revision
modifications can be made to the files. This way modifications can be
tracked.

Don't you think this solution is acceptable?

Kornél

- Original Message -
From: "Miguel de Icaza" <[EMAIL PROTECTED]>
To: "Eduard Ralph" <[EMAIL PROTECTED]>
Cc: 
Sent: Sunday, August 21, 2005 7:33 PM
Subject: Re: [Mono-dev] the c# compiler code


Hello,


I’m currently working on expanding the c# compiler for my personal
syntax. (the /mcs code, not gmcs). As part of that I noticed that the
compiler code is a bit messy and not well documented. I would touch up
the code I run into while working on my own expansion. That would
require creating new files to split some of the classes out of the C#
files and renaming a few of them aside from restructuring the Methods
and renaming some of them.

Is there any point in spending time on that and is there interest in
that?


We have no interest in integrating such changes into mcs.

The reason is not that I dislike the idea of splitting it up, but the
fact than the repository "history" would be rendered useless.

The history is a very important tool that we use to keep track of
changes, rationale, groupped commits and so on and it matters more to us
than the actual physical organization.

Miguel
___
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] mcs default encoding: Latin1 or not

[Miguel de Icaza]

Hello,

> Thus I think the decision is, whether we are for culture
> neutralism, or for convenience of Latin1 people. There is no
> reason I stand for the latter, at least based on the factors
> I listed above.

I would like to move to utf-8 myself, but we do need a plan to deploy
this, and with all the other changes, my personal preference is to way
after 1.1.9 is released to make the change.

This change is a change that will affect a lot of our contributors, so
we must understand if their tools will properly support utf-8.

I envision a set of stages:

* Reviewing the tools: do Emacs, vi and MonoDevelop cope with
  utf-8 files that have a 3-byte marker at the beginning and
  do they save them back?

  I do not want to end up in a situation where we get a mix of
  Latin1 + utf-8 files.

* Translating latin1 to utf-8 all the .cs source files on the
  mcs directory.  Set -codepage:utf-8 on the command line.

* Actually making the mcs default change.

Another possibility is not changing the mcs source files, and instead
force mcs to use the latin-1 code page while building the class
libraries and changing mcs to use Encoding.Default.

Miguel.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

RE: [Mono-dev] Re: [PATCH] Fully Asynchronous and Re-Factored SslStreams in Mono.Security

[JD Conley]

> I am unable to compile this, though, as I am getting CLS-compliance
> errors.  The Assembly is marked as compliant but the SslStreamBase
> class includes a "read" object and a "Read" method (differing only in
> case).
> 
> Is it just me?  I'm using VS 2003 to compile - maybe mcs doesn't check
> for compliance?

Oh, you can make almost all of the fields private in that class. At the
very least negotiate, read, and write can be private.  That should fix
it. :) I was compiling with VS 2005 and have that particular warning
disabled.

-JD
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] mcs default encoding: Latin1 or not

[Kornél Pál]

Hi,


From: Atsushi Eno
Can we edit UTF8 files on vim on cygwin? No. This fact simply tells
that we are not living in the age of Unicode.


I think that for example the fact that a lot of default Linux installations
are using UTF-8 as default code page shows that we are living in the age of
Unicode.

I rarely use Linux so I have little experience regarding UTF-8 suppor on
Linux but I have the following experience on Windows (Windows XP with
relatively recent versions of software):

All the tools I use (including notepad.exe, Visual Studio .NET, csc.exe,
Total Commander, Internet Explorer, Firefox, .NET Framework) know UTF-8 and
can detect it without BOM as well but all of them defaults to system default
ANSI code page. In addition Mono has all the infrastructure to do the same
altough it has different default behaviour currently. Windows NT's are using
Unicode for representing strings in memory.

This makes me think that we are in the age of Unicode.

We shouldn't use non-ASCII characters inside code for identifiers but we can
use other characters in strings and comments. Of course we could use ASCII
but I think UTF-8 is a better solution.

Back to vim: I think that the fact that vim has no UTF-8 support tells that
vim is a tool from the past or the developers of vim still live in the past
as everything around vim has UTF-8 support.

At least on Windows you can open texts in any code page, edit them and when
you save them no characters will be corrupted so you can open it again using
the correct code page. This is true for UTF-8 as well. Some control chars
(0x00-0x1F) may be lost but these charactes are neither used by SBCS nor by
DBCS code pages. So you can safely edit UTF-8 files without UTF-8 support as
long as you modify only ASCII characters and add only only ASCII characters.

Not using BOM was an idea to support text editors without UTF-8 support but
if this makes a lot of UTF-8 aware editors not to use UTF-8 we have to use
BOM.

But I'm still sure that mcs has a bug regarding UTF-8. As non UTF-8 encoded
files can be read using UTF8Encoding (it skips invalid characters) but mcs
throws error for the source code that should not be caused by ignored
comment characters.

Kornél

- Original Message -
From: "Rafael Teixeira" <[EMAIL PROTECTED]>
To: "Atsushi Eno" <[EMAIL PROTECTED]>
Cc: "Kornél Pál" <[EMAIL PROTECTED]>; "mono-devel mailing list"

Sent: Friday, August 26, 2005 3:30 PM
Subject: Re: [Mono-dev] mcs default encoding: Latin1 or not


Just to comment a bit.

We have at least two decisions to make coming from this discussion:

- What default encoding should mcs use?

I prefer to use the local current encoding (Encoding.Defaut), so it
works for files edited with the commonly used editors for each
platform (gedit and I believe MonoDevelop, follow that for instance)
read/saved without specifiying another encoding. On windows it would
also work as notepad/write/vs.net follow the current codepage.

- What standard encoding all of our source files in mono repository
should use to keep things workable for hackers from all cultures?

Here we should stick to utf-8 (and for those that like to use vim
inside cygwin, I think we should ask vim hackers to make it support it
in that platform).  Remember that while most code in mono use only
ASCII identifiers (as it follows MS API, or is new code sticking to
coding guidelines), author names for sure and even some other
commentary text may contain non-ASCII characters.

The derived question is: should the files have the BOM marker? I would
say that for easing mixed mono/.net (mcs/csc) work they should, but
regrettably while VS.NET editor does make a good job of
detecting/hiding/preserving the BOM marker AFAIK most linux editors
doesn't, showing it as the specially-typed space character it is. I do
think we can make MonoDevelop mimic VS.NET in that regard but many
mono hackers use other editors, or a multitude of them (besides MD, I
use gedit extensively when doing quick fixes from the console). So I
don't have a firm opinion on this sub-issue, input is welcome.

Regards,

On 8/26/05, Atsushi Eno <[EMAIL PROTECTED]> wrote:

Hi,

> If you don't like ISO 28591 because it's foreign, why do you want to use
> ASCII in source files?:)

Well, ASCII is not foreign for Japanese. All of iso-2022-jp /
shift_jis / euc-jp don't contradict ASCII and it is actually
part of those encodings.

I know there used to be non-ASCII based encodings such as Indian
ISSCII-7, Arabic ASMO 449, Banguradesh BDS 1520:1995 etc. but I
don't know any modern encoding that contradicts ASCII (I don't
think it is possible to publish world-ready applications with
those encodings).

So AFAIK ASCII is safe, the GCM for us. Latin1 is not the case.

> I personally hate the fact of having code pages but this has historical
> reasons. I think UTF-8 is a good solution as it is international,
> culture-neutral and ASCII compatible.
>
> I think we are living in the age of Unicode. So there is no reason 

[Mono-dev] [PATCH] Monodoc: Add contribution links to home page

[Mario Sopena]

Hi,

> "Restore" is less frightening than "Delete", but it works better for
> "changes" than for "additions" so I feel the
> The dialog helps filter unintended or not ready contributions (either
> "changes" and "additions"). I the dialog you'd need to have a way to
> "Restore/Delete" unintended contributions and other to "Select" those
> to be uploaded, as they may yeld different sets.
>
> This dialog, or some other derived from it, may help also in
> navigating through the "pending" contributions (the ones not yet ready
> to be uploaded) as the work on them may span many sessions inside the
> documentation browser.
>

I've added to the patch the dialog thing, to see an screenshot look
here: 
http://msopena.blogspot.com/2005/08/contributor-experiencetm-revisited.html

There is the possibility to:
- open selected contribution
- restore/delete selected contribution
- upload only the marked ones

Of course that only works with contributions writen after the patch.
The old ones are automatically sent in the first upload being made (at
least the program shows at the root page how many of those
contributions are left, as well as new contributions with a link).

I've tried several times the upload process and everything seems ok
(sorry if I have sent several mini-contributions to the docs).

Ok to commit?

Mario


monodoc.tar.gz
Description: GNU Zip compressed data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Re: [PATCH] Fully Asynchronous and Re-Factored Ssl Streams in Mono.Security

[Harry Holt]

Thanks for this patch - I'm going to try some testing on my own project.

I am unable to compile this, though, as I am getting CLS-compliance
errors.  The Assembly is marked as compliant but the SslStreamBase
class includes a "read" object and a "Read" method (differing only in
case).

Is it just me?  I'm using VS 2003 to compile - maybe mcs doesn't check
for compliance?

Thx... HH

On 8/25/05, Sebastien Pouliot <[EMAIL PROTECTED]> wrote:
> Hello JD,
> 
> On Wed, 2005-24-08 at 21:12 -0700, JD Conley wrote:
> > I took the plunge and fully implemented async Ssl streams for both
> > client and server.  This fixes
> > http://bugzilla.ximian.com/show_bug.cgi?id=75687 as well as other bugs
> > I've been talking with Sebastien and Carlos about off list. This patch
> > passes the SocketHell tests that I contributed to them last week
> > (multi threaded concurrent async streaming through TCP sockets).
> 
> Wow! That's the kind of surprise I like when I wake up :-)
> 
> > It's also a bit of a re-factor, though I only touched two classes and
> > added one.  I pulled most of the code out of the individual
> > SslClientStream and SslServerStream and moved it down into a new
> > abstract SslStreamBase.  Client and server are now practically the
> > same implementation.  I left all existing interfaces present, but
> > obviously had to add some new ones.
> 
> We always "sticked" to the Fx 1.2 preview specs for the Ssl[Client|
> Server]Stream API and didn't planned to change this before implementing
> the new SslStream (in System.dll) for 2.0 - BUT this isn't a major
> problem if it doesn't break binary compatibility (for current
> applications linked with Mono.Security.dll).
> 
> > The only "gotcha" is if you start running low on threadpool threads.
> > Then the Ssl Stream will fall back to a synchronous handshake. The
> > other option here is to spawn a thread ourselves for the handshake
> > instead of using Delegate.BeginInvoke(), use the IO ThreadPool (is
> > that available to Mono.Security?), or just live with a synchronous
> > handshake. Of course, 99.999% of the time this issue won't occur and
> > won't be a problem unless you have both client and server sharing the
> > same Threadpool causing a deadlock.
> 
> That's not worse than the original (where the handshake was always
> synchronous).
> 
> > I hope this helps and gets integrated.  It's definitely necessary for
> > our implementation.
> 
> 1. I'll review the patch and, in doing so, check for possible binary
> compatibility problems. I'm sure Carlos will do likewise;
> 
> 2. I'll make public a new Mono.Security.dll assembly so that people that
> depends on Ssl*Stream may tests it and report any problem/difference;
> 
> 3. I'll run the regressions tests, the tools under /mcs/class/
> Mono.Security/Test/tools/*, to see if it works in previously reported
> conditions.
> 
> 4. Commit (both the patch and your SocketHell tests). Hopefully we can
> do all this before the next release.
> 
> Many thanks!
> --
> Sebastien
> 
> ___
> 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] [PATCH] Monodoc: Add contribution links to home page

[Mario Sopena]

Hi,

> "Restore" is less frightening than "Delete", but it works better for
> "changes" than for "additions" so I feel the
> The dialog helps filter unintended or not ready contributions (either
> "changes" and "additions"). I the dialog you'd need to have a way to
> "Restore/Delete" unintended contributions and other to "Select" those
> to be uploaded, as they may yeld different sets.
> 
> This dialog, or some other derived from it, may help also in
> navigating through the "pending" contributions (the ones not yet ready
> to be uploaded) as the work on them may span many sessions inside the
> documentation browser.
> 

I've added to the patch the dialog thing, to see an screenshot look
here: 
http://msopena.blogspot.com/2005/08/contributor-experiencetm-revisited.html

There is the possibility to:
- open selected contribution
- restore/delete selected contribution
- upload only the marked ones

Of course that only works with contributions writen after the patch.
The old ones are automatically sent in the first upload being made (at
least the program shows at the root page how many of those
contributions are left, as well as new contributions with a link).

I've tried several times the upload process and everything seems ok
(sorry if I have sent several mini-contributions to the docs).

Ok to commit?

Mario
Index: docbrowser/GeckoHtmlRender.cs
===
--- docbrowser/GeckoHtmlRender.cs	(revision 48726)
+++ docbrowser/GeckoHtmlRender.cs	(working copy)
@@ -48,7 +48,6 @@
 	protected void OnOpenUri (object o, OpenUriArgs args)
 	{
 		url = CheckUrl (args.AURI);
-		System.Console.WriteLine ("Abriendo:{0}:{1}:", url, args.AURI);
 		if (UrlClicked != null)
 			UrlClicked (this, new EventArgs());
 		args.RetVal = true; //this prevents Gecko to continue processing
Index: docbrowser/ChangeLog
===
--- docbrowser/ChangeLog	(revision 48726)
+++ docbrowser/ChangeLog	(working copy)
@@ -1,3 +1,16 @@
+2005-08-22 Mario Sopena Novales <[EMAIL PROTECTED]>
+	* browser.cs:
+		- Update the treeview everytime we change the tab
+		- Added a new CurrentNode property to Tabs
+		- Added a new class Contributions (Contributions window)
+		- update the save process to include the new NodeUrl property
+		- update the serial of not uploaded changes after a successful upload
+		- dont set the browser mode to viewer every time a row is activated
+	* browser.glade: 
+		- Change the "upload contributions" menu to "Contributions"
+		- Add the Contributions window
+	* GeckoHtmlRender.cs: cleaned
+	
 2005-08-17 Mario Sopena Novales <[EMAIL PROTECTED]>
 	* browser.cs: Added Menu Items for changing the font size when using 
 	gecko. Also added a Reload function.
Index: docbrowser/browser.cs
===
--- docbrowser/browser.cs	(revision 48726)
+++ docbrowser/browser.cs	(working copy)
@@ -307,6 +307,9 @@
 		} else {
 			paste1.Sensitive = true;
 		}
+		
+		if (tree_browser.SelectedNode != CurrentTab.CurrentNode)
+			tree_browser.ShowNode (CurrentTab.CurrentNode);
 	}
 	//
 	// Reload current page
@@ -451,6 +454,7 @@
 	public void Render (string text, Node matched_node, string url)
 	{
 		CurrentUrl = url;
+		CurrentTab.CurrentNode = matched_node;
 		CurrentTab.html.Render(text);
 		if (matched_node != null) {
 			if (tree_browser.SelectedNode != matched_node)
@@ -740,7 +744,124 @@
 		About.Show (this);
 	}
 
-	void OnUpload (object sender, EventArgs a)
+	void OnContrib (object sender, EventArgs a) 
+	{
+		Contributions.Show (this);
+	}
+
+	class Contributions {
+		[Glade.Widget] Window contribs;
+		[Glade.Widget] TreeView contrib_tree;
+		[Glade.Widget] Button contrib_open;
+		[Glade.Widget] Button contrib_restore;
+		ListStore contrib_store;
+
+		static Contributions ContribBox;
+		Browser parent;
+		GlobalChangeset chgs;
+
+		Contributions (Browser parent)
+		{
+			Glade.XML ui = new Glade.XML (null, "browser.glade", "contribs", null);
+			ui.Autoconnect (this);
+			this.parent = parent;
+			contribs.TransientFor = parent.window1;
+
+			contrib_store = new ListStore (typeof (bool), typeof (string), typeof (Change));
+
+			chgs = EditingUtils.changes;
+			contrib_tree.Selection.Changed += new EventHandler (OnSelectionChg);
+
+			contrib_tree.Model = contrib_store;
+			
+			// columns
+			CellRendererToggle toggle_cell = new CellRendererToggle ();
+			toggle_cell.Toggled += new ToggledHandler (OnToggleCell);
+			contrib_tree.AppendColumn ("upload", toggle_cell, "active", 0);
+			contrib_tree.AppendColumn ("node_url", new CellRendererText (), "text", 1);
+		}
+		static public void Show (Browser parent)
+		{
+			if (ContribBox == null)
+ContribBox = new Contributions (parent);
+
+			ContribBox.Load ();
+			ContribBox.contribs.ShowAll ();
+
+		}
+		void Load ()
+		{
+			contrib_store.Clear ();
+			foreach (DocSetChangeset dscs in chgs.DocSetChangesets) 
+foreach (Fi

[Mono-dev] Re: [Mono-list] Firebird db provider missing from Mono 1.1.8.3 win32 installer

[Carlos Guzmán Álvarez]

Hello:

FirebirdSql.Data.Firebird is missing on Windows.  Can we get this 
added please?


Can somebody add it to the build proceess, please ( it's build fine )




--
Best regards

Carlos Guzmán Álvarez
Vigo-Spain
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] mcs default encoding: Latin1 or not

[Rafael Teixeira]

Just to comment a bit.

We have at least two decisions to make coming from this discussion:

- What default encoding should mcs use? 

I prefer to use the local current encoding (Encoding.Defaut), so it
works for files edited with the commonly used editors for each
platform (gedit and I believe MonoDevelop, follow that for instance)
read/saved without specifiying another encoding. On windows it would
also work as notepad/write/vs.net follow the current codepage.

- What standard encoding all of our source files in mono repository
should use to keep things workable for hackers from all cultures?

Here we should stick to utf-8 (and for those that like to use vim
inside cygwin, I think we should ask vim hackers to make it support it
in that platform).  Remember that while most code in mono use only
ASCII identifiers (as it follows MS API, or is new code sticking to
coding guidelines), author names for sure and even some other
commentary text may contain non-ASCII characters.

The derived question is: should the files have the BOM marker? I would
say that for easing mixed mono/.net (mcs/csc) work they should, but
regrettably while VS.NET editor does make a good job of
detecting/hiding/preserving the BOM marker AFAIK most linux editors
doesn't, showing it as the specially-typed space character it is. I do
think we can make MonoDevelop mimic VS.NET in that regard but many
mono hackers use other editors, or a multitude of them (besides MD, I
use gedit extensively when doing quick fixes from the console). So I
don't have a firm opinion on this sub-issue, input is welcome.

Regards, 

On 8/26/05, Atsushi Eno <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> > If you don't like ISO 28591 because it's foreign, why do you want to use
> > ASCII in source files?:)
> 
> Well, ASCII is not foreign for Japanese. All of iso-2022-jp /
> shift_jis / euc-jp don't contradict ASCII and it is actually
> part of those encodings.
> 
> I know there used to be non-ASCII based encodings such as Indian
> ISSCII-7, Arabic ASMO 449, Banguradesh BDS 1520:1995 etc. but I
> don't know any modern encoding that contradicts ASCII (I don't
> think it is possible to publish world-ready applications with
> those encodings).
> 
> So AFAIK ASCII is safe, the GCM for us. Latin1 is not the case.
> 
> > I personally hate the fact of having code pages but this has historical
> > reasons. I think UTF-8 is a good solution as it is international,
> > culture-neutral and ASCII compatible.
> >
> > I think we are living in the age of Unicode. So there is no reason to use
> > ASCII. It's OK to use only ASCII in identifiers and use English in comments
> > and texts but I don't think we shouldn't take advantage of Unicode. We can
> > use it for names for example.
> 
> Can we edit UTF8 files on vim on cygwin? No. This fact simply tells
> that we are not living in the age of Unicode.
> 
> I heard a story - there was a Japanese or Chinesee who used Chinese
> character in his (or her) blog which are aggregated in somewhere
> (I don't remember the details) and that person got blamed of using
> Chinese, even though it is written in utf-8 encoding.
> 
> > I think mcs should use Encoding.Default as default encoding as I think this
> > is nearest to the user's need and provides compatiblity with csc.exe.
> 
> > But we should use UTF-8 without signature (BOM) for our .cs source code
> > files and explicitly specify for mcs to use UTF-8.
> 
> Why? I think we *should* use BOM as we discussed before that mcs
> (nor csc) does not autodetect encoding correctly.
> 
> Here I guess that you think BOM-less UTF8 sources could be edited
> in Latin1 editors. What happens if I put CJK ideographs? Actually
> we all (really all) Japanese hackers said that they feel reluctant
> to edit those files that contain Latin1 letters, because our
> usual editors does not support Latin1 (even as a candidate of
> encodings to save file).
> 
> Atsushi Eno
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


-- 
Rafael "Monoman" Teixeira
---
I'm trying to become a "Rosh Gadol" before my own eyes. 
See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.
It hurts!
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Re: [Mono-winforms-list] Landing: libgdiplus cairo 1.0 update

[Jordi Mas]

El dv 26 de 08 del 2005 a les 13:52 +0300, en/na Vladimir Moushkov va
escriure:

> Much much better!! Excelent work!

Thanks!

> But there is still drawing glitches and I think they are MWF related.
> See SWF-Datagrid test in winforms/

We still need to implement clipping in libgdiplus that Datagrid uses
extensively and some other X11 issues.

Jordi,

-- 
Jordi Mas i Hernàndez - Mono development team - http://www.mono-project.com
Homepage and LiveJournal at http://www.softcatala.org/~jmas


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list