libbt-devel

[Libbt-devel] Re: Need some "other than Mac" checking done

[Alien <ali...@us...>]

hey,

good job, except that i don't work the with 1.03 codebase, you'll have to g=
et=20
this to Kevin, I don't use the 1.03 codebase in CVS HEAD, and frankly, the=
=20
util.c and util.h isn't really used much anymore, I do intend to keep most=
=20
stuff independant of platform...

I'm almost done reworking the CVS HEAD, until it is a little functional, no=
t=20
optimized in the least...

when it's more or less working, i'll send you a mail asking you to compile =
it=20
on mac...

about your patch:

well, I cannot compile it, for the simple reason that I only have linux, an=
d i=20
only have 64bit system, branch 1.03 has never worked for me before...

so, i could not even test your files if i wanted to...

i'll forward this mail to the mailing list, and we'll see if anything=20
happens...

good job, though...

AL13N

Op donderdag 5 mei 2005 23:38, schreef Dakidd:
> Hey guy...
> I think I've managed to knock the kinks out of util.c/util.h for use on
> Macs. I need somebody who can compile for Windows/Unix to check it out and
> see if I screwed up and trashed things for those platforms, or if my
> surgery managed to fix the Mac troubles, yet still leave the "other
> platforms" functional.
>
> The most obvious change (aside from "prettifying" the code - No offense
> intended against Kevin, but he writes code that, in my opinion, is all but
> completely unreadable) is that cacheopen() now takes a void * rather than=
 a
> char * as its first parameter - I *THINK* I've included the right "magic"
> to make this transparent, but I haven't got a way to test that theory. If
> you're wondering about the reason for this, it's kinda in-depth and a pain
> to explain, but I can give you the 411 if you really think it's needed. T=
he
> short version: Macs are *MUCH* happier dealing with files when they're
> passed around as an FSSpec rather than pathnames. There's a lot of voodoo
> involved, but it boils down to "if you want it to work properly in all
> situations on a Mac, do it with FSSPec structs instead of pathnames,
> otherwise, expect to hear your users screaming at you about meltdowns that
> happen for no apparent reason."
>
> I've done my best to conditionalize my changes (on the "TARGET_MACOS"
> value, set up in config.h) so that Unix/Windows can continue passing in a
> char * with a fully-qualified pathname and never notice a difference, whi=
le
> Macs will pass in an FSSpec, but have no way to test the Unix/Windows
> functionality.
>
> I've also done some cleanup and rewiring in the cacheopen() routine -
> You'll notice that the "mode" and "options" parameters have been renamed -
> Those two drove me absolutely *NUTS* until I finally broke down and
> "hand-executed" the code. The names were hideously confusing, and once I
> got through things, it became clear that Kevin had screwed the pooch
> bigtime - "options" gets passed in only when setting up a "writeable" fil=
e,
> and is the Unix file-access permission setting that should be used when t=
he
> file is created. As it was coded, it was being stored as one of the things
> to look at for deciding whether the file was open and cached or not. *BIG*
> screwup! It's obvious (now that I've "hand-executed" it) from looking at
> the rest of the routine that the intention was to open/cache a file based
> on its name and whether it was opened for read or write mode. Checking
> against the file permissions is pointless, and was the source of some maj=
or
> hair-pulling as I tried to figure out why nothing I did would make the
> routine work as expected on a Mac. This forced changes to the cache
> struct/array (c_fileset), and some rewriting of the code that worked with
> it.
>
> openPath() has also been reworked, again mainly to deal with the "Macs li=
ke
> FSSpecs better than pathnames" concept, and again, I believe I've managed
> to make the alterations transparent to Unix/Windows systems through
> conditionals.
>
> If you look through util.c, you'll also notice some "brain surgery" on the
> btAlloc/btMalloc/etc routines - This was done in the interest of
> speed/efficiency - I have yet to meet a library on the Mac that doesn't e=
nd
> up calling directly into the OS for malloc/calloc/realloc/etc calls exact=
ly
> as I do in the revised routines, but with idiotic amounts of useless
> overhead before doing so. So I've basically "chopped out the middleman" a=
nd
> gone straight to the MacOS toolbox routines - which are as old as the Mac
> itself, stable as a rock, and quite well documented - where the
> Windows/Unix versions got things done by way of the standard library
> routines. Operation for them shouldn't be affected, due to conditional
> compilation on the "TARGET_MACOS" value, but on the Mac, it's a good bit
> quicker.
>
> Overall, I've done some pretty major surgery throughout util.c, but I'm
> pretty sure that I've either made the needed changes compatible with, or
> transparent to, Unix and Windows systems by use of conditional compilation
> keyed on the "TARGET_MACOS" value.
>
> Now I need you (or someone else capable of compiling on Windows and/or
> Unix) to check and see if my changes are as compatible/transparent as I
> hope they are...
>
> Basically, "They work on my Mac. Do they still work on other platforms?"
>
> My altered versions (starting from the 1.03 version of the codebase) are
> attached. They might need line-end tweaking to be readable (Macs use '\r',
> windows '\n\r', and unix '\n') Let me know what you come up with, eh?
>
> (Oh - If you reply from somewhere other than your sourceforge.net address,
> make sure to put the string "PopperAndShadow" somewhere in the subject li=
ne
> - I've had to go to full-out email lockdown due to getting hit with more
> than 150 spams a day. I've got your sourceforge address whitelisted, but =
if
> you reply from somewhere else, I've got my procmailrc file set up to send
> *EVERYTHING* that isn't whitelisted straight to dev/null unless the subje=
ct
> line has the "PopperAndShadow" password in it somewhere - I might find out
> (far too late for it to make a difference) that you sent something if I
> notice in my procmail log, but otherwise, I'll never even know it existed)

Re: [94] [Libbt-devel] Re: Need some "other than Mac" checking done "PopperAndShadow"

[<ke...@an...>]

Hi Dakidd,

> Op donderdag 5 mei 2005 23:38, schreef Dakidd:
> > Hey guy...
> > I think I've managed to knock the kinks out of util.c/util.h for use on
> > Macs. I need somebody who can compile for Windows/Unix to check it out and
> > see if I screwed up and trashed things for those platforms, or if my
> > surgery managed to fix the Mac troubles, yet still leave the "other
> > platforms" functional.
> >
> > The most obvious change (aside from "prettifying" the code - No offense
> > intended against Kevin, but he writes code that, in my opinion, is all but
> > completely unreadable) is that cacheopen() now takes a void * rather than a
> > char * as its first parameter - I *THINK* I've included the right "magic"
> > to make this transparent, but I haven't got a way to test that theory. If
> > you're wondering about the reason for this, it's kinda in-depth and a pain
> > to explain, but I can give you the 411 if you really think it's needed. The
> > short version: Macs are *MUCH* happier dealing with files when they're
> > passed around as an FSSpec rather than pathnames. There's a lot of voodoo
> > involved, but it boils down to "if you want it to work properly in all
> > situations on a Mac, do it with FSSPec structs instead of pathnames,
> > otherwise, expect to hear your users screaming at you about meltdowns that
> > happen for no apparent reason."

If you are having trouble with code formatting then you probably need to set 
physical tabs to 8 columns in your editor.  

> >
> > I've done my best to conditionalize my changes (on the "TARGET_MACOS"
> > value, set up in config.h) so that Unix/Windows can continue passing in a
> > char * with a fully-qualified pathname and never notice a difference, while
> > Macs will pass in an FSSpec, but have no way to test the Unix/Windows
> > functionality.
> >

