Ciao-users May 2003

ciao-users@cliplab.org

12 participants
18 discussions

Re: "Printing" a term to a string
by Richard A. O'Keefe 20 May '03

20 May '03

Armin Rigo <arigo(a)tunes.org> wrote: By my definition 'text' streams are understood to be a subset of all 'binary' streams. Oh, neat trick. Neat trick. If text does worse than binary, that proves binary is better. But if text does better than binary, text is just a special case of binary, so that proves binary is better. I cannot comment these numbers more without any clue about how the files were actually encoded. The binary file was encoded as native binary, and written using fwrite(). The text file was encoded as little-endian hex, with spaces between numbers. By widening the average length of the bit strings, it was possible to push the text time above the binary time, and the text file size about the binary file size. But, and this is the big point, the cost of writing the data was STILL less than the cost of generating it in the first place. In short, the practical point is that - information encoded as printable ASCII can take LESS space than the same information encoded as native binary - information encoded as printable ASCII need never take MUCH more space than the same information encoded as native binary - writing information as printable ASCII can take LESS time than writing it as native binary - writing information as printable ASCII need never take MUCH more time than writing it in native binary - whichever you do, if you do it _well_, the major cost is going to be the cost of generating the data - so the advantages of native binary encoding over printable ASCII are slight to nonexistent. This must be interpreted with some care when dealing with floating point. "text" is not necessarily the same as "decimal". Fast text transmission forms for floating point are _not_ decimal. > If you want C, you know where to find it, and you can call it from > Prolog. How then do I efficiently delegate to my C snippet a block of data that my Prolog program should acquire from some external source ? Using the same kind of interface you *got* it from in the first place. Better still, the block of data should never enter the Prolog world in the first place. The C world should give the Prolog world information about _where to find it_, and the Prolog world should pass that information back to the C world. That way you can accept and forward a gigabyte as fast as you can accept and forward a single byte. > Here, of course, I'm referring to NATIVE binary formats. > If you talk about things like ASN.1 or XDR, most of the difficulties > I mentioned go away. But so, of course, does the claimed efficiency > advantage of binary representations. I am not particularly talking about 'native' binary, if you mean by that processor- or whatever-dependent format. I am not particularly talking about standards like ASN.1, either. There is plenty of room inbetween, where you assign a well-defined but custom meaning to a sequence of bytes (as opposed to a sequence of words or lines). The key point is this: if there is a chunk of data that is to be *processed* in Prolog, then reading and writing it a byte or character at a time is the most convenient way to reading and write it, and the cost of doing so is at worst comparable to the cost of fetching elements out of a block by any other means BUT if there is a chunk of data that is simply to be *routed* by Prolog, without Prolog actually looking at the contents of the chunk, then the chunk should never enter the Prolog world at all, only a descriptor. I am talking about 'SWI strings': atom-like objects that are not guaranteed to be unique. These (not atoms) have a minimal allocation overhead which is 'amortized constant' with respect to their length (where 'amortized constant' has the precise complexity theory meaning). Ah. You're referring to section 4.23 of the SWI Prolog manual. Did you note the bit where it said "new code should ... us[e] atoms"? I'm having trouble interpreting "'amortized constant' with respect to their length". I understand amortised very well; what I don't understand is the "with respect to their length bit", which cancels the "constant" bit. >From the SWI Prolog manual it is clear that the cost of creating a > SWI string that is N bytes long is proportional to N. I don't see > how that can be called "constant" in any sense; it's linear. I note that the space required for a SWI string is only a constant factor less than the space required for a compound term, or even a list of characters. But the important thing is that making a SWI string does involve allocating space on the global stack, which will typically have to be checked by the garbage collector. It cannot possibly be as fast as NOT making a Prolog data structure to hold a copy of the data and NOT copying the data. If you have a block of data in the C world, _leave_it_there_. Here's what I'm getting at. Suppose you have a chunk source, two chunk sinks, and a chunk classifier. route_chunks :- repeat, ( get_chunk(Start, Length), ( Length > 0 -> classify_chunk(Start, Length, Class), ( Class = 1 -> put_chunk_here(Start, Length) ; Class = 2 -> put_chunk_there(Start, Length) ; true ), hey_source_I_have_finished_with_this_chunk(Start, Length), fail ; ! ) ). All that moves between the C world and the Prolog world is the Start and Length of the chunk. Now, it's not just because one of the layers is Prolog that this is the right thing to do. If you are routing chunks in C, the right thing to do is LEAVE THE CHUNK WHERE IT IS, not copy it around. Some years ago someone made measurements that showed a UNIX kernel spending about 20% of its time just copying bytes from one place to another. There are alternative I/O system designs, like the "container shipping" design, a vague memory of which is at the back of my recommendations here. ============================================================================== Message: Address: Action: help majordomo(a)clip.dia.fi.upm.es Info. on useful commands subscribe ciao-users-request(a)clip.dia.fi.upm.es Subscribe to this list unsubscribe ciao-users-request(a)clip.dia.fi.upm.es Unsubscribe from this list <whatever> ciao-users(a)clip.dia.fi.upm.es Send message to list ----------------------------------------------------------------------------- Archived messages: http://www.clip.dia.fi.upm.es/Mail/ciao-users/ -----------------------------------------------------------------------------

