| 00:14.44 | the_map | ~blast007++ |
| 00:14.46 | the_map | :D |
| 00:40.00 | macsforme | karma for introducing a bug? :P |
| 00:40.52 | blast007 | lol |
| 00:41.01 | macsforme | at least I know an easy way to earn some, now |
| 00:41.11 | blast007 | for helping him get a functional OS going :) |
| 00:41.22 | macsforme | oh :P |
| 00:41.34 | macsforme | ~blast007++ |
| 00:43.31 | the_map | oh, didn't realize what that looked like :P |
| 00:43.56 | the_map | blast007: it's a bit early to say if this is going to work :P |
| 00:44.24 | blast007 | nah, it's Debian, it'll work ;) |
| 00:44.36 | the_map | uh huh, right |
| 00:45.04 | the_map | nothing against debian, of course |
| 00:45.06 | blast007 | and if not, there's far better people than me that can help too |
| 01:56.49 | *** join/#bzflag infobot (ibot@rikers.org) |
| 01:56.50 | *** topic/#bzflag is http://BZFlag.org || http://ohloh.net/p/bzflag || https://wiki.bzflag.org/Getting_Help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.4 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19186 |
| 01:56.50 | *** mode/#bzflag [+v infobot] by ChanServ |
| 02:03.43 | allejo | I thought it was discouraged to create your own bz_ApiString and to use std::string instead |
| 02:06.33 | blast007 | std::string can't be passed across the DLL boundary, at least |
| 02:07.42 | blast007 | JeffM is more familar with the quirks of that |
| 02:08.10 | allejo | wouldn't be passed through the boundary though, you'd be creating the std::string inside the plugin to check for it |
| 02:08.23 | allejo | it's not like the API is returning the std::string |
| 02:10.44 | blast007 | except when it does... BZF_API bz_APIStringList *bz_getHelpTopic( std::string name ); |
| 02:11.40 | allejo | why isn't that a const char*...? |
| 02:12.00 | blast007 | because consistency! |
| 02:12.09 | blast007 | it's what we're all about |
| 02:12.15 | allejo | lol |
| 02:12.30 | allejo | should have logs about this somewhere |
| 02:12.34 | blast007 | someday, maybe we'll reach at least PHP levels of consistency |
| 02:12.36 | allejo | but... from a long time ago |
| 02:14.26 | blast007 | in a galaxy far, far away? |
| 02:14.40 | blast007 | $ head -n 1 irclogs/freenode/#bzflag.log |
| 02:14.41 | blast007 | --- Log opened Mon Dec 11 06:37:38 2006 |
| 02:26.15 | allejo | https://wiki.bzflag.org/Bz_APIString#Construction |
| 02:31.12 | blast007 | hmm, fun |
| 02:32.06 | *** join/#bzflag Void7 (~Void7@205.157.147.198) |
| 02:34.56 | allejo | original content of that page was by JeffM so that's why I kinda just went with it |
| 02:41.12 | blast007 | so is it also bad to create a bz_APIStringList in a plugin? |
| 02:42.35 | blast007 | sounds like those are okay |
| 02:43.43 | allejo | my understanding is that those are ok. plus, nothing in the wiki explicitly saying otherwise |
| 02:44.34 | allejo | and you don't actually use a constructor for those since the functions just take the pointer to it |
| 03:05.13 | DTRemenak | why would you want to create one? |
| 03:05.35 | DTRemenak | just use a vector, if you're not passing it across the DLL boundary |
| 03:09.01 | DTRemenak | and no, do not create one in a plugin. use bz_newStringList if you need one. c'tor has to run on the bzfs side. |
| 03:09.30 | blast007 | that's what I mean |
| 03:09.56 | blast007 | I don't mean define the class for a bz_APIStringList in a plugin |
| 03:11.36 | DTRemenak | a plugin should never own an API container. bzfs needs to own them. a plugin can absolutely ask bzfs to create one and get a pointer back, that's fine. |
| 03:13.02 | DTRemenak | (and, due to an implementation defect, a plugin should NEVER call the bzAPIStringList functions that accept a std::string) |
| 03:13.54 | allejo | so what exactly is the issue with crossing the DLL boundary? |
| 03:14.23 | DTRemenak | the implementation of the class with the same name may be different (and the object itself may even be a different size) |
| 03:14.44 | DTRemenak | so you'll get unpredictable behavior when you access the wrong vtbl |
| 03:16.27 | DTRemenak | you can get the same problem on linux with shared object libraries, it's just a lot rarer to build against different STL implementations |
| 03:16.36 | DTRemenak | on windows that's really common |
| 03:16.45 | allejo | oh so that's the reason for the custom bz_* objects? chances are you won |
| 03:16.53 | allejo | won't already have a bz_ApiString? |
| 03:17.17 | DTRemenak | the header is KNOWN to be common to both components, and the implementation is wrapped |
| 03:17.34 | DTRemenak | so as long as one side only accesses the object through the header there will be no problems |
| 03:18.32 | DTRemenak | we could break it the same way (by changing the definition of the class in the header), but we can avoid that |
| 03:18.52 | DTRemenak | whereas we have no control over the STL headers |
| 03:21.47 | allejo | this is starting to make a lot more sense now |
| 03:24.22 | blast007 | yeah, but does it run crysi-wait, wrong meme |
| 03:25.21 | blast007 | DTRemenak: okay, so you meant don't 'new' your own bz_APIStringList in your plugin |
| 03:25.27 | DTRemenak | yes |
| 03:25.42 | DTRemenak | or construct them on the stack |
| 03:26.43 | DTRemenak | but you CAN ask bzfs to do it for you...then everything is hunky-dory |
| 03:27.41 | DTRemenak | same thing should be true for the other API objects like bz_APIString itself |
| 03:29.11 | DTRemenak | (although the same note regarding the member functions that accept std::string parameters probably holds true there too...) |
| 05:13.07 | *** join/#bzflag DTRemenak (~DTRemenak@cpe-172-112-10-183.socal.res.rr.com) |
| 05:13.07 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 05:13.07 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 05:33.56 | *** join/#bzflag Delusional (~Delusiona@unaffiliated/delusional) |
| 05:45.33 | rodie | <PROTECTED> |
| 05:45.58 | rodie | and that was enough. |
| 05:47.12 | RoscoePColtrain | basically templates cannot cross the DLL boundary |
| 05:47.30 | rodie | why would a dll boundry matter? |
| 05:47.54 | rodie | ^should |
| 05:47.55 | RoscoePColtrain | because it is likely that the DLL might have been compiled with a different compiler than the main |
| 05:48.05 | allejo | I got lost after "construct them on the stack" :( |
| 05:48.16 | RoscoePColtrain | if you require that the whole project is build from source, it's not a problem |
| 05:48.33 | RoscoePColtrain | allejo: an object that is constructed must be destructed |
| 05:48.55 | RoscoePColtrain | destructor is a function like anything else |
| 05:49.00 | allejo | oh |
| 05:49.08 | RoscoePColtrain | subject to vtable corruption/misinterpretation/whatever |
| 05:49.16 | allejo | ok now everything makes sense :D |
| 05:50.04 | rodie | i guess these fancy oo languages don't things simply like c;) |
| 05:50.11 | RoscoePColtrain | templates aren't "objects" like everything else |
| 05:50.12 | rodie | ^compilers too |
| 05:50.20 | RoscoePColtrain | they are code generators :) |
| 05:50.26 | rodie | oh. |
| 05:50.31 | RoscoePColtrain | subject to different implementations |
| 05:50.53 | RoscoePColtrain | one compiler may instantiate a template one way (or even use a different definition!) |
| 05:50.57 | RoscoePColtrain | than another |
| 05:51.21 | RoscoePColtrain | it's not really the language that complicates things... DLL's are complicated |
| 05:51.27 | RoscoePColtrain | and not for the average schmuck |
| 05:53.01 | rodie | i'd bet they exhibit similar problems to 60s and 70s "main frame" os compilers. |
| 05:53.16 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 05:53.31 | RoscoePColtrain | well, I wasn't coding in the (early) 70's, but I can't speak to that |
| 05:53.38 | RoscoePColtrain | we did assembler :) |
| 05:53.50 | rodie | that's where my heart still is;) |
| 05:54.01 | rodie | (assembly) |
| 05:54.02 | RoscoePColtrain | not me. I'm all about the abstractions |
| 05:54.29 | rodie | only when abstractions making coding more durable, sure;) |
| 05:54.53 | RoscoePColtrain | abstractions simplify complex concepts |
| 05:54.57 | RoscoePColtrain | allowing more complex concepts |
| 05:55.05 | rodie | yes, they can. until they hide deep flaws. |
| 05:55.33 | RoscoePColtrain | implementation defects are different than abstractions |
| 05:55.36 | rodie | but i can't win an argument against an idea, and am not trying, |
| 05:55.45 | RoscoePColtrain | although... most simplifying assumptions are wrong :) |
| 05:55.59 | rodie | just saying "reality" has shown me too many coding projects where problems were created which didn't need to exist ;) |
| 05:56.01 | rodie | that's all. |
| 05:56.15 | RoscoePColtrain | oh, the average programmer is incompetent |
| 05:56.22 | RoscoePColtrain | that's where the flaws come from |
| 05:56.43 | rodie | heh. which is everything ;) |
| 05:57.03 | rodie | unless you can prove some class library came from the gods. |
| 05:57.08 | rodie | ;) |
| 05:57.24 | RoscoePColtrain | in general, I will trust a class library |
| 05:57.43 | RoscoePColtrain | it's the new grad who wants to reinvent the wheel that is the main danger |
| 05:58.14 | the_map | and people like me that can look at a computer and break it ;P |
| 05:58.16 | rodie | i find it is overuse of "off the shelf" stuff. |
| 05:58.21 | RoscoePColtrain | example of absraction: |
| 05:58.29 | RoscoePColtrain | do you know what RAII means? |
| 05:59.28 | RoscoePColtrain | (did I scare you off, or are you just googling?) |
| 05:59.34 | rodie | who you asking? |
| 05:59.48 | RoscoePColtrain | you, mostly |
| 06:00.13 | rodie | i know the acronym. |
| 06:00.28 | RoscoePColtrain | Resource Allocation Is Initialization |
| 06:00.52 | RoscoePColtrain | it's the idea that a resource should always be allocated in a constructor and released in a destructor |
| 06:01.00 | rodie | ok. |
| 06:01.15 | RoscoePColtrain | so rather than remembering a bunch of new's and free's, you just create std::string |
| 06:01.23 | RoscoePColtrain | it manages memory so you don't have to |
| 06:01.35 | rodie | sorry, you don't need to explain it. |
| 06:01.43 | RoscoePColtrain | the same concept can/should be applied to other resources, like files, or mutexes |
| 06:02.12 | RoscoePColtrain | point being, that abstraction helps deal with one of the largest perceived flaws in C++ |
| 06:02.32 | RoscoePColtrain | personally, I prefer explicit resource management over garbage collection |
| 06:02.47 | rodie | have cats to feed ;) |
| 06:02.56 | RoscoePColtrain | people who only deal with garbage collected languages never really understand that resources come at a cost. |
| 06:03.11 | RoscoePColtrain | it's ok, I can ramble without an audience :) |
| 06:04.42 | rodie | no, i mean they are crawling all over me |
| 06:04.51 | rodie | thinking i'm a giant feeding bottle;) |
| 06:05.05 | RoscoePColtrain | are you? |
| 06:05.11 | rodie | to them, it appearzs. |
| 06:05.18 | rodie | back later. ramble as you please. |
| 06:05.29 | rodie | ;) |
| 06:06.03 | rodie | but you can assume a few things i do know ;) |
| 06:06.14 | RoscoePColtrain | I assume nothing |
| 06:06.22 | rodie | try it ;) |
| 06:06.28 | rodie | & for now |
| 06:06.32 | RoscoePColtrain | I have. it's why I don't |
| 06:48.55 | *** join/#bzflag the_map_ (~the_map@unaffiliated/the-map/x-1795707) |
| 07:57.10 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 09:36.58 | *** join/#bzflag dropsy (b23e059d@gateway/web/freenode/ip.178.62.5.157) |
| 11:08.18 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 11:25.14 | rodie | then there's always the assuming a negative, as i was slightly attempting to suggest ;) |
| 11:30.35 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 11:32.07 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 11:44.12 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 14:49.26 | *** join/#bzflag Void7 (~Void7@205.157.147.198) |
| 15:24.38 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 15:53.19 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 17:06.11 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 17:50.46 | *** join/#bzflag KaadmY (uid135503@gateway/web/irccloud.com/x-vhmsjrochahjpzqr) |
| 17:54.36 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 18:15.51 | *** join/#bzflag Void7 (~Void7@205.157.147.198) |
| 21:58.00 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 22:58.05 | *** join/#bzflag alpha1-2 (~alpha1@181.111.69.151) |
| 23:04.59 | alpha1-2 | can it be that compiling a new plug-in in linux is only possible compiling all BZ at once? |
| 23:08.21 | blast007 | can you elaborate on what you're trying to do? just trying to build a custom plugin? |
| 23:08.41 | alpha1-2 | yes, a custom plug-in |
| 23:09.52 | blast007 | are you trying to build it without adding it to the BZFlag build system? |
| 23:10.55 | blast007 | 2.4.4 and up make it easier to build extra plugins with the rest of the build process |
| 23:11.03 | alpha1-2 | I get this in the plug-in script "Use "configure --enable-custom-plugins=NAME to have it built automatically along with the standard plugins."; just wondering if it is the only way |
| 23:11.41 | blast007 | that's the way we support |
| 23:12.03 | blast007 | if you want to do it another way you'll have to figure out the specifics |
| 23:12.20 | alpha1-2 | ah okay; it seems for Windows there is an individual way, making DLLs, right? |
| 23:12.45 | alpha1-2 | (read it in an kind of old thread) |
| 23:12.52 | blast007 | DLLs are just what WIndows uses instead of .so files |
| 23:13.43 | alpha1-2 | "On linux plugins must be built with the rest of the system, you can't build a single one and just link to export libs like you can do on windows. Our build system just isn't set up that way." https://forums.bzflag.org/viewtopic.php?f=13&t=17872&p=161014&hilit=compiling+plugins#p161009 |
| 23:13.55 | blast007 | the Windows installer does include a .lib or two and some header files, so you can build a new plugin without needing the entire source |
| 23:13.59 | blast007 | we don't have that on Linux |
| 23:14.10 | blast007 | or at least, not included with any binaries |
| 23:14.48 | blast007 | and in the time this conversation took, you could have built bzfs with your custom plugins |
| 23:15.05 | alpha1-2 | okay; yes, got some problems trying to compile individually |
| 23:15.40 | alpha1-2 | there is only necessary the .cpp file right, noany other? |
| 23:16.19 | alpha1-2 | ah only bzfs? |
| 23:17.02 | alpha1-2 | is there a way to compile only bzfs? |
| 23:17.20 | blast007 | --disable-client --disable-bzadmin |
| 23:17.24 | blast007 | (to ./configure) |
| 23:18.01 | alpha1-2 | nice |
| 23:19.07 | alpha1-2 | Iused the script but also the PHP program, then I should use both methods right? |
| 23:19.18 | alpha1-2 | (not only the .cpp) |
| 23:20.29 | blast007 | I don't know what you are referring to |
| 23:21.16 | alpha1-2 | allejo updated a PHP code which helps you to create a plug-in... finding it |
| 23:22.24 | alpha1-2 | Plug-in Starter (Now for 2.4.x!) https://forums.bzflag.org/viewtopic.php?f=78&t=12301 |
| 23:22.29 | blast007 | you might need to use the ./newplug.sh script to create a new plugin and then replace the .cpp file it creates with your actual .cpp |
| 23:22.42 | alpha1-2 | ah okay, got it, thanks! |
| 23:45.22 | *** join/#bzflag [Gort] (~gort@unaffiliated/gort/x-9231432) |
| 23:53.50 | kierra | hey Gort |
| 23:54.01 | [Gort] | hey |
| 23:54.26 | [Gort] | I wish that other Gort in Freenode would give up the nick. ;) |
| 23:54.37 | kierra | oh |
| 23:56.43 | [Gort] | odd... that Gort hasn't been here for 39 weeks, yet still has kept the nick. I thought nicks disappeared after a few weeks non-usage |
| 23:59.09 | werelizard | [Gort]: They don't get automatically dropped; you can ask staff nicely if you can have the nick, though |
| 23:59.36 | blast007 | or you can ask the owner of the nick |