headers
Derek Jones | 1 Feb 21:50
Picon
Favicon

Slightly OT: Emacs mode for simple rule files

Hi all,

I like color syntax highlighting.

I use emacs in viper mode for code editing usually (call me a luser! I 
don't care :-D - been doing that for decades since I looOOove vi and 
err, don't love emacs so much, but I love emacs' flexibility and it's 
color syntax highlighting way better than vim and friends.)

Anyhow - I have a simple external expert system rule file - something 
like this:

----------------

goal result1

if
  answer1  and               % Something or the other
  answer2  and               % something else...
  answer3
then
  result1 cf 46

etc.

I have hacked emacs lisp files before but really don't like doing so. 
(Yes, I even have the O'Reilly books).

Wondered if anyone had a mode they had used for something like this. 
I've been looking at the generic and derived modes on the emacs wiki and
(Continue reading)

Permalink | Reply | 2 comments |
headers
Derek Jones | 1 Feb 21:51
Picon
Favicon

Re: Slightly OT: Emacs mode for simple rule files

Ooops

Forgot "rule"

e.g.

-----------------------

goal result1

rule 1
if
 answer1  and               % Something or the other
 answer2  and               % something else...
 answer3
then
 result1 cf 46
Permalink | Reply | 0 comments |
headers
Stassa Patsantzis | 4 Feb 23:54
Picon
Favicon

"ERROR: text_buffer <-matching_bracket: Argument 2 (bracket):"

Hi, list. 

I'm getting the following error when I enter a carriage return in PceEmacs: 

ERROR: text_buffer <-matching_bracket: Argument 2 (bracket): `[char]' expected, found `[integer,number,41,125,93]
ERROR: text_buffer <-matching_bracket: Argument 2 (bracket): `[char]' expected, found `[integer,number,41,125,93]
ERROR: text_buffer <-matching_bracket: Argument 2 (bracket): `[char]' expected, found `[integer,number,41,125,93]

(The error repeats three times for each cr). 

From what I can tell this happens when I compile the following code: 

    member -->
      [Value, Type],
      { type([Value, Type], []) }.

    member --> [Value, Type],
      { type([Value, Set], []),
      member([Set, Type], [])}.

    type --> [integer, number].
    type --> [1, integer].
    type --> [2, integer].
    type --> [a, alpha].
    type --> [b, alpha].

Note that [41,125,93] are the codes for ')}]'. Not sure how those end up inside my diff list. 

Other files don't have the same problem and if I start by loading a different file again no problem. There are
no problems with runnig, it's just the editor.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Fernando Guzmán | 6 Feb 02:15

Stand alone executable

I have compiled a stand-alone executable using swipl-ld in a linux machine running swipl 5.10.2.  The
stand-alone runs perfectly in the machine it was compiled. 

When I try to run this executable in another linux machine, identical to the first, except that it doesn't
have swipl installed, I get the error: 

% error while loading shared libraries: libswipl.so.5.10.2: cannot open shared object file: No such file
or directory 

(How) Can I create a stand-alone executable that includes and doesn't look for the swipl libraries? 

--
Fernando Guzman
fer <at> math.binghamton.edu

-------------- next part --------------
HTML attachment scrubbed and removed
Permalink | Reply | 2 comments |
headers
Jan Wielemaker | 6 Feb 13:20
Picon
Picon

Re: Stand alone executable

On 02/06/2012 02:15 AM, � wrote:
> I have compiled a stand-alone executable using swipl-ld in a linux
> machine running swipl 5.10.2.  The stand-alone runs perfectly in the
> machine it was compiled.
>
> When I try to run this executable in another linux machine, identical
> to the first, except that it doesn't have swipl installed, I get the
> error:
>
> % error while loading shared libraries: libswipl.so.5.10.2: cannot
> open shared object file: No such file or directory
>
> (How) Can I create a stand-alone executable that includes and doesn't
> look for the swipl libraries?

Completely stand-alone can be achieved by not compiling the SWI-Prolog
kernel as a shared object. This is default in 32-bit PC/Linux. Recent
versions transparently deal with additional shared objects, which are
added to the saved state. At run-time, they are copied to a tmp file
which is loaded and immediately removed. Unfortunately on most systems
it is not possible to link additional shared objects if the SWI-Prolog
kernel itself is not a shared object. That includes 64-bit (AMD64)
Linux.

So, if you use foreign libraries, you end up with at least two files:
the state and the kernel shared object. You can use chrpath to set the
search-path to the shared object relative to the executable (see also
man ld.so). Then you can distribute the executable as two files that can
be placed in the same dir.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Wielemaker | 6 Feb 13:27
Picon
Picon

Re: "ERROR: text_buffer <-matching_bracket: Argument 2 (bracket):"

On 02/04/2012 11:54 PM, Stassa Patsantzis wrote:
> Hi, list.
>
> I'm getting the following error when I enter a carriage return in PceEmacs:
>
> ERROR: text_buffer<-matching_bracket: Argument 2 (bracket): `[char]' expected, found `[integer,number,41,125,93]
> ERROR: text_buffer<-matching_bracket: Argument 2 (bracket): `[char]' expected, found `[integer,number,41,125,93]
> ERROR: text_buffer<-matching_bracket: Argument 2 (bracket): `[char]' expected, found `[integer,number,41,125,93]
>
> (The error repeats three times for each cr).
>
>
>  From what I can tell this happens when I compile the following code:
>
> ��� member -->
> ����� [Value, Type],
> ����� { type([Value, Type], []) }.
>
> ��� member -->  [Value, Type],
> ����� { type([Value, Set], []),
> ����� member([Set, Type], [])}.
>
> ��� type -->  [integer, number].
> ��� type -->  [1, integer].
> ��� type -->  [2, integer].
> ��� type -->  [a, alpha].
> ��� type -->  [b, alpha].
>
>
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stassa Patsantzis | 6 Feb 14:39
Picon
Favicon

Re: "ERROR: text_buffer <-matching_bracket: Argument 2 (bracket):"

Dear Jan, 

I see! The problem was only in the editor and my code had the expected behaviour, so I too thought that
redefining system predicates will not break anything. 

For the time being I'm OK loading a dummy file before loading my code (this eliminates the problem) so I think
I'll chicken out on your more involved solutions and wait for the next stable release. 

Thank you for replying so quickly, as you always do. I don't know how you manage it. 

Regards, 
Stassa

________________________________
 From: Jan Wielemaker <J.Wielemaker <at> vu.nl>
To: Stassa Patsantzis <idinatas <at> yahoo.com> 
Cc: "swi-prolog <at> lists.iai.uni-bonn.de" <swi-prolog <at> lists.iai.uni-bonn.de> 
Sent: Monday, 6 February 2012, 12:27
Subject: Re: [SWIPL] "ERROR: text_buffer <-matching_bracket: Argument 2 (bracket):"

On 02/04/2012 11:54 PM, Stassa Patsantzis wrote:
> Hi, list.
>
> I'm getting the following error when I enter a carriage return in PceEmacs:
>
> ERROR: text_buffer<-matching_bracket: Argument 2 (bracket): `[char]' expected, found `[integer,number,41,125,93]
> ERROR: text_buffer<-matching_bracket: Argument 2 (bracket): `[char]' expected, found `[integer,number,41,125,93]
> ERROR: text_buffer<-matching_bracket: Argument 2 (bracket): `[char]' expected, found `[integer,number,41,125,93]
>
> (The error repeats three times for each cr).
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jan Wielemaker | 6 Feb 15:14
Picon
Picon

Re: "ERROR: text_buffer <-matching_bracket: Argument 2 (bracket):"

On 02/06/2012 02:39 PM, Stassa Patsantzis wrote:
> Dear Jan,
>
> I see! The problem was only in the editor and my code had the expected
> behaviour, so I too thought that redefining system predicates will not
> break anything.
>
> For the time being I'm OK loading a dummy file before loading my code
> (this eliminates the problem) so I think I'll chicken out on your more
> involved solutions and wait for the next stable release.

That works `mostly' because when opening the dummy file, many of the
references will be resolved by the library.  Note however that 
SWI-Prolog resolves dependencies lazily, so you can still experience
problems.

	Cheers --- Jan

> Thank you for replying so quickly, as you always do. I don't know how
> you manage it.
>
> Regards,
> Stassa
>
> ------------------------------------------------------------------------
> *From:* Jan Wielemaker <J.Wielemaker <at> vu.nl>
> *To:* Stassa Patsantzis <idinatas <at> yahoo.com>
> *Cc:* "swi-prolog <at> lists.iai.uni-bonn.de" <swi-prolog <at> lists.iai.uni-bonn.de>
> *Sent:* Monday, 6 February 2012, 12:27
> *Subject:* Re: [SWIPL] "ERROR: text_buffer <-matching_bracket: Argument
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samer Abdallah | 7 Feb 15:26
Picon

Hang due to multithreaded access to Matlab interface foreign library

Hi,
thought I'd share this with the list even though I have now solved
the problem thanks to some pointers from Jan.

Basically, as was getting a total lock-up of the Prolog system in
an application that uses my Matlab interface library plml. (see
http://www.swi-prolog.org/contrib/ ) The effect was intermittent 
and not deterministically reproducible. The reason turned out to
be this: I was calling the Matlab engine API seemingly in single 
threaded fashion, but from a secondary thread in a mutithreaded
application; what I didn't notice was that the garbage collector
could be called simultaneously in another thread, and since I
am using BLOB atoms to manage some Matlab reasources, to be
released via garbage collection, this meant that occasionally, the
Matlab engine API was called from two threads at the same time.
This is no good as it caused the garbage collection thread to block
and thereby lock up the whole system.

Jan suggested a couple of options below. I went for the first option,
and it did the trick: I put a blocking mutex lock around all calls to the Matlab
engine API, except inside the release method of the BLOB atom class
that was causing the problem, which now has a non-blocking mutex lock.
If the mutex is locked when the garbage collector is run, the release method
returns FALSE to say that the atom cannot be reclaimed at this
time. The garbage collector simply leaves it and attempts to release it the 
next time it is run.

Anyway, I thought that might be a useful nugget of information to go
on the list. The latest version of the plml library is available here:
	https://code.soundsoftware.ac.uk/projects/plml
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Wielemaker | 8 Feb 11:48
Picon
Picon

Ann: SWI-Prolog 6.0.0

Hi,

I've uploaded SWI-Prolog 6.0.0, based on the current development GIT
(which is 5.11.37 with some bug-fixes). Bumping the major version to 6
is a rather arbitrary choice in a project that works with a frequent
release cycle. The changes since 5.0 certainly justify it. I think that
just-in-time multi-argument indexing is nice execuse for a major version
step.

This release should be compatible with 5.10.5 for almost all user
programs. Most of the incompatible changes are due to cleanup of
previously undocumented features that support the development
environment.  If you experience trouble, check warnings and check
the changes flagged "MODIFIED:" below.

Besides the usual cleanup and patches, a few developments stand out:

   - Introduction of just-in-time multi-argument indexing is now
     part of the stable release.

   - Can be compiled using MinGW.  This version is still rather
     experimental.  Thanks to Roberto Bagnara and Keri Harris.

   - Development APIs have been abstracted to support the PDT
     Eclipse based IDE.  Thanks to Guenter Kniesel and his team.

   - Memory management has been moved from the old custom allocator
     to system malloc.  The consequences may vary, but in general
     it seems that modern allocators deal better in fighting memory
     fragmentation, at the cost of slighly worse performance and a
(Continue reading)

Permalink | Reply | 6 comments |

Gmane