Paul Johnson | 30 Aug 11:33 2014
Picon

Parallella Epiphany III


Hi,

I've just ordered one of these development boards from RS Components
in the UK
(http://uk.rs-online.com/web/p/processor-microcontroller-development-kits/8194709/).
It's similar to the RPi in many ways, but has the far more powerful
ARM Cortex 9 processor on it.

I know the RPi has a version of Mono for it and that Mono is available
for ARM in general. Is there anything I should be looking out for when
building Mono for the Parallella with an ARM 9 or should it be
straight forward.

The board uses the gcc toolchain and a bog standard Linux distro (not
sure which flavour though).

TIA

Paul
--

-- 
Out now from Packt Publishing - "Xamarin Mobile Application
Development for iOS" - my first book
http://www.packtpub.com/xamarin-mobile-application-development-for-ios/book
Peter Dobson | 27 Aug 12:52 2014

Running NUnit from Linux

Hi,

 

I have done a fix for a bug I raised a while back (16256) which I would like to eventually submit, with some unit tests. Is there a way of easily running the NUnit tests, preferably from a Linux command line?

 

Thanks,

 

Peter

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Bob Summerwill | 27 Aug 08:07 2014
Picon

Unite 2014 - IL2CPP: The next generation of scripting in Unity


Video of the session on Unity's work-in-progress IL2PP technology:



This is their alternative to signing a new licensing deal with Xamarin after the fall-out of licensing Mono-2.6 from Novell, and getting left holding the baby.

Bonkers if you ask me, but I thought it might be of interest to some people here.


Cheers,
Bob Summerwill
Kitsilano Software
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Liwei Peng | 27 Aug 00:26 2014
Picon

Performance tests/benchmarks for mono

Hi Mono team,

 

I am evaluating mono for Linux (Ubuntu). One of my plans is to evaluate mono CLR perf compared with Windows .NET CLR perf.

 

Questions:

1)      What perf/benchmark tests are available for me to run for mono?

2)      Can you share some docs/links for them?

 

Thanks,

 

Liwei

 

 

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Bob Summerwill | 26 Aug 19:57 2014
Picon

Known issue with xbuild and line-feeds in Cygwin?


I have inherited a shell script with a horrible line of sed in it which OS X doesn't like, to deal with line-end issues in xbuild under Cygwin ...


# Check if we are running under Windows(cygwin) OR *nix, and use xbuild OR MSBuild.exe accordingly
set isRunningCygwin=`uname | grep CYGWIN`
if ( $isRunningCygwin == '' ) then
    # This LINUX machine should have Mono and friends (xbuild) installed
    set builder=`which xbuild`
else
    # This WINDOWS machine should have .Net Framework installed
    set builder=`find /cygdrive/c/Windows/Microsoft.NET/Framework/v4.0* -name MSBuild.exe`
endif

if ($builder == '') then
    echo "Unable to find 'xbuild' (Linux) OR 'MSBuild.exe' (Windows) to build Solution, bailing!"
    exit -1
endif

# Switch directories to get around silly MSBuild vs Cygwin issues
cd ../LucyServer
sed -i '/^$/d' ${LucyServerSolution}
$builder ${LucyServerSolution} /verbosity:quiet /p:Configuration=Release
cd ../Scripts


Is this something which is familiar to other xbuild users?

I  _think_ that the sed is trying to replace Windows-style line-endings in the SLN with Linux-style line-endings, though that shouldn't be necessary.

I think there is a bug report in here, when I can figure out exactly what is going wrong.

On Mac OSX the sed line barfs and fails.    Without the sed line the Cygwin build just silently doesn't build anything.


Cheers,
Bob


--
bob <at> summerwill.net

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Bob Summerwill | 24 Aug 04:52 2014
Picon

CHALLENGE to Miguel de Icaza!


Miguel,

I've just done the ALS Icebucket Challenge, and I am throwing down the gauntlet to you.   I know it's all getting a bit long in the tooth, so I will sweeten the pot by making a donation to the charity of your choice in addition to ALS:


Over to you!


Cheers,
Bob


--
bob <at> summerwill.net

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
mono user | 22 Aug 16:55 2014
Picon

Mono crash

Is there anything I can do to avoid the following crash? I am running Mono 3.6.0. I am not using any native libraries that don't ship witth Mono. Many thanks.


Stacktrace:


Native stacktrace:


Debug info from gdb:

