Wikipedia:Reference desk/Archives/Computing/2010 December 2

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

December 2

Modal JDialog

I'm trying to create a JDialog that's modal, so the owning window is disabled. The dialog is supposed to display a progress bar of another task, but when I try to run this task, it seems to freeze right after making the dialog visible. I've stripped the offending code down to:

JDialog jd = new JDialog(gui, true);
jd.add(whateverComponents);
jd.setVisible(true);
executeWhateverTask();

What is happening here? KyuubiSeal (talk) 00:46, 2 December 2010 (UTC)

I've formatted your source-example, which is about one notch too undescriptive to help us replicate the problem. But are you confused because executeWhateverTask() has not executed yet? I think a modal JDialog will halt other Swing threads - so depending on where it was created (i.e., if executeWhateverTask() would have been called from code in another Swing component), that code won't execute until the dialog completes. Can you elaborate your code just a little bit, so we can see exactly how it is breaking? Possible solutions include starting a thread for "executeWhateverTask()" - and then creating your modal dialog box. Nimur (talk) 02:19, 2 December 2010 (UTC)

That was all the code left in the method, sadly. Everything else was commented out. So I should just make a new Thread and make something implement Runnable? And what command kills the dialog? KyuubiSeal (talk) 03:44, 2 December 2010 (UTC)

The simple version (which may not be true if you call setVisible() other than from the Event Dispatch Thread) is that setVisible() doesn't return until the dialog becomes invisible, but another event pump runs to handle events associated with the dialog. So if the user clicks a button in the dialog, its associated actionPerformed() will get called while jd.setVisible(true); is running (perhaps "hung" is a better description). If your listener then hides (or disposes) the dialog, then your code resumes from the call to setVisible().

You could always cause such hiding other than in response to a user action, either on another thread or via, say, Swing timers. Note that if you have another thread, it can't make the actual updates to the GUI, but it can leave information for a timer to find or it can use things like invokeLater() to make asynchronous requests for updates. (The Java 6 SwingWorker class automates some of these thread interactions.) --Tardis (talk) 15:41, 2 December 2010 (UTC)

Okay, I think I get it, except the second paragraph. So I can't update the dialog from a different thread? EDIT: So I tried using invokeLater(), and it works for sample bits of code. It also works for most of mine, but when it reaches a try clause, it doesn't catch an IllegalThreadStateException. (I'm monitoring a process, and I use process.exitValue() to tell if it's unfinished) EDIT AGAIN: Never mind, that part was me being stupid. Now I can't edit a JLabel or JProgressBar in the dialog :\ Code around that area is:

private String trim(String s) { //Takes out filenames from s, which is taken from an inputstream, which is why s must be returned
	final String[] lines = s.split("\r\nCompressing");
	final int length = lines.length;
	if(length>1) {
		SwingUtilities.invokeLater(new Runnable() {
			@Override
			public void run() {
				label.setText(lines[0]);
				progressBar.setValue(progressBar.getValue()+length-1);
			}
		});
	}
	return lines[lines.length-1];
}

KyuubiSeal (talk) 00:37, 3 December 2010 (UTC)

If possible, use a Reader and then you won't have to deal with \r (and your code will work regardless of newline convention). Otherwise, I don't see anything immediately wrong with this; even if this code ends up on the EDT it won't block because it's invokeLater(). I presume your symptom is that the GUI just doesn't update, so start by throwing a System.err.println() in your run() to verify that it's running. (Do you know how to run your code from a command line so you can see that output? If not, maybe Toolkit.beep() will suffice.) For that matter, you'll want to verify that trim() is ever getting called. --Tardis (talk) 15:16, 3 December 2010 (UTC)

Okay, so trim wasn't being called, and after printing a lot of currentTimeMillis, I found out that process.read() hangs until the non-java process terminates. Here's where that is:

private void executeProcess(final FileGroup f) throws IOException {
		Backup.process = Runtime.getRuntime().exec(Backup.getCommand(f));
		waitToFinish();
		Backup.process = null;
	}

	private void waitToFinish() throws IOException {
		BufferedReader in = new BufferedReader(new InputStreamReader(
				Backup.process.getInputStream()));
		String s = "";
		while(true) {
			try {
				Backup.process.exitValue();
				break;
			} catch (IllegalThreadStateException e) {
				final String s = in.readLine().replaceAll("Compressing ", ""); //Stops at this line
				final File f = new File(s);
				SwingUtilities.invokeLater(new Runnable() {
					@Override
					public void run() {
						label.setText(f.getName());
						progressBar.setValue(progressBar.getValue()+1);
					}
				});
			}
		}
		Backup.process.destroy();
		in.close();
	}

