|
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. |
On March 10 2013 13:06 sob3k wrote:Show nested quote +On March 10 2013 12:34 CecilSunkure wrote:On March 10 2013 12:31 sob3k wrote: Here is my question guys:
I am very interested in learning how to design GUI's. I see just absolutely terrible GUI's in major products all the time and I really think I could contribute. I have very basic programming experience, but I'm ready to learn. I may seem silly but I really am passionate about really well designed GUI. It just makes such a huge difference when you don't have to fight a program you may use for hours a day, and I see such garbage running on massive products all the time that I just ache to be able to fix it.
What languages do you guys recommend? I'm interested in all kinds of GUI, games are often a great example of terrible UI that people are forced through, but I'm also totally up for all kinds of applications. I'm just looking for a starting spot. Well I think wxWidgets would be something to try using. A lot of gui work is going to be done with middleware, and most work to be done in terms of designing GUIs will be done by usability experts. A usability expert won't write any code at all and only give feedback on the state of a project. So there's a pretty big separation between the jobs in large companies. Smaller independent developers of games will of course design their own UI, but they won't be hiring someone to do it for them. At Microsoft such a task would be up to the likes of a project manager, which again won't really be writing any code. this is kind of what I was afraid of...So do you have any advice for how I could actually pursue getting into this field? It seems like If I could do the whole process and establish some sort of a portfolio it could get my ass in the door so to speak. how does one become a "usability expert", I mean from my point of view I just cringe on a daily basis seeing these awful design decisions. But I can't expect to just go into a company and say "look, your UI is a fucking disaster, pay me to fix it"....
1. Do it for free 2. Measure the results to see if your new designs were actually more usable 3. Pitch the proven benefits & testimonies of your services to other clients
|
On March 10 2013 13:06 sob3k wrote:Show nested quote +On March 10 2013 12:34 CecilSunkure wrote:On March 10 2013 12:31 sob3k wrote: Here is my question guys:
I am very interested in learning how to design GUI's. I see just absolutely terrible GUI's in major products all the time and I really think I could contribute. I have very basic programming experience, but I'm ready to learn. I may seem silly but I really am passionate about really well designed GUI. It just makes such a huge difference when you don't have to fight a program you may use for hours a day, and I see such garbage running on massive products all the time that I just ache to be able to fix it.
What languages do you guys recommend? I'm interested in all kinds of GUI, games are often a great example of terrible UI that people are forced through, but I'm also totally up for all kinds of applications. I'm just looking for a starting spot. Well I think wxWidgets would be something to try using. A lot of gui work is going to be done with middleware, and most work to be done in terms of designing GUIs will be done by usability experts. A usability expert won't write any code at all and only give feedback on the state of a project. So there's a pretty big separation between the jobs in large companies. Smaller independent developers of games will of course design their own UI, but they won't be hiring someone to do it for them. At Microsoft such a task would be up to the likes of a project manager, which again won't really be writing any code. this is kind of what I was afraid of...So do you have any advice for how I could actually pursue getting into this field? It seems like If I could do the whole process and establish some sort of a portfolio it could get my ass in the door so to speak. how does one become a "usability expert", I mean from my point of view I just cringe on a daily basis seeing these awful design decisions. But I can't expect to just go into a company and say "look, your UI is a fucking disaster, pay me to fix it".... HCI (Human-Computer Interaction) is a good field to look into for this. You'd wanna have skills in prototyping interfaces (there are a lot of toolkits around for doing this, differing depending on whether you're interested in mobile, web, or desktop applications). Most of these tools are going to focus on rapid development without a whole lot of programming (if any). I think if I was trying to convince a company that I could better their product, I would prototype out a better interface to their application to convince them, but there's a lot more to this sort of work than just what you think is best. You'll need knowledge of running usability studies (and being able to analyze the results) and I'd imagine that's pretty hard to develop without working under someone that already has a lot of these skills, unfortunately.
|
Pootie too good!4331 Posts
On March 09 2013 00:31 Yoshi- wrote:Show nested quote +On March 09 2013 00:16 JonGalt wrote:On March 07 2013 18:50 disco wrote:On March 07 2013 15:54 JonGalt wrote:On March 07 2013 04:57 tofucake wrote: do you have php installed and enabled? I have php installed. I think I have it enabled, but I am unsure now. I installed php5, mysql, and phphmyadmin through the terminal the other day. Then I made a dbconfig.php, register.php, login.php, members.php, logout.php, and integrated them with my login.html and register.html. When I try to register a user through register.html, my browser (chromium) just downloads register.php instead of sending the data to the database. I did many searches and it seemed like I did not have the apache2 conf files correctly configured. After editing what was suggested, I still have the same problem. And I don't think I have Xammp installed. If you need more information or I am unclear, let me know. Did you install libapache2-mod-php5 and not just the php cli? (If you want to run php as a apache module that is, which I am assuming you do). Using a package manager (apt-get) makes your life so much easier. It will automatically update the configuration files for you as well. I do have this installed. The same problem persists and is rather annoying. Any ideas or suggestions? I am searching the web and trying to read up but still nothing. http://www.php.net/manual/en/install.unix.apache2.phpSee if steps 7 and 8 apply to your Config file from apache.
I will check this out when my computer is charged again, thanks!
|
On March 10 2013 19:40 tec27 wrote:Show nested quote +On March 10 2013 13:06 sob3k wrote:On March 10 2013 12:34 CecilSunkure wrote:On March 10 2013 12:31 sob3k wrote: Here is my question guys:
I am very interested in learning how to design GUI's. I see just absolutely terrible GUI's in major products all the time and I really think I could contribute. I have very basic programming experience, but I'm ready to learn. I may seem silly but I really am passionate about really well designed GUI. It just makes such a huge difference when you don't have to fight a program you may use for hours a day, and I see such garbage running on massive products all the time that I just ache to be able to fix it.
What languages do you guys recommend? I'm interested in all kinds of GUI, games are often a great example of terrible UI that people are forced through, but I'm also totally up for all kinds of applications. I'm just looking for a starting spot. Well I think wxWidgets would be something to try using. A lot of gui work is going to be done with middleware, and most work to be done in terms of designing GUIs will be done by usability experts. A usability expert won't write any code at all and only give feedback on the state of a project. So there's a pretty big separation between the jobs in large companies. Smaller independent developers of games will of course design their own UI, but they won't be hiring someone to do it for them. At Microsoft such a task would be up to the likes of a project manager, which again won't really be writing any code. this is kind of what I was afraid of...So do you have any advice for how I could actually pursue getting into this field? It seems like If I could do the whole process and establish some sort of a portfolio it could get my ass in the door so to speak. how does one become a "usability expert", I mean from my point of view I just cringe on a daily basis seeing these awful design decisions. But I can't expect to just go into a company and say "look, your UI is a fucking disaster, pay me to fix it".... HCI (Human-Computer Interaction) is a good field to look into for this. You'd wanna have skills in prototyping interfaces (there are a lot of toolkits around for doing this, differing depending on whether you're interested in mobile, web, or desktop applications). Most of these tools are going to focus on rapid development without a whole lot of programming (if any). I think if I was trying to convince a company that I could better their product, I would prototype out a better interface to their application to convince them, but there's a lot more to this sort of work than just what you think is best. You'll need knowledge of running usability studies (and being able to analyze the results) and I'd imagine that's pretty hard to develop without working under someone that already has a lot of these skills, unfortunately.
i was about to post HCI but beat me to it. So i second this.
|
So for this HCI and GUI design stuff do you have any specific recommendations on toolkits or languages I could start working on or looking into now?
Does anyone have any idea how I would get into contact with someone in this field, or at least a first step in finding one?
You guys seem to agree that If I could prototype an improvement and show it/propose it, that would be a good start. So any more specific advice on what I would need to learn in order to do that other than a university HCI program? Who even offers HCI programs?
|
|
|
So nobody has any idea of a starting place for UI design? I feel like there has to be some language I could pick up to get me creating something...its never a waste of time to learn a common language. I'm sick in my mothers apartment for the next 8 weeks and I really want to make some life progress on something.
|
I'm trying to understand piping, but I'm having some trouble with it. My program is supposed to run a linux command that utilizes pipes, and I found some code that does this correctly. However, I don't understand what some of it does.
+ Show Spoiler [Working Code] +#include <unistd.h> #include <sys/wait.h>
// This program runs the following command: ls -ltr | wc -l
int main() { pid_t pid1; char *argvv[2][3] = { { "ls", "-ltr", 0}, { "wc", "-l", 0 } }; // commands to run int status;
int fd[2]; pipe(fd); pid1 = fork(); if(pid1 == 0) /* Child executing */ { close(fd[0]); // Child will not be reading, close this pipe close(1); dup(fd[1]); close(fd[1]); execvp(argvv[0][0], argvv[0]); // Run the command } else /* Parent executing */ { wait(&status); // Wait until child is finished running close(fd[1]); // Parent will not be writing, close this pipe close(0); dup(fd[0]); close(fd[0]); execvp(argvv[1][0], argvv[1]); // Run the command }
return 0; }
In particular, I don't understand what the dup function does, and I don't know what the uncommented close functions are for. Nevertheless, I tried to work off of this example to implement a program that runs a command with 2 pipes, but it's not working correctly:
+ Show Spoiler [Not working Code] +#include <unistd.h> #include <sys/wait.h>
// This program runs the following command: ls -ltr | head | wc -l
int main() { int pid; char *argvv[3][3] = { { "ls", "-ltr", 0}, {"head", 0, 0 }, { "wc", "-l", 0 } }; // commands to run int status;
int pipe1[2]; int pipe2[2]; pipe(pipe1); pipe(pipe2); pid = fork(); if(pid == 0) /* Child executing */ { pid = fork(); if(pid == 0) /* Child's child executing */ { close(pipe1[0]); // Child will not be reading, close this pipe close(1); dup(pipe1[1]); close(pipe1[1]); execvp(argvv[0][0], argvv[0]); // Run the command } else { wait(&status); // Wait until child is finished running close(pipe1[1]); // Child will not be reading, close this pipe close(0); dup(pipe1[0]); close(pipe1[0]); close(pipe2[0]); // Child will not be reading, close this pipe close(1); dup(pipe2[1]); close(pipe2[1]); execvp(argvv[1][0], argvv[1]); // Run the command } } else /* Parent executing */ { wait(&status); // Wait until child is finished running close(pipe2[1]); // Parent will not be writing, close this pipe close(0); dup(pipe2[0]); close(pipe2[0]); execvp(argvv[2][0], argvv[2]); // Run the command }
return 0; }
Hopefully someone can give me some insights into pipes that will help me understand how to work with them.
|
HCI is just common sense...
Yes, it's amazing how often you find software with horribly made interfaces (Bnet 2.0 is a great example), but still... it all comes down to common sense.
I like to believe that whenever I see a badly designed interface it was just the team who neglected UI in order to prioritize more important functionalities on a tight schedule.
|
On March 12 2013 09:35 fabiano wrote: HCI is just common sense...
Yes, it's amazing how often you find software with horribly made interfaces (Bnet 2.0 is a great example), but still... it all comes down to common sense.
I like to believe that whenever I see a badly designed interface it was just the team who neglected UI in order to prioritize more important functionalities on a tight schedule.
right, but obviously I cant just walk into a company with a sketch pad, tell them their UI is trash hire me to tell your programmers what to do, with nothing to show for it.
|
Try QT if you want to develop UI.
|
On March 12 2013 09:29 Beamer wrote:I'm trying to understand piping, but I'm having some trouble with it. My program is supposed to run a linux command that utilizes pipes, and I found some code that does this correctly. However, I don't understand what some of it does. + Show Spoiler [Working Code] +#include <unistd.h> #include <sys/wait.h>
// This program runs the following command: ls -ltr | wc -l
int main() { pid_t pid1; char *argvv[2][3] = { { "ls", "-ltr", 0}, { "wc", "-l", 0 } }; // commands to run int status;
int fd[2]; pipe(fd); pid1 = fork(); if(pid1 == 0) /* Child executing */ { close(fd[0] ; // Child will not be reading, close this pipe close(1); dup(fd[1] ; close(fd[1] ; execvp(argvv[0][0], argvv[0] ; // Run the command } else /* Parent executing */ { wait(&status); // Wait until child is finished running close(fd[1] ; // Parent will not be writing, close this pipe close(0); dup(fd[0] ; close(fd[0] ; execvp(argvv[1][0], argvv[1] ; // Run the command }
return 0; }
In particular, I don't understand what the dup function does, and I don't know what the uncommented close functions are for. Nevertheless, I tried to work off of this example to implement a program that runs a command with 2 pipes, but it's not working correctly: + Show Spoiler [Not working Code] +#include <unistd.h> #include <sys/wait.h>
// This program runs the following command: ls -ltr | head | wc -l
int main() { int pid; char *argvv[3][3] = { { "ls", "-ltr", 0}, {"head", 0, 0 }, { "wc", "-l", 0 } }; // commands to run int status;
int pipe1[2]; int pipe2[2]; pipe(pipe1); pipe(pipe2); pid = fork(); if(pid == 0) /* Child executing */ { pid = fork(); if(pid == 0) /* Child's child executing */ { close(pipe1[0] ; // Child will not be reading, close this pipe close(1); dup(pipe1[1] ; close(pipe1[1] ; execvp(argvv[0][0], argvv[0] ; // Run the command } else { wait(&status); // Wait until child is finished running close(pipe1[1] ; // Child will not be reading, close this pipe close(0); dup(pipe1[0] ; close(pipe1[0] ; close(pipe2[0] ; // Child will not be reading, close this pipe close(1); dup(pipe2[1] ; close(pipe2[1] ; execvp(argvv[1][0], argvv[1] ; // Run the command } } else /* Parent executing */ { wait(&status); // Wait until child is finished running close(pipe2[1] ; // Parent will not be writing, close this pipe close(0); dup(pipe2[0] ; close(pipe2[0] ; execvp(argvv[2][0], argvv[2] ; // Run the command }
return 0; }
Hopefully someone can give me some insights into pipes that will help me understand how to work with them.
Pipes are simple. When you run a program it outputs text. This text can be put into a file like so:
name.exe > out.txt
Then you can use that output as input for another program:
other.exe < out.txt
However you can speed things up tremendously by re-routing stdout for the first program, to go into stdin for the second program. This can be quite a difficult thing to do on your own, but luckily the OS does it for you:
name.exe | other.exe
Here the output from name.exe is going to be sent to stdout, and the operating system will feed name.exe's stdout directly into other.exe's stdin. Neither program will have any knowledge of this rerouting, as the rerouting is done within the OS layer.
You can feed output of programs into other programs as input and form long chains to do various types of actions:
name.exe | other.exe | grep | blahblah > out.txt
Above, output goes from name.exe into other.exe, which then gets piped into grep (to perform some regex or something), then pipe that output into blahlbah, which ouputs into out.txt.
The idea is to use separate executable altogether to perform some common task. This is powerful because each program can be highly specialized to perform a very specific task, and simply be "plugged into" some command line for versatile use.
|
On March 12 2013 12:40 CecilSunkure wrote:Show nested quote +On March 12 2013 09:29 Beamer wrote:I'm trying to understand piping, but I'm having some trouble with it. My program is supposed to run a linux command that utilizes pipes, and I found some code that does this correctly. However, I don't understand what some of it does. + Show Spoiler [Working Code] +#include <unistd.h> #include <sys/wait.h>
// This program runs the following command: ls -ltr | wc -l
int main() { pid_t pid1; char *argvv[2][3] = { { "ls", "-ltr", 0}, { "wc", "-l", 0 } }; // commands to run int status;
int fd[2]; pipe(fd); pid1 = fork(); if(pid1 == 0) /* Child executing */ { close(fd[0] ; // Child will not be reading, close this pipe close(1); dup(fd[1] ; close(fd[1] ; execvp(argvv[0][0], argvv[0] ; // Run the command } else /* Parent executing */ { wait(&status); // Wait until child is finished running close(fd[1] ; // Parent will not be writing, close this pipe close(0); dup(fd[0] ; close(fd[0] ; execvp(argvv[1][0], argvv[1] ; // Run the command }
return 0; }
In particular, I don't understand what the dup function does, and I don't know what the uncommented close functions are for. Nevertheless, I tried to work off of this example to implement a program that runs a command with 2 pipes, but it's not working correctly: + Show Spoiler [Not working Code] +#include <unistd.h> #include <sys/wait.h>
// This program runs the following command: ls -ltr | head | wc -l
int main() { int pid; char *argvv[3][3] = { { "ls", "-ltr", 0}, {"head", 0, 0 }, { "wc", "-l", 0 } }; // commands to run int status;
int pipe1[2]; int pipe2[2]; pipe(pipe1); pipe(pipe2); pid = fork(); if(pid == 0) /* Child executing */ { pid = fork(); if(pid == 0) /* Child's child executing */ { close(pipe1[0] ; // Child will not be reading, close this pipe close(1); dup(pipe1[1] ; close(pipe1[1] ; execvp(argvv[0][0], argvv[0] ; // Run the command } else { wait(&status); // Wait until child is finished running close(pipe1[1] ; // Child will not be reading, close this pipe close(0); dup(pipe1[0] ; close(pipe1[0] ; close(pipe2[0] ; // Child will not be reading, close this pipe close(1); dup(pipe2[1] ; close(pipe2[1] ; execvp(argvv[1][0], argvv[1] ; // Run the command } } else /* Parent executing */ { wait(&status); // Wait until child is finished running close(pipe2[1] ; // Parent will not be writing, close this pipe close(0); dup(pipe2[0] ; close(pipe2[0] ; execvp(argvv[2][0], argvv[2] ; // Run the command }
return 0; }
Hopefully someone can give me some insights into pipes that will help me understand how to work with them. Pipes are simple. When you run a program it outputs text. This text can be put into a file like so: name.exe > out.txt Then you can use that output as input for another program: other.exe < out.txt However you can speed things up tremendously by re-routing stdout for the first program, to go into stdin for the second program. This can be quite a difficult thing to do on your own, but luckily the OS does it for you: name.exe | other.exe Here the output from name.exe is going to be sent to stdout, and the operating system will feed name.exe's stdout directly into other.exe's stdin. Neither program will have any knowledge of this rerouting, as the rerouting is done within the OS layer. You can feed output of programs into other programs as input and form long chains to do various types of actions: name.exe | other.exe | grep | blahblah > out.txt Above, output goes from name.exe into other.exe, which then gets piped into grep (to perform some regex or something), then pipe that output into blahlbah, which ouputs into out.txt. The idea is to use separate executable altogether to perform some common task. This is powerful because each program can be highly specialized to perform a very specific task, and simply be "plugged into" some command line for versatile use. That's a nice explanation and all, but that's not at all what Beamer was asking. He's asking how to implement piping himself, and what you basically told him was "here's how you use pipes if they were already implemented!" 
Anyway Beamer, I'll try to explain. Firstly, if you ever don't understand what a standard C function does, they're all basically in man (so you can just type like `man dup` in a shell and get a nice reference page (or find them online: http://linux.die.net/man/2/dup). Sometimes these will collide with other man pages (like for shell functions), so you can specify a section for them. Pretty much all of the functions dealing with this sort of stuff will be in section 2 (e.g. `man 2 dup`). Anyway, now that you know where to find future details on stuff, onto the explanation!
I'll just add comments to the original working code, since I think that will be a bit simpler to read:
Also available as a gist if you'd prefer to read it syntax highlighted: https://gist.github.com/tec27/0c928496c846c5c9856b + Show Spoiler [Commented code] +#include <unistd.h> #include <sys/wait.h>
// This program runs the following command: ls -ltr | wc -l
int main() { // this variable will store the pid of the currently executing process, more on this later pid_t pid1; // these are your program arguments (you could actually pass these into main instead of creating // them here) char *argvv[2][3] = { { "ls", "-ltr", 0}, { "wc", "-l", 0 } }; // commands to run // this variable will be used to store the result code of the child process int status;
// this is used to store our endpoints for the pipe int fd[2]; // this fills fd with 2 file descriptors, fd[0] is the read end and fd[1] is the write end. // any data you write to fd[1] can be read at fd[0] pipe(fd); // this causes a new process to be created that is a copy of the current process. This new // process receives the same file descriptors as the currently running process, and begins its // execution at the same point we are currently at. pid1 = fork(); // since the child process begins its execution at the same point, we need to check whether we // are in the child process or the parent process in order to decide what to do. fork() returns // different pid results in each process, which allows us to check this with the following if // statement: if(pid1 == 0) /* Child executing */ { // fd[0], as you'll recall, is the read end of our pipe. since this process will be executing // the first command in our chain (ls -ltr), it has no need for reading. Thus, we can safely // close that file descriptor in our pipe-created array close(fd[0]); // Child will not be reading, close this pipe // With this process, we want to pipe all of our output to the next command in the chain // (wc -l). This means we don't want to send the output to STDOUT (the normal destination). // Because of this, we should close STDOUT (which at process start will be at index 1 of the // file descriptor table). close(1); // Now we need to replace STDOUT with our actual destination (the pipe write end). dup() will // copy the given file descriptor into the lowest available position in the file descriptor // table. Since we just opened up position 1 (STDOUT), this call will copy our write end of // the pipe into stdout. dup(fd[1]); // Now that we have a copy of fd[1] in the actual file descriptor table, we no longer need it // open in our pipe-created array, so we close it to clean up. close(fd[1]); // This will run the given command with the given arguments in the current process (meaning // that it uses all the file descriptors we setup). Since we set the STDOUT position to our // pipe instead of the standard file descriptor, anything this program outputs will go to // our pipe. execvp(argvv[0][0], argvv[0]); // Run the command } else /* Parent executing */ { // Keep in mind that anything in this else will be running in a separate process from anything // executing in the if above! This runs in the original (parent) process, and has its own // variables, file descriptors, etc. (although they start from the same initialization point).
// First, we wait for the child process to finish executing. We don't want to start the next // command in the chain until the output is completely in the pipe (although you could; this // is how this particular implementation chose to do it). wait(&status); // Wait until child is finished running // Since we are going to be running the final command in the pipe, any ouput we have will go // to the regular destination (STDOUT). As such, we have no need for the write end of the // pipe-created array. close(fd[1]); // Parent will not be writing, close this pipe // The process we will be executing will be reading data from the pipe (the previous process's // output) instead of from the normal location (STDIN). Because of this, we need to replace // STDIN with the pipe's read end. First we close STDIN... close(0); // Then we dup our read end into its position in the table, as above. dup(fd[0]); // Again, we have copied this file descriptor, so we no longer need to keep the original open. close(fd[0]); // Execute the `wc -l` command. It uses the file descriptors we setup and thus reads from the // pipe instead of stdin. execvp(argvv[1][0], argvv[1]); // Run the command } // this will never actually be reached because the current process image is replaced by execvp, // but your compiler will probably complain otherwise! (oh, and execvp can return if it errors, // like if it can't find the thing you're trying to execute). return 0; }
Hopefully that helps you understand this stuff a bit better so you can get your code working (although it does look mostly correct to me from a glance). I'd encourage you to, instead of approaching this as a copy-paste job, try to generalize it to N piped processes. You'll probably have to do it as a later part of whatever course this is for anyway
|
On March 12 2013 15:03 tec27 wrote:Show nested quote +On March 12 2013 12:40 CecilSunkure wrote:On March 12 2013 09:29 Beamer wrote:I'm trying to understand piping, but I'm having some trouble with it. My program is supposed to run a linux command that utilizes pipes, and I found some code that does this correctly. However, I don't understand what some of it does. + Show Spoiler [Working Code] +#include <unistd.h> #include <sys/wait.h>
// This program runs the following command: ls -ltr | wc -l
int main() { pid_t pid1; char *argvv[2][3] = { { "ls", "-ltr", 0}, { "wc", "-l", 0 } }; // commands to run int status;
int fd[2]; pipe(fd); pid1 = fork(); if(pid1 == 0) /* Child executing */ { close(fd[0] ; // Child will not be reading, close this pipe close(1); dup(fd[1] ; close(fd[1] ; execvp(argvv[0][0], argvv[0] ; // Run the command } else /* Parent executing */ { wait(&status); // Wait until child is finished running close(fd[1] ; // Parent will not be writing, close this pipe close(0); dup(fd[0] ; close(fd[0] ; execvp(argvv[1][0], argvv[1] ; // Run the command }
return 0; }
In particular, I don't understand what the dup function does, and I don't know what the uncommented close functions are for. Nevertheless, I tried to work off of this example to implement a program that runs a command with 2 pipes, but it's not working correctly: + Show Spoiler [Not working Code] +#include <unistd.h> #include <sys/wait.h>
// This program runs the following command: ls -ltr | head | wc -l
int main() { int pid; char *argvv[3][3] = { { "ls", "-ltr", 0}, {"head", 0, 0 }, { "wc", "-l", 0 } }; // commands to run int status;
int pipe1[2]; int pipe2[2]; pipe(pipe1); pipe(pipe2); pid = fork(); if(pid == 0) /* Child executing */ { pid = fork(); if(pid == 0) /* Child's child executing */ { close(pipe1[0] ; // Child will not be reading, close this pipe close(1); dup(pipe1[1] ; close(pipe1[1] ; execvp(argvv[0][0], argvv[0] ; // Run the command } else { wait(&status); // Wait until child is finished running close(pipe1[1] ; // Child will not be reading, close this pipe close(0); dup(pipe1[0] ; close(pipe1[0] ; close(pipe2[0] ; // Child will not be reading, close this pipe close(1); dup(pipe2[1] ; close(pipe2[1] ; execvp(argvv[1][0], argvv[1] ; // Run the command } } else /* Parent executing */ { wait(&status); // Wait until child is finished running close(pipe2[1] ; // Parent will not be writing, close this pipe close(0); dup(pipe2[0] ; close(pipe2[0] ; execvp(argvv[2][0], argvv[2] ; // Run the command }
return 0; }
Hopefully someone can give me some insights into pipes that will help me understand how to work with them. Pipes are simple. When you run a program it outputs text. This text can be put into a file like so: name.exe > out.txt Then you can use that output as input for another program: other.exe < out.txt However you can speed things up tremendously by re-routing stdout for the first program, to go into stdin for the second program. This can be quite a difficult thing to do on your own, but luckily the OS does it for you: name.exe | other.exe Here the output from name.exe is going to be sent to stdout, and the operating system will feed name.exe's stdout directly into other.exe's stdin. Neither program will have any knowledge of this rerouting, as the rerouting is done within the OS layer. You can feed output of programs into other programs as input and form long chains to do various types of actions: name.exe | other.exe | grep | blahblah > out.txt Above, output goes from name.exe into other.exe, which then gets piped into grep (to perform some regex or something), then pipe that output into blahlbah, which ouputs into out.txt. The idea is to use separate executable altogether to perform some common task. This is powerful because each program can be highly specialized to perform a very specific task, and simply be "plugged into" some command line for versatile use. That's a nice explanation and all, but that's not at all what Beamer was asking. He's asking how to implement piping himself, and what you basically told him was "here's how you use pipes if they were already implemented!"  Anyway Beamer, I'll try to explain. Firstly, if you ever don't understand what a standard C function does, they're all basically in man (so you can just type like `man dup` in a shell and get a nice reference page (or find them online: http://linux.die.net/man/2/dup). Sometimes these will collide with other man pages (like for shell functions), so you can specify a section for them. Pretty much all of the functions dealing with this sort of stuff will be in section 2 (e.g. `man 2 dup`). Anyway, now that you know where to find future details on stuff, onto the explanation! I'll just add comments to the original working code, since I think that will be a bit simpler to read: Also available as a gist if you'd prefer to read it syntax highlighted: https://gist.github.com/tec27/0c928496c846c5c9856b+ Show Spoiler [Commented code] +#include <unistd.h> #include <sys/wait.h>
// This program runs the following command: ls -ltr | wc -l
int main() { // this variable will store the pid of the currently executing process, more on this later pid_t pid1; // these are your program arguments (you could actually pass these into main instead of creating // them here) char *argvv[2][3] = { { "ls", "-ltr", 0}, { "wc", "-l", 0 } }; // commands to run // this variable will be used to store the result code of the child process int status;
// this is used to store our endpoints for the pipe int fd[2]; // this fills fd with 2 file descriptors, fd[0] is the read end and fd[1] is the write end. // any data you write to fd[1] can be read at fd[0] pipe(fd); // this causes a new process to be created that is a copy of the current process. This new // process receives the same file descriptors as the currently running process, and begins its // execution at the same point we are currently at. pid1 = fork(); // since the child process begins its execution at the same point, we need to check whether we // are in the child process or the parent process in order to decide what to do. fork() returns // different pid results in each process, which allows us to check this with the following if // statement: if(pid1 == 0) /* Child executing */ { // fd[0], as you'll recall, is the read end of our pipe. since this process will be executing // the first command in our chain (ls -ltr), it has no need for reading. Thus, we can safely // close that file descriptor in our pipe-created array close(fd[0] ; // Child will not be reading, close this pipe // With this process, we want to pipe all of our output to the next command in the chain // (wc -l). This means we don't want to send the output to STDOUT (the normal destination). // Because of this, we should close STDOUT (which at process start will be at index 1 of the // file descriptor table). close(1); // Now we need to replace STDOUT with our actual destination (the pipe write end). dup() will // copy the given file descriptor into the lowest available position in the file descriptor // table. Since we just opened up position 1 (STDOUT), this call will copy our write end of // the pipe into stdout. dup(fd[1] ; // Now that we have a copy of fd[1] in the actual file descriptor table, we no longer need it // open in our pipe-created array, so we close it to clean up. close(fd[1] ; // This will run the given command with the given arguments in the current process (meaning // that it uses all the file descriptors we setup). Since we set the STDOUT position to our // pipe instead of the standard file descriptor, anything this program outputs will go to // our pipe. execvp(argvv[0][0], argvv[0] ; // Run the command } else /* Parent executing */ { // Keep in mind that anything in this else will be running in a separate process from anything // executing in the if above! This runs in the original (parent) process, and has its own // variables, file descriptors, etc. (although they start from the same initialization point).
// First, we wait for the child process to finish executing. We don't want to start the next // command in the chain until the output is completely in the pipe (although you could; this // is how this particular implementation chose to do it). wait(&status); // Wait until child is finished running // Since we are going to be running the final command in the pipe, any ouput we have will go // to the regular destination (STDOUT). As such, we have no need for the write end of the // pipe-created array. close(fd[1] ; // Parent will not be writing, close this pipe // The process we will be executing will be reading data from the pipe (the previous process's // output) instead of from the normal location (STDIN). Because of this, we need to replace // STDIN with the pipe's read end. First we close STDIN... close(0); // Then we dup our read end into its position in the table, as above. dup(fd[0] ; // Again, we have copied this file descriptor, so we no longer need to keep the original open. close(fd[0] ; // Execute the `wc -l` command. It uses the file descriptors we setup and thus reads from the // pipe instead of stdin. execvp(argvv[1][0], argvv[1] ; // Run the command } // this will never actually be reached because the current process image is replaced by execvp, // but your compiler will probably complain otherwise! (oh, and execvp can return if it errors, // like if it can't find the thing you're trying to execute). return 0; } Hopefully that helps you understand this stuff a bit better so you can get your code working (although it does look mostly correct to me from a glance). I'd encourage you to, instead of approaching this as a copy-paste job, try to generalize it to N piped processes. You'll probably have to do it as a later part of whatever course this is for anyway  Yes, I was thinking the same thing. If beamer wanted to just use piping in bash it would have been easy to google it. But to write it is different.
|
On March 12 2013 09:21 sob3k wrote: So nobody has any idea of a starting place for UI design? I feel like there has to be some language I could pick up to get me creating something...its never a waste of time to learn a common language. I'm sick in my mothers apartment for the next 8 weeks and I really want to make some life progress on something.
Download visual studio 2010 express (its free) and use C#. Google around for some example C# project - it easily ties together code with drag-and-drop GUI creation tools.
|
Croatia9526 Posts
On March 12 2013 09:21 sob3k wrote: So nobody has any idea of a starting place for UI design? I feel like there has to be some language I could pick up to get me creating something...its never a waste of time to learn a common language. I'm sick in my mothers apartment for the next 8 weeks and I really want to make some life progress on something. If your priority is just UI design and not the actual programming, Microsoft Expression Blend is a pretty fun tool to play with.
|
Does anyone know if there is a JUnit contrib that allow customizable test execution order?
I know the test dependency is bad blah blah blah, but it's really a pain for Selenium testing when navigation fails at an early level.
(I could switch to TestNG but that's sort of a last resort)
|
On March 13 2013 02:21 ragz_gt wrote: Does anyone know if there is a JUnit contrib that allow customizable test execution order?
I know the test dependency is bad blah blah blah, but it's really a pain for Selenium testing when navigation fails at an early level.
(I could switch to TestNG but that's sort of a last resort) Yeah we use testng where I work.
|
|
|
On March 13 2013 02:21 ragz_gt wrote: Does anyone know if there is a JUnit contrib that allow customizable test execution order? I remember such a feature in a newer JUnit release. It can at least randomize orders I believe, not sure about a user-defined order though. Can tell you more details tomorrow when I have access to work mail.
|
|
|
|
|
|