Catchup to Vitor

[TeamSPoon]

No description provided.

[vscosta]

Hi Douglas

Just to say I'll be cooling off now, though I still have

• doc and xref (sysgraph)
  -win32 version
  -android version
• and many more

otherwise, I'd like to have the core stable :) There is a stupid leak I
have to fix though.

Excellent that you managed to compile yap and the cli interface. I can have
a look at the bug, but before that: is it still there? I fixed some thread
mem allocation stuff,

My feeling is that it is something not initialized (ok, that's usually the
problem). Can you call gdb yap, attach to the process and see some more
details?

Others:

Can you use plunit in YAP as it is?

My memory of porting :-

• Prolog code: main issue is autoloader, that makes it very confusing what
  is going on. The atom builtins are also too "generous". Otherwise, most
  often it is the easy part.
• FLI: should have much of the SWI functionality. some newer stuff and
  error handling may be missing. Core problem is that it is not as robust.
  Originally on top o of the Yap c-interface, that was an overhead and slowly
  I moved things to use the internal code.
• Streams, etc: I tried, my recommendation is just to have your own core
  I/o routines and translate both ways. The SWI I/O core is probably too
  complex fir

Packages: my main problem was the RDF store. I am also thinking that it may
be better to just use a standard xml/rdf parser, my experiments so far have
gone well.

clib: there is some nice stuff I want to recover, like UUID.

pldoc: I have bad memories, too many hooks and conf files). I am trying to
use doxygen (possibly some pipeline RDF to MkDocs would be cool).

Best

Vitor

On Mon, Feb 22, 2016 at 1:41 PM, Douglas R. Miles [email protected]
wrote:

Merged #8 #8.

—
Reply to this email directly or view it on GitHub
#8 (comment).

[TeamSPoon]

Oh the CLI bug at swi-to-yap/swicli#3 ?
Is still there.. though I figured it was my fault.

My feeling is that it is something not initialized (ok, that's usually the
problem). Can you call gdb yap, attach to the process and see some more
details?

Perhaps, I'll dig into it with GDB in the next hour ..

There is another issue on master..

That is easy. Yap by default tries to use file descriptors and fgetwc, based on the idea that the OS knows best. In Linux and osx memory streams should allow using fgerwc for buffers. In win it is not working.

It seems your memory streams do not like FILE *, as I don't understand why i am using the yap routines for generic reading, that should have fixed it.

Reading symbols from ./yap...done.
Starting program: /devel/GITHUB/build/yap

Program received signal SIGSEGV, Segmentation fault.
-----------------------------------------------------------------------------------------------------------------------[regs]
  RAX: 0xFFFFFFFFFFFFFFFF  RBX: 0x000000000067FAD0  RBP: 0x00007FFFFFFFC810  RSP: 0x00007FFFFFFFC7F0  o d I t S z a P c
  RDI: 0x000000000067FAD0  RSI: 0x0000000000000001  RDX: 0x000000000067FBD8  RCX: 0x0000000000619070  RIP: 0x00007FFFF751D6C8
  R8 : 0x00007FFFF7FC4740  R9 : 0x0000000000000000  R10: 0x00007FFFFFFFC5C0  R11: 0x00007FFFF751D660  R12: 0x0000000000400B80
  R13: 0x00007FFFFFFFE490  R14: 0x0000000000000000  R15: 0x0000000000000000
  CS: 0033  DS: 0000  ES: 0000  FS: 0000  GS: 0000  SS: 002B
-----------------------------------------------------------------------------------------------------------------------[code]
=> 0x7ffff751d6c8 <_IO_getwc+104>:      mov    rdx,QWORD PTR [rax]
   0x7ffff751d6cb <_IO_getwc+107>:      cmp    rdx,QWORD PTR [rax+0x8]
   0x7ffff751d6cf <_IO_getwc+111>:      jae    0x7ffff751d70f <_IO_getwc+175>
   0x7ffff751d6d1 <_IO_getwc+113>:      lea    rcx,[rdx+0x4]
   0x7ffff751d6d5 <_IO_getwc+117>:      mov    edx,DWORD PTR [rdx]
   0x7ffff751d6d7 <_IO_getwc+119>:      mov    QWORD PTR [rax],rcx
   0x7ffff751d6da <_IO_getwc+122>:      test   DWORD PTR [rbx],0x8000
   0x7ffff751d6e0 <_IO_getwc+128>:      jne    0x7ffff751d70b <_IO_getwc+171>
