Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Anime and Manga management

Name: Anonymous 2009-09-26 10:28

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: Anonymous 2009-09-28 7:39

>>37

There is no loss in functionality with *nix system calls, this is bullshit.

http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx

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).

Name: Anonymous 2009-09-28 7:43

>>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.

Name: Anonymous 2009-09-28 7:45

>>41
create a process?
if(fork() == 0){
   char *arg = "some_program";
   execl(arg, arg);
}

lrn2unix

Name: Anonymous 2009-09-28 7:49

>>43
Fuck off.

Name: Anonymous 2009-09-28 7:50

>>44
u mad?

Name: Anonymous 2009-09-28 7:58

>>45
he mad.

Name: Anonymous 2009-09-28 7:59

sure is itrollu in here

Name: Anonymous 2009-09-28 8:07

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

Name: Anonymous 2009-09-28 8:26

>>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: Anonymous 2009-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.

Name: Anonymous 2009-09-28 8:51

>>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.

Name: Anonymous 2009-09-28 8:55

>>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: Anonymous 2009-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.

Name: Anonymous 2009-09-28 8:57

harder to make a mistake
Can you still say that after accidentally rm'ing the wrong files due to a too broad mask?

Name: Anonymous 2009-09-28 9:08

>>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.

you are a pathetic excuse for a programmer

Name: Anonymous 2009-09-28 9:20

>>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.

Name: Anonymous 2009-09-28 9:26

>>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: Anonymous 2009-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:


