Prolog - win/unix portability (SWI)

Author

win/unix portability (SWI)

Mauro Di Nuzzo

2005-07-30, 5:01 pm

Hi. Here is two little examples of what I mean for "debug difficulties".

1) I have a simple atom parser (based only on atom_concat/3).
It works on SWI 5.4.7. After installation of SWI 5.5.19 it does not work
anymore.
Reinstallation of SWI 5.4.7 made my parser functional again.
atom_concat/3 failed to match sub atoms under SWI 5.5.19.

2) I am working on a relatively large CGI application. These lines are part
of it:

:- use_module(library(time)).
....
go :-
...
write('Content-Type: text/html\r\n\r\n'),
...
current_input(Stream),
write(pro),
alarm(30, throw(error(timeout_error(read, Stream),_)), _),
write(log),
....

I found the following (it was a kind of "adding one predicate, run
application, adding another predicate, run application... ... ...").

Under Windows (Apache or IIS) I am able to read 'prolog' on my web page
(i.e. alarm/3 works).
Under Unix (Apache) I read just 'pro'.
I made stand alone executable via qsave_program/2, and put all DLLs (when
under Windows) or SOs (when under Unix) in the same directory of my
executable.
The thing I am interested in is not really alarm/3, but...
How can I ever find this kind of errors?

Thanks,
M

Mauro Di Nuzzo

2005-07-30, 5:01 pm

In other words, I am having troubles:
1) with two different version of SWI prolog under the same OS (Windows).
2) with two different OS running the same version of SWI prolog.

I forgot to say that I have nothing against SWI prolog. It is superb, and
give me the opportunity to work with prolog seriously.
But there is something wrong (dont know if in my way of programming) when
things become just a little more complicated than coloring a four-color map
(for example).

M

"Mauro Di Nuzzo" <picorna@inwind.it> ha scritto nel messaggio
news:PcPGe.24531$a5.327946@twister2.libero.it...
> Hi. Here is two little examples of what I mean for "debug difficulties".
>
> 1) I have a simple atom parser (based only on atom_concat/3).
> It works on SWI 5.4.7. After installation of SWI 5.5.19 it does not work
> anymore.
> Reinstallation of SWI 5.4.7 made my parser functional again.
> atom_concat/3 failed to match sub atoms under SWI 5.5.19.
>
> 2) I am working on a relatively large CGI application. These lines are
part
> of it:
>
> :- use_module(library(time)).
> ...
> go :-
> ...
> write('Content-Type: text/html\r\n\r\n'),
> ...
> current_input(Stream),
> write(pro),
> alarm(30, throw(error(timeout_error(read, Stream),_)), _),
> write(log),
> ....
>
> I found the following (it was a kind of "adding one predicate, run
> application, adding another predicate, run application... ... ...").
>
> Under Windows (Apache or IIS) I am able to read 'prolog' on my web page
> (i.e. alarm/3 works).
> Under Unix (Apache) I read just 'pro'.
> I made stand alone executable via qsave_program/2, and put all DLLs (when
> under Windows) or SOs (when under Unix) in the same directory of my
> executable.
> The thing I am interested in is not really alarm/3, but...
> How can I ever find this kind of errors?
>
> Thanks,
> M
>
>
>

Mauro Di Nuzzo

2005-07-30, 5:01 pm

I ask and answer by myself :)
I think an explanation for the first part of my post is the following
(cut&paste from swi prolog web site):

About the 5.5.x release
Wide character support
Current development is adding support for wide characters (UTF-8, UCS,
UNICODE) to the Prolog kernel. This has no consequences for the of the
Prolog inferencing engine, but it does affect the atom-handling predicates,
I/O, character classification, etc. UNICODE is supported at different levels
by most of the packages, in particular the SGML/XML parser and XPCE allow
for parsing and representing documents with characters from multiple
languages.

Ok.

"Mauro Di Nuzzo" <picorna@inwind.it> ha scritto nel messaggio
news:ZmPGe.22889$B6.603525@twister1.libero.it...
> In other words, I am having troubles:
> 1) with two different version of SWI prolog under the same OS (Windows).
> 2) with two different OS running the same version of SWI prolog.
>
> I forgot to say that I have nothing against SWI prolog. It is superb, and
> give me the opportunity to work with prolog seriously.
> But there is something wrong (dont know if in my way of programming) when
> things become just a little more complicated than coloring a four-color
map
> (for example).
>
> M
>
> "Mauro Di Nuzzo" <picorna@inwind.it> ha scritto nel messaggio
> news:PcPGe.24531$a5.327946@twister2.libero.it...
> part
(when[color=darkred]
>
>

Jan Wielemaker

2005-07-31, 4:01 am

On 2005-07-30, Mauro Di Nuzzo <picorna@inwind.it> wrote:
> Hi. Here is two little examples of what I mean for "debug difficulties".

You appearently found one answer more or less. Some comments:

> 1) I have a simple atom parser (based only on atom_concat/3).
> It works on SWI 5.4.7. After installation of SWI 5.5.19 it does not work
> anymore.
> Reinstallation of SWI 5.4.7 made my parser functional again.
> atom_concat/3 failed to match sub atoms under SWI 5.5.19.

As you discovered, SWI-Prolog 5.5.x introduces Unicode and therefore a
lot of the atom handling and I/O has changed. Looks like this introduced
a bug. It was not found by the test-suite and trying some more examples,
I can't find it either. Please provide an example (preferably submit it
to the SWI-Prolog bugzilla, but by mail is fine too).

> 2) I am working on a relatively large CGI application. These lines are part
> of it:
>
>:- use_module(library(time)).
> ...
> go :-
> ...
> write('Content-Type: text/html\r\n\r\n'),
> ...
> current_input(Stream),
> write(pro),
> alarm(30, throw(error(timeout_error(read, Stream),_)), _),
> write(log),
> ....
>
> I found the following (it was a kind of "adding one predicate, run
> application, adding another predicate, run application... ... ...").
>
> Under Windows (Apache or IIS) I am able to read 'prolog' on my web page
> (i.e. alarm/3 works).
> Under Unix (Apache) I read just 'pro'.
> I made stand alone executable via qsave_program/2, and put all DLLs (when
> under Windows) or SOs (when under Unix) in the same directory of my
> executable.

Especially on Windows, not all operations are interruptable. I/O is
one of the problems. There is a timeout option on streams, but this
only deals in a portable way with streams related to TCP/IP sockets
because where select() works on any filedescriptor in POSIX systems,
it only works on sockets in Windows.

> The thing I am interested in is not really alarm/3, but...
> How can I ever find this kind of errors?

Good question. In theory all these versions should be the same of
course, but as you see there are two sources of trouble. One is
development introducing bugs and deliberate incompatibilities. Bugs
should be caught by the regression tests, but despite these getting more
eleborate over time it is of course not realistic to cach all of them
this way. The rest is supposed to be caught by users of the development
version, in practice with varying degrees of success. Deliberate
incompatibilities are listed in the ChangeLog and summaries in
release notes for major releases.

Incompatibilities exist between operating systems. In practice the
system currently runs on Windows and a wide variety of POSIX platforms
(Linux, many Unix variations including MacOS). There are other ports,
but many of these are either forgotten or poorly maintained. Problems
are related to filesystem behaviour, I/O, timing, (asynchronous) process
communication, etc. It is very hard to deal with these in a fully
portable manner. The system tries to do an as good as possible emulation
of POSIX behaviour on Windows and provides some win_* named primitives to
do things that are required by Windows users but have no meaning on
POSIX systems.

Cheers --- Jan

Sponsored Links