Mono support loaded.
[Thread debugging using libthread_db enabled]
[New Thread 0x7fba882d4700 (LWP 7103)]
[New Thread 0x7fba88315700 (LWP 7102)]
[New Thread 0x7fba833d0700 (LWP 7100)]
[New Thread 0x7fba88b0e700 (LWP 7099)]
0x00007fba90992cd4 in sigsuspend () from /lib64/libc.so.6
  5 Thread 0x7fba88b0e700 (LWP 7099)  0x00007fba90992cd4 in sigsuspend () from /lib64/libc.so.6
  4 Thread 0x7fba833d0700 (LWP 7100)  0x00007fba90d032ad in waitpid () from /lib64/libpthread.s        o.0
  3 Thread 0x7fba88315700 (LWP 7102)  0x00007fba90a49163 in epoll_wait () from /lib64/libc.so.6
  2 Thread 0x7fba882d4700 (LWP 7103)  0x00007fba90d01a21 in sem_timedwait () from /lib64/libpth        read.so.0
* 1 Thread 0x7fba917ab780 (LWP 7098)  0x00007fba90992cd4 in sigsuspend () from /lib64/libc.so.6

Thread 5 (Thread 0x7fba88b0e700 (LWP 7099)):
#0  0x00007fba90992cd4 in sigsuspend () from /lib64/libc.so.6
#1  0x00000000005cac54 in suspend_thread (sig=<value optimized out>, siginfo=<value optimized o        ut>, context=0x7fba88b0d780) at sgen-os-posix.c:113
#2  suspend_handler (sig=<value optimized out>, siginfo=<value optimized out>, context=0x7fba88        b0d780) at sgen-os-posix.c:140
#3  <signal handler called>
#4  0x00007fba90d0192e in sem_wait () from /lib64/libpthread.so.0
#5  0x000000000062c488 in mono_sem_wait (sem=0x977ca0, alertable=1) at mono-semaphore.c:101
#6  0x00000000005a501a in finalizer_thread (unused=<value optimized out>) at gc.c:1073
#7  0x00000000005823ab in start_wrapper_internal (data=<value optimized out>) at threads.c:660
#8  start_wrapper (data=<value optimized out>) at threads.c:707
#9  0x0000000000631b16 in inner_start_thread (arg=<value optimized out>) at mono-threads-posix.        c:100
#10 0x00007fba90cfb9d1 in start_thread () from /lib64/libpthread.so.0
#11 0x00007fba90a48b6d in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7fba833d0700 (LWP 7100)):
#0  0x00007fba90d032ad in waitpid () from /lib64/libpthread.so.0
#1  0x00000000004a33f8 in mono_handle_native_sigsegv (signal=<value optimized out>, ctx=<value         optimized out>) at mini-exceptions.c:2305
#2  0x00000000005005cf in mono_arch_handle_altstack_exception (sigctx=0x7fba9173bac0, fault_add        r=<value optimized out>, stack_ovf=0) at exceptions-amd64.c:905
#3  0x0000000000415b69 in mono_sigsegv_signal_handler (_dummy=11, info=0x7fba9173bbf0, context=        0x7fba9173bac0) at mini.c:6842
#4  <signal handler called>
#5  alloc_sb (heap=0x979530) at lock-free-alloc.c:166
#6  alloc_from_new_sb (heap=0x979530) at lock-free-alloc.c:415
#7  mono_lock_free_alloc (heap=0x979530) at lock-free-alloc.c:459
#8  0x00000000005d4bc7 in sgen_alloc_internal (type=<value optimized out>) at sgen-internal.c:1        69
#9  0x00000000005eda92 in sgen_gray_object_alloc_queue_section (queue=0x978ba0) at sgen-gray.c:        58
#10 0x00000000005edadd in sgen_gray_object_enqueue (queue=0x978ba0, obj=<value optimized out>)         at sgen-gray.c:96
#11 0x00000000005d0a1c in pin_objects_from_addresses (section=0x7fba91744010, start=<value opti        mized out>, end=0x7fb481428040, start_nursery=<value optimized out>, end_nursery=<value optimiz        ed out>, ctx=...) at sgen-gc.c:987
#12 0x00000000005d0afb in sgen_pin_objects_in_section (section=0x7fba91744010, ctx=...) at sgen        -gc.c:1025
#13 0x00000000005d2d81 in collect_nursery (unpin_queue=0x0, finish_up_concurrent_mark=0) at sge        n-gc.c:2284
#14 0x00000000005d3d88 in sgen_perform_collection (requested_size=4096, generation_to_collect=0        , reason=0x706be2 "Nursery full", wait_to_finish=<value optimized out>) at sgen-gc.c:3174
#15 0x00000000005f0c64 in mono_gc_alloc_obj_nolock (vtable=0x7fb78073c190
0xbcc240
0xbcc240
0x7fb78073c190
0x7fb78073c190
vtable(%s), size=<value optimized out>) at sgen-alloc.c:314
#16 0x00000000005f1074 in mono_gc_alloc_obj (vtable=0x7fb78073c190
0xbcc240
0xbcc240
0x7fb78073c190
0x7fb78073c190
vtable(%s), size=40) at sgen-alloc.c:490
#17 0x0000000041e50e83 in ?? ()
#18 0x00007fb9fc0025d0 in ?? ()
#19 0x00007fb44dd3cda8 in ?? ()
#20 0x0000000000000028 in ?? ()
#21 0x00007fba8a778ef0 in ?? ()
#22 0x00007fba83279d20 in ?? ()
#23 0x00007fba8a553e58 in ?? ()
#24 0x00007fba8a553e30 in ?? ()
#25 0x00007fba833d06e0 in ?? ()
#26 0x00007fb780721a38 in ?? ()
#27 0x0000000041e4d004 in ?? ()
#28 0x00007fb4e5be8c70 in ?? ()
#29 0x0000000000000000 in ?? ()

