Chris' Coding Fun

Ok. I've been trying to tracked down the error's meaning. specifically SIGSEGV code=2. I found it listed in the header file located at    sys/siginfo.h  : * SIGSEGV codes (si_addr == address of faulting memory reference)  */ #define SEGV_MAPERR     1       /* Address not mapped */ #define SEGV_ACCERR     2       /* No permissions */ #define SEGV_STKERR     3       /* ?? Stack exception */ #define SEGV_GPERR      4       /* ?? General protection */ #define SEGV_IRQERR     5       /* ?? Interrupt handler fault */ #if defined(__EXT_QNX) #define NSIGSEGV        5 #endif It seems to be SEGV_ACCERR. No permissions. Very interesting. I am not sure what it is trying to access, or why i dont have permissions as a developer. Hmmm... Update:  Found addr2line. seems like there are some errors in aot-compiler.c,...

I was able to use blackberry-connect to open up ssh access on my playbook. SCP'ed my mono install and received this error message: Process 10866804 (mono) terminated SIGSEGV code=2 fltno=11 ip=000bfde0 Memory fault (core dumped) Not sure what it means. I did some strange sig hacks, so I may start there. I wonder if i could use gdb to check out the core dump. When i run Mono -V i get: $ ./mono -V       Mono JIT compiler version 2.10.9 (mono-2-10-9/256094a Mon May 28 09:15:52 EDT 2012) Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com TLS:           normal SIGSEGV:       normal Notification:  Thread + polling Architecture:  armel,vfp Disabled:      none Misc:          softdebug LLVM:          supported, not enabled. GC:            none I wonder if SIGSEGV has a...

