| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10
Comments:
<0> oh, wait...
<1> that should be (macroexpand `(mref ,mat ,@args) ,env)
<0> yeah, thats what I was just thinking
<1> or (macroexpand whole ,env) ;)
<1> using &whole will serve you well in the long-run, heh
<0> ok, thanks guys!
<2> apropos stumpwm. Wasn't there someone here recently who decided that eclipse wasn't to his taste, so he started to hack yet another WM in Lisp?
<2> Did anything come out of that?
<3> slyrus annotated #34363 with "the final product" at http://paste.lisp.org/display/34363#1
<2> ah, CLFSWM looks like a recent development. Perhaps that was it.
<4> tritchey: hello
<2> uh oh, the largest file in CLFSWM is called keysyms.lisp. Taken from Hemlock.
<2> Is there -any- Common Lisp GUI project without its own copy of X11 keysym tables?
<1> slyrus_: good stuff :)
<0> Riastradh: I suppose I could make a unique accessor for each matrix instead of p***ing it in as an arg, but I like the fact that code is the same with or without the with-typed-mref form
<5> lichtblau: cl-sdl?
<5> graphic-forms?
<2> I'm sure clim-graphic-forms will correct that omission.
<2> slyrus: while we're at it. You ran the gtkairo key table generation for me a while ago, right?
<0> lichtblau: yup
<6> lichtblau: somebody should make trivial-keysyms (:
<2> It would be great to have new results on MacOS for the current generation code.
<6> every lisp project would lose 30% weight (:
<2> Not urgent at all, but if you can get around to it, that would be great!
<2> It's also much, much faster now.
<0> ok, some procedure as last time?
<0> same even
<2> same procedure, only less fragile. I hope.
<0> ok, give me a few minutes.
<7> slyrus_, well, for a subset of possible bodies -- that is, only those in which access to the matrix is made through a variable.
<0> Riastradh: you lost me there
<2> I'm also hoping that current CVS gives you correct : and ; even before you generate your own file. Is that the case?
<7> (with-typd-mref ((car x) (unsigned-byte 8)) ... (mref (car x) ...) ...) won't work, for instance.
<7> WITH-TYPED-MREF, even.
<0> ah, ok.
<7> ...on second thought, I suppose that doesn't matter much.
<7> Ideally, of course, it would be possible for the compiler to figure all this out. Out of curiosity, why do you have a separate `matrix' data type?
<0> Riastradh: it's what I use to do method dispatch and hold other information about the array/matrix.
<0> I can't do method dispatch on the element-type of the array, AFAIK.
<1> (mref (car x) COULD be made to work
<0> I mean, I can, but I have to do it by hand, rather than getting it for free in defmethod
<8> slyrus_: I think that code makes undefined use of the environment (it might not have dynamic extent)
<1> you'd just need the programmer to swear that he won't modify X in the body of that expression
<1> pkhuong: you sure about that?
<7> I see.
<8> slyrus_: also maybe that faking compiler-let w/ symbol-macrolet to keep an explicit environment would be easier.
<1> env is only used inside expansions by the macros defined in the macrolet
<1> and those can only appear inside the body of the with-typed-mref if they're to be expanded by that macrolet
<8> rahul: yeah, but the expansion of the local macros (and the use of env) is after the macro returns.
<1> hmm yes
<5> "The object that is bound to the environment parameter has dynamic extent."
<5> doesn't say what the size of the extent is
<8> kpreid: so nasal dragons if you use it outside that extent.
<0> lichtblau: what do I do again?
<7> Yes, pkhuong, but it doesn't say what precisely the extent is.
<8> kpreid: well, istm the sanest way to read it is to ***ume the tightest extent possible.
<5> s/sanest/safest/
<5> on the other hand, there's something to be said for choosing more flexibility even if the spec doesn't require it
<2> slyrus_: Let me think... Build clim-gtkairo and clim-clx. Also load keygen.lisp. Eval the two statements at the top of that file.
<8> kpreid: *macroexpand-hook* has `The environment object has dynamic extent; the consequences are undefined if the environment object is referred to outside the dynamic extent of the macro expansion function.' That seems to support the safe interpretation.
<0> pkhuong: if I do `,(macroexpand whole ,env) will that fix this problem?
<8> slyrus_: no, because macroexpansion fixpoints but doesn't recurse.
<8> oh wait, wrong arg name
<8> slyrus_: how does that make sense? And I don't see how this approach can ever work wrt extent. It's pretty close to one of the use case for http://www.alu.org/HyperSpec/Issues/iss229-writeup.html (the other being environment in codewalkers; bad memories...)
<1> hmm
<9> yow
<0> granted I don't really understand, but moon's rationale sounds like crap to me
<1> (symbol-macrolet ((.mref-expanders (acons ,z ,(lambda (...)...) .mref-expanders))) ,@body)
<1> er, that wouldn't interact quite right for optimization
<1> I think you need compiler-let here
<8> rahul: why wouldn't compiler-let w/ symbol-macrolet work here?
<0> what is compiler-let?
<1> (compiler-let ((.mref-expanders. (acons ,z ,(lambda ....)) .mref-expanders.)) ,@body)
<1> and in mref, ***oc the matrix into .mref-expanders. to get the function to apply to actually do the expansion
<8> slyrus_: `The intent of COMPILER-LET was to permit information to be communicated between macros by use of dynamic variables at macroexpansion time.' (removed)
<1> slyrus_: it's a LET that affects the compile-time bindings instead of run-time bindings
Return to
#lisp
or
Go to some related
logs:
CD_ROOT= CD_ROOT_1=
azerous for fedora
#gentoo
eps2pdf ubuntu
captive-static ubuntu install
#perl
#math
#suse
15 kilohertz mp3
+ltsp emu10k1 howto
|
|