1 0

Re: "Printing" a term to a string
by Richard A. O'Keefe 19 May '03

19 May '03

I'll focus my answer to the problem of reading/writing binary data. Using plain text to transfer information between programs always strike me as utterly inefficient anyway (even if it is often greatly appreciated in practice), and reading/writing from a user terminal doesn't need to be efficient. Claims like "utterly inefficient" are so much marsh gas without actual numbers. Here's one example. I wrote a program that generates 2**22 bit strings from 1 to 32 bits each, stored in an array of unsigned long. The cost of generating them and writing them out 5 times was: text version: 3.95 user + 0.13 system = 4.08 total seconds. binary version: 5.06 user + 2.08 system = 7.14 total seconds. This really doesn't look like a victory for binary, especially when you realise that the binary version was 1.6 times bigger. I don't call nearly twice as fast and nearly twice as small "utterly inefficient", and I don't believe anyone else would either. I refuse to focus on reading/writing binary data. I have several reasons for this. (1) That's just not what Prolog is about. Prolog's strengths are in the area of text and symbolic processing; these days the top Prolog systems are also good at some kinds of constraint logic programming. If you want C, you know where to find it, and you can call it from Prolog. (2) As it happens, I am supervising a 4th year student who _is_ very VERY interested in processing binary data. MIDI data, in fact. But this has to be grovelled over byte by byte; using a block level interface for reading and/or writing MIDI data would be about as sensible as using hedge clippers to trim your fingernails. This leads to my major point, which is that if you are DOING something with the binary data, chances are that the overheads of moving one item at a time between the Prolog world and the C world are dwarfed by the processing costs. (3) I have used binary data transmission between programs. And I have done it both before there was such a thing as the System V ABI (where processor supplements are supposed to spell out record layout for C) and between systems that had no interest in being in any way like System V. I have experienced UNIX systems where three different compilers laid simple structs out three different ways (not realised until _after_ the data failed to read). I have transmitted data from a 5-character-per-word machine to a 2-character-per-word machine via a 6-character-per-word machine. (I never want to do that again, especially if paper tape is involved.) I have spent hours sweating over how to convert between IBM mainframe, VAX, IEEE, and sort-of- like-IEEE-but-not-really floating point formats. I have found systems where one compiler could generate any of six different record layouts depending on compile-time options. I have had to deal with binary data containing addresses where a program was loaded at a different address each time it was run (and I see that some version of BSD is bringing this back in the interests of defeating the stack-smashing bandits). I've heard horror stories from friends about two C++ programs compiled with the same headers being unable to share data in a shared memory region (because the vtables were different). Then there's the fact that the processor- specific System V ABI supplements have nothing to say about record layout in Fortran or Pascal, let alone Ada or Eiffel. Put it this way, using binary formats to transfer information between programs that differ in even the slightest respect (such as being two different processes running the *same* executable on the *same* machine at the *same* time) may be efficient, but it's crazy. Here, of course, I'm referring to NATIVE binary formats. If you talk about things like ASN.1 or XDR, most of the difficulties I mentioned go away. But so, of course, does the claimed efficiency advantage of binary representations. (4) There's a vast tide of information flowing over the net. A lot of it is pictures and movies, which Prolog should be delegating to other processors anyway. Almost all the rest is text. All other information sources (disk files, sockets, unix pipes...) can typically be accessed a block at a time. Actually, in Unix, the native OS call is the block-oriented 'read' and 'write' for all types of file descriptors, even for conceptually character-oriented pipes. This is highly relevant to how the bottom layer works. It is highly IRRELEVANT to how the top layer works. This is, after all, the point of distinguishing layers. I have already shown in some detail how a single-byte-at-a-time interface (to the Prolog world) can be as efficient as anyone could wish for, built on a block-at-a-time C world layer. There are three activities: *generation* (the top layer's "writing" facilities) *transmission* (the bottom layer's concern) *parsing and processing* (the top layer's "reading" facilities) It is important to decouple these activities. I note, by the way, that one of the important points for the Quintus block layer was the fact that some important operating systems distinguish logical blocks and physical blocks, and what they actually _give_ you is physical blocks, which you have to reassemble yourself. If the top layer works in terms of blocks, there isn't the slightest reason to expect _those_ blocks to have any simple relationship to the blocks exchanged with the operating system. Even in UNIX, it may be necessary to issue several read() or write() requests to transmit a single logical block, and you don't know until you try whether a single read() or write() request will actually suffice. > OK, what are the type and mode of Block? As you point out, it has to be -, and the only reasonable data structure it can return is some kind of native packed string (like in SWI Prolog). SWI Prolog programmers routinely use atoms where other Prolog programmers might have used character lists. SWI atoms are compact, and garbage collected. They are well suited to holding text that you are just going to pass on. They are NOT convenient for generation or parsing and processing. But the overhead of having to allocate that memory is minimal. Well, no. On a 250MHz machine, I measured the cost of creating a 5-character atom as 33 microseconds. The cost of calling get_byte/1 5 times was measured as 17.5 microseconds. The cost you dismiss as "minimal" is in fact nearly twice the cost of single-byte input. It is an amortized constant. It is not amortized and it is not constant. A new object has to be created *EACH* time. This is Prolog, not C. Actually reading data into that buffer is a single system call. There is no need for any loop in your program, the OS kernel handles all details. This has never been true in UNIX. If you want to read N bytes, where N > 1, you MUST have a loop, because the operating system is under no obligation whatsoever to deliver all N bytes at once. Indeed, it may be unable to. (The same applies to write().) You just cannot make it more efficient on a Unix architecture (disregarding mmap(), which I concede has strong limitations). I _agree_ that reading and writing blocks is the right way to go IN THE BOTTOM LAYER. That's why Quintus did it that way; layering get0/1 on top of glue code on top of getc() on top of RMS on top of QIO was seriously inefficient (almost, but not quite, as bad as Java). Moving to a block-oriented bottom layer with "universal" mapping above meant that we just had get0/1 on top of glue code on top of QIO. As I've already shown, the fast path for the glue code can be EXTREMELY fast, although the VAX, M68k, and /370 were sufficiently register poor that it wasn't practical at the time to make it _quite_ that fast. On Unix applications, implementing block-reading in term of character-reading is an abstraction inversion (http://cliki.tunes.org/Abstraction%20Inversion) because the kernel natively provides block-reading. This is argument by alluding to intimidating authority, and as such uncompelling. It's basically uncompelling for three reasons: (1) I am not at all arguing that block reading should be implemented in terms of character reading. I'm arguing precisely the opposite: that character reading is practically always the right abstraction for Prolog, and that it should be implemented in terms of block reading. (2) the abstraction that matters is the abstraction your program NEEDS not the abstraction your operating system provides. I keep on trying to make the point that it is a waste of time worrying about the raw transput costs if you don't worry about the generating and processing costs. A program whose cost is dominated by raw transput is a program which isn't _doing_ anything much with its data, and about the only useful program of that kind is 'cat'. (3) The block abstraction provided by UNIX is ***not*** "the blocks you find convenient in your source code" but "the block fragments that the kernel finds convenient to accept or return". In the plainest possible terms, the block transput abstraction provided by UNIX is *not* the abstraction any program which generates or processes data wants; only a program whose task is simply to *route* data can be satsified with it directly. As witness: fread() and fwrite(), which do NOT map onto single read() and write() calls. > To wrap up, there is a logic programming language with Prolog-like > syntax in which it *is* possible to do byte-block-at-a-time I/O > without breaking the language's semantics, and that is Mercury. You are too concerned about the allocation cost. A lot of high-level languages more dynamic than Mercury have immutable string-like buffers and very successfully return them as a result of a block-reading operation (http://www.python.org). I am concerned about the allocation cost because I have *measured* it, it is an *avoidable* cost, and because it is the cost of making most Prolog I/O *harder* to write correctly, not easier. ============================================================================== Message: Address: Action: help majordomo(a)clip.dia.fi.upm.es Info. on useful commands subscribe ciao-users-request(a)clip.dia.fi.upm.es Subscribe to this list unsubscribe ciao-users-request(a)clip.dia.fi.upm.es Unsubscribe from this list <whatever> ciao-users(a)clip.dia.fi.upm.es Send message to list ----------------------------------------------------------------------------- Archived messages: http://www.clip.dia.fi.upm.es/Mail/ciao-users/ -----------------------------------------------------------------------------

2 1

Re: "Printing" a term to a string
by Richard A. O'Keefe 14 May '03

14 May '03

I wrote: > You want to work in terms of a BLOCK at a time. Armin Rigo <arigo(a)tunes.org> continues: Yes, exactly. Even on Unix in C nobody uses the character-oriented functions on the C API any more; using block-oriented functions is much more efficient. For reading and writing binary information, that's so; fread() and fwrite() have been there a long time. For reading and writing text, you might be surprised. The technique of reading a block at a time and throwing it at an "inverted" parser, as used in expat and SWI SGML, does lead to fast parsers (although expat is not as fast as my XML parser, which doesn't do that). But it also leads to parsers that are very hard to write. A high speed parser that does the wrong thing because it was too complex for its author to understand is not an efficient one. Something that is not often appreciated is that character I/O in the spirit of C can be implemented so that get_char(f, p, c) expands to while ((c = *p++) == '\0') if ((p = get_char_check(f, p)) == 0) {c = EOF; break;} which could compile to something like this on a V9 SPARC: ldub [p], c ! these three instructions are the "fast path" L1: brnz,pt c, L2 ! inc p ! mov f, %o0 ! these instructions are the "slow path" call get_char_check mov p, %o1 ! p and c must be in registers, brnz,pt,a p, L1 ! but f need not be, because accessing f ldub [p], c ! is on the slow path. set -1, c L2: The cost is 8 instructions per block plus 3 instructions per character. If you are going to look at the characters at all, once you have read them, it's going to cost you 2 instructions per character minimum. (The EOF test can be folded into branching logic.) The typical C loop for scanning the characters in a string is while ((c = *p++) != '\0') ... which boils down to the same 3 instructions as the fast path of character reading. For other machines the code would be slightly different, but it would still resemble the C string scanning loop. So it's true that reading a character at a time using the C stdio library interface can be slow, but it is NOT true that reading a character at a time in C using something *resembling* the C stdio interface has to be slow. The most efficient solution is even probably to use mmap() to map the whole file in the memory space. Yes, BUT that only works for disc files. You can't read from a terminal that way; you can't read from a pipe that way; you can't read from a socket that way; you can't read from a message queue that way; ... I well (actually, painfully) remember the way that TOPS-10 required you to use different system calls (actually, different instructions) to read from a disc file, from a tape, and from a terminal. Given the importance of the internet these days, a minimum requirement on I/O is that it should be easy to write tolerably efficient code which works with data sources and sinks that might be local or might be remote. The box on my desk has a 500MHz UltraSPARC and a 700MHz Pentium of some kind. There are 2.4GHz Pentiums on sale in the local shops at prices so low I have trouble believing them. There really isn't any point in me worrying about a factor of 2 in CPU speed if the cost of a program is dominated by the cost of reading and writing the blocks (network speed and disc speed do NOT increase anywhere near as fast as CPU speed). This is what I meant when I complained about the old-fashioned character of the standard Prolog predicates of the get_byte family. For the sake of argument, let's suppose that there was a built-in predicate read_block(Stream, Block, Length) with the same argument order as POSIX.1's read(2). OK, what are the type and mode of Block? The mode can't be +, because Prolog can't _change_ a data structure. (If it could change a block, trailing the changes so they could be undone on backtracking would be hideously expensive.) So it has to be -. If read_block/3 returns a list of (nauseating ISO botch) single-character atoms, or if it returns a list of (historic and efficient) character codes, or if it returns a packed-array-of-codes string object (some Prologs have such things) or if it returns a single atom, then there is the cost of dynamically allocating this object. Presto chango: you have just squandered far more time on allocating the result than you have saved by reading many bytes at once. So the type has to be something else. If the stream is actually bound to a memory mapped file, there _is_ something else we can return, block(StartAddress, ActualLength) But (a) as noted above, this isn't going to work for sockets, and (b) it introduces a vulnerability: if the stream is closed then a surviving Block counts as a dangling reference, with all that that implies, and (c) if you are going to do anything with the block other than pass it on to a block output predicate, it's going to cost you more to access each character than it would have to read them individually in the first place. So it would make sense to me to introduce block-oriented predicates in Prolog. With a correct design, user-defined predicates could then be used to define any new type of "blockstream" with very reasonable overhead. Every time I've tried to design such a thing, I have run into really nasty problems. That doesn't mean that "a correct design" couldn't exist; I am a bear of very little brain and have to learn from everyone. So if there _is_ such a "correct design" I would be extremely interested to know what it might be. For example, I would find it very natural to have a pair of predicates get_string and put_string with read or write a string of bytes from/to a stream. Yes, but that requires get_string to CHANGE a term, which may be all very well for C and Lisp, but is just not the way Prolog does things. Making them dynamic and defining all other predicates (like get_byte, for compatibility) in term of them would allow user-defined streams with little overhead. It is easy to _say_ this. It's rather harder to actually produce a design where all streams can do 8-bit character and 8-bit byte reading at a cost of 8 instructions overhead per block + 3 instructions per character. If such a design can in fact be produced, I will be an enthusiastic supporter of it. However, my earlier mention of the Internet raises another issue. XML is defined in terms of Unicode, which requires 21 bits per character. (The range of Unicode values is 0 to 16'10FFFF.) People have scarcely imaginable volumes of data coded using 8 bit character sets or 16 bit character sets, and aren't terribly interested in quadrupling or doubling their disc requirements or their network traffic. So programs that can deal with XML data (or, for that matter, Windows NT file names) have to be able to convert from other encodings to Unicode on input and convert from Unicode to other encodings on output. C handles this by defining a set of functions like [f]getwc(), which typically convert one character at a time. Block I/O is considerably complicated by the fact that block boundaries need not coincide with character boundaries: a character may be represented by several bytes some of which are on one block and some of which are on the next. This makes a source-level block approach to character streams rather unattractive. It is still possible to provide fairly efficient character-at-a-time I/O in a C-like style, provided you don't do it the C way. In fact, you keep the same interface, except that p is a pointer to uint32_t instead of a pointer to uint8_t. The user-supplied low-level code delivers blocks of *bytes* to the middle-level "glue" code, which decodes the block (using any left-over information from the previous block) and fills a buffer of decoded characters, which the high level code then pulls out one by one. I have implemented this scheme for an XML parser in C. The details are sufficiently hairy that I really don't think it is practical to require Prolog programmers to do their own (en,de)coding, but at least it solves the [....CR][LF...] problem neatly. To wrap up, there is a logic programming language with Prolog-like syntax in which it *is* possible to do byte-block-at-a-time I/O without breaking the language's semantics, and that is Mercury. Anyone seriously worried about the cost of I/O would do well to consider Mercury. The compiler uses type and mode information to generate native code, C code, or .NET code that is about as efficient as typical compiled imperative languages, even though the language is still a pure logic programming language. ============================================================================== Message: Address: Action: help majordomo(a)clip.dia.fi.upm.es Info. on useful commands subscribe ciao-users-request(a)clip.dia.fi.upm.es Subscribe to this list unsubscribe ciao-users-request(a)clip.dia.fi.upm.es Unsubscribe from this list <whatever> ciao-users(a)clip.dia.fi.upm.es Send message to list ----------------------------------------------------------------------------- Archived messages: http://www.clip.dia.fi.upm.es/Mail/ciao-users/ -----------------------------------------------------------------------------

