Re: [Libbt-devel] Intro and... suggestions

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

Op donderdag 21 april 2005 02:48, schreef Dakidd:
> >Hi,
> >
> >I'm the only one active at this time, and I'm already doing what you
> >describe,
> >except i didn't commit yet, because it'll break CVS HEAD.
>
> Hi yerself! :)
>
> No, Alien, you're not the "only one active"...=20

sorry, but I haven't heard much from you... and I am the only one active at=
=20
CVS, no offense.

> I've just been effectively=20
> silent, quietly banging away at adding stuff to make the thing truly
> cross-platform. As it stands now, it's Windows/*nix freindly (at least for
> the most part) but actively hostile to those of us still stuck by
> circumstances working on Macs that run an OS version below MacOS X (MacOS=
 X
> folks can use it *ALMOST* "as-is" due the the unix-like underpinnings of
> the OS). I'm hacking away, slowly but steadily, at changing that with a
> massive introduction of
> #if TARGET_MACOS
> ...
> #else
> ...
> #endif
> conditionals. At this point, I've done SOMETHING that has broken most of
> the library in a massive way, and am working on figuring out what it was
> that turned out to be "poison", but prior to the change that did it,
> btcheck, and "ctx_loadfile", which was basically all it called directly,
> was working 100% for me. I'll try to keep the list posted as I make
> progress back to functionality.

portability is good, i guess...

> FWIW:
> I started my "battle" on version 0.3, and that's where I'm sticking at
> least until I get things back to functional. It appears as though 1.3 is
> *MOSTLY* very similar, at least in the "core" btxxxxx code but I haven't
> wrapped my head around the various changes that come with the most recent
> versions, so I'm a lot more comfortable dealing with "the old one" until I
> get it functional again.
>
> If you'd like to see my changes so far, I'm willing to crate up SOME
> sections and pass them along to anyone interested, but outside of the
> "core" code listed, it's pretty much a minefield, since I've had to hack
> out huge swathes of utterly incompatible networking code to get a compile
> at all - peer.c being particularly obnoxious for me at this point - I'd
> estimate I've got more than 75% of it commented or conditionalized onto t=
he
> scrapheap - It's THAT hostile to Mac-style networking.

just a note, on CVS HEAD: peer.c is being completely rewritten. I do howeve=
r=20
not check anything little or big endian. which is not portable for some=20
*nixes including mac. but I must admit that there isn't much htonl stuff=20
anymore.

> Such a "crate up and send" will, by neccessity, have to be done "outside
> the channel" of CVS, since, quite bluntly, I'm *NOT* going to take the ti=
me
> needed to re-acquire the programs and skills needed to work with CVS away
> from banging on the code - never mind that committing anything in the sha=
pe
> it's currently in on my machine would be something close to a terrorist
> attack in terms of likely "damage" to the current codebase.

since I'm getting like "back to basics", for efficiency and maybe a little=
=20
portability reasons, you might be interested to check out how CVS HEAD work=
s=20
and extract it in a second codebase.

> >but because you seem interested, i'll commit everything now anyway, the
> >minute
> >i get my own version working a little again.
> >
> >I can tell you that i have gotten far and I restructured everything into=
 a
> >functional system, more or less...
> >
> >this "library" wasn't really a library when I started, they have 3 tools
> > (as the release from the 1.03 branch shows) btcheck, btlist & btget...
> >
> >the first 2 work more or less, the third is still not operational, becau=
se
> >i'm
> >working on the peer protocols now.
> >
> >
> >
> >The things i keep in mind:
> > - get rid of libevent
>
> Doesn't exist in MY copy of the source, but then, as mentioned, I'm worki=
ng
> from an old (v0.3) sourcebase.

thank god

> > - think of generalisation: 64bit, IPv6, torrent protocol deviations
>
> Something that should be "back burner" at least until basic IPv4/32 bit
> functionality is achieved - IMO...

well, I'm on a 64bit CPU and OS, so, it's big for me, i've never had it=20
working...

!plus! I am programming protocol independant, this reduces alot of htonl ca=
lls=20
and is much more simpler.

> > - make headers structured and make internal dependencies
> >
> >
> >
> >
> > - see libbt/include/bt/bt.h (it holds a header file that is supposed to
> > have all functions).
>
> This item is a *HUGE* one in my book, and in my opinion, needs to be at t=
he
> top of the priority list.

most of this is done.

> > - clean up the code
>
> Not far behind creation of a useful bt.h file in priority. Again, my
> opinion...

I must tell you that all of these above are only my big priorities...

good luck, and maybe you should check out CVS, or check the very near new=20
release for mac compatibility.