Send me your patches and I'll take a look.

-- 
Look ma, no threads[1]. 
[1] BitTorrent in C is http://www.sf.net/projects/libbt
	  
          //                               .--=,
 .....::://::::::::::::::::::::::::::::.. (o O &           ke...@an...
:::::::://:::://://://:/:://::||_//       / V  K   
 :::::://:::://:/:|//'/' // _,|'         r ,  'qk   
  :'''/____ // /  //  |_// // ||        .'~.  .~`, 
                                   kls   \_/-=\_/

Re: [94] [Libbt-devel] Re: Need some "other than Mac" checking done

[<ke...@an...>]

> Op donderdag 5 mei 2005 23:38, schreef Dakidd:
> > I've also done some cleanup and rewiring in the cacheopen() routine -
> > You'll notice that the "mode" and "options" parameters have been renamed -
> > Those two drove me absolutely *NUTS* until I finally broke down and
> > "hand-executed" the code. The names were hideously confusing, and once I
> > got through things, it became clear that Kevin had screwed the pooch
> > bigtime - "options" gets passed in only when setting up a "writeable" file,
> > and is the Unix file-access permission setting that should be used when the
> > file is created. As it was coded, it was being stored as one of the things
> > to look at for deciding whether the file was open and cached or not. *BIG*
> > screwup! It's obvious (now that I've "hand-executed" it) from looking at
> > the rest of the routine that the intention was to open/cache a file based
> > on its name and whether it was opened for read or write mode. Checking
> > against the file permissions is pointless, and was the source of some major
> > hair-pulling as I tried to figure out why nothing I did would make the
> > routine work as expected on a Mac. This forced changes to the cache
> > struct/array (c_fileset), and some rewriting of the code that worked with
> > it.

cacheopen() follows the signature of open(), see 'util.h'.  You have the 
meanings of options and mode reversed.  Mode is for unix permissions (cf
open), and options is the local variable name in cacheopen() for what is 
called 'flags' as a parameter to open (O_WRONLY, O_RDONLY, O_CREAT, etc.)
I should make it consistent with open and use 'flags' here, but there is
history to the variable 'options' and it would take a while to untangle 
it.

Cacheopen() is just a front-end to open that keeps the number of open file
descriptors to within some reasonable limit.  Originally I used to keep 
all of the files open simultaneously, but that could quickly overwhelm 
the limits in ulimit.h for a torrent with thousands of files embedded.

I've double checked the parameter order, and the mode and flags parameters
are in the correct order in each call, so I don't see how you could have 
gotten the mode parameter into the options parameter (or vice versa.)  It
certainly doesn't do that in my code.

-- 
Look ma, no threads[1]. 
[1] BitTorrent in C is http://www.sf.net/projects/libbt
	  
          //                               .--=,
 .....::://::::::::::::::::::::::::::::.. (o O &           ke...@an...
:::::::://:::://://://:/:://::||_//       / V  K   
 :::::://:::://:/:|//'/' // _,|'         r ,  'qk   
  :'''/____ // /  //  |_// // ||        .'~.  .~`, 
                                   kls   \_/-=\_/