2 1

RE: Configure Win32 Emacs
by Makumbi, James 14 May '03

14 May '03

Hi, the manual says to add two lines to the .Emacs file which file must then be saved at the root of the C drive and guess what, that is what i did!! -----Original Message----- From: George Thomas [mailto:georgemthomas(a)netzero.net] Sent: 14 May 2003 01:14 To: Makumbi, James Cc: ciao-users(a)clip.dia.fi.upm.es Subject: RE: Configure Win32 Emacs Hi - I puzzled over this a bit too: Placing the .emacs file (the content for this is generated by the ciao install script in the top dir of your ciao distribution file, in 'ForEmacs' file) in the emacs home dir etc makes no difference. The magic happened for me when the .emacs file gets located root C dir: c:/.emacs (This fact is indeed noted in the ciao pdf manual but it takes a while for us to get to page 746 or so... :-) Cheers, George -----Original Message----- From: owner-ciao-users(a)clip.dia.fi.upm.es [mailto:owner-ciao-users(a)clip.dia.fi.upm.es]On Behalf Of Makumbi, James Sent: Tuesday, May 13, 2003 7:19 AM To: ciao-users(a)clip.dia.fi.upm.es Subject: Configure Win32 Emacs Hello Everyone, i am not new to Prolog but i am new to CIAO Prolog. i have been trying for ages to get it to run on my win32 Emacs with no luck so far. when i start Emacs from the .Emacs file, it just opens as normal Emacs. anyone using win32 Emacs? ============================================================================ == Message: Address: Action: help majordomo(a)clip.dia.fi.upm.es Info. on useful commands subscribe ciao-users-request(a)clip.dia.fi.upm.es Subscribe to this list unsubscribe ciao-users-request(a)clip.dia.fi.upm.es Unsubscribe from this list <whatever> ciao-users(a)clip.dia.fi.upm.es Send message to list ---------------------------------------------------------------------------- - Archived messages: http://www.clip.dia.fi.upm.es/Mail/ciao-users/ ---------------------------------------------------------------------------- - ============================================================================ == Message: Address: Action: help majordomo(a)clip.dia.fi.upm.es Info. on useful commands subscribe ciao-users-request(a)clip.dia.fi.upm.es Subscribe to this list unsubscribe ciao-users-request(a)clip.dia.fi.upm.es Unsubscribe from this list <whatever> ciao-users(a)clip.dia.fi.upm.es Send message to list ---------------------------------------------------------------------------- - Archived messages: http://www.clip.dia.fi.upm.es/Mail/ciao-users/ ---------------------------------------------------------------------------- - ============================================================================== Message: Address: Action: help majordomo(a)clip.dia.fi.upm.es Info. on useful commands subscribe ciao-users-request(a)clip.dia.fi.upm.es Subscribe to this list unsubscribe ciao-users-request(a)clip.dia.fi.upm.es Unsubscribe from this list <whatever> ciao-users(a)clip.dia.fi.upm.es Send message to list ----------------------------------------------------------------------------- Archived messages: http://www.clip.dia.fi.upm.es/Mail/ciao-users/ -----------------------------------------------------------------------------