-----------------------------------------------------------------------------------------------------------------------------
0x00007ffff751d6c8 in _IO_getwc (fp=0x67fad0) at getwc.c:40
40      getwc.c: No such file or directory.
gdb$ bt
#0  0x00007ffff751d6c8 in _IO_getwc (fp=0x67fad0) at getwc.c:40
#1  0x00007ffff7b11e72 in get_wchar__ (sno=0x3) at /devel/GITHUB/yap-6.3/os/iopreds.c:697
#2  0x00007ffff7b11eac in get_wchar_from_file (sno=0x3) at /devel/GITHUB/yap-6.3/os/iopreds.c:700
#3  0x00007ffff7a81cf4 in Yap_tokenizer (inp_stream=0x619250, store_comments=0x0, tposp=0x7fffffffd090) at /devel/GITHUB/yap-6.3/C/scanner.c:1399
#4  0x00007ffff7b20330 in scan (re=0x7fffffffd0f0, fe=0x7fffffffd060, inp_stream=0x3) at /devel/GITHUB/yap-6.3/os/readterm.c:795
#5  0x00007ffff7b209f6 in Yap_read_term (inp_stream=0x3, opts=0x613441, nargs=0x3) at /devel/GITHUB/yap-6.3/os/readterm.c:933
#6  0x00007ffff7b2325a in Yap_StringToTerm (s=0x7ffff7b82712 "?-", len=0x3, encp=0x7ffff7dcf20c <Yap_local+300>, prio=0x4b0, bindings=0x0) at /devel/GITHUB/yap-6.3/os/readterm.c:1278
#7  0x00007ffff79d4c3f in setInitialValue (bootstrap=0x0, f=0x7ffff79cf2a1 <argv>, s=0x7ffff7b82712 "?-", tarr=0x61c8b8) at /devel/GITHUB/yap-6.3/C/flags.c:1258
#8  0x00007ffff79d6cce in Yap_InitFlags (bootstrap=0x0) at /devel/GITHUB/yap-6.3/C/flags.c:1537
#9  0x00007ffff7a27b88 in InitStdPreds () at /devel/GITHUB/yap-6.3/C/init.c:950
#10 0x00007ffff7a320fa in Yap_InitWorkspace (Heap=0x4000, Stack=0x2000, Trail=0x1000, Atts=0x10, max_table_size=0x0, n_workers=0x1, sch_loop=0xa, delay_load=0x3) at /devel/GITHUB/yap-6.3/C/init.c:1392
#11 0x00007ffff7aeb44d in YAP_Init (yap_init=0x7fffffffdc90) at /devel/GITHUB/yap-6.3/C/c_interface.c:2412
#12 0x0000000000400cf7 in init_standard_system (argc=0x1, argv=0x7fffffffe498, iap=0x7fffffffdc90) at /devel/GITHUB/yap-6.3/console/yap.c:99
#13 0x0000000000400de9 in main (argc=0x1, argv=0x7fffffffe498) at /devel/GITHUB/yap-6.3/console/yap.c:155
gdb$

See Full log @ http://pastebin.com/yE6TktqG

I work around it by reverting just one commit...

93eb717

Can you use plunit in YAP as it is?

I think, because plunit maybe hasn't grown since it was first ported.

• FLI: should have much of the SWI functionality. some newer stuff and
  error handling may be missing. Core problem is that it is not as robust.
  Originally on top o of the Yap c-interface, that was an overhead and slowly
  I moved things to use the internal code.

Help, what is the secret to getting libYap.so to _dllexport PL_chars_to_term() ?

You seem to be using win32? You need to add the X_API macro, either in the body or in the prototpe.

In Linux/mac shared objects export every global symbol, dlls are the other way round. Cmake has a discussion on that, basically recent cmakes can export everything in windows too.

I'm impressed if you're this on win32.

