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.
Name:
Anonymous2009-09-26 10:35
put your anime in hierarchy of folders.
something like this:
anime-> comedy
romance
porn-> tentacle_rape
etc.
it's not fucking hard
Name:
Anonymous2009-09-26 10:38
Lol, didn't we have a thread like this about 2 weeks ago
Name:
Anonymous2009-09-26 11:04
>>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.
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.
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.
>>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.
Name:
Anonymous2009-09-28 5:19
>>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.
>>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.
Name:
Anonymous2009-09-28 6:17
>>27
What's the matter? Can't use system calls without some EFF EFF AYEEEEEEEE?
>>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.
Name:
Anonymous2009-09-28 6:39
>>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.
>>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 (((((((())))))()()())))))(((())))))))(())))))))))).
Reproduce the "not lost" functionality in POSIX environment (you can use Linux, SELinux, *BSD, Solaris or whatever extensions you like, just don't forget to comment the code in question as non-portable).
>>41
There's also the whole memory management suite of functions and many other examples, but I have lost my interest to argue with him as he used the fact that Lisp uses parens to represent S-Expressions as an argument, which shows that he has no idea about what I'm talking about.
lispers obviously do not understand the Unix philosophy and subscribe to the Microsoft philosophy of implementing needless functionality in places where it doesn't belong at the expense of making your code run extra slow and be full of bugs
>>48
Actually they usually understand both philosophies. If you want more historical details about this, check out the "Worse is Better" article.
They don't directly apply to the Microsoft philosophy since they try to make the code look nice and clear/self-documenting first, which is different from "provide all the possible functionality at once". And even then, I might be wrong, as I'm sure there's many kinds of Lispers out there, some of which might think differently. A Lisper's philosophy is more close to the Lisp Machines/Symbolics(`The Right Thing') one than to Microsoft's.
What is needless functionality for someone, might actually be very useful for another person, and I'm grateful to that. There's a balance somewhere in the middle. The Unix philosophy comes from many ages ago, when things were hard to build and technical limitations. Do you things we would have short 2-3 letter command names these days if typing commands wasn't such a chore in the old days(teletype, no auto-completion, clunky keyboards, and so on) when Multics/Unix was first created?
Name:
Anonymous2009-09-28 8:41
>>49
This, actually. Pagers didn't exist until connections got fast enough and even then it was faster to pipe man to lpr.
>>49
jesus, do you ever write short posts?
and yes, i do think we would still use 2-3 letter command names if there was no technical limitations. they are much easier to remember, harder to make a mistake, and quicker type that way.
they are also less ambiguous - if you're talking to someone about grep, there is no question you're talking about grep. grep is grep, it has a unique name and there is no room confusion.
>>51
I have nothing against short commands or the *nix philosophy. It works for what it was made for.
However, most Lisp function names are long, and this poses no problem since the editor can just auto-complete the symbol, for example: I type m-v-b and press the M-TAB key-chord and Emacs auto-completes to multiple-value-bind. It was very easy to type and didn't waste me much time.
Name:
Anonymous2009-09-28 8:55
>>48 Microsoft philosophy of implementing needless functionality in places where it doesn't belong at the expense of making your code run extra slow and be full of bugs
If you had tried to follow the directions I gave in >>41 instead of pretending to be dumber than FV, you might have discovered that to reproduce even simpler pieces of extra functionality on POSIX you'd have to invent your own wheels, which would be slow and full of bugs indeed. Go on, implement `execved` which takes additional `startdir` argument. What, instead of one syscall you now have three? You fork current process and initialize copy-on-write structures just to abandon them immediately? And you forgot to check the return value of `chdir`, bitch.
>>53
to implement any of that extra functionality all you need to do is perform a separate system call.
only a fool would prefer having a function that takes 12 arguments over several that take just one or two. it's MUCH clearer to read that way and MUCH more efficient.
>>55
I'll leave >>53 to give you a full answer, but you know, this reminds me of my earlier post >>30, where I explained that if the language had good syntactic abstraction facilities, which in turn would lead to keyword/optional/rest arguments with ease, the overall syntax for the function call would be very simple, and wouldn't leave NULL, NULL, NULL all over the place.
As for efficiency, this depends on how your system implements process creation, if the process already has all that data associated with it in some system structure, it probably wouldn't cost much (validation of parameters may still cost a bit) to allow specifying it in the process creation function. Just because something looks simpler, doesn't mean it's more efficient, actually in Lisp, if you want better performance, you're going to write more code than a simple terse version. In C, the situation is a bit different, you have to write a lot of code for advanced functionality, but you don't have to work for speed.
So we can say, speed can be easier to achieve in C, but you have to work a lot of functionality. In Lisp, you get functionality easily, but have to work for speed.
>>56
i wasn't arguing about Lisp, i was arguing about long winded function calls that try to do EVERYTHING in one hit, requiring you to spend 10 minutes searching MSDN to see what each arg is actually used for.
i don't really have anything against lisp except for the fact that lispers always seem to be badmouthing C on /prog/
Name:
Anonymous2009-09-28 9:32
>>22 here, there's some progress with inotify but I'm too lazy to parse the inotify struct in memory (and cffi:mem-aref behaves silly IMHO), so here's what I wrote so far:
>>57
That's called being a Smug Lisp Weenie: showing everyone how Lisp does something better than another language. My personal opinion of C is that it's excellent when micro-optimizations and speed are paramount. It's an excellent portable assembler. I use it for those tasks, and sometimes I'm even guilty of using it for more high level problems, but I really have a hard time understanding people who think C is suitable for high level problems, and they just end up greenspunning a lot instead of just using a high level language.
This is not to say that Lisp can't be used to write low-level code, just that micro-optimizations are usually less work in C.
Note: Some Lisp implementations with native code compilers do sometimes include internal facilities for inline assembly, and there's even implementations which provide such things in a documented manner. You just have a macro which assembles some code for you at compilation time, and have the implementation use that piece of code as a function directly.
Name:
Anonymous2009-09-28 10:19
>>58 (defconstant +INOTIFY-MEMORY+ 256)
I use sizeof(struct inotify_event) + NAME_MAX + 1 (16 + 255 + 1 for me).
Name:
Anonymous2009-09-28 10:22
>>55 12 arguments over several that take just one or two. it's MUCH clearer to read that way and MUCH more efficient.
I don't thing the word ``efficient'' means what you think it means.
It doesn't mean "sparing the programmer the need to read manuals (especially if he is too stupid to understand which parameters he don't need by the short description)". Use the expression "easy to use" for that, please.
But well, mr. Unix Programmer, it seems to me that you are a piece of pretentious shit, not a real programmer, and I have a very nice little question that would simultaneously prove it and show the real "efficiency" and "ease of use" of UNIX. The code presented in >>43 contains a serious defect: when the parent process is killed all spawned processes are killed as well and until parent process quits, even terminated spawned processes just sit there waiting for someone to call `waitpid` on them.
Would you kindly explain the steps required from the programmer to understand source of the problem and find the proper way to fix it, then assess both the readability and the efficiency of the solution.
>>61
He could have probably used the groveler to auto-generate the FFI calls/definitions/imports, but I hear some people had some trouble using it.
Name:
Anonymous2009-09-28 10:27
>>61
Right, but if you notice inotify actually is able to return you relative paths too, so that number does not suffice if the path is too long. You should be using PATH_MAX + sizeof (struct inotify_event) to be completely on the safe side.
/*
struct inotify_event {
int wd; // Watch descriptor
uint32_t mask; // Mask of events
uint32_t cookie; // Unique cookie associating related
events (for rename(2))
uint32_t len; // Size of name field
char name[]; // Optional null-terminated name
};
*/
#define WRITE_LOG "inotify.log"
int main(int argc, char **argv) {
int *pfd, watch_fd[10], i, iev = inotify_init();
struct inotify_event *s;
size_t sn = sizeof *s + FILENAME_MAX; /* should be path max */
ssize_t n;
FILE *log;
clock_t t;
>>62
sigh.
there is also no main() function if you want to be a pedantic little shit. it's not a fully fledged program, you fucking moron, did you not notice that with your head shoved so far up your anus?
the reason it's more efficient to do it the Unix way is because your 12 argument function needs to check every parameter and act accordingly, whereas my 2 argument function has only one path of execution.
it's also much easier to read because if i use: setuid(whatever);
chdir(whatever);
execvl(whatever, whatever)
the code is self explanatory. whereas: create_process(NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 24, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, "\\some\\directory",NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 180);
is a complete mess.
you are a bad programmer and you should feel bad
Name:
Anonymous2009-09-28 10:39
>>64 Right, but if you notice inotify actually is able to return you relative paths too, so that number does not suffice if the path is too long. You should be using PATH_MAX + sizeof (struct inotify_event) to be completely on the safe side.
Are you sure? I think it will only have at most one (or none) slash in the name field. I assume NAME_MAX is used for directory names.
[m]The name field is only present when an event is returned for a file inside a watched directory; it identifies the file pathname relative to the watched directory. This pathname is null-terminated, and may include further null bytes to align subsequent reads to a suitable address boundary.[m]
I wonder if read will fail if you don't have enough space for the padding (the read size appears to be a multiple of 32 for me).
Name:
Anonymous2009-09-28 10:40
Guys, I wanted an Anime and Manga management tool. Where it is? I only see code, I want a goddamn binarie, now.
>>69-chan is fired for laughing at this chef.
And you two: >>70 >>71
STFU AND WORK. I'm not paying you for nothing.
Name:
Anonymous2009-09-28 11:37
>>72
I'll be reading SICP. I'll be ready to work on the project when I complete SICP next year.
Name:
Anonymous2009-09-28 11:50
>>66 there is also no main() function if you want to be a pedantic little shit. it's not a fully fledged program, you fucking moron, did you not notice that with your head shoved so far up your anus?
Is it your way to say that you only pretend to be a UNIX programmer? If so, please live comparisons between UNIX and Windows APIs to people who have actually used both.
Also, I recommend you to get back to /b/, as there you'll find people who'll share your idea that even one additional kernel call can be less expensive than OMG 12 NULL checks, here such clownery seems out of place.
>>78
First of all, WinAPI uses the BSD socket interface which is what POSIX standarizes. WinAPI modifies the function prototypes to mismatch (char * instead of void*!), changes ssize_t et cetera to its own types (which are both redundant and god-awful), adds its own set of functions that are related to networking, but makes them mandatory in the sense that you can't write code without them (WSAStartup et al), adds bloat like 'closesocket', does not provide access to raw sockets (sendmsg, recvmsg, ...). That alone should tell you why POSIX is superior for networking compared to WinAPI. Now imagine this for everything WinAPI provides: Microsoft made it bloater, suckier, incompatibl-er with competitors, etc. WinAPI also defines a lot of functionality that according to some should not be part of a standard API for developers. POSIX is almost an extension of C (with some exceptions, for example C says CHAR_BIT >= 8 while POSIX says CHAR_BIT == 8). WinAPI is a different language altogether, with its own types, errors, stupdiity, et cetera.
>>79
It also provides a lot of functionality which POSIX doesn't provide, however various *nix OSes do implement extensions to achieve some of that functionality.
WinAPI is a different language altogether, with its own types, errors, stupdiity, et cetera.
Yes, it's different than ANSI C stdlib and POSIX APIs, however that doesn't make it worse. It is a lot more complex than POSIX, which does mean that it offers a lot more functionality, but the cost is in much added complexity.
>80 Yes, it's different than ANSI C stdlib and POSIX APIs, however that doesn't make it worse. It is a lot more complex than POSIX, which does mean that it offers a lot more functionality, but the cost is in much added complexity.
This 'complexity' you speak of is all the nonsense Microsoft included which should be userland code.
>>81
A lot of it is userland code. For example, everything having to do with DLL's(Dynamic-link library) goes in the userland (of course, kernel mode code(kernel, drivers and others) has its own APIs for loading those). It's actually so well known how this works, that an user could easily implement his own DLL loader/API resolver without calling a single Windows API (it does however depend on some structures being present), it's also possible to do API resolving fully portably(offsets in structures are slightly different for windows 9x and nt, as it's a completly different kernel architecture, but that can easily be solved by checking the OS version in the same structure), for library loading you would actually need memory allocation/protection APIs, so you'll have to use some syscalls if you don't want to use the APIs directly. The actual APIs implemented in kernel-mode go through a mostly well-known interface(documented officially, but subject to change as OS version increases, however the usermode interface is usually not subject to change), and their numbers are not that high(for non-GUI stuff, ~150-350(nt4->nt6)). As for the GUI stuff, they did implement a lot of it in the kernel, but I'm no expert about that, I only care about the essential OS functionality (which means kernel32.dll in user mode and ntoskrnl/win32k in kernel mode).
>>82
It's pretty obvious that you've spent a lot of time with WinAPI and that tells me things about you (that for example, you don't share the same views with me on defining (IMHO) matters), therefore I'm not going to argue with you anymore. Have fun doing what you're doing, ignorance is bliss.
>>83
I did spend a lot of time working with the WinAPI, but that doesn't mean I think it's perfect. I do think it has many flaws, but the POSIX APIs do have plenty of their own flaws.
They're fine examples of what trade-offs one takes when designing such system APIs.
Better, more flexible API and at the same time simpler APIs could be created at the cost of efficiency, but sadly, I don't see this entering the mainstream anytime soon as Windows and Unix-like OSes have most of the marketshare. Such things have been created in the past, but they're now mostly history.
>>83 It's pretty obvious that you've spent a lot of time with WinAPI and that tells me things about you (that for example, you can write far more informed posts than me, which (IMHO) doesn't matter), therefore I'm not going to argue with you anymore. Have fun doing what you're doing, ignorance is bliss.
fixed. no need to thank me
Name:
Anonymous2009-09-28 19:53
>>74
no, it's my way of saying that you're an idiot for thinking that a short snipped of code is supposed to be a fully fledged program, and then criticising me as such.
it is OBVIOUSLY not supposed to be compiled and run as is, you're just grasping straws at random because you know i'm right and you can't prove me wrong.
i laugh at you. truly pathetic
The first anime I ever saw was "Revolutionary Girl Utena" the movie. I was attracted to it because it was bizarre and new. It hit me at a vulnerable time; my father and mother had just been murdered. I became obsessed with the "emptiness inside" theme of the movie, and felt that this related to my life somehow. I watched Evangelion next, and absolutely loved the depressing feeling both of these shows left me with. I am a person who loves depressions; I feel that I am at my most creative and "raw" when utterly depressed. The empty feeling these shows gave me filled me with emotions I wanted to recapture.
Like an addict seeking another hit, I kept downloading more and more programs, watching tons of shows. At one point, I had two shoeboxes full of CD-r's packed with Anime programs. I had a library of just about every show ever made. I became obsessive, but I wasn't finding that feeling that was originally there. Sure, I could recapture it with great stuff like Serial Experiments: Lain and Millenium actress, but that was only for a moment.
Eventually, I stopped watching the shows I was downloading, but just grabbed them for the sake of having them. I had to have more. I bought DVD's and didn't watch them. Gradually, over time, I felt my aesthetic become warped. What once was strange and bizarre looking character design became familiar; I sought it out. If I caught a glimpse of an anime style character in real life, I felt a rush; almost as if my hindbrain saw it before I was aware of it. I was visiting a Japanese tea Garden and saw real life schoolgirls in the familiar navy blue fuku uniforms. I was fascinated by them; I was drawn, attracted, but not in a sexual way; it blew my mind to see something in real life that I had before seen only in the abstract.
A familiar feeling came through me when I saw them. I felt the same at that moment as when I had first seen Utena, when I had first finished Evangelion. My obsession took a new direction.
I bought several sailor fuku uniforms from online retailers. J-list was too expensive and didn't sell in the size I desired. I had to have the legitimate stuff. At first it was satisfying to just look at the uniforms. I would keep them clean, iron them, and hang them up every day. The ritual was soothing to me.
Sooner or later I had to do it. I had to wear the uniforms I had treasured. I am proud to report that it took me a few months to break down, to really cross the threshold into utter depravity. After that line had been crossed, though, there was no going back. Tentatively, I started by simply wearing the uniforms around the house. I would wake up very early, before anyone could glimpse at me from outside on the street, and simply do my cleaning and cooking wearing the various uniforms I purchased. I got a matching apron. I would pretend I was getting ready for Japanese High school.
Soon, though, wearing the uniform in private was not enough. I purchased a duster trenchcoat and began walking through town wearing my outfit. Nobody knew, and this made me comfortable. But, again, this soon became insufficient to satisfy my obsession.
I began stalking this girl I knew, Sarah. I checked out her routines; when she left for work, when she got back, what time she went to bed. At first I furtively ventured into her place with my uniform under my trench coat while she was away. I knew where her spare key was because I had helped her move earlier. Speaking of this, I'm a pretty beefy guy. I weigh around 240-260 pounds, but I'm not that tall. A great friend to have if you need to move.
Anyway, gradually, I became more comfortable in her apartment. I started doing stuff like rolling around in her bed, stealing her underwear and putting it in little plastic bags, soforth. As you would expect, I became more and more comfortable doing this, and crossed a line. She came home unexpectedly one day, early from work. Panicked, I hid under the bed in my uniform. Immediately, as she came through the door, she spotted my trench coat. Lying under her bed, the sound of my heavy breathing seemed a thousand times louder than it actually was. I could hear her rooting through the trench coat, and could hear the wrinkling of celophane as she found my empty plastic bags. Thank god they didn't yet have her used underwear in them.
I put my sweaty, meaty hands together and prayed.
I heard her walking around the apartment. Thankfully, she didn't bring anyone with her. My mind was flashing; the excitement had triggered my epilepsy. Suddenly, I was barraged with memories from my first anime program, revolutionary girl utena. I heard her walking around some more, and then sit down on the bed. I saw her clothes come off and hit the floor in front of me. During this time I was controlling myself and having a minor epileptic fit. I could see transformation sequences from anime programs I had watched. It was all coming together; the near hallucinations, the girl in the bed above me, and most of all, my sweaty fuku uniform.
She approached the bathroom and got into the shower. She turned on the water. I was convinced that this was the one moment I had been searching for. This was my chance to cross over into the other world described in Utena; the fabric of reality was thin. I could taste it. In many of my anime programs I had seen the seemingly normal characters, like me, enter into a world of magic and joy.
I rolled out from under the bed and bounded into the bathroom. She saw my large form approaching through the glass of the shower and started screaming. I was having epileptic flashes; the screaming sounded just like "KYAAAAAAAAAAAAAAAH" I was having trouble walking, my steps staggered. I couldn't feel the floor. My meaty hands slammed the shower door open, but she sprayed me with a jet of water. The water triggered another fit and I seized, falling into the bath. She tripped and fell on top of me. As she was screaming and my blood filled the bath, it swirled around reality, and intermingled in my mind. Her screams, the blood, my sweat, the uniform, Japan, schoolgirls, magic, tragedy, terror, and hope all become one to me. For one moment, I could taste it. The anime reality. It was here, like a precious jewel perched between my meaty, sweaty pectorals. And then, gone.