1 0

Strange effect of Debugging
by Wamberto Vasconcelos 14 May '03

14 May '03

Dear CIAO Users I have been playing about with multithreading in CIAO Prolog and came across what I believe to be a strange side-effect of debugging on a simple piece of code. If I load the following piece of code :- use_module(library(dynamic)). :- use_module(library(concurrency)). :- concurrent p/1. :- concurrent q/1. try:- eng_call(test,create,create). test:- retract_fact(p(X)), asserta(q(X)). And type ?- try. I then am able to assert p(Something) and that gets re-written as q(Something): ?- asserta_fact(p(a)). yes ?- retract_fact_nb(q(A)). A = a ? However, if I try to debug the code, then it won't work! Check it out: ?- try. 1 1 Call: user:try ? 2 2 Call: concurrency:eng_call($:(user:test),create,create) ? 2 2 Exit: concurrency:eng_call($:(user:test),create,create) ? 1 1 Exit: user:try ? yes {trace} ?- asserta_fact(p(a)). yes {trace} ?- retract_fact_nb(q(A)). no What is going on here? Am I missing something? Thanks for any help! -- Wamberto Vasconcelos, PhD wvasconcelos(a)acm.org Department of Computing Science http://www.csd.abdn.ac.uk/~wvasconc University of Aberdeen, Aberdeen AB24 3UE, Scotland, UK Phone +44 (0)1224 272283 Fax +44 (0)1224 273422 ============================================================================== Message: Address: Action: help majordomo(a)clip.dia.fi.upm.es Info. on useful commands subscribe ciao-users-request(a)clip.dia.fi.upm.es Subscribe to this list unsubscribe ciao-users-request(a)clip.dia.fi.upm.es Unsubscribe from this list <whatever> ciao-users(a)clip.dia.fi.upm.es Send message to list ----------------------------------------------------------------------------- Archived messages: http://www.clip.dia.fi.upm.es/Mail/ciao-users/ -----------------------------------------------------------------------------

