Re: [Mono-list] Mono: Post 1.0 plans and development update.
Miguel de Icaza wrote: There are a number of areas in which we are focusing for the Mono 1.2 release: Is a working/bulletproof implementation of AppDomain.Unload on the radar for 1.2? Is it likely to make it back into the 1.0 branch, since it would be a bugfix in a sense? Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] IKVM+Rhino=JS for mono?
It occurred to me that it might be possible to run Rhino under IKVM to get a quick boost into a mature ECMAScript implementation for Mono. Presumably, with a couple of tweaks to ignore the cli. prefix that IKVM inserts for .NET classes, it would do most of what's required for the .NET platform's JavaScript. I have no time or knowledge to pursue this myself, but I'm throwing the idea out there in case anyone wants to run with it. It might be possible to get Rhino+IKVM to production quality quicker than the from-scratch ECMAScript implementation that's being worked on at the moment. Worst case, we end up with two high-quality ECMAScript implementations to choose between :) Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] IKVM+Rhino=JS for mono?
Carlos Alberto Cortez wrote: Hi: Currently I'm helping Cesar Lopez Nataren to port the Rhino Lexer and Parser stuff, and then finish the JScript compiler implementation. Maybe it would be a good idea to finish to port to C#, than trying to use them with IKVM, since you would have to run ikvm on top on mono, and then run rhino on top of ikvm, representing a big overhead. If you use ikvmc, the overhead isn't that huge and could be reduced further with a small amount of work (which would help other users of IKVM as well). A small amount of overhead for mapping certain method calls (not all) on java.lang.Object and java.lang.String is unavoidable, as is a larger amount of overhead when exceptions are used, but exceptions are slow anyway and shouldn't be used in performance-critical parts of the code. The rest of the current overhead, as far as I know, is memory overhead caused by the need to have all of IKVM.GNU.Classpath.dll and all of IKVM.Runtime.dll loaded even when not all of it is in use. Classpath.dll could be split up by Java package so that you might only need to load the java.lang equivalents and maybe java.io. IKVM.Runtime.dll could have the JIT compiler split out because you don't need it when you're in static mode, unless you're doing dynamic loading of classes. I believe that the IKVM author plans on doing these things anyway, eventually, although they won't make Mono 1.0. It occurs to me that perhaps Rhino *does* do dynamic loading of classes and so that overhead would be significant. Still, I imagine that adding a CIL-generator as an alternative to the Java bytecode generator would be less work than porting the entire code to C# - and you could benefit from ongoing improvements to Rhino in the future. (Of course, you can use System.Reflection.Emit directly from Java code to make the CIL generator simpler to write) Obviously I can't tell you what to do, and like I said, I don't have time to work on this myself. I can only suggest what I think would save you some work... Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] C# plugin for eclipse
Erik Dasque wrote: intellisense/autocompletion is of course big but requires some introspection into the project and mono assemblies which is tougher to do with Eclipse that it is with monodevelop (which runs within a mono vm) and 1-4 should be done before it is attempted. If you run Eclipse inside IKVM it could load mcs.exe as an assembly and call into it directly to do the C# parsing. (ie, it *could* run within a Mono VM). I don't know whether we want to limit intellisense to only working if Eclipse is running inside IKVM, though. A bridge to the CLR from a generic JVM using only JNI but providing the same capabilities as IKVM, compatibly, would be the holy grail ;) (With regard to your main point, I don't think that anyone would dispute that getting the basic, minimum features working is a higher priority than the advanced flashy ones, but the question originally asked sounded a lot like what features do you want?. It's unsurprising that the answers focused on advanced features. I want it to *work* is kind of implied...) Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Preview packages for windows?
Gonzalo Paniagua Javier wrote: Next week I'll prepare a new installer with teh stuff in CVS and may be a new separate one for 2.0 preview compiler and assemblies. Do you still plan on producing the 2.0 preview compiler installer for Windows? If not, is there a way to install it manually? Presumably I would need gmcs.exe and a bunch of 2.0-profile dlls in my GAC - perhaps I could download all those things separately and gacutil them into place? Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] New web site up
Erik Dasque wrote: Hi all, As some of you may know, we're moving to a new site (the old one will be phased out eventually) and to new content and design. We'd love feedback on it before we push it out officially : As others have already said, this looks great :) Tiny nits: Most of the links on the site have visual feedback on hover (the leftnav, the news on the right, links in the main body) but the nav at the top doesn't. Also, it would be nice if in the 'Mono Project News' section you could click on a title, rather than having to hunt for the link inside the teaser text. Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Portably getting the keyboard state in Windows.Forms?
I'm writing a simple WinForms based game, and obviously using normal keydown/keyup/keypress listeners has some limitations in that scenario (because you want to be able to be aware that several non-modifier keys are pressed at once, eg both up *and* left). An article at http://www.syncfusion.com/FAQ/WinForms/FAQ_c46c.asp appears to answer this question partially, but the answer is to use P/Invoke of the GetKeyState function which is obviously not portable to Mono (from reading around a little bit, it sounds like I might want GetAsyncKeyState instead, but the same problem applies, of course). Is there a way to do this on Mono's WinForms at all? If so, is it portable to the MS .NET framework too? Thanks, Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Preview packages for windows?
Are there any plans for a windows installer that includes the preview packages, in particular gmcs and S.C.Generic? I've been drooling over the possibility of generic C# ever since I learnt about its features, and Microsoft seem singularly unwilling to produce a public release to satisfy my cravings ;) (If it's in the current installer, I couldn't find it - there doesn't seem to be any option for a 'custom install' or anything) Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Managed disassembler?
I'm looking for any kind of C# API for reading IL assemblies and introspecting on the contents of the methods. I don't need to go as far as getting all the information to produce dissassembled ilasm source code, but that's a superset of my needs: if someone had produced a managed disassembler, it would be more than enough for what I want to achieve. What I actually need is just to identify all method calls and references to types outside the assembly I'm loading. At first I thought I'd just take the necessary parts of monodis, but it turns out that's unmanaged C code. Is that just historical accident? PEAPI appears to be write-only as does S.R.Emit. There is mention of a PERWAPI read-write API on the PEAPI homepage, but googling for that only gives PEAPI and a couple of blog entries. One of the blog entries mentions AbsIL, with a 404 link to research.microsoft.com (so unlikely to be Free Software). Anyone have any other suggestions? Thanks, Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Implementing sandbox security using Mono
In NRobot, I have a pressing need for a security architecture: something that prevents robots from running with full privileges, since in the general case you can't trust the source of all the robots you might want to compete against. Basically, I want to provide the same level of security that Applets have in Java - a sandbox in which they can run, without being able to do anything dangerous like access the filesystem or network (except, perhaps, in limited ways that I specify). I have two problems when it comes to implementing this: Firstly, I really don't understand the .NET security architecture well enough to know how it's supposed to be tackled, and secondly, I don't know how much of the necessary stuff is implemented in Mono. My understanding so far is that either Code Access Security (CAS) or AppDomains, or both, are what I need. But I don't understand either of them well enough to know how they help me. I'm pretty sure I need AppDomains anyway because I want to be able to unload, or at least forget about, loaded robot DLLs in order to start a new game with an updated copy, without closing the host process. But I'm not sure whether AppDomains by themselves give me the sandbox security I'm after, or how I'm supposed to talk to the loaded DLLs across an AppDomain boundary. I've also heard that CAS isn't implemented (fully? at all?) in Mono, and that currently Mono has problems with AppDomain unloading. But I don't know what the current state is, how badly they affect my needs, or how soon they are expected to be fully complete. The Mono roadmap paints a depressing picture of Mono's CAS capabilities - is that still true? And are there any workarounds? Thanks for any advice you can give me, Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Implementing sandbox security using Mono
Sebastien Pouliot wrote: I normally suggest the .NET Framework Security book from LaMacchia et al. but MSDN also has many articles on the subject. Can you suggest an order that I should start reading in? I can normally pick stuff up through web reading fairly quickly, but I have trouble when I'm faced with a large domain without any idea where to start. I keep finding snippets of information but no good overview of how all the pieces fit together or what parts are required understanding before learning others. For example, I've no idea how CAS and AppDomains interact, if they do at all, and what role AppDomains play in security, if any. I feel like I'm trying to understand a picture by looking at it through a microscope - I can understand some little bits of the picture, but I still have little idea how it works overall. One of the linked articles from Benjamin Wooton's site that you mentioned below gave the best overview of CAS I've yet found, though. You probably already know about it, but if not, you may be interested to look at gotdotnet's Terrarium. http://www.windowsforms.net/default.aspx?tabIndex=6tabId=42 Well that's depressing. I hate when I find that someone else has done something much more advanced than something I'm working on... Still, (1) it's not free software, AFAICT, and (2) it seems like a very different model of competition. Plus feature-parity with Terrarium may be a useful goal to work towards in future versions of NRobot, I guess :) Sadly not enough. :( CAS isn't on the roapmap for Mono 1.0. My hope is to have something working (experimental, not secure) for the 1.2 release. Non-secure security wouldn't help much :( So I'm looking at 1.4 at the earliest, which is scheduled for mid-2005, for something truly secure, right? Benjamin Wootton is working on some important parts of CAS for his university project. http://www.benjaminwootton.co.uk/project/ Is this work going back into Mono? I couldn't tell from his site whether it was or not, or whether his work so far could be downloaded in any form other than diffs. Another possibility is a (automated) audit where you use reflection to ensure that no illegal operations (reflection, p/invokes, ...) are done before actually running the assembly. A simple implementation shouldn't be hard but would be far more limiting than what CAS can offer (at least if you want it secure). I'd have to check all attempts to call methods in any other assembly, though, and specifically choose which methods to enable from some configuration file. That would be pretty tough and by default I'd have to be pretty restrictive (nothing in System.Xml in case it tries to use WriteXml, etc). Still, it might be worth it if otherwise I'm faced with being insecure until 2005. Contributions welcomed ;-) Unfortunately I think that since I can't yet even figure out how to *use* this stuff, I'm a *long* way from being able to *implement* it :( Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Use of mailing list for announcements
Is it considered acceptable to post announcements of projects that are developed for mono on this list? Thanks, Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] ANN: NRobot 0.12 released
to begin. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono 0.31 segfault
Gonzalo Paniagua Javier wrote: It worked for me using --with-nptl=no --with-sigaltstack=no and kernel 2.4.25, but when I turned sigaltstack on, it failed as it fails for Stuart. The backtrace took me to code in libpthread and libgcc :-? Should I file a bug report with the debian maintainers about this? Or are they already reading this list? If I do file the bug report I'd like to summarize the information from the replies I received here, but I'm not sure what the conclusion is. Should the debian maintainers just include --with-sigaltstack=no, or do they need to also do --with-nptl=no to fix the bug? Thanks, Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono 0.31 segfault
Gonzalo Paniagua Javier wrote: He has to pass --with-sigaltstack=no --with-nptl=no if he's running a 2.6.x kernel in the machine that builds the packages. For those following along at home, this is now Debian Bug#243940. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=243940 Thanks, Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono 0.31 segfault
Running mono 0.31 from debian packages. The following simple test
program crashes mono with a segmentation fault:
public class MainClass {
public static void Main() {
object o = null;
Console.WriteLine(o.ToString());
}
}
I'd expect to get a NullReferenceException, of course.
One thing I noticed is this:
[EMAIL PROTECTED]:~$ mono --version
Mono JIT compiler version 0.31, (C) 2002-2004 Novell, Inc and
Contributors. www.go-mono.com
TLS: NPTL
GC:Included Boehm (with typed GC)
Globalization: none
[EMAIL PROTECTED]:~$ uname -a
Linux rainbow 2.2.17 #1 Thu Sep 14 13:18:09 EDT 2000 i686 GNU/Linux
The thing that stands out is the mention of NPTL. I think that on a
2.2.17 kernel I'm a long way from having NPTL support, unless it has a
fallback mode for older kernels.
Any thoughts?
Thanks,
Stuart (thinking about upgrading his kernel now...).
--
Stuart Ballard, Senior Web Developer
NetReach, Inc.
(215) 283-2300, ext. 126
http://www.netreach.com/
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: The Mauve unicode testcase and VM performance
Mark Wielaard wrote: You then still need the original exe for execution. The man page says about --aot: This option is used to precompile the CIL code in the specified assembly to native code. The generated code is stored in a file with the extension .so. This file will be automatically picked up by the runtime when the assembly is executed. This pre-compiles the methods, but the original assembly is still required to execute as this one contains the metadata and exception information which is not availble on the generated file. When precompiling code, you might want to compile with all optimizations (-O=all). Pre-compiled code is position inde- pendent code. load test overhead total Old: 1703 1292 3174 6169 New: 2944 1337 624 4905 Oat: 2944 1312 626 4882 So that doesn't seem to help in this case (or I did something wrong and it isn't picking up the mauve.exe.so after all). Did you try --aot'ing classpath.dll, IK.VM.NET.dll etc? I'd imagine that this particular microbenchmark spends a large proportion of its time inside classpath itself, suggesting that merely JITing the mauve part wouldn't help much. The man page you cited says that --aot precompiles the CIL code in the specified assembly. In .NET terminology, each dll or exe is a separate assembly. So I take that doc to imply that you need to separately AOT each dll as well as the exe itself. Interestingly, my installation of mono (from debian sid) doesn't even come with its own libraries AOT'd. I'd have thought that you'd get the best performance by AOT'ing *all* the libraries, including (and especially) the low-level platform ones such as System.dll and System.Xml.dll. CC'ing mono-list for any insight they might have into why (or why not) you might want to AOT the platform libraries... Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: [Mono-devel-list] C#isms in CodeDom core and other bugs - willing to fix
methods are named according to the standard naming convention and that [IndexerNameAttribute] wasn't used, because you have no way to tell. I'm told that even Microsoft's J# CodeDom generates incorrect code for the equivalent of myString[0] - it produces myString.get_Item(0) instead of myString.get_Chars(0). Finally, if your language has special treatment for certain classes (such as object or string) you can't handle that properly in CodeDom because there's no way to specify what Type you expect a CodeExpression to evaluate to. Absolutely. Glad to see you on board! I have a preliminary patch but I haven't tested it yet. I'll send it as soon as I do. Let me have a guess. Starts with 'J' and ends with 'ava' Good guess! :) Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] C#isms in CodeDom core and other bugs - willing to fix
[Originally posted to mono-list only; I got no response there. Keeping mono-list CC'd for thread-continuity, and because I'm not subscribed to mono-devel] I'm working on a CodeDom provider for a language that happens to look an awful lot like C#[1]. I thought it would be sufficient to start with Mono's CSharpCodeGenerator and go through it in detail, changing each construct to the equivalent in Ja^H^Hthe language I'm dealing with. This turns out to actually not be sufficient, though, because in several places CSharpCodeGenerator simply inherits an implementation from CodeGenerator which gives C#-specific behavior. Examples of this behavior are OutputTypeAttributes() and OutputMemberAccessModifier(), both of which are non-abstract in CodeGenerator and give pure C# output. This seems like an incredibly bad idea that defeats the purpose of having a language-independent API. I recognize that there are other good reasons why the CodeDom API sucks (I've already compiled a half dozen items in my wishlist of API features) but this seems to me like implementation suckage, not API suckage. It may be that this behavior is required to be fully compatible with a sucky MS implementation. If that's the case, there should be a prominent comment in the source of CodeGenerator explaining this. I'd also be tempted to duplicate the methods in CSharpCodeGenerator even though that's technically redundant, because it's closer to the correct separation of concerns between the two classes. If not, there should at least be a large comment at the top of CSharpCodeGenerator documenting which methods it inherits from CodeGenerator that are C#-specific. If I produce a patch to this effect, would it be accepted? Which approach should I take? I've also encountered what I believe are some other bugs in CSharpCodeProvider: - GenerateLabeledStatement is missing a : emitted after the label name, if I remember C# label syntax correctly. - GenerateProperty attempts to determine whether to generate an indexer or not based on whether the name is Item. This is incorrect because Item is a perfectly valid name for a property, and an indexer can have a name other than Item. Instead, it should use the list of parameters to the property: If that list is non-empty, it's an indexer. In that case, if the name *isn't* Item, it should additionally generate an IndexerNameAttribute. If I'm correct about these behaviors being bugs, should I produce patches for them? By the way, on a completely unrelated note, is there a reason why Jeroen Frijters' excellent IKVM blog (http://www.ikvm.net/) isn't part of Monologue? The mono roadmap describes IKVM as a goal for Mono 1.0, so I'd definitely think that it's development weblog qualifies as Mono related. Plus it's an excellent project that deserves more publicity than it gets, and Monologue is one small way to raise its profile, at least among Mono developers and users. Thanks, Stuart. [1] Can you imagine what that language could *possibly* be? ;) -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] CodeDom testcases/examples
Does anyone know of any simple language-independent CodeDom testcases/examples that could be used to generate some code that a human could then look at and verify? Ideally some examples that start off doing really simple stuff (I guess defining an empty class in a given namespace would qualify), with gradually increasing complexity to eventually cover all the language features that CodeDom can express... If not, could the existing tests in mcs/class/System/Tests/Microsoft.* be used as the basis for starting something like that? Do other people agree that it would be a nice thing to have? As a later feature, I suppose you could test the compilation aspects of CodeDom by compiling the results for each language and using reflection to examine and invoke them. That would give a really nice testsuite for any new language that wants to be CodeDom-capable, and could probably supercede some of the tests in mcs/class/System/Tests altogether (just auto-enumerate all the languages defined in machine.config and run this testsuite against each one). Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] bootstrapping mono with free software?
Noa Resare wrote: Trying to compile mono's mscorlib.dll however is a completely different experience. Exceptions from Mono.CSharp.RootContext.BootCorlib_PopulateCoreTypes decendands all over the place. How about running the newly compiled mcs.exe against PNET's corlib to compile Mono's? Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Compiling egg-chicken libraries
Jaroslaw Kowalski wrote: This is a killer problem. The actual code from Objects is here. I don't want to pollute it with any unnecessary patterns. No factories, adaptors, facades. BTW. Some stubs return instances of business objects. This doesn't look possible in your case. Well, they can return instances of business objects, but not in a statically-typed way. Have you looked into the Whidbey partial classes feature? I don't know if partial classes can be defined across multiple assemblies, but if so, it would solve your problem. nrdo's way of doing this is less elegant, btw: It requires you to use C# and put your C# code into the .dfn file, rather than a separate C# file. And then your C# is compiled as part of the Generated Files assembly and isn't able to access anything in your main application assembly. A good solution to this problem might help nrdo too. Unfortunately, IObjectCreator is the best I can come up with. Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] A Problem with XSP
Gonzalo Paniagua Javier wrote: You can also use the MONO_SHARED_DIR (man mono) environment variable so that your application has its own .wapi directory not shared with any other. Wouldn't it be nice if the default location of .wapi was /tmp/.wapi-username? I'm pretty sure that the this could be deleted at any time semantics of /tmp don't apply to files that are in use at the time, or it would be impossible to *ever* use /tmp safely. Using /tmp as the default location and auto-deleting if the sanity check fails would fix two very frequently reported problems with Mono and XSP. Is there ever any reason why you would even want .wapi to persist when *no* mono processes are running? Is it even needed at all most of the time? What are the .NET semantics that it exists to enable? Could it be created on-demand when one of those features is used, instead of every time mono is run? Or just have all mono processes completely independent (no .wapi directory at all) by default unless you explicitly specify a parameter to turn on the sharing? Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Docs as plain HTML
Is there any way to get (a subset of) the docs from http://www.go-mono.com:8080/ as plain HTML that could be saved for offline use? Thanks, Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Docs as plain HTML
Met @ Uber wrote: You could use monodoc (check downloads). The computer I need to use these on can't support running a C# app (heck, it's a 486 with 4Mb ram and nonfunctioning g and h keys, I'm lucky it can support a text mode console with a remapped keyboard). It can just barely support HTML, by using Lynx... So even if I can use monodoc, that only helps if monodoc can spew out static HTML, which I don't think it can... can it? (I can't find any monodoc docs - how ironic ;) ) Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] XSP and ~/ resolution
I'm using the debian packages of the January 14th mono snapshot. Using XSP directly because current libapache-mod-mono is not yet packaged. There appears to be a problem with resolution of application relative URLS - ie, urls that start with ~/. In XSP, the ~/ seems to be ignored entirely, and ~/Foo/Bar.ascx is interpreted exactly as if it were Foo/Bar.ascx. The specific case that I'm encountering is when the URL is used as the Src attribute of a @Register directive - I can't confirm or deny whether the problem occurs for other uses of ~/, but it seems highly possible that it would. Around 0.28 I was able to get libapache-mod-mono working and did not have this problem, so it's either a regression or specific to standalone XSP. Even with that old libapache-mod-mono I had some problems with these URLs: sometimes the ~ would get passed through to the browser rather than being interpreted server-side. I intended to upgrade to a more recent version to test whether this problem was fixed before doing specific testing of when it happened, but I think it was either in the NavigateUrl attribute of asp:HyperLink or in the argument to Response.Redirect(). If I remember rightly, IBuySpy portal makes heavy use of these kind of URLs, and I'd be surprised if it works out of the box with this bug. Anyone know if this area of code has been changed since January 14th? Could this be fixed in 0.30? Thanks, Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] NullRefException compiling with mcs
Miguel de Icaza wrote: I see where the program is crashing, but am still going to need you to put prints around that area, so we understand what is happening and what is going wrong. Can you suggest some things that I should print that will help me to determine what types are being compiled that result in the crash? I'm afraid that the code in interface.cs is somewhat over my head - in particular, I have no idea what the role of a TypeBuilder is, which is presumably fairly fundamental to diagnosing this problem. My first attempt at isolating a testcase failed, but in a possibly interesting way. Am I right that interface.cs suggests that the problem has something to do with an interface (as opposed to a class or some other kind of Type)? There's only one interface declared in the whole of my project (although I do use and implement various interfaces that are declared in referenced DLLs), so I though okay, easy starting point: if I compile the smallest possible set of files that includes that interface declaration, I should get the error. Turns out I don't - it builds fine. You should use this information to produce a small test sample. It is probably something related to recursive definitions of the types, but I need the small test case. I'll keep trying, but if you can suggest some things that I should print out that will help me identify which types are in play at the time the error occurs, it will speed me up significantly. Thanks for all your help so far, Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] [TestCase] NullRefException compiling with mcs
Actually I found it and produced a very simple testcase - turned out I
needed to include at least one class that *implemented* the interface as
well as the one that declared it. I've attached the files but I can also
include them here in their entirety:
InnerInterface.cs:
public class Outer {
public interface Inner {
}
}
Impl.cs:
public class Impl : Outer.Inner {
}
Compiling these files in the order given, with mcs InnerInterface.cs
Impl.cs, works fine.
Compiling them in the opposite order, with mcs Impl.cs
InnerInterface.cs, gives the error.
Incidentally, if Inner is a class rather than an interface, a similar
bug manifests. You don't get a crash, but you get an erroneous claim
that the class definition of Inner is circular. Again, this only happens
if Impl.cs is specified first on the commandline.
The fact that the Class case is caught by a circularity handler, but the
Interface case is not, suggests to my untrained eye that there may also
be a problem in catching circularity problems with interfaces. I haven't
attempted to verify that, because I don't have sufficient depth of
understanding to be sure that I'm creating a circularity in the right
form that it would be caught by the same codepath, but it might be worth
looking into why the behavior of Classes versus Interfaces differs in
this way.
Stuart.
--
Stuart Ballard, Senior Web Developer
NetReach, Inc.
(215) 283-2300, ext. 126
http://www.netreach.com/
public class Impl : Outer.Inner {
}
public class Outer {
public interface Inner {
}
}
Re: [Mono-list] NullRefException compiling with mcs
Miguel de Icaza wrote: It is hard to tell from the stack trace that you provided, and that version of the compiler is fairly old, we have fixed roughly a hundred bugs since that release. It would be useful if you could try with a new compiler, or isolate a sample test case. The 20040111 snapshot has the same problem (stack trace below, I'm not sure whether it's identical but it's similar), and since that's the latest debian package to have been created, it's the latest that's easy for me to test. I'm pretty sure this is a regression - an older version of mcs was able to compile this project without problems. Although it's true that the project itself has changed in that time too, none of the changes seem particularly likely to break the compiler. Do you have any suggestions as to how I might go about narrowing down the problem? Are there any particular language features that are suggested or ruled out by the stack trace? I'll have a go myself at tracking it down as well, but I'm dealing with a compilation involving 102 generated source files (created by nrdo, http://savannah.nongnu.org/projects/nrdo) that range in size from 5K to 50K, so it's hard to know where to begin. There are only a few of the files that are truly standalone, but when I tried compiling one of those few by itself, the error didn't occur. I can send you (or someone else) the full source in private email, but I appreciate that that's not much use... Thanks in advance for any tips, Stuart. Unhandled Exception: System.NullReferenceException: A null value was found where an object instance was required in 0x0020c Mono.CSharp.Interface:DefineType () in 0x00226 Mono.CSharp.DeclSpace:LookupInterfaceOrClass (string,string,bool)in 0x00285 Mono.CSharp.DeclSpace:FindType (Mono.CSharp.Location,string) in 0x0011a Mono.CSharp.MemberAccess:ResolveAsTypeStep (Mono.CSharp.EmitContext) in 0x00011 Mono.CSharp.Expression:ResolveAsTypeTerminal (Mono.CSharp.EmitContext) in 0x0005b Mono.CSharp.DeclSpace:ResolveTypeExpr (Mono.CSharp.Expression,bool,Mono.CSharp.Location) in 0x004e6 Mono.CSharp.TypeContainer:GetClassBases (bool,Mono.CSharp.TypeExpr,bool) in 0x0022e Mono.CSharp.TypeContainer:DefineType () in 0x00305 Mono.CSharp.RootContext:ResolveTree () in 0x00a87 Mono.CSharp.Driver:MainDriver (string[]) in 0x0001a Mono.CSharp.Driver:Main (string[]) -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Debian Package + LibApache Mod_mono
Pablo Fischer wrote: Hi! Fixed and uploaded the new version of the libapache_mod_mono package, has the same name, in the same dir: http://debian2.pablo.com.mx/unstable/ http://debian2.pablo.com.mx/unstable/libapache-mod-mono_0.5-1_i386.deb Any bugs, please mail me :) apt isn't picking up the new version, even after doing: apt-get --purge remove libapache-mod-mono rm /var/cache/apt/archives/libapache-mod-mono* apt-get install libapache-mod-mono mono-xsp I had to manually download from the link above and dpkg -i the result... Thanks for the fixed package, though! It installed without problems, although I haven't actually tried running anything with it yet. Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Debian Package + LibApache Mod_mono
Pablo Fischer wrote:
Any bugs, please mail me :)
The debian packages at present seem to not include an /etc/init.d script
for starting mod-mono-server.exe, so I've tried writing one myself (via
shameless copy-n-pasting from another one on my system), and I'm not
having much luck so far. Maybe I shouldn't be trying to run the xsp
process as www-data, but I can't think of any better user to use. (btw,
I did make sure that www-data could read and write the root folder I
specified, /home/sballard/unix-ivory - obviously, that's not a good
location to use in general, but I wanted to get something working before
picking the perfect location).
I get the following error:
Starting XSP: mod-mono-serverListening on: /tmp/mod_mono_server
Root directory: /home/sballard/unix-ivory
Unhandled Exception: System.UnauthorizedAccessException: Access to the
path is denied.
Server stack trace:
in 0x00226 System.IO.File:Delete (string)
in 0x000af Mono.ASPNET.XSPApplicationHost:Start ()
in (unmanaged) /usr/lib/libmono.so.0 [0x40056adc]
in (unmanaged) /usr/lib/libmono.so.0(mono_runtime_invoke+0x35) [0x400a8dc2]
in (unmanaged) /usr/lib/libmono.so.0(mono_runtime_invoke_array+0x21b)
[0x400a9d35]
in (unmanaged) /usr/lib/libmono.so.0 [0x400b0791]
in 0x00193
System.Runtime.Remoting.RemotingServices:InternalExecuteMessage
(System.MarshalByRefObject,System.Runtime.Remoting.Messaging.IMethodCallMessage)
Exception rethrown at [0]:
in 0x001da System.Runtime.Remoting.Proxies.RealProxy:PrivateInvoke
(System.Runtime.Remoting.Proxies.RealProxy,System.Runtime.Remoting.Messaging.IMessage,System.Exception,object[])
in (unmanaged) (wrapper remoting-invoke)
Mono.ASPNET.XSPApplicationHost:Start ()
in 0x4 (wrapper remoting-invoke)
Mono.ASPNET.XSPApplicationHost:Start ()
in 0x0002f (wrapper remoting-invoke-with-check)
Mono.ASPNET.XSPApplicationHost:Start ()
in 0x00344 Mono.ASPNET.Server:Main (string[])
.
I've attached the non-working init.d script in case anyone's interested.
I had to create a /var/www/.wapi directory that was chowned to www-data
in order to get past another error caused by the fact that www-data
doesn't have write permissions to its own home directory. Can someone
explain why xsp doesn't use /tmp for these files?
Thanks in advance for any suggestions,
Stuart.
--
Stuart Ballard, Senior Web Developer
NetReach, Inc.
(215) 283-2300, ext. 126
http://www.netreach.com/
#! /bin/sh
PATH=/sbin:/bin
test -f /usr/bin/mod-mono-server.exe || exit 0
case $1 in
start)
echo -n Starting XSP: mod-mono-server
start-stop-daemon --start --quiet --chuid www-data --user www-data
--group www-data --chdir /home/sballard/unix-ivory --exec /usr/bin/mod-mono-server.exe
-- --applications /:. --nonstop
echo .
;;
stop)
echo -n Stopping XSP: mod-mono-server
start-stop-daemon --stop --quiet --chuid www-data --user www-data
--group www-data --exec /usr/bin/mod-mono-server.exe
echo .
;;
restart|force-reload)
echo -n Restarting NTP server: ntpd...
start-stop-daemon --stop --quiet --chuid www-data --user www-data
--group www-data --exec /usr/bin/mod-mono-server.exe
sleep 2
start-stop-daemon --start --quiet --chuid www-data --user www-data
--group www-data --chdir /home/sballard/unix-ivory --exec /usr/bin/mod-mono-server.exe
-- --applications /:. --nonstop
echo done.
;;
*)
echo Usage: /etc/init.d/local-xsp {start|stop|restart|force-reload}
exit 1
;;
esac
exit 0
Re: [Mono-list] New Year, New Debian Packages
Pablo Fischer wrote: * Build two versions: the snapshots (the -cvs prefix will be renamed to snapshot) and the 'official' packages (.26, .28, .29). * When I released the last packages (debian2.pablo.com.mx) I needed to edit the debian/rules (the file that do must part of the build package process) and found problems with the libs: I cannot be compiling two versions (official and cvs) in the same computer cause if some file of the official package get in contact with a cvs version that will be painfull. How about installing into two separate locations (/usr/lib/mono-release and /usr/lib/mono-snapshot, for example) and using /etc/alternatives to point /usr/lib/mono to the desired location? Then the debian/rules could avoid use of /usr/lib/mono altogether and just point directly to the desired version. Wouldn't the current situation cause problems with the autobuilders if mono ever makes it into debian-proper? Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] New Year, New Debian Packages
Michael Ott wrote: Setting up libapache-mod-mono (0.5-1) ... dpkg: error processing libapache-mod-mono (--configure): subprocess post-installation script returned error exit status 10 Errors were encountered while processing: libapache-mod-mono E: Sub-process /usr/bin/dpkg returned an error code (1) I get the same error on my mixed testing/unstable system - the system used to be several months out of date, but it still does the same thing after a full dist-upgrade. By putting a bunch of echo statements into the postinst script, I was able to identify the source of the error as the db_version 2.0 line - it is this, apparently, which aborts with exit code 10 and no error messages. There's no man page for the db_version command. I took a guess that this line was somehow related to debconf and upgraded to unstable's version of debconf, but it made no difference. Pablo (or anyone), any suggestions? Thanks, Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Status of Mono and ASP.NET on Solaris
I work for a company that does ASP.NET development and we have a potential customer who may insist on a solution using Solaris as the OS (I don't know whether they would insist on sparc or x86 in particular). Since we would be selling them an ASP.NET application (using a lot of ASP.NET code that we've already written), this would mean necessarily using Mono on the production system. I've already verified that it's feasible to make the changes to our code to run on Mono in general in an MS-free environment (I've tested on Linux/x86/Postgres). What I'm not sure about is the status of Mono on Solaris (sparc and x86, since I don't know which one applies). Is there a port? Is it up to the same level of functionality and stability as the Linux/x86 version? Also, I'm curious as to what opinion is regarding the use of Mono on production websites. Does the Mono project officially recommend (for or against) this at this point - on Solaris in particular? Do Ximian offer any support options that might be useful in selling this idea to the suits? Thanks, Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] New Year, New Debian Packages
Pablo Fischer wrote: Also I released the mod_mono and xsp packages cause I found them very easy, also, if someone tries to help with one of those packages that will be very helpfull. Any chance of libapache-mod-mono-cvs? I imagine that would be easy because it could be based on the libapache-mod-mono metadata? Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Any hosting providers that offer Mono?
Does anyone know of any hosting providers that offer Mono-based ASP.NET hosting? I'm looking for cheap but reliable hosting with Mono and PostgreSQL, if such a thing exists. Stuart. -- Stuart Ballard, Senior Web Developer FASTNET - Web Solutions (215) 283-2300, ext. 126 www.fast.net ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] The prove that they can all live together
Akhilesh wrote: Hi Gaurav, By enter I am referring to the key on the keyboard, not a button on the HTML page. When you press the enter key while the focus is on the textbox, the page is re-loaded but no re-calculation is done. Actually I've encountered this annoying behavior in ASP.NET in general, not just on Mono. It also appears to be browser-dependent. It appears that on a form with a single submit button, pressing 'enter' in a textbox will submit the form on all browsers. But there are discrepencies between browsers on whether the button's name and value get passed as part of the submission (as if the button had been pressed) or not (as if the submission happened without any button being pressed). ASP.NET's button.Click events, then, don't pick up the submission if it happens in one of the latter kind of browsers. I can't remember which browsers exhibit which behaviors, but I tend to feel that the latter kind are in the wrong. That doesn't change the need to accommodate them in practice, of course. And doing so in the general case is really hard - I believe we eventually managed it with a javascript hack that caught the enter keypress and called button.click(). If Mono's ASP.NET were to recognize this scenario and generate code to handle it automatically, that would be a (minor, but) cool benefit to offer over MS's implementation. Stuart. -- Stuart Ballard, Senior Web Developer FASTNET - Web Solutions (215) 283-2300, ext. 126 www.fast.net ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
