#pentagram@irc.freenode.net logs for 26 Sep 2006 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:24:20] --> watt has joined #pentagram
[00:24:20] --- ChanServ gives channel operator status to watt
[00:52:42] <-- etomek has left IRC ()
[01:22:27] --> SB-X has joined #pentagram
[01:40:17] --> Keal has joined #pentagram
[09:05:10] --> Kohlrabi has joined #pentagram
[09:47:41] <-- SB-X has left IRC (Read error: 110 (Connection timed out))
[09:53:57] --> SB-X has joined #pentagram
[11:31:36] <-- Kohlrabi has left IRC ("Quit")
[11:41:59] <-- Colourless has left IRC ("casts improved invisibility")
[11:47:27] <-- Kirben has left IRC ("System Meltdown")
[11:50:06] --> Kirben has joined #pentagram
[11:50:06] --- ChanServ gives channel operator status to Kirben
[12:18:43] <-- Kirben has left IRC (Read error: 60 (Operation timed out))
[12:59:00] <-- servus has left IRC (Read error: 60 (Operation timed out))
[12:59:57] --- LordNAway is now known as Lord_Nightmare
[13:06:53] --> servus has joined #pentagram
[13:12:49] <-- watt has left IRC ()
[13:37:33] --> Kohlrabi has joined #pentagram
[13:38:05] --> watt has joined #pentagram
[13:38:05] --- ChanServ gives channel operator status to watt
[13:44:32] <-- SB-X has left IRC ("*casts gate travel*")
[13:59:36] --> SB-X has joined #pentagram
[15:19:26] <-- Keal has left #pentagram ()
[15:23:07] --> Keal has joined #pentagram
[15:24:03] <-- Keal has left IRC (Client Quit)
[15:24:46] --> Keal has joined #pentagram
[15:25:32] --> servus_ has joined #pentagram
[15:25:47] <-- servus has left IRC (Read error: 110 (Connection timed out))
[17:04:12] <-- SB-X has left IRC (Read error: 104 (Connection reset by peer))
[17:10:42] --- Lord_Nightmare is now known as LordNAway
[17:40:21] --> wjp has joined #pentagram
[17:40:21] --- ChanServ gives channel operator status to wjp
[17:44:05] <-- watt has left IRC ()
[17:45:38] --> watt has joined #pentagram
[17:45:38] --- ChanServ gives channel operator status to watt
[17:48:38] <watt> well... pulled the scummvm repository... from the root... probably should've only grabbed trunk
[17:48:43] <watt> 1.01 Gb
[17:49:11] <watt> oh well, guess I'll keep it around until I need more space
[17:51:52] <wjp> it's fairly large :-)
[18:09:01] <watt> their OS X builds do seem pretty straight forward, although I am having a bit of difficulty finding the bits that make it universal - should only be some CFLAGS
[18:11:13] <wjp> there was a large thread on the scummvm forums some time ago on the subject
[18:14:00] <wjp> http://forum.scummvm.org/viewtopic.php?t=1069
[18:24:10] <watt> hmm... it mentions using lipo to put the intel and ppc builds together, but I don't think that's what is currently being done (couldn't see references to lipo in the makefile)
[18:24:26] <watt> I'll have to build it sometime when I'm not at work ;-)
[18:25:12] <watt> Although, this is beginning to change my opinion of fink & darwinports (macports)
[18:25:59] <watt> I still don't like the idea of suppling applications with it, but dev tools and libraries do actually make sense.
[18:36:21] <wjp> and some point I'll have to get a mac myself :-)
[18:42:51] <watt> increasingly popular choice ;-) I recommend all but the cost.
[18:43:38] <watt> This was a bit more expensive than I should have went for.... but hopefully it'll last 3-5 years before I want an upgrade.
[18:45:32] <watt> If I wasn't obsessed with being able to game (strangely something I don't do that much on here - quake3 is the newest thing I've run in a while), then a regular macbook would have sufficed
[18:45:51] <watt> and cost a grand less... *cough*
[18:47:11] <servus_> How would you make a universal binary without lipo?
[18:48:41] <watt> you can supply -x86 -ppc to gcc while building the objects and each object will be "fat", linking takes care of the rest
[18:49:49] <servus_> -x86 and -ppc? Weird, I've never even seen those. I've used "-march=i686" and "-arch ppc", then I lipo it.
[18:51:38] --- servus_ is now known as servus
[18:51:56] <watt> well, at least I think I read that.... can't find the source off the top of my head
[19:02:26] <watt> ahh... actually it is "-arch x86 -arch ppc"
[19:02:44] <watt> just tried it on hello world
[19:03:37] <servus> Interesting! I've been using lipo
[19:03:52] <servus> I don't like the whole -framework syntax for things like SDL though.
[19:07:31] <watt> I figure lipo is more for when you do something lower level, assembly or entirely different source files
[19:07:54] <watt> or you just wanna be extra sure they work independently.
[19:08:46] <watt> or something completely custom, like a screen saying "Sorry, we don't support PPC, please upgrade, you n00b"
[19:08:52] <watt> ;-)
[19:09:46] <watt> the framework stuff is a big NeXT-ism
[19:10:34] <watt> (does it handle include paths too? I don't remember"
[19:17:22] <watt> It's especially fun for that code that originally worked on NeXTstep and needed porting to windows after OpenStep was discontinued from Apple
[19:19:49] <watt> Framework support under GNUstep was a bit, er, fun. So we link them like normal libraries here.
[19:21:03] <watt> Not sure how well (or if) it works presently, but we got everything working and decided not to touch anything afterward
[19:26:47] <watt> The product we ship here is a crazy mix of objective-c (very nice language IMO) and windows programming (embedded activeX stuff
[20:00:45] * servus bemoans Java's seemingly slow network stream buffering.
[20:01:51] <watt> a specific java app or general case?
[20:02:55] <servus> To retrieve HTTP content, I use URL -> URLConnection -> InputStreamReader -> BufferedReader, then continue to call myBufferedReader.readLine(), and it's slooooooooow. while( (ch = is.read()) != -1 ) is also sloooooow, but seems equivalent in speed (or faster!) than BufferedReader...
[20:04:20] <servus> I seem to have come up with a decent workaround : Making a byte [] buf = new byte[65535] and then is.read( buf ); every inner loop of while( (ch = is.read()) != -1 )... and that seems to help a LOT. Oh well. What a bummer. Sorry for the OT talk :)
[20:05:28] <watt> I find it interesting.. think I may have encountered this before.....
[20:12:17] <watt> yup, I read 1024 at a time when uploading license keys to a webapp I worked on... and the license keys were evil... but that's besides the point
[20:12:54] <watt> byte[] buffer = new byte[1024];
[20:12:54] <watt> for (int length = ufin.read(buffer); length > 0; length = ufin.read(buffer))
[20:31:24] <servus> Hm, little simpler than what I was doing, but I seemed to have been having problems with truncated input
[20:34:31] <servus> At least it's not only me. I was only reading around 100KB with the obvious method and it was taking *minutes*!
[20:39:49] <watt> I figure the buffer in the BufferedReader tries to shift the buffer after every read by the amount asked for... making it inefficient if only one byte is read at a time... you would think the javadocs would say something along these lines, but I don't think they do.
[20:46:42] <servus> I just wanna myURLConnection.blockUntilFinished(), then .readAll() :) -- Interestingly, the deprecated class InputFilterStream (subclass of I think HTTPConnection) has a readFully() method which blocks.
[22:09:57] <-- Darke has left IRC (Read error: 104 (Connection reset by peer))
[22:11:36] <-- watt has left IRC ()
[22:18:31] <-- Kohlrabi has left IRC ("Quit")
[22:25:33] --> Darke has joined #pentagram
[22:33:36] --> Kirben has joined #pentagram
[22:33:36] --- ChanServ gives channel operator status to Kirben
[22:44:02] --> watt has joined #pentagram
[22:44:02] --- ChanServ gives channel operator status to watt
[23:03:09] --> Colourless has joined #Pentagram
[23:03:09] --- ChanServ gives channel operator status to Colourless
[23:40:55] --- LordNAway is now known as Lord_Nightmare