1 0

Optimization example - CLP(R)
by Ugoretzc＠Aol.com 14 May '03

14 May '03

I am new to PROLOG, but have a problem that I wish to solve. I am trying to design a layout manager for a domino game application. Below is a sampling of what I am trying to do. Can anyone provide me with a simple example of optimization using CLP(R) with the CIAO system or answer the example below? Take two angles A1 and A2 with a domain -45 to 45. Let X1 = 10*cos(A1)+5 Let Y1 = 3+10*sin(A1) Let X2 = 6*sin(A1)+5 Let Y2 = 3-5*cos(A1) Let X3 = 10*cos(A2)+5 Let Y3 = 3+10*sin(A2) Let X4 = 6*sin(A2)+5 Let Y4 = 3-5*cos(A1) Satisfy ((X3-X4)*(X1-X3)+(Y3-Y4)*(Y1-Y4))>0 AND ((X3-X4)*(X2-X3)+(Y3-Y4)*(Y2-Y4))>0 constraint (a constraint of dot products of vectors) Use an objective function minimize the sum of A1+A2.

1 0

Missing Header Files
by Jason Davis 14 May '03

14 May '03

Hi All, I cannot find two headers found in the foreign interface example, "//clip/clip/Systems/ciao-1.8/bin/Win32i86/datadefs.h" And "//clip/clip/Systems/ciao-1.8/bin/Win32i86/support.h" they should be located in the installation but I cannot see them anywhere, Can anyone help? Regards, Jason. ============================================================================== Message: Address: Action: help majordomo(a)clip.dia.fi.upm.es Info. on useful commands subscribe ciao-users-request(a)clip.dia.fi.upm.es Subscribe to this list unsubscribe ciao-users-request(a)clip.dia.fi.upm.es Unsubscribe from this list <whatever> ciao-users(a)clip.dia.fi.upm.es Send message to list ----------------------------------------------------------------------------- Archived messages: http://www.clip.dia.fi.upm.es/Mail/ciao-users/ -----------------------------------------------------------------------------

