#clojure – 2009-04-12

2009-04-12

02:35	cp2	lib names inside prefix lists must not contain periods
02:35	cp2	whats this about?
02:35	cp2	from
02:35	cp2	(read-classfile-header (DataInputStream. (FileInputStream. "../t.class")))
02:36	hiredman	,(doc read-classfile-header)
02:36	cp2	thats my own function
02:36	cp2	but, shouldnt matter
02:36	cp2	because it worked before
02:36	hiredman	oh no
02:36	hiredman	clojurebot
02:36	cp2	:(
02:37	cp2	i see
02:37	cp2	load-lib is throwing it
02:37	cp2	(throw-if (and prefix (pos? (.indexOf (name lib) (int \.))))
02:37	cp2	"lib names inside prefix lists must not contain periods")
02:37	cp2	the hell
02:37	cp2	oh
02:37	cp2	oops
02:38	cp2	mucked up a vector in (ns .... (:use [.....
02:39	hiredman	erp
02:40	hiredman	~botsnack
02:40	clojurebot	thanks; that was delicious. (nom nom nom)
03:43	durka42	is my answer to http://code.google.com/p/clojure/issues/detail?id=104 nonsense?
03:53	hiredman	it convinced me
04:36	Lau_of_DK	Top of the morning gents
07:04	Lau_of_DK	Anybody suffered from this? "org.lwjgl.opengl.OpenGLException: Cannot use Buffers when Pixel Unpack Buffer Object is enabled (NO_SOURCE_FILE:0)"
07:05	Lau_of_DK	Its thrown when I try to use createWindow - Its worked flawlessly for ages, but after a reinstall of my OS, it now borks
07:13	hiredman	http://lwjgl.org/forum/index.php?topic=2537.0%3Bwap2
07:15	hiredman	http://www.jmonkeyengine.com/jmeforum/index.php?action=printpage%3Btopic=6047.0
07:16	hiredman	the second link looks helpful
07:25	Lau_of_DK	Thanks hiredman
07:25	Lau_of_DK	I think it might be related to the latest nvidia driver, it doesnt give permissions to the video group, do access /dev/nvidiactl
07:27	Lau_of_DK	haha, same conclusion they reached
07:27	Lau_of_DK	Thanks hiredman, you hit it spot on
07:27	hiredman	glad it worked
07:28	Lau_of_DK	Its not working yet, but Im in the right zone now
07:29	Lau_of_DK	gotta restart x, brb
07:33	Lau_of_DK	Ok - something worth noting about LinuxMint - for some reason it doesnt add your primary user to 'video' when creating it - and for some reason, it gets compiz going even w/o....
07:34	Lau_of_DK	(working now)
07:37	Lau_of_DK	hey rhickey , long time no see
07:37	rhickey	good morning
07:46	Lau_of_DK	So rhickey , have you got Gerald J hacking away in Clojure yet?
07:46	rhickey	not yet
07:47	Lau_of_DK	k
09:53	leafw	someone's at work
09:56	hiredman	:D
09:56	hiredman	read-eval
10:58	cconstantine	is there a way to do named optional arguments?
11:02	singhv	yes.. you do it by giving your function multiple bodies. see the code sample here: http://clojure.org/special_forms
11:10	cconstantine	so, it looks like to do optional named arugments the caller needs to pass a map...
11:11	cconstantine	am I reading that right?
11:17	Cark	constantine : that's right
11:18	cconstantine	thats.... slightly awkward
11:20	Cark	would you rather have this be done behind the scene ?
11:20	Cark	and pay for the cost of it on every function ?
11:20	lisppaste8	cconstantine pasted "testing optional arguments" at http://paste.lisp.org/display/78450
11:21	cconstantine	I believe in CL it's done as a macro, so the cost is paid at compile-time
11:21	cconstantine	my paste doesn't work for some reason
11:21	singhv	the map way is one way to do it. but by multiple bodies i meant something else:
11:21	dliebke	Most of the functions I write have optional named arguments without the caller supplying a map. I make the map myself using (apply assoc {} options), where the function signature is something like [x y & options]. so the caller can just call (foo x y :opt1 1 :opt2 2)
11:21	lisppaste8	cconstantine annotated #78450 "untitled" at http://paste.lisp.org/display/78450#1
11:22	lisppaste8	cark annotated #78450 "untitled" at http://paste.lisp.org/display/78450#2
11:22	cconstantine	oh right
11:22	singhv	it's when you give your function multiple implementations each with different argument lists, and have some of them call other versions
11:22	Cark	constantine : how does CL know on the call site ?
11:23	cconstantine	Cark: not sure, I might be wrong now that I think about it
11:23	singhv	sorry, you said named optional arguments - ignore me.
11:23	lisppaste8	cark annotated #78450 "untitled" at http://paste.lisp.org/display/78450#3
11:24	cconstantine	dliebke: that sounds like exactly what I need... could you show me?
11:26	cconstantine	singhv: hehe, yeah I can get optional arguments just fine... I have 3 arguments. 1 is required, the other two are optional
11:26	cconstantine	To be able to specify 0, 1 or 2 of the optional arguments I need to name them
11:28	Cark	you could go like this : (fn [required & optionals] ... then check that every odd argument is the correct name in your function
11:28	Cark	but it isn't as good for editors as the map solution
11:28	lisppaste8	dliebke annotated #78450 "optional named arguments" at http://paste.lisp.org/display/78450#4
11:30	cconstantine	dliebke: ok, so you convert the &optional to a map, then pull out keys
11:30	dliebke	yes
11:32	Cark	but slime won't show you the argument list that way
11:34	dliebke	true. So, I write elaborate documentation strings for my functions showing the available options and their default values (but I need to do that anyway)
11:35	Cark	this is only to avoid the braces in your call site ?
11:37	dliebke	yes, I writing a R-like statistical library, and I want my function calls to be as close to the original R syntax as possible.
11:38	cconstantine	http://groups.google.com/group/clojure/msg/51bb53ca077154f8
11:46	cconstantine	It seems like the arguments passed from the caller could be resolved at compile-time, making named optional arguments just as fast as a normal call
11:51	cconstantine	How do I do destructuring in an optional argument?
11:51	cconstantine	nm
11:55	Lau_of_DK	user> (defn foo [a & options]
11:55	Lau_of_DK	(let [[b c d] options]
11:55	Lau_of_DK	(map println [a b c d])))
11:55	Lau_of_DK	You mean like that?
11:55	cconstantine	that kidna works, but that doesn't give me reording
11:55	Lau_of_DK	You asked about destructuring?
11:56	cconstantine	I was thinking an arg-list more like: [req {a :a b :b c :c :or {a 1 b 2 c 3}}]
11:56	cconstantine	and the map can be optional through another arg-list without it
11:57	cconstantine	so a call would look like: (some-func a {:a 1})
11:58	Lau_of_DK	I'd say it depends on the actual case - its not really a matter of destructuring
11:58	cconstantine	that is a destructuring
11:59	cconstantine	it works, but has some { }s in the call
13:17	Cark	" <cconstantine> It seems like the arguments passed from the caller could be resolved at compile-time" what if you change the definition of the called function after the call site is compiled ?
13:30	cconstantine	uh, don't do that?
13:31	cconstantine	what happens if you change the definition of the called function to add an argument?
13:31	cconstantine	or remove an argument
13:33	Cark	that's lisp we're doing here ... very dynamic
13:33	Cark	and one of the reasons of named optional arguments is just that, so that you can add argument
13:33	Cark	s
13:35	Cark	now if your call site is compiled so that it "magically" knows the named arguments, you'de better make sure the algorithm takes into account the possibility that some arguments might be added, or the order of arguments might change
13:35	Cark	so in the end you keep the runtime cost
13:36	Cark	you still need to look the name up at runtime
13:38	cconstantine	so what happens if you add an argument to a function and the call sites aren't recompiled?
13:38	cconstantine	I'm not saying it isn't a problem, but I'm not seeing why it isn't a problem for regular arguments
13:39	Cark	it's a problmem for regular arguments
13:39	Cark	not so for optional arguments
13:39	cconstantine	but it isn't a problem for optional arguments through a &rest because that's passed as a list
13:39	Cark	right
13:43	cconstantine	so why not just have it be a runtime failure when the arguments change same as with regular non-optional arguments?
13:44	Cark	one of the purposes of named optional arguments is precisely to let you add them or change their position without causing any problem
13:44	Cark	that's in my opinion anyways
13:46	cconstantine	ah, I just want to be able to have a a set of arguments that aren't required
13:47	cconstantine	if they aren't named you have to have preceding arguments in the argument list
13:47	Cark	there is a construct in the language to do what you want, and it's stricly more powerfull than what you need
13:47	Cark	so what's the trouble ?
13:48	cconstantine	I guess the trouble is I don't know it :)
13:48	Cark	well we showed that to you earlier
13:49	Lau_of_DK	clojurebot, seen technomancy?
13:49	cconstantine	optionally passing in a map?
13:49	Lau_of_DK	~seen technomancy?
13:49	clojurebot	no, I have not seen technomancy
13:49	Cark	constantine : that's a way to do it yes
13:50	cconstantine	Cark: that (and the other options) is close enough, but not exactly what I want
13:50	Cark	you want CL style named parameters
13:51	Cark	right ?
13:51	cconstantine	basically yeah.
13:52	Cark	you could make your own defn macro if that's absolutely what you want
13:52	Cark	but it seems a lot of work for something that's already there
13:52	Cark	i would argue that the clojure way is best
13:52	Cark	you have two orthogonal concepts
13:52	cconstantine	eh. We can disagree because the clojure way works :)
13:53	Cark	on concept is destructuring
13:53	Cark	and the other one is function call
13:53	Cark	they're kept separate
13:53	cconstantine	right
13:54	Cark	in CL, you have destructuring (destructuring-bind) and destructuring arg lists
13:54	Cark	that's mudying the waters !
13:55	cconstantine	if I didn't want muddy waters I'd be in scheme... but I want to get stuff done
13:56	Cark	right, so why not use the existing facilities ?
13:57	cconstantine	it forces me to either redefine how to define functions, or rewrite a pattern every time I want to use it
13:58	Cark	by pattern ? you mean the curly braces
13:58	Cark	?
13:58	cconstantine	right now, I'm just using the pattern, and forcing callers to pass in a { ... } for optional arguments
13:58	cconstantine	there is a call-side pattern (the curly braces) and a caller side pattern (accepting no options and passing in a {}
13:59	cconstantine	s/caller/callee
14:00	Cark	in order to avoid the problem with calers not needing any argument you can define you function like this : (denf bleh ([required] (bleh required {})) ([required {:keys [a b c]}] ....))
14:00	clojurebot	this is not a bug
14:01	cconstantine	right, that's a pattern
14:01	cconstantine	it works, but it's something that could be standardized and abtracted away with a standard macro
14:01	Cark	well then make a macro and be done with it =P
14:04	cconstantine	might, but it would be nice to have to macro extend to the call-site and do it there.
14:04	cconstantine	I'll have to think it through a bit more, and try to get it into clojure.contrib
14:05	Cark	first you would need to change the way function calls work
14:05	Cark	that cannot be done with a library i think
14:05	Cark	second i don't think that's a good idea
14:06	cconstantine	if the macro (defn-with-optional-named-arguments some-func [ ...]) made a macro named some-func that called a gensymed func
14:06	cconstantine	it could even wrapp the macro in a (var ...) to make it passable
14:07	Cark	then you can't map it anymore
14:07	cconstantine	all the call-site macro would do is convert a (some-funct a) to a (some-funct a {})
14:07	cconstantine	can't map it?
14:07	cconstantine	oh, like (map ...)
14:08	Cark	yes
14:08	cconstantine	I believe there is a way to do that (to be able to pass 'or' and 'and')
14:09	Cark	#(or %1 bleh)
14:09	Cark	this goes to show there are troubles anyways
14:10	cconstantine	no, I mean a simpler way
14:12	cconstantine	yeah, it's (var macro)
14:14	cconstantine	eh, the more I think about it the more this has problems with functions used as higher order funcs
14:15	cconstantine	'this' being a macro that makes a macro
14:36	Lau_of_DK	cconstantine, Im sorry I didnt see your question before now http://failblog.files.wordpress.com/2009/02/fail-owned-ownership-fail.jpg?w=500&h=112 ... Did you get this resolved?
14:36	cconstantine	mostly yeah
14:37	Lau_of_DK	Good
15:17	durka42	,(var or)
15:18	yason	When moving data around like in tuples or small lists, is it more idiomatic to use vectors or lists?
15:18	durka42	,(var or)
15:18	clojurebot	#'clojure.core/or
15:21	durka42	i might use a vector
15:21	durka42	depends on what you're doing with it though
15:22	yason	durka42: vectors seem more natural since there's better syntax for creating them
15:23	yason	durka42: mostly they'll just end up in some other place, probably deconstructed into variables
15:24	yason	lists and dotted pairs are just more traditional in lisps -- might not hold in clojure though :)
15:25	yason	when would it be more sensible to use lists?
15:25	durka42	well, vectors are faster for random access
15:26	durka42	lists are better for appending and prepending
15:26	yason	so new copies of vectors are made when something is added in them?
15:27	durka42	well, yes and no
15:27	durka42	data structures are immutable
15:27	durka42	so you always get a "new" one
15:27	durka42	but it will be mostly copy-on-write
15:27	yason	(as opposed to lists consed together from new heads and old tails)
15:28	Chouser	vectors are faster for appending, lists faster for prepending
15:28	durka42	http://clojure.org/data_structures
15:28	Chouser	yason: for your general question, I think vectors are most often slightly more idiomatic
15:29	yason	Chouser: that makes sense, you can extend vectors easily and you can (cons head old-list) more naturally. So is there any other essential differences besides random access and prepending/appending?
15:30	yason	Chouser: Ok, I guess I'll go with vectors then. Just wanted to check I'm not abusing them somehow. I'm just used to Lisps where vectors are maybe less generic than lists.
15:33	yason	Anyway, I think Clojure is pretty damn great and programming with it is great fun. I've also realised that JVM is actually rather nice as soon as you stick a real language onto it, which I would probably have missed without Clojure. :)
16:09	cconstantine	I've got a weird problem... pasting
16:10	lisppaste8	cconstantine pasted "cconstantine" at http://paste.lisp.org/display/78466
16:29	digash	how does one destructures Map into key values?
16:29	digash	,(let [[key val] {:a "a" :b "b"}] [key val])
16:29	clojurebot	java.lang.UnsupportedOperationException: nth not supported on this type: PersistentArrayMap
16:30	digash	oops, ignore my stupidity.
16:31	digash	i've obviously wanted a doseq or first.
16:31	digash	,(let [[key val] (first {:a "a" :b "b"})] [key val])
16:31	clojurebot	[:a "a"]
18:03	cconstantine	Who do I talk to for a code-review and possible inclusion in clojure-contrib?
18:20	danlarkin	the mailing list
18:54	Raynes	Has anyone noticed how massively boring Scala is? :\|
18:55	danlarkin	if you don't have anything good to say...
18:56	hiredman	you know #scala had a vote and decided not to log the channel
18:56	hiredman	bizzare
18:57	digash	My coworker bought the Scala book and the firs mention of concurrency is somewhere after p700.
19:04	gnuvince_	I find that most statically typed languages are much more complex than dynamic ones.
19:04	gnuvince_	Compare Clojure, Python, Smalltalk and Factor to Scala, C++, Java and Haskell and tell me the first four are not much simpler than the latter 4.
19:07	digash	"Our main goal is to ensure race safety with a type system that's simple and expressive enough to be deployed in production systems by normal users."
19:07	digash	-- http://lamp.epfl.ch/~phaller/uniquerefs/
19:07	digash	I feel that I am not "normal user".
19:08	Raynes	danlarkin: Oh, it's good enough to make me hate Java even more, but it's still boring.
19:09	gnuvince_	Raynes: I agree that Scala doesn't seem to have the "oomph" effect of Clojure or Haskell.
19:15	cp2	18:04 < gnuvince_> Compare Clojure, Python, Smalltalk and Factor to Scala, C++, Java and Haskell and tell me the first four are not much simpler than the latter 4.
19:16	cp2	oh yeah
19:16	cp2	definitely
19:16	cp2	i find it funny, all of my friends who are using c++, java, tell me 'oh clojure is so complex because of all the parentheses' etc
19:17	gnuvince_	There's something about knowing all the quirks and exceptions of C++ that people find so appealing.
19:17	cp2	heh
19:17	gnuvince_	"Wow, you must really be a good programmer if you know what a private virtual static friend function is!"
19:20	Raynes	Anyone who says Clojure is complex or bad because of the parentheses needs to be killed. :\|
19:20	hiredman	thats kind of harsh
19:20	danlarkin	yeah I don't really get where your anger comes from Raynes
19:20	hiredman	maybe shipped off to a re-education camp
19:22	Raynes	Well, not literally...
19:29	StartsWithK	anyone used Cloak to automate tasks from clojure?
20:09	Raynes	I want to learn Forth.
20:10	pstickne	so learn it :)
21:27	Chouser	rhickey: spent any more time on self-hosted clojure?
21:34	rhickey	Chouser: only in thinking about namespaces and modularity. I'm trying to get all known issues on the table in looking at self-hosting. A big one is the mismatch between namespaces and the way Java and especially Java module systems (OSGi etc) look at things
21:34	Chouser	ok
21:34	rhickey	there's a fundamental conflict between all-ns and modularity
21:35	Chouser	for better modularity you'd need some namespaces to be visible to less that the whole clojure world?
21:35	rhickey	yes, and to track class visibility in general
21:36	rhickey	it dovetails with classloader issues, which are still a pain
21:36	Chouser	indeed
21:37	rhickey	the fundamental problem is you can't do classForName on behalf of someone else, i.e. in library code
21:38	Chouser	where "someone else" is a different modules of the OSGi variety? Or where "someone else" is any other lib?
21:40	rhickey	It comes into play with regular classloaders - i.e. if a child classloader can see something Clojure's classloader can't, it can't successfully import it, because it is library code in Clojure that calls classforname
21:41	Chouser	ok, and the jvm is paying attention to the class that owns the method doing the actual classForName call?
21:42	rhickey	You can use context classloaders, but then you need to know that is happening, and most of the module systems don't. They are presuming the immediate consumer calls Class.forName, which does a stack walk to find the classloader of the caller (which could be a bundle classloader) and all works fine - try to proxy the forName call and it fails
21:42	rhickey	The bottom line is namespaces need to be found the same way classes are found
21:43	rhickey	So, my thinking is a connection between com.my.ns and com.my.ns$Namespace.value, where the latter is a clojure.lang.Namespace
21:44	rhickey	get rid of the master namespaces collection
21:44	rhickey	in a modular system, namespaces should be no more fully enumerable than classes - i.e. not at all
21:45	Chouser	interesting
21:45	Chouser	if I've got the a namespace object, getting to the package where all its classes are defined is easy
21:46	rhickey	this will provide many benefits, including the ability to load most of Clojure just once and share it with many ephemeral loading contexts, be that web apps, or NetKernel stuff, or OSGi...
21:47	Chouser	and for any given namespace name, finding the namespace object is also simple -- computed both ways then, right, no further connection needed?
21:47	rhickey	making namespaces align with classloader and module visibility is key
21:48	rhickey	Chouser: right, namespace-name leads to class leads to namespace object, not sure about the need to go the other way
21:50	rhickey	this obviously impacts the compiler - it can't presume a single global namespace world, and will need to generate code that will leverage the visibility it will have when loaded (i.e. it may be able to see things clojure.lang can't)
21:50	clojurebot	this is not a bug
21:51	Raynes	I wish they made bags of nothing but buttered popcorn jelly beans. :\
21:53	Chouser	Raynes: http://www.jellybelly.com/Shop/ProductDetail.aspx?ProductID=40137&ProductGroup=Buttered_Popcorn
21:53	Raynes	O.O
21:53	Chouser	that's a case of 24 bags, 3.5 oz per bag. Should hold you for a while.
21:53	Raynes	Chouser: You're my hero. hiredman: You're off the hook.
21:58	Chouser	rhickey: does that mean that any runtime reflection would have to be done differently?
21:59	Chouser	as in, not in a library that may not be allowed to look at the class being reflected upon?
21:59	Chouser	or could it examine an instance of Class that's specifically passed in?
22:07	lepassive	Hi anyone using Enclojure with NetBeans 6.7 ?
22:08	rhickey	Chouser: I don't think there will be issues there
22:09	Raynes	I don't think Enclojure supports NetBeans 6.7, but I might be incorrect.
22:09	lepassive	Raynes, that's right I can't get it working with 6.7 :(
22:10	Raynes	lepassive: I believe there is a thread about it on the Enclojure group.
22:12	lepassive	Raynes, thanks alot i found the thread
22:13	Raynes	lepassive: No problem. Good luck.
22:46	Mec	how does java reference string regex captures?
22:47	hiredman	$1
22:48	hiredman	,(.replaceAll "22nd" "(\\d+)nd" "$1ND")
22:48	clojurebot	"22ND"
22:48	Mec	thanks, tried \1 and got some bizarre results :D
22:49	hiredman	yeah