I have went through quite a few linux distros in my time, from Red Hat to Slackware,  knoppix, to Mandrake, Caldera, Debian, Gentoo (one of my favorite) to recently Ubuntu (I am also an AfterStep fan..lol). I chose Ubuntu as my main development platform of choice a few years ago because of its debian connections, the apt-get repository system is well supported, and third party repositories are easily found. (I found, while i loved Gentoo, and portage was amazing....it was slow on getting a system up and running). For the past few months I have been trying out Linux Mint (specifically 12, though now 13 is out). I have to say I am really impressed at how clean the interface is. After Ubuntu jumped the shark with their plasma interface I was longing for a simple gnome based (though i'd even go for kde) interface. I just want to jump in, install any supporting software, hack, tinker, coded, build, commit and jump out.   Just some background, A few years ago I decided...

I spent part of the weekend cross compiling Mono on RIM's playbook/QNX platform. I will be uploading the code to github (or bitbucket) and creating a patch. I purposely used the mono-2-10.8 branch, so there would be no need for messing around with changesets. doing a "git checkout mono-2-10-8" and then applying my patch will work. There are some limitations, such as no sgen. Also i commented out a timezone function. I'll post a full list once i actually upload the code. I am actually attempting to run the new mono build on the playbook, but I am having trouble. When i did this with WebOS, it was much easier. I just SCP'ed the build to my WebOS device, and ran some C#. I am unsure how to best go about this on the playbook. Time for some more tinkering.

Free eBooks from Microsoft. I grabbed all of them, but I am most interested in the Windows Phone 7 and SQL Server 2012 books. Free ebooks: Great content from Microsoft Press that won’t cost you a penny - Microsoft Press - Site Home - MSDN Blogs :

After trying to compile and install mono 2.10.8 on the latest builds of Haiku, its apparent that Haiku is now getting some Mono love. Its not 100% complete, but while spelunking through source I saw specific __HAIKU__ #ifdef tags, which didnt exist when i first started looking into getting mono working. It looks like by the next alpha or release candidate mono will be up and running. Its doubtful my endeavors really helped. Though going forward I will be,  at the very least, publishing the majority of hacks so they may be used as information for patches going forward. I will also attempt (where i see the need) to get patches committed into Mono (and any other projects/tech that I hack regularly). I think the knowledge gained from hacking Mono/WebOS, Mono/Haiku and ZFS/Snappy (among others) will allow me to start creating useful patches. I've learned a lot about autoconf, automake, et al.

One of my many side tinkerings has been porting Mono to different platforms. I've ported Mono successfully to WebOS 2.0 (which was instantly broke when 3.0 came out, and I have not looked into it further). I've also been looking at porting it to the Playbook OS. One of the platforms that I attempted and failed was Haiku. The failure was a combination of things. It was about 2-3 years ago, and Mono had some glib dependencies that were an issue, as well as libgdiplus. And then on the haiku side, libiconv, pthreads and POSIX signal.h wasnt available. I used this wiki entry to help guide me. I actually successfully compiled mono on haiku 2 years ago, after some header file hacks, some edits on the mono side, etc. I deemed it way way too neutered to do move forward, and dropped the project. Back around July 2011 alpha 3 was released (i was doing my initial stuff on alpha 2), and after checking the Haiku Porting guide I figured, "why not try?", so I spun up a Haiku...

Alright. I've finally got around to doing some Snappy testing. I've gotten some amazing results, but also noticed a bug. My current code seems to hang after a large amount of compression. It specifically hangs when i am doing an iozone benchmark. The 500MB pass (I set it to 4GB). But before I ran iozone, i did some paliminary testing vs lzjb, and I have to say, the compression performance is higher with Snappy. I was able to get a 23.14  compression ration instead of the 15.22 ratio from lzjb, with similar cpu usage. I suspect this has to do with the snappy_env_init method in the snappy-c library i found. It seems fishy having to initializing the environment for every compression event. I may look into it further but it does not seem very scaleable. and given that ZFS compression works at the block level, and not the file level, there are a lot of compression events happening for a single file (instead of one event, compressing a 400MB file...it would be 400 events with...

Found an interesting project called vertx. x I might end up trying to port it to the CLR using the technology that the folks over at the mono-project used for porting android's java layer to C#

I've completed my first zfs + snappy build. Its up on github at  https://github.com/techsaint/zfs-snappy . I tried to test it on my Virtualbox instance, but it doesn't look like there is very good VDI support for zfs. It seems to freeze when i try to write to a file system. I tried with the non snappy version too, just in case I mucked up something, but the vanilla version also froze. Now that I have a compatible version, I will test it on actual hardware, instead of in a VM. This build actually has snappy baked into zfsonlinux using the snappy-c library I found. If this route works, I will look at using the snappy-c port in an illumos build. I have all the changes out on bitbucket, and I did spend a few months learning the opensolaris/illumos build files....

Just wanted to make a statement that the CLI tooling for building software in linux (and really any *nix) has changed dramatically. In my mind, configure and make were all black boxes and it was very very hard to actually effect them as an independent developer once they were baked. This is not the case anymore. I was able, with autoconf, automake, and m4 templates (and of course some C++ glue) to actually integrate two libraries (zfs and snappy-c) that know nothing about each other. This is a testament not just to the auto tooling, but the level of maturity of a lot of open source software out there. While make is still technically a black box (yes, make scripts are simple in concept, fine...but go look at Illumos makefiles and we'll talk...), it may be ok for make to stay in the shadows...like some x86 assembly that gets generated on the fly... I just might, after this zfsonlinux + snappy release, revisit illumos. But from what I recall of the original opensolaris d...

Just wanted to give a quick update. On the ZFS front i have really made inroads. I now have to decide whether to create a stand alone snappy kernel module (which could assist folks outside of my little tinkerings) or roll snappy into zfsonlinux, so i can do some benches, and see if its a viable alternative to the compression included in zfs. I am leaning toward kernel module, but I've found a project called snappy-c that is a completely C port of snappy. This will make option #1 super easy. On the tinkering front, Xamarin has ported the java layer of android to C# . I have already gotten my hands on the source. Planning to put it on a phone or tablet soon.

I didnt expect to have the time, but I really became interested in answering the question of how easy working with the linux port of ZFS would be. I am here to say that I got everything compiled and installed last night. I am now trying to track down an shared library file that doesnt seem to be found. It exists, but my guess would be that the zfs tool is looking for it in /usr/lib instead of /usr/local/lib. The specific error is: /home/techsaint/files/zfs-project$ zpool zpool: error while loading shared libraries: libnvpair.so.1: cannot open shared object file: No such file or directory

My ZFS/Snappy project was put on hold, because of technical issues and lack of understanding (and documentation) of how to integrate a library into an Illumos build. I may have found a compromise. The zfs on linux project has become a bit more mature. I may switch up and use linux to create a snappy proof of concept.   I understand linux build structure much more than open solaris build structure, and the things i dont understand are fairly well documented. Because zfsonlinux is on github , I'll most likely be using Github and forking the project.