Re: [Mono-list] Mono.Http.Modules

2004-02-25 Thread Gonzalo Paniagua Javier
El mar, 24-02-2004 a las 21:50, Tracy Barlow escribió:
> Thanks,
> 
> What functionality does 'Mono.Http.Modules.AcceptEncodingModule'
> provide me with?

It compresses the response if the browser supports it so it saves some
bandwidth at the cost of a few CPU cycles.

-Gonzalo


___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] ASP.NET App breaks with Mono 0.30

2004-02-25 Thread Gonzalo Paniagua Javier
El mié, 25-02-2004 a las 00:50, Tracy Barlow escribió:
> >/ System.TypeLoadException: Cannot load type 
> />/ 'Mono.Http.AcceptEncodingModule, Mono.Http'
> /
> Remove the references to Mono.Http from web.config or use
> 'Mono.Http.Modules.AcceptEncodingModule'. That Type moved to another
> namespace.
> 
> What does this Type do?

It compresses the response if the browser sends a 'Accept-Encoding:
gzip' header.

> I was not to the best of my knowlwdge using it before, none of my code
>  uses the Mono.Http namespace, so why did it work before?

It should work now too, but you didn't update web.config from current
xsp, so the namespace change is not there.

-Gonzalo


___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


[Mono-list] Re: [Mono-devel-list] String::GetHashCode speedup

2004-02-25 Thread Jonathan Gilbert
At 11:03 PM 24/02/2004 -0500, Ben wrote:
>Hey guys,
>
>I transformed String.GetHashCode into a managed function. It works
>fairly well, even for somewhat large strings:
[snip]
>So it appears the break-even point here is at ~ 38 chars.
[snip]

I have an idea: why not keep both implementations?

class System.String
{
  .
  .
  public override int GetHashCode()
  {
if (Length < 38) // the property can probably be bypassed here
  return icall_GetHashCode();

// insert managed implementation
  }
  .
  .
}

Periodically, the break-even point can be tuned. That way, people who use
.GetHashCode on extremely large strings won't have exceptionally slow code
just because they are the minority, but hash tables with short string keys
will still perform well.

While it is true that this would require two independent implementations of
the same hash algorithm to be kept in sync, it would noticeably increase
the performance of both short & long strings.

The same argument applies to the copy operation that was also under
discussion: the icall overhead may be high, but for certain lengths and up,
the speed of the hand-optimized memcpy function outweighs the overhead. If
the string copy operation is going to be called every time someone uses the
instance method String::Append, I can certainly see a lot of cases where
the speed would improve substantially (e.g. people who don't realize that
'char' is not an 8-bit integer type using a System.String as a buffer for
incoming network data -- where have we seen this before? :-).

Jonathan
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


RE: [Mono-list] MacOS packages.

2004-02-25 Thread Urs Muff
If you actually look at /usr/bin/javac, /usr/bin/java, those are soft links
to /System/Library/Framework/JavaVM.Framework/Version/1.4.2/Command/java.

--> We only have to create soft links for stuff main executables, but not
necessary the .exe assemblies since those are just .Net assemblies unless we
have some .exe Mono launcher in /etc/... as discussed many times on this
list.

As for the version: that is the framework version not the assembly version.
The GAC is fine and no problem, but Apple is talking about the executables
(mono,mint) dynamic libraries (libmono.dylib, ...) and the C-headers, and
that has a standard folder structure.

- URS C. MUFF

-Original Message-
From: Miguel de Icaza [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 24, 2004 7:43 PM
To: Urs C Muff
Cc: Andy Satori; [EMAIL PROTECTED]
Subject: Re: [Mono-list] MacOS packages.

Hello,

> Well actually I agree that the shell scripts 'mono' and 'mcs' might 
> live in /usr/bin, but I would create a Framework and put it in 
> /System/Library/Frameworks/MonoVM.Framework the same way as 
> /System/Library/Frameworks/JavaVM.Framework is placed (look at the 
> folder structure within the framework to see how Apple is structuring 
> such a beast).
> 
> But the .Net assemblies should live in 
> /System/Library/Frameworks/MonoVM.Framework/Versions/0.30/Assemblies 
> where there is a link pointing there @ 
> /System/Library/Frameworks/MonoVM.Framework/Assemblies.
> 
> That would conform with Apple's standard much better: I don't know how 
> we would have to build mono to include those in the assembly load 
> path...

I think you just build mono with a prefix of:

/System/Library/Frameworks/MonoVM.Framework

And just copy anything that is installed in the bin/ subdirectory to
/usr/bin.

As for the versioning: we will be taking care of library versions in a
different way (the GAC approach)
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] MacOS packages.

