- cffi-devel - mailman3.common-lisp.net

[cffi-devel] Can you afford to lose 300.000 potential customers per year!?
by instant＠common-lisp.net 05 May '07

05 May '07

1 0

[cffi-devel] Feed Blaster puts your ad right to the screens of millions in 15 Minutes !
by Feed＠common-lisp.net 03 May '07

03 May '07

1 0

[cffi-devel] cffi-sys::default-encoding returns nil on clisp/mingw
by Jack Unrue 01 May '07

01 May '07

Running CLISP on my system with the newtypes branch, I find that the CFFI-SYS::DEFAULT-ENCODING function is returning NIL. Some poking around reveals that CUSTOM:*FOREIGN-ENCODING* is set to #<ENCODING CHARSET:CP1252 :DOS> I looked at the symbol values for everything in the :charset package, and they all specify :UNIX instead of :DOS and so that's what CFFI-SYS::*ENCODINGS* and CFFI-SYS::*CLISP-ENCODINGS* get populated with. So I can see why DEFAULT-ENCODING is returning NIL. Before I head over to clisp-devel and ask about this, I just wanted to see whether this situation surprises anyone here, or if you think it might be a CLISP build configuration issue (which would be funny because I'm one of the MingW package maintainers), or ??? For instance, can anyone point me at a spot in the CLISP manual that states that *FOREIGN-ENCODING* will always correspond to the value of one of the symbols in the :charset package? This is on WinXP SP2, CLISP 2.41 (mingw special) with nothing related to encoding for command-line arguments. -- Jack Unrue

3 4

[cffi-devel] How would you like unlimited hits to your website 15 minutes from now!?
by Hit＠common-lisp.net 30 Apr '07

30 Apr '07

1 0

[cffi-devel] E- MAIL TICKET NUMBER 2996005600546772 YOU ARE A WINNER!!!
by Wilfred＠common-lisp.net 24 Apr '07

24 Apr '07