Also, I changed the InputStream to a BufferedReader, as Tardis suggested. So the trim method became really small, so now it's inside waitToFinish(). KyuubiSeal (talk) 18:02, 3 December 2010 (UTC)

First, if Backup.getCommand() returns a String, change that: return String[] instead. Never call Runtime.exec(String); it's unreliable and often a security hazard. (If currently it says something like return "backupprog "+directory;, use return new String[] {"backupprog",directory};; note the space removed.) Second, the proper thing to do is to read from the process until you hit EOF rather than checking to see if it has exited. Then you need no try-catch (always a sign that your code is improved). Finally, if your call to readLine() is blocking, there are several possibilities. One is that your subprocess doesn't flush its output, so it could be a very long time before you can see it, and if the process exits before that your current code won't read its output (read until EOF also avoids this). Another is that it is waiting for input (or perhaps even just waiting for its input to show EOF), so you might try closing the output stream you have for it (which is its stdin). Another is that the program is writing its output on stderr — or is writing something there and waiting for you to read that before it will write to stdout. If it's the latter, you'll have to handle both stdout and stderr. The simplest, but least efficient, way of doing this is reading whichever one shows itself as ready (InputStream.available()) at any given time. Otherwise you can create a thread listening to each (even if the one on stderr is just reading and throwing it away). There is also a technique related to select of which I don't remember the details at the moment; it probably involves the java.nio package. Yes, running external processes is a pain in Java, not least because there's no way to preemptively redirect stdin/stderr to /dev/null when you don't want them. --Tardis (talk) 19:41, 3 December 2010 (UTC)

Well, it wasn't hanging forever, and it did print, just not until after the process finishes. So would it be that it doesn't flush its output? Is there anything that can be done about that? There doesn't seem to be a flush method for its output. Also, for the getCommand(), what exactly would go into the array if the string was "whatever.exe -a -b filename"? Should each switch be its own string? KyuubiSeal (talk) 01:44, 4 December 2010 (UTC)

