Hello,
> Regarding the developer contact you could reach either me or Sunil
> Kumar. Regarding the developer support contact you could reach Susan
> Perrin.
>
> Regarding the repository maintenance and sync we will get back to you
> ASAP. Hope this is fine.
Thanks, that would be fine.
We wo
Hello All,
Might be a simple question, but I'll ask anyway. I have a small
program that calls Type.GetType("MyType, MyAssembly"). This works fine.
The program references "MyAssembly" at compile time.
I also reference another assembly (say "MyAssembly2") in the
executable. MyAssembl
On Mon, 2005-08-29 at 13:25 +0300, Eyal Alaluf wrote:
> Hi, all.
>
> The attached diff is a patch compiling for
> System.Web/HttpApplicationFactory.cs under
> the TARGET_J2EE (Grasshoper) configuration.
This is ok to check in.
-Gonzalo
___
Mono-devel
Hi,
It is known bug #75925.
Atsushi Eno
Paul F. Johnson wrote:
> Hi,
>
> I noticed on the svn branch a nice little utility for browsing msdn
> without having to pratt about with the MSDN website.
>
> I've run makefile, but all I get back is this (the code fails to
> compile)
>
> Unhandled Exc
Gonzalo Paniagua Javier a écrit :
On Tue, 2005-08-23 at 16:36 +0200, Johann BLAIS wrote:
Should i file a bug for this ?
Please, do.
-Gonzalo
Thanks for your response.
Filed bug #75936.
Regards,
Johann.
___
Mono-devel-list mailing lis
Hello Eyal,
> Attached is a patch for compiling HttpResponseStream.cs under TARGET_JVM.
> Under TARGET_JVM (Grasshopper) we don't support unsafe code. I therefore made
> the following
> changes to minimize the use of unsafe code and maximize the code sharing:
> * I created a managed version of
Hi,
I tried your patch with ComIStreamMarshaler.cs and used -codepage:65001. It
worked as expected but it fails with SVN head. The expected behaviour is to
compile without errors so you patch solves the bug.
And I agree that SeekableStreamReader is a too tricky solution and seems to
be the cause
El dl 29 de 08 del 2005 a les 07:30 -0500, en/na Ganeshram Iyer va
escriure:
> Hello all,
> I am not sure if this is the right list to send this request to. It is
> a question on Monodevelop. I am running it on Debian Sarge and
> installed it from unstable. When running it unfortunately I get this
Hello all,
I am not sure if this is the right list to send this request to. It is
a question on Monodevelop. I am running it on Debian Sarge and
installed it from unstable. When running it unfortunately I get this
message and Monodevelop crashes. This happens both as normal user and
root. Any help
Hi,
I noticed on the svn branch a nice little utility for browsing msdn
without having to pratt about with the MSDN website.
I've run makefile, but all I get back is this (the code fails to
compile)
Unhandled Exception: System.Exception: Trying to emit a local from a
different ILGenerator.
in <0
Hi,
According to my experiences using no ArraySubType has the same result as
ArraySubType = (UnmanagedType)80 on mcs and csc.exe as well.
Could someone tell me please why UnmanagedType_80 is required?
Kornél
___
Mono-devel-list mailing list
Mono-deve
On Mon, 2005-08-29 at 13:00 +0300, Eyal Alaluf wrote:
> +#else
> wr.SendResponseFromMemory ((IntPtr)
> start, len);
> +#endif
This looks wrong. IntPtr is now an offset from the beginning of the
chunk, right?
Did you test this on the standard version?
-- Ben
_
On Tue, 2005-08-30 at 18:29 +0300, Eyal Alaluf wrote:
>
> You are correct. It forced me to make the ByteBucket class unsafe for
> Mono config, but
> I hope that difference won't matter in the future.
Why not add a method in chunk to send the chunk?
Also, please fully test the standard config bef
Hi,
Mono is an international project. This means that people all around the
world are hacking source code while using their own native code pages.
The problem is that sometimes there is a need to use non-ASCII characters.
When doing so it is important to compile source code using the same code
p
Hello,
I was toying around with Mono.Cairo today and noticed some things I
would like to change. Here is a patch with some of the smaller changes.
The end gaol is to make it more like pycairo and cairo bindings docs.
ChangeLog in the patch, let me know if any more explanation is needed.
> IMHO those people who really care about performance should use
> /noconfig (that's exactly the same behavior that csc does as
> well as Peter's patch does). It could be also used to build
> mscorlib, System and System.Xml dlls.
>
> Or at least we could provide something like /rsp to enable rsp f
Hello,
> I agree that xtoken() could be performance sensitive, but on the
> other hand, current code moves back the stream, which results in
> extraneous parse on every parenthesized expressions. Actually
> as mentioned later, the patched code seems faster. Note that
> SeekableStreamReader has to
Hi,
I tried your patch with ComIStreamMarshaler.cs and used -codepage:65001. It
worked as expected but it fails with SVN head. The expected behaviour is to
compile without errors so you patch solves the bug.
Yep - now the fixed patch is going.
I've done some tests with files readed as UTF-8
Hi,
I just commited and reverted the patch - gmcs seems pretty complex
on those tokenization matter than mcs. I'll try to make those
changes on gmcs directly.
Atsushi Eno
Miguel de Icaza wrote:
> Hello,
>
>> I agree that xtoken() could be performance sensitive, but on the
>> other hand, current
Hi, Ben.
You are correct. It forced me to make the ByteBucket class unsafe for Mono
config, but
I hope that difference won't matter in the future.
Eyal.
On Tue, 30 Aug 2005, Ben Maurer wrote:
> Date: Tue, 30 Aug 2005 10:45:08 -0400
> From: Ben Maurer <[EMAIL PROTECTED]>
> To: Eyal Alaluf <[EMA
20 matches
Mail list logo
