You can subscribe to this list here.
2000 |
Jan
|
Feb
(2) |
Mar
(54) |
Apr
(44) |
May
(22) |
Jun
(24) |
Jul
(35) |
Aug
(34) |
Sep
(14) |
Oct
(11) |
Nov
(77) |
Dec
(21) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(13) |
Feb
(27) |
Mar
(32) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
2023 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
From: <ki...@cs...> - 2001-02-28 22:09:55
|
Michael Kifer writes: > Can somebody check if the proposed change below is correct? It seems > correct to me, but the exact purpose of that code in init_para() in > init_xsb.c is not 100% clear to me. Talking to myself: Actually, I take it back. Even if "w" is replaced with "r", I don't see the purpose of this change. I've verified that the preprocessor works with the c_calling_xsb interface, so it must be something in the way Christos' particular program works. Somehow the standard input gets closed. Christos, can you send us a complete (as small as possible) testcase? --michael >>>>> "CP" == Christos Papaterpos <of Wed, 28 Feb 2001 21:00:02 +0200> writes: CP> To overcome the problem I altered the code in init_xsb.c line 281 into: CP> FILE *stream_in; // ADDITION CP> for (i=1; i<argc; i++) { /* check to see if should redirect output */ CP> if (!strcmp(argv[i],"-q")) { CP> stream_err = freopen("XSB_errlog", "w", stderr); CP> stream_out = freopen("XSB_outlog", "w", stdout); CP> stream_in = freopen("XSB_inlog", "w", stdin); // ADDITION CP> break; CP> } CP> As you can see, I reassign the stdin the same way that stdout and stderr CP> are reassigned to real files. |
From: David S. W. <wa...@cs...> - 2001-02-28 21:53:29
|
Michael Kifer writes: > Can somebody check if the proposed change below is correct? It seems > correct to me, but the exact purpose of that code in init_para() in > init_xsb.c is not 100% clear to me. > > It seems that this freopen code was added relatively recently (last > 6-10 months or so). I added it so that error/warning ouput from XSB when run from c_calling_xsb would have a place to go. Without these, it would just be lost. In debugging we found it very useful to have those logs, so we could see if something went wrong when starting up (or running) xsb. I don't realy know much about how unix handles this I/O. It does look unusual to me to reopen stdin as an output file. How does this work? What this is probably doing is just avoiding the error message? Would the redirection that gpp uses work? I.e., if gpp preprocessing is necessary, does it get done? I don't see how (but maybe it does). -David > >>>>> "CP" == Christos Papaterpos <of Wed, 28 Feb 2001 21:00:02 +0200> writes: > > CP> To overcome the problem I altered the code in init_xsb.c line 281 into: > > CP> FILE *stream_in; // ADDITION > CP> for (i=1; i<argc; i++) { /* check to see if should redirect output */ > CP> if (!strcmp(argv[i],"-q")) { > CP> stream_err = freopen("XSB_errlog", "w", stderr); > CP> stream_out = freopen("XSB_outlog", "w", stdout); > CP> stream_in = freopen("XSB_inlog", "w", stdin); // ADDITION > CP> break; > CP> } > CP> As you can see, I reassign the stdin the same way that stdout and stderr > CP> are reassigned to real files. > > _______________________________________________ > Xsb-users mailing list > Xsb...@li... > http://lists.sourceforge.net/lists/listinfo/xsb-users > |
From: <ki...@cs...> - 2001-02-28 21:26:43
|
Can somebody check if the proposed change below is correct? It seems correct to me, but the exact purpose of that code in init_para() in init_xsb.c is not 100% clear to me. It seems that this freopen code was added relatively recently (last 6-10 months or so). --michael >>>>> "CP" == Christos Papaterpos <of Wed, 28 Feb 2001 21:00:02 +0200> writes: CP> To overcome the problem I altered the code in init_xsb.c line 281 into: CP> FILE *stream_in; // ADDITION CP> for (i=1; i<argc; i++) { /* check to see if should redirect output */ CP> if (!strcmp(argv[i],"-q")) { CP> stream_err = freopen("XSB_errlog", "w", stderr); CP> stream_out = freopen("XSB_outlog", "w", stdout); CP> stream_in = freopen("XSB_inlog", "w", stdin); // ADDITION CP> break; CP> } CP> As you can see, I reassign the stdin the same way that stdout and stderr CP> are reassigned to real files. |
From: Christos P. <cm...@hp...> - 2001-02-28 18:55:36
|
Thanks for the reply. First of all, I should clarify some points on my problem: I am using Windows NT 4 SP3. I am using Java to call the XSB C-calling interface and specifically the "high level" methods like xsb_init_string, xsb_command etc. You are right about the problem with the stdin in the spawning of gpp. To overcome the problem I altered the code in init_xsb.c line 281 into: FILE *stream_in; // my addition to the code for (i=1; i<argc; i++) { /* check to see if should redirect output */ if (!strcmp(argv[i],"-q")) { stream_err = freopen("XSB_errlog", "w", stderr); stream_out = freopen("XSB_outlog", "w", stdout); stream_in = freopen("XSB_inlog", "w", stdin); // my addition to the code break; } As you can see, I reassign the stdin the same way that stdout and stderr are reassigned to real files. To use the C-interface I need the -q parameter in xsb_init_string (otherwise I get a GPF). Now everytime gpp is spawned the dup operations in system_xsb.c (line 434) succeed. If I don't reassign the stdin in init_xsb.c, then the dup operations fail. Naturally, I don't like this crude (and probably erroneous) hacking of the XSB source code. Alternatively I could reassign the stdin from the host language. However, even though this succeeds in Visual Basic, for some reason when using Java it fails. I wish if someone could verify that the ammendment I made in my copy of the XSB source is correct and won't cause potentially any other problems. Thanks again - still looking for a better solution, if possible one that will not involve changing the source. Michael Kifer wrote: > The problem is not with Flora but somewhere in the invocation of a new > process that executes the XSB preprocessor, gpp. For some reason the > standard input to this process is closed. > Did you try to use your Java program to invoke a plain XSB program? > (Say, take the output of the Flora compiler and call it directly from Java). > > Another possibility is that because you are using Windows 95/8 (do you?) > it can't create a new process for whatever reason (it's windows, after all :-) > Try to run it on another system to rule this possibility out. > > m > > PS. Another thought: this could be a problem with the C-calling XSB interface. > Did somebody try to invoke an XSB program that contains preprocessor > statements using this interface? > |
From: Luis F. P. de C. <lu...@cs...> - 2001-02-27 17:30:40
|
Hi, the file "XSB_2_3win.zip", available from sourceforge, is a compiled version for Windows systems. If you have any problems running or accessing it, please let us know. -Luis jef...@ho... writes: > Hi, > I was wondering if you had a pre-compiled version of XSB 2.3 for win 2000 (the prolog interpreter). I do all of my C\\C++ development at school and consequently do not have visual c++ at home, nor do I want to purchase it. > Much appreciated, > Jeff Sward. > Engineering Science, > University of Toronto. > > _______________________________________________ > Xsb-users mailing list > Xsb...@li... > http://lists.sourceforge.net/lists/listinfo/xsb-users |
From: <jef...@ho...> - 2001-02-27 17:14:20
|
Hi, I was wondering if you had a pre-compiled version of XSB 2.3 for win 2000 (the prolog interpreter). I do all of my C\\C++ development at school and consequently do not have visual c++ at home, nor do I want to purchase it. Much appreciated, Jeff Sward. Engineering Science, University of Toronto. |
From: <ki...@cs...> - 2001-02-27 17:13:15
|
The problem is not with Flora but somewhere in the invocation of a new process that executes the XSB preprocessor, gpp. For some reason the standard input to this process is closed. Did you try to use your Java program to invoke a plain XSB program? (Say, take the output of the Flora compiler and call it directly from Java). Another possibility is that because you are using Windows 95/8 (do you?) it can't create a new process for whatever reason (it's windows, after all :-) Try to run it on another system to rule this possibility out. m PS. Another thought: this could be a problem with the C-calling XSB interface. Did somebody try to invoke an XSB program that contains preprocessor statements using this interface? > I am having the following problem with XSB and I am wondering if anyone > can help me. > I have built a small java app that initializes XSB, passes a specific > query and displays the reply. If from within the shell I compile and > test the f-logic code and the query > then I can do the same from the java app. If however, I change my flr > file, then after the compilation of the .flr programm and during the > preprocessing of the .P file, I get the following messages in the > XSB_errlog: > > [Compiling .\MybootstrapFlora] > [MybootstrapFlora compiled, cpu time used: 0.0176 seconds] > [MybootstrapFlora loaded] > [FLORA: compiling .\Data.flr for static loading with options: eqlevel(0)] > [FLORA: Done! CPU time used: 0.138672 seconds] > [FLORA: calling XSB compiler] > [Compiling \Data] > [Preprocessing \Data.P] > ++Warning: SPAWN_PROCESS: Bad stdin=-1; stdin closed by mistake? > ++Warning: SPAWN_PROCESS: Can't fork off subprocess > ++Warning: SPAWN_PROCESS: Subprocess creation failed > > Although these are just warnings, my query does not take exploit the > changed file. Needless to say, every time before making the query I > initialize XSB, and after the query I close both the query and XSB. If I > run my .flr program for the first time and its .P program needs > recompiling, then I get no response to my query. > > The bootstrap program looks like: > :- import bootstrap_flora/0 from flora. > :- import flcompile/1 from flrutils. > ?- bootstrap_flora. > ?- flcompile('Data'). > > Any hints are welcome. I am using XSB 2.2 on Windows NT 4. The java - > XSB connection is done through the XSB_INIT_STRING ........ type calls. > Can this be a problem of FLORA (because, as you can see on the above > snippet from the XSB_errlog, the bootstrap file I am using in .P gets > compiled everytime). > The .flr file includes only simple F-logic predicates (classes and > instances) and no rules. > > Thanks in advance. > > Christos Papaterpos > > > _______________________________________________ > Xsb-users mailing list > Xsb...@li... > http://lists.sourceforge.net/lists/listinfo/xsb-users |
From: Christos P. <cm...@hp...> - 2001-02-27 12:01:53
|
Hi. I am having the following problem with XSB and I am wondering if anyone can help me. I have built a small java app that initializes XSB, passes a specific query and displays the reply. If from within the shell I compile and test the f-logic code and the query then I can do the same from the java app. If however, I change my flr file, then after the compilation of the .flr programm and during the preprocessing of the .P file, I get the following messages in the XSB_errlog: [Compiling .\MybootstrapFlora] [MybootstrapFlora compiled, cpu time used: 0.0176 seconds] [MybootstrapFlora loaded] [FLORA: compiling .\Data.flr for static loading with options: eqlevel(0)] [FLORA: Done! CPU time used: 0.138672 seconds] [FLORA: calling XSB compiler] [Compiling \Data] [Preprocessing \Data.P] ++Warning: SPAWN_PROCESS: Bad stdin=-1; stdin closed by mistake? ++Warning: SPAWN_PROCESS: Can't fork off subprocess ++Warning: SPAWN_PROCESS: Subprocess creation failed Although these are just warnings, my query does not take exploit the changed file. Needless to say, every time before making the query I initialize XSB, and after the query I close both the query and XSB. If I run my .flr program for the first time and its .P program needs recompiling, then I get no response to my query. The bootstrap program looks like: :- import bootstrap_flora/0 from flora. :- import flcompile/1 from flrutils. ?- bootstrap_flora. ?- flcompile('Data'). Any hints are welcome. I am using XSB 2.2 on Windows NT 4. The java - XSB connection is done through the XSB_INIT_STRING ........ type calls. Can this be a problem of FLORA (because, as you can see on the above snippet from the XSB_errlog, the bootstrap file I am using in .P gets compiled everytime). The .flr file includes only simple F-logic predicates (classes and instances) and no rules. Thanks in advance. Christos Papaterpos |
From: Bart D. <Bar...@cs...> - 2001-02-25 00:58:25
|
> Would adding this feature cause any problems? If not, would it be hard to add? twice no there is a small problem with this list of terms that your term_expansion delivers however - and I noticed that SICStus has fallen into the trap; if you have in a file the clause: [foo]. without term_expansion, SICStus considers this as a definition of foo/0, instead of complaining that the builtin for consulting has been redefined; and you can't have the fact []. in a file either ... the convention to deliver a list is apparently ill conceived; but XSB could stick with the SICStus behaviour without a problem Bart |
From: tim f. <fi...@cs...> - 2001-02-24 23:35:22
|
Sicstus Prolog (and others I believe) support the ability to expand a term to a collection of terms. If term_expansion expands a term to a list, then the list members are "spliced into" the place of the term. XSB, however, seems not to support this. I'd like to use it so I could define <=> as an operator and write some code to expand father(X,Y) <=> parent(X,Y), male(X). into :- table father./2, parent/2, male/1. father(X,Y) :- parent(X,Y), male(X). male(X) :- father(X,_). parent(X,Y) :- father(X,Y). Would adding this feature cause any problems? If not, would it be hard to add? -- Tim Finin, Prof Computer Science & Elect Eng, Director Inst. for Global Electronic Commerce, Univ of Maryland Baltimore Cty, 1000 Hilltop, Baltimore MD 21250. 410-455-3522 fax:-3969 fi...@um... http://umbc.edu/~finin/ |
From: Massimo Z. <mas...@in...> - 2001-02-24 19:54:34
|
Hello every body, I have a project heavily based on XSB (jude.sourceforge.net). I'm happy of new XSB release and I want to thank also for old releases that have good worked for me ! I hope you have good work because it is indirectly also a good work for me ! :-)) Best regards Massimo Zaniboni. |
From: Luis F. P. de C. <lu...@cs...> - 2001-02-23 00:20:35
|
The following message is a courtesy copy of an article that has been posted to comp.lang.prolog,comp.lang.misc as well. Version 2.3 of XSB, a tabled logic programming and deductive database system has been released. You can find more information, and download the system from http://xsb.sourceforge.net/ Included below are the changes for this release. ============================= Release Notes for Version 2.3 ============================= General ------- A great number of bugs fixed, new features, performance improvements. News ---- * Subsumption: In addition to variant-based tabling, XSB now provides tabling based on subsumption of calls. In such a "subsumption-based" tabled evaluation, answers from a more general subgoal are used to satisfy a subsumed (more specific) subgoal, thereby permitting greater reuse of computed results. The tabling strategy may be chosen on a per predicate basis. Subsumption-based tabling typically yields better performance in both time and space. However, subsumptive tabling is better suited to more declarative programs, as it may fail to give proper results in the presence of certain Prolog constructs such as var/1. This implementation of subsumption-based tabling correctly evaluates normal logic programs which do not require subgoal delays. * Jumptable Emulator: The system is now able to take advantage of special gcc features to implement a jumptable-based emulator, which speeds up XSB considerably. * Sockets: XSB now supports the socket select call and timeouts. * RDF parser: The XSB libwww package that first appeared in XSB 2.2 now has new interface to the RDF parser provided by e libwww package from W3C. It requires that the libwww library from W3C is installed. * An ISO-compatable throw/catch mechanism: It was already present in version 2.2, but now it is also documented. * Foreign C interface now works on SGI's IRIX. * Backtrackable assert and retract, plus Perl-style associative arrays. (Read about them in the section on modifying the database in Manual 1.) * Oracle Interface: The Oracle interface has been brought up-to-date with newer versions of Oracle. * ODBC Interface: The ODBC interface has been some major cleanups, and several bugs have been fixed; it also now works with SQL Server as well as Access. Support for multiple simultaneous connections has been introduced. Backward Incompatibility ------------------------ * The type bool used by the external C interface has been renamed to xsbBool, because of clashes with various include files that exist on some platforms. Likewise, the macros for dealing with the variable string type used by C programs that call XSB as a library have been renamed. For instance, vstrDEFINE is now XSB_StrDefine. See Vol. 2 of the manual for the new names. * The predicates file_read_line, file_read_line_atom, file_read_line_list have lost the last argument (the indicator of whether the read has read the entire line). This argument is no longer necessary, since buffers expand automatically to accommodate any size input. |
From: <ts...@cs...> - 2001-02-21 14:45:37
|
DLA use of XSB has been through the company XSB, Inc --- which seeks to make money by, among other things, performing interesting applications in XSB. I'm forwarding your email to the appropriate people at XSB, Inc. Regards, Terry Swift |
From: Wise, J. <jw...@dl...> - 2001-02-21 14:33:08
|
Gentlemen, Can you give me references on who in the Defense Logistics Agency has used XSB? Thanks in advance. V/R James W. Wise Computer Program Analyst DSN 932-7516 616-961-7516 |
From: Randall H. <rah...@ic...> - 2001-02-21 03:31:24
|
Dr. Swift: Lpdoc sounds really exicting! When it becomes available, I'll be an enthusiastic user/proponent of it. A few comments, you write: > THUS THE DOCUMENTATION STAYS IN SYNCH WITH THE CODE. As you can tell from > my use of caps here, I think this is important :-) Amen Brother!! I want these asserts and regtypes!! But....in order to keep the documentation from inexorably drifting away from the code, it sounds like you really do need to implement all of Ciao prolog's asserts, regtypes, etc, right? Even worse, if the system itself didn't check modes, regtypes, etc, how would you even know that the documentation was right in the first place? Until we get all that, can I have my humble \begin{code}..\end{code} patch? My proposed extension to XSB would in no way be either mutually exclusive with lpdoc nor in competition with it. Indeed, it could probably be made to be complementary. And with a few morning's worth of work, it could be available to us all... -Randy |
From: Randall H. <rah...@ic...> - 2001-02-21 02:46:09
|
Randall Schulz gives some reasons for delivering literate programming support as a preprocessor, wholly seperate from XSB. These reasons include: 1. It is flexible 2. It is dynamic 3. It is easily changed 4. It is reusable by other prologs/languages 5. It is "(importantly) a seperable, modular component." These are all worthy goals, but allow me submit that with proper coding, we could achieve them all while still making the stock XSB distribution read .lP and .lH modules "out of the box." Doing so would, in addition to yielding the above fine goals, also yield the following benefits: 1. Code sharing of literate prolog programs becomes much easier. It is advantagious to be able to assume that _everyone_ _everywhere_ using version XSB 2.xx and above could "out-of-the-box" use your code without having to bother with yet another external preprocessor to apply to your code. 2. Incremental Development/Debugging becomes much easier. Prolog programs arn't written in the same way as C/C++ programs are. You typically don't write type "make" and link 100 libraries together before trying out a new proceedure. Instead, you just consult a file and try it out. If I had to manually execute a preprocessor on my file first before consulting it, my interactive debugging time would be almost doubled. If this were some very complex proposal, which was never before tried for any language, I too would advocate an experimental phase in which it were implemented outside the stock distribution. But not only is the proposed functionality simplicity itself (just throw away anything outside of a \begin{code}....\end{code} block), it has already been proven to be useful. The Haskell community has been doing it for years. If the gods of XSB think its OK to include this functionality, I'd still gladly pay $500 towards the costs of implementing it. -Randy |
From: <ts...@cs...> - 2001-02-21 02:02:00
|
Here's a detailed response for the entire group, since I havent told a lot of people outside of SB what I'm trying to do with Ciao. The system I'm trying to port is lpdoc. Lpdoc sits on top of GNU's texinfo and Ciao's assertion language. Manuals, readme files, emacs tags, html documentation etc are all generated by lpdoc. Currently I've extended the XSB compiler so that it can compile simple lpdoc-asserted programs, by reading and filtering out the Ciao assertions, including predicate, property, regtype etc assertions in the XSB compilation. At the same time, I've hacked the lpdoc makefiles so that they call a program to translate XSB-isms to information readable by Ciao. Thus, we have .P and .H files as usual, and convert them to specialized form for documentation when and if needed. This is just the crawling stage, but I personally dont like the idea of a non-transparent preoprocessor for documentation. And the current system has already proven useful to document products developed by XSB, Inc and Medicine Rules, Inc. By the way, its worthwhile pointing out that often the most useful documentation concerns the data structures that predicates expect or produce. By using not only comment assertions but non-comment assertions about properties, regular types, etc. lpdoc gives a good way to specify these data structures, to produce documentation from them, and, as explained below, to verify the specifications. Of course, the better goal is to translate lpdoc to XSB. I've started looking at this, and it's exposed some problems with XSB. For instance, lpdoc uses a lot of operators. Its not too much of a problem for Ciao since operators are module-specific, but could be for XSB for which all operators active for an engine in a given state are global to all modules executed by the engine in that state. My current approach is to reduce the use of operators by supporting a *syntactic* subset of lpdoc. For instance, rather than declaring :- regtype p/n ... you'd have to use commas in the directive: :- regtype(p/n ...). To me, not a big deal. Next, the lpdoc people use a lot of ISO-specified character constants, (such as 0'\n) which the XSB tokenizer doesn't always read properly. I spent this morning starting to fix the reader to handle these, but may need another morning or two. Now lpdoc generates documentation not only from comment/2 assertions but from assertions specifying modes, types, global properties, etc. In porting lpdoc to XSB, I also want to generate documentation from XSB-specific directives such as tabling --- once lpdoc is ported this should be easy. Ciao assertions can be used in two other ways, of course. First, using a Ciao preprocessor (currently in Beta release) one can transform programs so that assertions are checked at runtime on test suites. Using such a capability, many of the assertions that generate such as modes, types, can be verified in a test suite. THUS THE DOCUMENTATION STAYS IN SYNCH WITH THE CODE. As you can tell from my use of caps here, I think this is important :-) Ultimately, the assertions can be combined with the XSB compiler just as they are envisioned to be combined with the Ciao compiler. The compiler can become more efficient in both larger things (e.g. checking indices, suggesting trie indexing as opposed to flat indexing) and in smaller things (e.g. optimizions using specialized WAM-style instructions). As for the comments themselves, they're pretty powerful. They consist of ISO-compatable strings with latex-style commands such as @begin{itemize} and @end{itemize}. This is texinfo syntax, but note that if we used \begin{itemize} or \end{itemize} the strings may not be ISO-compatable. Thus, our single, correct, reader supports documentation and code. Furthermore, comments can be placed at the level of applications, modules, predicates, predicate usages and so on, so that you can specify the hierarchy implicitly by commenting. The texinfo language itslf is a subset of latex, but is pretty powerful, and allows inclusion of figures, or specialized latex text if you like. The restriction of texinfo to a subset of latex is not due to Stallman's laziness (I doubt anyone has ever called him lazy) but to the fact that it's trying to generate documentation in several different formats. A final point for the use of lpdoc is that texinfo is a good way of documenting C code, so that the emulator can be documented in somewhat the same style as the XSB code. In terms of Randall's comments, lpdoc isnt quite as flexible at producing latex output as code embedded in latex. It is may be a matter of taste as to whether the code or the text should be primary, but lpdoc offers a methodolocy to link the text with the code in a non-trivial way. If anyone is interested in helping out with this, let me know. I'll eventually put some hooks to lpdoc as a package in XSB, but I have to travel for the first two weeks in March, so it'll have to wait until afterwards. Terry P.S. the downside of lpdoc is that at some point you still have to write the damn documentation :-) |
From: Randall R S. <rrs...@cr...> - 2001-02-21 01:07:39
|
Gentlemen, Let me offer an alternate approach. First of all, I should say that I really like the literate programming notion. I agree that the tools we use to capture algorithms and produce working information processing artifacts should allow a better union of formal / executable content and informal / human-readable content. However, I believe it's inappropriate to graft this functionality into the language itself, much less into one single compiler. I feel it's much better implemented as a separate pre-processing phase. If gpp could be made to handle it, of course that would be ideal. The nesting nature of the markup that I think you're proposing (or referring to) probably makes that impossible, but I haven't looked very carefully at the gpp docs. Failing the gpp option, I suggest a Perl or Python or other easily portable text processing script or tool. Perl seems like the most obvious and most realistically universally available choice. I would make the pre-processor "open" in the sense that I'd advertise it's usage, invocation options, etc. and let XSB programmers use it explicitly if they want to. The next step in integrating this capability, then, would be to modify the current XSB start-up script to sense the .LP suffix and apply the pre-processor before the XSB compiler itself. The last bit is the only part that involves XSB "on the inside" and that's getting it to sense a .LP file during consultation and then run the pre-processor (just as it would with gpp). A nice touch would be to supply generic makefile fragments that users can incorporate into their Makefiles. A script that would automatically batch process .LP files into .P would be handy, too, especially for unmodified XSBs and non-XSB Prologs. This, of course, brings up another advantage of the separate, portable pre-processor: its availability for use with other Prolog systems. As anecdotal evidence for the appropriateness of this sort of approach I recall the early-to-mid-life history of C++'s development. It grew, in part, out of C pre-processor-based experiments and was implemented entirely within an external pre-processor for at least a decade of its early life. The authors clearly favored this approach when designing, implementing, evolving and / or extending a significant language or programming facility. Under these circumstances it's important to maintain the malleability and particularly the independence of the new facility and the existing system it augments.. I'll leave it to you to say whether you think applies to integrating literate programming support with Prolog (in general or XSB in particular). However, unless you know for sure you're just going to code up a pre-specified (and well-specified) behavior and that's it (no experimentation or incremental development), then fine--code it into XSB at whatever level and in whatever language works best. But if not, then I'd say keep it in a more flexible, dynamic, easily changed and very importantly a separable, modular component. Randall Schulz Teknowledge Corp. Palo Alto, CA USA At 16:27 2/20/2001, Randall Helzerman wrote: > > Terry Swift is in the process of porting the Ciao LPDoc system to XSB. > >I took a look over at the Ciao LPDoc website and I like it. I hope also >that Dr. Swift is also porting over the assertions & regular type support >from Ciao prolog as well...those are very cool. > >However, I'd still like \begin{comment}....\end{comment} support. The >reason is that even something like: > > > :- comment(Pred/Arity,Comment). > >has an inherent flaw: it make code the default, instead of comments the >default. This inevitably leads to more code than comments. > >My Haskell code, by contrast, consists _mostly_ of comments and is easily >understood >not just by myself, but by other programmers, whether they know Haskell or >not! > > > (Of course, we could still think about extending XSB in the way you > > suggest. It would take some ferreting out all the places the > > ubiquitous '.P' suffix arises, and then dealing with filtering the > > input, but it should certainly be doable.) > >Well I'm willing to put my money where my mouth is. I'd gladly pay $500 >to someone >who could do it and get it into the next release of XSB. (I realize that's >not a lot of money for something which could well prove to be a tedious >combing >through many many files which are all assumming a ".P" suffex, but its about >all I can cough up before I know how much I'll owe in taxes this year.) > >Any takers? > >-Randy > >_______________________________________________ >Xsb-users mailing list >Xsb...@li... >http://lists.sourceforge.net/lists/listinfo/xsb-users |
From: Randall H. <rah...@ic...> - 2001-02-21 00:26:49
|
> Terry Swift is in the process of porting the Ciao LPDoc system to XSB. I took a look over at the Ciao LPDoc website and I like it. I hope also that Dr. Swift is also porting over the assertions & regular type support from Ciao prolog as well...those are very cool. However, I'd still like \begin{comment}....\end{comment} support. The reason is that even something like: > :- comment(Pred/Arity,Comment). has an inherent flaw: it make code the default, instead of comments the default. This inevitably leads to more code than comments. My Haskell code, by contrast, consists _mostly_ of comments and is easily understood not just by myself, but by other programmers, whether they know Haskell or not! > (Of course, we could still think about extending XSB in the way you > suggest. It would take some ferreting out all the places the > ubiquitous '.P' suffix arises, and then dealing with filtering the > input, but it should certainly be doable.) Well I'm willing to put my money where my mouth is. I'd gladly pay $500 to someone who could do it and get it into the next release of XSB. (I realize that's not a lot of money for something which could well prove to be a tedious combing through many many files which are all assumming a ".P" suffex, but its about all I can cough up before I know how much I'll owe in taxes this year.) Any takers? -Randy |
From: David S. W. <wa...@cs...> - 2001-02-20 22:03:44
|
Randy, Randall Helzerman writes: > > No, the nicest feature of Haskell is that you can make the same document be > both a valid Haskell program *and* a Latex document! Not only does this > solve the otherwise hopeless task of keeping the documentation for a program > up to date with the source code, but it also leverages my paper-writing > abiilties to help with the programming task (and vice versa). Finally, it > seems as though I'm programming with both sides of my brain. > > I'd like to be able to do the same in XSB. What I want to do is the following. > > Any file with an extension of ".lP" is a "literate XSB Program". > > In a literate XSB program, comments are the default. In order to write > prolog code, you have to embed it into \begin{code}....\end{code} blocks. > > What would be the easiest way to do this with XSB? That's an interesting idea. Terry Swift is in the process of porting the Ciao LPDoc system to XSB. This is a system that supports documentation of prolog programs. It knows about predicates and modes and all kinds of stuff and has :- comment(Pred/Arity,Comment). directives for comments, which can be large and document the code. From the comments, postscript, html, etc. forms of documentation can be generated. It's not quite what you envision, but it's an interesting alternative. I'm sure Terry will want to tell you (us all) more about it when he gets back to reading his mail. (Of course, we could still think about extending XSB in the way you suggest. It would take some ferreting out all the places the ubiquitous '.P' suffix arises, and then dealing with filtering the input, but it should certainly be doable.) Regards, -David |
From: Randall H. <rah...@ic...> - 2001-02-20 21:41:00
|
I just completed a course in Haskell, and have come to the conclusion that the nicest feature of Haskell is not the purity, nor type system, nor even the much-vaunted monads. No, the nicest feature of Haskell is that you can make the same document be both a valid Haskell program *and* a Latex document! Not only does this solve the otherwise hopeless task of keeping the documentation for a program up to date with the source code, but it also leverages my paper-writing abiilties to help with the programming task (and vice versa). Finally, it seems as though I'm programming with both sides of my brain. I'd like to be able to do the same in XSB. What I want to do is the following. Any file with an extension of ".lP" is a "literate XSB Program". In a literate XSB program, comments are the default. In order to write prolog code, you have to embed it into \begin{code}....\end{code} blocks. What would be the easiest way to do this with XSB? -Randy |
From: David S. W. <wa...@cs...> - 2001-02-19 21:03:35
|
Joshua Engel writes: > I've noticed something odd about the way various calls to index succeed or > fail. I think there was a bug in index/2 that caused it not to work in many cases. You could use index/3 instead. The bug has been fixed in the current system: warren% xsb [xsb_configuration loaded] [sysinitrc loaded] [packaging loaded] XSB Version 2.3 (Zombie) of February 16, 2001 [sparc-sun-solaris2.6; mode: optimal; engine: chat; gc: copy; scheduling: local] | ?- dynamic(a/3), index(a/3, 2), dynamic(b/3), index(b/3, 1). yes | ?- b(A,B,C). no | ?- We are in the process of making a new release. Sorry for problem. -David |
From: Joshua E. <en...@er...> - 2001-02-19 20:52:20
|
I've noticed something odd about the way various calls to index succeed or fail. Here's a recent XSB session I had: | ?- dynamic(a/3), index(a/3, 2), dynamic(b/3), index(b/3, 1). no | ?- b(A,B,C). ++Error: Undefined predicate: b / 3 Aborting... | ?- a(A,B,C). no | ?- dynamic(c/3), index(c/3, trie), dynamic(d/3), index(d/3, 1). no | ?- c(A,B,C). no | ?- d(A,B,C). no In the first call I declared a/3 and b/3 dynamic and asserted index statements about them. The index call on a/3 failed, so b/3 never got declared dynamic. I then tried again with c/3 and d/3. The call is the same except that I used trie indexing. In this case, even though the overall thing failed (that is, returned "no"), the dynamic call on d/3 must have gone happened. -- Joshua |
From: Luis F. P. de C. <lu...@cs...> - 2001-02-17 00:18:17
|
Hi, You can download XSB from http://xsb.sourceforge.net/. -Luis "Deborah Longley" <ste...@em...> writes: > requesting free copy of Prolog > > from D.Longley > ste...@ho... > > > > > > _______________________________________________ > Xsb-users mailing list > Xsb...@li... > http://lists.sourceforge.net/lists/listinfo/xsb-users |
From: Deborah L. <ste...@em...> - 2001-02-16 19:29:59
|
requesting free copy of Prolog from D.Longley ste...@ho... |