Re: [Mono-dev] Please help this Git newbie
Hello To sum things up: I'm on Windows, using msysgit, and have been following the FAQs on the Mono and GitHub sites. I'm at this point: http://mono-project.com/Compiling_Mono_From_Git Doing git clone git://github.com/mono/mono.git (anonymous access) works, (although I have no idea *where* it copies all the stuff; I stopped it before it was done). The git clone command clones repository (in .git/ directory) first. Making actual files are final step; If you stopped, other than .git are not exist. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Please help this Git newbie
Hi, If you have commit access, use: g...@github.com:mono/mono.git Zoltan On Wed, Jan 5, 2011 at 8:55 AM, Stifu st...@free.fr wrote: Hi guys, To sum things up: I'm on Windows, using msysgit, and have been following the FAQs on the Mono and GitHub sites. I'm at this point: http://mono-project.com/Compiling_Mono_From_Git Doing git clone git://github.com/mono/mono.git (anonymous access) works, (although I have no idea *where* it copies all the stuff; I stopped it before it was done). But when I try to clone the Mono repo using my GitHub username, it doesn't work. Here's the console output: $ git clone g...@github.com:thomasgoldstein/mono.git Cloning into mono... Enter passphrase for key '/c/Documents and Settings/Stifu/.ssh/id_rsa': ERROR: thomasgoldstein/mono.git doesn't exist. Did you enter it correctly? fatal: The remote end hung up unexpectedly Help? -- View this message in context: http://mono.1490590.n4.nabble.com/Please-help-this-Git-newbie-tp3174937p3174937.html Sent from the Mono - Dev mailing list archive at Nabble.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
Re: [Mono-dev] Please help this Git newbie
Thanks Zoltan! Will try that once I get back home. And thanks for the info, Makoto. Zoltan Varga wrote: Hi, If you have commit access, use: g...@github.com:mono/mono.git Zoltan On Wed, Jan 5, 2011 at 8:55 AM, Stifu st...@free.fr wrote: Hi guys, To sum things up: I'm on Windows, using msysgit, and have been following the FAQs on the Mono and GitHub sites. I'm at this point: http://mono-project.com/Compiling_Mono_From_Git Doing git clone git://github.com/mono/mono.git (anonymous access) works, (although I have no idea *where* it copies all the stuff; I stopped it before it was done). But when I try to clone the Mono repo using my GitHub username, it doesn't work. Here's the console output: $ git clone g...@github.com:thomasgoldstein/mono.git Cloning into mono... Enter passphrase for key '/c/Documents and Settings/Stifu/.ssh/id_rsa': ERROR: thomasgoldstein/mono.git doesn't exist. Did you enter it correctly? fatal: The remote end hung up unexpectedly Help? -- View this message in context: http://mono.1490590.n4.nabble.com/Please-help-this-Git-newbie-tp3174937p3174937.html Sent from the Mono - Dev mailing list archive at Nabble.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 -- View this message in context: http://mono.1490590.n4.nabble.com/Please-help-this-Git-newbie-tp3174937p3175002.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Please help this Git newbie
Hi, You need to create a fork of mono in your github account before you can check it out using your username. Rolf From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Stifu Sent: miércoles, 05 de enero de 2011 8:56 To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Please help this Git newbie Hi guys, To sum things up: I'm on Windows, using msysgit, and have been following the FAQs on the Mono and GitHub sites. I'm at this point: http://mono-project.com/Compiling_Mono_From_Git Doing git clone git://github.com/mono/mono.git (anonymous access) works, (although I have no idea *where* it copies all the stuff; I stopped it before it was done). But when I try to clone the Mono repo using my GitHub username, it doesn't work. Here's the console output: $ git clone g...@github.com:thomasgoldstein/mono.git Cloning into mono... Enter passphrase for key '/c/Documents and Settings/Stifu/.ssh/id_rsa': ERROR: thomasgoldstein/mono.git doesn't exist. Did you enter it correctly? fatal: The remote end hung up unexpectedly Help? -- View this message in context: http://mono.1490590.n4.nabble.com/Please-help-this-Git-newbie-tp3174937p3174 937.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3359 - Release Date: 01/04/11 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] File not found error when using Activator.CreateInstanceFrom()
Anybody else see this while using P/Invoke under mono? -- View this message in context: http://mono.1490590.n4.nabble.com/File-not-found-error-when-using-Activator-CreateInstanceFrom-tp3064104p3175616.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] File not found error when using Activator.CreateInstanceFrom()
On 05.01.2011 15:25, mike wrote: Anybody else see this while using P/Invoke under mono? They do not even relate, so no one else will see this ;) Please explain what you're trying to do. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] more support for Google Native Client
Hi Zoltan,
I've addressed all of the issues you pointed out (minus genmdesc.c:
__nacl_suspend_thread_if_needed, but that doesn't need to be merged in at
this time, it can remain in my local repository only). Please take another
look at your earliest convenience and let me know if there's anything else
you need from me.
-Elijah
On Tue, Jan 4, 2011 at 10:55 AM, Elijah Taylor elijahtay...@google.comwrote:
Replies inline:
On Tue, Jan 4, 2011 at 10:30 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
Some comments:
- the patch changes IMT_REG to AMD64_R11 in the non-nacl case, I'm not
sure thats
intentional.
Has this changed in the last six months on the Mono side? IIRC I didn't
mean to change anything like this. The reason I made explicit defines was
so code in aot-compiler and mini-amd64 could share defines over which reg
was the one we jump through and which was a scratch reg. I'll diff vs Mono
head revision and make it correct.
- you could define __mono_ilp32__ in the nacl/amd64 case, and use that
instead of
defined(__native_client_codegen__) defined(TARGET_AMD64) in a few
places.
That sounds reasonable. I'm assuming you mean non-arch specific areas like
mini.c, aot-*.c, method-to-ir.c, etc? Are there any other major
consequences to defining __mono_ilp32__ ?
- it would be better to define nacl_global_codeman_validate () as a no-op
in the non-nacl case, so its callers wouldn't need #ifdefs.
I'll fix this.
- genmdesc.c contains this change, which is probably not needed:
+void __nacl_suspend_thread_if_needed() {}
+
It is needed temporarily due to a preliminary GC implementation, we don't
have to submit it this way. Eventually (soon) we won't need it at all.
- you could use sizeof(mgreg_t) instead of SIZEOF_REGISTER to be
consistent with
the usage of sizeof(gpointer).
Sounds good. I'll try to use sizeof for all compiled code and only use
SIZEOF_REGISTER/SIZEOF_VOID_P for pre-processor directives only.
Other than these, I think the changes look fine, they aren't that
disruptive, since they don't
change the non-nacl behavior at all.
Great! I was worried just based on LOC changed that it might get more
resistance. In truth I'm more worried about future Mono changes
accidentally breaking NaCl behavior. I'm planning on getting some automated
testing implemented soon to combat this though.
On Tue, Dec 21, 2010 at 9:12 PM, Elijah Taylor
elijahtay...@google.comwrote:
Greetings Mono developers!
*[tl;dr very large patch for Native
Clienthttp://www.chromium.org/nativeclient support
hosted here https://github.com/elijahtaylor/mono, would love feedback
and many eyes to look at it]
*
I'm back with another round of changes for supporting Google's Native
Client (NaCl), including support for amd64, JIT compilation, and Garbage
Collection. It's a large set of changes, forked on Dec 14 in github @
https://github.com/elijahtaylor/mono. I would appreciate feedback on
these changes... to facilitate this, I'll try to explain the largest changes
by feature (please email if clarification is needed):
*1) amd64 codegen*
- Rules located here:
http://www.chromium.org/nativeclient/design-documents/nacl-sfi-model-on-x86-64-systems
- Removed %r15 from register allocation, LMF save/restore, etc.
(r15 is special and not modifiable by untrusted code)
- Sandbox all data access through membase address mode. If not
%rsp or %rbp relative, re-write as clearing upper 32-bits + memindex
addressing
- align functions, call sites
- Sandbox returns and all indirect jumps (need to be 32-byte
aligned, cleared upper 32-bits)
- Never omit frame pointer as general operations to rbp aren't
allowed
*2) NaCl x86-64 is ILP32 (this is the largest set of changes and may
make some mono devs unhappy)*
- Set SIZEOF_REGISTER == 8 while sizeof(gpointer) == 4 for NaCl amd64
(we can use 8-byte instructions, but pointers are 4-bytes)
- Re-write large portions of mini-amd64.c, tramp-amd64.c,
exceptions-amd64.c, mini.c, method-to-ir.c to use appropriate sizes
(SIZEOF_REGISTER, sizeof(gpointer), literal '8'). *These changes are
disruptive, but ultimately they should be more correct than what was
there
before. *It's our opinion that these changes actually improve Mono
despite their impact.
- We only generate NaCl amd64 code from an ILP32 machine (either a
32-bit application for AOT code, or NaCl runtime JIT), so we may not have
caught all of the [8 -- SIZEOF_REGISTER] conversions, but we likely
caught
most of the [sizeof(gpointer) -- SIZEOF_REGISTER] and [8 --
sizeof(gpointer)] changes that are necessary.
- Change atomic operations and default pointer directives to use
32-bit instructions (long instead of quad)
- Change default operations to use 32-bit integers/pointers (eg,
OP_LOAD_MEMBASE uses 4-bytes
Re: [Mono-dev] File not found error when using Activator.CreateInstanceFrom()
Are you still talking about Windows-only here? -- Spink On 5 January 2011 14:25, mike mgu...@knology.net wrote: Anybody else see this while using P/Invoke under mono? -- View this message in context: http://mono.1490590.n4.nabble.com/File-not-found-error-when-using-Activator-CreateInstanceFrom-tp3064104p3175616.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Tom Spink ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] File not found error when using Activator.CreateInstanceFrom()
Not sure what you mean. Actually, I was just refreshing the thread. ;-) See previous post and example code, If I p/Invoke to a single native dll, all is fine. However if that dll depends on a secondary native dll, I get an unhandled exception: System.DLLNotFoundException. Again, this scenario works fine under .NET, fails under 2.8 (under win mono) The issue seems to be related to p/Invoking a dynamic link library which depends on a second native dll. -- View this message in context: http://mono.1490590.n4.nabble.com/File-not-found-error-when-using-Activator-CreateInstanceFrom-tp3064104p3176193.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] more support for Google Native Client
Hi,
I think the current code looks ok, and we should think about how to merge
it into mono trunk. As a first step, could you rebase your master branch on
top of master to fix the few conflicts which has surfaced due to changes to
mono master ?
Zoltan
On Wed, Jan 5, 2011 at 8:23 PM, Elijah Taylor elijahtay...@google.comwrote:
Hi Zoltan,
I've addressed all of the issues you pointed out (minus genmdesc.c:
__nacl_suspend_thread_if_needed, but that doesn't need to be merged in at
this time, it can remain in my local repository only). Please take another
look at your earliest convenience and let me know if there's anything else
you need from me.
-Elijah
On Tue, Jan 4, 2011 at 10:55 AM, Elijah Taylor elijahtay...@google.comwrote:
Replies inline:
On Tue, Jan 4, 2011 at 10:30 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
Some comments:
- the patch changes IMT_REG to AMD64_R11 in the non-nacl case, I'm not
sure thats
intentional.
Has this changed in the last six months on the Mono side? IIRC I didn't
mean to change anything like this. The reason I made explicit defines was
so code in aot-compiler and mini-amd64 could share defines over which reg
was the one we jump through and which was a scratch reg. I'll diff vs Mono
head revision and make it correct.
- you could define __mono_ilp32__ in the nacl/amd64 case, and use that
instead of
defined(__native_client_codegen__) defined(TARGET_AMD64) in a few
places.
That sounds reasonable. I'm assuming you mean non-arch specific areas
like mini.c, aot-*.c, method-to-ir.c, etc? Are there any other major
consequences to defining __mono_ilp32__ ?
- it would be better to define nacl_global_codeman_validate () as a no-op
in the non-nacl case, so its callers wouldn't need #ifdefs.
I'll fix this.
- genmdesc.c contains this change, which is probably not needed:
+void __nacl_suspend_thread_if_needed() {}
+
It is needed temporarily due to a preliminary GC implementation, we don't
have to submit it this way. Eventually (soon) we won't need it at all.
- you could use sizeof(mgreg_t) instead of SIZEOF_REGISTER to be
consistent with
the usage of sizeof(gpointer).
Sounds good. I'll try to use sizeof for all compiled code and only use
SIZEOF_REGISTER/SIZEOF_VOID_P for pre-processor directives only.
Other than these, I think the changes look fine, they aren't that
disruptive, since they don't
change the non-nacl behavior at all.
Great! I was worried just based on LOC changed that it might get more
resistance. In truth I'm more worried about future Mono changes
accidentally breaking NaCl behavior. I'm planning on getting some automated
testing implemented soon to combat this though.
On Tue, Dec 21, 2010 at 9:12 PM, Elijah Taylor
elijahtay...@google.comwrote:
Greetings Mono developers!
*[tl;dr very large patch for Native
Clienthttp://www.chromium.org/nativeclient support
hosted here https://github.com/elijahtaylor/mono, would love feedback
and many eyes to look at it]
*
I'm back with another round of changes for supporting Google's Native
Client (NaCl), including support for amd64, JIT compilation, and Garbage
Collection. It's a large set of changes, forked on Dec 14 in github @
https://github.com/elijahtaylor/mono. I would appreciate feedback on
these changes... to facilitate this, I'll try to explain the largest
changes
by feature (please email if clarification is needed):
*1) amd64 codegen*
- Rules located here:
http://www.chromium.org/nativeclient/design-documents/nacl-sfi-model-on-x86-64-systems
- Removed %r15 from register allocation, LMF save/restore, etc.
(r15 is special and not modifiable by untrusted code)
- Sandbox all data access through membase address mode. If not
%rsp or %rbp relative, re-write as clearing upper 32-bits + memindex
addressing
- align functions, call sites
- Sandbox returns and all indirect jumps (need to be 32-byte
aligned, cleared upper 32-bits)
- Never omit frame pointer as general operations to rbp aren't
allowed
*2) NaCl x86-64 is ILP32 (this is the largest set of changes and may
make some mono devs unhappy)*
- Set SIZEOF_REGISTER == 8 while sizeof(gpointer) == 4 for NaCl
amd64 (we can use 8-byte instructions, but pointers are 4-bytes)
- Re-write large portions of mini-amd64.c, tramp-amd64.c,
exceptions-amd64.c, mini.c, method-to-ir.c to use appropriate sizes
(SIZEOF_REGISTER, sizeof(gpointer), literal '8'). *These changes
are disruptive, but ultimately they should be more correct than what was
there before. *It's our opinion that these changes actually improve
Mono despite their impact.
- We only generate NaCl amd64 code from an ILP32 machine (either a
32-bit application for AOT code, or NaCl runtime JIT), so we may not
have
caught all of the [8 -- SIZEOF_REGISTER] conversions,
Re: [Mono-dev] [PATCH] more support for Google Native Client
Zoltan,
I've rebased from mono's master branch and fixed all merge conflicts, but
something that's gone in since I first forked has now broken NaCl AOT
compilation for me. On amd64 the compiler just crashes and I'm looking into
that, nut on x86 I'm getting this: Can't use AOT image 'mscorlib' in
aot-only mode because it is not compiled with --aot=full. But I'm compiling
with --aot=full,static,nodebug,ntrampolines=4096
If need be I can pick through the AOT changes that have gone in, but I was
hoping you or someone on this list would be able to tell me the major
changes to AOT from the past 3 weeks and some ideas about what might be
getting in my way. Can you shed any light?
-Elijah
On Wed, Jan 5, 2011 at 3:51 PM, Zoltan Varga var...@gmail.com wrote:
Hi,
I think the current code looks ok, and we should think about how to merge
it into mono trunk. As a first step, could you rebase your master branch on
top of master to fix the few conflicts which has surfaced due to changes to
mono master ?
Zoltan
On Wed, Jan 5, 2011 at 8:23 PM, Elijah Taylor elijahtay...@google.comwrote:
Hi Zoltan,
I've addressed all of the issues you pointed out (minus genmdesc.c:
__nacl_suspend_thread_if_needed, but that doesn't need to be merged in at
this time, it can remain in my local repository only). Please take another
look at your earliest convenience and let me know if there's anything else
you need from me.
-Elijah
On Tue, Jan 4, 2011 at 10:55 AM, Elijah Taylor
elijahtay...@google.comwrote:
Replies inline:
On Tue, Jan 4, 2011 at 10:30 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
Some comments:
- the patch changes IMT_REG to AMD64_R11 in the non-nacl case, I'm not
sure thats
intentional.
Has this changed in the last six months on the Mono side? IIRC I didn't
mean to change anything like this. The reason I made explicit defines was
so code in aot-compiler and mini-amd64 could share defines over which reg
was the one we jump through and which was a scratch reg. I'll diff vs Mono
head revision and make it correct.
- you could define __mono_ilp32__ in the nacl/amd64 case, and use that
instead of
defined(__native_client_codegen__) defined(TARGET_AMD64) in a few
places.
That sounds reasonable. I'm assuming you mean non-arch specific areas
like mini.c, aot-*.c, method-to-ir.c, etc? Are there any other major
consequences to defining __mono_ilp32__ ?
- it would be better to define nacl_global_codeman_validate () as a
no-op in the non-nacl case, so its callers wouldn't need #ifdefs.
I'll fix this.
- genmdesc.c contains this change, which is probably not needed:
+void __nacl_suspend_thread_if_needed() {}
+
It is needed temporarily due to a preliminary GC implementation, we don't
have to submit it this way. Eventually (soon) we won't need it at all.
- you could use sizeof(mgreg_t) instead of SIZEOF_REGISTER to be
consistent with
the usage of sizeof(gpointer).
Sounds good. I'll try to use sizeof for all compiled code and only use
SIZEOF_REGISTER/SIZEOF_VOID_P for pre-processor directives only.
Other than these, I think the changes look fine, they aren't that
disruptive, since they don't
change the non-nacl behavior at all.
Great! I was worried just based on LOC changed that it might get more
resistance. In truth I'm more worried about future Mono changes
accidentally breaking NaCl behavior. I'm planning on getting some automated
testing implemented soon to combat this though.
On Tue, Dec 21, 2010 at 9:12 PM, Elijah Taylor elijahtay...@google.com
wrote:
Greetings Mono developers!
*[tl;dr very large patch for Native
Clienthttp://www.chromium.org/nativeclient support
hosted here https://github.com/elijahtaylor/mono, would love
feedback and many eyes to look at it]
*
I'm back with another round of changes for supporting Google's Native
Client (NaCl), including support for amd64, JIT compilation, and Garbage
Collection. It's a large set of changes, forked on Dec 14 in github @
https://github.com/elijahtaylor/mono. I would appreciate feedback on
these changes... to facilitate this, I'll try to explain the largest
changes
by feature (please email if clarification is needed):
*1) amd64 codegen*
- Rules located here:
http://www.chromium.org/nativeclient/design-documents/nacl-sfi-model-on-x86-64-systems
- Removed %r15 from register allocation, LMF save/restore, etc.
(r15 is special and not modifiable by untrusted code)
- Sandbox all data access through membase address mode. If not
%rsp or %rbp relative, re-write as clearing upper 32-bits + memindex
addressing
- align functions, call sites
- Sandbox returns and all indirect jumps (need to be 32-byte
aligned, cleared upper 32-bits)
- Never omit frame pointer as general operations to rbp aren't
allowed
*2) NaCl x86-64 is ILP32 (this is the largest set of
Re: [Mono-dev] [PATCH] more support for Google Native Client
Hi,
On Thu, Jan 6, 2011 at 1:24 AM, Elijah Taylor elijahtay...@google.comwrote:
Zoltan,
I've rebased from mono's master branch and fixed all merge conflicts, but
something that's gone in since I first forked has now broken NaCl AOT
compilation for me. On amd64 the compiler just crashes and I'm looking into
that, nut on x86 I'm getting this: Can't use AOT image 'mscorlib' in
aot-only mode because it is not compiled with --aot=full. But I'm
compiling with --aot=full,static,nodebug,ntrampolines=4096
If need be I can pick through the AOT changes that have gone in, but I was
hoping you or someone on this list would be able to tell me the major
changes to AOT from the past 3 weeks and some ideas about what might be
getting in my way. Can you shed any light?
There was a big reorganization in the AOT file format to reduce the number
of global symbols exported from the aot images. No idea why this is causing
problems. make fullaotcheck and make fsacheck still seems to work for me on
x86. I fixed a uninitilized memory error in 88d676ffd425def3, maybe that
will help.
Zoltan
-Elijah
On Wed, Jan 5, 2011 at 3:51 PM, Zoltan Varga var...@gmail.com wrote:
Hi,
I think the current code looks ok, and we should think about how to
merge it into mono trunk. As a first step, could you rebase your master
branch on top of master to fix the few conflicts which has surfaced due to
changes to mono master ?
Zoltan
On Wed, Jan 5, 2011 at 8:23 PM, Elijah Taylor elijahtay...@google.comwrote:
Hi Zoltan,
I've addressed all of the issues you pointed out (minus genmdesc.c:
__nacl_suspend_thread_if_needed, but that doesn't need to be merged in at
this time, it can remain in my local repository only). Please take another
look at your earliest convenience and let me know if there's anything else
you need from me.
-Elijah
On Tue, Jan 4, 2011 at 10:55 AM, Elijah Taylor
elijahtay...@google.comwrote:
Replies inline:
On Tue, Jan 4, 2011 at 10:30 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
Some comments:
- the patch changes IMT_REG to AMD64_R11 in the non-nacl case, I'm not
sure thats
intentional.
Has this changed in the last six months on the Mono side? IIRC I didn't
mean to change anything like this. The reason I made explicit defines was
so code in aot-compiler and mini-amd64 could share defines over which reg
was the one we jump through and which was a scratch reg. I'll diff vs Mono
head revision and make it correct.
- you could define __mono_ilp32__ in the nacl/amd64 case, and use that
instead of
defined(__native_client_codegen__) defined(TARGET_AMD64) in a few
places.
That sounds reasonable. I'm assuming you mean non-arch specific areas
like mini.c, aot-*.c, method-to-ir.c, etc? Are there any other major
consequences to defining __mono_ilp32__ ?
- it would be better to define nacl_global_codeman_validate () as a
no-op in the non-nacl case, so its callers wouldn't need #ifdefs.
I'll fix this.
- genmdesc.c contains this change, which is probably not needed:
+void __nacl_suspend_thread_if_needed() {}
+
It is needed temporarily due to a preliminary GC implementation, we
don't have to submit it this way. Eventually (soon) we won't need it at
all.
- you could use sizeof(mgreg_t) instead of SIZEOF_REGISTER to be
consistent with
the usage of sizeof(gpointer).
Sounds good. I'll try to use sizeof for all compiled code and only use
SIZEOF_REGISTER/SIZEOF_VOID_P for pre-processor directives only.
Other than these, I think the changes look fine, they aren't that
disruptive, since they don't
change the non-nacl behavior at all.
Great! I was worried just based on LOC changed that it might get more
resistance. In truth I'm more worried about future Mono changes
accidentally breaking NaCl behavior. I'm planning on getting some
automated
testing implemented soon to combat this though.
On Tue, Dec 21, 2010 at 9:12 PM, Elijah Taylor
elijahtay...@google.com wrote:
Greetings Mono developers!
*[tl;dr very large patch for Native
Clienthttp://www.chromium.org/nativeclient support
hosted here https://github.com/elijahtaylor/mono, would love
feedback and many eyes to look at it]
*
I'm back with another round of changes for supporting Google's Native
Client (NaCl), including support for amd64, JIT compilation, and Garbage
Collection. It's a large set of changes, forked on Dec 14 in github @
https://github.com/elijahtaylor/mono. I would appreciate feedback on
these changes... to facilitate this, I'll try to explain the largest
changes
by feature (please email if clarification is needed):
*1) amd64 codegen*
- Rules located here:
http://www.chromium.org/nativeclient/design-documents/nacl-sfi-model-on-x86-64-systems
- Removed %r15 from register allocation, LMF save/restore, etc.
(r15 is special and not modifiable by untrusted
Re: [Mono-dev] [PATCH] more support for Google Native Client
Hi,
This should work as follows: every aot image contains a MonoAotFileInfo
structure,
emitted in emit_file_info () in aot-compiler.c, which has a 'flags' field,
and the MONO_AOT_FILE_FLAG_FULL_AOT flag should be set in
this field. At runtime, check_usable() in aot-runtime.c checks this flag.
Zoltan
On Thu, Jan 6, 2011 at 2:10 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
On Thu, Jan 6, 2011 at 1:24 AM, Elijah Taylor elijahtay...@google.comwrote:
Zoltan,
I've rebased from mono's master branch and fixed all merge conflicts, but
something that's gone in since I first forked has now broken NaCl AOT
compilation for me. On amd64 the compiler just crashes and I'm looking into
that, nut on x86 I'm getting this: Can't use AOT image 'mscorlib' in
aot-only mode because it is not compiled with --aot=full. But I'm
compiling with --aot=full,static,nodebug,ntrampolines=4096
If need be I can pick through the AOT changes that have gone in, but I was
hoping you or someone on this list would be able to tell me the major
changes to AOT from the past 3 weeks and some ideas about what might be
getting in my way. Can you shed any light?
There was a big reorganization in the AOT file format to reduce the number
of global symbols exported from the aot images. No idea why this is causing
problems. make fullaotcheck and make fsacheck still seems to work for me on
x86. I fixed a uninitilized memory error in 88d676ffd425def3, maybe that
will help.
Zoltan
-Elijah
On Wed, Jan 5, 2011 at 3:51 PM, Zoltan Varga var...@gmail.com wrote:
Hi,
I think the current code looks ok, and we should think about how to
merge it into mono trunk. As a first step, could you rebase your master
branch on top of master to fix the few conflicts which has surfaced due to
changes to mono master ?
Zoltan
On Wed, Jan 5, 2011 at 8:23 PM, Elijah Taylor
elijahtay...@google.comwrote:
Hi Zoltan,
I've addressed all of the issues you pointed out (minus genmdesc.c:
__nacl_suspend_thread_if_needed, but that doesn't need to be merged in at
this time, it can remain in my local repository only). Please take another
look at your earliest convenience and let me know if there's anything else
you need from me.
-Elijah
On Tue, Jan 4, 2011 at 10:55 AM, Elijah Taylor elijahtay...@google.com
wrote:
Replies inline:
On Tue, Jan 4, 2011 at 10:30 AM, Zoltan Varga var...@gmail.comwrote:
Hi,
Some comments:
- the patch changes IMT_REG to AMD64_R11 in the non-nacl case, I'm not
sure thats
intentional.
Has this changed in the last six months on the Mono side? IIRC I
didn't mean to change anything like this. The reason I made explicit
defines was so code in aot-compiler and mini-amd64 could share defines
over
which reg was the one we jump through and which was a scratch reg. I'll
diff vs Mono head revision and make it correct.
- you could define __mono_ilp32__ in the nacl/amd64 case, and use that
instead of
defined(__native_client_codegen__) defined(TARGET_AMD64) in a few
places.
That sounds reasonable. I'm assuming you mean non-arch specific areas
like mini.c, aot-*.c, method-to-ir.c, etc? Are there any other major
consequences to defining __mono_ilp32__ ?
- it would be better to define nacl_global_codeman_validate () as a
no-op in the non-nacl case, so its callers wouldn't need #ifdefs.
I'll fix this.
- genmdesc.c contains this change, which is probably not needed:
+void __nacl_suspend_thread_if_needed() {}
+
It is needed temporarily due to a preliminary GC implementation, we
don't have to submit it this way. Eventually (soon) we won't need it at
all.
- you could use sizeof(mgreg_t) instead of SIZEOF_REGISTER to be
consistent with
the usage of sizeof(gpointer).
Sounds good. I'll try to use sizeof for all compiled code and only use
SIZEOF_REGISTER/SIZEOF_VOID_P for pre-processor directives only.
Other than these, I think the changes look fine, they aren't that
disruptive, since they don't
change the non-nacl behavior at all.
Great! I was worried just based on LOC changed that it might get more
resistance. In truth I'm more worried about future Mono changes
accidentally breaking NaCl behavior. I'm planning on getting some
automated
testing implemented soon to combat this though.
On Tue, Dec 21, 2010 at 9:12 PM, Elijah Taylor
elijahtay...@google.com wrote:
Greetings Mono developers!
*[tl;dr very large patch for Native
Clienthttp://www.chromium.org/nativeclient support
hosted here https://github.com/elijahtaylor/mono, would love
feedback and many eyes to look at it]
*
I'm back with another round of changes for supporting Google's Native
Client (NaCl), including support for amd64, JIT compilation, and Garbage
Collection. It's a large set of changes, forked on Dec 14 in github @
https://github.com/elijahtaylor/mono. I would appreciate
Re: [Mono-dev] [PATCH] more support for Google Native Client
Ok, I'll check out the changes/info you mentioned and go through the files
that auto-merged, too. Probably won't get this done for at least a day or
so, but I'll rebase again once I've fixed it. Hopefully by that point
something else won't have broken too :)
-Elijah
On Wed, Jan 5, 2011 at 5:19 PM, Zoltan Varga var...@gmail.com wrote:
Hi,
This should work as follows: every aot image contains a MonoAotFileInfo
structure,
emitted in emit_file_info () in aot-compiler.c, which has a 'flags' field,
and the MONO_AOT_FILE_FLAG_FULL_AOT flag should be set in
this field. At runtime, check_usable() in aot-runtime.c checks this flag.
Zoltan
On Thu, Jan 6, 2011 at 2:10 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
On Thu, Jan 6, 2011 at 1:24 AM, Elijah Taylor elijahtay...@google.comwrote:
Zoltan,
I've rebased from mono's master branch and fixed all merge conflicts, but
something that's gone in since I first forked has now broken NaCl AOT
compilation for me. On amd64 the compiler just crashes and I'm looking into
that, nut on x86 I'm getting this: Can't use AOT image 'mscorlib' in
aot-only mode because it is not compiled with --aot=full. But I'm
compiling with --aot=full,static,nodebug,ntrampolines=4096
If need be I can pick through the AOT changes that have gone in, but I
was hoping you or someone on this list would be able to tell me the major
changes to AOT from the past 3 weeks and some ideas about what might be
getting in my way. Can you shed any light?
There was a big reorganization in the AOT file format to reduce the number
of global symbols exported from the aot images. No idea why this is causing
problems. make fullaotcheck and make fsacheck still seems to work for me on
x86. I fixed a uninitilized memory error in 88d676ffd425def3, maybe that
will help.
Zoltan
-Elijah
On Wed, Jan 5, 2011 at 3:51 PM, Zoltan Varga var...@gmail.com wrote:
Hi,
I think the current code looks ok, and we should think about how to
merge it into mono trunk. As a first step, could you rebase your master
branch on top of master to fix the few conflicts which has surfaced due to
changes to mono master ?
Zoltan
On Wed, Jan 5, 2011 at 8:23 PM, Elijah Taylor
elijahtay...@google.comwrote:
Hi Zoltan,
I've addressed all of the issues you pointed out (minus genmdesc.c:
__nacl_suspend_thread_if_needed, but that doesn't need to be merged in at
this time, it can remain in my local repository only). Please take
another
look at your earliest convenience and let me know if there's anything else
you need from me.
-Elijah
On Tue, Jan 4, 2011 at 10:55 AM, Elijah Taylor
elijahtay...@google.com wrote:
Replies inline:
On Tue, Jan 4, 2011 at 10:30 AM, Zoltan Varga var...@gmail.comwrote:
Hi,
Some comments:
- the patch changes IMT_REG to AMD64_R11 in the non-nacl case, I'm
not sure thats
intentional.
Has this changed in the last six months on the Mono side? IIRC I
didn't mean to change anything like this. The reason I made explicit
defines was so code in aot-compiler and mini-amd64 could share defines
over
which reg was the one we jump through and which was a scratch reg. I'll
diff vs Mono head revision and make it correct.
- you could define __mono_ilp32__ in the nacl/amd64 case, and use
that instead of
defined(__native_client_codegen__) defined(TARGET_AMD64) in a
few places.
That sounds reasonable. I'm assuming you mean non-arch specific areas
like mini.c, aot-*.c, method-to-ir.c, etc? Are there any other major
consequences to defining __mono_ilp32__ ?
- it would be better to define nacl_global_codeman_validate () as a
no-op in the non-nacl case, so its callers wouldn't need #ifdefs.
I'll fix this.
- genmdesc.c contains this change, which is probably not needed:
+void __nacl_suspend_thread_if_needed() {}
+
It is needed temporarily due to a preliminary GC implementation, we
don't have to submit it this way. Eventually (soon) we won't need it at
all.
- you could use sizeof(mgreg_t) instead of SIZEOF_REGISTER to be
consistent with
the usage of sizeof(gpointer).
Sounds good. I'll try to use sizeof for all compiled code and only
use SIZEOF_REGISTER/SIZEOF_VOID_P for pre-processor directives only.
Other than these, I think the changes look fine, they aren't that
disruptive, since they don't
change the non-nacl behavior at all.
Great! I was worried just based on LOC changed that it might get more
resistance. In truth I'm more worried about future Mono changes
accidentally breaking NaCl behavior. I'm planning on getting some
automated
testing implemented soon to combat this though.
On Tue, Dec 21, 2010 at 9:12 PM, Elijah Taylor
elijahtay...@google.com wrote:
Greetings Mono developers!
*[tl;dr very large patch for Native
Clienthttp://www.chromium.org/nativeclient support
hosted here
[Mono-list] Site downloads section incompatible with IE
Hello, This is not software-related at all, just noticed that the Mono website's downloads section ( http://www.go-mono.com/mono-downloads/download.html http://www.go-mono.com/mono-downloads/download.html ) doesn't work with Internet Explorer... If you try to click on one platform's icons, it does nothing but brings a JavaScript error. Tested with IE7 and IE8 on two computers. Works with Firefox. Doesn't know who cares but it might harm the project's accessibility... -- View this message in context: http://mono.1490590.n4.nabble.com/Site-downloads-section-incompatible-with-IE-tp3175156p3175156.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Site downloads section incompatible with IE
This is not software-related at all, just noticed that the Mono website's downloads section ( http://www.go-mono.com/mono-downloads/download.html http://www.go-mono.com/mono-downloads/download.html ) doesn't work with Internet Explorer... If you try to click on one platform's icons, it does nothing but brings a JavaScript error. Tested with IE7 and IE8 on two computers. Works with Firefox. Doesn't know who cares but it might harm the project's accessibility... If anyone cares, this happens due to the following line of code in download.js: document.getElementById(stable_td + i).style.removeProperty(background); IE, in its infinite wisdom, has decided not to support the removeProperty method and instead has a removeAttribute method. Or, you can just set background to null or empty string. Ugh DOM stuff sucks, but yea this should be fixed. Mike ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] ANN: Pyjama Project, and need help
Hello mono-list; hope this is appropriate place to post! After some initial prototypes, we are heading in a general direction with our cross-platform IDE incorporating Mono, Gtk#, the DLR, and associated languages for education. I'm looking for some feedback on current implementation, so if you have the inclination, your feedback is appreciated! The project is called Pyjama, and has a homepage here: http://PyjamaProject.org/ Overview videos: http://pyjamaproject.org/PyjamaScreenShots#Prototype_3 Quickstart instructions: You can download the current packaged Pyjama (7MB) from: http://myro.roboteducation.org/~dblank/download/ and unzip. You'll need a current installation of Mono, Gtk, and optionally Gtk-SourceView (for nice source code highlighting and line numbering). Start with Pyjama/pyjama and try loading some of the Pyjama/examples/ (Windows has a hardcoded path to Mono in src/pyjama.py). Additional information available on the website. Briefly: There are 5 directories in the Pyjama folder: bin - contains the startup files, and language dll files for languages bin/Lib - contains the standard language (ie, Python) libraries languages - contains the language definition files for Python, Ruby, Scheme, and Dinah modules - Cross-language modules that can be used by all Pyjama languages examples - sample code src - the source code for the Pyjama Project Pyjama is written in IronPython, using the Gtk# graphical user interface. The Python files for the Pyjama Project are in Pyjama/src/*.py. They are: document.py - base classes for Document interface editor.py - the Editor Window engine.py - base classes for the Engine interface pyjama.py - setup and startup code reflection.py - code to read DLL data shell.py - the Shell Window utils.py - utility functions and classes window.py - base class for Shell and Editor Pyjama is an editor and executor of code from a Language. Languages are defined in Pyjama/languages and define two items: editor document, and an executor engine. Pyjama has 5 languages, in various states of completeness: Python (finished) Ruby (nearly finished) Scheme (somewhat working) Sympl (example language in Python) Dinah (drag and drop language, just started) You can switch between languages in the shell with Ctrl+1 through Ctrl+4. A Language file in Pyjama/languages/*.py defines the editing document, and the shell executor API. Documents can do things like open, save, and display data for editing. Engines can do things like execute, execute_file, and parse files. Engines also allow for the languages to share data and functionality. There is a long list of items to be completed just to be functional, and I'll be working on this full time this semester. If anyone would like to join this open source project, please let me know. There are a couple of hacky seeming spots that I'd like to clean up: 1. Is the background executing code appropriately done? See Pyjama/src/shell.py 2. In a couple of places I'm using ManualResetEvent, Gtk.Application.Invoke, and WaitOne; is that the best way to accomplish syncing between threads? See grep ManualResetEvent src/*.py 3. The error display code doesn't always work. See grep EXCEPTION */*.py Any feedback appreciated! -Doug ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] taglib-sharp
It appears Novell has (or had) a C# library named taglib-sharp for editing ID3 tags commonly found in MP3 files (and other audio files.) There doesn't appear to be any download link for it on Novell's web site. Does anyone know how I can get this library? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] taglib-sharp
Hi, Wouldn't it be what you're looking for ? http://www.novell.com/products/linuxpackages/opensuse11/taglib-sharp.html http://www.novell.com/products/linuxpackages/opensuse11/taglib-sharp.html -- View this message in context: http://mono.1490590.n4.nabble.com/taglib-sharp-tp3176268p3176327.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] why does gmcs let me assign null to a value type?
csharp newbie
I have a C# struct that's defined as
public struct Field : IComparable, IComparableField,
IEquatableField
{
}
When I do this:
Field f = null;
I'd expect error CS0037 (can't convert null to 'Field' because it is a value
type.
But when Field is defined in an assembly that was compiled by VisStudio, gmcs
(v2.8.1.0) is happy to let me assign null to it.
Why?
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] taglib-sharp
On Wed, Jan 5, 2011 at 2:41 PM, Steve Lessard s_less...@yahoo.com wrote: It appears Novell has (or had) a C# library named taglib-sharp for editing ID3 tags commonly found in MP3 files (and other audio files.) There doesn't appear to be any download link for it on Novell's web site. Does anyone know how I can get this library? http://download.banshee-project.org/taglib-sharp/ https://github.com/mono/taglib-sharp/ -- Michael Hutchinson http://mjhutchinson.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Not writing all of the data to file
I have the following routine, Match result = regex.Match(rule); Match mat = payload.Match(rule); // Console.WriteLine( result.Groups[alert].Value + , + result.Groups[proto].Value + , + result.Groups[sip].Value + , + result.Groups[sport].Value + , + result.Groups[direc].Value + , + result.Groups[dest].Value + , + result.Groups[dport].Value + , + mat.Groups[pl].Value ); sw.WriteLine( result.Groups[alert].Value + , + result.Groups[proto].Value + , + result.Groups[sip].Value + , + result.Groups[sport].Value + , + result.Groups[direc].Value + , + result.Groups[dest].Value + , + result.Groups[dport].Value + , + mat.Groups[pl].Value ); sw.Close(); When i use just Console.WriteLine, it will display the whole file, but when i use the StreamWriter (sw.WriteLine) it only write the last line of the file. I have tried many different combinations and still nothing it either writes a single line, or it reapts the same line creating a huge, megabyte file. -- View this message in context: http://mono.1490590.n4.nabble.com/Not-writing-all-of-the-data-to-file-tp3176369p3176369.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] why does gmcs let me assign null to a value type?
I hate this behavior, and I believe it was introduced around c# 3
On Wednesday, January 5, 2011, Eric Slosser eric.slos...@v-fx.com wrote:
csharp newbie
I have a C# struct that's defined as
public struct Field : IComparable, IComparableField,
IEquatableField
{
}
When I do this:
Field f = null;
I'd expect error CS0037 (can't convert null to 'Field' because it is a value
type.
But when Field is defined in an assembly that was compiled by VisStudio, gmcs
(v2.8.1.0) is happy to let me assign null to it.
Why?
___
Mono-list maillist - mono-l...@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] mono compiler: error CS0115 when overriding a method
Hello,
I try to compile a file that contains a class that inherits from another one
which is defined in an external assembly. The class from the file override a
method marked as virtual but when i try to compile it with gmcs it give me
the following error:
src\extensions\apps.cs(911,50): error CS0115:
`Google.GData.Extensions.Apps.Rfc8
22MsgElement.CreateInstance(System.Xml.XmlNode,
Google.GData.Client.AtomFeedPars
er)' is marked as an override but no suitable method found to override
I use this command to compile (the version of mono is 2.8.1):
C:\Program Files\Mono-2.8\bin\gmcs /d:TRACE;MonoDroid -target:library
-out:Google.GData.Extensions.dll -r:Google.GData.Client.dll -noconfig
-nostdlib+ -r:C:\Program Files\Reference
Assemblies\Microsoft\Framework\MonoDroid\v2.0\mscorlib.dll -r:C:\Program
Files\Reference Assemblies\Microsoft\Framework\MonoDroid\v2.0\System.dll
-r:C:\Program Files\Reference
Assemblies\Microsoft\Framework\MonoDroid\v2.0\System.Xml.dll -r:C:\Program
Files\Reference
Assemblies\Microsoft\Framework\MonoDroid\v2.0\System.Web.Services.dll
src\extensions\apps.cs
The compilation of the file works with the .NET compiler with the same
command arguments:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe /d:TRACE;MonoDroid
-target:library -out:Google.GData.Extensions.dll -r:Google.GData.Client.dll
-noconfig -nostdlib+ -r:C:\Program Files\Reference
Assemblies\Microsoft\Framework\MonoDroid\v2.0\mscorlib.dll -r:C:\Program
Files\Reference Assemblies\Microsoft\Framework\MonoDroid\v2.0\System.dll
-r:C:\Program Files\Reference
Assemblies\Microsoft\Framework\MonoDroid\v2.0\System.Xml.dll -r:C:\Program
Files\Reference
Assemblies\Microsoft\Framework\MonoDroid\v2.0\System.Web.Services.dll
src\extensions\apps.cs
The code looks like this (these lines of code are from the gdata library
http://code.google.com/p/google-gdata/):
public abstract class ExtensionBase : IExtensionElementFactory,
IVersionAware
{
public virtual IExtensionElementFactory CreateInstance(XmlNode node,
AtomFeedParser parser)
{
// some codes here
}
}
public class Rfc822MsgElement : ExtensionBase
{
public override IExtensionElementFactory CreateInstance(XmlNode node,
AtomFeedParser parser)
{
// some codes here
}
}
Do i need to do something special to get it to compile with mono?
Thanks,
--
View this message in context:
http://mono.1490590.n4.nabble.com/mono-compiler-error-CS0115-when-overriding-a-method-tp3176455p3176455.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] where can I find mod_mono.conf?
On 12/29/2010 10:13 PM, ghader wrote: Hi, Where can I find mod_mono.conf for windows? As you know, in the web page for autohosting (I mean http://www.mono-project.com/AutoHosting) is been written that include mod_mono.conf in your apache config file in order to auto host your ASP.NET application. But the problem is that I couldn't figure out where to find mod_mono.conf in order to include it in my apache config file. Regards, Hamidreza Ghader I have come to believe that mono does not run very well on Windows when it comes to web hosting. The documentation that I find online and on the mono pages aren't very encouraging. If you wish to run mono, your best bet is to stick with Linux. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