Thread 3 (Thread 0x7fba88315700 (LWP 7102)):
#0  0x00007fba90a49163 in epoll_wait () from /lib64/libc.so.6
#1  0x0000000000585e0a in tp_epoll_wait (p=0x9776a0) at ../../mono/metadata/tpool-epoll.c:118
#2  0x00000000005823ab in start_wrapper_internal (data=<value optimized out>) at threads.c:660
#3  start_wrapper (data=<value optimized out>) at threads.c:707
#4  0x0000000000631b16 in inner_start_thread (arg=<value optimized out>) at mono-threads-posix.        c:100
#5  0x00007fba90cfb9d1 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fba90a48b6d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7fba882d4700 (LWP 7103)):
#0  0x00007fba90d01a21 in sem_timedwait () from /lib64/libpthread.so.0
#1  0x000000000062c59c in mono_sem_timedwait (sem=0x977808, timeout_ms=<value optimized out>, a        lertable=1) at mono-semaphore.c:64
#2  0x00000000005870ea in async_invoke_thread (data=0x0) at threadpool.c:1566
#3  0x00000000005823ab in start_wrapper_internal (data=<value optimized out>) at threads.c:660
#4  start_wrapper (data=<value optimized out>) at threads.c:707
#5  0x0000000000631b16 in inner_start_thread (arg=<value optimized out>) at mono-threads-posix.        c:100
#6  0x00007fba90cfb9d1 in start_thread () from /lib64/libpthread.so.0
#7  0x00007fba90a48b6d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7fba917ab780 (LWP 7098)):
#0  0x00007fba90992cd4 in sigsuspend () from /lib64/libc.so.6
#1  0x00000000005cac54 in suspend_thread (sig=<value optimized out>, siginfo=<value optimized o        ut>, context=0x7fff0cb35880) at sgen-os-posix.c:113
#2  suspend_handler (sig=<value optimized out>, siginfo=<value optimized out>, context=0x7fff0c        b35880) at sgen-os-posix.c:140
#3  <signal handler called>
#4  0x00007fba90cff5ba in pthread_cond_wait <at> <at> GLIBC_2.3.2 () from /lib64/libpthread.so.0
#5  0x000000000060c34c in _wapi_handle_timedwait_signal_handle (handle=0x280a, timeout=0x0, ale        rtable=1, poll=<value optimized out>) at handles.c:1596
#6  0x000000000061e7fb in WaitForSingleObjectEx (handle=0x280a, timeout=4294967295, alertable=1        ) at wait.c:194
#7  0x000000000058122c in ves_icall_System_Threading_Thread_Join_internal (this=0x7fba917102d0,         ms=-1, thread=0x280a) at threads.c:1306
#8  0x0000000041e653f9 in ?? ()
#9  0x0000000000a16d80 in ?? ()
#10 0x00007fff0cb363f0 in ?? ()
#11 0x00007fba8a4514a8 in ?? ()
#12 0x00007fff0cb36190 in ?? ()
#13 0x00007fff0cb35f80 in ?? ()
#14 0x0000000000a23e40 in ?? ()
#15 0x0000000000000000 in ?? ()

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Neale Ferguson | 22 Aug 00:58 2014
Picon
Picon

OracleClient.Oci and GC

I've been looking at OciDefineHandle and the OciDefineByPos call it uses in particular. Currently two of
the parameters passed to this call are short variables. They are passed as "ref" fields as Oracle uses
their address to put size and indicator data once the data is fetched. However, being defined as short
means that they are eligible for being moved during garbage collection. Thus if that field is moved
between the OciDefineByPos call and the fetch of the data then what Oracle is pointing to may no longer be
variable. I'm thinking it may be better to define these fields as IntPtr and allocate them and retrieve
their values via Marshal.ReadInt16. I'm currently testing these changes and so far I'm not getting the
failures I had been encountering. If this is a valid analysis then the OciB
 indxxxx calls will also need attention as it uses a ref indp parameter as well - these appear to be used in
