00:00:26 _danb_ [~user@124-168-128-117.dyn.iinet.net.au] has joined #lisp 00:02:01 -!- Paraselene_ [~Not@81-178-167-119.dsl.pipex.com] has quit [Disconnected by services] 00:02:04 Paraselene [~Not@81-178-167-119.dsl.pipex.com] has joined #lisp 00:04:08 -!- bizarrefish [~lee@host86-146-53-214.range86-146.btcentralplus.com] has quit [Ping timeout: 260 seconds] 00:05:16 -!- mrSpec [~Spec@unaffiliated/mrspec] has quit [Quit: ZZzzzzZzzzz...] 00:06:00 bizarrefish [~lee@host86-146-53-214.range86-146.btcentralplus.com] has joined #lisp 00:07:35 delYsid` [~user@chello084115136207.3.graz.surfer.at] has joined #lisp 00:07:38 -!- delYsid [~user@chello084115136207.3.graz.surfer.at] has quit [Remote host closed the connection] 00:09:01 hohoho [~hohoho@ntkngw227224.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #lisp 00:10:01 -!- slyrus_ [~slyrus@dsl092-019-253.sfo1.dsl.speakeasy.net] has quit [Ping timeout: 265 seconds] 00:15:07 smanek [~smanek@cpe-98-14-140-77.nyc.res.rr.com] has joined #lisp 00:22:38 mbohun [~mbohun@202.124.72.110] has joined #lisp 00:22:40 OmniMancer [~OmniMance@202.36.179.65] has joined #lisp 00:24:15 -!- gigamonkey [~user@adsl-99-24-216-122.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 240 seconds] 00:25:03 -!- hohoho [~hohoho@ntkngw227224.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Remote host closed the connection] 00:27:09 -!- fisxoj [~fisxoj@HSI-KBW-095-208-108-231.hsi5.kabel-badenwuerttemberg.de] has quit [Ping timeout: 276 seconds] 00:29:16 peddie_ [~peddie@c-67-160-245-238.hsd1.ca.comcast.net] has joined #lisp 00:32:01 -!- xan_ [~xan@83.32.114.158] has quit [Ping timeout: 276 seconds] 00:32:13 -!- peddie [~peddie@c-67-169-8-208.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds] 00:32:46 derekv [qyq1qbnvug@c-68-62-78-203.hsd1.mi.comcast.net] has joined #lisp 00:35:55 -!- toxygen [toxygen@stip-static-98.213-81-186.telecom.sk] has quit [Ping timeout: 248 seconds] 00:36:45 -!- aw [~aw@port-92-195-41-185.dynamic.qsc.de] has quit [Quit: WeeChat 0.3.3-dev] 00:37:34 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Ping timeout: 265 seconds] 00:45:14 cxml is not playing nice with asdf, asdf:defsystem looks as if it type checks its arguments and not what they resolve to. cxml.asd supplies an expression as an argument. 00:45:25 pdelgallego [~pdelgalle@42.Red-217-125-2.staticIP.rima-tde.net] has joined #lisp 00:48:47 -!- TeMPOraL [~user@178.182.162.253.nat.umts.dynamic.eranet.pl] has quit [Quit: (global-set-mode 'sleep)] 00:48:48 -!- peddie_ [~peddie@c-67-160-245-238.hsd1.ca.comcast.net] has quit [Quit: peace!] 00:48:53 loading cxml fails on clisp sbcl and cmucl, there is a cxml mailing list bug query as yet unresolved, 00:49:41 Is this a bug, and if so is it a asdf or cxml bug? 00:50:02 cisticola: i find that hard to believe... i've never had problems with loading cxml, so unless this is very new (say within the last few days), i suspect something else is amiss. 00:50:04 billstclair [~billstcla@unaffiliated/billstclair] has joined #lisp 00:51:58 mathrick: looks like a good start :) 00:52:58 mathrick: at least, it's an important step. If ecl would be able to compile applications for android, then we'd have the ingredients, no? 00:52:59 madnificent: aye, hopefully I can get make into a useful devel environment 00:53:00 cisticola: and by way of confirmation, i have no problem loading the latest cxml (as of right now) into the latest (as of a few hours ago) sbcl 00:53:28 mathrick: I'd be glad to test and help where possible (and when I have the time) 00:53:44 madnificent: yeah, though not really applications. You want to stay within the confines of the JVM if your apps are to be well-behaved on android 00:54:04 mathrick: what are you trying to say? 00:54:04 madnificent: sure, that'll come in its time :) 00:54:10 the mailing list query, not by me, was 22may. I first tried loading cxml about the same time. 00:54:24 madnificent: that you'd be compiling JNI components rather than standalone applications 00:55:22 mathrick: and what are the implications of that? the JNI components can call back to java code, so if our/your system would be smart enough to know what it should make accessible to JNI, then you'd be able to control everything from within CL 00:56:14 madnificent: yes, that's my hope too. But what I'm saying is that it needs more smarts on the DSL level, because it needs to be partitioned into components corresponding to all necessary activities 00:56:18 mathrick: and exposing the correct components boils down to building the correct java code (for which you're building the important parts right now) 00:56:30 cisticola: it works with the latest and greatest, it looks like the bug report is someone trying to do it via debian packages... never a good idea 00:56:36 mathrick: ah yes, I understand you now 00:56:46 cisticola: are you on debian using debian packaged libraries? 00:56:47 mathrick: that could be something cool de develop though :) 00:57:10 and/or sbcl 00:57:27 madnificent: my pipe dream is to make it cross-platform, putting even more weight on the DSL. But we'll see how it goes 00:57:39 sellout [~greg@c-24-128-48-180.hsd1.ma.comcast.net] has joined #lisp 00:57:40 yes cmucl and clisp 00:58:12 mathrick: how cross-platform? over multiple types of phone os? 00:58:20 -!- enthymeme [~kraken@130.166.209.32] has quit [Quit: rcirc on GNU Emacs 23.1.1] 00:58:32 but asdf and cxml is not 00:58:36 cisticola: don't use debian packages for lisp related things and you won't run into such problems. Otherwise, take it up with the package mantainer, as it works 'in the wild' 00:59:23 madnificent: yes 00:59:32 minion: tell cisticola about clbuild 00:59:33 cisticola: please look at clbuild: clbuild is a shell script helping with the download, compilation, and invocation of Common Lisp applications. http://www.cliki.net/clbuild 00:59:41 madnificent: being able to target android, pre and S60 would be nice 00:59:47 -!- silenius [~silenius@rrcs-64-183-24-50.west.biz.rr.com] has quit [Quit: Leaving] 00:59:52 cisticola: use your debian-installed sbcl to build sbcl via clbuild, forget about cmucl and clisp 01:00:09 skeledrew [~skeledrew@0088-174-27-72-DYNAMIC-dsl.cwjamaica.com] has joined #lisp 01:00:12 mathrick: it sounds hard, but I think mvilleneuve was thinking about something similar (if not, I'll need to dig in the logs of #lispgames) 01:00:17 -!- Fullma [~fullma@ram94-2-82-66-69-246.fbx.proxad.net] has quit [Ping timeout: 265 seconds] 01:01:13 drewc: OK, got you, clbuild will be investigated 01:01:35 <_3b`> is that one of the things that changed in asdf2 (and are you using that?) 01:01:44 Fullma [~fullma@ram94-2-82-66-69-246.fbx.proxad.net] has joined #lisp 01:02:04 madnificent: oh? More info is needed 01:03:11 _3b`: ARRGGGHHH never noticed I will look at that as well, thanks 01:04:03 <_3b`> if you are using asdf2, that might be the problem 01:04:03 mathrick: don't take the following for granted, I'm not an elephant: I don't think he started on it yet, and it wasn't going to be open (perhaps if it'd be a joint venture, it would be open) and it wasn't initially going to be common lisp 01:05:35 <_3b`> cisticola: does (asdf:asdf-version) work? 01:06:10 madnificent: I see. Well, I dunno how exactly what I'm doing is gonna work, but I think I'll want to make it open for greater good, even though I want to make commercial apps too 01:06:53 -!- netytan [~netytan@85.211.16.208] has quit [Quit: netytan] 01:07:17 mathrick: I don't think webos works the same way as android does 01:07:41 I know, hence my mentions of a DSL to even things out 01:07:48 mathrick: however, with a decent core, it would be fairly simple to port applications between the several versions. WebOS has an NDK too (it's called differently there) and webos is fairly hackable 01:07:57 webos is JS + HTML, which is covered by parenscript 01:08:33 *madnificent* still wants a pre (not nice of palm to leave us out for so long) 01:08:43 <_3b`> drewc: just to verify, you aren't using the new asdf/asdf2 to load cxml, right? 01:08:47 mathrick: you'd really want to have common lisp instead of parenscript 01:08:47 -!- sellout [~greg@c-24-128-48-180.hsd1.ma.comcast.net] has quit [Quit: sellout] 01:09:01 mathrick: but the javascript part can probably be what you do in java now 01:10:07 madnificent: parenscript is much more similar to CL than LinJ, which makes it easier 01:11:18 mathrick: wouldn't you want LinJ out of the picture (for the user of the system) in the end? 01:12:00 _3b`: ah, indeed i am not. using whatever asdf is included with SBCL AFAIK 01:12:24 well, yes. But what I meant is also that it'd be much more doable to make parenscript the language you write in, because there's not as much pressure to get it out of the way 01:12:40 -!- Yuuhi [benni@p5483B9F3.dip.t-dialin.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 01:12:49 ignas [~ignas@ctv-79-132-160-221.vinita.lt] has joined #lisp 01:13:23 -!- pizzledizzle [~pizdets@pool-96-250-215-244.nycmny.fios.verizon.net] has quit [Ping timeout: 272 seconds] 01:13:59 _3b`: yes it does, I am on 1.728 which is asdf2 01:15:02 <_3b`> cisticola: try putting #+asdf2 "xml/" #-asdf2 before that(merge-pathnames ... 01:15:27 madnificent: the drawbacks are not as significant, since you wouldn't be using a million CFFI-calling libs on a mobile handset anyway 01:16:37 _3B` OK but its going to be on cmucl because I broke sbcl 01:16:53 *_3b`* assumes the implementation doesn't matter for that 01:16:53 mathrick: somewhat, yes... I find parenscript to sound like a great approach, but whenever I use it, it makes me a bit sad. 01:17:03 madnificent: so with a little care, you could probably compile everything down 01:17:08 madnificent: why so? 01:17:08 mathrick: it just isn't lisp. You still have to think about how it will expand, not what you want to write. 01:17:32 well, yeah, but that's the life of a foreigner 01:17:41 mathrick: the best option for parenscript imho, is to write a lisp that would compile to/run in javascript 01:17:49 madnificent, It becomes easier 01:18:06 madnificent: that's what parenscript is. A lisp that compiles to JS 01:18:10 Guthur: it becomes easier, but you're still thinking in two languages... they only look the same for a large portion 01:18:18 I'm generally creating correctly expanding PS now more often than not. 01:18:20 *_3b`* would like a full lisp that compiled to js, or a thin sexp js... ps is currently too much in the middle, so has the weaknesses of both 01:18:21 one very close to CL, too 01:18:23 Guthur: I'm not claiming that parenscript isn't a great thing to have though! 01:18:45 The PS guys are actively developing it 01:19:03 <_3b`> mathrick: not close enough (though i understand that is the goal, so presumably it will get better) 01:19:04 mathrick: I had a design document for that laying around somewhere (real writing on real paper though) 01:19:20 And from the mailing list there seems to soundings of moving more towards what _3b` mentioned of a PS compiling to JS 01:19:25 Guthur: another thing! ps changes quite often. It's good that it evolves though.. 01:19:27 *_3b`* wonders what happened to that guy who did a CL-in-js for school 01:19:35 And the PS being more CL like 01:19:45 ps is just a tough nut to crack imho. It isn't CL, and if I'd need to do a lot of stuff, I'd prefer CL. 01:19:48 madnificent: for a CL on JS implementation? 01:19:53 _3b`: any name, maybe? 01:20:13 mathrick: in a longer sentence that question would become, what? 01:20:44 madnificent: the design documents you have, what are they for? 01:21:10 -!- pemryan [~pem@2001:cc0:201e:107:221:86ff:fe1a:e5aa] has left #lisp 01:21:41 mathrick: ah, for CL within JS. In short: you have a small core that evals, a small core that allows to call native JS functions, and a system to fetch lisp components from the server. In that way you don't make the browser first load 5Mb of source JS before the site can start running. 01:22:13 mathrick: it would also allow for libs to be cached on the client's side 01:22:37 but it would require a CL to be written mainly in CL... which is a lot of work I guess 01:22:42 the whole thing would be a lot of work anyways 01:23:11 madnificent: hmm, what about compiling down to JS, rather than running in JS? 01:23:24 aka more ECL style than ABCL style 01:24:35 mathrick: it sounds hard to do too... Having a core written in CL would only make it easier though. Also, I'd like to have eval support in the browser. 01:24:50 mathrick: essentially, yes. But still a lot of work 01:25:09 CL is a complex beast 01:25:24 madnificent: well, depends on what you want to use it for. 5MB of JS doesn't sound fun in almost any scenario, really 01:26:04 mathrick: by splitting it up in components, you should never reach that amount (far from that amount even) 01:26:14 mathrick: perhaps a hybrid approach? 01:26:18 just have a flash-like (Clash?) plugin :d 01:26:28 adeht: somebody made it actually 01:26:34 though for FF only, IIRC 01:27:00 madnificent: well then you run into the on-demand loading thing, which is not very feasible either 01:27:00 mathrick: the benefit of that is that you don't need to load everything you want the user to execute. It will be loaded on demand. Thus allowing you to require a whole bunch of huge libs, and only send the relevant parts to the client 01:27:05 also, doesn't 3b work on Flash-based Lisp? 01:27:06 why not use CL on the server, and JS in the browser? works for me. 01:27:17 adeht: yup, that's working even (I think) 01:27:30 -!- tritchey [~tritchey@70-35-37-146.static.wiline.com] has quit [Quit: tritchey] 01:27:40 seems like a cl->js compiler adds a lot of complexity for very little gain. 01:27:51 -!- Odin- [~sbkhh@s121-302.gardur.hi.is] has quit [Read error: Operation timed out] 01:28:02 drewc: because if you want to develop WebOS applications in Common Lisp, then you don't want to have javascript (as it's not CL) 01:28:20 especially not if you want to cross-compile between android and webos 01:28:28 this doesn't mean you need CL in the browser 01:28:47 GWT doesn't put Java in the browser 01:28:55 madnificent: webos is not a browser, really 01:28:59 it doesn't mean you need it, I would _like_ it 01:29:07 mathrick: no, but it is javascript which powers the applications :) 01:29:44 doesn't mean I want my apps break because the user has gone out of range before they happened to hit the on-deman-loaded part 01:30:06 what kind of language is opera written in ? 01:30:24 C++ 01:30:46 doesit use some javascript or so ? 01:31:02 it's very fast here even in a vm 01:31:03 mathrick: actually, I figured that one out. By running an application you could see which parts it requires (preferably over multiple users) and send all that data to them. That would make it fairly complete. Or the whole thing if you'd want. If you can send content, you can send w/e you need them to know. 01:31:21 sellout [~greg@c-24-128-48-180.hsd1.ma.comcast.net] has joined #lisp 01:31:26 -!- sellout [~greg@c-24-128-48-180.hsd1.ma.comcast.net] has quit [Client Quit] 01:31:29 sepult: it has a javascript vm 01:31:33 ah 01:31:36 ok 01:31:57 sellout [~greg@c-24-128-48-180.hsd1.ma.comcast.net] has joined #lisp 01:32:22 mathrick: also: for webos that (range) is not a problem, as you'll supply the full app to them. For regular websites it's quite common (but html5 offers solutions) 01:32:57 madnificent: I still don't think a CL in JS is needed or even beneficial. You don't need the whole CL with all its interactive, REPL-y glory to deploy an app 01:33:06 sepult: http://my.opera.com/core/blog/2009/02/04/carakan 01:33:34 madnificent: for regular webapps yes, but it'd be rather ridiculous to implement AJAXy bits by embedding a full CL in the browser 01:34:05 mathrick: no you don't, but it would be nice to have for regular web apps and I think it would be good for WebOS too 01:34:09 not to mention readability and debugging 01:35:01 it would be easier to debug, you'd have the whole thing there to debug. Compiling to JS makes it harder to debug, I think. (it's hard to debug what you just wrote down, as the JS is not what you actually wrote down) 01:35:05 -!- Fullma [~fullma@ram94-2-82-66-69-246.fbx.proxad.net] has quit [Ping timeout: 265 seconds] 01:35:52 -!- ltriant [~ltriant@lithium.mailguard.com.au] has quit [Read error: Connection reset by peer] 01:36:01 -!- curi_ [~curi@adsl-99-114-139-86.dsl.pltn13.sbcglobal.net] has quit [Quit: Leaving] 01:36:28 neoesque [~neoesque@210.59.147.232] has joined #lisp 01:36:40 ltriant [~ltriant@lithium.mailguard.com.au] has joined #lisp 01:37:39 mathrick: anyways, it would be great to have android support ;) That'd be a great step forward 01:38:01 hopefully 01:38:25 madnificent: but re: debugging, that's only assuming the CL implementation is perfect and absolutely portable between engines 01:38:38 -!- sellout [~greg@c-24-128-48-180.hsd1.ma.comcast.net] has quit [Quit: sellout] 01:38:42 which is unlike to be the case in practice 01:38:54 btw, you can run ECL (and not only ECL) in Chrome 01:38:55 and debugging second-order code is nigh impossible 01:39:08 p_l: howso? That silly native something plugin? 01:39:12 though porting SBCL might be a little hard :P 01:39:16 NaCL 01:39:25 *NaCl 01:39:27 -!- xinming [~hyy@125.109.245.54] has quit [Ping timeout: 260 seconds] 01:39:41 tritchey [~tritchey@70-35-37-146.static.wiline.com] has joined #lisp 01:40:33 sellout [~greg@c-24-128-48-180.hsd1.ma.comcast.net] has joined #lisp 01:40:51