Nixers project: Bittorrent library - Community & Forums Related Discussions
z3bra
No I didn't think about it. I want to avoid external dependencies as much as possible, and for things I cannot handle myself (HTTP protocol, crypot, ...).

Freeing memory is some basic concept, so I don't feel like having an external library for the sake of being lazy :)
jkl
Usually, your compiler's static analyzer (you do use a decent compiler, don't you?) should find forgotten mallocs for you and annoy you to fix them. Having a library to do that is only one step behind just using Java or something. /s
z3bra
(31-07-2017, 04:13 AM)jkl Wrote: Usually, your compiler's static analyzer (you do use a decent compiler, don't you?) should find forgotten mallocs for you and annoy you to fix them. Having a library to do that is only one step behind just using Java or something. /s

I use valgrind to hunt forgotten mallocs. It works well enough for my needs. You're right about the lib, and I don't see the point of using a library to do garbage collection when some languages offer it natively.
sff
What a cool looking project! As someone who knows a little C (I was taught C++ at uni last year), is there something I can do to contribute? Or should I try to get more accustomed to C before trying to help? I'm looking forward to see the evolution of this project.
z3bra
No need to get a a pro in C, start reading what is already there, and ask questions about things you don't understand, it will help others. Then fire up your editor, and start coding!
r4ndom
Isn't the dictionary missing in your implementation?

And do we create branches or are we working on master?
z3bra
(01-08-2017, 05:31 PM)r4ndom Wrote: Isn't the dictionary missing in your implementation?

And do we create branches or are we working on master?

A lot of things are missing! Dictionnaries are next on my list. Actually, they're the same thing as lists, except that there is a relation between each pair of member. So the difference really stands in the usage you made of them, rather than how you store them. For reference, this commit adds the dictionnary parsing functionality :)

What needs to be implemented now is skimming through dictionnaries to find a specify key.

As you can see, I'm working directly on master. I prefer linear histories and rebasing commits upon merging is always a pain (also, stagit won't show the branch history, but that's another story). I'd advise you to work on master, unless you want to try a new feature that might not emd up on master (eg. it will be painful to rollback) or if you want to work separately for a later review (might be great if you're not confident enough in your code).

The end goal is to keep the master easy to browse, so people joining can easily replay the project history with "git log".
z3bra
I finaly implemented key search in dictionaries. That was way easier than expected ^^

I also wrote a TODO file! with a summary of what (i think) should be done. You can pick a task from here and start working if you want.

I guess we can use this thread to discuss who's doing what for now?
For anyone that's new to C, I'd suggest doing the "bencode" function :) It's already written in the test case, but in a quick and dirty way. The goal is to implement it in the library directly, and expose it through the API.
Who feels up for it? (I can help if needed, no worries)
r4ndom
(02-08-2017, 03:53 AM)z3bra Wrote: I finaly implemented key search in dictionaries. That was way easier than expected ^^
Nice. But what I do not get: There is a `parseint`, `parsestr`, and `parselist` function, but why no `parsedict`. I know parselist and parsedict are somewhat the same, but isn't it counterintuitive to just have a parselist and no parsedict.
Or is this irrelevant, since what is currently writte is just the logic within the library and the API is the point where verbosity matters?

(02-08-2017, 03:53 AM)z3bra Wrote: Who feels up for it? (I can help if needed, no worries)
Sure, I can do it. But beforehand I have some questions:
  • Is there any short explanation/tutorial for a TAILQ (besides the manual), because some things aren't clear for me (like when I init a TAILQ, where is it stored?). If I'm home I can skim through my C book to find something, but maybe there isn't something about it (its "learn c the hard way").
  • How do I implement an API? What are the important parts about it? I'll propably going to take a look at the wmlib, which probably have one. But a short explanation is always appreciated :)


_____
Thanks for fixing the dictionary typo :P
z3bra
You could always create something like this:
Code:
struct blist *
parsedict(FILE *stream)
{
    return parsrlist(stream);
}

But IMO it clutters the code, and anyway "bparselist" is not a good name for exposing it. I was considering a more general name, ala "bdecode()" (either renaming bparselist(), or making it a wrapper).

For TAILQ, the man page is good enough IMO, but you need to understand the concept of linked-lists before.
We can discuss it on IRC if ypu want.
For the API, it's just about finding good names for functions and how to use it (its more a discussion than actual code though).




Members  |  Stats  |  Night Mode  |  Help