2004-02-25 Thread Andy Satori
Urs is correct, after some more digging, it's the 'way' to go.  it's 
going to take me a couple of days to cleanup my own system to get all 
this built and tested (wish I had another machine for this...  oh 
well).

I've got the packages and base installer's built, I just need to run 
through and tweak them into frameworks.  This will also make them much 
easier to install and manage in the future.

Andy

On Feb 25, 2004, at 8:21 AM, Urs Muff wrote:

If you actually look at /usr/bin/javac, /usr/bin/java, those are soft 
links
to 
/System/Library/Framework/JavaVM.Framework/Version/1.4.2/Command/java.

--> We only have to create soft links for stuff main executables, but 
not
necessary the .exe assemblies since those are just .Net assemblies 
unless we
have some .exe Mono launcher in /etc/... as discussed many times on 
this
list.

As for the version: that is the framework version not the assembly 
version.
The GAC is fine and no problem, but Apple is talking about the 
executables
(mono,mint) dynamic libraries (libmono.dylib, ...) and the C-headers, 
and
that has a standard folder structure.

- URS C. MUFF

-Original Message-
From: Miguel de Icaza [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 24, 2004 7:43 PM
To: Urs C Muff
Cc: Andy Satori; [EMAIL PROTECTED]
Subject: Re: [Mono-list] MacOS packages.
Hello,

Well actually I agree that the shell scripts 'mono' and 'mcs' might
live in /usr/bin, but I would create a Framework and put it in
/System/Library/Frameworks/MonoVM.Framework the same way as
/System/Library/Frameworks/JavaVM.Framework is placed (look at the
folder structure within the framework to see how Apple is structuring
such a beast).
But the .Net assemblies should live in
/System/Library/Frameworks/MonoVM.Framework/Versions/0.30/Assemblies
where there is a link pointing there @
/System/Library/Frameworks/MonoVM.Framework/Assemblies.
That would conform with Apple's standard much better: I don't know how
we would have to build mono to include those in the assembly load
path...
I think you just build mono with a prefix of:

	/System/Library/Frameworks/MonoVM.Framework

And just copy anything that is installed in the bin/ subdirectory to
/usr/bin.
As for the versioning: we will be taking care of library versions in a
different way (the GAC approach)
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


RE: [Mono-list] MacOS packages.

2004-02-25 Thread Urs Muff
This is great!  Please publish the Xcode projects and scripts you use to
make the package and framework so others can build it from CVS.  Miguel or
myself will check them into CVS in case you don't have access.

- Urs

-Original Message-
From: Andy Satori [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 25, 2004 7:21 AM
To: Urs Muff
Cc: 'Miguel de Icaza'; [EMAIL PROTECTED]
Subject: Re: [Mono-list] MacOS packages.

Urs is correct, after some more digging, it's the 'way' to go.  it's 
going to take me a couple of days to cleanup my own system to get all 
this built and tested (wish I had another machine for this...  oh 
well).

I've got the packages and base installer's built, I just need to run 
through and tweak them into frameworks.  This will also make them much 
easier to install and manage in the future.

Andy

On Feb 25, 2004, at 8:21 AM, Urs Muff wrote:

> If you actually look at /usr/bin/javac, /usr/bin/java, those are soft 
> links
> to 
> /System/Library/Framework/JavaVM.Framework/Version/1.4.2/Command/java.
>
> --> We only have to create soft links for stuff main executables, but 
> not
> necessary the .exe assemblies since those are just .Net assemblies 
> unless we
> have some .exe Mono launcher in /etc/... as discussed many times on 
> this
> list.
>
> As for the version: that is the framework version not the assembly 
> version.
> The GAC is fine and no problem, but Apple is talking about the 
> executables
> (mono,mint) dynamic libraries (libmono.dylib, ...) and the C-headers, 
> and
> that has a standard folder structure.
>
> - URS C. MUFF
>
> -Original Message-
> From: Miguel de Icaza [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 24, 2004 7:43 PM
> To: Urs C Muff
> Cc: Andy Satori; [EMAIL PROTECTED]
> Subject: Re: [Mono-list] MacOS packages.
>
> Hello,
>
>> Well actually I agree that the shell scripts 'mono' and 'mcs' might
>> live in /usr/bin, but I would create a Framework and put it in
>> /System/Library/Frameworks/MonoVM.Framework the same way as
>> /System/Library/Frameworks/JavaVM.Framework is placed (look at the
>> folder structure within the framework to see how Apple is structuring
>> such a beast).
>>
>> But the .Net assemblies should live in
>> /System/Library/Frameworks/MonoVM.Framework/Versions/0.30/Assemblies
>> where there is a link pointing there @
>> /System/Library/Frameworks/MonoVM.Framework/Assemblies.
>>
>> That would conform with Apple's standard much better: I don't know how
>> we would have to build mono to include those in the assembly load
>> path...
>
> I think you just build mono with a prefix of:
>
>   /System/Library/Frameworks/MonoVM.Framework
>
> And just copy anything that is installed in the bin/ subdirectory to
> /usr/bin.
>
> As for the versioning: we will be taking care of library versions in a
> different way (the GAC approach)
>
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] will MONO support .NET applets ?

2004-02-25 Thread A Rafael D Teixeira
On Mon, 2004-02-23 at 08:35, Goodman, Gareth wrote:
> Hi
>  
> I've been experimenting with .NET applets using c#, deployed on XP.
> I've been keeping
> an eye on MONO's progress to date as it looks like the answer to many
> problems, and
> I would like to know if (for example) a MONO-enabled Linux machine
> will be capable of
> running .NET applets inside a browser on that machine. 

Not currently, because such feature have high demands on the security
area: Specially it needs to have a full implementation of CAS (Code
Acess Security) working, and we are just starting to implement it
(Sebastien correct me if needed please).

Nobody should give .NET Applets all the powers of a local application,
or it would be a feast for worms and trojan-horses writers. 

When you factor in all the limitations you have to impose in such
applets because of security concerns, their usefullness for some
enticing scenarios become nearly zero.

> please say yes :)

Sorry, not yet...

Also someone have to build a plugin for the browsers to recognize the
mime-type plus specific headers in the exes, and them make a container
for managed content. This plugin would start/embed mono.

Also .NET Applets are normally WinForms-based so as our WinForms
implementation is also incomplete, probably even if the other cited
pieces were in place you couldn't have it working.

Some things just take more time to implement and mature. Care to help us
into making it possible earlier than later...
 
> Regards,
>  
> Gareth Goodman
> English Heritage UK

Best regards,

-- 
Rafael "Monoman" Teixeira 
Mono Hacker since 16 Jul 2001 - http://www.go-mono.org/
Mono Brasil Founding Member - http://monobrasil.redesolbrasil.org/
English Blog: http://monoblog.blogspot.com/
Brazilian Portuguese Blog: http://monoblog.weblogger.terra.com.br/

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] MacOS packages.