(cffi:defcenum inotify-mask
  (:IN_ACCESS #16r1)
  (:IN_MODIFY #16r2)
  (:IN_ATTRIB #16r4)
  (:IN_CLOSE_WRITE #16r8)
  (:IN_CLOSE_NOWRITE #16r10)
;  (:IN_CLOSE #16r18) ; 0x8 | 0x10
  (:IN_OPEN #16r20)
  (:IN_MOVED_FROM #16r40)
  (:IN_MOVED_TO #16r80)
;  (:IN_MOVE #16r40 #16r80) ; 0x40 | 0x80
  (:IN_CREATE #16r100)
  (:IN_DELETE #16r200)
  (:IN_DELETE_SELF #16r400)
  (:IN_MOVE_SELF #16r800)
  (:IN_UNMOUNT #16r2000)
  (:IN_Q_OVERFLOW #16r4000)
  (:IN_IGNORED #16r8000)
  (:IN_ONLY_DIR #16r1000000)
  (:IN_DONT_FOLLOW #16r2000000)
  (:IN_MASK_ADD #16r20000000)
  (:IN_ISDIR #16r40000000)
  (:IN_ONESHOT #16r80000000)
  (:IN_ALL_EVENTS #16rFFFFFFFF))


(cffi:defctype uint32_t :unsigned-int)

(cffi:defcfun "inotify_init1" :int
  (flags :int))

(cffi:defcfun "inotify_add_watch" :int
  (fd :int) (pathname :string) (mask inotify-mask))

(cffi:defcfun "inotify_rm_watch" :int
  (fd :int) (wd uint32_t))

(defconstant +INOTIFY-MEMORY+ 256)

(defclass inotify ()
  ((inotify-instance
    :initform (let ((x (inotify-init1 0)))
                (if (= x -1)
                    (error "inotify-init1")
                    x))
    :reader inotify-instance
    :documentation "Inotify instance file descriptor")
   (inotify-table
    :initform (make-hash-table)
    :initarg :table
    :reader inotify-table
    :documentation "Hash table that pathname->wd entries are stored")))

(defmacro with-inotify-instance ((name &optional (flags 0)) &body body)
  `(let ((,name (make-instance 'inotify)))
     (unwind-protect
          (progn ,@body)
       (cffi:foreign-funcall "close"
                             :int (inotify-instance ,name)))))

(defun inotify-add (inotify file-or-dir events)
  "Add or modify file-or-dir to watch list"
  (let ((watch-descriptor (inotify-add-watch (inotify-instance inotify)
                              file-or-dir events)))
    (setf (gethash file-or-dir (inotify-table inotify))
          watch-descriptor)))

(defun inotify-remove (inotify file-or-dir)
  (multiple-value-bind (watch-descriptor bool)
      (gethash file-or-dir
               (inotify-table inotify))
    (when bool
      (inotify-rm-watch (inotify-instance inotify)
                        watch-descriptor))))

(defun inotify-parse-event (event)
  "Parse event from foreign pointer to lisp data"
  (let* ((watch-descriptor (cffi:mem-aref event :int))
         (mask (cffi:mem-aref event :unsigned-int 1))
         (pointer-name (cffi:mem-aref event :pointer 4)))
    (list watch-descriptor mask pointer-name)))
 
(defun inotify-event (inotify)
  "Read event from inotify object"
  (cffi:with-foreign-pointer (pointer +INOTIFY-MEMORY+)
    (if (< 0 (cffi:foreign-funcall "read"
                                   :int (inotify-instance inotify)
                                   :pointer pointer
                                   :unsigned-int +INOTIFY-MEMORY+
                                   :int))
        (inotify-parse-event pointer))))

Name: Anonymous 2009-09-28 9:36

>>58
Cool.

Name: Anonymous 2009-09-28 10:04

>>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: Anonymous 2009-09-28 10:19

>>58
(defconstant +INOTIFY-MEMORY+ 256)
I use sizeof(struct inotify_event) + NAME_MAX + 1 (16 + 255 + 1 for me).

Name: Anonymous 2009-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.

Name: Anonymous 2009-09-28 10:22

>>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: Anonymous 2009-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.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdint.h>
#include <time.h>

#include <unistd.h>

#include <sys/inotify.h>

/*
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;

  if(iev == -1) {
    perror("inotify_init");
    exit(EXIT_FAILURE);
  }
  s = malloc(sn);
  if(s == NULL) {
    perror("malloc");
    exit(EXIT_FAILURE);
  }
  for(pfd = watch_fd, i = 1; i < argc; i++) {
    *pfd = inotify_add_watch(iev, argv[i], IN_ACCESS | IN_DELETE);
    if(*pfd == -1)
      perror("inotify_add_watch");
    else pfd++;
  }
  i = pfd - watch_fd;
#ifdef DEBUG
  // BUG: Duplicate filenames report additions
  printf("%d added to watch list\n", i);
#endif

  log = fopen(WRITE_LOG, "w");
  if(log == NULL) log = stdout;
  /*
 {
    perror(WRITE_LOG);
    free(s);
    exit(EXIT_FAILURE);
  }
  */
  while((n = read(iev, s, sn)) > 0) {
    t = clock();
    fprintf(log, "%s occured in %d at %s!\n", s->mask == IN_ACCESS ?
            "ACCESS" : "DELETION", s->wd, ctime(&t));
    fflush(log);
  }
  free(s);
  close(iev);
  return 0;
}

Name: TRUE TRUTH EXPERT !tQq1sLlmuk 2009-09-28 10:28

tHIS THREAD IS GOING PLACES!

Name: Anonymous 2009-09-28 10:31

>>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: Anonymous 2009-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: Anonymous 2009-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.

You got 2 hours left, consider yourselves lucky.

Name: Anonymous 2009-09-28 10:41

>>68
i lol'd

Name: Anonymous 2009-09-28 10:53

>>68
Are you by any chance a project manager?

Name: Anonymous 2009-09-28 11:17

>>68
http://mitpress.mit.edu/sicp
You too can reach the stars with this knowledge.

Name: Anonymous 2009-09-28 11:33

>>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: Anonymous 2009-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: Anonymous 2009-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.

Name: Anonymous 2009-09-28 11:59

>>74
POSIX is superior to WinAPI.

Name: Anonymous 2009-09-28 12:00

>>74
A complete program is one that actually meets all the stated requirements or reaches a suitable level of complete.

Name: Anonymous 2009-09-28 12:01

>>71
(define (square x)
  (* x x))

(define (abs x)
  (cond ((< x 0) (- x))
        (else x)))

(define (average x y)
  (/ ( + x y) 2))

(define (factorial n)
  (fact-iter 1 1 n))

(define (fact-iter product counter max-count)
  (if (> counter max-count)
      product
      (fact-iter (* counter product)
                 (+ counter 1)
                 max-count)))

(define (sqrt x)
  (define (good-enough? guess)
    (< (abs (- (square guess) x)) 0.001))
  (define (improve guess)
    (average guess (/ x guess)))
  (define (sqrt-iter guess)
    (if (good-enough? guess)
        guess
        (sqrt-iter (improve guess))))
  (sqrt-iter 1.0))

Name: Anonymous 2009-09-28 12:17

>>75
Superior in what way? And where's the proof?
This is becoming about as stupid as /g/ Windows vs Unix threads.

Name: Anonymous 2009-09-28 13:12

>>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.

Name: Anonymous 2009-09-28 13:21

>>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.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List