INTERNATIONAL PROMOTION/PRIZE AWARD DEPT. CALLE GRANVIA 32N 1C MADRID SPAIN REF: RSSL/61-ILGI0509/45 BATCH:RSSL/15/096/WRCS DATE:4/24/2007 Dear winner, AWARD NOTIFICATION FINAL NOTICE This is to inform you of the release of the Royal Spainish Sweepstake Lottery Email Promotional Program held on the 12st April 2007, this result was initially delayed due to mix up of email addresses, the results were finally released on the 20 April 2007, and your e-mail attached to.Ticket number: 2996005600546 772 with Serial number: 4888/02,which drew the Lucky numbers: 41-6-76-13-45-8, which consequently won the lottery in the Second category of the year 2006. You are therefore approved. for a lump sum payout of 1,000,000.00 (ONE MILLION EUROS ONLY) in cash accredited to file reference number: KPC/9080333308/03 this is from a total cash prize of 19,000,000.00 (NINTEEN MILLION EUROS ONLY) Shared among the nineteen international winners in this category. Your fund is now deposited in a security company with your prize money insured in your e-mail.Due to mix up of some email addresses, we ask that you keep this award from public notice until your claim has been processed and money remitted to your account as this is part of our security protocol to avoid double claiming or unwarranted abuse of this program by participants as it has happened in the past. Allparticipants were selected randomly from World Wide Web site through computer drawsystem and extracted from over 100,000 companies,this promotion takesplace annually.We hope your lucky email address will draw a bigger cash prize in the next high stake promotion agenda of 30,000,000.00 (THIRTY MILLION EUROS) ********************************************************** To begin your lottery claim, please contact your claim agent, AGRO CONSULTANCY AND SECURITIES S.L. MADRID SPAIN DR.RICHARD ANTONIO Remittance/foreign operations manager) Tel:+34-619-693-930 Email:agroyacom@yahoo.es ********************************************************** For due processing and remittance of your winning prize money to designated account of your choice. Remember, all prize money must be claimed.(not later than 30st April 2007 After this date, this fund will bereturned to the MINISTERIO DE ECONOMIA Y HACIENDA as unclaimed fund. NOTE: In order to avoid unnecessary delay and complication, please remember to quote your reference and batch numbers in everycorrespondence with your agent or us. Furthermore, should there be any change of your contact email address, do inform your claim agent as soon as possible. Congratulation once again from all members of our staff and thank you for being part of our International promotion program. We wish you continued good fortunes. Yours Sincerely Wilfred Alberto (Lottery Director

1 0

[cffi-devel] [SPAM] FROM: MR. MIKE EDWARD
by FROM＠common-lisp.net 23 Apr '07

23 Apr '07

Spam detection software, running on the system "clnet", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: FROM: MR. MIKE EDWARD MANAGER; PRUDENTIAL INSURANCE COMPANY. REPLY TO MY ALTERNATIVE EMAIL ADDRESS: MRMIKEEDWARD(a)O2.PL MY DEAR FRIEND, I FEEL QUITE SAFE DEALING WITH YOU IN THIS MUTUAL BENEFICIAL TRANSACTION.THOUGH, THIS MEDIUM (INTERNET) HAS BEEN GREATLY ABUSED, I CHOOSE TO REACH YOU THROUGH IT BECAUSE IT STILL REMAINS THE FASTEST, SUREST AND MOST SECURED MEDIUM OF COMMUNICATION. HOWEVER, THIS CORRESPONDENCE IS PURELY PRIVATE,AND IT SHOULD BE TREATED AS SUCH. I ALSO GUARANTEE YOU THAT THIS DEAL IS HITCH FREE FROM ALL WHAT YOU MAY THINK OF. I AM MR. MIKE EDWARD, MANAGER IN CHARGE OF CLAIMS AND INDEMNITY OF PRUDENTIAL INSURANCE COMPANY. I AM CONTACTING YOU BASED ON TRUST AND CONFIDENTIALITY THAT WILL BE ATTACHED TO THIS DEAL FOR THE BENEFIT OF BOTH OF US. THE MANAGEMENT AND THE LEGAL / TREASURY DEPARTMENT OF THIS PRUDENTIAL INSURANCE COMPANY IN A RECENT MEETING, RECOMMENDED THAT THE ACCOUNT OF MR. ROBERT FINKELSTEIN,WHO MAINTAINED A LIFE ASSURANCE POLICY, SHOULD BE DECLARED DORMANT AND CONFISTICATED HENCE MOVING HIS UNCLAIMED BENEFITS FUNDS TO THE TREASURY ACCORDING TO OUR BANKING AND FINANCIAL LAW. RECENTLY, I CAME ACROSS A VERY HUGE SUM OF MONEY BELONGING TO A DECEASED PERSON (MR. ROBERT FINKELSTEIN). HE IS FOREIGNER,UNFORTUNATELY HE IS NOW LATE AS HE WAS AMONGST THOSE THAT WAS KILLED IN THE RECENT PLANE CRASH AS YOU CAN CONFIRM THROUGH THIS WEBSITE HTTP://NEWS.BBC.CO.UK/1/HI/WORLD/EUROPE/859479.STM THIS MAN WAS OUR CLIENT AND HAS A LIFE ASSURANCE POLICY WORTH THE SUM OF FORTY FIVE MILLION UNITED STATES DOLLARS (US$45,000,000.00). RIGHT NOW, THE FUND IS LYING UNCLAIMED IN OUR CUSTODY AND THERE IS NO NEXT OF KIN MENTIONED IN HIS FILE AND THERE IS NO HOW WE CAN REACH ANY OF HIS OTHER RELATIVES. ALL EFFORTS MADE BY US TO ESTABLISH CONTACTS WITH ANY OTHER OF HIS RELATION HAS PROVED ABORTIVE AND UNSUCCESSFUL. HIS LIFE ASSURANCE POLICY WILL EXPIRE IN THE NEXT FEW MONTHS FROM THE DATE OF THIS LETTER. JUST LAST WEEK WE RECEIVED AN INSTRUCTION FROM MINISTRY OF SOCIAL WELFARE TO FORWARD PARTICULARS OF ALL UNCLAIMED BENEFI [...] Content analysis details: (13.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 MSGID_NO_HOST Message-Id has no hostname 0.7 SUBJ_ALL_CAPS Subject is all capitals 2.8 MILLION_USD BODY: Talks about millions of dollars 2.6 NA_DOLLARS BODY: Talks about a million North American dollars 0.4 US_DOLLARS_3 BODY: Mentions millions of $ ($NN,NNN,NNN.NN) 0.0 HTML_MESSAGE BODY: HTML included in message 1.1 HTML_00_10 BODY: Message is 0% to 10% HTML 0.2 MIME_HTML_ONLY BODY: Message only has text/html MIME parts -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.1 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag 0.0 UPPERCASE_75_100 message body is 75-100% uppercase 0.6 NIGERIAN_BODY2 Message body looks like a Nigerian spam message 2+ 3.4 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+ 1.1 INVALID_MSGID Message-Id is not valid, according to RFC 2822 2.7 NIGERIAN_BODY4 Message body looks like a Nigerian spam message 4+ 0.1 NIGERIAN_BODY3 Message body looks like a Nigerian spam message 3+ The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

1 0

[cffi-devel] Patch that adds an example of arrays to the documentation of defcstruct
by Ignas Mikalajunas 17 Apr '07

17 Apr '07

Hi, some users are not very attentive when reading documentation and rely on examples so i just though that it would be useful to have an example of an array defined as a member of a c struct in the manual. Ignas

2 1

[cffi-devel] Road to 0.9.3 (and encoding issues)
by Luis Oliveira 17 Apr '07

17 Apr '07

Hello, The cffi-newtypes branch[1] is getting huge (~30 patches), and since it seems nobody has complained much about the new type system, I'd like to push it into the main branch along with the encoding support and other minor features and bugfixes that have accumulated over last ~2 months. Any objections? Then, after some remaining issues are fixed, I'd like to release 0.9.3. So here's my TODO list for 0.9.3: - <http://article.gmane.org/gmane.lisp.cffi.devel/1033> Figure out whether any of those issues are critical. The only change I've made to the typesystem since I wrote that message was a new :class option to DEFSTRUCT; - iron out some issues with the new encoding support (see below, this might take a while); - finish the documentation of the new features; - integrate cffi-grovel into the CFFI tree and document it. There are some issues with the current encoding support though: - James' original code had a CFFI-SYS:DEFAULT-ENCODING function which would use some implemention-specific way of determining what the default encoding should be. Every implementation had a different way of determining that, so I though that simply picking one ourselves (say, :utf-8) would be better. Also, I changed that to be a special variable instead. That way *DEFAULT-FOREIGN-ENCODING* can be bound to something else and affect the behaviour of the :string type and other string operations that don't explicitely specify an encoding. (E.g., the behaviour of :STRING would be influenced at run-time by the value of *D-F-E* whereas (:STRING :ENCODING :UTF-8) would not.) - Allegro's %lisp-string-into-foreign overflows. Allegro's EXCL:STRING-TO-NATIVE doesn't take a bufsize argument. Another problem is that Allegro's %lisp-string-octet-length isn't very effective otherwise it'd be easier to check for an overflow. Anyway, this is not the worst issue. - Corman, SCL and ECL support is broken, not necessarily because of the new string stuff. Also, a recent 1.1 snapshot of OpenMCL with unicode support is necessary; is this a problem? Last but definitely not least, there's a huge problem with error semantics. Everything works fine until you try to, e.g. convert a #\λ into iso-8859-1. Or #\ç into ascii. Some Lisps treat ascii as a synonym for iso-8859-1. Some silently substitute inconvertible characters with #\? (or #\Sub) while others will raise an exception. Of those that do raise exceptions, some provide a use-value substitution restart, others don't. To sum it up, it's horribly inconsistent. Before forward porting James's cffi-encondings branch, we discussed the possibility of doing the enconding conversion in portable CL, like what flexi-streams does for instance. I'm beginning to reconsider this idea. One the one hand it would mean introducing a dependency for CFFI, on the other hand it would provide consistent semantics across the various Lisps (including useful semantics for lisps that don't support unicode) we support and simplify CFFI-SYS. Any thoughts? [1] http://common-lisp.net/~loliveira/darcs/cffi-newtypes/ -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0

[cffi-devel] problem "asdf:loading" cffi
by Jonathan Johansen 16 Apr '07

16 Apr '07

Hi All, I'm trying to compile the current version of CFFI (0.9.2) in Clisp (2.39) on Ubuntu with asdf. I entered: (asdf:oos 'asdf:load-op :cffi) It then proceeded to load cffi.asd with no problems, and loads utils.fas, features.fas and cffi-clisp.fas without problems, and then complains in the following way: *** - READ: input stream #<INPUT BUFFERED FILE-STREAM CHARACTER #P"/var/cache/common-lisp-controller/1000/clisp/local/home/jon/code/ systems/cffi_0.9.2/src/package.fas" @1> has reached its end Does anyone know why this happens? (If I should go ask this question on the clisp or asdf mailing list, I welcome your directions :). Yes, I'm a newbie. If more information is needed, I'm happy to oblige. Regards, Jonathan Johansen framlingham(at)gmail(dot)com

2 1

[cffi-devel] translate-type-from-foreign
by Sean 15 Apr '07

15 Apr '07

Hi all, I've noticed that in the upgrade from cffi 0.9.1 to 0.9.2 that there were a few lines removed from early-types.lisp namely : -;; Default Translators for foreign-struct-type -(defmethod translate-type-from-foreign (value (type foreign-struct-type)) - (translate-from-foreign value (name type))) - -(defmethod translate-type-to-foreign (value (type foreign-struct-type)) - (translate-to-foreign value (name type))) I've been specialising translate-to-foreign to automatically convert c structures to their equivalent lisp counterparts but without these lines this obviously no longer works. Was this removal deliberate and if so what is the preferred way to accomplish this? Cheers, Sean. -- ...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list. Kent Pitman.

2 3