Re: [Mono-devel-list] Help getting past error building libgdiplus - NO GIF option
I also cannot get GIF to say yes when compiling. I have all the required packages and also have the libungif package installed. Does anyone know why it still won't compile with the Gif option being yes. --- Peter Dennis Bartok <[EMAIL PROTECTED]> wrote: > Seems you're missing freetype on your system. > > Peter > > -Original Message- > From: "Joe Audette" <[EMAIL PROTECTED]> > To: > Date: 04 May, 2005 18:27 > Subject: [Mono-devel-list] Help getting past error > building libgdiplus > > > > > >Hi, > > > >On revision 44055 > >I'm getting this error when trying to build > >libgdiplus. > >After ./autogen.sh --prefix=$HOME/mono > >it said yes to everything except GIF > > > >error: > >eps/cairo_font.pp -c cairo_font.c -fPIC -DPIC -o > >..libs/cairo_font.o > >cairo_font.c: In function > `_font_cache_create_entry': > >cairo_font.c:89: error: > `CAIRO_FONT_BACKEND_DEFAULT' > >undeclared (first use in this function) > >cairo_font.c:89: error: (Each undeclared identifier > is > >reported only once > >cairo_font.c:89: error: for each function it > appears > >in.) > >make[4]: *** [cairo_font.lo] Error 1 > >make[4]: Leaving directory > >`/home/advanced/jaudette/src/mono/libgdiplus/cairo/src' > >make[3]: *** [all-recursive] Error 1 > >make[3]: Leaving directory > >`/home/advanced/jaudette/src/mono/libgdiplus/cairo' > >make[2]: *** [all-recursive-am] Error 2 > >make[2]: Leaving directory > >`/home/advanced/jaudette/src/mono/libgdiplus/cairo' > >make[1]: *** [all-recursive] Error 1 > >make[1]: Leaving directory > >`/home/advanced/jaudette/src/mono/libgdiplus' > >make: *** [all-recursive-am] Error 2 > > > >My hosting company grokthis.net is letting my run > my > >sites using mono from svn if I can get it working. > I > >have my own instance of apache and the idea is to > >build and run mono, xsp, mod_mono from my home > >direcotry. Its a Debian machine if that helps any. > > > >Any help or advice much appreciated. > > > >Thanks, > > > >Joe Audette > > > >joe_audette [at] yahoo dotcom > >http://www.joeaudette.com > >http://www.mojoportal.com > >___ > >Mono-devel-list mailing list > >Mono-devel-list@lists.ximian.com > >http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] GUI Toolkits
On Wed, 2005-05-04 at 22:29 -0400, Thomas Harning Jr. wrote: > About Gtk#... is there anything that I can do to prevent this > exceptions? Yes, you can file bug reports with the complete exception trace. Sending an email to a list with no more detail than "Gtk# likes to throw NullRefExceptions" doesn't help much. > I'm not sure what MonoDevelop's doing in the background and the UI > code looks split throughout... so I wouldn't know where to look for > problems (besides the fact that crashes seem extremely > non-deterministic). The exception trace tells you exactly where to look. > I've seen with sending delegates that you have to keep an instance in > managed code if you're going to send it off to unmanaged realm as a > function pointer [ex: for Tao.FreeGlut], which is a minor pain... but > will certainly be worth it if I can use Gtk# in my apps. This is not necessary for the most part in Gtk# trunk any more. If there are still places where crashes occur because of released delegates, they should be reported as bugs. -- Mike Kestner <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Limiting Memory Allocation
> Even with CAS on Microsoft's .NET, the system isn't > really geared to running the way you need to on a > game server. No, it's not, but with Mono you get a very good virtual machine that (hopefully) just needs some panel beating in places to work in a game server. > In contrast with the Java JVM, the philosphy of .NET > isn't one of a virtual machine within > the machine. Instead .NET is meant to be a layer > over OS functionality that just makes stuff easier > for developers. Again, the JVM is a square peg too. > The practical upshot of this is for example is if you > need to schedule lots of code to run concurrently you > have to use OS threads. That's OK for a web server > that might have 10 or maybe 20 ASP.NET apps running > on it, but if you gave every script on a SecondLife > server a seperate thread the machine > would grind to a halt. Which is why the plan is to inject bytecode to perform threading in a similar way to the .NET 2 iterators that Thomas was talking about. > Likewise .NET doesn't have a > mechanism that's explicity designed for handling > memory allocation. Does Java? > You can do some stuff using the profiler API as > you've seen but it's clearly not intended for that > use. No, but again if it's good enough, then that's OK. > Also, if you need to inject code into a random > .NET assembly, you can do that using the profiler > API (with a lot of additional code of course!), but > it's easier and more robust to create > a modified assembly on disk ahead of time instead. Agreed. The solution will probably involve some bytecode translation of assemblies, some appropriation of runtime facilities like profiling and (hopefully not too much) hacking of the runtime and or libraries. > A lot of stuff in .NET 1.x seems geared to support > the ASP.NET server which figures as they are probably > the most advanced 'customer' of the CLR in that > version. I think you're right, but I also think there's enough good stuff in there that it's worth trying to bend it a bit to use elsewhere. > Unless you're a big Microsoft product team though > it's probably quite hard to get features added to the > .NET CLR :) Yes, much easier to make use of the things everyday folk leave behind :-) Cheers, Jim. ___ Does your mail provider give you FREE antivirus protection? Get Yahoo! Mail http://uk.mail.yahoo.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Limiting Memory Allocation
--- Zoltan Varga <[EMAIL PROTECTED]> wrote: > Hi, > > Keep in mind that mono currently doesn't support > code access > security (CAS), so > running assemblies containing untrusted CIL code is > not a very safe thing to do. > > Zoltan Is there anything that can be done in the meantime? Put extra checks in the bytecode translator? Remove dangerous bits of the framework so they can't be called? Cheers, Jim. ___ Yahoo! Messenger - want a free and easy way to contact your friends online? http://uk.messenger.yahoo.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Limiting Memory Allocation
--- Jim Purbrick <[EMAIL PROTECTED]> wrote: > Paolo was talking about DynamicMethod Lightweight > Code Generation stuff as a potential solution to this > problem, which I'm planing to look in to. Hmmm, I've had a look at this and I don't think DynamicMethod is going to be enough. Besides Richard's suggestion of saving all the scripts and restarting Mono, are there any other ways to unload assemblies and JIT output? I can work out when they aren't needed, so just need a way to remove them from Mono. Cheers, Jim. ___ Does your mail provider give you FREE antivirus protection? Get Yahoo! Mail http://uk.mail.yahoo.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] Limiting Memory Allocation
Hello Jim, > --- Zoltan Varga <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Keep in mind that mono currently doesn't support > > code access > > security (CAS), so > > running assemblies containing untrusted CIL code is > > not a very safe thing to do. > > > > Zoltan Executing unsafe code will never be safe, even when CAS is completed. The security runtime can be compromised by unsafe code - or any native code for the matter. CAS isn't designed to help you for such scenarios (unless you decide not to allow executing unsafe/native/reflection/... code). However the problem is different if you take an "untrusted safe" assembly and transform it to an "unsafe" (and still untrusted) assembly to add specific functionalities (like tracking memory allocation...). In this case you know the only unsafe parts are your own, at least if you ensure* that the original assembly is really 100% safe. AFAIK the current Mono runtime doesn't detect all possible unsafe cases (or at least isn't tested as such). > Is there anything that can be done in the meantime? Taking this as a "yes|no" question I can assure you the answer is: YES ;-) Now if you ask "what ?" then things gets more fuzzy... > Put extra checks in the bytecode translator? Yes, it's possible to pre-check assemblies to ensure they only use class/methods from within the script or from a "white list". The "white" list can be the a part of the actual framework and/or an object model you provide. However this approach limit extensibility, existing code reuse... > Remove dangerous bits of the framework so they can't be > called? I'm unsure for your project but, in general, I don't believe this is a good approach. First the balance (functionality/security) is hard to keep and even when something gets completed you risk having a very crippled result (functionality-wise), a still insecure subset or (most probably) both. My (probably not very partial ;-) opinion is that both options requires a lot of efforts and time (not just to get there but to continue supporting it later). The same efforts could be invested in defining your security model requirements (well you would need that anyway) and helping to complete CAS to match them. But at this stage it's hard to guess when the payoff would be... Sebastien Pouliot home: [EMAIL PROTECTED] blog: http://pages.infinit.net/ctech/poupou.html ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