1 0

Configure Win32 Emacs
by Makumbi, James 14 May '03

14 May '03

Hello Everyone, i am not new to Prolog but i am new to CIAO Prolog. i have been trying for ages to get it to run on my win32 Emacs with no luck so far. when i start Emacs from the .Emacs file, it just opens as normal Emacs. anyone using win32 Emacs? Regards James Makumbi eBusiness Support Citibank Uganda Limited Tel: 256-41-340945/9 Fax: 256-41-340624 ============================================================================== Message: Address: Action: help majordomo(a)clip.dia.fi.upm.es Info. on useful commands subscribe ciao-users-request(a)clip.dia.fi.upm.es Subscribe to this list unsubscribe ciao-users-request(a)clip.dia.fi.upm.es Unsubscribe from this list <whatever> ciao-users(a)clip.dia.fi.upm.es Send message to list ----------------------------------------------------------------------------- Archived messages: http://www.clip.dia.fi.upm.es/Mail/ciao-users/ -----------------------------------------------------------------------------

2 1

ciao + apache.
by robinson vida 13 May '03

13 May '03

Hi ! I'm a new in Ciao system. I need use Ciao with Apache and I don't know how . Could you help me, please ? Robinson.

2 1

Re: "Printing" a term to a string
by Armin Rigo 13 May '03

