Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #12873 > unrolled thread
| Started by | Jan Burse <janburse@fastmail.fm> |
|---|---|
| First post | 2012-03-11 21:57 +0100 |
| Last post | 2012-03-13 18:44 +0100 |
| Articles | 11 on this page of 71 — 12 participants |
Back to article view | Back to comp.lang.java.programmer
[Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-11 21:57 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-11 22:10 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-11 17:28 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-11 22:49 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-11 18:13 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-11 23:23 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-11 18:35 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? markspace <-@.> - 2012-03-11 15:51 -0700
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-12 10:58 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Lew <noone@lewscanon.com> - 2012-03-12 07:38 -0700
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-12 20:43 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 16:01 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-03-12 17:28 -0500
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 00:33 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Lew <lewbloch@gmail.com> - 2012-03-12 16:50 -0700
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 00:56 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 20:03 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 01:05 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 20:53 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 14:06 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 14:13 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 11:36 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 17:48 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 17:51 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 13:06 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 19:56 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 01:05 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Lew <lewbloch@gmail.com> - 2012-03-12 17:23 -0700
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 20:51 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-13 02:33 +0000
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Patricia Shanahan <pats@acm.org> - 2012-03-12 20:39 -0700
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 14:17 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 11:38 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-03-12 21:59 -0500
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 14:20 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 11:28 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 17:42 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 13:16 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 18:17 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 18:19 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Silvio Bierman <silvio@moc.com> - 2012-03-12 16:21 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-12 20:35 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Robert Klemme <shortcutter@googlemail.com> - 2012-03-12 22:49 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Silvio Bierman <silvio@moc.com> - 2012-03-13 14:10 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 13:49 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-12 20:16 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-03-12 14:42 -0500
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-12 20:46 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 16:09 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 16:07 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-12 21:27 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 16:52 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-12 22:39 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 17:56 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Robert Klemme <shortcutter@googlemail.com> - 2012-03-12 23:02 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 00:18 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 00:19 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Steven Simpson <ss@domain.invalid> - 2012-03-13 10:28 +0000
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 14:11 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 11:41 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 17:43 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 13:03 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 18:20 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 13:36 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-03-13 12:42 -0500
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 18:51 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 18:51 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-13 19:53 -0400
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-14 01:21 +0100
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Steven Simpson <ss@domain.invalid> - 2012-03-13 17:26 +0000
Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse <janburse@fastmail.fm> - 2012-03-13 18:44 +0100
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2012-03-13 17:43 +0100 |
| Message-ID | <jjntfk$ees$2@news.albasani.net> |
| In reply to | #12959 |
Arne Vajhøj schrieb: > It is a rather risky business to rely on such > features. How does Joshua then do it? Bye
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-03-13 13:03 -0400 |
| Message-ID | <4f5f7dc5$0$286$14726298@news.sunsite.dk> |
| In reply to | #12963 |
On 3/13/2012 12:43 PM, Jan Burse wrote: > Arne Vajhøj schrieb: >> It is a rather risky business to rely on such >> features. > > How does Joshua then do it? All his suggestions were for using well defined and supported behavior. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2012-03-13 18:20 +0100 |
| Message-ID | <jjnvk3$jb2$3@news.albasani.net> |
| In reply to | #12967 |
Arne Vajhøj schrieb: > On 3/13/2012 12:43 PM, Jan Burse wrote: >> Arne Vajhøj schrieb: >>> It is a rather risky business to rely on such >>> features. >> >> How does Joshua then do it? > > All his suggestions were for using well defined > and supported behavior. > > Arne > > Didn't you read my note: People who are not used to work on solutions, please refrain from posting? You are just wasting bandwidth.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-03-13 13:36 -0400 |
| Message-ID | <4f5f85aa$0$283$14726298@news.sunsite.dk> |
| In reply to | #12972 |
On 3/13/2012 1:20 PM, Jan Burse wrote: > Arne Vajhøj schrieb: >> On 3/13/2012 12:43 PM, Jan Burse wrote: >>> Arne Vajhøj schrieb: >>>> It is a rather risky business to rely on such >>>> features. >>> >>> How does Joshua then do it? >> >> All his suggestions were for using well defined >> and supported behavior. > > Didn't you read my note: People who are > not used to work on solutions, please > refrain from posting? I would hope that well defined and supported behavior is a strong preference among people used to work on solutions. There are many places where software being reliable and easy to upgrade and platform independent is considered a good thing. Arne
[toc] | [prev] | [next] | [standalone]
| From | Leif Roar Moldskred <leifm@dimnakorr.com> |
|---|---|
| Date | 2012-03-13 12:42 -0500 |
| Message-ID | <zu-dnQJjvOpuG8LSnZ2dnUVZ8vednZ2d@giganews.com> |
| In reply to | #12972 |
Jan Burse <janburse@fastmail.fm> wrote: > > Didn't you read my note: People who are > not used to work on solutions, please > refrain from posting? > > You are just wasting bandwidth. I think you're confusing the terms "solution" and "hack" here, actually, but that's just me. -- Leif Roar Moldskred
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2012-03-13 18:51 +0100 |
| Message-ID | <jjo1f4$nms$1@news.albasani.net> |
| In reply to | #12977 |
Leif Roar Moldskred schrieb: > Jan Burse<janburse@fastmail.fm> wrote: >> >> Didn't you read my note: People who are >> not used to work on solutions, please >> refrain from posting? >> >> You are just wasting bandwidth. > > I think you're confusing the terms "solution" and "hack" here, > actually, but that's just me. > Conceptually Signal/SignalHandler is a solution for providing a SIGINT hook. When I wrap this in my own class without other visible classes than from java.lang.* I am not anymore dependent on sun.misc.*. For platforms that don't have sun.misc.* I can bundle a different implementation of my class. This is programming by contract. My class defines a contract, and I can deliver what ever realization I want. So its only in as far a hack, because I have not yet done a wide range realization of the contract. But sun.misc.* is already pretty wide range. For example I am not that dependent on Sun/Oracle, since OpenJDK on Linux has also sun.misc.* at the moment. But I am open to suggestions that would provide: - Their own contract - Their own set of realizations What would Joshua do? Bye
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2012-03-13 18:51 +0100 |
| Message-ID | <jjo1fs$nms$2@news.albasani.net> |
| In reply to | #12979 |
Jan Burse schrieb: > > But I am open to suggestions that would provide: > - Their own contract > - Their own set of realizations Same to: FileInputStreamFix
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-03-13 19:53 -0400 |
| Message-ID | <4f5fde0b$0$290$14726298@news.sunsite.dk> |
| In reply to | #12979 |
On 3/13/2012 1:51 PM, Jan Burse wrote: > Leif Roar Moldskred schrieb: >> Jan Burse<janburse@fastmail.fm> wrote: >>> >>> Didn't you read my note: People who are >>> not used to work on solutions, please >>> refrain from posting? >>> >>> You are just wasting bandwidth. >> >> I think you're confusing the terms "solution" and "hack" here, >> actually, but that's just me. >> > > Conceptually Signal/SignalHandler is a solution for > providing a SIGINT hook. When I wrap this in my > own class without other visible classes than from > java.lang.* I am not anymore dependent on sun.misc.*. > > For platforms that don't have sun.misc.* I can > bundle a different implementation of my class. > This is programming by contract. My class defines > a contract, and I can deliver what ever realization > I want. > > So its only in as far a hack, because I have not yet > done a wide range realization of the contract. But > sun.misc.* is already pretty wide range. For example > I am not that dependent on Sun/Oracle, since OpenJDK > on Linux has also sun.misc.* at the moment. > > But I am open to suggestions that would provide: > - Their own contract > - Their own set of realizations I believe the JNI solution is more clean. If you use sun.* and hit a platform where it is not available or work differently, then it is a hard problem to solve. It basically means back to square one. If you use JNI and define a C API with certain semantics, then it should be a relative simple task to implement that on a new platform (assuming that there are expertise about the platform available). Arne
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2012-03-14 01:21 +0100 |
| Message-ID | <jjooan$69u$1@news.albasani.net> |
| In reply to | #12997 |
Arne Vajhøj schrieb: > If you use JNI and define a C API with certain semantics, then > it should be a relative simple task to implement that on a new > platform (assuming that there are expertise about the platform > available). In the present case JNI would be more expensive. I would need to create and bundle a .dll, a .so and a .dyln. And need 3 different platforms to develop them. (When I want to support Windows, Linux and Mac) Using sun.misc.* takes about 1 hour to implement the Ctrl-C handler. If someone comes up with a platform where there is no sun.misc.*, it might be that there is already some other Java class. "personally" using JNI to make something CPU/OS independent is most of the time last resort and NOT a good advice. There are bigger entities which have most likely already faced the problem. One has only to search. For example I found the following just now: http://rxr.whitequark.org/jruby/source/src/org/jruby/util/SunSignalFacade.java org.jruby.util.SunSignalFacade But did not dig further. But for example the good news are the IBM J9 has also sun.misc.*. BTW: It was you guys who slapped this into my face a dozen times, that I have a "personal" program- ming problem, i.e. that it is my fault. But "personal" programming problems that are CPU/OS independent should never call for JNI. Just look around whether the problem is not so "personal". But currently I don't waste some time on sun.misc.*, what interests me is: FileInputStreamFix Which fixes the superflous <EOF>. This is also the title of the thread, and not where do I find a portable sun.misc.*. But the same principle does not apply, that JNI is last resort. Since it is Windows specific, thats why I put [Windows] in the thread title. Here you are right a JNI solutions is feasible. So please forget about sun.misc.* and focus on the <EOF> issue. Bye
[toc] | [prev] | [next] | [standalone]
| From | Steven Simpson <ss@domain.invalid> |
|---|---|
| Date | 2012-03-13 17:26 +0000 |
| Message-ID | <3jc439-dc4.ln1@s.simpson148.btinternet.com> |
| In reply to | #12951 |
On 13/03/12 13:11, Jan Burse wrote:
> Its a custom made wrapper for Signal & SignalHandler.
> In version 1 of the above class I used the package
> sun.misc.*. In version 2 of the above class I
> used reflection i.e. Proxy class etc.. It will
> noop when sun.misc.Signal is not present.
I was going to suggest using Runtime.addShutdownHook(Thread) as a
portable alternative. You don't find out which signal was raised, but
it gives your program a chance to shut down gracefully instead of abruptly.
import java.io.*;
public class TestInput {
public static void main(String[] args) throws Exception {
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
try {
Thread.sleep(10 * 1000);
} catch (InterruptedException ex) {
}
}
});
FileInputStream fs = new FileInputStream(FileDescriptor.in);
byte[] buf = new byte[256];
for (;;) {
System.out.print("test: ");
int len = fs.read(buf);
String str = new String(buf,0,Math.max(0,len));
System.out.println("len = "+len+", buf = "+str+", buf[0]="+buf[0]);
if ("exit".equals(str.trim())) break;
}
}
}
Unfortunately, you still get the same read()==-1 on Windows, while the
read call doesn't return on Linux. Of course, this loop doesn't
terminate on EOF, and while the shutdown hook is still running, you can
continue to type on both Windows and Linux, and have the results printed.
However, this could be a way to distinguish the 'fake' EOF from a real
one. Having received -1, read again. A real one will produce -1 again,
but the fake one will block or yield more input. For a real EOF, the
behaviour seems the same on Windows and Linux, so stop when you get two
'-1's. Can't speak for Mac, or anything else, of course.
Is a read() call's behaviour well defined after a previous call returned
-1? I couldn't tell from a quick scan of the docs.
--
ss at comp dot lancs dot ac dot uk
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2012-03-13 18:44 +0100 |
| Message-ID | <jjo117$mpr$1@news.albasani.net> |
| In reply to | #12974 |
Steven Simpson schrieb: > I was going to suggest using Runtime.addShutdownHook(Thread) as a portable In the final application the SIGINT should enter a monitor, and the end-user can then choose among other things whether he would like to abort the application or not. But the effect is of course also seen with ordinary shut down hooks. When one overrides the SIGINT with the help of Signal/SignalHandler the shutdown sequence is not anymore called. But the handler is free to call System.exit() which will initiate the shut down sequence. > Unfortunately, you still get the same read()==-1 on Windows, while > the read call doesn't return on Linux. Yes, on Linux, it is as it should be. The read call is blocking. > However, this could be a way to distinguish the 'fake' EOF > from a real one. Having received -1, read again. A real > one will produce -1 again, but the fake one will block or > yield more input. For a real EOF, the behaviour seems the > same Actually the standard input stream is special. It can return -1 but will not close. And then after returning -1 it will return normal user input. This works for Linux, Mac and Windows. So one can enter: abc <EOF> def <EOF> Where <EOF> depends on the platform (^D on Mac and Linux, ^Z + Enter on Windows). When doing Buffered str = readLine(). One gets: str = "abc" str = null str = "def" str = null The above is perfectly fine and intended. And one can write applications that use recursive stream input. The only issue on Windows is now that SIGINT injects a EOF. I don't think that in my Monitor case a continued reading might detect the SIGINT EOF. Since the SIGINT will not perform a System.exit(). I guess that eventually in the non-Monitor case after a System.exit() or so, the continued reading might show something, IOException or so. Not sure. But getting two EOF in general might be just the user interaction, and not a SIGINT EOF. Getting two EOF is actually a legal user interaction in my application. For example on can recursively open a REPL, and then exit form it: ?- break. [1] ?- break. [2] ?- <EOF> [1] ?- <EOF> ?- Bye
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.java.programmer
csiph-web