← Previous day | Index | Channel Index | Today | Next day → | Search | Google Search | Plain-Text
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 00:42 | TonyC | strangely enough, my old Imager::SDL code works with the current CPAN SDL |
| 01:01 | kthakore | yay!!! |
| 01:01 | back compat for the win | |
| 01:03 | TonyC | Imager::SDL is pretty low-level too (it's mostly C) |
| 01:50 | kthakore | yay |
| 01:50 | where can I see it? | |
| 01:54 | nothingmuch: if you are back | |
| 01:54 | how can I get Object to take null for -height or -width | |
| 01:54 | Argument "-width" isn't numeric in subroutine entry at /usr/local/lib/perl/5.10.0/SDL/Object.pm line 13. | |
| 01:54 | if they are given 0? | |
| 01:55 | I mean I want to give 0 default if null for those values | |
| 01:56 | nothingmuch | kthakore: that's the XS stuff |
| 01:56 | it needs to handle undef | |
| 01:57 | though in this case it sounds like you're mixing positional and named? | |
| 01:57 | kthakore | no frozenbubble does this sometimes |
| 01:57 | Rect->new( -x => 0, -y => 0) | |
| 01:58 | nothing for width or height | |
| 01:58 | I want to return 0 as that is what SDL::NULL is | |
| 03:29 | garu | kthakore, SDL has funny constants |
| 03:29 | wtf is a "HAT" ? | |
| 03:29 | or a "NOPARACHUTE" ? | |
| 03:44 | also... what -are- sdlpm.t tests | |
| 03:45 | it tests for "in" and "verify" | |
| 03:45 | but only does tests for "in" | |
| 03:45 | and I can't find any documentation for those | |
| 03:45 | nor any tests for any of the actual funcions (Init, GetError, etc) | |
| 06:13 | kthakore, refactored Constants.pm on master, and did constants.t testing them | |
| 06:13 | oh, also updated tickets and created a couple new ones | |
| 06:14 | g'night & | |
| 10:35 | kthakore | garu++ |
| 10:36 | garu: there is a script that used to generate the constants.pm | |
| 10:36 | it would be nice if we can use it again | |
| 10:36 | its in scripts/ | |
| 10:36 | I am busy the whole day so I am off | |
| 11:19 | saorge joined #sdl | |
| 14:42 | garu | 'k... that would be even better |
| 15:04 | kthakore | there is a README in there |
| 15:04 | we can hook it into Build.PL | |
| 15:05 | once you make it do whatever you want | |
| 15:05 | garu: oh morning btw | |
| 15:07 | garu | kthakore, morning :) |
| 15:10 | kthakore | OH HAI |
| 15:11 | garu: did you try bouncy yet? | |
| 15:11 | acme's breakout | |
| 15:12 | garu | kthakore, I couldn't..../Build still fails here for master SDL Perl |
| 15:12 | let me paste it for you | |
| 15:12 | kthakore | garu: maybe you can fork that and use you SDL::Game::Rect in it to show for YAPC::Brazil |
| 15:12 | ok paste it | |
| 15:12 | :( | |
| 15:13 | garu | funny.... now it passed |
| 15:13 | :P | |
| 15:13 | * acme | notes bouncy is a work in progress, i'm going to change it all once i have my head around the problem space |
| 15:14 | garu | oh, I'll definitely show it off, just like tetris and lander |
| 15:14 | acme | \o/ |
| 15:14 | kthakore | we need lander pics |
| 15:14 | \0/ indeed | |
| 15:14 | garu | yeah, working on that too... can you create a ticket for it and assign it to me, kthakore ? |
| 15:14 | kthakore | sure |
| 15:15 | garu | thanks |
| 15:15 | anyway, I won't dabble in internals except to say bouncy is written in Moose :) | |
| 15:16 | kthakore | garu: would it be possible to launch the site during YAPC::Brazil |
| 15:16 | if possible? | |
| 15:16 | garu | I hope so |
| 15:16 | I'll try to make some progress later tonight | |
| 15:16 | sorry for neglecting it | |
| 15:17 | kthakore | I ain't blaming |
| 15:17 | garu | I know.. I am :) |
| 15:17 | kthakore | I just see it as a potential for work to be done on it |
| 15:17 | ok just as long as someone is balming :P | |
| 15:18 | balming? | |
| 15:18 | wth | |
| 15:18 | garu | hmm... do I have to install the github version before running bouncy? I tried perl -I../path/to/github_SDL/lib boucy.pl but it failed |
| 15:18 | kthakore | yes |
| 15:18 | github has new mixer stuff | |
| 15:18 | which will hook into XS so XS needs to be compiled | |
| 15:19 | so build it then do -I../ whatever | |
| 15:19 | garu | yeah, but I ./Build it already... just didn't ./Build install |
| 15:19 | kthakore | hmm I dunno |
| 15:19 | garu | that's what I did |
| 15:19 | kthakore | you guys are the wizards in that area |
| 15:19 | i dunno ask acme how he does this | |
| 15:20 | garu | I don't want to install it until we have it frozen bubble compatible |
| 15:20 | guess I'll just use local::lib :) | |
| 15:20 | kthakore | me neither I use lo |
| 15:20 | goddamn stop reading my miND!!! | |
| 15:20 | OO | |
| 15:21 | garu: we are pretty close to FB compat | |
| 15:22 | I just have this error to fix | |
| 15:22 | garu | :) |
| 15:22 | kthakore | Argument "-height" isn't numeric in subroutine entry at /usr/local/lib/perl/5.10.0/SDL/Object.pm line 13. |
| 15:22 | I dunno where in Object this error is occuring | |
| 15:22 | garu | it works for width but not for height? |
| 15:22 | kthakore | as we can send null for -height and -width |
| 15:23 | garu | ahn |
| 15:23 | kthakore | I fixed the XS |
| 15:23 | just need Object to do this somehow | |
| 15:23 | oh btw SDL/Object is what makes both (0,0,0,0) and (x => 0, ... so on works | |
| 15:24 | we will move it to XS once it works as expected | |
| 15:24 | garu | weird... my pull on SDL_perl doesn't have Object.pm |
| 15:24 | kthakore | experimental branch |
| 15:24 | garu | hmm... I'm on master, not experimental |
| 15:24 | yeah | |
| 15:24 | kthakore | STOP READING MY MIND!!!! |
| 15:25 | garu | sorry, can't help it |
| 15:25 | :P | |
| 15:25 | how did you do it...I don't see how this can be easily achieved | |
| 15:26 | I mean, (1, 2, 3, 4) could be interpreted as (1=>2, 3=>4) | |
| 15:26 | kthakore | nothingmuch magic not mines |
| 15:26 | garu | hmm |
| 15:26 | kthakore | I am still wrapping head around |
| 15:27 | I got it last night | |
| 15:27 | garu | but now you lost it again? :) |
| 15:27 | kthakore | no I mean I got the code only last night |
| 15:27 | so haven't had a chance to grok it into my mental image of SDL | |
| 15:27 | Perl | |
| 15:27 | garu | ah |
| 15:27 | 'k | |
| 15:28 | kthakore | I think it occurs here _parse_pos_hash |
| 15:28 | in that sub there is a map | |
| 15:28 | that I have no clue what it does | |
| 15:28 | but I thinks it doesn't like undef or null | |
| 15:28 | I need to rewrite the undef to SDL::NULL | |
| 15:29 | which is just 0 | |
| 15:29 | nothingmuch | garu: it compares the length |
| 15:29 | garu: the subclass has to declare all the positional parameters | |
| 15:29 | kthakore | yay |
| 15:29 | no I can go back to studying | |
| 15:29 | nothingmuch meet garu | |
| 15:29 | bye yall | |
| 15:29 | nothingmuch | ->_new_pos([qw(x y h w)], @args) # if @args == 4 then it's positional |
| 15:29 | it's kinda kludgy | |
| 15:30 | honestly i'd rather see it only work for @args == 1 and ref $args[0] eq 'ARRAY' | |
| 15:30 | i'm not sure what code relies on SDL::Rect->new(1, 2, 3, 4) | |
| 15:30 | kthakore | not much |
| 15:30 | we can get rid of it | |
| 15:30 | sorry acme | |
| 15:30 | nothingmuch | the ambiguous case is when you have optional fields |
| 15:30 | kthakore | acme: you will have to go back to old hash way |
| 15:30 | nothingmuch | if you pass half of the possible options |
| 15:31 | then it may be misparsed as positional | |
| 15:31 | e.g. Rect->new( x => 1, y => 2 ); # h and w omitted | |
| 15:31 | kthakore | nothingmuch: garu: what if we keep old way of doing this? |
| 15:31 | ohhh thats why | |
| 15:31 | ok | |
| 15:31 | I understand the error now | |
| 15:31 | nothingmuch | i think Rect->new([ 1, 2, 3, 4 ]) # best |
| 15:31 | kthakore | what about the old hash way? |
| 15:32 | where a HV is parsed? | |
| 15:32 | only | |
| 15:32 | no positional | |
| 15:33 | nothingmuch | yeah sure |
| 15:33 | that's even simpler | |
| 15:33 | i thought people really wanted positoinals for some reason | |
| 15:33 | garu | nothingmuch, nice... I was actually thinking the other way around... making non-positional the rule and testing @args == 1 and ref $args eq 'HASH' |
| 15:34 | nothingmuch, but this would be easier, yeah | |
| 15:34 | * acme | can change |
| 15:34 | * garu | can change as well |
| 15:34 | nothingmuch | that's usually annoying because if you want to provide defaults you have to do call->({ %$args, extra }) |
| 15:34 | instead of ->call( @args, @extra ) | |
| 15:34 | where @extra should override @args | |
| 15:34 | obviously you can still call ->_new(1,2,3,4) | |
| 15:35 | garu | the problem with named args is that it's long... but it's easy enough to wrap it around an array ref, yes |
| 15:36 | nothingmuch | you're optimizing for writing |
| 15:36 | garu | yes I am |
| 15:36 | :) | |
| 15:36 | nothingmuch | why? |
| 15:36 | * kthakore | is off this conv now ... :) |
| 15:36 | garu | because writing should be easy for newcomers |
| 15:36 | nothingmuch | so typing a string is harder than remembering an offset? |
| 15:36 | i don't see how | |
| 15:36 | also, reading existing code is much easier when the code is self documenting | |
| 15:37 | garu | I agree. But while named arguments is easy to look at and understand what it's doing, (x,y,w,h) is way shorter and it's not hard |
| 15:38 | I'm not saying to change all occurrences | |
| 15:38 | just Rect's | |
| 15:38 | nothingmuch | well, it's not my place to argue |
| 15:38 | but I think that is all that is wrong with C in a nutshell | |
| 15:38 | kthakore | nothingmuch: garu: this is what we need to do for optionals in Rect, it is nessecary for SDL calls |
| 15:38 | http://github.com/kthakore/SDL[…]b/SDL/Rect.pm#L44 | |
| 15:39 | nothingmuch | kthakore: it's much simpler to do that in the XS |
| 15:39 | kthakore | yay!! |
| 15:39 | nothingmuch | also, why is both -top and -y supported? |
| 15:39 | that allows ambiguous constructions like ->new( -top => 1, -y => 2 ) | |
| 15:40 | which with this will silently use the -y | |
| 15:40 | kthakore | nothingmuch: dunno thats the way it was when I got the code |
| 15:40 | nothingmuch | instead of producing an error |
| 15:40 | blech | |
| 15:40 | kthakore | this is very legacy |
| 15:40 | nothingmuch | yeah |
| 15:40 | ok | |
| 15:40 | so my suggestion: | |
| 15:40 | forget everything for now | |
| 15:40 | kthakore | change it if you need |
| 15:40 | ok done!!! | |
| 15:40 | nothingmuch | argue with garu a bit |
| 15:40 | kthakore | whut where the hell am I |
| 15:40 | ... | |
| 15:40 | garu | what, me? |
| 15:40 | kthakore | who are you ppl :P |
| 15:40 | nothingmuch | figure out what the idealized constructor args should be |
| 15:40 | and code for that | |
| 15:40 | *then* add backwards compatibility | |
| 15:41 | including dashes, aliases, shortcuts, whatever | |
| 15:41 | kthakore | garu: C style or hash style ? |
| 15:41 | nothingmuch | with a nice way to warn for deprecation |
| 15:41 | i think C style would be very incosnsitent | |
| 15:41 | typing a letter and and an arrow is a lot easier than trying to remember the order of things | |
| 15:41 | esp. if you're used to high level code | |
| 15:41 | garu | nothingmuch, I was suggesting ->new( { -x, => 10, -y => 20, ... } ), just like it is today but with a hashref |
| 15:41 | kthakore | but C style is performance wise faster |
| 15:42 | less complex code | |
| 15:42 | nothingmuch | every single time I try to remember what order 'margin' is in CSS i give up and add 'margin-top: ...; margin-bottom: ...' margin-left: ...' |
| 15:42 | that style kinda sucks | |
| 15:42 | garu | indeed |
| 15:42 | nothingmuch | because you need to clone and copy the hash |
| 15:42 | instead of just appending or prepending more key/value pairs | |
| 15:42 | kthakore | yup |
| 15:42 | nothingmuch | and btw please please kill the leading dash |
| 15:42 | it's so useless | |
| 15:42 | kthakore | I so want to do that!!! |
| 15:42 | so legacy | |
| 15:42 | garu | nothingmuch, also legacy :) |
| 15:43 | nothingmuch | ignore legacy for a minute =) |
| 15:43 | too many competing concerns | |
| 15:43 | kthakore | but FB is build on it and I think I will have to rewrite it |
| 15:43 | garu: nothingmuch FUCK LEGACY | |
| 15:43 | nothingmuch | compatibility is possible |
| 15:43 | kthakore | I took decision |
| 15:43 | there | |
| 15:43 | nothingmuch | no no |
| 15:43 | fuck legacy when trying to decide what you want to have | |
| 15:43 | kthakore | thats what I am saying |
| 15:43 | nothingmuch | once you've settled on what you actually want, then figure out how to add compat |
| 15:44 | but don't let legacy cloud your judgement about what things *should* be | |
| 15:44 | so issues I can see: | |
| 15:44 | kthakore | I like this SDL::Rect->new( -x=> ...) |
| 15:44 | nothingmuch | 1. leading dashes are meaningless |
| 15:44 | kthakore | oops no has |
| 15:44 | nothingmuch | 2. there are ambiguous option names |
| 15:44 | kthakore | dash |
| 15:44 | nothingmuch | 3. it's unclear what is optional and what isn't, and how it should behave |
| 15:44 | kthakore | nothingmuch: taking 1 + 3 |
| 15:44 | nothingmuch | 4. it's unclear if you're allowed to subclass |
| 15:45 | kthakore | can we not do this |
| 15:45 | -x is optional x is not optional? | |
| 15:45 | nothingmuch | 5. it's unclear whether or not there are default values |
| 15:45 | acme | please don't make up syntax |
| 15:45 | nothingmuch | yeah, please don't |
| 15:45 | kthakore | ok |
| 15:45 | nothingmuch | Moose/Class::Accessor/Object::tiny etc are all pretty consistent |
| 15:45 | acme | or you'll end up like POE |
| 15:45 | nothingmuch | i would stick to that |
| 15:45 | kthakore | acme: sssssh ... dngor is in here |
| 15:45 | nothingmuch | note that this also applies to accessors |
| 15:46 | I think a good standard is | |
| 15:46 | Rect->new( width => ..., height => ..., x => .., y => .. ) | |
| 15:46 | verbose, descriptive names | |
| 15:46 | garu | wait, wait... I updated SDL::Rect's documentation a while ago... it says "By default, x, y, height and width are all set to 0" |
| 15:46 | nothingmuch | but with an allowance for shorthand |
| 15:46 | (i.e. one letter) | |
| 15:46 | when it's unambiguous | |
| 15:46 | garu | ah |
| 15:46 | I see | |
| 15:47 | nothingmuch | garu: that's what it is, but is it what it shoudl be? |
| 15:47 | how often does it actually make sense to create a 0 sized rectangle at pos 0,0? | |
| 15:47 | kthakore | nothingmuch: yes default 0 on pretty much everything |
| 15:47 | thats how SDL understands NULL | |
| 15:47 | SDL::NULL is 0 | |
| 15:47 | nothingmuch | so is that like undef? |
| 15:48 | or is it literally position (0,0)? | |
| 15:48 | kthakore | yes and no |
| 15:48 | for x and y its 0, 0 | |
| 15:48 | nothingmuch | ok |
| 15:48 | so that's a distinction | |
| 15:48 | garu | nothingmuch, do you think we should take into consideration compatibility with other SDL projects in different languages? |
| 15:48 | nothingmuch | potentially |
| 15:48 | garu | like pygame, for instance? |
| 15:48 | nothingmuch | my point is, decide on something |
| 15:48 | make it clear and simple | |
| 15:48 | easy to implement, easy to use, easy to read | |
| 15:49 | and *then* figure out all the yak shaving needed for compat | |
| 15:49 | kthakore | garu: thats what our slogan is |
| 15:49 | nothingmuch | which can be done using a deprecation wrapper |
| 15:49 | so for instance if you use deprecated features you might get bad performance now, a deprecation warning in some future version, or a runtime error even later on | |
| 15:49 | garu | nothingmuch, we will most definitely need your help with all that :) |
| 15:49 | kthakore | yup :) |
| 15:49 | nothingmuch | just keep in mind that i've never used SDL |
| 15:49 | i don't know what is good and bad | |
| 15:50 | kthakore | nothingmuch: no problem we will tell you |
| 15:50 | nothingmuch | someone who has needs to make the decisions about what the API should be like |
| 15:50 | i think acme is in a good position for this | |
| 15:50 | kthakore | yes |
| 15:50 | garu | acme++ |
| 15:50 | kthakore | acme: you are on now |
| 15:50 | *echo( | |
| 15:50 | nothingmuch | another thing to keep in mind is performance |
| 15:50 | in perl most of the cost is in the number of opcodes | |
| 15:50 | many things that seem more expensive than others aren't really | |
| 15:51 | garu | kthakore also has experience on SDL game design |
| 15:51 | kthakore | garu: game design ... not SDL API specifically though |
| 15:51 | nothingmuch | i suspect that creating 1 million Rects per second on commodoty hardware would be nice to have |
| 15:51 | kthakore | I am still learning SDL API |
| 15:51 | nothingmuch | but if a better API makes that drop to 500k |
| 15:51 | kthakore | yes |
| 15:51 | nothingmuch | which is a 50% reduction (!!!) |
| 15:51 | that's probably still nothing to worry about | |
| 15:52 | kthakore | nothingmuch: Rect is the equivalent of Accessors to SDL |
| 15:52 | nothingmuch | because any game code that would have to create these rects needs to calculate the proper values for them |
| 15:52 | garu | nothingmuch, so it would be expensive elsewhere, yes |
| 15:52 | nothingmuch | and doing that would probably be an order of magnitudde more costly than rect construction |
| 15:52 | of course, that's no excuse for an order of magnitude degredation in construction times | |
| 15:52 | kthakore | yup |
| 15:53 | which is why I like the straight binding to SDL | |
| 15:53 | then do extending in SDL::Game layer | |
| 15:53 | nothingmuch | but if someone really needs to create millions of objects per second then they can just drop to C for that tight loop i guess |
| 15:53 | kthakore | for nicities |
| 15:53 | nothingmuch | yes |
| 15:53 | but even in the SDL:: layer | |
| 15:53 | garu | nothingmuch, I told kthakore once we had things working (and not before) we should profile some SDL Perl games... to figure out potential bottlenecks |
| 15:53 | nothingmuch | yep |
| 15:53 | that's a good plan | |
| 15:54 | kthakore | garu: lets do it on Tetris, and Breakout and Frozen Bubble |
| 15:54 | it would be like | |
| 15:54 | nothingmuch | basically what Im saying is that just the overhead of wrapping is going to introduce probably an order of magnitude of slowness on top of the C api |
| 15:54 | kthakore | yup |
| 15:54 | nothingmuch | so if it's slower or faster by a small factor, that doesn't actually matter |
| 15:54 | kthakore | but if most of the Code is forced into XS we should be fine |
| 15:54 | nothingmuch | anyway, so SDL peeps, please figure out how you would want to code with SDL in 2 years |
| 15:55 | what the ideal low level wrapper API should look like | |
| 15:55 | (tip: look at the BerkeleyDB api, and then do the opposite) | |
| 15:55 | kthakore | and then come bug you? :) |
| 15:55 | garu | heh |
| 15:55 | kthakore | heh |
| 15:55 | nothingmuch | things to look out for: |
| 15:55 | params | |
| 15:56 | optional, default, named or positional, the meaning of out of band values | |
| 15:56 | (C uses 0 or -1 usually, when perl has undef, which is no longer in band) | |
| 15:56 | perl can also completely omit an optional param | |
| 15:56 | garu | nothingmuch, any thoughs on ambiguity? Like -w vs. -width ? |
| 15:56 | nothingmuch | whereas in C it still has an in band value |
| 15:56 | my gut feeling says to make the canonical field name be 'width' and allow 'w' as an alias | |
| 15:57 | but that's just me | |
| 15:57 | ... also how are errors handled | |
| 15:57 | garu | so "full names" as default, no ambiguity warnings on runtime? |
| 15:57 | in case ->new( w => 1, width => 2) ? | |
| 15:57 | 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 } |
| 15:58 | that's just retarded | |
| 15:58 | my $var = $db->get($key); # that's perlish | |
| 15:58 | and it should either die on real errors, and return undef when $BerkeleyDB::Status == DBNOTFOUND | |
| 15:58 | expecting me to do that every time is just sadistic | |
| 15:58 | there's no gain whatsoever | |
| 15:58 | and the only reason it does it this way is because the C api looks like that | |
| 15:59 | i don't think he did it for performance reasons | |
| 15:59 | but supposing he did, the overhead of doing so many error checks, probably 10x as many opcodes as just doing the logic in C | |
| 15:59 | is probably so much slower than just providing perlish semantics | |
| 16:00 | that it makes all code that uses BerkeleyDB either slow and safe, or negligiably faster and error prone | |
| 16:00 | i think he did it out of lazyness | |
| 16:00 | staying faithful to the API means that you don't have to think about how it should behave | |
| 16:01 | kthakore | man I am so glab we have an irc log now |
| 16:01 | nothingmuch | anymoose, i'm done ranting =) |
| 16:01 | kthakore | ok |
| 16:01 | nothingmuch | IMHO don't merge anything I did |
| 16:01 | kthakore | well let us mull over |
| 16:01 | nothingmuch | just keep it in mind as a possibility |
| 16:01 | kthakore | nothingmuch: never did |
| 16:01 | nothingmuch | it demonstrates that it can be easily made to be flexible, is all |
| 16:02 | kthakore | nothingmuch: we will make a ticket for this |
| 16:03 | nothingmuch: consider registering on the trac site | |
| 16:03 | nothingmuch: all this stuff will go in the redesign milestone | |
| 16:04 | http://sdlperl.ath.cx/projects[…]/Enter%20Redesign | |
| 16:05 | oh you are there thanks | |
| 16:05 | ok I gtg study or I am gonna fail | |
| 16:05 | nothingmuch++ thanks so much | |
| 16:07 | nothingmuch | =) |
| 16:09 | garu | acme, did you spot any "this should be sweeter" SDL things yet during bouncy coding? |
| 16:18 | dngor | Hey, now. Moose makes up way more syntax than POE does. |
| 16:20 | You take an array slice of @_ an' everybody be hatin'. Sheeit. | |
| 16:29 | acme | garu: a bunch of the C calls have multiple options, 99% of the time you will completely ignore |
| 16:31 | like int Mix_PlayChannel (int channel, Mix_Chunk *chunk, int loops); | |
| 16:31 | 99% of the time you don't care what channel it is and you only want to play it once | |
| 16:31 | but that's a simple wrapper | |
| 16:31 | garu | acme, they don't have sane defaults? |
| 16:31 | or -any- defaults, for that matter? :) | |
| 16:32 | acme | so i end up doing $mixer->play_channel( -1, $bounce, 0 ), which is silly |
| 16:33 | and not all things are documented. and not all things are implemented | |
| 16:33 | and some things could be their own classes (audio channels look like a good candidate) | |
| 16:34 | garu | yeah... magnet is working on the docs so we have a better understanding of the state of things now |
| 16:35 | acme | but i do see a conflict between a) writing a perl interface to sdl and b) writing a perlish interface to sdl |
| 16:35 | garu | yes, that's one of our problems, and the main reason we did SDL::Game |
| 16:36 | SDL would have exact bindings, while SDL::Game would have a perlish api for game creation on top of it (or something like that) | |
| 16:37 | acme | if you want to change everything, you could always rename it SDL2:: |
| 16:38 | garu | but since some of the perl interface to sdl is already perlish (or at least tries to be), I see little reason not to rethink them |
| 16:38 | * acme | nods |
| 16:38 | garu | I'm not sure I like the idea of SDL2::... sometimes keeping legacy is wrong :) |
| 16:39 | but ultimately it's kthakore's baby, I have no say on this | |
| 16:41 | acme, would you mind helping us spec'ing a new SDL::Audio that would perlishly integrate SDL::Mixer and SDL::Music, taking out the drudge from them and making it DWIM? | |
| 16:42 | you seem to be by far the most knowledgeable of us to do it | |
| 16:42 | and we could really use the help | |
| 16:44 | kthakore | garu: I dub thee godfather of this ugly ugly ugly baby |
| 16:44 | do whatever is nessecary | |
| 16:45 | * kthakore | kthakore goes back to study and closes his irssi window |
| 16:53 | kthakore | oh I forgot make tickets so I can follow |
| 16:59 | acme | i do see one major plus point: libsdl is not a moving target |
| 17:28 | kthakore | yay!! SDL 1.2.14 Pre Release |
| 17:28 | http://article.gmane.org/gmane.comp.lib.sdl/44190 | |
| 17:28 | that is stable now and Snow Leopard Support! | |
| 18:16 | acme | oh, drat, it's still a moving target |
| 18:59 | szabgab joined #sdl | |
| 19:34 | kthakore | acme: its a slow target |
| 19:34 | we can pick one and focus on it | |
| 19:34 | hi szabgab | |
| 19:40 | szabgab_ joined #sdl | |
| 19:41 | kthakore | hi szabgab_ |
| 19:42 | szabgab_ | hi |
| 19:45 | japhb joined #sdl | |
| 19:46 | kthakore | szabgab_: we got some real design questions to sort out now :P |
| 19:46 | szabgab_: nothingmuch pretty much nailed all the things wrong with the old Design | |
| 19:48 | szabgab_ | I am glad you are making progress but if you hope that I can help with software design issues then you are wrong |
| 19:48 | I am really bad at that | |
| 19:48 | kthakore | szabgab_: lol |
| 19:48 | szabgab_: no just informing | |
| 19:49 | szabgab_: and I think pretty much everyone is bad at software design until something once in a while comes along and awes everyone | |
| 19:53 | garu: hi | |
| 19:57 | szabgab_: oh I forgot | |
| 19:58 | szabgab_: we have BREAKOUT!!! acme++ | |
| 19:58 | szabgab_ | :-) |
| 19:58 | kthakore | szabgab_: it is here http://github.com/acme/bouncy |
| 19:59 | szabgab_: you need SDL Perl on github though | |
| 23:43 | hello | |
| 23:43 | TonyC: around? | |
| 23:43 | TonyC: 1.2.14 seems to build on Snow Leopard | |
| 23:43 | TonyC | sort of |
| 23:44 | cool, with the system mixed-mode perl? | |
| 23:44 | kthakore | SDL 1.2.14 is just the C libraries |
| 23:45 | TonyC | do you know if it builds fat libraries? |
| 23:45 | kthakore | http://article.gmane.org/gmane.comp.lib.sdl/44190 |
| 23:45 | * TonyC | looks |
| 23:45 | kthakore | TonyC: As far as I know Latinga said 100% macosx support now |
| 23:46 | TonyC | cool, it says universal binaries |
| 23:48 | ok, it says you don't have a google wave account | |
| 23:48 | wrong channel | |
| 23:50 | kthakore | oooh |
| 23:51 | wanna send me one? | |
| 23:51 | a google wave account I meant | |
| 23:51 | TonyC | they haven't given me any invites to hand out (yet) |
| 23:51 | kthakore | oh ok |
| 23:52 | well just try out SDL 1.2.14 with our github |
← Previous day | Index | Channel Index | Today | Next day → | Search | Google Search | Plain-Text