Anime and Manga management

I'm searching for an easy way to organize your Anime and Manga collection. Something like this

./anime "The Melanch*" +
The Melancholy of Suzumiya Haruhi Episode 110 -> Episode 111

If it doesn't exist yet, code it for me, you are prog after all.

put your anime in hierarchy of folders.
something like this:

anime->
comedy
romance
porn->
tentacle_rape
etc.
it's not fucking hard

Lol, didn't we have a thread like this about 2 weeks ago

>>1
At one point I coded a whole site for this, with multi user system and everything, but maintaining it was a pain so i just keep a text file now.
It looks something like this:

Kanamemo　8/11
Spice And Wolf II 6/12

and whevever I watch something I just edit the text file.

>>4

i lold

I just keep mine in my mind, I don't have such a short memory about which episode I watched last, and I usually follow a few dozen series at the same time.
If you want truly ENTERPRISE anime list management, you should check out anidb.

>>6

do you keep anime figures on your shelf?

I'm considering starting a project like this, but only because I want to write a program with a lot of different daemons communicating.  I haven't started yet because I don't really know how to tell if all the daemons are running, and how to communicate without ever losing any data (or detecting if it is lost and resending it later).

>>7
No, despite me consuming a lot of Japanese media(anime,manga,VNs and eroge), I don't actually own merchandise or have much stuff in my house that would make me look weeaboo.

>>9
whats a vn

>>10
Visual novel, the kind people in /jp/ read.

What I want to know is, where did this guy get 111 episodes of Haruhi from?

>>12
It was probably a joke, Endless 8 and all that.

>>1
If it doesn't exist yet, code it for me, you are prog after all.
I vomited a huge bit in my mouth.
Please do not make shit threads.

>>12
He just did a s/Bleach/The Melancholy of Suzumiya Haruhi/g.

>>10
vietnam.

>>10
porn for lonely weeaboos

>>13
the haruhi writers must have felt like trolling their audience when they wrote the endless 8. it was horible

>>18
Art is wasted on the ignorant.

>>19
You're slightly above-average moe harem japanese cartoon is not art

>>20
"DICKS" is not a valid TCP header.


(defun keep-anime (anime &key (episode 1) (format "avi") (print-func nil))
  (lambda ()
    (if print-func
      (funcall print-func anime episode format)
      (format nil "~A-~D.~A" anime episode format))))

>>19
no.
episodes 3,4,5,6,& 7 were just laziness on the part of the writers.
they could have easily shortened it to 3 episodes long and spent the remaining 5 episodes on original content.

>>22 here
If you tell me what kind of features you'd like for your 'anime management' I might be able to write this in lisp.

>>23
Actually they could have shortened it to zero episode in total. There's a reason they didn't choose this particular story in the original tv run.

>>24
inotify.

>>26
inotify what? I could write you a simple user interface to the inotify system calls, but that'd be in C; I could use CFFI to do it in common lisp. I think I'm going to do the latter, after I experiment some in C.

>>27
What's the matter?  Can't use system calls without some EFF EFF AYEEEEEEEE?

>>28
On a LISP Machine you could.

>>28
What is an FFI after all? Just a way to call external native code. If the language and interface in which the system calls were written matches your current one, then you don't need an FFI. If your language has a different interface, then you need some way to translate the calls to the other interface. There's no shame in this, Lisp's lambda lists are far superior(&rest, &key, &optional, destructuring-bind and others) than most NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL argument lists encountered in popular OSes. Just a simple example: using &rest is elementary, but using varargs in C, you have to use va_start/va_end(which are actually just macros for accessing the stack) and may have to pass another argument first to guess the amount of arguments in the list, I wouldn't call that easy at all. And keyword arguments are not even worth trying to do in C, as the syntax for using them would be too costly anyway, which is why when someone needs to do something like that, they have to improvise using some structs/unions/enum's to represent something equivalent.

>>30
Lisp's lists are just abstractions over things like linked lists and describe nothing towards their implementation.

>>31
I think everyone knows that lisp lists are just chained conses, and a proper list is one that ends with a NIL. A cons is a pair of 2 objects. The actual representation of a NIL or of the objects is left to the implementation. In practice, they're usually represented using pointers + type tags.

>>30
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL argument lists encountered in popular OSes
you idiot.
NULL, NULL, NULL... for systemcalls is a windows specific thing and much much more common with OO languages like java than C.

>>30
And keyword arguments are not even worth trying to do in C, as the syntax for using them would be too costly anyway
has never heard of #define or enum statements, or at least has no idea how to use them effectively.
you're just a frozenvoid style poster who pretends to be an expert on subjects you know nothing about

>>33
Actually, the Windows NT kernel and user interface is coded in C. It's a fairly complex interface as it tries to be feature-full, so functions with a dozen or more arguments are not uncommon. In most cases people would only need to specify only a few of them, while leaving the rest NULL. In rarer cases you would need to specify most of them. In Lisp, you could just use keyword arguments and specify only those that you need, while leaving the rest unspecified and the compiler would have added code handling these keyword/optional/rest arguments as needed. OO languages like Java have a similar problem, where they try to solve this defficiency by using overloads, but that just makes the user write a lot of boilerplate code. *nix evades the problem by just keeping the argument lists as simple as possible, while sacrificing functionality(Worse is Better), but that isn't the solution to the problem, it's just running away from it.

>>34
Actually I have, and I've written my fair share of complex C macros. They're never as clear and beautiful as their Lisp equivalents, and they can't hide all the uglyness away.

>>35
There is no loss in functionality with *nix system calls, this is bullshit.
>>36
They're never as clear and beautiful as their Lisp equivalents
Only in your opinion.

>>37
Are you claiming that C preprocessor macros are as powerful and expressive as Lisp macros?

>>38
I'm claiming that anything you can do with Lisp you can also do in C and that a good deal of people prefer the look and feel of C than (((((((())))))()()())))))(((())))))))(())))))))))).

>>39
Sure, the languages are turing equivalent, but beware of the land where everything is possible, but nothing of interest is easy.