2004-02-25 Thread Erik Dasque
What about GTK# ? Is that Mono built with ICU, Andy ?

What are you doing with XCode ?

Erik

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


[Mono-list] Npgsql encoding problems with 0.6rc1 fixed in cvs

2004-02-25 Thread Francisco Figueiredo Jr.
Hi all,

In order to add Unicode encoding support, 0.6rc1 added a little bug when 
handling non Unicode encodings.

Now this is fixed in cvs.

Please, grab the latest cvs code with the fix and give it a try.

Let me know of any problems you get.

A new release will come shortly with this fix.

--
Regards,
Francisco Figueiredo Jr.
Membro Fundador do Projeto MonoBrasil - MonoBrasil Project Founder Member
-
"Science without religion is lame;
religion without science is blind."
  ~ Albert Einstein
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] MacOS packages.

2004-02-25 Thread Andy Satori
At this point, I'm packaging GTK#, XSP and MOD_MONO as seperate 
packages.

On the ICU (and GC) front, I currently build without either, but once I 
get all the foundation in place, I'll add them.

With XCode, I currently have a C# language filter defined so that XCode 
can parse the functions and color C# files.  I also have a Makefile 
based project template for building a C# application in XCode.  I'm now 
working on enhancing that to be a part of the XCode native build 
system, instead of the old Project Builder, jam based, build system.  
This will improve the error parsing and display, as well as allow you 
to use the much more powerful Info panels in XCode to set up your build 
environments.  After that, it is my intent to build a library of 
templates for XCode to setup your basic projects, much like VS.NET.  
Hopefully by that time, Apple will have updated XCode to make it easier 
to integrate external debuggers into XCode, and I'll be able to add 
that.

