Re: [Yap-users] BUGLISTS

[Nicos A. <nic...@ya...>]

Hi Vitor, 

As far as Real (the interface to R) is concerned 
I am commited to have it working on both systems.

The latest sources for the pack from
http://stoics.org.uk/~nicos/sware/packs/real/
(real-1.5.tgz)
Are identical to the git repository. 
The changes for SWI 7 were made with back-compatibility in mind. 
To start with the interface worked for both SWI-6 and 7 so
on the whole I don't expect any major issues.
With some of the SWI 7 enhancements, the integration is 
really smooth and I can write complex unadulterated R in Prolog.
But that is an extra bonus. The interface is perfectly fine
on SWI-6. 

If you have made any Yap changes to Real, then I am happy to 
try and create a merged version, if that 's acceptable.

Once you have a Yap version I can try it on, 
let me know and I will see how Real 1.5 can be build for it.
(will be the perfect excuse to release version 2).  

Regards,

Nicos

On Sat, 13 Feb 2016 12:47:26 +0000
Vitor Santos Costa <vs...@gm...> wrote:

> Hi Douglas, Eyal and Nicos
> 
> Douglas, thanks for your enthusiasm, it's really appreciated. Eyal, sorry
> for the delay.
> 
> The version I committed has two main bugs before being release
> 
> - a logtalk bug (well, one major) which seems connected to absfile
> 
> - a real conundrum: there was once a single real r. But it was to be that
> Nicos worked on supporting swi7, so it does nit quite work with yap.
> 
> On my side, i played a bit with some syntactic changes ( yap always had a .
> Operator) and i wanted to study r, so i kept on messing with r internals.
> Unfortunately, r is strange and many operations require a specific
> environment, so the C code may sometimes do things different.
> 
> In practice, this means that for general users it may be better to use the
> prolog code. I'll fix that.
> 
> Regarding ports i once looked into it, but it had a bit of swi dependent
> code, even with plstream in yap. One solution separating the swid code, or
> builtins
> 
> I am mulling some ideas that may help, also because of the android port.
> 
> About swi compat. The Swi c-interface is still there, and supports the jpl,
> r and python interfaces, so it's not going away. I am not tracking new
> developments, but will accept patches :)
> 
> Builtins: i mostly just follow. One point where I might have to make a
> stand is the text conversion builtins ( if you say atom, use atom). We
> should use "text" when it is unclear what we refer to, so i'll try to add
> text routines for those cases where we refer to any text element.
> 
> Io: no way i'll go back to supporting the swi io (plstream) it's like
> copying a plane on the air while sitting on a wing. If anyone wants to
> pursue that, it is still in yap sources.
> 
> Strings:i have much improved support on strings, although in the end dcgs
> work better with code lists :( for me, that is. Dcgs are really really
> important for me. Utf-8 should be everywhere inside.
> 
> Dicts and named args: that's really cool, y has support for featrure
> bundles, which are kind of the same problem. .
> 
> Arrays: see packages/gecode for the clp(fd) examples
> 
> [] it makes a lot of sense if you also have a type system, but so far i
> don't
> 
> 
> Hope this helps
> 
> Vitor
> 
> 
> 
> 
> 
> 
> 
> 
> On Sat, 13 Feb 2016 at 05:47, Douglas Miles <log...@gm...> wrote:
> 
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]