CRiSP Weblog

The wifi works - in fact the indicator on the menu bar is full strength. I have never seen that before!

As soon as I stress the cpu, it decreases to about 50%.

How interesting, bizarre, distressing that the strength of the wifi is proportional to the amount of cpu power!

Previously reported issues with the macmini - wifi not working. After trying numerous things and googling, finally found it.

HEAT !

Yes. heat. I had moved the mac an inch or so - it sits on a DVD recorder/player which is pretty warm. So I moved it off the DVD recorder - its sitting on a glass shelf, and within a few seconds, the wifi was back - I had spent the last few hours resetting, reconfigurating, rebooting, all to no avail.

But repositioning helped.

I suspect in attaching the external hard drive, the small movement hadnt really helped the dodgy wifi.

At least now I know. I need to be careful when doing things like encoding movies for the ipod will send the cpu into overdrive and cause more heat.

I blog this here in case it helps other people.

(This is a dual core 2GHz Intel mac mini).

Just fixed an interesting bug in CRiSP which someone reported. If you have a file, say 1GB in size, and no line endings, CRiSP would try very hard to read the file and keep doubling memory. I stopped it before it crashed my system or ran out of swap space, but it was interesting how large it was growing. A sillyism meant that it wasnt honoring the max line length attribute (was 1MB, now defaults to 256K). I need to figure out why even for a 1GB line, it didnt just try and allocate a 1GB buffer.

I gave up on my wifi and homeplug network on my mac mini - the one I use for audio/video/ipod - it keeps dropping out. I dont understand why - it has always been flaky, and numerous reports on the internet show others having the same issue - just randomly loses the connection (both wired and wifi) which is a nuisance. I thought I had cured it by deleting a file in /Library/Preferences, but it persists.

I need the wifi because the mac has such a small hard drive (I could upgrade it, but 1TB drives are expensive, and 500GB is too small). I dont want another power supply next to the computer for an external HD, so I thought I would grab a 500GB Freecom drive (2.5", bus powered) and it works brilliantly. I left it in FAT32 mode - copied the files from the Linux master and Apple can read it fine.

What I find incredibly infuriating with Apple is how amatuerish they can be. If you export the drive over NFS, it wont work. Apple doesnt support NFS over a FAT32 filesystem. I dont understand why this should matter - it absolutely should not, not in the 21st century. Back in 1980, I could understand it.

Which lead me to "unfsd" (see sourceforge.net). This was written back in the 1980s when NFS first surfaced, as a user space NFS daemon for those systems which hadnt adopted this "new" technology. It was useful back in the days when a 386 with 4MB of RAM was the latest tech to have. Now, it resurfaces as a perfect solution on a deformed Apple OS where they havent bothered "to do the right thing" in the kernel. Shame on them.

Shame on them for having such a bad wifi implementation. Shame on them for my ipod touch totally losing its ability to rotate the screen.

Next step will be to replace the mac with a nettop, as its just too painful trying to keep this running.

Am impressed with Microsoft. Never thought I would say that, but I will. The Win64 API is a doddle to port to from Win32. There are only a few gotchas - far, far fewer than the Win16 to Win32 transition.

Issues like SetWindowLong(GWL_WNDPROC) is now SetWindowLongPtr(GWLP_WNDPROC) since the wndproc is a pointer type.

There are some other minor issues, but two things caught my eye. First was that you do need to be more careful with portability issues. Much of my code had UINT/LONG function parameter types where WPARAM/LPARAM should be used. I got away with it in Win32 but not in Win64; that accounted for most of my porting issues.

Another issue thrown up by the CL.EXE compiler was a construct like this:

int len = strlen(str);

The return type of strlen() is "size_t", which on the common IL32P64 platforms is a 64-bit value - a string can be more than 4GB in size, so if we assign to an int or unsigned, then we can have problems coping with strings longer than 4GB. This is true on Linux as it is on Windows, but GCC never highlighted that warning to me. Now I know.

Similarly

char *p1;
char *p2;

int n = p2 - p1;

suffers the same issue.

CRiSP is running now but have a few more bugs/porting issues to fix.

Finally got the new laptop (8GB RAM!) Its nice - except that RAM suspend doesnt work, so it means a full reboot when I finish for the day. Strangely my Zyxel powerline network stopped working around the same time - probably unrelated (the powerline connects the mac-mini to the master machine - not the laptop).

So I installed Ubuntu 9.10, then VirtualBox, and then Windows 7, and CR.EXE (win64) now runs fine and am just debugging the CRISP.EXE win64 binary.

I will make available the win32 and win64 release when I am finished. (The bin.w32 directory will be renamed to bin.win32, with a corresponding bin.win64 directory).

The reason the bin.w32 directory is called that was to be MSDOS 8.3 friendly. In 2010, I think I can stop worrying about floppy disks and MSDOS FAT filesystems :-)

I updated fcterm to support the 256 color palette extensions available in other terminal emulators. I hadnt realised I was missing that.

And somebody gave me a small fix for bad code in Dtrace (I must resume my playing with dtrace, as I feel a fraud for having left it sit alone for so long!). At least it compiles on my Ubuntu 9.10 without any issues.