Andy



On Feb 25, 2004, at 10:54 AM, Erik Dasque wrote:

What about GTK# ? Is that Mono built with ICU, Andy ?

What are you doing with XCode ?

Erik

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] MacOS packages.

2004-02-25 Thread Erik Dasque
Andy,

The xcode stuff sounds great. Are you packaging 0.30.2 or a cvs build ? 
I don't believe the ppc fix is in the releases yet. I have found that 
many applications crash (Bus error) without it thus far (including a 
lot of GTK# apps). Do you use the interpreter only ? Also, I believe 
ICU is needed to run monodevelop, wink, wink.

Erik

On Feb 25, 2004, at 11:27 AM, Andy Satori wrote:

At this point, I'm packaging GTK#, XSP and MOD_MONO as seperate 
packages.

On the ICU (and GC) front, I currently build without either, but once 
I get all the foundation in place, I'll add them.

With XCode, I currently have a C# language filter defined so that 
XCode can parse the functions and color C# files.  I also have a 
Makefile based project template for building a C# application in 
XCode.  I'm now working on enhancing that to be a part of the XCode 
native build system, instead of the old Project Builder, jam based, 
build system.  This will improve the error parsing and display, as 
well as allow you to use the much more powerful Info panels in XCode 
to set up your build environments.  After that, it is my intent to 
build a library of templates for XCode to setup your basic projects, 
much like VS.NET.  Hopefully by that time, Apple will have updated 
XCode to make it easier to integrate external debuggers into XCode, 
and I'll be able to add that.

Andy



On Feb 25, 2004, at 10:54 AM, Erik Dasque wrote:

What about GTK# ? Is that Mono built with ICU, Andy ?

What are you doing with XCode ?

Erik

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] MacOS packages - GTK#.

2004-02-25 Thread Elfred Pagán
This is a little offtopic, but since you mention GTK#

I tried to compile GTK# early this week and the compilation through an 
exception and since mcs doesn't support exception handling yet, the 
process crashed.

Are you doing anything special to compile GTK#?
On Feb 25, 2004, at 12:27 PM, Andy Satori wrote:
At this point, I'm packaging GTK#, XSP and MOD_MONO as seperate 
packages.

On the ICU (and GC) front, I currently build without either, but once 
I get all the foundation in place, I'll add them.

With XCode, I currently have a C# language filter defined so that 
XCode can parse the functions and color C# files.  I also have a 
Makefile based project template for building a C# application in 
XCode.  I'm now working on enhancing that to be a part of the XCode 
native build system, instead of the old Project Builder, jam based, 
build system.  This will improve the error parsing and display, as 
well as allow you to use the much more powerful Info panels in XCode 
to set up your build environments.  After that, it is my intent to 
build a library of templates for XCode to setup your basic projects, 
much like VS.NET.  Hopefully by that time, Apple will have updated 
XCode to make it easier to integrate external debuggers into XCode, 
and I'll be able to add that.

