IRC log for #sdl, 2009-10-13

All times shown according to UTC.

Time	Nick	Message
05:21		japhb joined #sdl
05:33		KatrinaTheLamia joined #sdl
06:18		KatrinaTheLamia joined #sdl
06:40		sami joined #sdl
06:40	sami	Hey kthakore, sorry for not being able to help before. I just switched jobs so it's been lots to do.
09:17	kthakore	sami: np
09:17		sami: btw http://article.gmane.org/gmane.comp.lib.sdl/44190
09:18		sami: try that out
09:18		hi KatrinaTheLamia
09:18		Morning garu
11:43		magnet joined #sdl
11:43	magnet	hi
12:40		jeekl left #sdl
13:55	kthakore	hi magnet
14:19		garu: around?
14:24		nothingmuch: hi
14:25		nothingmuch: I am looking into the api of Obect::Tiny and I think it does a lot of the things we need
14:25	nothingmuch	wit only does readonly accessors
14:26		and it doesn't apply to XS accessors
14:26		i think it's kinda pointles
14:26	kthakore	nothingmuch: thats what I mean
14:26		nothingmuch: I like the interface of it
14:26		nothingmuch: but it needs more features
14:26		like get and set
14:26		and optional
14:26	acme	... like Moose? ;-)
14:27	kthakore	acme: Moose would be ideal
14:27		but I need to do benchmarks to see if its the best way to go
14:27	nothingmuch	kthakore: sketch it with Moose
14:27	kthakore	ok
14:27	nothingmuch	then figure out what's the minimal subset
14:27		Moose won't really help anyway
14:28		because again, the accessors are backed by a C struct
14:28	kthakore	ya
14:28	nothingmuch	so nothing really applies
14:28	kthakore	Class::XSAccessor?
14:28	nothingmuch	(theoretically Moose is the closest thing to working, but it still requires a bit of glue...)
14:28		no
14:28		that still works on a hash ref
14:28		it's just implemented in XS
14:28	kthakore	right
14:28		hold on
14:28	nothingmuch	no Perl module can actually do this without Inline::C or Language::XS or something like that
14:29	kthakore	what I meant is we do something like Class::XSaccessor but hook it in to the C structs specifically
14:29		so CLass::XS::Rect
14:29		kinda thing
14:29	nothingmuch	that's just Rect.xs
14:29		there's no real way to generate this code
14:29		well, there is
14:29		but it still has to be generated at build time
14:29		otherwise you have a runtime dependency for a compiler
14:30	kthakore	build time is what I prefer
14:30		so XS
14:30		then
14:30	nothingmuch	but this is all irrelevant
14:30	kthakore	ok
14:30	nothingmuch	you're still thinking implementation
14:30		think interface =)
14:30	kthakore	ahhh I know
14:30	nothingmuch	then worry about impl
14:30	kthakore	....
14:30		its hard for me
14:30		I am a hacker
14:31		I hack
14:31	nothingmuch	there's still hacking to be done, but it's nice to have a direction to hack in ;-)
14:31	kthakore	I know, but I always do this
14:31		start thinking of impl too early
14:31	nothingmuch	i mean, by all means play around with Class::XSAccessor, it's an awesome module and uses a very clever trick
14:31	kthakore	ok is there like a interface or API good practices checklist I can follow
14:32	nothingmuch	but it's not really going tohelp ;-)
14:32	kthakore	nothingmuch: no no you are right interface then impl
14:32	nothingmuch	i think typical Moose style is generally what's preferred nowadays
14:32		some people like semi affordance constructors
14:32		($rect->X is readonly, $rect->set_x modifies)
14:32		i don't mind either way
14:33		personally i always optimize for cognitive overhead
14:33	kthakore	I noticed
14:33	nothingmuch	(unfortunately it's typically my cognitive overhead ;-)
14:33	kthakore	thats perlishness though
14:33	nothingmuch	basically i don't mind typing a bit more or reading a bit more if it gets self documenting
14:33	kthakore	make stuff eaiser for programmer rather then machine
14:33	nothingmuch	but too self documenting is a problem in its own right
14:34		i have a fetish for small, self contained things
14:34		which means i often have too many components
14:35	kthakore	nothingmuch: so is there like a link or something that lays out all the things I need to think about for interface design?
14:35		nothingmuch: I am using this for now http://lcsd05.cs.tamu.edu/slides/keynote.pdf
14:36	nothingmuch	not really
14:36	kthakore	slide 4 is my goal
14:36	nothingmuch	TIMTOWTDI
14:36	kthakore	huh?
14:37	nothingmuch	i like that slide
14:37	kthakore	me too
14:37	nothingmuch	i also like orthogonality
14:37	kthakore	I saw it in my Software Design course but never acutally groked it like now
14:37		please define orthogonality
14:38	nothingmuch	making sure components stay out of each others' hair as much as possible
14:38		for several reasons:
14:38		1. the implementation is more robust in the face of change
14:38	kthakore	indeed
14:38	nothingmuch	because there are fewer shared assumptions
14:38		2. you can learn and understand each piece separately
14:38		of course that's idealized
14:38		but this does help to solve the framework kool aid problem
14:39		the downside is that you need to get educated to use such code
14:39	kthakore	jsut add water?
14:39	nothingmuch	neither really applies to an SDL binding though
14:39		it's just one component thick ;-)
14:39	kthakore	yup
14:39	nothingmuch	the framework kool aid problem = when it's all or nothing, like a rails app
14:39	kthakore	easy for a API noob like me
14:40	nothingmuch	(you gotta drink the kool aid, or you don't get anything out of it)
14:40	kthakore	ok
14:40		nothingmuch: so I guess these are my goals
14:40		Easy to use ( i.e. intuitive)
14:40		Easy to Extend
14:41		Hard to Misuse
14:41	nothingmuch	worry about that second one afterwords IMHO
14:41		XS::Object::Magic pretty much takes care of it
14:41	kthakore	shameless plug eh?
14:41		:P
14:41	nothingmuch	well, that's what it's for
14:41		and it's rafl's code
14:41		i just packaged it=)
14:41	kthakore	ok
14:42		I wanted to use it too I tried and failed because I was doing ti wrong
14:42	nothingmuch	that's fine
14:42		it doesn't matter yet
14:42	kthakore	I know
14:42		ok Easy to Use means this to me
14:42	nothingmuch	i think the hard to misuse point is important to focus on
14:42	kthakore	me too
14:42	nothingmuch	because C code is very easy to misuse
14:42	kthakore	oh hell yes!!
14:42	nothingmuch	so you want to walk a fine line between faithfully exposing the C api
14:43		so that you support everythign SDL supports easily
14:43		no extra limitations
14:43	kthakore	and preventing people from shooting themselves in the face
14:43	nothingmuch	but on the other hand remove all the C idioms that have nothing to do with SDL
14:43		hide them, so that the API is perlish
14:43		BerkeleyDB is an example of how to not do this
14:43	kthakore	nothingmuch: I am going to do slide 8 there and comeback
14:43	nothingmuch	on both points
14:44	kthakore	nothingmuch: you really hate BDB eh
14:44		anyway
14:44	nothingmuch	what i explained yesterday WRT the calling conventions is too C like
14:44		and there's another point
14:44		for instance in the real BDB api all operations go through the transaction handle
14:44		which can be a pain but is flexible
14:44		BerkeleyDB makes that into an instance variable
14:44		so you set the active transaction for a DB handle
14:44		this gets VERY error prone
14:45		and is more limiting
14:45		so basically, too little perlishness on the caling convention, too much on the componentization
14:47	kthakore	whats wrong with just exposing all of SDL C as it is ?
14:48		SDL C already follows most of the stuff I am reading in this slide
14:49		nothingmuch: I mean we can trust Developers and give them all the sharp pointing things
14:49		/s/pointing/pointy
14:50	* garu	points at nothingmuch's "but on the other hand remove all the C idioms that have nothing to do with SDL" as an answer to kthakore's question
14:51	kthakore	garu: ok thn
14:52		I am trying to understand
14:52		whats is a C idiom
14:53	garu	<nothingmuch> one of the things that drives me insane with berkrleydb is if ( $db->get($key, my $var) == 0 ) { return $var } else { croak $BerkeleyDB::Error }
14:53		<nothingmuch> that's just retarded
14:53		<nothingmuch> my $var = $db->get($key); # that's perlish
14:53		<nothingmuch> and it should either die on real errors, and return undef when $BerkeleyDB::Status == DBNOTFOUND
14:54		kthakore, some things in the C SDL API may be optimized for C constructs
14:54	kthakore	ok
14:54		so how about we do one thing at a time
14:54	garu	while we can haz teh powa of Perl
14:55	kthakore	and then move C idioms to PErl idioms?
14:55		as we see them
14:55		?
14:55		it would be ideal to me if everything in SDL_perl not SDL::Game was in XS
14:55		and extendible with XS::Auto::Magic wahtever
14:56	garu	well, let's do what magnet's been doing, and what nothingmuch said as well
14:56		forget current Perl SDL implementation for a while
14:56		what is the SDL API?
14:56		(in C)
14:56		what does it do, and how does it do it
14:57		then we figure out why it does some things instead of others (is it because it's actually easier to code with, or just a C idiom)
14:57	kthakore	SDL is a low level cross platform framebuffer acess library
14:58	garu	and then we figure out how we want it to be in Perl SDL
14:58		after we settled, we check what is already done
14:58		fix what's broken, implement what's missing
14:59	kthakore	ahh now I get this
14:59		in Perl SDL I want it like Moose
14:59		is that bad?
14:59	garu	it depends on what do you mean by "like Moose"
15:00	kthakore	ok
15:00		well this is what I mean
15:01		SDL->run_video( fullscreen => 0, ...)
15:01	garu	lovely
15:01		spec it out
15:01		fill up the wiki
15:01	kthakore	fin
15:02	* kthakore	mutters under his beard (if he had one)
15:02	garu	I think we have something of a dichotomy here... SDL Perl needs to be -fast-, but it also needs to be -easy-
15:04	nothingmuch	kthakore: wrt extensibility you have two things
15:04		1. you can always wrap
15:04		delegation is more extensible than inheritence
15:04		2. using XS::Object::Maigc you can allow subclasses to add extra fields
15:04		and wrap the accessors
15:05		so that's a non issue
15:05	kthakore	ok
15:05	nothingmuch	so really, don't worry about it yet
15:05	kthakore	so I am doing this
15:05		hold on first
15:05		read C API
15:05	nothingmuch	the only problem with the current way is that it uses T_PTROBJ which means you need to extend it with inside out style attributes
15:06	kthakore	see what is absolutly nessceray
15:06	nothingmuch	yep
15:06	kthakore	then remove everything else
15:06	nothingmuch	what do you mean/
15:06	kthakore	well for eaxmple
15:07	nothingmuch	the way I see it you have two choices, given a C function that works on a struct
15:07		you can either have a minimal XS wrapper that just passes the arguments through
15:07		or you can do things in the XS wrapper that modify the interface
15:07		if you do only the first way then you get a very faithful port
15:07	kthakore	take a look at SDL/Constants.pm
15:07	nothingmuch	(see like what SWIG produces, for instance)
15:07	kthakore	that is what I mean
15:08	nothingmuch	you thik that's gratuitous?
15:08	kthakore	nothingmuch: no I just meant focus on core stuff first
15:08	nothingmuch	ah
15:08	kthakore	then come to other stuff
15:08	nothingmuch	yes
15:08	kthakore	I need 0.01
15:08	nothingmuch	i agree
15:08	kthakore	first
15:08	nothingmuch	\not even
15:09		imagine you were writing this from scratch
15:09		what would it look like?
15:09	kthakore	esactly
15:09	nothingmuch	don't actually rewrite it from scratch
15:09		then look at what You have and figure out what is the least amount of work to get the most amount of benefit
15:09	kthakore	I don't want to write 10 millions lines of spec and then comeback and have to go through all that shit
15:09	nothingmuch	don't write a spec
15:09		just play around
15:09		create mock ups
15:10	kthakore	or unit tests
15:10	nothingmuch	i.e. if youw ere to write the tetris game again
15:10		you could create mock objects with Moose
15:10		that pretend to be idealized SDL objects
15:10	kthakore	ah ok
15:10	nothingmuch	that let you plauy with the API
15:10		it doesn't even have to compile/run
15:11	kthakore	acme: garu: wanna help :P
15:12	nothingmuch	once you have a vague idea you can convert 1-2 real .xs impls
15:12		see what kind of work has to be done
15:12	kthakore	ok
15:12	nothingmuch	cut corners, but make sure you deal with real world problems
15:12	kthakore	oh shit $work time
15:12		brb &
15:12	nothingmuch	and that should give you a pretty good idea of what yuou've got, what you could have, and what you'd have in an ideal world
15:13		basically, JFDI ;-)
15:13		too much talk
15:15	* acme	nods
15:17	garu	that's basically what we've been doing with SDL::Game::Rect, is it not?
15:17	nothingmuch	what's the diff between SDL::Game::Rect and SDL::Rect?
15:18	kthakore	SDL Game extends SDL
15:18	nothingmuch	yes i know =)
15:19	kthakore	so Rect has stuff like collision and things
15:19	nothingmuch	ok
15:19	kthakore	garu is the masteblunderer behind that
15:19		:P
15:19	nothingmuch	so that sounds like a real subclass
15:19	kthakore	yup
15:19	nothingmuch	it's not something directly provided by the SDL library
15:19	kthakore	nope
15:19	nothingmuch	ok, so the tetris game might be a bad example
15:19	kthakore	SDL is super super low level
15:20	nothingmuch	think of how you'd create just a graphical demo
15:20		something which doesn't really need extras
15:20		that works well with just the low level types
15:20		but that can demonstrate what might be tedius or crufty in the current api
15:22	garu	nothingmuch, Game::Rect has all of Rect accessors but also implements moving, other relative accessors (like bottom, center, etc), collision detection between one or more rects, etc
15:23		nothingmuch, we're working on a pong tutorial which only uses rects and event polling. Could it be a good example?
15:24	acme	yet again the conflict between raw SDL and perlish or more useful wrappers
15:24	garu	yes
15:24	* acme	wonders if we can steal anything from PyGame / XNA
15:24	garu	of course we can
15:24		where do you think Game::Rect came from? :
15:24		:)
15:25		it's basically pygame's rect implementation, with a little more sugar
15:26	kthakore	and spice!
15:26	garu	so SDL becomes "everything nice"? :)
15:27	* acme	isn't sure about the _ip methods in that
15:28	acme	and i think the method names need more underscores. centery sounds like a vegetable
15:28	nothingmuch	yes
15:28		spell it out
15:28	garu	YES
15:28		I was actually typing this :)
15:29	nothingmuch	i actually really want to write Acme::Symbol::Optimize
15:29		which makes your program "faster" by removing vowels from symbol tables
15:29	garu	what I did was borrow all names and functionality from pygame's rect verbatim
15:29		so we have their crappy names and know what-does-what
15:30		but we really really really need to "fix" those :)
15:30		like the _ip ones
15:30		acme, what would you suggest we do?
15:30		nothingmuch, ^^
15:32	nothingmuch	http://c2.com/cgi/wiki?IntentionRevealingNames
15:32	garu	(pygame's rect API delivers a new (changed) rect for almost all method calls, leaving the original intact. In order to change the original, the dev needs to call ->$method_ip (for "in place"))
15:32	nothingmuch	how often is _ip needed?
15:32		and what are the rules for inclusion
15:33		(again, my SDL n00b shines here)
15:33		is a rect owned by a canvas?\
15:33	garu	how often, no idea (SDL n00b myself)
15:33	nothingmuch	or can it be shared and used as a simple value type?
15:33	garu	rules for inclusion, no idea what you mean
15:33	nothingmuch	well, a rectangle has an absolute position, right?
15:33		that always struck me as odd
15:33	garu	owned by canvas? no - a rect is just a x,y,w,h struct
15:33	kthakore	_ip is used sooooo much I cry myself to bed
15:34	nothingmuch	because it mixes knowlege about itself (its width and height) and knowlege about its context
15:35	kthakore	nothingmuch: thats because the rect acts as a placeholder (read accessor) for almost every game object
15:35	nothingmuch	given this blech it seems like _ip is probably very necessary in practice
15:35		so how do you move a rectangle
15:35		without using _ip?
15:35	kthakore	rect->x = new x
15:36	nothingmuch	no
15:36		i mean with the modified clone it returns
15:36	kthakore	oh
15:36	nothingmuch	do you need to locate it in its parent, remove the old one and replace?
15:36	kthakore	remove old and replace
15:36	nothingmuch	what is the notion of identity/ just pointer equality?
15:37	kthakore	pointer equality for the most part
15:37	garu	I always thought _ip should be the rule, and if someone wanted a new one they'd just my $newrect = $oldrect->clone->move(x,y,w,h);
15:37	kthakore	but I have done deeper checks if needed
15:37	nothingmuch	http://lambda-the-ultimate.org/node/3040
15:38	garu	brb &
15:38	nothingmuch	haskell's SDL bindings provide no _ip variants
15:39	acme	that makes sense
15:39	kthakore	yes
15:39		you can go all absolute
15:39		or do relative fairly easily
15:39		no need for ip if you don't need to use it
15:39		$rect->x($rect->x++)
15:40		but its nice to do
15:40	nothingmuch	no no
15:40		in haskell's bindings Rect is not mutable
15:40		you can only clone
15:40	kthakore	ewww no
15:40		thats a waste
15:40	nothingmuch	not really
15:40		read that worlds article
15:40	kthakore	ok
15:40	nothingmuch	i'm not saying ti should be this way
15:41	acme	so far bouncy doesn't mutate Rects
15:41	nothingmuch	cloning means you can share things
15:41		safely
15:41	kthakore	yeah good point
15:41	nothingmuch	so it's always a tradeoff
15:41		there's no clear cut rule that one is more efficient than the other
15:41	kthakore	... I have always not used clone because I am efficiency freak
15:41		well if you are using less rects per game
15:42		I have found it to be faster
15:42		usually
15:42		but it is not the case
15:42	nothingmuch	that's a fallacy in perl though
15:42	kthakore	s/less rects per game/less rects per frame/
15:42		how so ?
15:42	nothingmuch	orders of magnitude
15:42	kthakore	ah
15:42	nothingmuch	it's not incredibly slow to clone
15:42		it's marginally slower
15:43	kthakore	right
15:43	nothingmuch	of course, there's always the NeXTStep approach
15:43		MutableRect isa Rect
15:43		but that's hard to subclass (requires a parallel hierarchy)
15:43		infinite tradeoffs =)
15:44	* kthakore	is getting woozy
15:45	nothingmuch	basically immutability tends to pay off on the large scale
15:45		because you can make sweeping assumptions
15:45		that are impossible to make even if there is just a single mutable object
15:45		for instance if you are implementing a redraw
15:45		and your domain objects are immutable
15:45		you never need to check if they have changed
15:45		only if the set of objects has changed
15:46		if you have identical objects than they can share a single representation type
15:46		etc etc
15:47	acme	mmm, undo
15:47	nothingmuch	also, that =)
15:47	kthakore	acme: but there is no undo in games (unless if you are doing like time travel shit(
15:47	nothingmuch	undo is for free, and undo log cleanup is provided automatically using garbage collcetion
15:48	kthakore	ok
15:48	nothingmuch	there is undo for other things
15:48	kthakore	so how do I do an immutable move of say a ball
15:48	nothingmuch	not necessarily graphics rel`ated
15:48	kthakore	ok
15:48	nothingmuch	but a game decision tree for instance invovles lots of backtracking
15:48	kthakore	indeed
15:48		but thats game algorithms
15:48	nothingmuch	so if you need to clone game objects to make a decision and then backtrack
15:48	kthakore	nothing to do with SDL structs
15:48	nothingmuch	and those game objects hold references to SDL structs
15:49	kthakore	oh I see what you mean
15:49	nothingmuch	if you can clone the SDL objects that's great
15:49		you limit yourself to just cloning
15:49		if you must modify in place, then you are fucked
15:49		you need to separate the two steps
15:49	kthakore	but if I am just moving an object wouldn't it be better just to mutate
15:50	nothingmuch	first search/backtrack, then finalize a decision, then modify the graphics objects
15:50		http://conal.net/Fran/
15:50		=)
15:50		maybe, maybe not
15:51	garu	acme, I skimmed through bouncy, and I might be wrong, but it appears the only reason you're not changing your rects is because you made them simple width/height containers, and kept x and y as outside variables
15:51		I'm not sure why you did $bat = Rect->new (0 0 w h) and then $bat_x and $bat_y separately
15:52	acme	and that's why i can it a work in progress
15:53	garu	oh... I thought maybe that was something we needed to work on... like Rect not working or not providing the api you required for the game
15:53		(it was not at all meant as criticism, forgive me if it sounded like that)
15:53		it's just that the argument was revolving on immutable rects
15:54	nothingmuch	(fwiw, i'm not suggesting SDL_perl goes immutable, i'm just making the case that someone might want to use them immutably and there are legitimate reasons)
15:54	garu	ah, ok
15:55	kthakore	I think its valid to have both
15:55		if we think of SDL Rects as brushes on the canvas of the screen
15:55	garu	I'm not well experienced in game creation, it just somehow struck me as odd because I figured _ip should be the rule, not the exception
15:56	kthakore	then there is no point changing the brush to another same brush of same color and just move it
15:56	nothingmuch	it is the rule
15:56	kthakore	garu: it is the rule
15:56	garu	cool
15:56	nothingmuch	http://conal.net/Fran/tutorial.htm # this demonstrates it's an arbitrary rule though
15:56	kthakore	garu: in C you move the rect
15:56	garu	but, if it is, we should change Game::Rect to do everything "in place" instead of having crappy-named _ip methods
15:57		and add some underscores on other methods while we're at it :)
15:57	nothingmuch	there are another of other appraoches
15:57		probably all not worth considering
15:57		1. my $copy = $rect->x(3); # immutable, but $rect->x(3); # mutable
15:58		context sensitivity is often a bad idea
15:58		but it's another option
15:58	kthakore	ooj I like this motion = 0.7 ^ vector2XY (cos time) (sin (2 time))
15:58	nothingmuch	2. the MutableRect vs. ImmutableRect thingy can be coded as a flag on the object
16:02	kthakore	$work
16:02		bb
16:23	acme	now for something crazy: can we call it Rectangle?
16:23		(it's Rect in sdl of course)
16:26		actually, on a slightly more serious note, is Rect going back to -width etc? there are lots of things in the core which use it
17:13	kthakore	acme: we can call it anything
17:13		but Rect is fine imo
17:14		acme: I am still working on it but I think the SDL:: Layer is going to be as close to XS as possible
17:14		and teh SDL::Game::* Layer is going to provide all the nice things
17:14		the SDL C Library is extremly well designed
17:15		it is good for what it means to do
17:15	acme	yes, i think that's best
17:15	kthakore	that way developers can choose to go whichever way they want to go
17:16		I am not worrying about back compat mind you .. yet
17:16		if needed we can add a thin layer of SDL::Compat
17:16		but as of now I don't care about lecagy anymore
17:17		as I am working on FB too so I can help it migrate
17:20		acme: design wise the real change is not a Monolithic SDL.xs
17:20		so XS for each SDL:: module
17:20		garu: I played around with how I think a binding should be
17:21		garu: and my feeling is that there are no areas in SDL C libraries Design wise. If we stick to their API we will get the most out of their library
17:22		oops
17:22		I meant to say I haven't found any failings in SDL C libraries design wise
17:23	acme	fantastic ;-)
17:23	garu	kthakore, how about acme's complaints about Audio handling? maybe just wrap it around a higher layer, but keep the core (C) SDL API as is?
17:23	kthakore	SDL::Game::Audio
17:23	garu	cool
17:23		wrapping it is :)
17:24	kthakore	SDL::Game::App so on
17:24		SDL::Game = nice stuff
17:24		SDL:: = hardcore rage!!!
17:24		:)
17:24		so I am discontinuing SDL::App from 2.4 on
17:25		all the extra crud if absolutely needed goes to SDL::Game
17:25		SDL:: is bindings to C API nothing more
17:25		nothing less
17:26	acme	so that's a first step
17:26	kthakore	yup
17:27		I don't like a library or namespace doing more then 1 thing
17:28		acme: garu: so from now on if you guys are working on SDL::Game lib base your access points straight from the SDL C API docs
17:28		as SDL:: is going to major overhaul
17:28	garu	roger roger
17:29	kthakore	I will make a wiki page on how naming conventions are going to work from original SDL method names
17:30	* acme	heads for dinner
17:30	garu	that should give magnet++ enough fuel
17:30	kthakore	ye
17:30		indeed
17:30		garu: also 1.2.14 is the last 1.2.x release of SDL C API
17:30		that should be our focus
17:31		as it works Mac 10.6\|10.4, Window 7\|XP\|Vista, and linux 100%
17:31		it is in prerelease right now
17:31		1.3 isn't due for another year
17:31		or so
17:32		enough time to catch up
17:33		so this brings me to the next area of trouble
17:33		Alien::SDL
17:33		any clues on how we get people SDL + SDL libs?
17:34		right now it checks for sdl-config (which will fail because some packagers don't include it) or build from scratch
17:34		and only exception is download binaries for windows
17:34		which is only 32 bit
17:35		anyway $work plus cramming for midterm
17:35		so gtg
17:50		j03 joined #sdl
18:00	garu	kthakore, you can try loading the library or something
18:25	kthakore	garu: not sure what you mean?
18:25		garu: distribute SDL with binaries ?
18:26		oh you mean try to compile the XS
18:26		but thats not possible without knowing where the headers are
19:40		szabgab joined #sdl
19:42	kthakore	hi szabgab
19:45	szabgab	rehi
19:45	kthakore	szabgab: whats up?
19:45	szabgab	just came home from teaching
19:46	kthakore	oooh teaching? SVN? Perl?
19:47	szabgab	perl
19:47	kthakore	nice
19:47	szabgab	I showed them frozen bubble but they were not impressed :-(
19:47		we need something they might get impressed :-)
19:48	kthakore	ok
19:48		what do you suggest?
19:48		Tetris
19:48		if they are not impressed by tetris kick them out :P
19:48		szabgab: breakout ?
19:49		szabgab: feel free to make a ticket
19:49		[Ticket] Make impressive game!
19:49	szabgab	:-)
19:49	kthakore	szabgab: as a course material have them design a Perly game!!!
19:49	szabgab	I have no idea what impressive would mean here
19:50	kthakore	Moose + Perl + SDL PErl
19:50	szabgab	I am not sure corporation will like that :-)
19:50	kthakore	awww :P
19:50		it is teaching them Moose (OOP) in a fun way
19:51		szabgab: and how C bindings can work in Perl (better performance)
19:51		szabgab: I can sugar coat anything :P
19:59		szabgab: what do you think?
20:00	szabgab	that I need to do other things now
20:00		and the course is over anyway
20:00	kthakore	awww
20:00		ok
20:01		szabgab: just saying you can't just come in here and say FB is unimpressive and just leave
20:01	szabgab	nope, I beat them up
20:01	kthakore	yay
20:01	garu	++
20:01	kthakore	indeed
20:02	garu	we gotta work on Sigil
20:02	kthakore	hmm indeed
20:02	garu	and make a top view original warcraft example
20:02	kthakore	ok
20:02		garu: jsut make tickets and I do or try doign
20:03	garu	kthakore, I think we need to focus on both things here
20:03		making SDL
20:03		and making SDL games, that would give us a better grasp of what SDL::Game needs
20:04		like acme is doing
20:04		and like you did
20:05	kthakore	ok so its your turn now
20:05		garu: go make Sigil and I will help
20:05		I want to decrudify SDL too though
20:06	garu	heh
20:06		one step at a time
20:06		I can't figure out Sigil unless I finish pong
20:06	kthakore	ok
20:06	garu	so I'll do pong
20:06	kthakore	ok
20:06	garu	while you do SDL
20:06	kthakore	lol that seems fair :P
20:06	garu	then we switch
20:06		you do $other_games
20:06	kthakore	ok
20:06	garu	while I work on SDL::Game::$Foo
20:06	kthakore	I can do both but it just cuts time
20:07		garu: I think you should do SDL::Game::Surface and use Pong as guide for that
20:07	garu	kthakore, I just wish we could have Game::Rect working for yapc
20:07		so pong can rely on it
20:07	kthakore	we do don't we
20:07		what doesn't work int it?
20:07		I tested everything
20:08	garu	it's not on cpan
20:08		:)
20:08	kthakore	oh
20:08		um .. but if I put it up super Back Compat break
20:08	garu	but I don't want to rush things
20:08	kthakore	FB no longer works?
20:08	garu	yeah
20:08	kthakore	how about this
20:08		get FB from my repo
20:08		try to make it run with master branch
20:09		it will just be a matter of cah a lot of Rect->new
20:09	garu	we just can't release a tutorial based on repo code
20:09	kthakore	indeed
20:09		read last few lines
20:09		then I will release SDL Perl on CPAN and Release FB as is on CPAN too
20:10	garu	hmm
20:10	kthakore	this will force Alais to start making it pretty
20:10	garu	I don't want to rush things
20:10	kthakore	me niether but this is the only way I see Rect ending up on CPAN for now
20:10	garu	too much on my plate for you to depend on me getting things done
20:10		no worries
20:10	kthakore	:)
20:11	garu	we write the tutorial with standard Rect then
20:11	kthakore	get me more minions !!!!
20:11		ok
20:11		np
20:11	garu	and update it when the time comes :)
20:11	kthakore	whatever you want
20:11	garu	save the world a step at a time
20:11	kthakore	yup!
20:12		Also I am spending next couple days making a gazillion amount of Test Cases and Docs
20:12		for SDL redesign
20:12		if you need help you know where I lurk
20:12		oh garu forgot
20:14		this is the design for new major namespaces SDL:: -> SDL::General SDL::Video SDL::Window SDL::Events SDL::Mouse ...
20:14		then we have the structs
20:14		SDL::Surface so on
20:14		because some fuctions have no objects
20:15		http://www.libsdl.org/cgi/docwiki.cgi/SDL_API is where I am getting this from
20:15		garu: magnet acme what do you think?
20:16		bb &
20:17	garu	I think a new (empty) branch would be in order :)
20:19	acme	looks good to me. i've got the beginnings of a pure-XS Color class
20:22	kthakore	yay!!!
20:22		garu: this should also fix the constants export problem
20:22		for example SDL::Window will have window specific constants
20:22		SDL::Mouse mouse specific constants
20:22		so on
20:23		so if you never need a mouse for you game you just don't use SDL::Mouse and the constants are not exportable
20:24		acme: new branch?
20:24		I make it now
20:25		acme: its the redesign branch
20:25		acme: its a fork of the master
20:25		acme: go ahead and code where ever you need in that branch
20:26		I will work on organizing and making test cases which will move your code around a lot at the begining
20:27		acme: at this point it might be a good idea for you to fork
20:28		acme++
20:38		acme: garu: here is the ticket for that http://sdlperl.ath.cx/projects/SDLPerl/ticket/36
20:39		please feel free to modify in anyway
20:41	acme	yay, it passes tests
20:42	kthakore	yay!!!
20:42		acme++
20:43		garu: here I made the ticket for you http://sdlperl.ath.cx/projects/SDLPerl/ticket/37
20:43	acme	will finish it up tomorrow. nn!
20:43	kthakore	acme: gnight
20:43		acme: see the ticket if you get time
20:43		acme: 36
20:44	acme	kthakore: yup, looks great
20:44	kthakore	ok great
20:44		acme: are you going to fork or push onto the redisgn branch?
20:45	acme	will push onto redesign
20:45	kthakore	acme: ok :P
20:46		nothingmuch: this is what we ended up agreeing on ... http://sdlperl.ath.cx/projects/SDLPerl/ticket/36
20:46		nothingmuch: garu: acme: ok bye's gtg
20:46		class + midterm time :(
21:04		TonyC joined #sdl
21:27		KatrinaTheLamia joined #sdl