Re: [Yap-users] BUGLISTS

[Vitor S. C. <vs...@gm...>]

Hi

Yes, I think the list deserves to know what is going on.

3 or 4 years ago we started an effort to better integrate SWi-Prolog and
Yap. This involved supporting SWI built-ins, the SWI foreign language
interface, and the SWI I/O subsystem in YAP.

Thanks to jan's dedication and collaboration, we managed to get YAP running
the major SWI packages, but then I started noticing a few problems:
- Bugs: we had 3 possible sources of bugs: YAP, the YAP-SWI glue code, and
the SWI code. Although there was a lot of progress, debugging was harder (I
am not so familiar with the SWI code). This does not mean SWI is buggy:
most often the problem was understanding how something worked in SWI.
-Compatibility: old code had problems with the newer YAP
- Relevance: most SWI apps run well in SWI, and do not benefit much from
YAP. I didn't see many people using the new packages. Moreover, the SWI
codebase is always evolving, so either I maintain an older version or I
will always be a bit less stable, just because Jan will have included a new
feature and I will need to include it too and verify it too.

NOtice that this is a good thing: the fact that SWI is getting better is
excellent news for the whole Prolog community, and I always was really
careful never to put pressure on Jan to do things that slow down progress
in SWI.

Most important, most work in YAP became maintenance work: not fun! I
started wondering what to do next, and eventually I decided I was going
back to basics. I had 3 choices:-
- maintain the current system
- backtrack to some point in the past
- hybrid model: clean up the system but try to include some of the ideas I
liked the most in SWI (and other systems).

I should have gone for 1 or 2, but 3 was enticing: YAP is a very old system
with lots of cruft. If I am going to cleanup, why not to clean up?

Well, one good reason is that Prolog has a lot of thingies, and YAP too :(
So the last few months I have been trying to improve those thingies. No
Nobel there. R

At that point, I wasn't sure how long I'd take or how would things look in
the end, so I kind of decided to just dive in. About one month ago I
thought I was almost there: but last again I got stuck with
 absolute_file_name, a swiss army knife built-in. In YAP, it was
implemented as a i xor C,  tower of Babel with very old code, and lots of
redndant code. Now it should be much easier to folllow, It might evene be
easy to follow :)

I am hoping this is the last stumbling block. Wait and see. Meanwhile, what
I am doing affects basic functionality, so I have been avoiding releases.
github will have something that mostly works.
The new version will fix the clause/2 bug mentioned before.

Hope this helps.

Vitor


On Wed, Feb 10, 2016 at 12:49 PM, Eyal Dechter <eya...@gm...>
wrote:

> I have been sending bugs to this mailing list. But my recent communication
> with victor suggests that he is engaging in a major rewrite of some sort,
> and is not paying attention to bugs in the current development branch. I
> may have misunderstood though.
>
> Sent from my iPhone
>
> On Feb 9, 2016, at 9:17 PM, Douglas Miles <log...@gm...> wrote:
>
> Where are bugs and feature requests worked on?
>
> Sourceforge seems neglected now
>
>
> Should they be filed on https://github.com/vscosta/yap-6.3/issues ?
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Yap-users mailing list
> Yap...@li...
> https://lists.sourceforge.net/lists/listinfo/yap-users
>
>