13 May '03

Hello, On Tue, May 13, 2003 at 10:55:21AM +1200, Richard A. O'Keefe wrote: > Armin Rigo <arigo(a)tunes.org> wrote: > However, the stream concept of all Prolog implementations I know > seems very old-fashioned to me; doesn't any give the user a way > to define his own streams (i.e. objects that would be usable in > lieu of streams in the built-in predicates, but whose byte-level > read and write operations are user-defined predicates) ? That > would nicely solve this and other problems. > > Quintus Prolog has *serious* (but *SERIOUS*) support for just that. Thanks for the notice ! > One difference between this and what Armin Rigo suggests is that > the code you plugged in for your own stream types had to be written > in C. (...) > > You want to work in terms of a BLOCK at a time. Yes, exactly. Even on Unix in C nobody uses the character-oriented functions on the C API any more; using block-oriented functions is much more efficient. The most efficient solution is even probably to use mmap() to map the whole file in the memory space. This is what I meant when I complained about the old-fashioned character of the standard Prolog predicates of the get_byte family. So it would make sense to me to introduce block-oriented predicates in Prolog. With a correct design, user-defined predicates could then be used to define any new type of "blockstream" with very reasonable overhead. For example, I would find it very natural to have a pair of predicates get_string and put_string with read or write a string of bytes from/to a stream. Making them dynamic and defining all other predicates (like get_byte, for compatibility) in term of them would allow user-defined streams with little overhead. A bientôt, Armin. ============================================================================== Message: Address: Action: help majordomo(a)clip.dia.fi.upm.es Info. on useful commands subscribe ciao-users-request(a)clip.dia.fi.upm.es Subscribe to this list unsubscribe ciao-users-request(a)clip.dia.fi.upm.es Unsubscribe from this list <whatever> ciao-users(a)clip.dia.fi.upm.es Send message to list ----------------------------------------------------------------------------- Archived messages: http://www.clip.dia.fi.upm.es/Mail/ciao-users/ -----------------------------------------------------------------------------

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Ciao-users May 2003