2010-11-03T01:44:14 *** kevbo has quit IRC 2010-11-03T03:05:59 *** pmplett has quit IRC 2010-11-03T06:42:14 *** collum has joined #evergreen 2010-11-03T07:36:55 *** Dmagick_ has quit IRC 2010-11-03T07:39:04 *** sfortin has joined #evergreen 2010-11-03T08:21:31 *** mrpeters-isl has joined #evergreen 2010-11-03T08:25:53 *** 84XAA63GZ has joined #evergreen 2010-11-03T08:26:06 *** 84XAA63GZ is now known as Dmagick 2010-11-03T08:28:51 *** r123 has joined #evergreen 2010-11-03T08:29:21 *** tspindler has joined #evergreen 2010-11-03T08:38:51 going on 2 days and 36 minutes of the "UPDATE/TRIM metabib.real_full_rec" for the 1.6.0.3 > 1.6.0.4 upgrade script. About 168,159,378 rows in m.rfr is that time extreme or expected? 2010-11-03T09:04:30 *** Meliss has joined #evergreen 2010-11-03T09:04:58 *** rickd has joined #evergreen 2010-11-03T09:10:06 *** dbs has joined #evergreen 2010-11-03T09:12:34 *** kmlussier has joined #evergreen 2010-11-03T09:18:52 *** bshum has joined #evergreen 2010-11-03T09:21:10 mrpeters-isl: Wow, that is alot of rows 2010-11-03T09:23:01 Or I mean, that sounds like alot of rows. 2010-11-03T09:25:03 2 days sounds extreme for me, even if you do have 24 times as many rows as I have. 2010-11-03T09:29:39 *** parsr has joined #evergreen 2010-11-03T09:30:01 *** jenny has joined #evergreen 2010-11-03T09:33:34 custom staff client skin: can someone remind me what file I use to change the default opac skin to use in the Staff Client - from 'default' to whatever else? (I'll continue poking around) 2010-11-03T09:34:27 constants.js 2010-11-03T09:35:16 parsr: Specifically, find any reference to the word "default" in strings in there, I think 2010-11-03T09:35:56 *** yboston has joined #evergreen 2010-11-03T09:37:12 tsbere - thanks! 2010-11-03T09:37:56 *** parsr has quit IRC 2010-11-03T09:54:13 bshum: best i can tell, its still "doing its thing" but i'm starting to worry... 2010-11-03T09:55:43 mrpeters-isl: Yeah, I wish I knew more about how to check on stuff like that. 2010-11-03T09:56:05 mrpeters-isl: Are you running the 1.6.0.3-1.6.0.4 upgrade script in pieces? Or as the whole deal 2010-11-03T09:56:10 (just curious) 2010-11-03T09:56:10 whole deal 2010-11-03T09:57:08 so im still stuck on that first step 2010-11-03T09:58:29 Hmm 2010-11-03T09:58:39 The trim shouldn't be taking that long in my experience. 2010-11-03T09:58:52 I would have imagined the replace view for reporter.simple_record taking the longest time. 2010-11-03T09:58:57 That's what took us the longest, rather. 2010-11-03T09:59:25 And it failed because we were using a bad one. You managed to grab the latest update to the script from the repos right? The one in the tarballs is probably bad. 2010-11-03T10:03:12 bshum: im using the one from 1.6.1.2 tarball 2010-11-03T10:04:52 mrpeters-isl: Hmm 2010-11-03T10:05:12 How do you know which step you're at? 2010-11-03T10:05:24 Guessing based on commits, etc.? 2010-11-03T10:05:31 Well not commits, I guess 2010-11-03T10:05:37 But the messages I mean 2010-11-03T10:07:02 bshum: SELECT procpid, now()-query_start AS duration, current_query FROM pg_stat_activity WHERE current_query <> '' ORDER BY 2; 2010-11-03T10:07:39 Ahh, neato, going to have to save that one :) 2010-11-03T10:07:57 so 2 days of UPDATE metabib.real_full_rec SET value = TRIM(value) WHERE (tag = '022' AND subfield = 'a') OR (tag = '100' AND subfield = 'd'); 2010-11-03T10:08:17 bshum: it's from http://open-ils.org/dokuwiki/doku.php?id=scratchpad:random_magic_spells 2010-11-03T10:08:22 Of course it is... 2010-11-03T10:08:24 :) 2010-11-03T10:09:00 so you think this version of the script from the 1.6.1.2 tarball is bad? 2010-11-03T10:09:14 and there is a new version in trunk? 2010-11-03T10:09:46 I'm unclear of where Galen put it. 2010-11-03T10:09:50 err -- not trunk 2010-11-03T10:09:54 probably in the 1.6 brnach 2010-11-03T10:09:57 I'd have to double check the timeline 2010-11-03T10:10:01 But you're probably right. 2010-11-03T10:10:56 yep, rel_1_6 and rel_1_6_1 2010-11-03T10:10:57 hmm 1.6.0.3-1.6.0.4-upgrade-db.sql hasnt been updated in the 1_6_1 branch for 5 months 2010-11-03T10:11:27 mrpeters-isl: http://svn.open-ils.org/trac/ILS/changeset/18363 2010-11-03T10:11:28 1.6.0.4-1.6.1.0-upgrade-db.sql is the one gmcharlt has updated 2010-11-03T10:11:52 ok, i guess ill grab this and try again! 2010-11-03T10:11:57 Guess it didn't make its way to 1_6_1 2010-11-03T10:12:16 *** kmlussier has quit IRC 2010-11-03T10:12:17 *** denials_ has quit IRC 2010-11-03T10:12:32 No, it's in the rel_1_6 2010-11-03T10:12:44 Dunno, but that's the changeset 2010-11-03T10:12:59 Might not be entirely related to your issue though. 2010-11-03T10:13:09 The SQL you reference is different than the one that is changed here. 2010-11-03T10:13:17 Still, it's important down the road. 2010-11-03T10:13:57 yeah 2010-11-03T10:14:20 prob should have just let it run, but 2+ days is a LONG time 2010-11-03T10:14:43 I agree, but then our DB isn't as big as yours. 2010-11-03T10:14:53 Has anyone put thought into preventing transit of items with certain circ mods between branches? 2010-11-03T10:14:55 I think ours completed its cycles in about half an hour or so. 2010-11-03T10:15:21 jeff: That sounds like a good idea. 2010-11-03T10:15:42 jeff: We've been doing that kind of through use of managing our hold matrix to prevent items from being requested in the first place. 2010-11-03T10:15:49 I'm not sold on it being a great idea yet. ;-) 2010-11-03T10:16:06 jeff: But does your question involve actually blocking items from going regardless of rules, etc.? 2010-11-03T10:16:07 jeff: we do that 2010-11-03T10:16:12 But for example, if TOY circ mod items should be otherwise holdable by patrons for pickup at the circ lib of the item -- but not transit to fill holds at other libs. 2010-11-03T10:16:22 at least that sounds like what we do 2010-11-03T10:16:41 Great. Do you have an example, and any details on how you implemented it? 2010-11-03T10:16:46 its legacy circ scripts 2010-11-03T10:16:54 check. we're using 'em. 2010-11-03T10:16:56 jeff: That makes sense, but I think you can play with the different defining rules in in-db holds to stop that sort of behavior. We did it with newbooks 2010-11-03T10:17:03 Equinox set them up, but we've added a few....let me pull out an example 2010-11-03T10:17:05 jeff: Oh, right... shutting up now :) 2010-11-03T10:17:33 Scripts *scoff* 2010-11-03T10:18:20 i dotn think theres any rules on sharing this, even though they set them up...so let me tar these up for oyu 2010-11-03T10:18:40 gracias! 2010-11-03T10:18:45 examples++ 2010-11-03T10:19:18 208.119.1.11/circscript.tgz 2010-11-03T10:19:32 let me know when you have it, then ill do my best to explain 2010-11-03T10:20:03 Connecting to 208.119.1.11:80... 2010-11-03T10:20:09 for example, rules that prevent DVD transits except between branches -- so you could just remove the common ancestor code -- if you wanted to dissalow that too 2010-11-03T10:20:17 jeff: crap, firewall 2010-11-03T10:20:20 :-) 2010-11-03T10:21:02 http://help.evergreen.lib.in.us/circscript.tgz 2010-11-03T10:21:25 mrpeters-isl: 404. 2010-11-03T10:21:26 bah...im striking out big time 2010-11-03T10:21:27 http://208.119.72.66/circscript.tgz 2010-11-03T10:21:37 mrpeters-isl: success! :) 2010-11-03T10:21:42 that domain must not go where i think it does :) 2010-11-03T10:23:25 jeff: line 42 in circ_permit_hold.js is a good starting point... 2010-11-03T10:23:43 thats all of the stuff we don't allow to transit, EXCEPT between branches 2010-11-03T10:23:50 not 100% what you want, but really close 2010-11-03T10:33:40 *** kmlussier has joined #evergreen 2010-11-03T10:33:40 *** denials_ has joined #evergreen 2010-11-03T10:37:01 *** r123 has quit IRC 2010-11-03T10:40:37 *** StephenGWills has joined #evergreen 2010-11-03T10:47:01 *** CarlSagan has quit IRC 2010-11-03T10:47:56 *** CarlSagan has joined #evergreen 2010-11-03T10:50:47 *** dbs has quit IRC 2010-11-03T10:51:38 *** jenny has quit IRC 2010-11-03T10:55:50 *** rjackson-isl has joined #evergreen 2010-11-03T11:00:12 *** tspindler has quit IRC 2010-11-03T11:03:13 *** dbs has joined #evergreen 2010-11-03T11:12:32 *** jenny has joined #evergreen 2010-11-03T11:15:42 *** tspindler has joined #evergreen 2010-11-03T11:20:35 *** youdonotexist has joined #evergreen 2010-11-03T11:24:28 *** mtcarlson has joined #evergreen 2010-11-03T11:25:44 *** Dyrcona has joined #evergreen 2010-11-03T11:43:14 *** natschil has joined #evergreen 2010-11-03T11:47:15 *** natschil has quit IRC 2010-11-03T11:47:32 *** natschil has joined #evergreen 2010-11-03T11:48:12 bshum thanks for the test of OpenSRF 1.6.* with EG 1.6.1.* dbs is there a reason 1.4.* is suggested when 1.6.* is available? 2010-11-03T11:49:01 moodaepo: Glad to help. :) 2010-11-03T11:49:02 bshum++ for "Catalog Search" button option 2010-11-03T11:49:28 Meliss++ for cool icons 2010-11-03T11:49:33 moodaepo: dunno if OpenSRF 1.6 works with EG 1.6.1; we're running OpenSRF 1.2 for what it's worth 2010-11-03T11:51:03 dbs: Will do. 2010-11-03T11:51:38 *** natschil has quit IRC 2010-11-03T11:51:48 OpenSRF 1.6 should work with anything back to EG 1.4, and it has less leaks and more features 2010-11-03T11:52:14 Empirical testing says yes! 2010-11-03T11:53:06 Okay, here's a fun story 2010-11-03T11:53:10 Or question rather 2010-11-03T11:53:25 Evergreen skips fines for days that are marked "closed" right? 2010-11-03T11:53:30 I turn into a pumpkin soon, but I wanted to throw out a grenade: for OpenSRF 2, who'd like to switch from to some other top-level element? is meant for chat 2010-11-03T11:54:10 bshum: if the closed dates are entered /before/ the fine generator runs for those intervals, it is supposed to, yes 2010-11-03T11:54:37 eeevil: That's what we expect. I guess the question is what to do if the library is mean and wants to fine on days they are closed. 2010-11-03T11:54:41 eeevil: +1 besides, I wanna abuse ejabberd on Evergreen servers so that it carries both OpenSRF messages and ones for a hypothetical chat reference feature ;) 2010-11-03T11:54:41 But only for specific items. 2010-11-03T11:54:50 I'm not expecting this to be possible with in-db circ 2010-11-03T11:55:08 gmcharlt: and I want to do a test of opensrf over gtalk ;) 2010-11-03T11:55:21 eeevil: That won't work. <_< 2010-11-03T11:55:59 tsbere: tried it? (/me hopes "yes") 2010-11-03T11:56:08 bshum: well, it wouldn't be possible with script-based circ rules either 2010-11-03T11:56:25 eeevil: gtalk changes your resource identifier when you connect, you cannot predict resource identifiers. 2010-11-03T11:56:32 by the point that the fine generator runs, it's well past the point where the circ rules were determined for that loan 2010-11-03T11:56:33 gmcharlt: Small comfort actually. 2010-11-03T11:57:16 tsbere: gah... lame 2010-11-03T11:57:42 that said, I will live dangerously and say that it wouldn't be a huge deal to code a new feature; most of the work would lie in figuring out the optimal way to express how to configure it, paticularly for a consortium 2010-11-03T11:58:01 *** natschil has joined #evergreen 2010-11-03T11:58:17 eeevil: It adds a random string to the end (like "C566E920"), and if the string is too long it truncates it, THEN adds the random string. 2010-11-03T11:58:57 gmcharlt: Well, we might have dodged a bullet here. Meliss convinced them it's bad to fine patrons on their closed days. 2010-11-03T11:59:02 hates_patrons = true 2010-11-03T11:59:05 I think it limits to 10 chars + the random string 2010-11-03T11:59:06 tsbere: have to teach OpenSRF to investigate it's own jid and adjust 2010-11-03T11:59:09 ;) 2010-11-03T11:59:15 bshum: cool 2010-11-03T11:59:21 eby++ 2010-11-03T12:02:01 *** natschil has quit IRC 2010-11-03T12:02:33 gmcharlt: Did you want help configuring ejabberd to allow offline messages for some domains and not others for your "abuse ejabberd" thing? :p 2010-11-03T12:03:23 tsbere: if I were serious about it, sure :) 2010-11-03T12:05:38 *** StephenGWills has quit IRC 2010-11-03T12:09:50 gmcharlt: I am considering abusing ejabberd in a similar manner, but only because OpenSRF knows what domains it "likes" already. 2010-11-03T12:10:08 BTW, in regards to that......is there any chance of making opensrf understand SRV records for XMPP? 2010-11-03T12:13:09 SRV records have the nice benefit of being able to specify the hostname *and* port, both for client to server and server to server on XMPP. 2010-11-03T12:13:13 *** natschil has joined #evergreen 2010-11-03T12:16:47 as an example, you can check gmail's entries: "dig _xmpp-client._tcp.gmail.com SRV" and "dig _xmpp-server._tcp.gmail.com SRV", although the server one would be most useful to ejabberd itself. 2010-11-03T12:18:54 * tsbere is also interested in possibly distributing ejabberd handling across multiple machines in the future 2010-11-03T12:20:50 *** natschil has quit IRC 2010-11-03T12:28:25 SRV records++ 2010-11-03T12:59:35 *** dbs has quit IRC 2010-11-03T13:08:20 *** mtcarlson has quit IRC 2010-11-03T13:10:24 *** jscott has joined #evergreen 2010-11-03T13:12:59 *** natschil has joined #evergreen 2010-11-03T13:13:35 *** kmlussier has quit IRC 2010-11-03T13:14:15 Hello. I am using autogen in a project, and I would like to turn off optimisation for gcc (-O0). I specified this in DEF_CFLAGS, however it still compiles with -O2...any suggestions as to how to fix this 2010-11-03T13:14:16 \? 2010-11-03T13:15:24 *** jscott has quit IRC 2010-11-03T13:15:35 *** kmlussier has joined #evergreen 2010-11-03T13:17:11 oops, I meant to post that in #gnu 2010-11-03T13:17:25 sorry 2010-11-03T13:22:14 *** bshum has quit IRC 2010-11-03T13:29:09 *** bshum has joined #evergreen 2010-11-03T13:29:10 *** bshum has joined #evergreen 2010-11-03T13:34:57 *** dbs has joined #evergreen 2010-11-03T13:34:58 *** dbs has joined #evergreen 2010-11-03T13:36:12 *** tildeequals has quit IRC 2010-11-03T13:39:46 *** dbs has quit IRC 2010-11-03T13:44:45 *** Callender has quit IRC 2010-11-03T14:07:59 *** jenny1 has joined #evergreen 2010-11-03T14:10:17 *** jenny has quit IRC 2010-11-03T14:20:28 *** mtcarlson has joined #evergreen 2010-11-03T14:20:41 *** Callender has joined #evergreen 2010-11-03T14:37:59 *** pmplett has joined #evergreen 2010-11-03T14:43:28 Hello. How would it be possible to write an opensrf server in c++ (or even D) just wondering. 2010-11-03T14:44:00 (using the c opensrf libraries, that is) 2010-11-03T14:45:06 first, write a C++ or D wrapper around the c libraries. 2010-11-03T14:46:54 i don't even think you'd need a wrapper for c++. it should just work. 2010-11-03T14:47:33 I'd suggest writing the wrapper library to have a C++ interface, in the interest of doing it right. 2010-11-03T14:47:36 there's a extern "C" {} bloc that surrounds all of the code, but I'm not sure if that's what you mean. 2010-11-03T14:48:01 Dyrcona: oh, yeah, if you wanted an OO interface for opensrf in c++ 2010-11-03T14:48:59 *** dbs has joined #evergreen 2010-11-03T14:48:59 *** dbs has joined #evergreen 2010-11-03T14:49:13 Dyrcona: I was mainly thinking c++ simply because there are many quite good libraries that are written in c++ that have no good c implementations... though I don't like c++ myself. And since I was just reading some things on d, I was wondering if that would work too 2010-11-03T14:50:08 berick: I meant more like write c++ code in the server that uses the c opensrf libraries to communicate with the rest of opensrf 2010-11-03T14:51:30 *** jenny has joined #evergreen 2010-11-03T14:51:43 natschil: in that case, i /think/ you can just load the C libs and call the funcs from within c++. (disclaimer: I haven't written c++ code in a long time). 2010-11-03T14:52:10 natschil: If you don't mind a little ugliness, then you could write your c++ code and call the c opensrf libraries. 2010-11-03T14:52:38 *** jenny1 has quit IRC 2010-11-03T14:53:11 berick is correct. As long as the C function declarations are surrounded by extern "C { ... } when the c++ compiler sees them. 2010-11-03T14:53:14 Dyrcona: what do you mean? Like for things like osrfHash and jsonObject, or for things like osrfAppRequestRespondComplete 2010-11-03T14:53:40 I'm not being specific, because yours is actually a general question. 2010-11-03T14:54:02 You can call C library functions in C++ with no problems usually. 2010-11-03T14:54:15 If I were to use c++, would I simply do everything like in c, i.e. have an int osrfAppChildInit(), etc and accept osrfMethodContext* for my function argument for all functions, but simply have c++ code in the function bodies? 2010-11-03T14:54:20 So, in principle, the opensrf C routines should just work. 2010-11-03T14:54:37 Dyrcona: Yes, but can one call c++ from c? 2010-11-03T14:55:14 natschil: to answer your second question, in principle no. in actuality, yes, but it is ugly. 2010-11-03T14:55:46 natschil: You can't just run c++ code through a c compiler, it won't work. 2010-11-03T14:55:54 Dyrcona: of course 2010-11-03T14:57:07 Dyrcona: hmmm. But if I register an opensrf Method, I need to give the name of the function it calls as a parameter (as a string, not function pointer). Registering a function that looks like a c function from the outside i.e returns int, takes c paramters but that has c++ paramters would be what I would like to do 2010-11-03T14:57:18 *** steve_ has joined #evergreen 2010-11-03T14:57:26 sorry, that meant to say c++ function body 2010-11-03T14:57:46 hi everybody.... am installing evergreen ILS on a spare box as we speak 2010-11-03T14:57:58 natschil: c++ name mangling makes that tricky. 2010-11-03T14:58:47 Dyrcona: so could I create c wrapper functions for the c++ library, and then simply call those from the function body? 2010-11-03T14:59:08 natschil: IIRC, you can declare a function as extern C in a header, and in the implementation file call c++ objects and methods, I think that works. 2010-11-03T14:59:19 natschil: I wanted to do a D implementation long ago :) 2010-11-03T15:00:30 eeevil: In theory, it shouldn't be too hard, as most of the c stuff can be re-used. tbh, I haven't used d myself at all, but it looks like an interresting language to use, if only they get OOP done better than c++ (amongst other things) 2010-11-03T15:00:41 natschil: i'm not sure that you really need to have a C function though. 2010-11-03T15:01:37 all opensrf needs is the function entry point to call, so you give it a name, and when its asked for, run your implementation function or method. 2010-11-03T15:02:33 Dyrcona: Ok, if that works that'd be great. I wasn't completely sure how c++ functions worked with that though. 2010-11-03T15:03:42 functions that are not object members work very much like C functions, except that function names are mangled because of the possibility of overloading. 2010-11-03T15:05:07 rather than give opensrf the real name of your c++ function, you could maintain a dispatch table that maps a string to the actual function. 2010-11-03T15:06:02 you then give opensrf the string as the function name to call. 2010-11-03T15:06:30 Dyrcona: I see. But how would opensrf know to look up the string I feed it in the table, or how would I know the "real" name of the function from it's pointer? 2010-11-03T15:07:09 when you create an opensrf service, you call an opensrf function to register your function. that's when you tell opensrf. 2010-11-03T15:07:51 Dyrcona: yes, but what exactly do I tell it? If the function names are mangled, how do I find the "real" function name? 2010-11-03T15:08:35 you don't. you give opensrf a string, and you store a pointer to your function in the dispatch table, indexed by the string that you gave to opensrf. 2010-11-03T15:10:43 Sorry, i'm still a bit confused about the dispatch table. Do I create it, or does opensrf already have it. If I create it, how does opensrf know to look it up in the dispatch table? 2010-11-03T15:10:55 so, when opensrf says, run this function, and you pick the function name out of the request, you look up your function pointer by the string, and then call your function with the parameters that were also given with the request. 2010-11-03T15:11:33 you create the dispatch table. because of c++ name mangling you can't your functions real name until after the code is compiled. 2010-11-03T15:11:51 ^you can't know your 2010-11-03T15:12:10 *** steve_ has quit IRC 2010-11-03T15:12:32 Dyrcona: ok, thanks, that makes sense. So basically, I give opensrf the name of a c function that looks up the name of the c++ function in a dispatch table that somehow gets the name of the c++ function at compile time... yes? 2010-11-03T15:12:44 no. 2010-11-03T15:13:27 i'd give opensrf the name of the function as it appears in my source. 2010-11-03T15:13:49 *** tildeequals has joined #evergreen 2010-11-03T15:14:21 in the dispatch table (std::map) i'd use that string as the key that indexes the pointer to the function, i.e. the address of the function in the compiled code. 2010-11-03T15:15:13 you'd then have a function to handle all incoming opensrf requests, cracks out the parameters, and runs the appropriate function. 2010-11-03T15:15:16 Is there any particular reason that the javascript for REGEX_PHONE in /openils/var/web/opac/common/js/config.js disallows extensions? This breaks hold placement on behalf of patrons who have extensions in their phone number fields. 2010-11-03T15:15:24 i don't think opensrf runs your code directly. 2010-11-03T15:15:29 It can only match on XXX-YYY-ZZZZ 2010-11-03T15:16:05 bshum change it to .*? :) 2010-11-03T15:16:25 Dyrcona: Right, I tested changing that to match like what we see for the patron registration regex 2010-11-03T15:16:28 Dyrcona: but the function that handles all incoming opensrf requests, won't it's name also be mangled? 2010-11-03T15:16:28 For phone 2010-11-03T15:16:41 Dyrcona: I'm just wondering if there's a reason it's not like that. 2010-11-03T15:16:50 Dyrcona: If it'll break other stuff down the line. 2010-11-03T15:17:20 natschil: yes, but it shouldn't matter, if I understand correctly, because opensrf won't be calling that function, your code will be. 2010-11-03T15:17:47 opensrf sends you a message: run function blah with parameters x, y, z. 2010-11-03T15:18:16 whatever code you've got looks up function blah, and calls it with parameter x, y, z and returns the result. 2010-11-03T15:19:06 Dyrcona: Yes, but then I would need to implement the part that receives the message in c++, instead of using the c libraries, if that is what you mean 2010-11-03T15:19:51 natschil: not if your method is declared extern C in your headers. 2010-11-03T15:20:15 natschil: you can very easily call C from C++. 2010-11-03T15:21:04 natschil: as I said earlier a C++ wrapper would make this so much easier if you plan on doing a lot of this. 2010-11-03T15:22:28 I need to look at the opensrf C interfaces in more detail. 2010-11-03T15:23:45 Dyrcona: I still don't completely understand what parts are c and which parts are c++, but I think that mostly stems from my incomplete knowledge about how to mix the two, so I should probably do some reading on that.... Thanks a lot for the help though... I only plan to call a few c++ libraries, so I guess I'll either find replacements for them or somehow use the way you were talking about... 2010-11-03T15:27:18 Anyways, I think I'll look into it more at some stage and then if it works well I might write some documentation... Thanks again for the help, hope everyone has a good day! 2010-11-03T15:27:23 *** natschil has quit IRC 2010-11-03T15:30:09 too bad he left. 2010-11-03T15:30:13 i have an answer. 2010-11-03T15:30:18 he can't do what he wants. 2010-11-03T15:30:53 it doesn't look like the internal function register_method in libopensrf would handle name mangled functions. 2010-11-03T15:31:17 it didn't work the way i thought it did. typical. i should do some investigation before i open my big mouth. 2010-11-03T15:31:42 basically, it sounds like natschil is trying to call c++ from c and you typically can't do that. 2010-11-03T15:32:35 Well, maybe he'll see the log :) 2010-11-03T15:32:50 Leave him a @later? 2010-11-03T15:37:29 *** jenny1 has joined #evergreen 2010-11-03T15:38:01 *** mtcarlson has quit IRC 2010-11-03T15:40:53 *** jenny has quit IRC 2010-11-03T15:41:54 @later natschil The only way I see it working is for you to declare your C++ function as extern C. 2010-11-03T15:41:54 Dyrcona: Error: The "Later" plugin is loaded, but there is no command named "natschil" in it. Try "list Later" to see the commands in the "Later" plugin. 2010-11-03T15:42:03 oops. 2010-11-03T15:44:29 @later tell Dyrcona doh 2010-11-03T15:44:29 phasefx: The operation succeeded. 2010-11-03T15:44:57 @later tell natschil The only way I see it working is for you to declare your C++ function as extern C. Then the C++ compiler won't mangle the function name and libopensrf should be a able to find it by name. You shouldn't need a dispatch table. 2010-11-03T15:44:57 Dyrcona: The operation succeeded. 2010-11-03T15:45:21 -> phasefx :) 2010-11-03T15:46:15 * Dyrcona decides to try something as an experiment. 2010-11-03T15:50:30 *** collum has left #evergreen 2010-11-03T15:55:06 *** jenny1 has left #evergreen 2010-11-03T15:55:41 *** Meliss has quit IRC 2010-11-03T15:56:21 *** sfortin has quit IRC 2010-11-03T15:57:12 *** mtcarlson has joined #evergreen 2010-11-03T15:57:54 *** bshum has quit IRC 2010-11-03T16:00:40 *** tspindler has quit IRC 2010-11-03T16:03:38 *** yboston has quit IRC 2010-11-03T16:09:07 *** dbs has quit IRC 2010-11-03T16:11:16 *** gdunbar has quit IRC 2010-11-03T16:12:20 oh well. experiment failed. I can't even get a simple program to compile with g++ against libopensrf..... 2010-11-03T16:15:53 struct socket_node; 2010-11-03T16:15:55 typedef struct socket_node_struct socket_node; 2010-11-03T16:15:57 Aren't valid c++, but are valid C. 2010-11-03T16:18:39 crazy. i tought C++ was a superset of C. 2010-11-03T16:21:57 *** dbs has joined #evergreen 2010-11-03T16:23:41 berick: it is but there are differences. stuct is a class in c++ with public members by default. it's a very different beast from a C struct. 2010-11-03T16:25:12 http://www.cprogramming.com/tutorial/c-vs-c++.html 2010-11-03T16:26:16 That's not even a good short list. Shoulda looked first. been impulsive today. :) 2010-11-03T16:26:31 *** granitize has left #evergreen 2010-11-03T16:27:19 *** rjackson-isl has quit IRC 2010-11-03T16:31:35 Dyrcona: interesting... 2010-11-03T16:32:17 This one is more interesting: http://david.tribble.com/text/cdiffs.htm 2010-11-03T16:39:17 the c++ compiler fails on typedef struct socket_node_struct socket_node because as far as c++ is concerned after the previous line (struct socket_node) socket_node by iteslf is now a valid type. In C, it isn't so it can be typedef'd away. 2010-11-03T16:40:10 * tsbere just had to manually install wget to run makefile.install on ubuntu-lucid. <_< 2010-11-03T16:40:13 i am also now a bit confused about how the opensrf c-apps work. They are libraries, so I'm trying to figure out how they are actually executed. 2010-11-03T16:41:49 guess i'll take a fresh look in the morning when my brain is less clouded by other things. 2010-11-03T16:55:34 *** dbs has quit IRC 2010-11-03T17:02:30 *** jamesrf has quit IRC 2010-11-03T17:02:38 *** kmlussier has quit IRC 2010-11-03T17:05:53 ... 2010-11-03T17:06:03 * tsbere isn't getting vandelay loading 2010-11-03T17:10:09 eeevil, you around? 2010-11-03T17:19:16 tsbere pasted "rel_2_0 db fix" at http://paste.lisp.org/display/116210 2010-11-03T17:19:36 @later tell eeevil tsbere pasted "rel_2_0 db fix" at http://paste.lisp.org/display/116210 2010-11-03T17:19:36 tsbere: The operation succeeded. 2010-11-03T17:22:39 *** granitize has joined #evergreen 2010-11-03T17:30:11 @later tell eeevil I also had to, on rel_2_0 checkout, comment out the Batch Bib Update module in startup.pl? The OpenILS::WWW::TemplateBatchBibUpdate line. Apache wouldn't start with it there. 2010-11-03T17:30:11 tsbere: The operation succeeded. 2010-11-03T17:31:03 *** Dyrcona has quit IRC 2010-11-03T18:05:13 *** pmplett has quit IRC 2010-11-03T18:14:47 *** jamesrf has joined #evergreen 2010-11-03T18:24:42 *** pmplett has joined #evergreen 2010-11-03T18:55:56 *** mtcarlson has quit IRC 2010-11-03T19:02:36 *** jamesrf has quit IRC 2010-11-03T19:33:39 *** youdonotexist has quit IRC 2010-11-03T20:23:50 *** mtate has quit IRC 2010-11-03T20:24:04 *** mtate has joined #evergreen 2010-11-03T20:45:50 *** tildeequals has quit IRC 2010-11-03T21:02:34 *** moodaepo_home has joined #evergreen 2010-11-03T21:24:16 *** moodaepo_home has quit IRC 2010-11-03T23:11:48 *** jeffdavis has quit IRC 2010-11-03T23:30:23 *** lisppaste has quit IRC 2010-11-03T23:41:45 *** pmplett has quit IRC