Re: [Mono-dev] idea summary: Swing in Mono?...
Just pitching in to say that QT 4.5 has gained OpenGL support (http://labs.trolltech.com/blogs/2008/10/22/so-long-and-thanks-for-the-blit/). They have also demonstrated QT rendering directly onto an OpenGL surface. My personal opinion (as a developer) is that the last thing we need is yet another UI API. What you describe amounts more or less to WPF (so why not just implement WPF in Mono?) Besides, as Chris said, Mono already supports Moonlight so why not use that directly? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] question about Boo and monolipse
Hi, I've watched the screencast about Boo and monolipse in monologue: http://blogs.codehaus.org/people/bamboo/archives/001751_experience_boojay_with_monolipse.html I've seen a debugger running on Eclipse/OSX... Is it possible to debug mono code on MacOS with monolipse pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] question about Boo and monolipse
On 02/08/2009 07:22 AM, psant...@codicesoftware.com wrote: Hi, I've watched the screencast about Boo and monolipse in monologue: http://blogs.codehaus.org/people/bamboo/archives/001751_experience_boojay_with_monolipse.html I've seen a debugger running on Eclipse/OSX... Is it possible to debug mono code on MacOS with monolipse I'm pretty sure what you saw was Boojay (Boo running on the JVM) being debugged. So not Mono at all, really (if I understood correctly). Sandy ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] idea summary: Swing in Mono?...
- Original Message - From: Stefanos A. stapos...@gmail.com To: BGB cr88...@hotmail.com; Michael Hutchinson m.j.hutchin...@gmail.com Cc: mono-devel-list@lists.ximian.com Sent: Sunday, February 08, 2009 6:49 PM Subject: Re: [Mono-dev] idea summary: Swing in Mono?... Just pitching in to say that QT 4.5 has gained OpenGL support (http://labs.trolltech.com/blogs/2008/10/22/so-long-and-thanks-for-the-blit/). They have also demonstrated QT rendering directly onto an OpenGL surface. My personal opinion (as a developer) is that the last thing we need is yet another UI API. What you describe amounts more or less to WPF (so why not just implement WPF in Mono?) Besides, as Chris said, Mono already supports Moonlight so why not use that directly? well, WPF works, only that WPF does have risk of legal issues... as for the last part, I was describing my own existing GUI support (in my project), but I have no intention of trying to force it off on the Mono people... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] idea summary: Swing in Mono?...
err, I meant: cross VM, cross platform, cross ui framework toolkit of some kind On Sun, Feb 8, 2009 at 12:06 PM, Chris Toshok tos...@gmail.com wrote: Yeah, I really don't understand the aim of this thread. It seems you are trying to decide how to write a cross VM (of which you are *writing* a jvm and CIL vm?), cross platform, cross ui framework. Or at least that's what I've understood, anyway. Perhaps being a little more specific about things with us would help us understand exactly where you're going. On Sun, Feb 8, 2009 at 12:49 AM, Stefanos A. stapos...@gmail.com wrote: Just pitching in to say that QT 4.5 has gained OpenGL support (http://labs.trolltech.com/blogs/2008/10/22/so-long-and-thanks-for-the-blit/). They have also demonstrated QT rendering directly onto an OpenGL surface. My personal opinion (as a developer) is that the last thing we need is yet another UI API. What you describe amounts more or less to WPF (so why not just implement WPF in Mono?) Besides, as Chris said, Mono already supports Moonlight so why not use that directly? ___ 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] RootContext.cs
Hi, I am trying to find out what variables were contained in the c# file parsed by mcs. I am looking in RootContext.cs where the whole structure is created but I am unable to access the variables of the class. Any help appreciated. I don't know what information you need but type fields are stored in TypeContainer::Fields Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] idea summary: Swing in Mono?...
what legal risks? without specifics it's impossible to discount this claim, and if it's just the usual vague threat of software patents, you'll run into that regardless of the path you choose. On Sun, Feb 8, 2009 at 12:07 PM, BGB cr88...@hotmail.com wrote: - Original Message - From: Stefanos A. stapos...@gmail.com To: BGB cr88...@hotmail.com; Michael Hutchinson m.j.hutchin...@gmail.com Cc: mono-devel-list@lists.ximian.com Sent: Sunday, February 08, 2009 6:49 PM Subject: Re: [Mono-dev] idea summary: Swing in Mono?... Just pitching in to say that QT 4.5 has gained OpenGL support (http://labs.trolltech.com/blogs/2008/10/22/so-long-and-thanks-for-the-blit/). They have also demonstrated QT rendering directly onto an OpenGL surface. My personal opinion (as a developer) is that the last thing we need is yet another UI API. What you describe amounts more or less to WPF (so why not just implement WPF in Mono?) Besides, as Chris said, Mono already supports Moonlight so why not use that directly? well, WPF works, only that WPF does have risk of legal issues... as for the last part, I was describing my own existing GUI support (in my project), but I have no intention of trying to force it off on the Mono people... ___ 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] idea summary: Swing in Mono?...
- Original Message - From: Chris Toshok tos...@gmail.com To: BGB cr88...@hotmail.com Cc: Michael Hutchinson m.j.hutchin...@gmail.com; Stefanos A. stapos...@gmail.com; mono-devel-list@lists.ximian.com Sent: Monday, February 09, 2009 6:35 AM Subject: Re: [Mono-dev] idea summary: Swing in Mono?... what legal risks? without specifics it's impossible to discount this claim, and if it's just the usual vague threat of software patents, you'll run into that regardless of the path you choose. MS patents nearly everything, and without them clearly making it free for everyone (as they had done with CIL and C# via ECMA-334 and 335), I am not so inclined to mess with it... (this is actually for a long time I had not looked much into Mono...). so, my usual approach is if there is a risk of patents, I will usually look for something else which serves my purposes, or design something clean (and working hard to avoid any patented designs I am aware of...). luckily, for most things, the implementation can be made generic and a thin wrapper can be provided for any patented APIs, such that one can easily remove it if any cease and desist orders show up... (although, sadly, there are far too many SW patents to be aware of all of them, or when certain ones expire, ...). but, yes, to me upholding copyrights and patents is an issue much like that of maintaining clean and modular code. messy code is bad; interdependencies and/or external dependencies are bad; uncertain copyrights are bad; possible patent violations are bad; .. or such... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] idea summary: Swing in Mono?...
The only good response to that email is summarised pretty well by this blogpost. http://www.jprl.com/Blog/archive/development/mono/2009/Jan-19.html The only addition I'll make is to ask this question: Have you ever created/distributed a CD which contains a hyperlink? If so, you've just infringed a patent! http://www.techdirt.com/articles/20070417/112812.shtml If something so trivial can be patented, than I think it's safe enough to assume that if your application is more than 1000 LOC, you've unwittingly infringed on at least one patent. So if you really are worried about patents, then you really should not be a software developer. Alan. On Sun, Feb 8, 2009 at 8:45 PM, BGB cr88...@hotmail.com wrote: - Original Message - From: Chris Toshok tos...@gmail.com To: BGB cr88...@hotmail.com Cc: Michael Hutchinson m.j.hutchin...@gmail.com; Stefanos A. stapos...@gmail.com; mono-devel-list@lists.ximian.com Sent: Monday, February 09, 2009 6:35 AM Subject: Re: [Mono-dev] idea summary: Swing in Mono?... what legal risks? without specifics it's impossible to discount this claim, and if it's just the usual vague threat of software patents, you'll run into that regardless of the path you choose. MS patents nearly everything, and without them clearly making it free for everyone (as they had done with CIL and C# via ECMA-334 and 335), I am not so inclined to mess with it... (this is actually for a long time I had not looked much into Mono...). so, my usual approach is if there is a risk of patents, I will usually look for something else which serves my purposes, or design something clean (and working hard to avoid any patented designs I am aware of...). luckily, for most things, the implementation can be made generic and a thin wrapper can be provided for any patented APIs, such that one can easily remove it if any cease and desist orders show up... (although, sadly, there are far too many SW patents to be aware of all of them, or when certain ones expire, ...). but, yes, to me upholding copyrights and patents is an issue much like that of maintaining clean and modular code. messy code is bad; interdependencies and/or external dependencies are bad; uncertain copyrights are bad; possible patent violations are bad; .. or such... ___ 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] idea summary: Swing in Mono?...
- Original Message - From: Chris Toshok tos...@gmail.com To: Stefanos A. stapos...@gmail.com Cc: BGB cr88...@hotmail.com; Michael Hutchinson m.j.hutchin...@gmail.com; mono-devel-list@lists.ximian.com Sent: Monday, February 09, 2009 6:06 AM Subject: Re: [Mono-dev] idea summary: Swing in Mono?... Yeah, I really don't understand the aim of this thread. It seems you are trying to decide how to write a cross VM (of which you are *writing* a jvm and CIL vm?), cross platform, cross ui framework. Or at least that's what I've understood, anyway. Perhaps being a little more specific about things with us would help us understand exactly where you're going. well, I have my main project, which is basically around 300-400 kloc or so of misc code (a lot of 3D stuff, ...). and, my VM effort, which is about 250 kloc. now, my VM is a VM or sorts, but has a very different architecture from Mono... the partial reason is that my VM (subproject) started off originally as a script VM, which was then transformed into a dynamic C compiler, and which then has had ever more functionality added on... so, C code was compiled at runtime, and over time I added GC, dynamic typing support, an object system, ... the C remained, but all this additional stuff became APIs. internally, the C compiler produces code fairly similar to what might come out of GCC or similar, and at one point, I was benchmarking them and getting similar performance (although GCC had a clear speed advantage for floating-point scalar code, ...). most of the code is implemented in a more-or-less modular fashion (the idea of one area of code messing with or depending on structs/data/code/... belonging elsewhere is just distasteful...). and, more so, most APIs have a more or less defined API (many of which have been influenced in terms of design and conventions by the likes of OpenGL and POSIX, namely, the empasis being on abstraction). performance is also a concern, but as I see it not even performance should allow violation of modularity (although it may allow designing the API to allow as much performance as is reasonable). the compiler in general has components similar to those of a traditional compiler, and is more or less divided into independent modules along these lines. for example, my upper compiler produces an IR (I call RPNIL, and it sort of resembles Forth or PostScript hybridized with COBOL...), then my middle compiler produces ASM (in an NASM/Intel style syntax), and my assembler produces objects, and my linker links them (actually, the assembler and linker share the same library, and are not completely isolated in terms of their internals). the frontend of the compiler then orchestrates the process by sending input into one component, then taking the output from that component and feeding it into the next, ... the core of the C compiler remains, but is being gradually reworked so that it can handle JIT for both JBC and CIL (along with most of the rest of the framework). granted, both JBC and CIL are fairly similar at this level, but are a good deal different than what is needed for C. note that I decided to actually integrate most of the extended functionality directly into the existing compiler machinery, rather than more-or-less translating the JBC into something like if the code were written in C (AKA: bunches of hackery and API calls), because if the compiler supports all this natively this is cleaner and allows better performance. so, going forwards, I more or less just implemented a JVM on top of all this (as another module), but currently it is not yet complete: it does not handle exceptions and the JIT is not complete, but it does have an interpreter. CIL will likely come later than JBC, mostly because JBC is the one requiring less implementation work, and most of what would go into making JBC work would be easily adaptable to CIL. note that the compiler machinery does not directly accept JBC (or later, CIL) output, nor does it directly accept the specifics of these formats, more the JIT process (owned by the mini-VM) converts the JBC or CIL into my compilers' IR, which then goes through all the machinery as before (so, the internal changes to the compiler are more in terms of adding capabilities to the IR). now, elsewhere in the project, there is a bunch of 3D stuff, and this is what I use the compiler framework mostly as a big elaborate scripting engine. now, as I see it, a GUI framework runs on top of a VM, and stuff running on top of a VM should not depend on the internals of the VM on which it runs (if possible). but, as is, I have some GUI code, but it is written in C, and is part of the 3D engine's GL-related utility functions. I lumped together all the basic drawing stuff (text rendering, GUI, image/texture loading/saving, ...) into a single library. then, most of the purely 3D-engine specific stuff (model rendering, 3D animation, scene graph,
Re: [Mono-dev] idea summary: Swing in Mono?...
well, I am not THAT worried/fussy, but it is better to steer clear of known issues, and if there is an unintended patent issue, people are far less likely to notice if it is somewhere unrelated to the context of the original claim... - Original Message - From: Alan McGovern To: BGB Cc: Chris Toshok ; mono-devel-list@lists.ximian.com Sent: Monday, February 09, 2009 6:56 AM Subject: Re: [Mono-dev] idea summary: Swing in Mono?... The only good response to that email is summarised pretty well by this blogpost. http://www.jprl.com/Blog/archive/development/mono/2009/Jan-19.html The only addition I'll make is to ask this question: Have you ever created/distributed a CD which contains a hyperlink? If so, you've just infringed a patent! http://www.techdirt.com/articles/20070417/112812.shtml If something so trivial can be patented, than I think it's safe enough to assume that if your application is more than 1000 LOC, you've unwittingly infringed on at least one patent. So if you really are worried about patents, then you really should not be a software developer. Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Runtime.Remoting unit test hangs
On Sat, 2009-02-07 at 20:48 +0100, Zoltan Varga wrote: Hi, Attached a smaller testcase which exhibits the second kind of hang. Zoltan This is now fixed in svn HEAD and the 2-4 branch. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RootContext.cs
I am trying tc.Fields but I don't get any option to display the names of fields or their values. Also, I get the following exception Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object at Mono.CSharp.RootContext.PopulateTypes () [0x0] at Mono.CSharp.Driver.Compile () [0x0] at Mono.CSharp.Driver.Main (System.String[] args) [0x0] when I try to use ToString like tc.Fields.ToString Marek Safar wrote: Hi, I am trying to find out what variables were contained in the c# file parsed by mcs. I am looking in RootContext.cs where the whole structure is created but I am unable to access the variables of the class. Any help appreciated. I don't know what information you need but type fields are stored in TypeContainer::Fields Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RootContext.cs
The information that I need from the parser is name of all the variables that were present in the file which was parsed. Marek Safar wrote: Hi, I am trying to find out what variables were contained in the c# file parsed by mcs. I am looking in RootContext.cs where the whole structure is created but I am unable to access the variables of the class. Any help appreciated. I don't know what information you need but type fields are stored in TypeContainer::Fields Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] variables
Hi Can anyone please explain how variables of a class are handled in parsing ? Thanks ! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
