[Mono-docs-list] [PATCH] Monodoc: Add contribution links to home page
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-docs-list maillist - Mono-docs-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-docs-list
Re: [Mono-winforms-list] Landing: libgdiplus cairo 1.0 update
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-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Master's Thesis
At 02:34 PM 26/08/2005 +0300, you wrote: Hi! I composed a reply message to you earlier but I guess our mail system blocked it because it contained .exe files as attachment (two versions of the game I am making). I just wanted to thank you for your good advice!!! I wrote one version of the game just the way you described. And it works really good! Only problem is that it is slow compared to real double buffer. It shouldn't be slow. The only reason I can think is that it must still be doing some sort of translation of the buffer. I assume you went with the second approach, with the Bitmap that you LockBits, draw to, UnlockBits, and then Graphics.DrawImageUnscaled to the screen. You can find the code for Bitmap.LockBits inside libgdiplus's src/bitmap.c file (the source code is in Mono's SVN). I actually wrote parts of it myself, but I was forced to work with the existing infrastructure which, for simplicity, only has one real non-indexed pixel format, that being CAIRO_FORMAT_ARGB32. This corresponds, I believe, to PixelFormat.Format32bppArgb. I'm not sure exactly how mono implements its double-buffer, but at least when I wrote my library (mode13 -- http://www.deltaq.org/mode13/), it was crucial that repainting the form not hold up the message queue, and also that it not be delayed by WM_* messages. I actually came up with a rather elaborate scheme involving two Bitmaps that get swapped back and forth, making an active plane that isn't visible, and a visible plane that isn't being drawn to. However, I never leave the game's thread, and I never use Window Messages, in order to paint the surface of the form. One other minor point of note for performance is that Mono is in the process of switching from Cairo 0.3 to Cairo 1.0. The current SVN head does not reflect this, afaik; it's still sitting on a branch. However, it will be switched over soon, after which many drawing operations should see a notable improvement in speed. Depending on exactly what you're doing when drawing, this may affect you more or less. :-) I wrote a second version of the game that uses overridden OnPaint()-method for drawing AND thread for game loop. This way I could use the doublebuffer setting and get about two times faster framerate compared to what you suggested. Only problem is that it doesn't work with Mono :( I call Refresh()-method in thread's while loop to get form redrawn. This works just fine with .NET but not with Mono. Could it be that Mono's Refresh()-method is not implemented at all? It should force invalidate and update of the form immediately after calling, and that way it may not append any messages to message queue? Check out the following MSDN page: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/ frlrfsystemwindowsformscontrolclassinvokerequiredtopic.asp (try http://lnks.us/WCTG09 if that wraps too badly; it should go to the same place) In particular, it says, quote: There are four methods on a control that are safe to call from any thread: Invoke, BeginInvoke, EndInvoke and CreateGraphics. The Refresh method isn't one of these, I'm afraid, and that could be the source of your problems. Even if it were (or if you used Control.Invoke), it would still require marshalling the repaint operation to a different thread, which is something you really want to avoid! It should be possible to get directly drawing to the form from a background thread to perform *better* than drawing from the UI thread, since you can do essentially exactly what the framework does on the UI thread without all the extra baggage of passing messages around, waiting for other messages to be handled, etc. If you really want the standard double-buffering behaviour, you might be able to replicate it within your own code; just search System.Windows.Forms/Control.cs and any other applicable files for places where it checks whether the DoubleBuffer style is set. Would you like to see the sourcecode of my game too? I can try to attach it again without any binaries (so our mail-blocker shouldn't block it). It's very nice to have someone that can understand my point of view there :) BTW. You were the only one on your post list who replyed something useful to me! Sure, and thanks :-) Many people see programming as a job -- something tedious which must be done but at least they get paid for it -- but I have a true passion for it :-) Jonathan Gilbert At 11:10 AM 10/08/2005 +0300, Alvi Happonen wrote: [snip] This is easy to do with .NET by overriding main forms OnPaint-method and calling this.Invalidate() at the end of it. This is very simple and effective but only seems to work with .NET. Mono doesn't start looping this way. It seems that Mono always needs somekind of event (from Timer for example) to call OnPaint-method. While the GUI widgets and such all require marshalling calls to a specific UI thread, System.Drawing is completely threadsafe and can be used from multiple threads at the same time with
[Mono-dev] Re: [Mono-winforms-list] Landing: libgdiplus cairo 1.0 update
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
[Mono-dev] Re: [Mono-list] Firebird db provider missing from Mono 1.1.8.3 win32 installer
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] [PATCH] Monodoc: Add contribution links to home page
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 (FileChangeset fcs in dscs.FileChangesets)
+
Re: [Mono-dev] mcs default encoding: Latin1 or not
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 mono-devel-list@lists.ximian.com 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
RE: [Mono-dev] Re: [PATCH] Fully Asynchronous and Re-Factored SslStreams in Mono.Security
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
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] the c# compiler code
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: mono-devel-list@lists.ximian.com 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] 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
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.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
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
AW: [Mono-dev] the c# compiler code
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] 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: mono-devel-list@lists.ximian.com 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-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
RE: [Mono-list] Re: Embedded Mono with native threads
On 08/25/05 Alexey Tsynaev wrote: But actually I don't invoke any unmanaged code from c# code Host application creates thread where function from my plugin is called. In this function I just get MonoMethod and execute it by mono_runtime_invoke. That is all. Then you are responsible for calling mono_thread_attach() yourself. Anyway, the patch I posted should solve your issue as well: care to try it out? I'm calling mono_thread_attach() in plugin's function before executing managed code. Where I can get your patch? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mod_mono install
Hello Jeremy. It is possible to change the destination of those files. But the first problem we'll have to look at, is if you have the permissions to edit in the Apache configuration files. If you haven't it is impossible to make mod_mono work. Please give me further feedback on this =) Med venlig hilsen / Best Regards -- Janus Tougaard Ridderhatten 316 DK-5220 Odense SØ Phone: +45 6165 4801 E-mail: [EMAIL PROTECTED] Web-site: DaniJonex.NET -- Jeremy Vaught wrote: I'm trying to install mod_mono, but I'm installing on a hosted server, and don't have write permissions in apache. I can './configure' mod_mono and I can 'make'. But when I run 'make install', I get this: cp .libs/mod_mono.so /usr/local/apache/libexec/mod_mono.so cp: cannot create regular file `/usr/local/apache/libexec/mod_mono.so': Permission denied And so of course my installation aborts. Can I change where this is put and it will still work? If so, how? Thanks for your help, Jeremy Vaught ImBloggingThis.org ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list begin:vcard fn:Janus Tougaard n:Tougaard;Janus email;internet:[EMAIL PROTECTED] tel;fax:+45 6593 0996 tel;home:+45 6593 0996 tel;cell:+45 6165 4801 x-mozilla-html:TRUE version:2.1 end:vcard ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Re: Embedded Mono with native threads
El vie, 26-08-2005 a las 11:44 +0500, Alexey Tsynaev escribió: On 08/25/05 Alexey Tsynaev wrote: But actually I don't invoke any unmanaged code from c# code Hi Alexey, Where I can get your patch? You can find it in the following Paolo's message: http://lists.ximian.com/pipermail/mono-list/2005-August/028134.html Cheers, ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Francis Brosnan Blazquez [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
Paul F. Johnson wrote: On Thu, 2005-08-25 at 16:04 +0200, Paolo Molaro wrote: On 08/23/05 Julien Gilli wrote: There hasn't been any feedback from several core developers on this point. So I ask the same question again :-). Do you think that it's something that could be help mono development ? Yes, it would be useful. Who is going to step up and organize everything? What needs to be done? I think that putting the following couple of pages together on the Wiki : - General informations on bug days : * What is a bug day ? * Who can attempt ? * When does it take place ? - Detailed informations on what to do during a bug day : This can be split in two parts : bug squashing and bug triaging : * As for bug triaging : * How to find bug reports that are most important to triage ? * How to triage a bug report ? * As for bug squashing : * How to find bug confirmed bug reports that are most important to fix ? * How to fix a bug ? along with an IRC channel and a mailing-list to announce special events (like special bug days before a release, etc.) could be a good step forward :-). What do you think about this ? I can give some time to help organize these bug squashing/triaging thing. I can write the wiki pages too . However, I think we should discuss about conventions used by mono developers for the bugzilla system (like what version or milestone a bug report should be assigned to, etc.) before doing it. Looking forward to hear your comments. All the best, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: Serializing Objects to a Stream
Jonathan,
how can i serialize an object to Xml but storing the object to a
Stream and not to a File?
A file _is_ a stream. Where is the point? Do you mean storing to memory?
Then use MemoryStream.
I am looking for a way to do XmlSerialization (or maybe
SoapSerialization) to send objects
Maybe? XmlSerialization and Binary+SoapSerialization are
totally different, so you should take a decision soon:
- XmlSerialization is mainly used for WebServices, because it
assures cross-platform compatibility. It can only be used
with custom types (types you have defined) and some basic
types.
See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconintroducingxmlserialization.asp
- Binary+SoapSerialization is .NET-only
via Remoting over the wire, and the deserialize on the Server the
serialized object stream.
how to?
This may sound strange, but that's they way i should do it.
Since streams cannot be remoted you have to convert the
stream to a byte[] or to a string:
// using binary serialization
public static byte[] SerializeToArray(object data)
{
MemoryStream stream = new MemoryStream();
BinaryFormatter formatter = new BinaryFormatter();
formatter.Serialize(stream, data);
return stream.ToArray();
}
// using XML serialization
public static string XmlSerializeToString(object data)
{
StringBuilder b = new StringBuilder();
XmlSerializer x = new XmlSerializer(data.GetType());
TextWriter w = new StringWriter(b);
x.Serialize(w, data);
w.Close();
return b.ToString();
}
The deserialization methods are left as an exercise for the reader ;-)
Rob
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
Hi, What needs to be done? I think that putting the following couple of pages together on the Wiki : - General informations on bug days : * What is a bug day ? * Who can attempt ? This would need to be split and preferably, peer mentored. For example, user a may write and compile some code which clearly shows (say) MWF is broken for spot colours. This is submitted and a peer proofs the code to see that it's not user a who has made a boo-boo before submitting as a real bug. * When does it take place ? Logistically, the third is the biggest one given the diversity of places people are (I'm in the UK for instance while Peter (say) is out by 6 hours from GMT). I'd suggest that the bug day would need to be split into two half days for when the developers are around. - Detailed informations on what to do during a bug day : This can be split in two parts : bug squashing and bug triaging : * As for bug triaging : * How to find bug reports that are most important to triage ? * How to triage a bug report ? All bugs are important, just some more than others. I remember finding one very small bug in an application called TechWriterPro (it's a RISC OS app) which when investigated, proved to be massive and set back the release schedule by a month. * As for bug squashing : * How to find bug confirmed bug reports that are most important to fix ? * How to fix a bug ? Ideally, the developers, though others should never be discouraged. This is were the peer review comes into it's own - bugs which aren't bugs never get past the reviewer. along with an IRC channel and a mailing-list to announce special events (like special bug days before a release, etc.) could be a good step forward :-). Definitely! What do you think about this ? I can give some time to help organize these bug squashing/triaging thing. I can write the wiki pages too . However, I think we should discuss about conventions used by mono developers for the bugzilla system (like what version or milestone a bug report should be assigned to, etc.) before doing it. Sounds a very good set of ideas. Would this bug day be best set on a saturday or sunday though? Whatever happens, I'm happy to give over as much time as I can. I am using mono more and more now (especially as it forms the basis of some of my research project) - I can give back this way :-) TTFN Paul (watching MS.NET deinstall while thrashing the HD) -- Logic, my dear Zoe, is merely the ability to be wrong with authority - Dr Who ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mod_mono install
Thanks Janus, I only have permissions on '/home/jeremyvaught/' However, I have been in contact with the tech support, and I may be able to have them make some configuration changes, if I know exactly what changes need to be made. I don't suppose this is possible, but can I install my a second instance of apache in my directory? Would this work as a work-around? Now that I think about it more, I'm pretty sure that wouldn't work. :-( Thanks again for your help, Jeremy Vaught ImBloggingThis.org On Fri, 2005-08-26 at 09:06 +0200, Janus Tougaard wrote: Hello Jeremy. It is possible to change the destination of those files. But the first problem we'll have to look at, is if you have the permissions to edit in the Apache configuration files. If you haven't it is impossible to make mod_mono work. Please give me further feedback on this =) Med venlig hilsen / Best Regards -- Janus Tougaard Ridderhatten 316 DK-5220 Odense S Phone: +45 6165 4801 E-mail: [EMAIL PROTECTED] Web-site: DaniJonex.NET -- Jeremy Vaught wrote: I'm trying to install mod_mono, but I'm installing on a hosted server, and don't have write permissions in apache. I can './configure' mod_mono and I can 'make'. But when I run 'make install', I get this: cp .libs/mod_mono.so /usr/local/apache/libexec/mod_mono.so cp: cannot create regular file `/usr/local/apache/libexec/mod_mono.so': Permission denied And so of course my installation aborts. Can I change where this is put and it will still work? If so, how? Thanks for your help, Jeremy Vaught ImBloggingThis.org ___ 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 Bug Day
Hello, Paul F. Johnson wrote: I think that putting the following couple of pages together on the Wiki : - General informations on bug days : * What is a bug day ? * Who can attempt ? This would need to be split and preferably, peer mentored. I don't understand what you think should be peer mentored. Do you mean that attempting a bug day should be peer mentored ? Or were you mentionning writing up these pages should be peer mentored ? For example, user a may write and compile some code which clearly shows (say) MWF is broken for spot colours. This is submitted and a peer proofs the code to see that it's not user a who has made a boo-boo before submitting as a real bug. I totally agree with that, it is a typical use case of a bug day :-). * When does it take place ? Logistically, the third is the biggest one given the diversity of places people are (I'm in the UK for instance while Peter (say) is out by 6 hours from GMT). I'd suggest that the bug day would need to be split into two half days for when the developers are around. IIRC, the GNOME project has bug days from 15 PM to 21 PM UTC, which is nice during the week. I agree that bug days during the week-end would be fine too. Maybe we could split bug days with one in the middle of the week and one during the week-end ? - Detailed informations on what to do during a bug day : This can be split in two parts : bug squashing and bug triaging : * As for bug triaging : * How to find bug reports that are most important to triage ? * How to triage a bug report ? All bugs are important, just some more than others. I remember finding one very small bug in an application called TechWriterPro (it's a RISC OS app) which when investigated, proved to be massive and set back the release schedule by a month. I agree too, but there are some special cases for which you could want to focus your attention on a certain kind of bugs (just before a release, a feature freeze, whatever). * As for bug squashing : * How to find bug confirmed bug reports that are most important to fix ? * How to fix a bug ? Ideally, the developers, though others should never be discouraged. This is were the peer review comes into it's own - bugs which aren't bugs never get past the reviewer. I agree too : triaging bug is the primary goal, nevertheless fixing them is great :-). Would this bug day be best set on a saturday or sunday though? What do you think about the middle of the week/week-end schedule i mentionned above ? Maybe we should set a goal for the first milestone, like having a bug day next saturday, or on 09/10 ? By trying to get things done, we will probably come across some problems that we'll resolve, and then we can go from there for the future bug days. Again, looking forward to hearing from you :-). All the best, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Sqlite version
Thomas Zoechling a écrit : You have to specify the Version in the Connectionstring: string connectionString = Version=3,URI=file:SqliteTest.db; Hello, it doesn't seem to work with mono 1.1.6: System.DllNotFoundException: sqlite3 in (wrapper managed-to-native) Mono.Data.SqliteClient.Sqlite:sqlite3_open (string,intptr) in 0x00056 Mono.Data.SqliteClient.SqliteConnection:Open () in 0x00066 Platine.Plugins.FetchCDInfo:Initialize (Platine.CoreLibs.Session session) in 0x00130 Platine.Plugins.FetchCDInfo:Main (System.String[] args) It looks like it doesn't handle sqlite version 3. I couldn't find anything useful on Internet about this error message. Julien Sobrier ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mono Bug Day
IIRC, the GNOME project has bug days from 15 PM to 21 PM UTC, which is nice during the week. UTC == GMT Universal Coordinated Time. Keeps the French happy (well, happier)! ;) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Sqlite version
http://turchin.homelinux.net/blogx/PermaLink.aspx/acbc7138-08d6-4a0f-a86d-709748a283d8 Julien Sobrier wrote: Thomas Zoechling a écrit : You have to specify the Version in the Connectionstring: string connectionString = Version=3,URI=file:SqliteTest.db; Hello, it doesn't seem to work with mono 1.1.6: System.DllNotFoundException: sqlite3 in (wrapper managed-to-native) Mono.Data.SqliteClient.Sqlite:sqlite3_open (string,intptr) in 0x00056 Mono.Data.SqliteClient.SqliteConnection:Open () in 0x00066 Platine.Plugins.FetchCDInfo:Initialize (Platine.CoreLibs.Session session) in 0x00130 Platine.Plugins.FetchCDInfo:Main (System.String[] args) It looks like it doesn't handle sqlite version 3. I couldn't find anything useful on Internet about this error message. Julien Sobrier ___ 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 Bug Day
Paul F. Johnson wrote: This would need to be split and preferably, peer mentored. I don't understand what you think should be peer mentored. Do you mean that attempting a bug day should be peer mentored ? Or were you mentionning writing up these pages should be peer mentored ? The reports coming in. For example, if I was to submit a massive lump of code which demonstrated two bugs, neither of which depending on each other, then the reviewer would reject the code and ask for the smallest case of each to demonstrate the point. Ok, got it :-). All bugs are important, just some more than others. I remember finding one very small bug in an application called TechWriterPro (it's a RISC OS app) which when investigated, proved to be massive and set back the release schedule by a month. I agree too, but there are some special cases for which you could want to focus your attention on a certain kind of bugs (just before a release, a feature freeze, whatever). True. I'm assuming this will be a freeze before an official beta release (going by the time line). In that case, some order of importance needs to be given over - something like (most important) compiler and mono runtime - corelibs - MWF [inc. cairo/libgdiplus] - monodevelop - gtklibs - monodoc (least). I've distinguished between MWF and the corelibs as despite it being mega important, having the likes of Encoding, threading and IO streams working spot on is of greater importance as a whole. Again, I will refer to GNOME for this : they use the term showstopper for bugs that truly shows. That is, everybody get to see the consequence of the bug. As for GNOME, it can be for example the mouse pointer that get locked inside the panel, or evolution that can't send and e-mail. It must be highly reproductible, and affect many platforms. Briefly, the order of importance here is given by how many users can see the bug and how much it prevents them from doing what they want. For example, if there's a bug that prevent monodevelop from starting, it would be marked as a showstopper, whereas not being able to compile a given type of not so often used code with the compiler (which is more a core component than monodevelop) would not. Maybe we should set a goal for the first milestone, like having a bug day next saturday, or on 09/10 ? Next sat sounds fine, though will there be enough time to set things up and would it be an idea for there to be a default email address (say [EMAIL PROTECTED]) whereby test cases arrive to all the reviewers and if they pass, bugzilla them? We can go this way, or mark bug that have not been reviewed as UNAPROVED and then wait for either a developer or a bug day buddy to confirm it before working on a fix. Whatever we choose, we must have some agreement from the key developers to even start thinking about seting up what we are discussing now. All the best, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
There are two email lists that will help: - mono-bugs - mono-patches If you subscribe to these mail lists, you will be able to get email about a new bug or a change in a bug or its status. Also, mono-patches will allow you to peer review others code. Maybe a Pre-Release Days instead of Bug Day would be more appropriate for Mono. We could help with docs, update status info on the mono wiki, test building the pre-release tarballs, test a pre-release of the installers, etc... And of course, make sure any serious bugs are squashedso we can have an outstandingstable release. However, any pre-release tarballs,RPMs,or installers would not be downloadable from the Downloads page. Maybe only available as ftp and the word prerelease is in the tarball or installer's filename. Just some ideas... I'll be waiting to see your wiki page. "Paul F. Johnson" [EMAIL PROTECTED] wrote: Hi, What needs to be done?I think that putting the following couple of pages together on the Wiki : - General informations on bug days : * What is a bug day ? * Who can attempt ?This would need to be split and preferably, peer mentored. For example, user"a" may write and compile some code which clearly shows (say) MWF is brokenfor spot colours. This is submitted and a peer proofs the code to see thatit's not user "a" who has made a boo-boo before submitting as a real bug. * When does it take place ?Logistically, the third is the biggest one given the diversity of placespeople are (I'm in the UK for instance while Peter (say) is out by 6 hoursfrom GMT). I'd suggest that the bug "day" would need to be split into two halfdays for when t he developers are around. - Detailed informations on what to do during a bug day : This can be split in two parts : bug squashing and bug triaging : * As for bug triaging : * How to find bug reports that are most important to triage ? * How to triage a bug report ?All bugs are important, just some more than others. I remember finding onevery small bug in an application called TechWriterPro (it's a RISC OS app)which when investigated, proved to be massive and set back the releaseschedule by a month. * As for bug squashing : * How to find bug confirmed bug reports that are most important to fix ? * How to fix a bug ?Ideally, the developers, though others should never be discouraged. This iswere the peer review comes into it's own - bugs which aren't bugs never getpast the reviewer. along with an IRC channel and a mailing-list to announce specia l events (like special bug days before a release, etc.) could be a good step forward :-).Definitely! What do you think about this ? I can give some time to help organize these bug squashing/triaging thing. I can write the wiki pages too . However, I think we should discuss about conventions used by mono developers for the bugzilla system (like what version or milestone a bug report should be assigned to, etc.) before doing it.Sounds a very good set of ideas. Would this bug day be best set on a saturdayor sunday though? Whatever happens, I'm happy to give over as much time as Ican. I am using mono more and more now (especially as it forms the basis ofsome of my research project) - I can give back this way :-)TTFNPaul(watching MS.NET deinstall while thrashing the HD)-- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - DrWho___Mono-list maillist - Mono-list@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-list__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] OpenOffice.org and Mono status update
I heard some people such as Christian Hergert were interested in Mono working with Open Office.org 2.0. Here is Michael Meek's blog about Open Office.org and Mono working together on SUSE 9.3 Beta2. http://www.gnome.org/~michael/activity.html#2005-08-23 This links to a wiki detailing how to get OOo working with Mono: http://www.go-oo.org/wiki/index.php/Mono_Integration Here is what Michael had to say on his blog: Mono/OO.o on SUSE 9.3 Beta2 working nicely out of the box here's how to get it working: Install the OpenOffice_org-mono package via Yast. Download my .exe run it [you know you want to]: $ cd /usr/lib/ooo-2.0/program $ MONO_PATH=. mono SpreadsheetSample.exe Watch the frenzied spreadsheet construction Start your day with Yahoo! - make it your home page ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
Daniel Morgan wrote: Maybe a Pre-Release Days instead of Bug Day would be more appropriate for Mono. What do developers think about this ? I think that doing the hard work little by little is easier than having a big sprint once in a while, but I agree that prerelease days would be a great thing too :-). We could help with docs, update status info on the mono wiki, test building the pre-release tarballs, test a pre-release of the installers, etc... And of course, make sure any serious bugs are squashed so we can have an outstanding stable release. However, any pre-release tarballs, RPMs, or installers would not be downloadable from the Downloads page. Maybe only available as ftp and the word prerelease is in the tarball or installer's filename. Just some ideas... They sound great to me, however I don't think that prerelease days serve the same purpose as a bug day. I think that there is room for the two of them :-). -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Serial Port Libraries
The SerialPort class is implemented by Microsoft in the .net 2.0 framework in the System.IO.Ports namespace. Mono doesn't seem to have it implemented yet. But eventually someone will implement it. On 8/26/05, Howard Cole [EMAIL PROTECTED] wrote: Are there any Serial Port libraries in Mono? Thanks in advance Howard Cole http://www.selestial.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Bas Westerbaan http://blog.w-nz.com/ GPG Public Keys: http://w-nz.com/keys/bas.westerbaan.asc ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] (no subject)
Do we need to get in contact with Neoware to talk about it ? Erik On Tue, 2005-08-09 at 22:01 -0400, Nick Berardi wrote: I personally see no problem with show casing the site. Let me know what you need and anything I can do. Nick -Original Message- From: Miguel de Icaza [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 09, 2005 2:05 PM To: Nick Berardi; Erik Dasque Cc: mono-list@ximian.com Subject: Re: [Mono-list] (no subject) Hello, I have just recently completed a site for a client using Mono/XSP. The client is Neoware (http://www.neoware.com), they are the #2 thin client provider in the world right a head of HP. IBM distributes their products on IBM's website. So they are no small company. I replaced their backend processing which use to use CGI/Perl scripting, with handlers and a couple ASPX pages placed around the site. For example http://www.neoware.com/auth/Login.aspx and all the forms on the site use a handler I called BlackBox.ashx. Congratulations! Do you think it would be possible to showcase or link to it from the Mono site as a place that is using Mono/XSP? miguel. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
Hi, True. I'm assuming this will be a freeze before an official beta release (going by the time line). In that case, some order of importance needs to be given over - something like (most important) compiler and mono runtime - corelibs - MWF [inc. cairo/libgdiplus] - monodevelop - gtklibs - monodoc (least). I've distinguished between MWF and the corelibs as despite it being mega important, having the likes of Encoding, threading and IO streams working spot on is of greater importance as a whole. Again, I will refer to GNOME for this : they use the term showstopper for bugs that truly shows. That is, everybody get to see the consequence of the bug. As for GNOME, it can be for example the mouse pointer that get locked inside the panel, or evolution that can't send and e-mail. True. Problem here is that mono is not GNOME and while we certainly can borrow the methodology, the most important thing has to be that the compiler does as it's told and things like threading don't screw things up. How often is the screw up in MWF or gtk-sharp because of faulty code generation or a problem of the compiler? It must be highly reproductible, and affect many platforms. Yep. We have to consider Win32, MacOSX as well as many different Linux distros. Briefly, the order of importance here is given by how many users can see the bug and how much it prevents them from doing what they want. It certainly would be an interesting statistical exercise to see how many people are affected by the same bug (or more likely, same root problem bug). For example, if there's a bug that prevent monodevelop from starting, it would be marked as a showstopper, whereas not being able to compile a given type of not so often used code with the compiler (which is more a core component than monodevelop) would not. I'd actually argue that that would not constitute it being a show stopper unless it was a component (such as monodoc or gtksharp) which was at fault in which case the show stopper is not with MonoDevelop, but with the broken component, in which case we'd need to do some poking around to form a test case. Next sat sounds fine, though will there be enough time to set things up and would it be an idea for there to be a default email address (say [EMAIL PROTECTED]) whereby test cases arrive to all the reviewers and if they pass, bugzilla them? We can go this way, or mark bug that have not been reviewed as UNAPROVED and then wait for either a developer or a bug day buddy to confirm it before working on a fix. Could do. Whatever we choose, we must have some agreement from the key developers to even start thinking about seting up what we are discussing now. Couldn't agree more. Miguel, Peter, Jordi - comments? TTFN Paul -- A lot of football success is in the mind. You must believe you are the best and then make sure that you are. In my time at Liverpool we always said we had the best two teams on Merseyside, Liverpool and Liverpool Reserves. - Bill Shankly ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] (no subject)
I don't see any legal issue regarding listing the site on a page that showcases Mono/ASP.NET users. It can be seen in Server HTTP header that it uses mod_mono and can be seen that has .aspx pages as well. So it's no secret that they use Mono/ASP.NET. Only people related to the site or the company (Nick for example) who has inside information should take care not to publish information they shouldn't because of non-disclosure agreements for example. But this is their business we (other people) don't have to worry about such things. Kornél - Original Message - From: Erik Dasque [EMAIL PROTECTED] To: Nick Berardi [EMAIL PROTECTED] Cc: mono-list@ximian.com; 'Miguel de Icaza' [EMAIL PROTECTED] Sent: Friday, August 26, 2005 8:59 PM Subject: RE: [Mono-list] (no subject) Do we need to get in contact with Neoware to talk about it ? Erik On Tue, 2005-08-09 at 22:01 -0400, Nick Berardi wrote: I personally see no problem with show casing the site. Let me know what you need and anything I can do. Nick -Original Message- From: Miguel de Icaza [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 09, 2005 2:05 PM To: Nick Berardi; Erik Dasque Cc: mono-list@ximian.com Subject: Re: [Mono-list] (no subject) Hello, I have just recently completed a site for a client using Mono/XSP. The client is Neoware (http://www.neoware.com), they are the #2 thin client provider in the world right a head of HP. IBM distributes their products on IBM's website. So they are no small company. I replaced their backend processing which use to use CGI/Perl scripting, with handlers and a couple ASPX pages placed around the site. For example http://www.neoware.com/auth/Login.aspx and all the forms on the site use a handler I called BlackBox.ashx. Congratulations! Do you think it would be possible to showcase or link to it from the Mono site as a place that is using Mono/XSP? miguel. ___ 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] mod_mono install
Well i think it would be a quite difficult operation, maby impossible. You can't make any Apache configuration your self from that directory, have you told this guy from the hosting company that you are planing to load a new module on their server? - Usaly this aint possible, they wont. Also keep in mind that you'll have to install mono and XSP, have you done that on the hosting server? Have you tried to ask them if they just can put mono on it the real way? Med venlig hilsen / Best Regards -- Janus Tougaard Ridderhatten 316 DK-5220 Odense SØ Phone: +45 6165 4801 E-mail: [EMAIL PROTECTED] Web-site: DaniJonex.NET -- Jeremy Vaught wrote: Thanks Janus, I only have permissions on '/home/jeremyvaught/' However, I have been in contact with the tech support, and I may be able to have them make some configuration changes, if I know exactly what changes need to be made. I don't suppose this is possible, but can I install my a second instance of apache in my directory? Would this work as a work-around? Now that I think about it more, I'm pretty sure that wouldn't work. :-( Thanks again for your help, Jeremy Vaught ImBloggingThis.org On Fri, 2005-08-26 at 09:06 +0200, Janus Tougaard wrote: Hello Jeremy. It is possible to change the destination of those files. But the first problem we'll have to look at, is if you have the permissions to edit in the Apache configuration files. If you haven't it is impossible to make mod_mono work. Please give me further feedback on this =) Med venlig hilsen / Best Regards -- Janus Tougaard Ridderhatten 316 DK-5220 Odense SØ Phone: +45 6165 4801 E-mail: [EMAIL PROTECTED] Web-site: DaniJonex.NET -- Jeremy Vaught wrote: I'm trying to install mod_mono, but I'm installing on a hosted server, and don't have write permissions in apache. I can './configure' mod_mono and I can 'make'. But when I run 'make install', I get this: cp .libs/mod_mono.so /usr/local/apache/libexec/mod_mono.so cp: cannot create regular file `/usr/local/apache/libexec/mod_mono.so': Permission denied And so of course my installation aborts. Can I change where this is put and it will still work? If so, how? Thanks for your help, Jeremy Vaught ImBloggingThis.org ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list begin:vcard fn:Janus Tougaard n:Tougaard;Janus email;internet:[EMAIL PROTECTED] tel;fax:+45 6593 0996 tel;home:+45 6593 0996 tel;cell:+45 6165 4801 x-mozilla-html:TRUE version:2.1 end:vcard ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Npgsql 0.7.1 is out!!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'd like to say that Npgsql version 0.7.1 is out. Npgsql is a .Net Provider for Postgresql 7.x and above. It allows your .Net programs access a Postgresql backend. More info about it can be found at: http://www.mono-project.com/contributing/postgresql.html and http://gborg.postgresql.org/project/npgsql This release fix some critical bugs with MinPoolSize and concurrent utilization of Npgsql. Also fixed problems when calling stored procedures and having trailing ; on commandtexts. Some other bugs were fixed and metadata improved. Please, see full change log below for more details. All users are encouraged to upgrade to this version. Also, on this release, there is no ms.net 1.0 Npgsql version available. Previous 1.0 releases were using Mono.Security.dll compiled for 1.1 and so it was really a 1.1 assembly. Nobody complained up to now so I think nobody is using Npgsql with ms 1.0. Please, let me know if you need a 1.0 installation. Download Page: http://gborg.postgresql.org/project/npgsql/download/download.php We now have windows installers for .Net 1.0 and 1.1. Gnu/Linux and FreeBSD are also available. Special Thanks: * Oluwatope Akinniyi for building and testing windows installers. * Josh Cooley for helping with bug fixes :) * Jon Asher for help and support. * All users and developers who give feedback and comments about Npgsql. Please, give it a try and let me know of any problems you get. RELEASE NOTES: Npgsql 0.7.1 Features added: Josh Cooley (jbnpgsql at tuxinthebox dot net) improved Metadata support in Npgsql. Added support for the following collections through NpgsqlConnection.GetSchema() methods: MetaDataCollections, Restrictions, Databases, Tables, Columns, Views and Users. Also added support for restrictions when getting info about these collections. Added refcursor parameter support. Now, refcursors can be passed as arguments for functions. Thanks Jon Asher for heads up and tests. Bug fixes: Fixed problem with query strings with newlines. Regexp used to parse parameters were removing new line bytes creating query strings with errors. Thanks Jaroslaw Kowalski (jaak at jkowalski dot net) for fix. Updated ProviderType metadata from NpgsqlDataReader.GetResultsetSchema to be the string for the type rather than the oid. Fixed ColumnSize, NumericPrecision, NumericScale, BaseColumnName, AllowDBNull, and IsAliased. Also integrated patch from (rlp at bamafolks dot com), gborg 751. Thanks Josh Cooley (jbnpgsql at tuxinthebox dot net). gborg 1388. Fixed documentation about User Id connection string key. Thanks Peyn (peyn at tlen dot pl) for heads up. gborg 1387. Fixed problem when using commandtype.storedprocedure with command texts which have parameters with ' or any other value which needed to be escaped. Now they are properly handled. Thanks Dalibor (dalxxx at email dot com) for heads up and tests. Fixed problem with stored procedure command texts which finished with a ;. Npgsql was adding incorrectly a trailing () when calling this command text. Fixed ConnectorPool when creating MinPoolSize connections. Josh Cooley said when submitting patch: It seems that if the MinPoolSize was set to anything other than one, then it was prepopulated with the first connector created. Thanks Aza (aza at azaclauson dot com) for heads up and big thanks Josh Cooley (jbnpgsql at tuxinthebox dot net) for fix! Fixed problems with parameters with @ prefix. They weren't correctly recognized. Thanks Pejvan Beigui ( pejvan at gmail dot com) for heads up. Fixed infinite loop when getting metadata using Mono runtime. We were using DataSet.Fill to get metadata info and Mono implementation of DataSet.Fill was calling our method to get metadata which resulted in a loop. Thanks Josh Cooley (jbnpgsql at tuxinthebox dot net) for fix! Thanks in advance. - -- Regards, Francisco Figueiredo Jr. Npgsql Lead Developer http://gborg.postgresql.org/project/npgsql MonoBrasil Project Founder Member http://monobrasil.softwarelivre.org - - Science without religion is lame; religion without science is blind. ~ Albert Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQw/l6f7iFmsNzeXfAQKuoAf/fYU1bjVe9lmdEi58oLOXFNbNCqYT7vkc EcZXbyYOyOSsiG042pPUcu3ni7k5WHXH+D6glknEZIYswrmtC9J9hwZU/C1g0Jme N9xZMu9e9vJ/iXAadTY1bhhaS5zC3OWe9Q8BznnFKFY0rHeXa2IF2UOt1r3AaMYp 6YfBXu8v/fpDCg5u0ccbX7nog/6EZsZgWyeyVrvqiJO6WCP8sK2T3+eXnqPA2sNJ RSKiOr4L2yWHZj5qdHAWSNoTQRP8rb6tZay+V3vNJH0gn8V7vmFQcrgf606Y8KgX G3tnNX1IZLIMt5ojX6A9a+HS2j+09oVHS3CvJ8iTRvdRd9bCVttqJQ== =vPe3 -END PGP SIGNATURE- ___ Yahoo! Acesso Grátis - Internet rápida e
Re: [Mono-list] Firebird db provider missing from Mono 1.1.8.3 win32 installer
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-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
