| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11
Comments:
<rpg> Beef__: it's tempting to think of things like "cl***es" being exported, but they aren't. Only symbols are exported.
<Beef__> yeah I know, empty ones :P
<rpg> The cl package system is not an interface system as in other languages; it's only a namespace system.
<segv> nikodemus: i just now noticed that the hyperspec says "both code size and RUN-TIME space" (emphasise mine).
<Beef__> I realize that, but I'm stuck on cl***es :/
<rpg> If you export a symbol that names a cl***, then you have a less-cumbersome way of referring to the cl***. The cl*** itself is neither more nor less exported than before.
<segv> i was surprised to find that run-time clause and was simply curious what sbcl does.
<lisppaste> nyef pasted "Does this look right for VOP operand validation?" at http://paste.lisp.org/display/24545
<rpg> Beef__: In particular, exporting the name of a cl*** does nothing to help you refer to cl*** accessors, slots, etc. For that you need to export the names of said accessors, etc.
<Beef__> that I did
<Beef__> it is the type/cl***name itself that is not getting exported, generating an error
<rtoy_> setv: FWIW, there is some magic option of space and speed for cmucl/sparc where it increases run-time but drastically decreases heap space, by zapping out unused slots on the control stack that might be holding onto random objects in the heap.
<nikodemus> segv: if you're interested, src/compiler/policies.lisp has the define-optimization-quality forms
<rtoy_> Er, segv, not setv.
<Beef__> I defcl*** 'point' for example in a package type
<segv> nikodemus, rtoy_: thanks a bunch.
<Beef__> and try to do defmethod (p point) in another package
<Beef__> how do I go around doing that?
<nikodemus> dx-allocation, tail-calls, self-calls, debug-instrumentation all depend on SPACE at least partially in sbcl
<nyef> Beef__: Did you export "POINT" from the packae you defined it in?
<rpg> Beef__: either defmethod (p package::point) [yuck] or you can export point from package, import it into your new package and just do defmethod (p point).
<nikodemus> (defmethod foo ((p type:point)) ...) or (defmethod foo ((p type::point)) ...)
<rpg> Or don't import it and do defmethod (p package:point)
<Beef__> but :export :point just exports an empty symbol :/
<ingvar> Or elide the impotring and defmethod (p type:point)
<nyef> Beef__: So? It's not used for its value, it's used for its identity.
<ingvar> But exports only EVEr exports symbols.
<slyrus> well, that's nice to know. sbcl 0.9.0.1 still starts up in this old box here.
<rpg> Beef__: What do you mean by "an empty symbol"?
<Beef__> There is no cl*** named INFER::RECTANGLE.
<Beef__> (infer makes :use of package types)
<ingvar> Is RECTANGLE :exported from package TYPES?
<Beef__> :rectangle is ok too right?
<Beef__> yes
<ingvar> Er. Only if you've defcl***-ed :rectangle. and taht would be a surprising thing to do.
<Beef__> and I restarted with a clean environment
<nikodemus> Beef__: lisppaste your stuff
<rpg> Beef__: Are you mistakenly exporting keyword symbols?
<Xach> rpg: you can't export keyword symbols.
<Xach> rpg: defpackage takes string designators in the export list.
<nikodemus> have we established that beef has defpackage instead of EXPORT calls?
<lichtblau> (defpackage foo (:use) (:import-from "keyword" "bar") (:export "bar"))
<lichtblau> (eq 'foo:bar :bar)
<lichtblau> t
<antifuchs> make symbols, not war!
<Xach> make-instance not war
<ingvar> lictblau: Imagine the possibilities that opens with (defcl*** :foo () ())...
<sqweek> error: unbound-variable war
<Xof> you can have even more fun than that
<Beef__> ... I think I tracked the problem down to an uncommented ;(in-package "TYPES")
<Beef__> sorry guys :p
<ingvar> Well, there's the fun of anonymous cl***es.
<beach> good afternoon
<ingvar> 'beach
<nyef> Hello beach.
<nyef> Hrm... Something isn't right with my vop operand validator. :-/
<rpg> Xach: You can export keyword symbols if you call (export...) but, of course you are right that you can't export them in defpackage.
<Xach> I forgot about export.
<antifuchs> sigh. emacs-multi-tty is broken again. gnah
<rpg> Xach: perhaps you are gc'ing deprecated knowledge...
<lisppaste> nyef annotated #24545 with "This version is a little better, and checks all VOPs in a running system." at http://paste.lisp.org/display/24545#1
<nikodemus> nyef: and do all our vops p*** muster?
<nyef> No, of course not.
<antifuchs> argh, I want my mac back
<nyef> But hey, now we have a list of what's broken, to go with the instructions for how to do it right that I wrote at the beginning of the month. ^_^
<rtoy_> nyef: Very nice!
<nyef> Thanks.
<rtoy_> Even works on cmucl, with a couple of minor changes. :-)
<nyef> The idea came to me last night that it should be done during define-vop, but that required finding the hooks and debugging the logic first (the hook is !grovel-vop-operands, btw.), and once I had the logic mostly working, it turned out to be easy enough to do it this way instead.
<rtoy_> Now, what does it mean if the lifetime does not overlap?
<nyef> That should be explained in http://www.lisphacker.com/codex/001-sbcl-vops.txt
<Xof> nyef: cool. Have you seen the vop-testing code somewhere in tests/compiler.impure.lisp?
<nyef> Xof: Umm... No?
<Xof> it does something different, don't worry
<Xof> consistency checking between declared argument and return types for functions and the vops that implement them
<nyef> Ahh.
<rtoy_> nyef: Yeah, I read that page. Nice description. I obviously didn't read it in enough detail before.
<nyef> Anyway, now that I have code to do this, I should package it up on my website, blog it, and email sbcl-devel.
<nyef> Yurik: Can I direct your interest to tech.coop?
<Yurik> I know about it. But as far as I remember it isn't that cheap
<cliini> Computer administration is teh **** any way you care to put it.
<nyef> I figure that using WARN somewhere under DEFINE-VOP will prevent further disrepair once the current VOPs have been fixed.
<sellout> Yurik: But there's the bonus #lisp support :)
<rtoy_> nyef: So warning means that the argument or temporary could be :targeted to some result arg?
<slyrus> looks like gbyers is going to beat us to darwin/x86-64
<nyef> It means that it might end up on the same location, preempting the :target.
<nyef> Probably has something to do with evaluation order within the pack phase.
<nyef> Yurik: $35CAD/month for the basic plan is too much?
<Yurik> nyef: is it for dedicated server? :)
<nyef> It's a Xen VPS.
<nyef> Runs SBCL quite nicely, if that's what you're worried about.
<Yurik> after one month of $30 VPS I hate VPS
<kire> Yurik, who are you with now?
<AWizzArd> dedicated AMD Athlon 64 3700+, 1 gig ram, 2 x 160 GB SATA HDD, unlimited traffic: 39 euro per month
<Yurik> kire: I'm with local company now
<AWizzArd> (and 100 mbit into the net)
<Yurik> AWizzArd: where?
<nyef> Yurik: What'd they give you, a UML instance?
<AWizzArd> www.hetzner.de
<kire> Yurik, common-lisp.net runs in a Xen VPS at tech.coop. No complaints so far.
<Yurik> nyef: something on freebsd
<AWizzArd> http://www.hetzner.de/rootserver_en.html
<Yurik> AWizzArd: looks nice (except setup fee :)
<AWizzArd> Yurik: set up fee yes, but: you can cancel the offer every month.. no need to order 12 or 18 months
<Yurik> AWizzArd: it becomes common to other dedicated servers provider to offer a month-to-month contract
<AWizzArd> well, Hetzner is just really really good, but noone forces you to try it
<Yurik> even without startup fee... but after few hours googling I can't stop on any one. Making choice is hard! :)
<Yurik> Hetzner parameters are really cool
<AWizzArd> it got very good ratings in a test of the leading german computer magazine some weeks ago
<AWizzArd> and they update their servers every few months
<AWizzArd> some weeks ago one could order a dual opteron with 4 gigs for just 150 per month
<AWizzArd> and i like their minimal debian installation, without apache, mysql and php
<AWizzArd> i can compile my sbcl and be happy
<Yurik> :)
<antifuchs> afaik, my old workplace had a hetzner host, too, and they were very happy with it
<Yurik> it seems that everything is cool with hetzner, except, ~$125 setup fee. I need to think more :)
<Yurik> and lack of Deutsch knowledge :]
<jsnell> they speak english
<rtoy_> nyef: Speaking of lifetimes, do you know what the :load-if option really means?
<Yurik> I just see that site switches to deutsch for documentation
<Yurik> :)
<Yurik> and things like terms and conditions are in German :)))
<Yurik> anyway, interesting option
<nyef> rtoy_: No, I haven't looked into that yet.
<rtoy_> nyef: Ok. The docstring for it is clear as mud to me.
<nyef> Yeah, clear as mud, and the code isn't much better...
<Xof> VOP: CHECK-VECTOR-NIL
<Xof> WARNING:
<Xof> Lifetime of non-:TARGET TEMPORARY EAX does not overlap :TARGETted RESULT RESULT.
<Xof> nyef: in these CHECK-TYPE-derived VOPs, while the complaint might be legitimate the way the vops are written mean that in fact nothing will go wrong
<Xof> I think
<nikodemus> this is about better packing, not correctness? no?
<Xof> possibly. I think the way these vops are written you can't get better packing either
<Xof> there is one temporary, which conflicts in lifetime with the argument. The argument targets the result
<Xof> therefore, the temporary will have its own register, and the argument / result will have a second register. Which is the minimum necessary
<Xof> so I think that nyef's checking code needs to check for an overlap of _either_ the targeted result or the TN it's targeted from
<Xof> If I've understood his 001-sbcl-vops.txt correctly, anyway
<turtle_bazon> Hi, some CLOS question appears...
<turtle_bazon> Is anyone find that CLOS object system usability is more UGLY than in such languages as C++, Ruby, Java?
<nikodemus> no
<nikodemus> next question
<pjb> They really got strange questions these newbies...
<turtle_bazon> Why no? I don't understand that method definitions is outside cl***.
<ingvar> I find, after much thinking about things, CLOS to be close a good fit as an object system for CL. I also find methods-belong-to-cl***es and enforced single dispatch incredibly limiting and code uglifying.
<pjb> turtle_bazon: well, it allows you to define methods on non-CLOS objects.
<pjb> (defmethod double ((self integer)) (* 2 self)) (defmethod double ((self string)) (concatenate 'string self self))
Return to
#lisp
or
Go to some related
logs:
ubuntu not automatically fixing this
#linux
pastebin iptables
#kde
to move a large crate across a rough floor
#debian
#gentoo
php mysql_config not found
#linux
toolchain-glibc_src_compile
|
|