Andy



On Feb 25, 2004, at 10:54 AM, Erik Dasque wrote:

What about GTK# ? Is that Mono built with ICU, Andy ?

What are you doing with XCode ?

Erik

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
Elfred Pagán

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] MacOS packages.

2004-02-25 Thread Andy Satori
At the moment, my primary installation is a CVS build.  I did all the 
dependancy work and checks on a clean OS X install (gotta love firewire 
external drives) and it's using 0.30.2, as it's a quicker and easier 
build process on a virgin machine.

Once I have the basics established, I'll bring it all up to date, 
including updating to the newly releasesd GLib 2.3.3.

Andy

On Feb 25, 2004, at 11:37 AM, Erik Dasque wrote:

Andy,

The xcode stuff sounds great. Are you packaging 0.30.2 or a cvs build 
? I don't believe the ppc fix is in the releases yet. I have found 
that many applications crash (Bus error) without it thus far 
(including a lot of GTK# apps). Do you use the interpreter only ? 
Also, I believe ICU is needed to run monodevelop, wink, wink.

Erik

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] MacOS packages - GTK#.

2004-02-25 Thread Erik Dasque
I replaced all references to mono to point to mint in the makefiles. If 
you're using 0.30.x, you probably don't have the ppc fix and mcs.exe 
(running with mono, the JIT) as well as other .exe processes (gapi 
comes to mind) will die.

Erik

On Feb 25, 2004, at 11:54 AM, Elfred Pagán wrote:

This is a little offtopic, but since you mention GTK#

I tried to compile GTK# early this week and the compilation through an 
exception and since mcs doesn't support exception handling yet, the 
process crashed.

Are you doing anything special to compile GTK#?
On Feb 25, 2004, at 12:27 PM, Andy Satori wrote:
At this point, I'm packaging GTK#, XSP and MOD_MONO as seperate 
packages.

On the ICU (and GC) front, I currently build without either, but once 
I get all the foundation in place, I'll add them.

With XCode, I currently have a C# language filter defined so that 
XCode can parse the functions and color C# files.  I also have a 
Makefile based project template for building a C# application in 
XCode.  I'm now working on enhancing that to be a part of the XCode 
native build system, instead of the old Project Builder, jam based, 
build system.  This will improve the error parsing and display, as 
well as allow you to use the much more powerful Info panels in XCode 
to set up your build environments.  After that, it is my intent to 
build a library of templates for XCode to setup your basic projects, 
much like VS.NET.  Hopefully by that time, Apple will have updated 
XCode to make it easier to integrate external debuggers into XCode, 
and I'll be able to add that.

Andy



On Feb 25, 2004, at 10:54 AM, Erik Dasque wrote:

What about GTK# ? Is that Mono built with ICU, Andy ?

What are you doing with XCode ?

Erik

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
Elfred Pagán

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


[Mono-list] monodoc advice

2004-02-25 Thread Philip
Hello,

I'm using monodoc to build some docs for a project and had a few
questions. First monodoc has been integrated into our build system,
integration was easy and the docs look great. Once the docs are built
(make doc) they're exported to the sources directory where they can be
viewed with the browser. I want to be able to sync any docs generated
from future code changes, and documentation written through the browser.
Do I have to do anything special here to prevent anything from being
lost? 

Second, I'm getting errors in the browser when viewing my name spaces.
The classes view with the "Type" and "Summary" headings show up fine
with the Type field populated with my class names and the Summary field
containing the "to be added" tag and "An error occured while loading
type information: File "My.Namespace" not found. I'm not really sure
where to start tracking this one down. Any help would be great.

Thanks,
- Phil

ps Monodoc is one of the most useful tools yet, it's getting me out of
writing A LOT of documentation for my senior design project. Less
writing is good.

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


[Mono-list] Re: [Ikvm-developers] IKVM on Mono on OS/X

