| *** Pseudonym has joined #Aqsis | 00:09 | |
| *** render has quit IRC | 01:03 | |
| *** scorp007 has joined #aqsis | 04:03 | |
| scorp007 | hi | 04:04 |
|---|---|---|
| *** ShortWave has quit IRC | 04:29 | |
| *** ShortWave has joined #aqsis | 04:30 | |
| scorp007 | hi ShortWave | 04:36 |
| ShortWave | hiya | 04:36 |
| scorp007 | how's development on Neqsus going? | 04:37 |
| ShortWave | it's going | 04:37 |
| scorp007 | well, I assume? | 04:37 |
| ShortWave | for the moment | 04:37 |
| ShortWave | I think I'm going to hit a brick wall soon, where I have to wait on the next blender release tho | 04:38 |
| scorp007 | ok -- do you basically generate a rib on the fly, then invoke the render command as a separate process? Or do you link directly against the library? | 04:38 |
| ShortWave | option #1 | 04:39 |
| scorp007 | well, you don't have to wait for the next release, you can stay up to date with the cvs | 04:39 |
| ShortWave | well | 04:39 |
| ShortWave | the CVS is less than stable | 04:39 |
| scorp007 | hmmm... anyone good with latex here? | 04:44 |
| scorp007 | nevermind, worked it out | 05:41 |
| *** ShortWave has quit IRC | 06:16 | |
| *** Pseudonym has quit IRC | 06:23 | |
| *** Pseudonym has joined #Aqsis | 06:28 | |
| *** render has joined #aqsis | 07:26 | |
| *** pgregory has joined #aqsis | 07:48 | |
| *** ChanServ sets mode: +o pgregory | 07:48 | |
| pgregory | morning all | 07:57 |
| *** pgregory sets mode: +vvv scorp007 render Pseudonym | 07:57 | |
| Pseudonym | G'day. | 07:57 |
| pgregory | hi Andrew | 07:58 |
| pgregory | was thinking about that binary/XML thing a little | 07:58 |
| *** joeedh is now known as joeedh_walk | 07:58 | |
| Pseudonym | Yeah? | 08:00 |
| pgregory | how does it work in the case of different content types? | 08:01 |
| pgregory | i.e. we might have a buffer full of chars, shorts, longs or floats. | 08:01 |
| Pseudonym | Good question. | 08:01 |
| pgregory | if they are chars, for examples, surely we don't actually want to do any reordering at all. | 08:01 |
| pgregory | ? | 08:02 |
| Pseudonym | Sure. | 08:02 |
| Pseudonym | Well, htons() and ntohs() work on "shorts". | 08:02 |
| Pseudonym | and htonl() etc work on "longs". | 08:02 |
| Pseudonym | s == short, l == long | 08:02 |
| pgregory | yeah | 08:02 |
| pgregory | presumably, a float can be treated as a long? | 08:02 |
| Pseudonym | Presumably, yes. | 08:02 |
| Pseudonym | Via a packed C union, for example. | 08:02 |
| Pseudonym | double would be a bit tricker. | 08:03 |
| pgregory | we don't deal with doubles in the display interface | 08:03 |
| Pseudonym | Right. | 08:03 |
| pgregory | ok, looks like I need to take the elementsize into consideration when packing the data. | 08:05 |
| Pseudonym | Right. | 08:05 |
| pgregory | not too bad, I just hope all this packing/encoding doesn't hit the transfer time too much. | 08:06 |
| pgregory | might need to look into threading to handle this. | 08:06 |
| pgregory | also, if you've got a moment, would appreciate your thoughts on another part of this, code design related. | 08:07 |
| Pseudonym | OK | 08:09 |
| Pseudonym | Shoot. | 08:09 |
| pgregory | right, the XML packets for the messages are modelled very heavily on the Dspy interface data, making them a simple 'forwarding' mechanism. | 08:09 |
| Pseudonym | Sure. | 08:10 |
| pgregory | so at the moment, I simply package up the data passed into the DspyImageOpen function into an XML packet. | 08:10 |
| pgregory | within the DspyImageOpen function. | 08:10 |
| Pseudonym | Right. | 08:10 |
| pgregory | but I'd like to separate this functionality a bit, message classes semm overkill, as they would be transient, resulting in effectively a useless class with a constructor that builds the message and sends it. | 08:11 |
| pgregory | but I'd still like to have it abstracted a bit for maintenance reasons, I have a couple of ideas, wondered if you had any thoughts. | 08:11 |
| Pseudonym | Let me check one thing. | 08:12 |
| Pseudonym | I assume the new fancy framebuffer is in two parts. | 08:12 |
| Pseudonym | One a Dspy shared object, the other the GUI code, right? | 08:12 |
| pgregory | right | 08:12 |
| Pseudonym | OK, just checking. | 08:12 |
| pgregory | the Dspy server is very lightweight, or will be, just packaging up the data into XML and sending it off to the app. | 08:13 |
| Pseudonym | Sure. | 08:13 |
| Pseudonym | Hmmm. | 08:13 |
| Pseudonym | How are you packaging XML? | 08:13 |
| pgregory | TinyXML | 08:13 |
| Pseudonym | Are you using some standard XML library? | 08:13 |
| Pseudonym | Right. | 08:13 |
| Pseudonym | So you're building an XML tree, sending it, then destroying the tree. | 08:13 |
| pgregory | yes | 08:13 |
| Pseudonym | Seems to me that it's only once per frame. | 08:13 |
| Pseudonym | Is it worth optimising? | 08:14 |
| pgregory | for the open, yes, but not for the data. | 08:14 |
| pgregory | I'm not really worried at this point about optimisation, just clean coding. | 08:14 |
| Pseudonym | Right. | 08:14 |
| pgregory | do you think it's reasonable to just have the XML build/send/teardown in the Dspy??? functions? | 08:15 |
| Pseudonym | I don't see why not. | 08:15 |
| pgregory | with no further abstraction? if so, I'm happy to go with that, just wanted to find the 'right' solution. | 08:15 |
| Pseudonym | Yeah, it seems fine, especially for now. | 08:15 |
| pgregory | cool, glad you said that, that's what I was leaning to. | 08:16 |
| Pseudonym | :-) | 08:16 |
| Pseudonym | It's simple, and it works. | 08:16 |
| pgregory | all other abstraction methods I've thought of seemed over complicated for the task, hiding for the sake of hiding. | 08:16 |
| Pseudonym | Yeah. | 08:16 |
| *** joeedh_walk is now known as joeedh | 08:16 | |
| Pseudonym | It's just a stub. | 08:16 |
| Pseudonym | I don't think there's any point building internal abstraction layers. | 08:17 |
| Pseudonym | Especially if TinyXML is easy to use. | 08:17 |
| pgregory | very easy/clean | 08:17 |
| *** Anteru has joined #aqsis | 08:26 | |
| Anteru | Morning | 08:26 |
| pgregory | morning Anteru | 08:27 |
| Pseudonym | G'day. | 08:27 |
| *** pgregory sets mode: +v Anteru | 08:27 | |
| Anteru | What's up? | 08:30 |
| Anteru | How should I progress with program_options ... ? I can work on it locally with Boost 1.34 beta but it will break any pre-1.34 build with VC8 :/ | 08:30 |
| pgregory | sounds like a good reason to stick with what we've got, especially as it works. | 08:31 |
| pgregory | it isn't broken, it doesn't have any known problems/weaknesses, so why replace it? | 08:31 |
| scorp007 | sounds like a bug in boost. (Or perhaps they made a workaround for VC8 in the beta.) | 08:32 |
| Anteru | No, it's a bug in VC8 being too aggressive in their checks ... | 08:32 |
| Anteru | More or less | 08:32 |
| scorp007 | I personally don't see how being 'too strict' is a bug -- unless they violate the standard in doing so. | 08:34 |
| pgregory | Anteru: what problem does using boost::program_options solve? | 08:34 |
| *** AlexK has joined #aqsis | 08:34 | |
| Pseudonym | There's a new Boost release soon, isn't there? | 08:35 |
| scorp007 | pgregory, my guess would be potentially cleaner code, in not having to reinvent the wheel. I could be wrong though... | 08:35 |
| scorp007 | pgregory, although, if it involves existing working code, that may not outweigh it's advantage. | 08:36 |
| scorp007 | involves rewriting* | 08:36 |
| pgregory | we're not 'reinventing' the wheel, we already have a wheel. | 08:37 |
| Pseudonym | Seems to me that rewriting existing code plus breaking compilers that we use is a lose-lose. | 08:37 |
| scorp007 | right. | 08:37 |
| pgregory | agreed | 08:37 |
| scorp007 | if we didn't have a wheel, it might have made more sense | 08:37 |
| Pseudonym | If it wasn't for the broken compiler issue... then if someone wanted to do the rewrite and make the code cleaner, well, that's cool. | 08:38 |
| Anteru | Yeah, that was the original intention :/ | 08:40 |
| Anteru | Didn't suspect boost 1.33.1 would break VC8 :( | 08:40 |
| Pseudonym | Gotta go. | 08:48 |
| Pseudonym | Night everyone. | 08:48 |
| Anteru | Bye | 08:48 |
| *** Pseudonym has quit IRC | 08:48 | |
| *** cgTobi has joined #Aqsis | 08:50 | |
| *** ChanServ sets mode: +o cgTobi | 08:50 | |
| cgTobi | morning all | 09:10 |
| *** Anteru has quit IRC | 09:21 | |
| *** renderguy has joined #aqsis | 09:53 | |
| renderguy | Morning all | 09:53 |
| renderguy | .TGIF! | 09:53 |
| *** AlexK has quit IRC | 09:59 | |
| cgTobi | Hi LEon | 10:28 |
| *** cgTobi sets mode: +v renderguy | 10:28 | |
| renderguy | cgTobi: Moin, how is/was German? | 10:41 |
| renderguy | cgTobi: German == Germany. | 10:41 |
| cgTobi | 127.0.0.1 sweet 127.0.0.1 | 10:42 |
| cgTobi | :) | 10:43 |
| renderguy | cgTobi: :-) | 11:00 |
| *** Anteru has joined #aqsis | 11:01 | |
| *** Joron has joined #Aqsis | 11:30 | |
| renderguy | Joron: Morning. | 11:33 |
| Joron | Hello | 11:34 |
| cgTobi | Leon, have you tried to build svn 1020? | 11:34 |
| renderguy | cgTobi: Not yet, why? | 11:51 |
| cgTobi | I have problems with mkstemp() | 11:53 |
| cgTobi | just wanted you to confirm it | 11:53 |
| cgTobi | as soon as I switch back to mktemp() it works fine. | 11:53 |
| cgTobi | I need to investigate that after lunch | 11:53 |
| cgTobi | bbl | 11:53 |
| renderguy | cgTobi: Which OS is that issue under? | 11:54 |
| *** Anteru has quit IRC | 12:06 | |
| *** Joron has quit IRC | 12:14 | |
| cgTobi | renderguy: OSX | 12:22 |
| renderguy | cgTobi: What error do you get (message)? | 12:27 |
| * renderguy notices the Win32 build seems to be okay, though Linux also has issues now. | 12:28 | |
| cgTobi | build/shadercompiler/aqsl/aqslcomp.cpp:163: error: invalid conversion from 'int' to 'char*' | 12:29 |
| renderguy | cgTobi: Yep, same issue on Linux. | 12:29 |
| cgTobi | Ah, IC | 12:30 |
| renderguy | Anyone know the difference between 'mktemp()' and 'mkstemp()'? | 12:30 |
| pgregory | security on Windows I think, I thought AndyB's change should only have affected Windows. | 12:31 |
| renderguy | pgregory: Quite the opposite. ;-) | 12:31 |
| cgTobi | not really :) | 12:33 |
| cgTobi | #ifdef AQSIS_SYSTEM_WIN32 | 12:33 |
| cgTobi | tempname = _mktemp( ifile ); | 12:33 |
| cgTobi | #else | 12:33 |
| cgTobi | tempname = mkstemp( ifile ); | 12:33 |
| cgTobi | #endif //AQSIS_SYSTEM_WIN32 | 12:33 |
| pgregory | oops, my mistake | 12:33 |
| pgregory | aha, this is why I hadn't used mkstemp before (I do wish people would read the logs before making changes). | 12:34 |
| renderguy | cgTobi: Is that your fix or what's currently in the code? | 12:35 |
| pgregory | mktemp returns the name of a temporary file, mkstemp creates the file, which is no good to us, as we need the name to pass through to the preprocessore. | 12:35 |
| cgTobi | renderguy: that's the current code | 12:35 |
| pgregory | that change needs to be rolled back | 12:35 |
| renderguy | pgregory: Perhaps using 'tempfile()' would be a better soltion? | 12:37 |
| renderguy | pgregory: http://unixhelp.ed.ac.uk/CGI/man-cgi?tempfile+1 | 12:38 |
| pgregory | a) tempfile is a tool, not a function, b) it still creates a file, we need a filename. | 12:39 |
| renderguy | pgregory: My mistake, what is wrong with 'mktemp()' anyway? | 12:41 |
| pgregory | there is a known race condition. | 12:41 |
| pgregory | if you call mktemp, get a 'safe' filename back, and before you create the file, another process calls mktemp and gets the same 'safe' filename back, you're stuffed. | 12:42 |
| renderguy | pgregory: K, but has it ever caused us an issue yet? | 12:43 |
| pgregory | no | 12:43 |
| renderguy | pgregory: Guess we have our fix/answer then. ;-) | 12:44 |
| pgregory | the 'fix' is to change the way we do preprocessing, but as our preprocessing is based on a thirdparty preprocessor, it's difficult to make the changes we need. | 12:45 |
| *** Auralis has quit IRC | 12:49 | |
| *** Auralis has joined #aqsis | 12:49 | |
| pgregory | it is a definite problem, and something we should be wary of, and change if/when we can. | 12:50 |
| *** cgTobi sets mode: +v Auralis | 12:52 | |
| *** mafm has joined #aqsis | 13:16 | |
| mafm | hi | 13:16 |
| pgregory | hi mafm | 13:20 |
| *** pgregory sets mode: +v mafm | 13:20 | |
| renderguy | mafm: Afternoon. | 13:23 |
| mafm | :) | 13:30 |
| renderguy | mafm: How are you projects going? | 13:37 |
| mafm | which projects, do you mean school projects? | 13:45 |
| renderguy | mafm: Yep. | 13:46 |
| mafm | I'm trying to finish a compiler for one of the subjects and that's almost finished | 13:46 |
| mafm | but the other ones are delayed :S | 13:46 |
| mafm | I think that I'll have to leave some of the projects/subjects for a better occasion | 13:48 |
| mafm | btw, I don't know whether there are things which need preparation before SOC projects start, besides the SVN account? | 13:54 |
| pgregory | we'll need to setup a branch for you to work in, although you should be able to do that yourself if you want, once you're commit authorised. | 14:00 |
| mafm | I mean if there's anything else to do before I start? I don't think so | 14:02 |
| *** Anteru has joined #aqsis | 14:03 | |
| pgregory | no, don't think so | 14:04 |
| mafm | goody | 14:08 |
| *** cgTobi has quit IRC | 14:22 | |
| pgregory | WARNING: new-framebuffer branch is broken, don't update! | 14:50 |
| pgregory | gotta go, cya all later. | 14:50 |
| *** pgregory has left #aqsis | 14:50 | |
| *** scorp007 has quit IRC | 14:55 | |
| renderguy | tcolgate: You around? | 14:57 |
| mafm | I haven't seem him on-line for weeks | 15:27 |
| renderguy | mafm: He must be busy, ill or on holiday. | 15:36 |
| mafm | hole that it's the latter :) | 15:37 |
| mafm | I have to go now, see you | 15:37 |
| *** mafm has quit IRC | 15:37 | |
| *** Anteru has quit IRC | 15:43 | |
| *** renderguy has quit IRC | 16:11 | |
| *** Anteru has joined #aqsis | 17:26 | |
| *** cgTobi has joined #Aqsis | 17:38 | |
| *** ChanServ sets mode: +o cgTobi | 17:38 | |
| *** Anteru has quit IRC | 17:54 | |
| *** cgTobi has quit IRC | 17:55 | |
| *** joeedh is now known as joeedh_biking | 20:48 | |
| *** joeedh_biking is now known as joeedh | 21:08 | |
| *** cgTobi has joined #Aqsis | 22:47 | |
| *** ChanServ sets mode: +o cgTobi | 22:47 | |
| *** cgTobi has quit IRC | 22:47 | |
| *** render has quit IRC | 23:16 | |
| *** joeedh is now known as joeedh_class | 23:16 | |
| *** render has joined #aqsis | 23:17 | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!