OracleParameter.cs. 

Neale
mono user | 20 Aug 03:05 2014
Picon

PSeq.reduce does not seem to work under Mono

The following tiny bit of F# does not seem to work under Mono 3.6.0. It's fine under .net. PSeq is a thin wrapper implemented using parallel Linq (see the stacktrace). I am afraid I don't know if it's meant to work yet.

let res = Microsoft.FSharp.Collections.PSeq.reduce (+) [0..100]
printf "Result is %d" res

Any suggestions? Many thanks.

mono reduce.exe

Unhandled Exception:
System.ArgumentNullException: Argument cannot be null.
Parameter name: seedFactory
  at System.Linq.ParallelEnumerable.Aggregate[Int32,Int32,Int32] (System.Linq.ParallelQuery`1 source, System.Func`1 seedFactory, System.Func`3 updateAccumulatorFunc, System.Func`3 combineAccumulatorsFunc, System.Func`2 resultSelector) [0x00000] in <filename unknown>:0
  at System.Linq.ParallelEnumerable.Aggregate[Int32] (System.Linq.ParallelQuery`1 source, System.Func`3 func) [0x00000] in <filename unknown>:0
  at Microsoft.FSharp.Collections.PSeqModule.reduce[Int32] (Microsoft.FSharp.Core.FSharpFunc`2 reduction, IEnumerable`1 source) [0x00000] in <filename unknown>:0
  at <StartupCode$reduce>.$Reduce.main <at> () [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.ArgumentNullException: Argument cannot be null.
Parameter name: seedFactory
  at System.Linq.ParallelEnumerable.Aggregate[Int32,Int32,Int32] (System.Linq.ParallelQuery`1 source, System.Func`1 seedFactory, System.Func`3 updateAccumulatorFunc, System.Func`3 combineAccumulatorsFunc, System.Func`2 resultSelector) [0x00000] in <filename unknown>:0
  at System.Linq.ParallelEnumerable.Aggregate[Int32] (System.Linq.ParallelQuery`1 source, System.Func`3 func) [0x00000] in <filename unknown>:0
  at Microsoft.FSharp.Collections.PSeqModule.reduce[Int32] (Microsoft.FSharp.Core.FSharpFunc`2 reduction, IEnumerable`1 source) [0x00000] in <filename unknown>:0
  at <StartupCode$reduce>.$Reduce.main <at> () [0x00000] in <filename unknown>:0

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Keithen | 19 Aug 23:04 2014
Picon

Linux ComImport

Hi,

I'm trying to make a Windows.Net(c#) application run on Linux(Raspbian).
The application is trying to use some COM-stuff, causing the App to crash.
Since I dont need the content of the COM-Object, I wanted to rewrite just
the libraries/parts necessary for not crashing the App.
I have written an ole32.dll exporting CoCreateIntance. So far, my
CoCreateInstance gots callen and receives parameters correctly. But after
CoCreateInstance is called, the application crashes with

Stacktrace:
  at <unknown> <0xffffffff>
  at (wrapper managed-to-native)
object.__icall_wrapper_mono_object_new_specific (intptr) <0xffffffff>
  at linuxcom.linuxcom.Main (string[]) <0x00033>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object
(object,intptr,intptr,intptr) <0xffffffff>
  at <unknown> <0xffffffff>

The c#-code belonging to the application:

Object obj = Activator.CreateInstance(Type.GetTypeFromCLSID(new
Guid("AE1E00AA-3FD5-403C-8A27-2BBDC30CD0E1")));

I attached c++ code belonging to ole32.dll (I haven't written c++ for some
time): 
ole32.c <http://mono.1490590.n4.nabble.com/file/n4663589/ole32.c>  

Is there an easier way to do this?
Why doesn't it work?

Greetings,
Keithen

--
View this message in context: http://mono.1490590.n4.nabble.com/Linux-ComImport-tp4663589.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
Neale Ferguson | 19 Aug 21:47 2014
Picon
Picon

thread6 test

What should the output of thread6 test look like (apart from "caught" instead of "cought")? Here's what I'm
getting at the moment - 

Thread 1 started
Count: 0
cought exception level 3
cought exception level 2 STATETEST
System.Threading.ThreadAbortException: Thread was being aborted
  at Tests.ThreadStart1 () [0x00087] in /home/neale/mono/mono/tests/thread6.cs:51
cought exception level 1
System.Threading.ThreadAbortException: Thread was being aborted
  at Tests.ThreadStart1 () [0x00087] in /home/neale/mono/mono/tests/thread6.cs:51
end

Gmane