2007/10/05
IRC [01:42] *** cacru1 parted the chat.
IRC [09:14] *** cacru1 joined the chat.
IRC [09:15] *** cacrus parted the chat.
IRC [09:49] *** _justQ_ joined the chat.
IRC [11:10] *** cacrus joined the chat.
IRC [11:13] *** holycow joined the chat.
IRC [12:29] <_justQ_> Hi
IRC [12:32] <_justQ_> I'm having problems using nsoracle
IRC [12:32] <_justQ_> with oracle 10g
IRC [12:33] <_justQ_> have you had any issues with this combination?
IRC [12:33] <_justQ_> ..unable to alloc 190785760 bytes....
IRC [12:39] <_justQ_> i'm using oracle20g
IRC [12:40] <_justQ_> and aolserver 45
IRC [12:40] <_justQ_> in a linux box
IRC [13:51] *** Snowbal1 joined the chat.
IRC [13:52] *** Snowbal1 parted the chat.
IRC [13:56] <_justQ_> it's fixed now, reduced the stacksize flag from 8192 to 1024 and the maxthreads number. it was a memory problem =).
IRC [13:56] *** _justQ_ parted the chat.
IRC [15:04] *** manyu joined the chat.
IRC [15:05] *** manyu parted the chat.
IRC [15:56] *** daguz parted the chat.
IRC [16:01] *** holycow parted the chat.
IRC [19:24] *** Spark joined the chat.
IRC [19:25] <Spark> good evening
IRC [19:26] <Spark> i've noticed that NsTclNsvUnsetObjCmd releases it's lock on arrayPtr before it finishes operating on the same
IRC [19:27] <Spark> i'm not sure why that is allowed
IRC [19:51] <Spark> ah i think i've worked it out
IRC [19:54] <Spark> by the time the lock is released, the data is effectively thread local
IRC [19:56] *** The_Wuhb joined the chat.
IRC [20:53] <Dossy> :-)
IRC [20:53] <Dossy> Spark, I'm so glad you're reading/understanding the source. It's remarkably clean for a non-trivial body of C code, IMHO -- what do you think?
IRC [20:54] <Spark> i had to learn a sizable chunk of the tcl API :)
IRC [20:54] <Spark> but yeah it's been pretty intuitive stuff
IRC [20:54] <Spark> a lot of tclvar.c is not conceptually very interesting though
IRC [20:55] <Dossy> No, most of it isn't very interesting. That's what makes it so great.
IRC [20:55] <Dossy> It's (a) simple, doesn't try to be all fancy schoolboy-bullshit on you, (b) works.
IRC [20:56] <Dossy> Sometimes, I laugh when I see "really clever" code ... "intersting" solutions to problems ... wholly inappropriate for the most part, but the product of someone who clearly just read some algorithms or systems book and just needed an excuse to code something.
IRC [20:56] <Spark> heh
IRC [20:56] <Dossy> AOLserver really pleases the pragmatic asthete in me. It works well and uses the simple (fine, call it "naive") solution.
IRC [20:57] <Spark> i don't like excessive use of design patterns in OO languages either
IRC [20:57] <Dossy> right
IRC [20:57] <Spark> what i dislike about some c software is macro abuse and stuff like that :)
IRC [20:58] <Spark> it's amazing the hoops people will jump through to avoid duplicating code
IRC [20:59] <Spark> 90% of the time, factoring out a function is good enough (e.g. lockArray etc), and the rest of the time, the maintenance cost of the duplication is not so high
IRC [21:00] <Spark> programmers are usually pretty good at working with idiomatic code
IRC [21:00] <Spark> once you've read one NsTclNsv*ObjCmd, you've read them all :)
IRC [21:12] <Dossy> As long as the code is consistent, yeah.
IRC [21:13] <Spark> we're trying to put our lock inference stuff into a research paper for the "compiler construction" conference, the deadline is next saturday
IRC [21:13] <Spark> do you remember what we intended to do with the aolserver source? :)
IRC [21:16] <Dossy> Vaguely, yeah.
IRC [21:16] <Dossy> Next Saturday? Ouch. How far along are you? :-(
IRC [21:16] <Spark> it's no so bad, we haven't written the paper yet, but it doesn't need to be too long
IRC [21:17] <Spark> the main issue is finishing the implementation so we can make a nice table of results
IRC [21:17] <Spark> over the last couple of years, there have been a few attempts at lock inference, and someone decided that aolserver was a good case study and stress test for the algorithms involved
IRC [21:18] <Dossy> Right.
IRC [21:18] <Dossy> The previous papers.
IRC [21:18] *** The_Wuhb parted the chat.
IRC [21:18] <Spark> yeah, and they annotated the code with various stuff to make this possible
IRC [21:18] <Spark> the best and most recent effort didn't like tclvar.c very much, taking 2000 seconds to process it or something :)
IRC [21:19] <Spark> so we figured that we should try that file as well
IRC [21:19] <Spark> but our implementation uses a toy OO language, so i had to translate tclvar.c into that
IRC [21:20] <Spark> it actually maps rather well, although some of the functions don't really belong in any particular class, so they have been put in classes at random :)
IRC [21:21] <Dossy> :-)
IRC [21:21] <Dossy> ouch, OO. yeah.
IRC [21:21] <Dossy> that is the path of much pain, I bet.
IRC [21:22] <Spark> we don't even have public/private
IRC [21:23] <Spark> so it's a bit of a token effort
IRC [21:23] <Spark> i was going to dump the code into a pastebin for you but it seems my ssh session has frozen up
IRC [21:25] <Dossy> d'oh
IRC [21:35] <Spark> http://rafb.net/p/HmtfxF56.html
IRC [21:36] <Spark> there's also stubs and half-arsed implementations of bits of tcl in there
IRC [21:36] <Spark> since our toy can't do calls out to c libraries
IRC [21:36] <Spark> and it wouldn't be able to analyse their behaviour anyway
IRC [21:38] <Spark> the atomic sections designate where the locking code should be inserted
IRC [22:25] <Dossy> Hmm.
IRC [22:25] <Dossy> I wonder how/if this affects the actual analysis
IRC [22:28] <Spark> if the tcl code clearly has visible side-effects, we've made sure that the stubs also cause the same side-effects
IRC [22:29] <Spark> one of the things i regret doing, is writing strings into the toy language is values, rather than char arrays
IRC [22:29] <Spark> so they're a bit like std::string instances on the stack, and not at all like java.lang.String objects
IRC [22:29] <Spark> or allocated char arrays
IRC [22:33] <Spark> the next step is to operate directly on java or CLR bytecode though
IRC [22:33] <Spark> and at that stage we will have to make some arrangements for calls out to native code
IRC [22:34] <Spark> especially where that native code can cause side-effects within java classes, there may well need to be some kind of interface specification saying what the native code does, in a language that the analysis can understand