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
(1) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
|
From: windlewood <win...@ea...> - 2002-07-24 20:36:31
|
Want to watch HARDCORE PORN MOVIES ? Our site is voted the #1 BROADBAND MOVIE SITE ONLINE ! Click this link to WATCH OUR STEAMING CHIX IN ACTION : http://www.froggyhost.com/clubs/sexmoviestoday/ To unsubscribe from our list enter you email here : http://www.froggyhost.com/clubs/remove/ [PO1:KJ)_8J7BJK] |
|
From: Michael B. <mic...@zg...> - 2002-07-24 12:12:06
|
Hi all! Is there a way to interrupt the user input after a specified amount of time? I simply want to write the following method: read(+TimeOut, -Input) reads the next term from the current input stream, and unifies it with Input if the time limit TimeOut is not exceeded. Otherwise Input is unified with time_out. The following sample program just throws a time_out Exception because time_out uses alarm and alarm doesn't work well with read: read_to(TimeOut, Input) :- time_out(read(Input), TimeOut, Result), (time_out == Result -> Input = Result; true). Is there a way to interrupt the built-in read predicate? I'm using the Yap V4.3.22 binaries with Windows NT Workstation. thanks in advance, Michael |
|
From: DR. A. B. <ahm...@ho...> - 2002-07-19 19:58:38
|
200 BOL AHMED IKEJA-LAGOS NIGERIA TEL/FAX:234-1-7590154 DEAR I am the Chief Medical Doctor and close confidant of Mrs. Maryam Abacha, the former first lady and wife of the late Gen.Sani Abacha, the former head of state and commander in chief of the armed forces of the Federal Republic of Nigeria. She (MRS. M.ABACHA), has as a result of the trust and confidence,she has in me mandated that I search for a reliable and trustworthy foreign partner, who will help receive some funds which she had in cash totaling US$35M (Thirty fifty Million United States Dollars only) into a personal, company or any reliable foreign bank accounts within or outside your country as all their personal and family Bank accounts within and outside Nigeria have all been frozen by the Nigerian authorities. (I would refer you to the websiteof Weekly Tell magazine: WWW.TELLMAGAZINE.com of November 23, 1998 page 25,and another edition of TELL WEEKLY MAGAZINE of October 11 1999, Page 10 captioned the tyrants son,for further information about this money and the ABACHAS) This money in question has however, been clearly moved in defaced form and Deposited with a security company that has branches in Asia, Africa, Europe and various parts of America. It may also interest you to note that she (MRS.ABACHA)and her family have, since the inception of the resent democratic government, been placed under partial house arrest, with their international travelling passports seized pending when the current fund recovery face off between them and the present (RTD) GEN, OBASANJO led Democratic Government is resolved, in which from all indication will not exceed this year. She has decided to offer anybody who will be willing to render this tremendous assistance, 20% of the total sum. Note that this transaction involves no risks whatsoever, as you will have no dealing with my country, Nigeria. Rather you will deal directly with the Security Company, which is based where the money is right now. Let me have your confidential Tel/Fax numbers in your response to this proposal. I shall let you into a complete detailed picture of this mutual beneficial transaction when I have received your anticipated positive reply. Reply to this e-mail address(ahm...@ya...) OR TEL/FAX:234-1-7590154 This matter should be treated as urgent and confidential!) Regards, DR. AHMED BOL TEL/FAX:234-1-7590154 |
|
From: Contest A. <omn...@ya...> - 2002-07-11 04:54:57
|
<html> <body bgcolor="#FFFFFF" text="#000000"> <div align="left"><font size="6" face="Times New Roman, Times, serif"><b><font color="#0000FF">You're A Winner! </font></b></font><br> <br> <font face="Times New Roman, Times, serif" size="4">Dear yap-users, </font></div> <p><font face="Times New Roman, Times, serif" size="4">Congratulations you’re a winner! </font></p> <p><font face="Times New Roman, Times, serif" size="4">You’ve won 2nd prize in our recent drawing for an all expense paid Carribean Vacation for Two. <br> The grand prize went to Emma Eichanaur and she was delighted. Sorry, you didn’t win. </font></p> <p><font face="Times New Roman, Times, serif" size="4">But, there is good news! You've won the runner-up prize. </font></p> <p><font face="Times New Roman, Times, serif" size="4">You’ve won a 3 day 2 night weekend getaway for 2. You’ll really enjoy our weekend getaway because it... it's what you need. </font></p> <p><font face="Times New Roman, Times, serif" size="4">To claim your prize just come to our website and claim your prize. <br> <a href="http://www143.wiildaccess.com/form.htm">Click here<br> </a> </font></p> <p><font face="Times New Roman, Times, serif" size="4">Thanks for entering our contest and we look forward to seeing you soon. </font></p> <p><font face="Times New Roman, Times, serif" size="4">Sincerely, </font></p> <p><font face="Times New Roman, Times, serif" size="4">Lisa Diaz</font></p> <p><font face="Times New Roman, Times, serif" size="4">P.S. You’ve got to hurry. If you don’t claim your weekend getaway by in 24 hours<br> it will be awarded to the next runner-up. So don’t wait, <a href="http://www143.wiildaccess.com/form.htm">Click here</a> today. </font><font face="Times New Roman, Times, serif"><br> <br> <br> <br> <br> To be excluded from future prizes <a href="http://www143.wiildaccess.com/remove.htm">Click here</a></font></p> </body> </html> |
|
From: <kla...@ao...> - 2002-07-08 21:05:01
|
DQoNCjxodG1sPg0KPGRpdiBhbGlnbj0iY2VudGVyIj4gPHN0cm9uZz48Zm9u dCBmYWNlPSJUcmVidWNoZXQgTVMiIGNvbG9yPSIjZmYwMDAwIiBzaXplPSI2 Ij5UaGUgQ3JlZGl0IENhcmQgU2hvcHBlciBJcyBIZXJlIFRvIFN0YXk8L2Zv bnQ+PC9zdHJvbmc+PC9kaXY+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxzdHJv bmc+PGZvbnQgZmFjZT0iVHJlYnVjaGV0IE1TIiBjb2xvcj0iIzAwMDA4MCIg c2l6ZT0iNiI+TWFrZSBTdXJlIFRoZXkgQXJlIEJ1eWluZyBmcm9tIFlvdSE8 L2ZvbnQ+PC9zdHJvbmc+PC9kaXY+DQo8ZGl2IGFsaWduPSJsZWZ0Ij4gPHN0 cm9uZz4gPGZvbnQgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0IE1TIj5UaGUg ZmFjdHMgYWJvdXQgdG9kYXkncyBjb25zdW1lcjo8L2ZvbnQ+IDwvc3Ryb25n Pg0KICA8Zm9udCBzaXplPSI0IiBmYWNlPSJUcmVidWNoZXQgTVMiPiBIZSBv ciBzaGUgaXMgYSBmYXN0LXBhY2VkLCBvbi10aGUtZ28sICJJIHdhbnQgaXQg bm93IiBraW5kIG9mIHNob3BwZXIuIFRoZWlyIHdhbGxldHMgYXJlIHN0dWZm ZWQgZnVsbCBvZiBjcmVkaXQgY2FyZHMsIGFuZCB0aGUgY2hlY2tib29rIGlz ICB1c3VhbGx5IG5vd2hlcmUgdG8gYmUgZm91bmQuPC9mb250Pg0KPGRpdiBh bGlnbj0ibGVmdCI+IDxwIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6IDA7IG1hcmdpbi1yaWdodDogMCI+PGI+PGZvbnQgY29sb3I9IiNmZjAw MDAiIHNpemU9IjQiIGZhY2U9IlRyZWJ1Y2hldCBNUyI+VEhFU0UNCiAgU0hP UFBFUlMgQVJFIEVWRVJZV0hFUkUhPC9mb250PiA8L2I+PC9kaXY+DQo8ZGl2 IGFsaWduPSJsZWZ0Ij4gPHAgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW46 IDAiPjxmb250IGNvbG9yPSIjZmYwMDAwIiBzaXplPSI0IiBmYWNlPSJUcmVi dWNoZXQgTVMiPjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQ6IHNtYWxsLWNh cHMiPm9uDQogIHRoZSB3ZWI8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRy ZWJ1Y2hldCBNUyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudDogc21hbGwt Y2FwcyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgYWxpZ249 ImxlZnQiPiA8cCBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjogMCI+PGZv bnQgY29sb3I9IiNmZjAwMDAiIHNpemU9IjQiIGZhY2U9IlRyZWJ1Y2hldCBN UyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudDogc21hbGwtY2FwcyI+b24N CiAgdGhlIHBob25lPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgYWxpZ249 ImxlZnQiPjxwIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luOiAwIj48Zm9u dCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0IE1T Ij48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFsbC1jYXBzIj5pbg0K ICB0aGUgYXV0byBzaG9wPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgYWxp Z249ImxlZnQiPiA8cCBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjogMCI+ PGZvbnQgY29sb3I9IiNmZjAwMDAiIHNpemU9IjQiIGZhY2U9IlRyZWJ1Y2hl dCBNUyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudDogc21hbGwtY2FwcyI+ YXQNCiAgdGhlIGdpZnQgc2hvcDwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGFsaWduPSJsZWZ0Ij4gPHAgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW46 IDAiPjxiPjxmb250IGNvbG9yPSIjZmYwMDAwIiBmYWNlPSJUcmVidWNoZXQg TVMiIHNpemU9IjUiPjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQ6IHNtYWxs LWNhcHMiPkVWRVJZV0hFUkUhPC9zcGFuPjwvZm9udD48L2I+PC9kaXY+DQo8 ZGl2IGFsaWduPSJjZW50ZXIiPjxwIGFsaWduPSJsZWZ0Ij48ZW0+PGZvbnQg c2l6ZT0iMiIgY29sb3I9IiMwMDAwMDAiIGZhY2U9IlRyZWJ1Y2hldCBNUyI+ QWxsIFJldGFpbCxXaG9sZXNhbGUsIE9yZGVyIENlbnRlcnMsIE1haWwtT3Jk ZXIgQnVzaW5lc3MsIENvbnN0cnVjdGlvbiBUcmFkZXMsIGFuZCBTZXJ2aWNl IFByb3ZpZGVycyBuZWVkIHRvIGFjY2VwdCBjcmVkaXQgY2FyZHMhPC9mb250 PjwvZW0+PC9kaXY+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxwPjwvZGl2Pg0K PGRpdiBhbGlnbj0iY2VudGVyIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250 LXZhcmlhbnQ6IHNtYWxsLWNhcHMiPjxlbT48ZGZuPjxmb250IGNvbG9yPSIj RkYwMDAwIiBzaXplPSIzIiBmYWNlPSJUcmFqYW4iPk92ZXINCiAgOTIlIG9m IG1haWwgb3JkZXJzICZhbXA7IHBob25lIG9yZGVycyBhcmUgZG9uZSB3aXRo IGNyZWRpdCBjYXJkcy48L2ZvbnQ+PC9kZm4+PC9lbT48L3NwYW4+PC9zdHJv bmc+PC9kaXY+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPiA8L2Rpdj4NCjxmb250 IHNpemU9IjQiPjxoMSBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCIgYWxp Z249ImNlbnRlciI+PHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTRwdDsgbXNv LWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxmb250IGNvbG9yPSIjMDAwMDgw IiBmYWNlPSJUcmFqYW4iIHNpemU9IjUiPjxiPldoeSBOb3QgSW5jcmVhc2Ug eW91ciBzYWxlcyBieSA0MDAlPzwvYj48L2ZvbnQ+PC9zcGFuPjwvaDE+DQo8 cCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCIgYWxpZ249ImNlbnRlciI+ Jm5ic3A7PC9wPjwvZm9udD4NCjxkaXYgYWxpZ249ImNlbnRlciI+PHN0cm9u Zz48Zm9udCBmYWNlPSJUcmFqYW4iIHNpemU9IjQiIGNvbG9yPSIjRkYwMDAw Ij48aT5ZT1UgQ0FOIEJFR0lOIEFDQ0VQVElORyBDUkVESVQgQ0FSRFMgSU4g QVMgTElUVExFIEFTIDI0IEhPVVJTITwvaT48L2ZvbnQ+PC9zdHJvbmc+PC9k aXY+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9IlRyZWJ1Y2hl dCBNUyIgc2l6ZT0iNCIgY29sb3I9IiMwMDAwMDAiPihEZXBlbmRpbmcgdXBv biB0aGUgY3JlZGl0IGNhcmQgIHByb2dyYW0gd2UgZ2V0IHlvdSBxdWFsaWZp ZWQgZm9yKTwvZm9udD4NCjwvZGl2Pg0KPGZvbnQgc2l6ZT0iNCI+PGZvbnQg ZmFjZT0iVHcgQ2VuIE1UIiBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iNSI+PGZv bnQgZmFjZT0iVHcgQ2VuIE1UIiBzaXplPSI1Ij48ZGl2IGFsaWduPSJjZW50 ZXIiPjxiPjxmb250IHNpemU9IjUiIGZhY2U9IlRyZWJ1Y2hldCBNUyIgY29s b3I9IiMwMDAwODAiPlZpc2EsIE1hc3RlckNhcmQsIEFtZXJpY2FuIEV4cHJl c3MsIERpc2NvdmVyPC9mb250PjwvYj48L2Rpdj4NCjxkaXYgYWxpZ249ImNl bnRlciI+PC9kaXY+PC9mb250PjwvZm9udD4NCjxoNCBzdHlsZT0iTUFSR0lO OiAwaW4gMGluIDBwdCIgYWxpZ249ImxlZnQiPjxmb250IGZhY2U9IlRyZWJ1 Y2hldCBNUyIgY29sb3I9IiMwMDAwMDAiIHNpemU9IjQiPlNhbWUgZGF5IGFw cHJvdmFsIC0gbm8gdHVybiBkb3ducyAtIGVhc3kgZmF4IGFwcGxpY2F0aW9u PC9mb250PjwvaDQ+PGg0IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IiBh bGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0iVHJlYnVjaGV0IE1TIiBzaXplPSI0 Ij48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxm b250IGNvbG9yPSIjMDAwMDAwIj5SZXRhaWw8L2ZvbnQ+PGZvbnQgY29sb3I9 IiNGRjAwMDAiPio8L2ZvbnQ+DQo8Zm9udCBzaXplPSI1IiBmYWNlPSJUdyBD ZW4gTVQiIGNvbG9yPSIjMDAwMDAwIj5XZWIgVmlydHVhbCB0ZXJtaW5hbCA8 L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRjAwMDAiPio8L2ZvbnQ+DQo8Zm9udCBj b2xvcj0iIzAwMDAwMCI+TWFpbCBvcmRlcjwvZm9udD48Zm9udCBjb2xvcj0i I0ZGMDAwMCI+KjwvZm9udD48Zm9udCBjb2xvcj0iIzAwMDAwMCI+IFRlbGVw aG9uZSBvcmRlcjwvZm9udD48L3NwYW4+PC9mb250PjxzdHJvbmc+PHNwYW4g c3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48Zm9udCBzaXpl PSI0IiBmYWNlPSJUcmVidWNoZXQgTVMiIGNvbG9yPSIjMDAwMDAwIj48TzpQ Pg0KPC9POlA+PC9mb250Pjwvc3Bhbj48L3N0cm9uZz48L2g0Pg0KICA8aDQg c3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiIGFsaWduPSJsZWZ0Ij48Zm9u dCBmYWNlPSJUcmVidWNoZXQgTVMiIHNpemU9IjQiPkV4aXN0aW5nIE1lcmNo YW50czogPGk+PGZvbnQgZmFjZT0iVHcgQ2VuIE1UIiBjb2xvcj0iIzAwMDAw MCIgc2l6ZT0iNSI+TG93ZXIgeW91ciByYXRlcyAtLUZSRUUgc3RhdGVtZW50 IGFuYWx5c2lzPC9mb250PjwvaT48L2ZvbnQ+DQogIDwvaDQ+DQo8UD48Zm9u dCBzaXplPSIrMiIgZmFjZT0iVHcgQ2VuIE1UIiBjb2xvcj0iIzAwMDAwMCI+ PGEgaHJlZj0iaHR0cDovL3d3dy5sb3dlc3QtcmF0ZS5uZXQvY2dpLWJpbi9t ZXJjaGFudF9zZXJ2aWNlcy5jZ2k/YWZmaWxpYXRlPTU1MDQ2MyI+IEp1c3Qg Q2xpY2sgSGVyZSB0byBTdGFydCBBY2NlcHRpbmcgQ3JlZGl0IENhcmRzIFJp Z2h0IEF3YXkhPC9hPiAgDQo8cD5BIHJlcHJlc2VudGF0aXZlIHdpbGwgY29u dGFjdCB5b3Ugd2l0aGluIDI0IGhvdXJzITwvZm9udD4NCjxmb250IGZhY2U9 IlR3IENlbiBNVCIgY29sb3I9IiMwMDAwMDAiIHNpemU9IjUiPg0KPFA+PGZv bnQgZmFjZT0iQXJpYWwiIHNpemU9IjMiPg0KSnVzdCBWaXNpdCBPdXIgV2Vi c2l0ZSB0byB0YWtlIHlvdXIgbmFtZSBvdXQgb2Ygb3VyIG1hc3RlciBkYXRh YmFzZS4NCjxmb250IGNvbG9yPSJmZmZmZmYiPg0KPHA+DQo8L2Rpdj4NCg0K PC9oND4NCg0KPC9odG1sPg0KNjk4MFdWQ2FsOA== |
|
From: <jru...@an...> - 2002-07-08 17:30:17
|
DQoNCjxodG1sPg0KPGRpdiBhbGlnbj0iY2VudGVyIj4gPHN0cm9uZz48Zm9u dCBmYWNlPSJUcmVidWNoZXQgTVMiIGNvbG9yPSIjZmYwMDAwIiBzaXplPSI2 Ij5Nb3N0IFNob3BwZXJzIFdhbnQgdG8gVXNlIENyZWRpdDwvZm9udD48L3N0 cm9uZz48L2Rpdj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PHN0cm9uZz48Zm9u dCBmYWNlPSJUcmVidWNoZXQgTVMiIGNvbG9yPSIjMDAwMDgwIiBzaXplPSI2 Ij5NYWtlIFN1cmUgVGhleSBBcmUgQnV5aW5nIGZyb20gWW91ITwvZm9udD48 L3N0cm9uZz48L2Rpdj4NCjxkaXYgYWxpZ249ImxlZnQiPiA8c3Ryb25nPiA8 Zm9udCBzaXplPSI0IiBmYWNlPSJUcmVidWNoZXQgTVMiPlRoZSBmYWN0cyBh Ym91dCB0b2RheSdzIGNvbnN1bWVyOjwvZm9udD4gPC9zdHJvbmc+DQogIDxm b250IHNpemU9IjQiIGZhY2U9IlRyZWJ1Y2hldCBNUyI+IEhlIG9yIHNoZSBp cyBhIGZhc3QtcGFjZWQsIG9uLXRoZS1nbywgIkkgd2FudCBpdCBub3ciIGtp bmQgb2Ygc2hvcHBlci4gVGhlaXIgd2FsbGV0cyBhcmUgc3R1ZmZlZCBmdWxs IG9mIGNyZWRpdCBjYXJkcywgYW5kIHRoZSBjaGVja2Jvb2sgaXMgIHVzdWFs bHkgbm93aGVyZSB0byBiZSBmb3VuZC48L2ZvbnQ+DQo8ZGl2IGFsaWduPSJs ZWZ0Ij4gPHAgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW4tbGVmdDogMDsg bWFyZ2luLXJpZ2h0OiAwIj48Yj48Zm9udCBjb2xvcj0iI2ZmMDAwMCIgc2l6 ZT0iNCIgZmFjZT0iVHJlYnVjaGV0IE1TIj5USEVTRQ0KICBTSE9QUEVSUyBB UkUgRVZFUllXSEVSRSE8L2ZvbnQ+IDwvYj48L2Rpdj4NCjxkaXYgYWxpZ249 ImxlZnQiPiA8cCBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjogMCI+PGZv bnQgY29sb3I9IiNmZjAwMDAiIHNpemU9IjQiIGZhY2U9IlRyZWJ1Y2hldCBN UyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudDogc21hbGwtY2FwcyI+b24N CiAgdGhlIHdlYjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVHJlYnVjaGV0 IE1TIj48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFsbC1jYXBzIj4m bmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBhbGlnbj0ibGVmdCI+ IDxwIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luOiAwIj48Zm9udCBjb2xv cj0iI2ZmMDAwMCIgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0IE1TIj48c3Bh biBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFsbC1jYXBzIj5vbg0KICB0aGUg cGhvbmU8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBhbGlnbj0ibGVmdCI+ PHAgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW46IDAiPjxmb250IGNvbG9y PSIjZmYwMDAwIiBzaXplPSI0IiBmYWNlPSJUcmVidWNoZXQgTVMiPjxzcGFu IHN0eWxlPSJmb250LXZhcmlhbnQ6IHNtYWxsLWNhcHMiPmluDQogIHRoZSBh dXRvIHNob3A8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBhbGlnbj0ibGVm dCI+IDxwIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luOiAwIj48Zm9udCBj b2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0IE1TIj48 c3BhbiBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFsbC1jYXBzIj5hdA0KICB0 aGUgZ2lmdCBzaG9wPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgYWxpZ249 ImxlZnQiPiA8cCBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjogMCI+PGI+ PGZvbnQgY29sb3I9IiNmZjAwMDAiIGZhY2U9IlRyZWJ1Y2hldCBNUyIgc2l6 ZT0iNSI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudDogc21hbGwtY2FwcyI+ RVZFUllXSEVSRSE8L3NwYW4+PC9mb250PjwvYj48L2Rpdj4NCjxkaXYgYWxp Z249ImNlbnRlciI+PHAgYWxpZ249ImxlZnQiPjxlbT48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzAwMDAwMCIgZmFjZT0iVHJlYnVjaGV0IE1TIj5BbGwgUmV0 YWlsLFdob2xlc2FsZSwgT3JkZXIgQ2VudGVycywgTWFpbC1PcmRlciBCdXNp bmVzcywgQ29uc3RydWN0aW9uIFRyYWRlcywgYW5kIFNlcnZpY2UgUHJvdmlk ZXJzIG5lZWQgdG8gYWNjZXB0IGNyZWRpdCBjYXJkcyE8L2ZvbnQ+PC9lbT48 L2Rpdj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PHA+PC9kaXY+DQo8ZGl2IGFs aWduPSJjZW50ZXIiPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFu dDogc21hbGwtY2FwcyI+PGVtPjxkZm4+PGZvbnQgY29sb3I9IiNGRjAwMDAi IHNpemU9IjMiIGZhY2U9IlRyYWphbiI+T3Zlcg0KICA5MiUgb2YgbWFpbCBv cmRlcnMgJmFtcDsgcGhvbmUgb3JkZXJzIGFyZSBkb25lIHdpdGggY3JlZGl0 IGNhcmRzLjwvZm9udD48L2Rmbj48L2VtPjwvc3Bhbj48L3N0cm9uZz48L2Rp dj4NCjxkaXYgYWxpZ249ImNlbnRlciI+IDwvZGl2Pg0KPGZvbnQgc2l6ZT0i NCI+PGgxIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IiBhbGlnbj0iY2Vu dGVyIj48c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxNHB0OyBtc28tYmlkaS1m b250LXNpemU6IDEwLjBwdCI+PGZvbnQgY29sb3I9IiMwMDAwODAiIGZhY2U9 IlRyYWphbiIgc2l6ZT0iNSI+PGI+V2h5IE5vdCBJbmNyZWFzZSB5b3VyIHNh bGVzIGJ5IDQwMCU/PC9iPjwvZm9udD48L3NwYW4+PC9oMT4NCjxwIHN0eWxl PSJNQVJHSU46IDBpbiAwaW4gMHB0IiBhbGlnbj0iY2VudGVyIj4mbmJzcDs8 L3A+PC9mb250Pg0KPGRpdiBhbGlnbj0iY2VudGVyIj48c3Ryb25nPjxmb250 IGZhY2U9IlRyYWphbiIgc2l6ZT0iNCIgY29sb3I9IiNGRjAwMDAiPjxpPllP VSBDQU4gQkVHSU4gQUNDRVBUSU5HIENSRURJVCBDQVJEUyBJTiBBUyBMSVRU TEUgQVMgMjQgSE9VUlMhPC9pPjwvZm9udD48L3N0cm9uZz48L2Rpdj4NCjxk aXYgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0iVHJlYnVjaGV0IE1TIiBz aXplPSI0IiBjb2xvcj0iIzAwMDAwMCI+KERlcGVuZGluZyB1cG9uIHRoZSBj cmVkaXQgY2FyZCAgcHJvZ3JhbSB3ZSBnZXQgeW91IHF1YWxpZmllZCBmb3Ip PC9mb250Pg0KPC9kaXY+DQo8Zm9udCBzaXplPSI0Ij48Zm9udCBmYWNlPSJU dyBDZW4gTVQiIGNvbG9yPSIjMDAwMDAwIiBzaXplPSI1Ij48Zm9udCBmYWNl PSJUdyBDZW4gTVQiIHNpemU9IjUiPjxkaXYgYWxpZ249ImNlbnRlciI+PGI+ PGZvbnQgc2l6ZT0iNSIgZmFjZT0iVHJlYnVjaGV0IE1TIiBjb2xvcj0iIzAw MDA4MCI+VmlzYSwgTWFzdGVyQ2FyZCwgQW1lcmljYW4gRXhwcmVzcywgRGlz Y292ZXI8L2ZvbnQ+PC9iPjwvZGl2Pg0KPGRpdiBhbGlnbj0iY2VudGVyIj48 L2Rpdj48L2ZvbnQ+PC9mb250Pg0KPGg0IHN0eWxlPSJNQVJHSU46IDBpbiAw aW4gMHB0IiBhbGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0iVHJlYnVjaGV0IE1T IiBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iNCI+U2FtZSBkYXkgYXBwcm92YWwg LSBubyB0dXJuIGRvd25zIC0gZWFzeSBmYXggYXBwbGljYXRpb248L2ZvbnQ+ PC9oND48aDQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiIGFsaWduPSJs ZWZ0Ij48Zm9udCBmYWNlPSJUcmVidWNoZXQgTVMiIHNpemU9IjQiPjxzcGFu IHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PGZvbnQgY29s b3I9IiMwMDAwMDAiPlJldGFpbDwvZm9udD48Zm9udCBjb2xvcj0iI0ZGMDAw MCI+KjwvZm9udD4NCjxmb250IHNpemU9IjUiIGZhY2U9IlR3IENlbiBNVCIg Y29sb3I9IiMwMDAwMDAiPldlYiBWaXJ0dWFsIHRlcm1pbmFsIDwvZm9udD48 Zm9udCBjb2xvcj0iI0ZGMDAwMCI+KjwvZm9udD4NCjxmb250IGNvbG9yPSIj MDAwMDAwIj5NYWlsIG9yZGVyPC9mb250Pjxmb250IGNvbG9yPSIjRkYwMDAw Ij4qPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMDAwIj4gVGVsZXBob25lIG9y ZGVyPC9mb250Pjwvc3Bhbj48L2ZvbnQ+PHN0cm9uZz48c3BhbiBzdHlsZT0i bXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxmb250IHNpemU9IjQiIGZh Y2U9IlRyZWJ1Y2hldCBNUyIgY29sb3I9IiMwMDAwMDAiPjxPOlA+DQo8L086 UD48L2ZvbnQ+PC9zcGFuPjwvc3Ryb25nPjwvaDQ+DQogIDxoNCBzdHlsZT0i TUFSR0lOOiAwaW4gMGluIDBwdCIgYWxpZ249ImxlZnQiPjxmb250IGZhY2U9 IlRyZWJ1Y2hldCBNUyIgc2l6ZT0iNCI+RXhpc3RpbmcgTWVyY2hhbnRzOiA8 aT48Zm9udCBmYWNlPSJUdyBDZW4gTVQiIGNvbG9yPSIjMDAwMDAwIiBzaXpl PSI1Ij5Mb3dlciB5b3VyIHJhdGVzIC0tRlJFRSBzdGF0ZW1lbnQgYW5hbHlz aXM8L2ZvbnQ+PC9pPjwvZm9udD4NCiAgPC9oND4NCjxQPjxmb250IHNpemU9 IisyIiBmYWNlPSJUdyBDZW4gTVQiIGNvbG9yPSIjMDAwMDAwIj48YSBocmVm PSJodHRwOi8vd3d3Lmxvd2VzdC1yYXRlLm5ldC9jZ2ktYmluL21lcmNoYW50 X3NlcnZpY2VzLmNnaT9hZmZpbGlhdGU9NTUwNDYzIj4gSnVzdCBDbGljayBI ZXJlIHRvIFN0YXJ0IEFjY2VwdGluZyBDcmVkaXQgQ2FyZHMgUmlnaHQgQXdh eSE8L2E+ICANCjxwPkEgcmVwcmVzZW50YXRpdmUgd2lsbCBjb250YWN0IHlv dSB3aXRoaW4gMjQgaG91cnMhPC9mb250Pg0KPGZvbnQgZmFjZT0iVHcgQ2Vu IE1UIiBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iNSI+DQo8UD48Zm9udCBmYWNl PSJBcmlhbCIgc2l6ZT0iMyI+DQpKdXN0IFZpc2l0IE91ciBXZWJzaXRlIHRv IHRha2UgeW91ciBuYW1lIG91dCBvZiBvdXIgbWFzdGVyIGRhdGFiYXNlLg0K PGZvbnQgY29sb3I9ImZmZmZmZiI+DQo8cD4NCjwvZGl2Pg0KDQo8L2g0Pg0K DQo8L2h0bWw+DQo3MzgzcHlhYzQtMTQzQVdscjM5OTNxbW9DMi00OTNwS0lv OTYxM1RqUnExLTg3MkppYlA5ODM5TWxMRjctMzk3QWw2MQ== |
|
From: <alv...@pi...> - 2002-06-28 01:27:42
|
Easy 30-50% Return? Learn how you can receive a monthly check for 3, 4, or 5% a month until your initial investment is paid off...then a monthly check for over 4% a month for years to come... We know it sounds impossible, but it's happening today. For complete information on this multi-trillion dollar industry: http://just4unow.com/pos ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To Opt Out please go to our website and click on the link at the bottom of the page: http://just4unow.com/options 0939NdYA6-539Puxul16 |
|
From: Vitor S. C. <vi...@bi...> - 2002-06-26 05:26:46
|
Dear Roberto, > with your change I have succeeded, after fixing a couple of bugs > on my part, at producing a working YAP interface for the Parma > Polyhedra Library. This will be part of the next PPL release. > BTW, finding these bugs has been exceptionally difficult due to the > fact that Term, Functor and Atom are all typedef'd to be CELL: > this means you can do all sorts of mistakes without any help > from the C compiler. That is quite a reasonable complaint, they actually have different types in Yap itself. I fixed it. Cheers, Vitor |
|
From: Vitor S. C. <vi...@bi...> - 2002-06-24 22:54:32
|
Hi Roberto, > with your change I have succeeded, after fixing a couple of bugs > on my part, at producing a working YAP interface for the Parma > Polyhedra Library. This will be part of the next PPL release. Great. > BTW, finding these bugs has been exceptionally difficult due to the > fact that Term, Functor and Atom are all typedef'd to be CELL: > this means you can do all sorts of mistakes without any help > from the C compiler. Yes, actually it is possible to have them being different types. > Thanks again for you help. Thanks for your work, great news! Cheers, Vitor |
|
From: Roberto B. <ba...@cs...> - 2002-06-24 21:27:00
|
Vitor Santos Costa wrote:
> I changed the Yap GMP allocation routines to fall back to
> malloc/realloc/free if outside context. I think that is the best
> solution for two reasons:
>
> - It is the most general: external processes might not want their
> objects to disappear during backtracking.
> - It avoids nasty interactions with the garbage collector: even I
> disallow gc of these objects, is application is not prepared for
> the gc barging in and shifting objects around?
>
> I haven't actually tested it outside Yap, do you mind trying it and
> telling me it works?
Dear Vitor,
with your change I have succeeded, after fixing a couple of bugs
on my part, at producing a working YAP interface for the Parma
Polyhedra Library. This will be part of the next PPL release.
BTW, finding these bugs has been exceptionally difficult due to the
fact that Term, Functor and Atom are all typedef'd to be CELL:
this means you can do all sorts of mistakes without any help
from the C compiler.
Thanks again for you help.
All the best
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:ba...@cs...
|
|
From: Roberto B. <ba...@cs...> - 2002-06-20 08:56:05
|
Vitor Santos Costa wrote:
>> I changed the Yap GMP allocation routines to fall back to
> malloc/realloc/free if outside context. I think that is the best
> solution for two reasons:
>
> - It is the most general: external processes might not want their
> objects to disappear during backtracking.
> - It avoids nasty interactions with the garbage collector: even I
> disallow gc of these objects, is application is not prepared for
> the gc barging in and shifting objects around?
>
> I haven't actually tested it outside Yap, do you mind trying it and
> telling me it works?
Hi Vitor,
I can confirm I am no longer observing the problem we had with GLP.
(I am observing other problems, but more debugging work is needed
to properly identify them.)
Thanks a lot
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:ba...@cs...
|
|
From: Vitor S. C. <vi...@bi...> - 2002-06-19 21:51:31
|
>
> Hi Vitor,
>
> I believe that calling mp_set_memory_functions repeatedly would mean that
> we must abandon all the guarantees provided by GMP's interface.
> In fact, the following paragraph is taken from GMP's manual:
>
> @strong{Be sure to call @code{mp_set_memory_functions} only when there are no
> active GMP objects allocated using the previous memory functions! Usually
> that means calling it before any other GMP function.}
>
> Ciao
>
> Roberto
>
Hi Roberto,
I changed the Yap GMP allocation routines to fall back to
malloc/realloc/free if outside context. I think that is the best
solution for two reasons:
- It is the most general: external processes might not want their
objects to disappear during backtracking.
- It avoids nasty interactions with the garbage collector: even I
disallow gc of these objects, is application is not prepared for
the gc barging in and shifting objects around?
I haven't actually tested it outside Yap, do you mind trying it and
telling me it works?
Thanks
Vitor
|
|
From: Vitor S. C. <vi...@bi...> - 2002-06-18 18:16:57
|
Hi Roberto,
> I believe that calling mp_set_memory_functions repeatedly would mean that
> we must abandon all the guarantees provided by GMP's interface.
> In fact, the following paragraph is taken from GMP's manual:
>
> @strong{Be sure to call @code{mp_set_memory_functions} only when there are no
> active GMP objects allocated using the previous memory functions! Usually
> that means calling it before any other GMP function.}
>
I have to think a bit about this. The functions are really not ok to
be exported right now. On the other hand what you want to do is quite
legitimate. It's a bit of the minefield, let me consider the best
alternative.
Cheers
Vitor
|
|
From: Roberto B. <ba...@cs...> - 2002-06-18 18:12:16
|
Vitor Santos Costa wrote:
> The problem seems to be that Yap defines its own allocation functions
> for gmp objects:
>
> #ifdef USE_GMP
> /* YAP style memory allocation */
> mp_set_memory_functions(
> AllocBigNumSpace,
> ReAllocBigNumSpace,
> FreeBigNumSpace);
> #endif
>
> This allows Yap to work with such objects in its own
> stacks. Unfortunately, these functions require for another function,
> PreAllocBigNum to have been called before. In general, using them is a
> bit dangerous, because they assume they have control over the global stack.
>
> I suppose Yap is polluting the application space, so the correct
> solution would be for Yap to reset these functions before entering
> user code. But this would make the interface slower for any
> application that doesn't use GMP.
>
> A compromise might be for me to provide two interface functions
> (YapResetGMPFunctions() and YapSet GMPFunctions()) and for you to call
> them before you started manipulating GMP objects.
Hi Vitor,
I believe that calling mp_set_memory_functions repeatedly would mean that
we must abandon all the guarantees provided by GMP's interface.
In fact, the following paragraph is taken from GMP's manual:
@strong{Be sure to call @code{mp_set_memory_functions} only when there are no
active GMP objects allocated using the previous memory functions! Usually
that means calling it before any other GMP function.}
Ciao
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:ba...@cs...
|
|
From: Roberto B. <ba...@cs...> - 2002-06-18 17:30:24
|
Vitor Santos Costa wrote:
> The problem seems to be that Yap defines its own allocation functions
> for gmp objects:
>
> #ifdef USE_GMP
> /* YAP style memory allocation */
> mp_set_memory_functions(
> AllocBigNumSpace,
> ReAllocBigNumSpace,
> FreeBigNumSpace);
> #endif
>
> This allows Yap to work with such objects in its own
> stacks. Unfortunately, these functions require for another function,
> PreAllocBigNum to have been called before. In general, using them is a
> bit dangerous, because they assume they have control over the global stack.
>
> I suppose Yap is polluting the application space, so the correct
> solution would be for Yap to reset these functions before entering
> user code. But this would make the interface slower for any
> application that doesn't use GMP.
>
> A compromise might be for me to provide two interface functions
> (YapResetGMPFunctions() and YapSet GMPFunctions()) and for you to call
> them before you started manipulating GMP objects.
Why is not Yap calling PreAllocBigNum first?
I mean, initializing things so that AllocBigNumSpace and friends
work correctly would seem something to be done in the first lines
of Yap's main function.
Wouldn't this solve all the problems? The PPL does not really care
where GMP takes the memory from: if it comes from Yap's stacks that
is fine. In other words, PPL just uses the GMP's entry point without
making any further assumption.
All the best
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:ba...@cs...
|
|
From: Vitor S. C. <vi...@bi...> - 2002-06-18 16:55:37
|
The problem seems to be that Yap defines its own allocation functions for gmp objects: #ifdef USE_GMP /* YAP style memory allocation */ mp_set_memory_functions( AllocBigNumSpace, ReAllocBigNumSpace, FreeBigNumSpace); #endif This allows Yap to work with such objects in its own stacks. Unfortunately, these functions require for another function, PreAllocBigNum to have been called before. In general, using them is a bit dangerous, because they assume they have control over the global stack. I suppose Yap is polluting the application space, so the correct solution would be for Yap to reset these functions before entering user code. But this would make the interface slower for any application that doesn't use GMP. A compromise might be for me to provide two interface functions (YapResetGMPFunctions() and YapSet GMPFunctions()) and for you to call them before you started manipulating GMP objects. Cheers, Vitor |
|
From: Roberto B. <ba...@cs...> - 2002-06-18 16:38:37
|
Hi there,
since we have decided that PPL 0.4 must be shipped with a reasonably
complete YAP interface, we have investigated a bit more the problems
we are experiencing. These can be split in two: the first one has to
do with the fact that PPL uses GMP and YAP also uses, by default, GMP.
That results in a segmentation fault at the very first memory allocation
of a GMP object that the PPL performs. But let us proceed with order.
The machines we use are Athlon machines running RedHat GNU/Linux 7.2
and 7.3 with all the updates applied. We use GCC 3.0.4.
$ uname -a
Linux xyzzy 2.4.18 #2 Thu Feb 28 07:12:54 CET 2002 i686 unknown
$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0.4/specs
Configured with: ../gcc-3.0.4/configure --prefix=3D/usr/local
Thread model: single
gcc version 3.0.4
$
We use a CVS version of yap that is up-to-date at the time of writing.
This has been configured with
--enable-debug-yap --prefix=3D/usr/local
With this configuration we cannot even load the PPL-YAP interface
due to a segmentation fault in AllocBigNumSpace (size=3D4) at C/bignum.c:=
96.
The complete log of a gdb session is below the signature (I am sure
Vitor will immediately see where the problem is).
To expose the other problems we have (I will do that in a following
message) we must therefore add --disable-gmp to the configuration
options of YAP.
Will be back later
Roberto
--=20
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:ba...@cs...
$ gdb yap
GNU gdb Red Hat Linux (5.1-1)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you =
are
welcome to change it and/or distribute copies of it under certain conditi=
ons.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for detail=
s.
This GDB was configured as "i386-redhat-linux"...
(gdb) r
Starting program: /usr/local/bin/yap
[ Restoring file startup ]
[ YAP version Yap-4.3.23 ]
?- load_foreign_files(['ppl_yap'],[],init).
Program received signal SIGSEGV, Segmentation fault.
AllocBigNumSpace (size=3D4) at C/bignum.c:96
96=20
alloc_ptr[0] =3D size;
(gdb) info stack
#0 AllocBigNumSpace (size=3D4) at C/bignum.c:96
#1 0x400272a4 in __gmpz_init (x=3D0x80e1198) at ../../gmp-4.0.1/mpz/init=
.c:29
#2 0x4020b7cb in Parma_Polyhedra_Library::Init::Init() (this=3D0x4000cba=
0)
at ../../../../ppl/ppl/src/Init.inlines.hh:36
#3 0x40203f11 in __static_initialization_and_destruction_0(int, int) (
__initialize_p=3D1, __priority=3D65535)
at ../../../../ppl/ppl/src/initializer.hh:29
#4 0x40204845 in _GLOBAL__I__Z23Prolog_atom_from_stringPKc ()
at /usr/local/include/g++-v3/bits/locale_facets.h:97
#5 0x402048e7 in __do_global_ctors_aux ()
at /usr/local/include/g++-v3/bits/locale_facets.h:97
#6 0x401f05c6 in _init ()
from /home/roberto/dtppl/interfaces/Prolog/YAP/.libs/ppl_yap.so
#7 0x4000d111 in _dl_init (main_map=3D0x80e1198, argc=3D1, argv=3D0xbfff=
f904,
env=3D0xbffff90c) at dl-init.c:70
#8 0x401ad3e1 in dl_open_worker (a=3D0xbffff4f0) at dl-open.c:361
#9 0x4000ce55 in _dl_catch_error (objname=3D0xbffff4e8, errstring=3D0xbf=
fff4ec,
operate=3D0x401ad14c <dl_open_worker>, args=3D0xbffff4f0) at dl-erro=
r.c:152
#10 0x401ad756 in _dl_open (
file=3D0x80dd7e0 "/home/roberto/dtppl/interfaces/Prolog/YAP/.libs/pp=
l_yap.so", mode=3D-2147483391, caller=3D0x809f01a) at dl-open.c:407
#11 0x40080363 in dlopen_doit (a=3D0xbffff650) at dlopen.c:39
#12 0x4000ce55 in _dl_catch_error (objname=3D0x400820e4, errstring=3D0x40=
0820e8,
---Type <return> to continue, or q <return> to quit---
operate=3D0x40080338 <dlopen_doit>, args=3D0xbffff650) at dl-error.c=
:152
#13 0x400806b6 in _dlerror_run (operate=3D0x40080338 <dlopen_doit>,
args=3D0xbffff650) at dlerror.c:130
#14 0x40080323 in __dlopen_check (
file=3D0x80dd7e0 "/home/roberto/dtppl/interfaces/Prolog/YAP/.libs/pp=
l_yap.so", mode=3D257) at dlopen.c:53
#15 0x0809f01a in LoadForeign (ofiles=3D0x90cbba8, libs=3D0x0,
proc_name=3D0x90cba3c "init", init_proc=3D0xbffff6b8) at C/load_dl.c=
:60
#16 0x0809edff in p_load_foreign () at C/load_foreign.c:86
#17 0x080a932a in absmi (inp=3D0) at C/absmi.c:5659
#18 0x0806d988 in exec_absmi (top=3D1) at C/exec.c:881
#19 0x0806db82 in do_goal (CodeAdr=3D0x901a460 "=F0V\n\b=F4=FF=FF=FF=D8=A3=
\001\t", arity=3D0,
pt=3D0x0, args_to_save=3D0, top=3D1) at C/exec.c:934
#20 0x0806e1b4 in RunTopGoal (t=3D214482) at C/exec.c:1118
#21 0x08050f07 in YapRunGoal (t=3D214482) at C/c_interface.c:698
#22 0x0804f581 in do_top_goal (Goal=3D214482) at console/yap.c:122
#23 0x0804fd21 in exec_top_level (BootMode=3D1, filename=3D0x0)
at console/yap.c:460
#24 0x0804fd9f in main (argc=3D1, argv=3D0xbffff904) at console/yap.c:486
#25 0x400b6316 in __libc_start_main (main=3D0x804fd50 <main>, argc=3D1,
ubp_av=3D0xbffff904, init=3D0x804e974 <_init>, fini=3D0x80c8690 <_fi=
ni>,
rtld_fini=3D0x4000d2fc <_dl_fini>, stack_end=3D0xbffff8fc)
at ../sysdeps/generic/libc-start.c:129
(gdb) frame 0
#0 AllocBigNumSpace (size=3D4) at C/bignum.c:96
96=20
alloc_ptr[0] =3D size;
(gdb) print alloc_ptr
$1 =3D (CELL *) 0x0
(gdb)
The following output may also be of interest:
$ ldd /usr/local/bin/yap
libgmp.so.3 =3D> /usr/local/lib/libgmp.so.3 (0x40017000)
libm.so.6 =3D> /lib/libm.so.6 (0x4005d000)
libdl.so.2 =3D> /lib/libdl.so.2 (0x4007f000)
libnsl.so.1 =3D> /lib/libnsl.so.1 (0x40083000)
libc.so.6 =3D> /lib/libc.so.6 (0x4009a000)
libgcc_s.so.1 =3D> /usr/local/lib/libgcc_s.so.1 (0x401d1000)
/lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x40000000)
$ ldd ppl_yap.so
libppl.so.0 =3D> /home/roberto/dtppl/src/.libs/libppl.so.0 (0x4004f000)
libgmp.so.3 =3D> /usr/local/lib/libgmp.so.3 (0x400ed000)
libgmpxx.so.3 =3D> /usr/local/lib/libgmpxx.so.3 (0x40126000)
libgcc_s.so.1 =3D> /usr/local/lib/libgcc_s.so.1 (0x40132000)
libc.so.6 =3D> /lib/libc.so.6 (0x40148000)
libstdc++.so.3 =3D> /usr/local/lib/libstdc++.so.3 (0x4027e000)
libm.so.6 =3D> /lib/libm.so.6 (0x40315000)
/lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)
|
|
From: Vitor S. C. <vi...@bi...> - 2002-06-18 15:41:20
|
> i suggest keeping everything the way it is, and printing out the -? > message when an error is encountered. this way "yap -h" will write > s'thing like "error while parsing cmommand line" and then print the -? > message. i'll code it if you think it's a worth while compromise. > Yes, I think we should not break too much stuff before 4.4.0 (or 5.0?). Then we can reimplement the console using getopt. Cheers, Vitor |
|
From: Stasinos K. <kon...@le...> - 2002-06-18 10:12:26
|
Op Mon 17 Jun 2002 23:29:00 GMT zei Vitor Santos Costa: > > I think the -h option means "help: tell me about the allowed options" > > to almost anyone. Why not using -H for selecting the Heap size? > > Then for consistency we would have -S for Stack and -T for trail. > > It would also be a nice thing to support long options, > > in which case I would vote for --heap, --stack, and --trail. > > Just a suggestion, of course. > > I included -H, -S and -T. I agree -h for help makes sense, but it > would break programs. Anyone has any comments? i suggest keeping everything the way it is, and printing out the -? message when an error is encountered. this way "yap -h" will write s'thing like "error while parsing cmommand line" and then print the -? message. i'll code it if you think it's a worth while compromise. s |
|
From: Vitor S. C. <vi...@bi...> - 2002-06-18 06:04:04
|
> I have temporarily included your code into our YAP module (see near the end of > http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/Prolog/YAP/ppl_yap.cc?rev=1.31&content-type=text/x-cvsweb-markup > It seems that the external predicates are not behaving as expected. > I enclose under the signature the log of a gdb session. > Please let me know what should I do to help in identifying the > problem. Hi Roberto. First, are you using the very latest CVS version? I uploaded several changes. Just to be sure. If so, what is the OS/compiler you are using? > P.S. Very recently, a problem with the exception mechanism of GNU Prolog > was identified. Roughly speaking, to make things work both GNU Prolog > and foreign code have to be compiled with -fomit-frame-pointer, > or both of them have to be compiled without using that option. > Does this ring a bell? > Actually, I do the opposite: I always compile the interface with frame pointer active. Strange. Cheers, Vitor |
|
From: Roberto B. <ba...@cs...> - 2002-06-18 05:45:51
|
Vitor Santos Costa wrote: > Sorry for the delay. > > There were indeed problems when using YapRunGoal, as it was only > tested from the top-level. YapThrow and YapCallProlog seemed to be > working fine. > > This is a program I used for testing (I updated some changes to the > CVS version). Do you mind checking if it works for you? If it > doesn't, please tell me. If it does, then I think I'll need some more > info to track your bug. Dear Vitor, I have temporarily included your code into our YAP module (see near the end of http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/Prolog/YAP/ppl_yap.cc?rev=1.31&content-type=text/x-cvsweb-markup It seems that the external predicates are not behaving as expected. I enclose under the signature the log of a gdb session. Please let me know what should I do to help in identifying the problem. All the best Roberto P.S. Very recently, a problem with the exception mechanism of GNU Prolog was identified. Roughly speaking, to make things work both GNU Prolog and foreign code have to be compiled with -fomit-frame-pointer, or both of them have to be compiled without using that option. Does this ring a bell? -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:ba...@cs... $ gdb yap (gdb) r Starting program: /usr/local/bin/yap [ Restoring file startup ] [ YAP version Yap-4.3.22 ] ?- load_foreign_files(['ppl_yap'], [], init). yes ?- x(a). [ No handler for error f(hello,_96,a) ] ?- x2(a). no ?- ux(a). Program received signal SIGSEGV, Segmentation fault. 0x08051469 in StaticGetAPropHavingLock (ae=0x16911100, kind=65535) at Yatom.h:108 108 { (gdb) info stack #0 0x08051469 in StaticGetAPropHavingLock (ae=0x16911100, kind=65535) at Yatom.h:108 #1 0x080514b1 in GetAProp (a=0x16911100, kind=65535) at C/adtdefs.c:264 #2 0x0809af4d in writeTerm (t=135986733, p=1200, depth=1, rinfixarg=0) at C/write.c:446 #3 0x0809b853 in plwrite (t=135986733, mywrite=0x807ef10 <format_putc>, flags=4) at C/write.c:675 #4 0x08080a67 in format (tail=135986987, args=34, sno=2) at C/iopreds.c:4227 #5 0x08080f7a in p_format2 () at C/iopreds.c:4356 #6 0x080a602a in absmi (inp=0) at C/absmi.c:5719 #7 0x0806c9ec in exec_absmi (top=1) at C/exec.c:881 #8 0x0806cbf2 in do_goal (CodeAdr=0x80f2130 "", arity=0, pt=0x0, args_to_save=0, top=1) at C/exec.c:942 #9 0x0806d254 in RunTopGoal (t=214610) at C/exec.c:1128 #10 0x080504da in YapRunGoal (t=214610) at C/c_interface.c:704 #11 0x0804eb41 in do_top_goal (Goal=214610) at console/yap.c:122 #12 0x0804f2e1 in exec_top_level (BootMode=1, filename=0x0) at console/yap.c:457 #13 0x0804f35f in main (argc=1, argv=0xbffff994) at console/yap.c:483 #14 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/local/bin/yap [ Restoring file startup ] [ YAP version Yap-4.3.22 ] ?- load_foreign_files(['ppl_yap'], [], init). yes ?- g(X=2). no ?- g(fail). no ?- g(throw(a)). [ No handler for error a ] ?- h2(X=2). no ?- h2(fail). [ YAP version Yap-4.3.22 ] ?- h2(throw(a)). [ YAP version Yap-4.3.22 ] ?- Program exited normally. (gdb) q $ |
|
From: Vitor S. C. <vi...@bi...> - 2002-06-18 04:32:13
|
> I was too lazy to look at the documentation and I typed `yap -h' > thinking that yap would have given me a list of options. > Instead it segfaulted. I have tried to reproduce this under gdb > as follows: > > $ gdb /usr/local/bin/yap > (gdb) run -h > Starting program: /usr/local/bin/yap -h > [ YAP unrecoverable error: missing size in flag /usr/local/bin/yap ] > Program received signal SIGSEGV, Segmentation fault. > 0x0809e12a in ShutdownLoadForeign () at C/load_dl.c:112 > 112 > f_code = ForeignCodeLoaded; > (gdb) > OK, shame on me for keeping that one liner for so long. That has been fixed in CVS. > I think the -h option means "help: tell me about the allowed options" > to almost anyone. Why not using -H for selecting the Heap size? > Then for consistency we would have -S for Stack and -T for trail. > It would also be a nice thing to support long options, > in which case I would vote for --heap, --stack, and --trail. > Just a suggestion, of course. I included -H, -S and -T. I agree -h for help makes sense, but it would break programs. Anyone has any comments? > Keep up the good work > Thanks! Vitor |
|
From: Vitor S. C. <vi...@bi...> - 2002-06-18 02:56:19
|
Hi, The system is complaining because you are trying to do clause/2 for a conjunction. My guess is that this happens because your program unintentionally backtracked to the fourth clause. Where you have ebgnew(true,true,true). ebgnew(Goal,GenGoal,GenGoal) :- operational(GenGoal), call(Goal). ebgnew((Goal1,Goal2),(Gen1,Gen2),Cond):- ebgnew(Goal1,Gen1,Cond1), ebgnew(Goal2,Gen2,Cond2), and(Cond1,Cond2,Cond). ebgnew(Goal,GenGoal,Cond):- not operational(Goal), clause(GenGoal,GenBody), copy_term((GenGoal,GenBody),(Goal,Body)), ebgnew(Body,GenBody,Cond). you may want to try: ebgnew(true,true,true) :- !. ebgnew(Goal,GenGoal,GenGoal) :- operational(GenGoal), !, call(Goal). ebgnew((Goal1,Goal2),(Gen1,Gen2),Cond):- !, ebgnew(Goal1,Gen1,Cond1), ebgnew(Goal2,Gen2,Cond2), and(Cond1,Cond2,Cond). ebgnew(Goal,GenGoal,Cond):- % not operational(Goal), clause(GenGoal,GenBody), copy_term((GenGoal,GenBody),(Goal,Body)), ebgnew(Body,GenBody,Cond). If you don't like cuts, you may also try: ebgnew(Goal,GenGoal,Cond):- not operational2(Goal), clause(GenGoal,GenBody), copy_term((GenGoal,GenBody),(Goal,Body)), ebgnew(Body,GenBody,Cond). operational2(likesit(_,_)). operational2(needs(_,_)). operational2(sad(_)). operational2((_,_)). Good Luck! Vitor |
|
From: Vitor S. C. <vi...@bi...> - 2002-06-18 02:41:17
|
Hi Roberto,
>
>
> Hi Vitor,
>
> I have tried right now and still get a failure,
> but with a very different stack trace.
> Thanks a lot for your prompt responses
>
Sorry for the delay.
There were indeed problems when using YapRunGoal, as it was only
tested from the top-level. YapThrow and YapCallProlog seemed to be
working fine.
This is a program I used for testing (I updated some changes to the
CVS version). Do you mind checking if it works for you? If it
doesn't, please tell me. If it does, then I think I'll need some more
info to track your bug.
Cheers,
Vitor
PS: Yes, I know, the documentation is very bad :-(.
/*************************************************************************
* *
* YAP Prolog *
* *
* Yap Prolog was developed at NCCUP - Universidade do Porto *
* *
* Copyright L.Damas, V.S.Costa and Universidade do Porto 1985-1997 *
* *
**************************************************************************
* *
* File: x.c *
* Last rev: *
* mods: *
* comments: example of exception handling in C-interface *
* *
*************************************************************************/
#include "config.h"
#include "c_interface.h"
#include <math.h>
#if defined(__MINGW32__) || _MSC_VER
#include <windows.h>
#endif
void PROTO(init_x, (void));
/* Throw a simple exception
?- x(a).
*/
static int
p_x(void)
{
Term tf = YapMkAtomTerm(YapLookupAtom("hello"));
YapThrow(tf);
return(TRUE);
}
/* Throw a complex exception
?- x2(a).
*/
static int
p_x2(void)
{
Term tf, t[3];
Functor f = YapMkFunctor(YapLookupAtom("f"),3);
t[0] = YapMkAtomTerm(YapLookupAtom("hello"));
t[1] = YapMkVarTerm();
t[2] = ARG1;
tf = YapMkApplTerm(f,3,t);
YapThrow(tf);
return(TRUE);
}
/* Run a throw goal: exception is not thrown outside caller
?- ux(a).
*/
static int
p_ux(void)
{
Term tf, t[3];
Functor f1 = YapMkFunctor(YapLookupAtom("throw"),1);
Functor f2 = YapMkFunctor(YapLookupAtom("f"),3);
t[0] = YapMkAtomTerm(YapLookupAtom("hello"));
t[1] = YapMkVarTerm();
t[2] = ARG1;
tf = YapMkApplTerm(f2,3,t);
t[0] = tf;
tf = YapMkApplTerm(f1,1,t);
return(YapCallProlog(tf));
}
/* Run goal as argument
?- g(X=2).
;
?- g(fail).
?- g(throw(a)).
*/
static int
p_g(void)
{
return(YapCallProlog(ARG1));
}
/* Run goal as argument and check for exceptions. Do a throw if so.
?- g2(X=2).
;
?- g2(fail).
?- g2(throw(a)).
*/
static int
p_g2(void)
{
Term ex;
int out = YapCallProlog(ARG1);
if (YapGoalHasException(&ex)) {
YapThrow(ex);
return(FALSE);
}
return(out);
}
/*
Use YapRunGoal, as it keeps the choice-point stack. Notice that we need
to do prunegoal before we exit
*/
static int
p_h(void)
{
int out = YapRunGoal(ARG1);
if (out) {
YapPruneGoal();
}
return(out);
}
/*
same and also check for exceptions.
?- h2(X=2).
;
?- h2(fail).
?- h2(throw(a)).
*/
static int
p_h2(void)
{
Term ex;
int out = YapRunGoal(ARG1);
if (out) {
YapPruneGoal();
}
if (YapGoalHasException(&ex)) {
YapThrow(ex);
return(FALSE);
}
return(out);
}
void
init_x(void)
{
UserCPredicate("x", p_x, 0);
UserCPredicate("x", p_x2, 1);
UserCPredicate("ux", p_ux, 1);
UserCPredicate("g", p_g, 1);
UserCPredicate("g2", p_g2, 1);
UserCPredicate("h", p_h, 1);
UserCPredicate("h2", p_h2, 1);
}
#ifdef _WIN32
int WINAPI PROTO(win_x, (HANDLE, DWORD, LPVOID));
int WINAPI win_x(HANDLE hinst, DWORD reason, LPVOID reserved)
{
switch (reason)
{
case DLL_PROCESS_ATTACH:
break;
case DLL_PROCESS_DETACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
}
return 1;
}
#endif
|
|
From: Roberto B. <ba...@cs...> - 2002-06-17 20:57:40
|
I was too lazy to look at the documentation and I typed `yap -h'
thinking that yap would have given me a list of options.
Instead it segfaulted. I have tried to reproduce this under gdb
as follows:
$ gdb /usr/local/bin/yap
(gdb) run -h
Starting program: /usr/local/bin/yap -h
[ YAP unrecoverable error: missing size in flag /usr/local/bin/yap ]
Program received signal SIGSEGV, Segmentation fault.
0x0809e12a in ShutdownLoadForeign () at C/load_dl.c:112
112
f_code = ForeignCodeLoaded;
(gdb)
I think the -h option means "help: tell me about the allowed options"
to almost anyone. Why not using -H for selecting the Heap size?
Then for consistency we would have -S for Stack and -T for trail.
It would also be a nice thing to support long options,
in which case I would vote for --heap, --stack, and --trail.
Just a suggestion, of course.
Keep up the good work
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:ba...@cs...
|