2004-02-25 Thread Andrew C. Oliver
>> From: "Andrew C. Oliver" <[EMAIL PROTECTED]>
>> Date: Fri, 20 Feb 2004 11:12:22 -0500
>> To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
>> Subject: [Ikvm-developers] IKVM on Mono on OS/X
>> 
>> I know this is a bit on the experimental side but I just grabbed the latest
>> mono 0.30.1 and ikvm.  I tried to run Hello.class (the function should be
>> obvious) and I get a bus error (-v -v -v output attached).  I can run the
>> same code written in C#.  Any suggestions, thoughts, comments?
>> 
>> (Sorry for the cross post but I bet its about equally PPC mono it related as
>> IKVM)
>> 
>> Thanks,
>> -- 
>> Andrew C. Oliver
>> http://www.superlinksoftware.com/poi.jsp
>> Custom enhancements and Commercial Implementation for Jakarta POI
>> 
>> http://jakarta.apache.org/poi
>> For Java and Excel, Got POI?
>> 
>> The views expressed in this email are those of the author and are almost
>> definitely not shared by the Apache Software Foundation, its board or its
>> general membership.  In fact they probably most definitively disagree with
>> everything espoused in the above email.
>> 
>> 



foo2
Description: Binary data


Re: [Mono-list] Re: [Ikvm-developers] IKVM on Mono on OS/X

2004-02-25 Thread Erik Dasque
Did you try using mint instead of mono to run this ? 0.30.x on PPC has 
a bug which appears very quickly when you use mono (the JIT) and less 
frequently with the interpreter.

Erik

On Feb 25, 2004, at 2:50 PM, Andrew C. Oliver wrote:

From: "Andrew C. Oliver" <[EMAIL PROTECTED]>
Date: Fri, 20 Feb 2004 11:12:22 -0500
To: <[EMAIL PROTECTED]>, 
<[EMAIL PROTECTED]>
Subject: [Ikvm-developers] IKVM on Mono on OS/X

I know this is a bit on the experimental side but I just grabbed the 
latest
mono 0.30.1 and ikvm.  I tried to run Hello.class (the function 
should be
obvious) and I get a bus error (-v -v -v output attached).  I can 
run the
same code written in C#.  Any suggestions, thoughts, comments?

(Sorry for the cross post but I bet its about equally PPC mono it 
related as
IKVM)

Thanks,
--
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
The views expressed in this email are those of the author and are 
almost
definitely not shared by the Apache Software Foundation, its board 
or its
general membership.  In fact they probably most definitively 
disagree with
everything espoused in the above email.



___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] monodoc advice

2004-02-25 Thread Joshua Tauberer
Philip wrote:
Second, I'm getting errors in the browser when viewing my name spaces.
(. . .) containing the "to be added" tag and "An error occured while loading
type information: File "My.Namespace" not found.
Monodoc loads up the classes at run time to make sure that the 
documentation being viewed for a class matches what's actually defined 
in the class.  e.g. If a member hasn't been implemented but there's 
documentation for it, Monodoc says so so that the developer knows not to 
use the method.  (I imagine this will disappear at some point.)

If Monodoc can't find the assembly to load (because it's not in 
MONO_PATH), it'll show that message.

--
- Joshua Tauberer
http://taubz.for.net

** Nothing Unreal Exists **

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


[Mono-list] [ANNOUNCE] Kurush Personal Finance Tool 0.5

2004-02-25 Thread Ecmel Ercan
Hi,

I have released a new version of my personal finance tool called "Kurush".

It is developed with Mono and Gtk# and requires Gnome Desktop 2

The source code, binary and screenshots can be found at:

http://www.ercansoy.com/kurush/

Hope, people will find it useful.

Ecmel Ercan


___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


RE: [Mono-list] [ANNOUNCE] Kurush Personal Finance Tool 0.5

2004-02-25 Thread Daniel Morgan
Hi,

Very Nice!

I was wanting to do something like that.  I wanted a program like gnuCash,
but I was disappointed to not find a Windows port.  Now, I don't have to
create one - I can just use yours.

BTW, does it use pure gtk#, or does it require other stuff such as GNOME#?
I was wanting to use this on Windows.