The not-flushing does seem likely; there's no easy way to change that (you can't flush it from your end). It may just be that whatever.exe was never meant to provide ongoing status updates. If you run it from a terminal and you can see each line being printed, that's because output is buffered differently on terminals; it would in theory be possible to use a pseudoterminal to invoke that same sort of buffering behavior, but I don't know if those even exist on Windows (which I presume from the ".exe" you are using). (I see that people have written expect-like tools for Windows, but I don't know anything about them.) It might be worthwhile to try without BufferedReader (collecting single characters in a loop) to see if you can get smaller bits of output; I don't know if there are any circumstances in which BufferedReader waits for more input than is necessary. Yes, use a string for each argument or option. (The advantage is that the arguments and options may then contain spaces and other special characters without confusing anyone.) --Tardis (talk) 21:48, 4 December 2010 (UTC)

Using InputStreamReader didn't work. Can I call cmd with the getRuntime.exec() and somehow prevent the window from popping up? KyuubiSeal (talk) 04:38, 5 December 2010 (UTC)

I think that even if you could, you would then not be able to read the output of your program; it would be written to the (invisible) cmd window. Assuming that you really care more about the final result than the methodology (and that your program is creating files, which it seems to be), perhaps you could watch the directory where it's creating them and react to them that way? --Tardis (talk) 14:39, 5 December 2010 (UTC)

Hooray! It finally works. All that needed to be done to get the output was process.getInputStream(). :D . Plus, the window never popped up in the first place. Thank you so much! KyuubiSeal (talk) 18:02, 5 December 2010 (UTC)

I'm sorry — what worked? You were already calling process.getInputStream(), weren't you? Or do you mean that you called it via cmd and it worked? I'm glad I could help, even if I don't understand what did help… --Tardis (talk) 20:09, 5 December 2010 (UTC)

Yeah, it was the cmd. Wasn't too clear, was I? :\ Oh well. KyuubiSeal (talk) 02:16, 7 December 2010 (UTC)

Ipod not detected

my computer dont recognise my ipod? —Preceding unsigned comment added by 112.206.91.223 (talk) 04:30, 2 December 2010 (UTC)

I've added a title for you, so that the question stands out from the previous one. CS Miller (talk) 14:09, 2 December 2010 (UTC)

What OS and revision is on the computer? Mac OS X, Windows XP, etc... CS Miller (talk) 14:09, 2 December 2010 (UTC)

A good first thing to rule out is a cable fault. Try a different cable or plug a different ipod into your cable to see if your computer can recognise it then. Exxolon (talk) 19:09, 2 December 2010 (UTC)

Value of learning awk, grep and sed

If you already know a programming language, is it worth learning those tools above? If yes, are there other similar tools in Linux that 'everybody' should know? Quest09 (talk) 12:00, 2 December 2010 (UTC)

Awk, grep, and sed are not programming languages. As such, your question makes little sense. It is similar to asking, "If I can already drive a car, it is useful to ride a bus?" Writing a program and using grep are two completely different things. Further, there is little to "learn". So, I will give you a concrete example. Assume you need to find the file that you remember has the word "hedgehog" in it. You have over 100 files, but you have no clue which file you need. You could write a program to open every file, read through them, locate the word hedgehog, and report the findings. It would be much easier to type "grep hedgehog *". -- kainaw™ 13:35, 2 December 2010 (UTC)

"If I can drive a a car, and have one, is it useful to ride a bus?" is a meaningful question. Isn't awk a programming language? Quest09 (talk) 13:38, 2 December 2010 (UTC)

Yes, awk is a programming language, but in use you will usually find it treated as a quick-and-dirty scripting tool. I often see it being used in a rather complicated manner to replicate the function of sed. As for the question, the usefulness of a bus is not dependent on knowing how to drive a car. Similarly, usefulness of grep and sed (as well as the way in which many people use awk) is not based in any on knowledge of programming. -- kainaw™ 13:49, 2 December 2010 (UTC)

I'm looking at it from a different perspective. If you have a car, you don't need a bus, even if it may be useful for others. If you know how to program, you don't need those tools necessarily, but many got used to them, so they keep using them. (BTW, I believe that I need grep, as long as using Linux, it makes our lives easier).

If you have and can drive a car, there are still occasions where it is useful to know how to catch a bus or train. For example in Perth, Western Australia, it is often much cheaper and easier to catch public transport into the CBD than it is to drive in and find and pay for parking. (Or you might just prefer not to add to the peak-hour traffic congestion). Also, even if you normally drive a car, there are still occasions when your car is unavailable (eg being serviced) or you can't or shouldn't drive but (eg some illnesses or injuries, planning to have a few drinks) but still want to get somewhere. Mitch Ames (talk) 00:25, 3 December 2010 (UTC)

I'm wondering if you're about to dip your toe into Linux for the first time. If so, then I would suggest learning how to use the Linux command line really well. Then, as you get to understand more about Linux you will be in a more knowledgeable position to choose a language that will be the most useful to you.See:Linux command line tutorial. You might also find this explanation invaluable.Linux is Not Windows . Windows appears to be reaching the end of it life-cycle now, so another string for your bow would be useful to have.--Aspro (talk) 13:54, 2 December 2010 (UTC)

Windows still has over 90% of the market share. I don't see it disappearing overnight! Total Linux/Unix distros make up less than 5% of the total market share; around 10% if you count OS X. --Mr.98 (talk) 15:20, 2 December 2010 (UTC)

Don't be silly Mr.98, Windows is always reaching the end of it life-cycle.

”There's nothing so absurd that if you repeat it often enough, people will believe it.” --William James. Debunking the 1% Myth ;Microsoft sees end of Windows era; Usage share of operating systems, etc., etc. --Aspro (talk) 19:18, 2 December 2010 (UTC)

And yet, all of those sites give numbers similar to the ones I had (maybe 10% different, at most), which show that Windows still has a near total dominance in desktop and laptops. Servers and cell phones are a different story, obviously, but unless the OP is going to be a server admin I hardly see the need to worry about it becoming mandatory anytime soon. Someone is being silly here, but it's not me... You can slice and dice the numbers all you want, but whatever wins out in the future amongst the casual computer user, it will not resemble awk, sed, or grep. --Mr.98 (talk) 00:32, 3 December 2010 (UTC)

Sure, but we've got them down to their last 90%! --Sean 19:54, 2 December 2010 (UTC)

It's all in how your count it. iPads, android tablets, game consoles.... are all computer devices that people are using for things they formerly used windows machines for. APL (talk) 22:38, 2 December 2010 (UTC)

So are people using awk and sed on their iPads, tablets, game consoles, smart phones, etc? "Unix as a back-end to a very restricted GUI" is not the same thing as "Unix as your main personal computer OS". Totally different worlds, totally different usage, and totally different level of technical knowledge required. --Mr.98 (talk) 00:32, 3 December 2010 (UTC)

In some ways Perl is a replacement for awk and sed. Most of what you can do with them, you can do with Perl almost as easily. And since Perl is a general-purpose programming language (albeit one heavily oriented toward text processing), there are many things that you might want to do that are much easier in Perl than in awk and sed. Grep, however, isn't replaceable that way (though you might prefer to use a souped-up grep-like tool, like "ack", whose homepage is, tellingly, betterthangrep.com), since you really want searching through files to be as simple as possible. Paul (Stansifer) 15:22, 2 December 2010 (UTC)

Learning Perl is definitely the easiest way to get the abilities that awk, sed, and grep have without learning all three. You can replace their respective commands with Perl equivalents very easily, and if your task grows beyond a one-liner you have all the power of Perl without having to start over. --Sean 19:52, 2 December 2010 (UTC)

I'm surprised at the comment that Perl can replace awk and sed but not grep. The basic functionality of grep can be reproduced by simply executing the Perl statement "print if (/pattern/);" on every input line. (Admittedly, it's not quite a drop-in replacement because Perl's regular expression syntax is a bit different from grep's. But in compensation, Perl's regular expressions are more powerful.) Anyway, while Perl can replace awk and sed and grep, each of those languages or commands has things that it's conveniently tuned to do most easily. It's more convenient to have at least the basic aspects of all of them available to you when writing shell scripts, and especially when reading other people's shell scripts. In fact, I think Perl is more valuable as a replacement for the shell itself, because a Perl program can be made much more robust against the things that shell-script writers are often careless about handling. --Anonymous, 08:55 UTC, December 3, 2010.

Obviously any turing-complete language can replace awk, grep, and sed. It is a matter of ease of use. I concur with the opinion that awk and sed can be replaced by perl without a significant decrease of ease of use, but there are a lot of situations where grep is a lot easier and quicker. -- Q Chris (talk) 09:05, 3 December 2010 (UTC)

Um, I said grep. --Sean 18:05, 3 December 2010 (UTC)

I think perl is probably more valuable, but the evil empire (awk, grep, sed) all use much more efficient regex engines in many cases. Shadowjams (talk) 10:32, 3 December 2010 (UTC)

Computer cabling

Describe past, present and emerging developments in computer cabling including: - Characteristics - Materials - Standards —Preceding unsigned comment added by Lucasratsoma (talk • contribs) 12:23, 2 December 2010 (UTC)

Please do your own homework.

Welcome to Wikipedia. Your question appears to be a homework question. I apologize if this is a misinterpretation, but it is our aim here not to do people's homework for them, but to merely aid them in doing it themselves. Letting someone else do your homework does not help you learn nearly as much as doing it yourself. Please attempt to solve the problem or answer the question yourself first. If you need help with a specific part of your homework, feel free to tell us where you are stuck and ask for help. If you need help grasping the concept of a problem, by all means let us know. Dismas|^(talk) 12:45, 2 December 2010 (UTC)

Powerpoint to PDF

My lecture notes are in a PDF format available for download from my University's website, but at the actual lecture they are a PowerPoint file. When in .ppt, you can print the slides with lines next to the slide to take down notes. Is there any way to get a similar arrangement when I print them in PDF? Thanks, KiloT 13:48, 2 December 2010 (UTC)

Just a clarification... I use slides in my classes. They look like a powerpoint presentation, but they are actually a pdf. I have had students ask for the powerpoint version, but there isn't one. I tried to find a pdf-to-powerpoint converter a while back, but I've never found anything useful. -- kainaw™ 13:53, 2 December 2010 (UTC)

The OP is not asking how to convert PPT to PDF. --Mr.98 (talk) 14:25, 2 December 2010 (UTC)

I don't think so. The best I can do with Adobe Reader is print multiple to a page, and if you modify the "Custom" number per page (e.g. have it set up as 1x3), you get an ample amount of space next to the pages in question. --Mr.98 (talk) 14:24, 2 December 2010 (UTC)

How do you convert them from .PPT to .PDF? --86.133.83.252 (talk) 15:21, 2 December 2010 (UTC)

You used to do it with the pdf-printer utility. Now, Office has a PDF exporter built in. Just select PDF as the type when you save. -- kainaw™ 15:39, 2 December 2010 (UTC)

I wasn't asking how one could, in principle, convert PPT to PDF. I was asking the OP how he, specifically, did this, in case it was using a printer-driver utility.--86.133.83.252 (talk) 17:45, 2 December 2010 (UTC)

The PDF format is designed to fully specify the appearance of the output -- it isn't designed to be modifiable, except in specific cases such as PDF forms that can be filled out. Looie496 (talk) 19:09, 2 December 2010 (UTC)

There are several ways to go from Powerpoint (or Word) to a PDF. One is to have an Office-specific plugin/add-on which will convert the file to a PDF. If you are using this method, you'd have to look at the plugin/add-on settings to see how to control the output. How to do that, or even if it's possible at all varies based on the plugin/add-on. The other, more general, option is to have a PDF converter which acts like a printer driver. That is, the PDF converter makes itself look like a printer to the operating system. So instead of printing to a physical printer, you print to the PDF converter. If you have this type of PDF converter, you just need to set the program to print the slides how you want them, and then print them to the PDF converter, as opposed to your physical printer. - However, all this assumes you have access to the original .ppt file. -- 140.142.20.229 (talk) 22:44, 2 December 2010 (UTC)

8086 addressing modes

Please tell me and describe the 8086 instruction sets and addressing modes in a simple way. —Preceding unsigned comment added by Vicky ds (talk • contribs) 15:32, 2 December 2010 (UTC)

See X86 instruction set and This WikiBook. Roger (talk) 18:27, 2 December 2010 (UTC)

The Intel 8086#Segmentation section describes the addressing modes. I think the hope of finding this stuff described in a simple way is forlorn, though. Looie496 (talk) 19:04, 2 December 2010 (UTC)

what is an Ink Tank Sub-Cartridge

What is an ink tank sub-cartridge. They ddo not appear to have the chip on them to make them work with the printer. Where do the chips come from to make them work. —Preceding unsigned comment added by 108.18.105.110 (talk) 20:20, 2 December 2010 (UTC)

POSIX regex to match a string not containing a given substring

Is it possible to construct a POSIX regex that matches any string that doesn't contain a particular substring, for example match every string not containing "foo"? An attempt at this was added to the Regular expression article, but it doesn't work properly, as discussed on the talk page. This isn't a good example to have in the article anyway, as it is unreadable and not something one would use a regex for. Can it be done though? Winston365 (talk) 23:51, 2 December 2010 (UTC)

It's possible but evil. It's easier to see without repeated characters ("fox"): ^([^f]|f(o?f)*([^fo]|o([^fx]|$)|$))*$, or ^([^f]|f(o?f)*([^fo]|o[^fx]))*(f(o?f)*o?)?$ if your matcher doesn't like the nested/repeated $s. Applications that are strictly matching rather than searching don't need the outer ^$, of course. I think it's safe to say that it's impractical. --Tardis (talk) 00:37, 3 December 2010 (UTC)

Wow, that's a beauty (or monstrosity). Had to stare at that one for quite a while to figure it out. Cool, but certainly evil. ;) Thanks! Winston365 (talk) 01:04, 3 December 2010 (UTC)

Since I'm a perl slave I don't know the answer, but I assume POSIX doesn't accept negative look aheads? If it did then that'd be an easy answer, and much more elegant than the evil answer above. Shadowjams (talk) 10:29, 3 December 2010 (UTC)

It's possible, because the complement of a regular language is also regular. But as shown above, it is ugly to write. --Spoon! (talk) 10:38, 3 December 2010 (UTC)

This would almost never be done in practice, so I don't see the point of muddying the waters with it. If your regex flavor lacks lookaround you would just do "! /foo/". --Sean 18:14, 3 December 2010 (UTC)

Most programs that implement regex also implement a "not" functionality. For example, you can grep for files that do not contain something with -v. -- kainaw™ 18:22, 3 December 2010 (UTC)

That's all very nice until you need to grep all lines that contain foo or do not contain bar.—Emil J. 18:30, 3 December 2010 (UTC)

perl -ne 'print if /foo/ || !/bar/' --Sean 22:03, 3 December 2010 (UTC)

Or, if an quick-and-dirty solution is okay, grep 'foo' * | grep -v "bar", which works if none of your filenames contain bar. Regexes just find text. Something else has to specify what level the regular expression operates. Searching for foo and not bar doesn't make sense unless you specify how far away foo and bar have to be. So the negation really should be at the client level. Paul (Stansifer) 14:15, 4 December 2010 (UTC)

That's foo and not bar. To do or is much harder: perhaps (grep -n foo file; grep -n bar file) | sort -n. --Tardis (talk) 14:30, 5 December 2010 (UTC)