| # | Time | Nick | Message |
|---|
| # | 01:44:14 | kevbo has quit IRC |
| # | 03:05:59 | pmplett has quit IRC |
| # | 06:42:14 | collum has joined #evergreen |
| # | 07:36:55 | Dmagick_ has quit IRC |
| # | 07:39:04 | sfortin has joined #evergreen |
| # | 08:21:31 | mrpeters-isl has joined #evergreen |
| # | 08:25:53 | 84XAA63GZ has joined #evergreen |
| # | 08:26:06 | 84XAA63GZ is now known as Dmagick |
| # | 08:28:51 | r123 has joined #evergreen |
| # | 08:29:21 | tspindler has joined #evergreen |
| # | 08:38:51 | mrpeters-isl | 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? |
| # | 09:04:30 | Meliss has joined #evergreen |
| # | 09:04:58 | rickd has joined #evergreen |
| # | 09:10:06 | dbs has joined #evergreen |
| # | 09:12:34 | kmlussier has joined #evergreen |
| # | 09:18:52 | bshum has joined #evergreen |
| # | 09:21:10 | bshum | mrpeters-isl: Wow, that is alot of rows |
| # | 09:23:01 | bshum | Or I mean, that sounds like alot of rows. |
| # | 09:25:03 | bshum | 2 days sounds extreme for me, even if you do have 24 times as many rows as I have. |
| # | 09:29:39 | parsr has joined #evergreen |
| # | 09:30:01 | jenny has joined #evergreen |
| # | 09:33:34 | parsr | 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) |
| # | 09:34:27 | tsbere | constants.js |
| # | 09:35:16 | tsbere | parsr: Specifically, find any reference to the word "default" in strings in there, I think |
| # | 09:35:56 | yboston has joined #evergreen |
| # | 09:37:12 | parsr | tsbere - thanks! |
| # | 09:37:56 | parsr has quit IRC |
| # | 09:54:13 | mrpeters-isl | bshum: best i can tell, its still "doing its thing" but i'm starting to worry... |
| # | 09:55:43 | bshum | mrpeters-isl: Yeah, I wish I knew more about how to check on stuff like that. |
| # | 09:56:05 | bshum | mrpeters-isl: Are you running the 1.6.0.3-1.6.0.4 upgrade script in pieces? Or as the whole deal |
| # | 09:56:10 | bshum | (just curious) |
| # | 09:56:10 | mrpeters-isl | whole deal |
| # | 09:57:08 | mrpeters-isl | so im still stuck on that first step |
| # | 09:58:29 | bshum | Hmm |
| # | 09:58:39 | bshum | The trim shouldn't be taking that long in my experience. |
| # | 09:58:52 | bshum | I would have imagined the replace view for reporter.simple_record taking the longest time. |
| # | 09:58:57 | bshum | That's what took us the longest, rather. |
| # | 09:59:25 | bshum | 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. |
| # | 10:03:12 | mrpeters-isl | bshum: im using the one from 1.6.1.2 tarball |
| # | 10:04:52 | bshum | mrpeters-isl: Hmm |
| # | 10:05:12 | bshum | How do you know which step you're at? |
| # | 10:05:24 | bshum | Guessing based on commits, etc.? |
| # | 10:05:31 | bshum | Well not commits, I guess |
| # | 10:05:37 | bshum | But the messages I mean |
| # | 10:07:02 | mrpeters-isl | bshum: SELECT procpid, now()-query_start AS duration, current_query FROM pg_stat_activity WHERE current_query <> '<IDLE>' ORDER BY 2; |
| # | 10:07:39 | bshum | Ahh, neato, going to have to save that one :) |
| # | 10:07:57 | mrpeters-isl | 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'); |
| # | 10:08:17 | mrpeters-isl | bshum: it's from http://open-ils.org/dokuwiki/doku.php?id=scratchpad:random_magic_spells |
| # | 10:08:22 | bshum | Of course it is... |
| # | 10:08:24 | mrpeters-isl | :) |
| # | 10:09:00 | mrpeters-isl | so you think this version of the script from the 1.6.1.2 tarball is bad? |
| # | 10:09:14 | mrpeters-isl | and there is a new version in trunk? |
| # | 10:09:46 | bshum | I'm unclear of where Galen put it. |
| # | 10:09:50 | mrpeters-isl | err -- not trunk |
| # | 10:09:54 | mrpeters-isl | probably in the 1.6 brnach |
| # | 10:09:57 | bshum | I'd have to double check the timeline |
| # | 10:10:01 | bshum | But you're probably right. |
| # | 10:10:56 | gmcharlt | yep, rel_1_6 and rel_1_6_1 |
| # | 10:10:57 | mrpeters-isl | hmm 1.6.0.3-1.6.0.4-upgrade-db.sql hasnt been updated in the 1_6_1 branch for 5 months |
| # | 10:11:27 | bshum | mrpeters-isl: http://svn.open-ils.org/trac/ILS/changeset/18363 |
| # | 10:11:28 | mrpeters-isl | 1.6.0.4-1.6.1.0-upgrade-db.sql is the one gmcharlt has updated |
| # | 10:11:52 | mrpeters-isl | ok, i guess ill grab this and try again! |
| # | 10:11:57 | bshum | Guess it didn't make its way to 1_6_1 |
| # | 10:12:16 | kmlussier has quit IRC |
| # | 10:12:17 | denials_ has quit IRC |
| # | 10:12:32 | bshum | No, it's in the rel_1_6 |
| # | 10:12:44 | bshum | Dunno, but that's the changeset |
| # | 10:12:59 | bshum | Might not be entirely related to your issue though. |
| # | 10:13:09 | bshum | The SQL you reference is different than the one that is changed here. |
| # | 10:13:17 | bshum | Still, it's important down the road. |
| # | 10:13:57 | mrpeters-isl | yeah |
| # | 10:14:20 | mrpeters-isl | prob should have just let it run, but 2+ days is a LONG time |
| # | 10:14:43 | bshum | I agree, but then our DB isn't as big as yours. |
| # | 10:14:53 | jeff | Has anyone put thought into preventing transit of items with certain circ mods between branches? |
| # | 10:14:55 | bshum | I think ours completed its cycles in about half an hour or so. |
| # | 10:15:21 | bshum | jeff: That sounds like a good idea. |
| # | 10:15:42 | bshum | 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. |
| # | 10:15:49 | jeff | I'm not sold on it being a great idea yet. ;-) |
| # | 10:16:06 | bshum | jeff: But does your question involve actually blocking items from going regardless of rules, etc.? |
| # | 10:16:07 | mrpeters-isl | jeff: we do that |
| # | 10:16:12 | jeff | 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. |
| # | 10:16:22 | mrpeters-isl | at least that sounds like what we do |
| # | 10:16:41 | jeff | Great. Do you have an example, and any details on how you implemented it? |
| # | 10:16:46 | mrpeters-isl | its legacy circ scripts |
| # | 10:16:54 | jeff | check. we're using 'em. |
| # | 10:16:56 | bshum | 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 |
| # | 10:17:03 | mrpeters-isl | Equinox set them up, but we've added a few....let me pull out an example |
| # | 10:17:05 | bshum | jeff: Oh, right... shutting up now :) |
| # | 10:17:33 | bshum | Scripts *scoff* |
| # | 10:18:20 | mrpeters-isl | i dotn think theres any rules on sharing this, even though they set them up...so let me tar these up for oyu |
| # | 10:18:40 | jeff | gracias! |
| # | 10:18:45 | jeff | examples++ |
| # | 10:19:18 | mrpeters-isl | 208.119.1.11/circscript.tgz |
| # | 10:19:32 | mrpeters-isl | let me know when you have it, then ill do my best to explain |
| # | 10:20:03 | jeff | Connecting to 208.119.1.11:80... |
| # | 10:20:09 | mrpeters-isl | 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 |
| # | 10:20:17 | mrpeters-isl | jeff: crap, firewall |
| # | 10:20:20 | jeff | :-) |
| # | 10:21:02 | mrpeters-isl | http://help.evergreen.lib.in.us/circscript.tgz |
| # | 10:21:25 | jeff | mrpeters-isl: 404. |
| # | 10:21:26 | mrpeters-isl | bah...im striking out big time |
| # | 10:21:27 | mrpeters-isl | http://208.119.72.66/circscript.tgz |
| # | 10:21:37 | jeff | mrpeters-isl: success! :) |
| # | 10:21:42 | mrpeters-isl | that domain must not go where i think it does :) |
| # | 10:23:25 | mrpeters-isl | jeff: line 42 in circ_permit_hold.js is a good starting point... |
| # | 10:23:43 | mrpeters-isl | thats all of the stuff we don't allow to transit, EXCEPT between branches |
| # | 10:23:50 | mrpeters-isl | not 100% what you want, but really close |
| # | 10:33:40 | kmlussier has joined #evergreen |
| # | 10:33:40 | denials_ has joined #evergreen |
| # | 10:37:01 | r123 has quit IRC |
| # | 10:40:37 | StephenGWills has joined #evergreen |
| # | 10:47:01 | CarlSagan has quit IRC |
| # | 10:47:56 | CarlSagan has joined #evergreen |
| # | 10:50:47 | dbs has quit IRC |
| # | 10:51:38 | jenny has quit IRC |
| # | 10:55:50 | rjackson-isl has joined #evergreen |
| # | 11:00:12 | tspindler has quit IRC |
| # | 11:03:13 | dbs has joined #evergreen |
| # | 11:12:32 | jenny has joined #evergreen |
| # | 11:15:42 | tspindler has joined #evergreen |
| # | 11:20:35 | youdonotexist has joined #evergreen |
| # | 11:24:28 | mtcarlson has joined #evergreen |
| # | 11:25:44 | Dyrcona has joined #evergreen |
| # | 11:43:14 | natschil has joined #evergreen |
| # | 11:47:15 | natschil has quit IRC |
| # | 11:47:32 | natschil has joined #evergreen |
| # | 11:48:12 | moodaepo | 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? |
| # | 11:49:01 | bshum | moodaepo: Glad to help. :) |
| # | 11:49:02 | moodaepo | bshum++ for "Catalog Search" button option |
| # | 11:49:28 | bshum | Meliss++ for cool icons |
| # | 11:49:33 | dbs | moodaepo: dunno if OpenSRF 1.6 works with EG 1.6.1; we're running OpenSRF 1.2 for what it's worth |
| # | 11:51:03 | moodaepo | dbs: Will do. |
| # | 11:51:38 | natschil has quit IRC |
| # | 11:51:48 | eeevil | OpenSRF 1.6 should work with anything back to EG 1.4, and it has less leaks and more features |
| # | 11:52:14 | bshum | Empirical testing says yes! |
| # | 11:53:06 | bshum | Okay, here's a fun story |
| # | 11:53:10 | bshum | Or question rather |
| # | 11:53:25 | bshum | Evergreen skips fines for days that are marked "closed" right? |
| # | 11:53:30 | eeevil | I turn into a pumpkin soon, but I wanted to throw out a grenade: for OpenSRF 2, who'd like to switch from <message> to some other top-level element? <message> is meant for chat |
| # | 11:54:10 | eeevil | bshum: if the closed dates are entered /before/ the fine generator runs for those intervals, it is supposed to, yes |
| # | 11:54:37 | bshum | 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. |
| # | 11:54:41 | gmcharlt | 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 ;) |
| # | 11:54:41 | bshum | But only for specific items. |
| # | 11:54:50 | bshum | I'm not expecting this to be possible with in-db circ |
| # | 11:55:08 | eeevil | gmcharlt: and I want to do a test of opensrf over gtalk ;) |
| # | 11:55:21 | tsbere | eeevil: That won't work. <_< |
| # | 11:55:59 | eeevil | tsbere: tried it? (/me hopes "yes") |
| # | 11:56:08 | gmcharlt | bshum: well, it wouldn't be possible with script-based circ rules either |
| # | 11:56:25 | tsbere | eeevil: gtalk changes your resource identifier when you connect, you cannot predict resource identifiers. |
| # | 11:56:32 | gmcharlt | by the point that the fine generator runs, it's well past the point where the circ rules were determined for that loan |
| # | 11:56:33 | bshum | gmcharlt: Small comfort actually. |
| # | 11:57:16 | eeevil | tsbere: gah... lame |
| # | 11:57:42 | gmcharlt | 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 |
| # | 11:58:01 | natschil has joined #evergreen |
| # | 11:58:17 | tsbere | 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. |
| # | 11:58:57 | bshum | gmcharlt: Well, we might have dodged a bullet here. Meliss convinced them it's bad to fine patrons on their closed days. |
| # | 11:59:02 | eby | hates_patrons = true |
| # | 11:59:05 | tsbere | I think it limits to 10 chars + the random string |
| # | 11:59:06 | eeevil | tsbere: have to teach OpenSRF to investigate it's own jid and adjust |
| # | 11:59:09 | eeevil | ;) |
| # | 11:59:15 | gmcharlt | bshum: cool |
| # | 11:59:21 | gmcharlt | eby++ |
| # | 12:02:01 | natschil has quit IRC |
| # | 12:02:33 | tsbere | gmcharlt: Did you want help configuring ejabberd to allow offline messages for some domains and not others for your "abuse ejabberd" thing? :p |
| # | 12:03:23 | gmcharlt | tsbere: if I were serious about it, sure :) |
| # | 12:05:38 | StephenGWills has quit IRC |
| # | 12:09:50 | tsbere | gmcharlt: I am considering abusing ejabberd in a similar manner, but only because OpenSRF knows what domains it "likes" already. |
| # | 12:10:08 | tsbere | BTW, in regards to that......is there any chance of making opensrf understand SRV records for XMPP? |
| # | 12:13:09 | tsbere | 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. |
| # | 12:13:13 | natschil has joined #evergreen |
| # | 12:16:47 | tsbere | 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. |
| # | 12:18:54 | tsbere is also interested in possibly distributing ejabberd handling across multiple machines in the future |
| # | 12:20:50 | natschil has quit IRC |
| # | 12:28:25 | Dyrcona | SRV records++ |
| # | 12:59:35 | dbs has quit IRC |
| # | 13:08:20 | mtcarlson has quit IRC |
| # | 13:10:24 | jscott has joined #evergreen |
| # | 13:12:59 | natschil has joined #evergreen |
| # | 13:13:35 | kmlussier has quit IRC |
| # | 13:14:15 | natschil | 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 |
| # | 13:14:16 | natschil | \? |
| # | 13:15:24 | jscott has quit IRC |
| # | 13:15:35 | kmlussier has joined #evergreen |
| # | 13:17:11 | natschil | oops, I meant to post that in #gnu |
| # | 13:17:25 | natschil | sorry |
| # | 13:22:14 | bshum has quit IRC |
| # | 13:29:09 | bshum has joined #evergreen |
| # | 13:29:10 | bshum has joined #evergreen |
| # | 13:34:57 | dbs has joined #evergreen |
| # | 13:34:58 | dbs has joined #evergreen |
| # | 13:36:12 | tildeequals has quit IRC |
| # | 13:39:46 | dbs has quit IRC |
| # | 13:44:45 | Callender has quit IRC |
| # | 14:07:59 | jenny1 has joined #evergreen |
| # | 14:10:17 | jenny has quit IRC |
| # | 14:20:28 | mtcarlson has joined #evergreen |
| # | 14:20:41 | Callender has joined #evergreen |
| # | 14:37:59 | pmplett has joined #evergreen |
| # | 14:43:28 | natschil | Hello. How would it be possible to write an opensrf server in c++ (or even D) just wondering. |
| # | 14:44:00 | natschil | (using the c opensrf libraries, that is) |
| # | 14:45:06 | Dyrcona | first, write a C++ or D wrapper around the c libraries. |
| # | 14:46:54 | berick | i don't even think you'd need a wrapper for c++. it should just work. |
| # | 14:47:33 | Dyrcona | I'd suggest writing the wrapper library to have a C++ interface, in the interest of doing it right. |
| # | 14:47:36 | natschil | there's a extern "C" {} bloc that surrounds all of the code, but I'm not sure if that's what you mean. |
| # | 14:48:01 | berick | Dyrcona: oh, yeah, if you wanted an OO interface for opensrf in c++ |
| # | 14:48:59 | dbs has joined #evergreen |
| # | 14:48:59 | dbs has joined #evergreen |
| # | 14:49:13 | natschil | 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 |
| # | 14:50:08 | natschil | berick: I meant more like write c++ code in the server that uses the c opensrf libraries to communicate with the rest of opensrf |
| # | 14:51:30 | jenny has joined #evergreen |
| # | 14:51:43 | berick | 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). |
| # | 14:52:10 | Dyrcona | natschil: If you don't mind a little ugliness, then you could write your c++ code and call the c opensrf libraries. |
| # | 14:52:38 | jenny1 has quit IRC |
| # | 14:53:11 | Dyrcona | berick is correct. As long as the C function declarations are surrounded by extern "C { ... } when the c++ compiler sees them. |
| # | 14:53:14 | natschil | Dyrcona: what do you mean? Like for things like osrfHash and jsonObject, or for things like osrfAppRequestRespondComplete |
| # | 14:53:40 | Dyrcona | I'm not being specific, because yours is actually a general question. |
| # | 14:54:02 | Dyrcona | You can call C library functions in C++ with no problems usually. |
| # | 14:54:15 | natschil | 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? |
| # | 14:54:20 | Dyrcona | So, in principle, the opensrf C routines should just work. |
| # | 14:54:37 | natschil | Dyrcona: Yes, but can one call c++ from c? |
| # | 14:55:14 | Dyrcona | natschil: to answer your second question, in principle no. in actuality, yes, but it is ugly. |
| # | 14:55:46 | Dyrcona | natschil: You can't just run c++ code through a c compiler, it won't work. |
| # | 14:55:54 | natschil | Dyrcona: of course |
| # | 14:57:07 | natschil | 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 |
| # | 14:57:18 | steve_ has joined #evergreen |
| # | 14:57:26 | natschil | sorry, that meant to say c++ function body |
| # | 14:57:46 | steve_ | hi everybody.... am installing evergreen ILS on a spare box as we speak |
| # | 14:57:58 | Dyrcona | natschil: c++ name mangling makes that tricky. |
| # | 14:58:47 | natschil | Dyrcona: so could I create c wrapper functions for the c++ library, and then simply call those from the function body? |
| # | 14:59:08 | Dyrcona | 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. |
| # | 14:59:19 | eeevil | natschil: I wanted to do a D implementation long ago :) |
| # | 15:00:30 | natschil | 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) |
| # | 15:00:41 | Dyrcona | natschil: i'm not sure that you really need to have a C function though. |
| # | 15:01:37 | Dyrcona | 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. |
| # | 15:02:33 | natschil | Dyrcona: Ok, if that works that'd be great. I wasn't completely sure how c++ functions worked with that though. |
| # | 15:03:42 | Dyrcona | functions that are not object members work very much like C functions, except that function names are mangled because of the possibility of overloading. |
| # | 15:05:07 | Dyrcona | 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. |
| # | 15:06:02 | Dyrcona | you then give opensrf the string as the function name to call. |
| # | 15:06:30 | natschil | 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? |
| # | 15:07:09 | Dyrcona | when you create an opensrf service, you call an opensrf function to register your function. that's when you tell opensrf. |
| # | 15:07:51 | natschil | Dyrcona: yes, but what exactly do I tell it? If the function names are mangled, how do I find the "real" function name? |
| # | 15:08:35 | Dyrcona | 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. |
| # | 15:10:43 | natschil | 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? |
| # | 15:10:55 | Dyrcona | 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. |
| # | 15:11:33 | Dyrcona | you create the dispatch table. because of c++ name mangling you can't your functions real name until after the code is compiled. |
| # | 15:11:51 | Dyrcona | ^you can't know your |
| # | 15:12:10 | steve_ has quit IRC |
| # | 15:12:32 | natschil | 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? |
| # | 15:12:44 | Dyrcona | no. |
| # | 15:13:27 | Dyrcona | i'd give opensrf the name of the function as it appears in my source. |
| # | 15:13:49 | tildeequals has joined #evergreen |
| # | 15:14:21 | Dyrcona | 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. |
| # | 15:15:13 | Dyrcona | you'd then have a function to handle all incoming opensrf requests, cracks out the parameters, and runs the appropriate function. |
| # | 15:15:16 | bshum | 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. |
| # | 15:15:24 | Dyrcona | i don't think opensrf runs your code directly. |
| # | 15:15:29 | bshum | It can only match on XXX-YYY-ZZZZ |
| # | 15:16:05 | Dyrcona | bshum change it to .*? :) |
| # | 15:16:25 | bshum | Dyrcona: Right, I tested changing that to match like what we see for the patron registration regex |
| # | 15:16:28 | natschil | Dyrcona: but the function that handles all incoming opensrf requests, won't it's name also be mangled? |
| # | 15:16:28 | bshum | For phone |
| # | 15:16:41 | bshum | Dyrcona: I'm just wondering if there's a reason it's not like that. |
| # | 15:16:50 | bshum | Dyrcona: If it'll break other stuff down the line. |
| # | 15:17:20 | Dyrcona | natschil: yes, but it shouldn't matter, if I understand correctly, because opensrf won't be calling that function, your code will be. |
| # | 15:17:47 | Dyrcona | opensrf sends you a message: run function blah with parameters x, y, z. |
| # | 15:18:16 | Dyrcona | whatever code you've got looks up function blah, and calls it with parameter x, y, z and returns the result. |
| # | 15:19:06 | natschil | 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 |
| # | 15:19:51 | Dyrcona | natschil: not if your method is declared extern C in your headers. |
| # | 15:20:15 | Dyrcona | natschil: you can very easily call C from C++. |
| # | 15:21:04 | Dyrcona | natschil: as I said earlier a C++ wrapper would make this so much easier if you plan on doing a lot of this. |
| # | 15:22:28 | Dyrcona | I need to look at the opensrf C interfaces in more detail. |
| # | 15:23:45 | natschil | 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... |
| # | 15:27:18 | natschil | 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! |
| # | 15:27:23 | natschil has quit IRC |
| # | 15:30:09 | Dyrcona | too bad he left. |
| # | 15:30:13 | Dyrcona | i have an answer. |
| # | 15:30:18 | Dyrcona | he can't do what he wants. |
| # | 15:30:53 | Dyrcona | it doesn't look like the internal function register_method in libopensrf would handle name mangled functions. |
| # | 15:31:17 | Dyrcona | it didn't work the way i thought it did. typical. i should do some investigation before i open my big mouth. |
| # | 15:31:42 | Dyrcona | basically, it sounds like natschil is trying to call c++ from c and you typically can't do that. |
| # | 15:32:35 | bshum | Well, maybe he'll see the log :) |
| # | 15:32:50 | tsbere | Leave him a @later? |
| # | 15:37:29 | jenny1 has joined #evergreen |
| # | 15:38:01 | mtcarlson has quit IRC |
| # | 15:40:53 | jenny has quit IRC |
| # | 15:41:54 | Dyrcona | @later natschil The only way I see it working is for you to declare your C++ function as extern C. |
| # | 15:41:54 | pinesol` | 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. |
| # | 15:42:03 | Dyrcona | oops. |
| # | 15:44:29 | phasefx | @later tell Dyrcona doh |
| # | 15:44:29 | pinesol` | phasefx: The operation succeeded. |
| # | 15:44:57 | Dyrcona | @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. |
| # | 15:44:57 | pinesol` | Dyrcona: The operation succeeded. |
| # | 15:45:21 | Dyrcona | -> phasefx :) |
| # | 15:46:15 | Dyrcona decides to try something as an experiment. |
| # | 15:50:30 | collum has left #evergreen |
| # | 15:55:06 | jenny1 has left #evergreen |
| # | 15:55:41 | Meliss has quit IRC |
| # | 15:56:21 | sfortin has quit IRC |
| # | 15:57:12 | mtcarlson has joined #evergreen |
| # | 15:57:54 | bshum has quit IRC |
| # | 16:00:40 | tspindler has quit IRC |
| # | 16:03:38 | yboston has quit IRC |
| # | 16:09:07 | dbs has quit IRC |
| # | 16:11:16 | gdunbar has quit IRC |
| # | 16:12:20 | Dyrcona | oh well. experiment failed. I can't even get a simple program to compile with g++ against libopensrf..... |
| # | 16:15:53 | Dyrcona | struct socket_node; |
| # | 16:15:55 | Dyrcona | typedef struct socket_node_struct socket_node; |
| # | 16:15:57 | Dyrcona | Aren't valid c++, but are valid C. |
| # | 16:18:39 | berick | crazy. i tought C++ was a superset of C. |
| # | 16:21:57 | dbs has joined #evergreen |
| # | 16:23:41 | Dyrcona | 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. |
| # | 16:25:12 | Dyrcona | http://www.cprogramming.com/tutorial/c-vs-c++.html |
| # | 16:26:16 | Dyrcona | That's not even a good short list. Shoulda looked first. been impulsive today. :) |
| # | 16:26:31 | granitize has left #evergreen |
| # | 16:27:19 | rjackson-isl has quit IRC |
| # | 16:31:35 | berick | Dyrcona: interesting... |
| # | 16:32:17 | Dyrcona | This one is more interesting: http://david.tribble.com/text/cdiffs.htm |
| # | 16:39:17 | Dyrcona | 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. |
| # | 16:40:10 | tsbere just had to manually install wget to run makefile.install on ubuntu-lucid. <_< |
| # | 16:40:13 | Dyrcona | 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. |
| # | 16:41:49 | Dyrcona | guess i'll take a fresh look in the morning when my brain is less clouded by other things. |
| # | 16:55:34 | dbs has quit IRC |
| # | 17:02:30 | jamesrf has quit IRC |
| # | 17:02:38 | kmlussier has quit IRC |
| # | 17:05:53 | tsbere | ... |
| # | 17:06:03 | tsbere isn't getting vandelay loading |
| # | 17:10:09 | tsbere | eeevil, you around? |
| # | 17:19:16 | lisppaste | tsbere pasted "rel_2_0 db fix" at http://paste.lisp.org/display/116210 |
| # | 17:19:36 | tsbere | @later tell eeevil <lisppaste> tsbere pasted "rel_2_0 db fix" at http://paste.lisp.org/display/116210 |
| # | 17:19:36 | pinesol` | tsbere: The operation succeeded. |
| # | 17:22:39 | granitize has joined #evergreen |
| # | 17:30:11 | tsbere | @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. |
| # | 17:30:11 | pinesol` | tsbere: The operation succeeded. |
| # | 17:31:03 | Dyrcona has quit IRC |
| # | 18:05:13 | pmplett has quit IRC |
| # | 18:14:47 | jamesrf has joined #evergreen |
| # | 18:24:42 | pmplett has joined #evergreen |
| # | 18:55:56 | mtcarlson has quit IRC |
| # | 19:02:36 | jamesrf has quit IRC |
| # | 19:33:39 | youdonotexist has quit IRC |
| # | 20:23:50 | mtate has quit IRC |
| # | 20:24:04 | mtate has joined #evergreen |
| # | 20:45:50 | tildeequals has quit IRC |
| # | 21:02:34 | moodaepo_home has joined #evergreen |
| # | 21:24:16 | moodaepo_home has quit IRC |
| # | 23:11:48 | jeffdavis has quit IRC |
| # | 23:30:23 | lisppaste has quit IRC |
| # | 23:41:45 | pmplett has quit IRC |
April 10-13