Thanks,
Daniel

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ecmel Ercan
Sent: Wednesday, February 25, 2004 6:25 PM
To: [EMAIL PROTECTED]
Subject: [Mono-list] [ANNOUNCE] Kurush Personal Finance Tool 0.5


Hi,

I have released a new version of my personal finance tool called "Kurush".

It is developed with Mono and Gtk# and requires Gnome Desktop 2

The source code, binary and screenshots can be found at:

http://www.ercansoy.com/kurush/

Hope, people will find it useful.

Ecmel Ercan


___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


[Mono-list] Most recent snapshot and Mac OS X

2004-02-25 Thread Jonel
I tried compiling the latest mono snapshot and I got the following 
error message when I did a configure:

config.status: error: cannot find input file: 
mono/arch/amd64/Makefile.in

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] Compiling egg-chicken libraries

2004-02-25 Thread max
shouldn't you avoid such situations in the first place ?
Isn't this a design issue, more than a compilation issue ?

On Tuesday 24 February 2004 05:16, Jaroslaw Kowalski wrote:
> I've had similar problem and looks like there's no general-purpose
> solution.
>
> I deal with it by creating a stub version of one library, compiling the
> other library against it and then recompiling the first library against
> just built second library.
>
> The stub contains nothing but public API of the library that's used by the
> second library.
>
> Jarek
> - Original Message -
> From: "Martin Tsachev" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 24, 2004 2:03 PM
> Subject: [Mono-list] Compiling egg-chicken libraries
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> I have some code that compiles in Visual Studio but I didn't have much luck
> trying to compile it with mono. The problem is that I have lib1 and lib2
> and each instantiates an object with a class definition in the other
> library.
>
> I found in the archive that I can compile the libraries with mcs /t:library
> lib1.cs -r... I get this error
>
> lib1.cs (line) error CS0246: Cannot find type 'lib2.foo'
>
> The same happens if I try to compile lib2. I tried with -r:lib1.cs but it
> didn't quite like it.
>
> Also is there a way that I can automate the whole compiling process, maybe
> if
> not direct I can dig into Makefiles and write one?
>
> - --
> Martin Tsachev
> http://martin.f2o.org
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.3 (GNU/Linux)
>
> iD8DBQFAO0unypytlz9Py3wRAk3sAJ9W3Y1MUASk2LwTGursdJIBl+7E3ACgqBYG
> kr5zz7Bl41qjloGHqJ/ncwU=
> =EaFM
> -END PGP SIGNATURE-
> ___
> Mono-list maillist  -  [EMAIL PROTECTED]
> http://lists.ximian.com/mailman/listinfo/mono-list
>
> ___
> Mono-list maillist  -  [EMAIL PROTECTED]
> http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] Compiling egg-chicken libraries

2004-02-25 Thread Ben Maurer
Hello,

The problem is that there are some dependencies built into the public
api of the class libraries that we can't redesign because it would break
binary compat with assemblies built on the Microsoft runtime.

Honestly, if I had been designing it, I would not have built in the
dependency.

-- Ben

