Menu
▾
▴
yap-users — General Information on Yap
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(8) |
Feb
(3) |
Mar
(9) |
Apr
(6) |
May
(13) |
Jun
(33) |
Jul
(11) |
Aug
(17) |
Sep
(31) |
Oct
(64) |
Nov
(19) |
Dec
(28) |
| 2003 |
Jan
(5) |
Feb
(4) |
Mar
(11) |
Apr
(11) |
May
(4) |
Jun
(15) |
Jul
(4) |
Aug
(16) |
Sep
(14) |
Oct
(1) |
Nov
(3) |
Dec
(1) |
| 2004 |
Jan
(8) |
Feb
(24) |
Mar
(16) |
Apr
(23) |
May
(11) |
Jun
(16) |
Jul
(15) |
Aug
(1) |
Sep
(9) |
Oct
(2) |
Nov
(20) |
Dec
(37) |
| 2005 |
Jan
(10) |
Feb
(1) |
Mar
|
Apr
(9) |
May
(8) |
Jun
(1) |
Jul
(6) |
Aug
(14) |
Sep
(3) |
Oct
(35) |
Nov
(10) |
Dec
(3) |
| 2006 |
Jan
(10) |
Feb
(11) |
Mar
(8) |
Apr
(6) |
May
(2) |
Jun
(2) |
Jul
(5) |
Aug
(6) |
Sep
(6) |
Oct
(10) |
Nov
(6) |
Dec
(2) |
| 2007 |
Jan
(26) |
Feb
(17) |
Mar
|
Apr
(6) |
May
(3) |
Jun
(4) |
Jul
(5) |
Aug
|
Sep
(8) |
Oct
(3) |
Nov
(16) |
Dec
(20) |
| 2008 |
Jan
(32) |
Feb
(4) |
Mar
(14) |
Apr
(7) |
May
(13) |
Jun
(13) |
Jul
(21) |
Aug
(8) |
Sep
(6) |
Oct
(7) |
Nov
(4) |
Dec
(7) |
| 2009 |
Jan
(49) |
Feb
(11) |
Mar
(12) |
Apr
(20) |
May
(7) |
Jun
(11) |
Jul
(12) |
Aug
(3) |
Sep
(5) |
Oct
(12) |
Nov
(36) |
Dec
(14) |
| 2010 |
Jan
(35) |
Feb
(27) |
Mar
(84) |
Apr
(32) |
May
(42) |
Jun
(25) |
Jul
(50) |
Aug
(30) |
Sep
(8) |
Oct
(30) |
Nov
(69) |
Dec
(140) |
| 2011 |
Jan
(16) |
Feb
(26) |
Mar
(33) |
Apr
(23) |
May
(6) |
Jun
(20) |
Jul
(45) |
Aug
(14) |
Sep
(4) |
Oct
(8) |
Nov
(5) |
Dec
(9) |
| 2012 |
Jan
(2) |
Feb
(5) |
Mar
(14) |
Apr
(11) |
May
(7) |
Jun
(37) |
Jul
(11) |
Aug
(9) |
Sep
(7) |
Oct
(6) |
Nov
(4) |
Dec
(6) |
| 2013 |
Jan
(52) |
Feb
(28) |
Mar
(21) |
Apr
(17) |
May
(7) |
Jun
(12) |
Jul
(5) |
Aug
(10) |
Sep
(29) |
Oct
(3) |
Nov
(30) |
Dec
(1) |
| 2014 |
Jan
(6) |
Feb
(3) |
Mar
(9) |
Apr
(6) |
May
(8) |
Jun
(11) |
Jul
(2) |
Aug
(1) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
(5) |
| 2015 |
Jan
(3) |
Feb
(9) |
Mar
(6) |
Apr
(4) |
May
(5) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(3) |
Dec
(3) |
| 2016 |
Jan
|
Feb
(40) |
Mar
(6) |
Apr
|
May
(2) |
Jun
(2) |
Jul
(5) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2020 |
Jan
(1) |
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
(1) |
| 2022 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2024 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(1) |
May
(5) |
Jun
(4) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2025 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Edward S. <esc...@ce...> - 2016-02-16 19:05:42
|
Hi Eyal, Thank you -- this seems to explain the behavior I'm seeing. Do you have any suggested alternative? A version of dif/2 that doesn't use co-routining maybe? Does such a thing exist? Thanks, Ed On 02/16/2016 01:29 PM, Eyal Dechter wrote: > Hi Ed, > > I think that this is because dif/2 is part of the co-routining extension > and the tabling extension (YAPTab) doesn't support the co-routining > extension. According to the manual (section 18) this should through an > error; that it doesn't is likely a bug. > > I think the reason it is not supported is because tabling in YAP depends > on being able to ask when one term is a variant of another. But in the > presence of constraints like dif/2, two terms that are syntactic > variants are no longer necessarily unifiable. > > Best, > Eyal |
|
From: Eyal D. <eya...@gm...> - 2016-02-16 18:29:39
|
Hi Ed, I think that this is because dif/2 is part of the co-routining extension and the tabling extension (YAPTab) doesn't support the co-routining extension. According to the manual (section 18) this should through an error; that it doesn't is likely a bug. I think the reason it is not supported is because tabling in YAP depends on being able to ask when one term is a variant of another. But in the presence of constraints like dif/2, two terms that are syntactic variants are no longer necessarily unifiable. Best, Eyal On Tue, Feb 16, 2016 at 11:29 AM, Edward Schwartz <esc...@ce...> wrote: > Hi all, > > I am experiencing some strange behavior when I combine tabling and dif/2. > > Here's a very simple prolog program for computing transitivity: > > % 1, 2 and 3 are on the same class. > same(1, 2). > same(1, 3). > % 4, 5, and 6 are the same class. > same(4, 5). > same(4, 6). > :- table ruleSame/2. > % Root from real facts. > ruleSame(X, Y) :- > same(X, Y). > % Commutative. > ruleSame(X, Y) :- > dif(X, Y), > ruleSame(Y, X). > % Transitive. > ruleSame(X, Y) :- > dif(X, Y), > dif(Y, Z), > dif(X, Z), > ruleSame(X, Z), > ruleSame(Z, Y). > > Basic facts are ok: > > ?- ruleSame(1,2). > yes > ?- ruleSame(1,3). > yes > ?- ruleSame(2,3). > yes > > But then some unexpected facts are generated... > > ?- ruleSame(2,4). > yes > > If I debug the evaluation of these facts, I get an extremely long trace. > > If I move the dif sub-goals after the ruleSame sub-goals, the program > works as expected. > > Is this a bug? I think it is, but hopefully I haven't overlooked > something. It seems like maybe the deferred goals from dif/2 are > interacting with tabling in a non-trivial way. > > I tested this both on YAP 6.2.2 and the current development git branch > of 6.3. Both had the same behavior. > > Thanks for any help, > > Ed > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Edward S. <esc...@ce...> - 2016-02-16 16:43:15
|
Hi all,
I am experiencing some strange behavior when I combine tabling and dif/2.
Here's a very simple prolog program for computing transitivity:
% 1, 2 and 3 are on the same class.
same(1, 2).
same(1, 3).
% 4, 5, and 6 are the same class.
same(4, 5).
same(4, 6).
:- table ruleSame/2.
% Root from real facts.
ruleSame(X, Y) :-
same(X, Y).
% Commutative.
ruleSame(X, Y) :-
dif(X, Y),
ruleSame(Y, X).
% Transitive.
ruleSame(X, Y) :-
dif(X, Y),
dif(Y, Z),
dif(X, Z),
ruleSame(X, Z),
ruleSame(Z, Y).
Basic facts are ok:
?- ruleSame(1,2).
yes
?- ruleSame(1,3).
yes
?- ruleSame(2,3).
yes
But then some unexpected facts are generated...
?- ruleSame(2,4).
yes
If I debug the evaluation of these facts, I get an extremely long trace.
If I move the dif sub-goals after the ruleSame sub-goals, the program
works as expected.
Is this a bug? I think it is, but hopefully I haven't overlooked
something. It seems like maybe the deferred goals from dif/2 are
interacting with tabling in a non-trivial way.
I tested this both on YAP 6.2.2 and the current development git branch
of 6.3. Both had the same behavior.
Thanks for any help,
Ed
|
|
From: Eyal D. <eya...@gm...> - 2016-02-14 18:59:45
|
Hi Vitor, was this issue supposed to be fixed in 6961626a3d7d45a472aa91f9800be75261e8709a? It seemed like the commit message was related... In any case, I'm still having the same installation issue with HEAD. Thanks, Eyal On Wed, Feb 10, 2016 at 11:07 AM, Vitor Santos Costa <vs...@gm...> wrote: > Hi > > Let's try github for filing. > > The latter one is fixed upstream, I'll try sending a partial patch. > > I suppose that now that I got rid of modules, I should start playing more > with branches :) > > Thanks > > Vitor > > > On Wed, Feb 10, 2016 at 3:37 PM, Eyal Dechter <eya...@gm...> > wrote: > >> Hi Victor, >> >> Thank you for the update. But just to follow up on Douglas' question, >> where should bugs be filed? Through the github repository issues? >> >> Also, I get the following make error when trying to build from current >> master, which refers to something added in the latest commit I believe: >> >> make: *** No rule to make target `H/dglobals.h', needed by `yap'. Stop. >> >> Best, >> Eyal >> >> >> >> >> On Wed, Feb 10, 2016 at 10:27 AM, Vitor Santos Costa <vs...@gm...> >> wrote: >> >>> 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 >>>> >>>> >>> >> > |
|
From: Nicos A. <nic...@ya...> - 2016-02-13 15:01:40
|
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: > > [...] > [...] > [...] > [...] > [...] > [...] > [...] |
|
From: Vitor S. C. <vs...@gm...> - 2016-02-13 12:47:43
|
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: > On Thu, Feb 11, 2016 at 3:38 PM, Nicos Angelopoulos < > nic...@ya...> wrote: > >> >> >> In my opinion I think the community is a little too obsessed with >> performance. Which of course is welcome, >> but on the whole, Prolog is much more than an efficient tool > > > I am obsessed with performance, which is why the SWI as an outer skin and > with YAP being the heart of the kernel is the best setup for my use cases. > Though I suppose this software would be called YAP and not SWI. This > would be a YAP that runs SWISH/Cliopatria uses pack installation and has a > much faster kernel under the hood since I need raw speed for the software I > write. > > > >> >> In any case, I hope the two systems will coordinate because Prolog will >> be all the better for it, >> > > > I am excited to see YAP get caught back up to SWI and leave out the > regressions that came with SWI 7. > > > |
|
From: Jacques G. <gre...@gm...> - 2016-02-13 09:38:01
|
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 13/02/2016 06:47, Douglas Miles a
écrit :<br>
</div>
<blockquote
cite="mid:CAE...@ma..."
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Feb 11, 2016 at 3:38 PM,
Nicos Angelopoulos <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:nic...@ya..."
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:nic...@ya...">nic...@ya...</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
In my opinion I think the community is a little too
obsessed with performance. Which of course is welcome,<br>
but on the whole, Prolog is much more than an efficient
tool</blockquote>
<div><br>
</div>
<div>I am obsessed with performance, which is why the SWI
as an outer skin and with YAP being the heart of the
kernel is the best setup for my use cases. Though I
suppose this software would be called YAP and not SWI.
This would be a YAP that runs SWISH/Cliopatria uses pack
installation and has a much faster kernel under the hood
since I need raw speed for the software I write.</div>
</div>
</div>
</div>
</blockquote>
<br>
So am I. In my case, an inference engine dealing with proofs in
Euclidian Geometry, Yap has proved to be so much faster. <br>
<br>
Same code in both versions (Yap / Swi), the average overspeed in
favour of Yap is 300% or 400%, and when dealing with constructions
with more than 12 points it is around 10000% !<br>
<br>
I have kept both versions of Prolog. Swi remains the main language.
I use the C interface, sockets and threads to integrate Swi into
Freepascal/Lazarus. But now the main inference engine is launched by
Swi calling Yap.exe loading a Yap state and the database that
describes the geometric figure in a fraction of a second. Then this
Yap process makes all the necessary inferences to prove a maximum of
geometric propositions before sending back a stream through sockets
to Swi. As far as this program is concerned, speed is absolutely
essential.<br>
<br>
These news about Yap are indeed very very good news.<br>
<br>
Best regards<br>
<br>
Jacques Gressier<br>
<a class="moz-txt-link-freetext" href="http://geometrix.free.fr/site/logiciels.php">http://geometrix.free.fr/site/logiciels.php</a><br>
<br>
<blockquote
cite="mid:CAE...@ma..."
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
In any case, I hope the two systems will coordinate
because Prolog will be all the better for it,<br>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>I am excited to see YAP get caught back up to SWI and
leave out the regressions that came with SWI 7. </div>
<div><br>
</div>
<div> </div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
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!
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140">http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Yap-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Yap...@li...">Yap...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/yap-users">https://lists.sourceforge.net/lists/listinfo/yap-users</a>
</pre>
</blockquote>
<br>
<br />
<table style="border-top: 1px solid #aaabb6;">
<tr>
<td style="width: 470px; padding-top: 20px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Cet e-mail a été envoyé depuis un ordinateur protégé par Avast. <br /><a href="https://www.avast.com/sig-email" target="_blank" style="color: #4453ea;">www.avast.com</a> </td>
</tr>
</table>
</body>
</html>
|
|
From: Douglas M. <log...@gm...> - 2016-02-13 05:47:10
|
On Thu, Feb 11, 2016 at 3:38 PM, Nicos Angelopoulos < nic...@ya...> wrote: > > > In my opinion I think the community is a little too obsessed with > performance. Which of course is welcome, > but on the whole, Prolog is much more than an efficient tool I am obsessed with performance, which is why the SWI as an outer skin and with YAP being the heart of the kernel is the best setup for my use cases. Though I suppose this software would be called YAP and not SWI. This would be a YAP that runs SWISH/Cliopatria uses pack installation and has a much faster kernel under the hood since I need raw speed for the software I write. > > In any case, I hope the two systems will coordinate because Prolog will be > all the better for it, > I am excited to see YAP get caught back up to SWI and leave out the regressions that came with SWI 7. |
|
From: Douglas M. <log...@gm...> - 2016-02-13 05:25:51
|
On Fri, Feb 12, 2016 at 12:51 AM, Douglas Miles <log...@gm...> wrote: > >> I suppose that now that I got rid of modules, I should start playing more >> with branches :) >> >> > Where are you working out of? Is it github or.. ? > > I hope you make a branch on github of your current work > > > Nevermind, I found your (Vitor's work) .. What is the opinion about the SWI-7 changes ? It seems to be mostly good with additional things like strings. Lists using '|'/2 as a functor I see the point being to make such a great incompatibility that we can detect and comb out occurrences user code that expect this '.'/2 in order for it to update to '|'/2 in which after several cycles any list code that didn't need the conversion will be ready for the next round of the next first class datatype. |
|
From: Douglas M. <log...@gm...> - 2016-02-12 08:51:32
|
> > > I suppose that now that I got rid of modules, I should start playing more > with branches :) > > Where are you working out of? Is it github or.. ? I hope you make a branch on github of your current work |
|
From: Nicos A. <nic...@ya...> - 2016-02-11 23:38:49
|
Dear Vitor, all, It is great to hear there might be a new release soon. From the perspective of a user of both Yap & Swi, the time when the two systems touched true compatibility was one of the most exciting times in using Prolog. Although in terms of pluralism having 2 systems is great, it might be uneconomical to do so in isolation or without some coordination. We are all getting on (growing older), if anyone needs reminding. Any time spent in coordinating Swi & Yap is a time well spend as far as Prolog users are concerned. I appreciate that the developers themselves might have different outlook. Technically, the ideal solution would be a kernel approach where Yap and SWI kernels can be used inter-changeably with most of the system being built on top talking to the kernel API. I think there is too much uncertainty around the feasibility and amount of resources required for this to succeed. In the past, I suggested that maybe the way to go is for Jan with your help to transplant Yap's heart into Swi leading to a single system. In my opinion I think the community is a little too obsessed with performance. Which of course is welcome, but on the whole, Prolog is much more than an efficient tool. This opinion might not be independent of the kind of things I use Prolog for now days. In any case, I hope the two systems will coordinate because Prolog will be all the better for it, and maybe in this way you can share some of the boring stuff hopefully leaving more time for the interesting stuff (i know there is a non insignificant amount of time taken for communication). Btw, has Yap already dealt with SWI-7 changes in your private branch ? All the best, Nicos --- Nicos Angelopoulos http://stoics.org.uk/~nicos On Wed, 10 Feb 2016 15:27:56 +0000 Vitor Santos Costa <vs...@gm...> wrote: > 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: > > [...] |
|
From: Douglas M. <log...@gm...> - 2016-02-10 18:22:56
|
I was setting up my February 2016 todo list for SWI-Prolog .... https://github.com/logicmoo/swipl-devel-unstable/issues/ With my Higherlevel goals here https://github.com/logicmoo/swipl-devel-unstable And here was the rub: After I am done I will still be not be as performant as I want AND I will have merely duplicated work done in YAP already. So I am thinking Getting YAP caught up to doing the things SWI-Prolog does will take less time than catching up SWI-Prolog.. Though I started adding tabling to SWI it will be multitudes slower than normal code which by another factor is still slower yet comparatively to YAP Whereas it should not take and longer than 6 months to get YAP caught up and have all of SWI-Prolog feature and packages working.. It might take a couple years to get SWI-Prolog up to the speed of YAP.. (Both these figures are wrong except for the proportions) If Jan is more interested in doing new and exciting things and the tooth to tail time for fixing up the swi-kernel is just too expensive.. He probably needs to stay in boring bug fixing mode with SWI and develop the applications he wants Example: would having JIT-LLVM in SWI-Prolog make SWISH any better? No. Also, If some other developer started hacking on SWI's kernel anding these things JIT-LLVM /Tabling etc .. Is that going to make it easier for Jan to do more interesting things? No, he'll be helping and sorting out the development and goals. (A distraction) https://github.com/logicmoo/yap-6.3/issues > So I am going to spend Feb/March 2016 experimenting with the opposite > approach: > > 5 Open > <https://github.com/logicmoo/yap-6.3/issues?q=is%3Aopen+is%3Aissue> 0 > Closed > <https://github.com/logicmoo/yap-6.3/issues?q=is%3Aissue+is%3Aclosed> > Author > Labels > Milestones > Assignee > Sort > > - <https://github.com/logicmoo/yap-6.3/issues?q=is%3Aissue+is%3Aopen> > XSB verify_attributes/2 attv_unify/2 INFRA to be called between > verify_attributes/3 and attr_unify_hook/2 > <https://github.com/logicmoo/yap-6.3/issues/5> > #5 opened 6 minutes ago by logicmoo > <https://github.com/logicmoo/yap-6.3/issues?q=is%3Aissue+is%3Aopen+author%3Alogicmoo> > > 0 <https://github.com/logicmoo/yap-6.3/issues/5> > - <https://github.com/logicmoo/yap-6.3/issues?q=is%3Aissue+is%3Aopen> > PORT library(pack) works in YAP (do any porting) With the end goal to > even use SWI's hosting site to exchange packs > <https://github.com/logicmoo/yap-6.3/issues/4>enhancement > <https://github.com/logicmoo/yap-6.3/issues?q=is%3Aissue+is%3Aopen+label%3Aenhancement> > #4 opened 16 minutes ago by logicmoo > <https://github.com/logicmoo/yap-6.3/issues?q=is%3Aissue+is%3Aopen+author%3Alogicmoo> > > 0 <https://github.com/logicmoo/yap-6.3/issues/4> > - <https://github.com/logicmoo/yap-6.3/issues?q=is%3Aissue+is%3Aopen> > Ensure library(pengines) works in YAP (do any porting) > <https://github.com/logicmoo/yap-6.3/issues/3> > #3 opened 19 minutes ago by logicmoo > <https://github.com/logicmoo/yap-6.3/issues?q=is%3Aissue+is%3Aopen+author%3Alogicmoo> > > 0 <https://github.com/logicmoo/yap-6.3/issues/3> > - <https://github.com/logicmoo/yap-6.3/issues?q=is%3Aissue+is%3Aopen> > Ensure new library(prolog_streams) or equivalent is in YAP > <https://github.com/logicmoo/yap-6.3/issues/2> > #2 opened 20 minutes ago by logicmoo > <https://github.com/logicmoo/yap-6.3/issues?q=is%3Aissue+is%3Aopen+author%3Alogicmoo> > > 0 <https://github.com/logicmoo/yap-6.3/issues/2> > - <https://github.com/logicmoo/yap-6.3/issues?q=is%3Aissue+is%3Aopen> > Port SWICLI ( my .NET/MONO clone of JPL ) from SWI-Prolog to YAP This > will be a good introduction to YAP FFI > <https://github.com/logicmoo/yap-6.3/issues/1> > #1 opened 21 minutes ago by logicmoo > <https://github.com/logicmoo/yap-6.3/issues?q=is%3Aissue+is%3Aopen+author%3Alogicmoo> > http://www.swi-prolog.org/pack/file_details/swicli/doc/api.html > > > > This includes ClioPatria/SWISH etc > |
|
From: Vitor S. C. <vs...@gm...> - 2016-02-10 16:07:38
|
Hi Let's try github for filing. The latter one is fixed upstream, I'll try sending a partial patch. I suppose that now that I got rid of modules, I should start playing more with branches :) Thanks Vitor On Wed, Feb 10, 2016 at 3:37 PM, Eyal Dechter <eya...@gm...> wrote: > Hi Victor, > > Thank you for the update. But just to follow up on Douglas' question, > where should bugs be filed? Through the github repository issues? > > Also, I get the following make error when trying to build from current > master, which refers to something added in the latest commit I believe: > > make: *** No rule to make target `H/dglobals.h', needed by `yap'. Stop. > > Best, > Eyal > > > > > On Wed, Feb 10, 2016 at 10:27 AM, Vitor Santos Costa <vs...@gm...> > wrote: > >> 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 >>> >>> >> > |
|
From: Eyal D. <eya...@gm...> - 2016-02-10 15:37:46
|
Hi Victor, Thank you for the update. But just to follow up on Douglas' question, where should bugs be filed? Through the github repository issues? Also, I get the following make error when trying to build from current master, which refers to something added in the latest commit I believe: make: *** No rule to make target `H/dglobals.h', needed by `yap'. Stop. Best, Eyal On Wed, Feb 10, 2016 at 10:27 AM, Vitor Santos Costa <vs...@gm...> wrote: > 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 >> >> > |
|
From: Vitor S. C. <vs...@gm...> - 2016-02-10 15:28:04
|
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 > > |
|
From: Eyal D. <eya...@gm...> - 2016-02-10 12:50:01
|
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 ? |
|
From: Douglas M. <log...@gm...> - 2016-02-10 05:24:03
|
% YAP 6.3.4-c8305988 (compiled 2016-02-09T20:55:16@gitlab)
?- listing(file_search_path).
:- dynamic file_search_path/2.
:- multifile file_search_path/2.
file_search_path(foreign,yap('lib/Yap')).
true.
?- file_search_path(X,Y).
X = library,
Y = '/devel/LogicmooDeveloperFramework/yap-6.3' ? ;
X = library,
Y = '/usr/local/share/Yap' ? ;
user_input:3:0 error in prolog:'$handle_error'/3:
user_input:3:0 found while compiling this file.
!!! procedure system_commons/1 could not be found,
goal was
prolog:context(prolog:system_commons(_131114),prolog:'$command'/4)
exception raised from prolog:'$handle_error':3, user_input:0:0.
Why doesnt listing show more?
Is something wrong that prolog:system_commons/1 is missing?
|
|
From: Douglas M. <log...@gm...> - 2016-02-10 02:17:10
|
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 ? |
|
From: Fabrizio R. <fab...@un...> - 2016-02-03 12:10:37
|
Dear all, I would like to announce new versions of two web sites for reasoning with probabilistic logics. With the first site http://cplint.lamping.unife.it you can reason with probabilistic logic programs under the distribution semantics, such as ProbLog, Logic Programs with Annotated Disjunctions and CP-Logic. The new version now includes Monte Carlo inference (including argument sampling), parameter and structure learning, together with many new inference and learning examples and the possibility of writing notebooks. You can test learned programs and compute the areas under the PR and ROC curve. A standalone online AUC calculator is also available at http://cplint.lamping.unife.it/example/exauc.pl You can download the PR and ROC curves as SVG. A tutorial is available at http://cplint.lamping.unife.it/tutorial/tutorial.swinb Please use the Google group cp...@go... to send questions, suggestions, comments and bug reports. With the second site http://trill.lamping.unife.it you can perform inference with probabilistic description logics under a possible worlds semantics. The new version now includes new examples and the possibility of writing notebooks. Both sites are based on SWISH: SWI-Prolog for Sharing, a web application for Prolog programming, developed by Jan Wielemaker and Torbjörn Lager. Please use the Google group tri...@go... to send questions, suggestions, comments and bug reports. Best Fabrizio Riguzzi http://ds.ing.unife.it/~friguzzi/ |
|
From: Eyal D. <eya...@gm...> - 2015-12-27 23:58:33
|
Hi,
The following script causes a segfault on my Mac OS X 10.9.5 with the HEAD
version of YAP:
?- yap_flag(version, V).
V = 'YAP 6.3.4 (x86_64-darwin13.4.0): Fri Dec 25 19:42:56 EST 2015'.
Changing 20 to 10 in the script does removes the segfault.
Thanks,
Eyal
=======================================================
:- initialization main.
:- table a/1.
a(X).
a(X).
main :-
length(Xs, 20),
a(Xs).
=======================================================
Causes:
%
%
% YAP OOOPS: likely bug in YAP, segmentation violation.
%
%
%
% PC: prolog:$exec_initialisation_goals/0 at clause 4
% Continuation: prolog:$exec_initialisation_goals/0 at clause 4
Active Choice-Points:
$catch(_164888,user:$LoopError(_164888,top),_1048369)
lists:member(user:main,[user:main])
$exec_initialisation_goals
$comp_mode(source,source)
$comp_mode(source,source)
$catch(_1048506,fail,_1048487)
$do_startup_reconsult(_131781)
$do_startup_reconsult(../test/test_02_segfault.pl)
$init_from_saved_state_and_args
$do_init_state
Exiting ....
|
|
From: Eyal D. <eya...@gm...> - 2015-12-26 00:59:11
|
Hi all, Is YAP being actively maintained? I've noticed few responses to questions/bug reports on this mailing list. Thanks, Eyal |
|
From: Eyal D. <eya...@gm...> - 2015-12-23 17:45:55
|
Hi,
The code below leads to a segmentation fault (every few executions). See
My machine:
$ uname -v
Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014;
root:xnu-2422.115.4~1/RELEASE_X86_64
Thanks,
Eyal
The code:
==================================================
/*
test_abolish_table.pl
Every few executions, the following leads to a segmentation violation in
YAP.
yap -L test_abolish_table.pl
========================================================
YAP 6.3.4 (x86_64-darwin13.4.0): Fri Dec 18 17:25:15 EST 2015
%
%
% YAP OOOPS: likely bug in YAP, segmentation violation.
%
%
%
% PC: user:a/1 at clause 1
% Continuation: user:a/1 at clause 1
Active Choice-Points:
Exiting ....
========================================================
Running in lldb reveals the following:
========================================================
YAP 6.3.4 (x86_64-darwin13.4.0): Fri Dec 18 17:25:15 EST 2015
Process 34644 stopped
* thread #1: tid = 0x5bc402, 0x000000010015a066
libYap.6.dylib`answer_search + 84, queue = 'com.apple.main-thread', stop
reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x000000010015a066 libYap.6.dylib`answer_search + 84
libYap.6.dylib`answer_search + 84:
-> 0x10015a066: movq 0x8(%rax), %rax
0x10015a06a: testb $0x2, 0x57(%rax)
0x10015a06e: je 0x10015acf1 ; answer_search + 3295
0x10015a074: movq (%rbx), %rcx
(lldb) bt
* thread #1: tid = 0x5bc402, 0x000000010015a066
libYap.6.dylib`answer_search + 84, queue = 'com.apple.main-thread', stop
reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
* frame #0: 0x000000010015a066 libYap.6.dylib`answer_search + 84
frame #1: 0x00000001000232f1 libYap.6.dylib`Yap_absmi + 90731
frame #2: 0x0000000100083c84 libYap.6.dylib`exec_absmi + 74
frame #3: 0x0000000100084095 libYap.6.dylib`do_goal + 349
frame #4: 0x0000000100149c48 libYap.6.dylib`YAP_RunGoalOnce + 86
frame #5: 0x000000010014a422 libYap.6.dylib`YAP_Init + 1788
frame #6: 0x0000000100003c8e yap`main + 58
(lldb)
========================================================
*/
:- initialization main.
:- table a/1.
a(X) :- abolish_table(a/1), X = 1.
main :- yap_flag(version, V), writeln(V), a(X).
|
|
From: Eyal D. <eya...@gm...> - 2015-11-30 18:48:14
|
Hi, with yap 6.3.4 HEAD I get the error below. Note, the error only appears with output to chars (list or difference list version), but not atom, codes, etc. thanks, Eyal YAP 6.3.4 (x86_64-darwin13.4.0): Mon Nov 23 08:52:11 EST 2015 ?- with_output_to(chars(C), writeln(hello)). % % % YAP OOOPS: likely bug in YAP, segmentation violation. % % % % PC: prolog:copy_term/3 at clause 1 % Continuation: prolog:$delayed_goals/5 at clause 1 Active Choice-Points: $delayed_goals(98,with_output_to([],writeln(hello)),119,98,119) $query(user,with_output_to([],writeln(hello))) $catch(_131086,user:$Error(_131086),_1048527) repeat % YAP regs: P=0x7f8992ebb888, CP=0x7f899388cdd8, ASP=0x110261c00, H=0x10fb62aa8, TR=0x110262098, HeapTop=0x0 % YAP mode: 2x % % PC: prolog:copy_term/3 at clause 1 % Continuation: prolog:$delayed_goals/5 at clause 1 % 1026KB of Global Stack (0x10fa62008--0x10fb62aa8) % 1KB of Local Stack (0x110261c00--0x110262000) % 0KB of Trail (0x110262008--0x110262098) % Performed 0 garbage collections % All Active Calls and % Goals With Alternatives Open (Global In Use--Local In Use) % % prolog:$delayed_goals/5 at clause 1 % prolog:$delayed_goals/5 at clause 1 % prolog:$query/2 at clause 3 % prolog:$command/4 at clause 2 % prolog:$enter_top_level/0 at clause 5 % prolog:$catch/3 (1024KB--0KB) % prolog:$system_catch/4 at clause 1 % meta-call Exiting .... |
|
From: Jacques G. <gre...@gm...> - 2015-11-07 10:29:04
|
Hello, I'm sorry. Some mispelling in the previous message due to copy/paste from the french version of the program. : asserta(test([mode(assiste)])). yes listing(test). test([(mode assiste)]). yes Whereas : asserta(test([foo(assiste)])). yes listing(test). test([(foo(assiste)]). yes Best regards Jacques Gressier |
30 messages has been excluded from this view by a project administrator.