(Adding it to swi.defs wasn't enough .. though, I suppose it was in os.c.o)

Packages: my main problem was the RDF store. I am also thinking that it may
be better to just use a standard xml/rdf parser, my experiments so far have
gone well.

SWI's RDF literals are based on blobs which I see you started to implement BLOBs. Deep down rdf literals do not have anything over atoms (unless the those blobs were more than a char* ... but also a linked index over the triples ). From what I was thinking the reasoning behind RDF store itself was to not have repeated assertions. But I've often wondered if there was really any gain over a prolog asserta database. The triple store being implemented in C made sense in the context of SWI I due to memory management/performance reasons according to Jan.

However being in C, it didn't have the flexibility I needed. So once I spent no more than a 1/2 hour porting ClioPatria to not use those RDF Stores (instead I use merely the plain prolog database) and it worked very well. The rest of the RDF stuff (parsing) makes sense to be done in a standard xml/rdf parser.

cool.

clib: there is some nice stuff I want to recover, like UUID.

Indeed..

And there is one more thing.. a very recent is that prolog can implement interpreted prolog streams (I think (hope) this is different than the plstreams you mentioned earlier) I had added them via SWICLI a few years ago so. But one project I had 7 months ago it seemed heavy to use SWICLI streams just for a this little piece. So I sent an email to Jan.. low and behold he just created them days before to clib days before I sent the email :)

https://groups.google.com/d/msg/swi-prolog/0e-iNq_ojO4/SMxrXFP4BQAJ

Here is a use of it: https://github.com/TeamSPoon/PrologMUD/blob/master/pack/logicmoo_base/prolog/logicmoo/util/logicmoo_util_prolog_streams.pl

i was thinking of allowing a stream to have its own parser and writer, This seems the same but more complicated? Is it the same idea.

pldoc: I have bad memories, too many hooks and conf files). I am trying to
use doxygen (possibly some pipeline RDF to MkDocs would be cool).

pldoc is sort of a monster that way .. I actually have my own version of a pldocing system that is a runtime web server that htmlizes the listing of the prolog predicates and shows their comments. This includes dynamic predicates. .. It also includes the variable names..
(it does all this using format/3) Also includes buttons to edit the predicates

Nice, but doxygen has some advantages too, especiallywith sysgraph working.

PlDoc did seem like a lot of hooks but really all we need is one pass thru source creating '$pldoc'/4 assertions of the comments. Part of why pldoc feels so complex (besides the fact that it is) was it is trying to include the Latex docs as well. And provide user code hooks etc..

Yes, also for me this new web stuff is impressive but a lot of stuff ;)
Maj

I am trying to use doxygen (possibly some pipeline RDF to MkDocs would be cool).

I do see a great hybrid possible

The real shizzy is for us is the get SWISH working. Though as luck has it, is pretty much doable without any C other than the clib work I mention above however any version of SWISH from 8 months ago or before doesn't need that

What do you need from clib? Sockets?

Yap has a c++ interface that could be used straight with node.js or via the swig gateway too. It is mostly similar to the swi interface.

Best

Vitor

[TeamSPoon]

all we need is one pass thru source creating '$pldoc'/4

I take that back.. we have .. https://github.com/vscosta/doxygen-yap

[vscosta]

Yes, doxygen-yap, it has some difficulties with operators and not quite
perfect, but it is jumping between Prolog and C already. From doxygen there
are bridges everywhere.

To be honest, it may be easy to integrate with PlDoc too, and there is a
SWI filter for doxygen, that may be a good option too,

I am now trying to bring back from the dead my small sysgraph
cross-referencer, so that it can do a global analysis of the docs (sysgraph
has a simple understanding of C files), and fix broken links. sysgraph was
written to actually parse the info doc, split it and feed it to the
sources. It can work the other way: ultimately, it would be nice to get the
doxygen xml and produce a simpler MD documentation.

Sometimes, we in the LP community get ourselves in our little world (SWI is
n exception), I feel a bit sad when I see all these new editors coming out
without decent Prolog support.

Best

Vitor

On Mon, Feb 22, 2016 at 9:37 PM, Douglas R. Miles [email protected]
wrote:

all we need is one pass thru source creating '$pldoc'/4

I take that back.. we have .. https://github.com/vscosta/doxygen-yap

—
Reply to this email directly or view it on GitHub
#8 (comment).