注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

about blank

PEM`s Enhanced Memories

 
 
 

日志

 
 

LISP-C-Python  

2009-07-16 23:13:15|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
irc上看到有人聊C和Python,顺便更新blog。

[22:10] <matimago> Zhivago: there's also a good reason why to rewrite a library in CL instead of C.  It is that of program verification/certification.  It would be easier to verify automatically a lisp program than a C program.  (But even without a formal automatic verification, I'd feel safer with a CL library, knowing that there are less bugs and foremost, less run-time crash possibility in CL than in C).
[22:11] <Zhivago> matimago: And people wonder why python and ruby are popular languages :)
[22:11] <matimago> Zhivago: have you tried to write a CFFI interface to a C library?
[22:11] <matimago> How many times did you crash your image because of that C library?
[22:11] <Zhivago> Um, not at all?
[22:11] <Xach> aerique: that seems quite convoluted. pkhuong suggested just (define-alien-variable dynamic-space-size unsigned-long)
[22:12] <Zhivago> To be honest, I don't really have problems talking to C code.
[22:12] <Xach> aerique: oh, sorry! that's the same thing
[22:12] <Zhivago> I guess this is a special trait that python programmers must also have.
[22:13] <matimago> It's not the talking to C code the problem. It's that C code is much less amenable to interactive and exploratory use, because when you make a mistake in the calling sequence, C code can easily overide anything in memory rather than just signal a condition.
[22:13] <matimago> Perhaps python crashes as much as its C libraries, or perhaps they run their C libraries in a forked child?
[22:13] <Zhivago> And that's why you don't use C code for exploratory use.
[22:14] <Zhivago> matimago: Ah, you are completely ignorant of it.
[22:14] <matimago> Of python, yes.
[22:14] <matimago> I only know about the significant indent.
[22:14] <Zhivago> matimago: No. They call C code directly. They don't have significant problems.
[22:14] <p_l> matimago: the core is implemented in C, and their FFI is done the other way around - you write it in C calling CPython's API
[22:14] <matimago> How do they deal with memory corruption then?
[22:14] <aerique> Xach: yes, nevermind the problem seems to be me but I haven't quite figured it out yet
[22:15] --> willb has joined this channel (n=wibenton@compsci-wifi-39.cs.wisc.edu).
[22:15] <Zhivago> In some regards, python has the benefit of having filthy, practical developers rather than people waffling on about code verification techniques that they'll never actually use.
[22:16] <p_l> matimago: by carefully writing C FFI. You don't do "exploratory" FFI coding in CPython or Ruby
[22:16] <p_l> at least there's PyRex, it made writing FFI much easier
[22:16] <Zhivago> pl: There's also that inline C++ thingy.
[22:18] <matimago> How do they prevent you to pass a pointer to an object of class A to a C function expecting a pointer to an "object" of class B in python?  Is their FFI strongly typed?  CFFI is not typed.
[22:19] <matimago> That'd be a defect of CFFI, clisp FFI is better in this respect.
[22:19] <p_l> Zhivago: that's probably PyRex you are talking about :)
[22:20] <aerique> CFFI seems to be using SBCLs default dynamic space size instead of the one I'm supplying
[22:20] <p_l> matimago: you have only C's type system. CPython's FFI is pure C (with possible generation through various tools)
[22:20] <Zhivago> p_l: No. I think this was called CWeave or something like that -- it was actual C++ code inline in python.
[22:21] <p_l> Zhivago: PyRex looks similar - you have Python-like statements/code with bits of direct, inline C. Then you run PyRex on it and you get _modulename.so and modulename.py
[22:21] <aerique> You can sorta inline C++ code in ECL as well. Let me find the mailinglist post.
[22:21] <Zhivago> http://www.scipy.org/Weave <- there.
[22:21] <matimago> p_l: So the C programmer must check the python object type and signal an error to python.
[22:22] <p_l> matimago: kind of. Don't remember details
[22:25] <aerique> christ, sourceforge.. nevermind
[22:25] <p_l> matimago: http://docs.python.org/c-api/arg.html
[22:39] <TDT> The FFI (CFFI) just allows lisp to call C libraries directly, right?
[22:39] <TDT> Trying to see if I understand what it is doing correctly.
[22:45] <matimago> TDT: correct.
[22:45] <matimago> TDT: only that a direct call is rarely possible, given the differences in ABI and data types.
[22:46] <TDT> matimago: Yeah, that makes sense.  I wish there were easy ways to call python libraries from within lisp..my life would be so much easier, heh
[22:46] <matimago> TDT: eg. a fixnum such as 42 is encoded as 0x000000A8 in Lisp, while it's encoded as 0x0000002A in C.
[22:47] <rsynnott> TDT: well, you COULD write a little C layer to link the two :)
[22:47] <nyef> Why would a C layer be needed?
[22:47] <matimago> TDT: Well we could provide the CPython FFI API to be compatible with all the python FFI libraries...
[22:47] <rsynnott> oh, actually, I suppose you could do it directly, yep
[22:47] <matimago> Or it could be implemented as CFFI callbacks :-0
[22:48] <nyef> Now I'm getting a minor headache contemplating alien-metaobject-protocols.
[22:48] <TDT> matimago: heh, I think a lot of htis stuff is over my head..I need to read some programs that use the cffi I think to understand this a bit, heh.
[22:48] <matimago> Yes, we'd have to provide and get back python objects instead of C objects :-0
[22:48] <matimago> Grr, this Shift is broken?!
[22:48] <Xach> here are some parens to cut and paste: (((())))
[22:49] <matimago> Thanks.
[22:52] <lnostdal> isn't python very eval-friendly? .. lisp <--socket--> python doing eval with stuff received ..   *shrug*
[22:53] <Xach> at ILC, Duane Rettig and <mumble> presented on a marriage of python to Allegro CL.
[22:53] <Xach> showing interactive use of the Allegro debugger on python source
[22:54] <Xach> http://www.international-lisp-conference.org/2009/tutorials#debug
[22:54] <Xach> Willem Broekma was the other fellow
[22:54] <mrSpec> Do you know why when I'm trying to use (drakma:http-request ... ) in Slime I got "Lisp connection closed unexpectedly: connection broken by remote peer" ? In SBCL all is working fine :S
[22:54] <Xach> mrSpec: perhaps it is returning a character that can't be encoded over your slime connection
[22:55] <mrSpec> hmm what can I do with it?
[22:55] <rsynnott> mrSpec: you should be able to tell slime to use utf-8
[22:55] <Xach> mrSpec: i set slime-net-coding-system to utf-8-unix
[22:55] <mrSpec> ok I'll set it, thankx
[23:03] <artagnon> SBCL is neither a compiler or an interpreter, right? And it isn't a virtual machine either? Then what is it?
[23:03] <aerique> I'm running into a maximum with the amount of foreign memory that SBCL wants to allocate with make-alien even though I've increased its dynamic size on the command line.
[23:04] <mrSpec> I told slime to use utf and now all is working fine :D
[23:05] <aerique> I'm not even sure I need to increase its dynamic size on the command line, I realize now.
[23:05] <luis> artagnon: make-alien calls malloc(), that is not related to the dynamic space.
[23:05] <aerique> right :)
[23:05] <luis> s/artagnon/aerique
[23:05] <pkhuong> aerique: if anything, increasing the dynamic space size will reduce the amount of mallocable memory.
[23:05] <beach> artagnon: Who told you SBCL is neither a compiler nor an interpreter?
[23:06] <luis> artagnon: SBCL is both a compiler and an interpreter, actually.
[23:06] <aerique> luis: Am I out of luck and should I find a way around it (allocating smaller segments)
[23:06] <pkhuong> artagnon: It's a program that includes an interpreter, a compiler and a lot of library functions.
[23:06] <artagnon> beach: well, I guess it's both then.
  评论这张
 
阅读(1167)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018