connecting from mac to pc

so you can’t see the pc in your normal finder, to share docs with it?  Easy (from http://lifehacker.com/software/mac-os-x/how-to-mount-a-windows-shared-folder-on-your-mac-247148.php) just go to finger->go->connect to server-> type in ‘smb://ip_addy_of_pc’ (or smb://name_of_pc)

select limitations on windows, linux

These are my observations on select on mingw+ruby+eventmachine.

Overall, it seems on linux you can't pass a descriptor (number itself) > FD_SETSIZE - (1 or 2) to select, and on windows I can't seem to get it to work with anything > 64, despite all #define's I do (there may be a future fix for this, though).GL. 

// note that windows sometimes, for some reason if you have open sockets, then you do File.open (?) then one of your open sockets no longer responds to select.  Maybe File.open 's file descriptor is ploughing a socket descriptor?
// note also that on windows, server editions you can have more than 256 (msvcrt.dll) or 2048 (msvcrtXX.dll) file descriptors total, per process, so our setting FD_SETSIZE to 2048 might could use to be raised in those cases.  But I'd say leaving it at 2048 is good till it becomes a problem for someone.
// update--appears that it doesn't matter what you set FD_SETSIZE to be, it only 'works' up to 64, for some reason.  Maybe ruby itself 'redefines' FD_SETSIZE to be low? So we need to set it? todo (there's a test that tests this, you can set FD_SETSIZE to whatever, run the test--it errs if you set it above 64!
// it appears that even having this loop doesn't solve all the problems, as select sometimes returns '3' even when none of them even requested to read or write--probably corruption

       /* if we're on linux, and using select, and sd >= FD_SETSIZE then reject it-- we can't fit it into a select!  The problem being that with linux, the first parameter to select must be < FD_SETSIZE (it checks up to that many file descriptors).
        i.e., if you get a file descriptor with a value as high as FD_SETSIZE, you cannot put that descriptor into an fd_set. (from http://www.delorie.com/gnu/docs/glibc/libc_248.html)
        With windows, it appears that the total number of sockets it will cram into an fd_set is FD_SETSIZE, so...it basically ignores the call to FD_SET if the fd_set is already too populated, resulting in  us losing a lot of data.  So it's the same logic check, but it errs in different parameters.
        http://doc.ddart.net/msdn/header/include/winsock.h.html -- we use winsock.h, not winsock2.h

        todo add this to udp, well just about everything (?) Note that it's dangerous to 'close' it since it still will make it to select

        So note that on linux descriptor numbers must be less than FD_SETSIZE, and on windows, the sum of descriptor counts must be < FD_SETSIZE.

dns woes

 

 

      Yeah it appears that if you have flaky internet, leopard will cache your ‘failed’ dns entries, which means that unless you are constantly flushing your dns, your internet will be only half functional. Switching to opendns seems to help.

 

ruby bug

./lib/logger.rb:83:in `write’: Invalid argument – ../logs/192.168.2.202/buggy_50751386_dClient1_dTotal50_dw2.0_blockSize100000_linger20_dr125000_dt1.0_serverBpS1000000000.0/peer_number_26_start_27.75.log.txt (Errno::EINVAL) What this really means is ‘the system is out of file descriptors’ or something like that.  It happens under high load.  

valgrind on mac os x

appears that it doesn’t work yet. closest is’man malloc’, or

export MallocGuardEdges=true
export MallocPreScribble=true
export MallocScribble=true
export MallocCheckHeapStart=200 

Then run your prog again

Roger's meanderings, notes to himself, bug reports, and other things