On Wed, 2004-02-25 at 22:35, max wrote:
> shouldn't you avoid such situations in the first place ?
> Isn't this a design issue, more than a compilation issue ?
> 
> On Tuesday 24 February 2004 05:16, Jaroslaw Kowalski wrote:
> > I've had similar problem and looks like there's no general-purpose
> > solution.
> >
> > I deal with it by creating a stub version of one library, compiling the
> > other library against it and then recompiling the first library against
> > just built second library.
> >
> > The stub contains nothing but public API of the library that's used by the
> > second library.
> >
> > Jarek
> > - Original Message -
> > From: "Martin Tsachev" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, February 24, 2004 2:03 PM
> > Subject: [Mono-list] Compiling egg-chicken libraries
> >
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Hello,
> >
> > I have some code that compiles in Visual Studio but I didn't have much luck
> > trying to compile it with mono. The problem is that I have lib1 and lib2
> > and each instantiates an object with a class definition in the other
> > library.
> >
> > I found in the archive that I can compile the libraries with mcs /t:library
> > lib1.cs -r... I get this error
> >
> > lib1.cs (line) error CS0246: Cannot find type 'lib2.foo'
> >
> > The same happens if I try to compile lib2. I tried with -r:lib1.cs but it
> > didn't quite like it.
> >
> > Also is there a way that I can automate the whole compiling process, maybe
> > if
> > not direct I can dig into Makefiles and write one?
> >
> > - --
> > Martin Tsachev
> > http://martin.f2o.org
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.2.3 (GNU/Linux)
> >
> > iD8DBQFAO0unypytlz9Py3wRAk3sAJ9W3Y1MUASk2LwTGursdJIBl+7E3ACgqBYG
> > kr5zz7Bl41qjloGHqJ/ncwU=
> > =EaFM
> > -END PGP SIGNATURE-
> > ___
> > Mono-list maillist  -  [EMAIL PROTECTED]
> > http://lists.ximian.com/mailman/listinfo/mono-list
> >
> > ___
> > Mono-list maillist  -  [EMAIL PROTECTED]
> > http://lists.ximian.com/mailman/listinfo/mono-list
> ___
> Mono-list maillist  -  [EMAIL PROTECTED]
> http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] Compiling egg-chicken libraries

2004-02-25 Thread Jaroslaw Kowalski
I need (as an option) this for my O/R mapping software because I want to be
able to use mutliple languages.

I have:

1. "Stubs" assembly - written in C# - that must be able to create objects
from "Objects" assembly to represent 1-1 relations and 1-N relations.
2. "Objects" assembly - written in some other language whose classes inherit
from the appropriate classes in "Stubs" assembly

So I have a mutual dependency here. But as I've said this is optional. If
you stict to C# you have just a single assembly with no interdependencies.

Jarek

- Original Message - 
From: "max" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 26, 2004 4:35 AM
Subject: Re: [Mono-list] Compiling egg-chicken libraries


> shouldn't you avoid such situations in the first place ?
> Isn't this a design issue, more than a compilation issue ?
>
> On Tuesday 24 February 2004 05:16, Jaroslaw Kowalski wrote:
> > I've had similar problem and looks like there's no general-purpose
> > solution.
> >
> > I deal with it by creating a stub version of one library, compiling the
> > other library against it and then recompiling the first library against
> > just built second library.
> >
> > The stub contains nothing but public API of the library that's used by
the
> > second library.
> >
> > Jarek
> > - Original Message -
> > From: "Martin Tsachev" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, February 24, 2004 2:03 PM
> > Subject: [Mono-list] Compiling egg-chicken libraries
> >
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Hello,
> >
> > I have some code that compiles in Visual Studio but I didn't have much
luck
> > trying to compile it with mono. The problem is that I have lib1 and lib2
> > and each instantiates an object with a class definition in the other
> > library.
> >
> > I found in the archive that I can compile the libraries with mcs
/t:library
> > lib1.cs -r... I get this error
> >
> > lib1.cs (line) error CS0246: Cannot find type 'lib2.foo'
> >
> > The same happens if I try to compile lib2. I tried with -r:lib1.cs but
it
> > didn't quite like it.
> >
> > Also is there a way that I can automate the whole compiling process,
maybe
> > if
> > not direct I can dig into Makefiles and write one?
> >
> > - --
> > Martin Tsachev
> > http://martin.f2o.org
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.2.3 (GNU/Linux)
> >
> > iD8DBQFAO0unypytlz9Py3wRAk3sAJ9W3Y1MUASk2LwTGursdJIBl+7E3ACgqBYG
> > kr5zz7Bl41qjloGHqJ/ncwU=
> > =EaFM
> > -END PGP SIGNATURE-
> > ___
> > Mono-list maillist  -  [EMAIL PROTECTED]
> > http://lists.ximian.com/mailman/listinfo/mono-list
> >
> > ___
> > Mono-list maillist  -  [EMAIL PROTECTED]
> > http://lists.ximian.com/mailman/listinfo/mono-list
> ___
> Mono-list maillist  -  [EMAIL PROTECTED]
> http://lists.ximian.com/mailman/listinfo/mono-list
>

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list