#exult@irc.freenode.net logs for 22 Nov 2013 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage


[00:49:02] --> Marzo has joined #exult
[00:57:09] <-- ParuNexus has left IRC (Ping timeout: 248 seconds)
[01:03:41] --> ParuNexus has joined #exult
[01:43:39] <-- ParuNexus has left IRC (Ping timeout: 246 seconds)
[01:50:06] --> ParuNexus has joined #exult
[02:32:39] --> i30817 has joined #exult
[02:34:43] <i30817> Dominus, the '--with-timidity' on configure.ac checks if the directory given exists before configurating the define.
[02:34:44] <i30817> The trouble with this is that the library may not be installed yet when the exult is building - after all the only thing exult needs from the timidity dir is the cfg file.
[02:35:32] <i30817> And i'm providing that myself, so i'd like to set the define to point to the place where i put the cfg file, but the dir doesn't exist yet, see what i mean?
[03:00:32] <i30817> scratch that, i was confused by the sed
[03:00:34] <i30817> if test ! -d $with_timidity; then
[03:00:35] <i30817> with_timidity=`echo "$with_timidity" | sed 's/timidity.cfg//'`
[03:00:37] <i30817> fi
[03:00:38] <i30817> Means if not a dir (a file) remove the timidity.cfg file portion of the path right? False alarm then.
[03:09:03] --> Rottingbeef has joined #exult
[05:06:37] <-- ParuNexus has left IRC (Ping timeout: 240 seconds)
[05:10:56] --> ParuNexus has joined #exult
[07:03:10] <-- i30817 has left IRC (Quit: ChatZilla 0.9.90.1 [Firefox 25.0/20131028112627])
[07:25:50] <-- ParuNexus has left IRC (Ping timeout: 245 seconds)
[07:27:26] --> ParuNexus has joined #exult
[07:29:47] <-- Rottingbeef has left IRC ()
[07:47:54] <-- Dark-Star has left IRC ()
[07:51:00] <sh4rm4> the makefile rule could look like this:
[07:51:05] <sh4rm4> ucparse.hh:
[07:51:15] <sh4rm4> yacc foo bar
[07:51:32] <sh4rm4> test -e ucparse.h && cp ucparse.h ucparse.hh
[08:00:35] <wjp> unfortunately it's not quite that simple
[08:01:29] <sh4rm4> oh ? what could go wrong ?
[08:02:40] <wjp> well, this is automake 1.12's yy rule:
[08:02:47] <wjp> $(am__skipyacc) $(SHELL) $(YLWRAP) $< y.tab.c $@ y.tab.h `echo $@ | $(am__yacc_c2h)` y.output $*.output -- $(YACCCOMPILE)
[08:04:04] <sh4rm4> that looks way too complex
[08:04:40] <sh4rm4> wouldn't it simplify things if you put the rule into makefile.in ?
[08:08:37] <wjp> sure, you can use a simpler version, but not quite as simple as the one you gave
[08:08:45] <sh4rm4> :(
[08:08:57] <wjp> (and not in Makefile.in of course, since that's auto-generated)
[08:09:04] <wjp> may I suggest actually testing it? :-)
[08:10:30] <sh4rm4> let me try...
[08:42:01] <sh4rm4> make[3]: Entering directory `/tmp/exult/usecode/compiler'
[08:42:02] <sh4rm4> /bin/bash ../../ylwrap ucparse.yy y.tab.c ucparse.cc y.tab.h `echo ucparse.cc | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s/c++$/h++/ -e s/c$/h/` y.output ucparse.output -- bison -y -d -v
[08:42:02] <sh4rm4> /bin/bash ../../ylwrap uclex.ll lex.yy.c uclex.cc -- flex
[08:42:02] <sh4rm4> make[3]: *** No rule to make target `ucparse.h', needed by `uclex.o'. Stop.
[08:42:02] <sh4rm4> m
[08:46:17] <sh4rm4> fixed
[08:46:34] <sh4rm4> diff --git a/usecode/compiler/Makefile.am b/usecode/compiler/Makefile.am
[08:46:34] <sh4rm4> index b12e3fa..b637615 100644
[08:46:34] <sh4rm4> --- a/usecode/compiler/Makefile.am
[08:46:34] <sh4rm4> +++ b/usecode/compiler/Makefile.am
[08:46:34] <sh4rm4> @@ -28,6 +28,9 @@ ucc_LDADD = \
[08:46:34] <sh4rm4> ../libusecode.la \
[08:46:36] <sh4rm4> $(SYSLIBS)
[08:46:38] <sh4rm4>
[08:46:40] <sh4rm4> +ucparse.h: ucparse.cc
[08:46:42] <sh4rm4> + $(SHELL) test -e ucparse.hh && cp ucparse.hh ucparse.h
[08:46:44] <sh4rm4> +
[08:46:46] <sh4rm4> uclex.o: uclex.cc ucparse.h
[08:46:48] <sh4rm4>
[09:01:41] <sh4rm4> Looking for 'blackgate' at '/share/exult/blackgate'... found game with identity 'FORGE'
[09:01:41] <sh4rm4> Looking for 'forgeofvirtue' at '/share/exult/forgeofvirtue'... but it wasn't there.
[09:01:41] <sh4rm4> Looking for 'serpentisle' at '/share/exult/serpentisle'... found game with identity 'SILVER SEED'
[09:01:41] <sh4rm4> Looking for 'silverseed' at '/share/exult/silverseed'... but it wasn't there.
[09:01:47] <sh4rm4> ^ that's ok i guess ?
[09:02:20] <sh4rm4> however there's silverseed/mods
[09:02:35] <sh4rm4> should i copy that into serpentisle/ ?
[09:10:04] <-- Marzo has left IRC (Ping timeout: 264 seconds)
[09:56:03] <Dominus> sh4rm4: yes, copy it over
[09:56:39] <Dominus> the different folders are only if you really have the original BG and SI without the addons and also the addons
[09:57:39] <Dominus> https://a.fsdn.com/con/app/proj/exult/screenshots/281503.jpg
[10:17:39] <-- ParuNexus has left IRC (Ping timeout: 272 seconds)
[10:20:06] <-- sh4rm4 has left IRC (Ping timeout: 240 seconds)
[10:47:34] --> ParuNexus has joined #exult
[10:55:51] <Dominus> hmm, our weather effects are certainly not right. they are not resetting as they should
[11:19:21] --> Marzo has joined #exult
[11:22:38] --> sh4rm4 has joined #exult
[11:39:09] <-- ParuNexus has left IRC (Ping timeout: 240 seconds)
[11:42:54] --> ParuNexus has joined #exult
[11:53:45] <-- Marzo has left IRC (Read error: Connection reset by peer)
[11:53:47] --> Marzo1 has joined #exult
[11:53:47] --- Marzo1 is now known as Marzo
[12:20:27] <Dominus> wjp, marzo, weather effects are screwy. The anti magic rain will keep up as long as there is no other weather change
[12:22:29] <Dominus> I'm thinking that this is because there needs some end in objs/egg.cc:1061
[12:24:24] <Marzo> If memory serves, weather in the original (at least for the weather intrinsic when a duration of zero was specified) lasted something like 100 or 200 hours; and when I implemented that, I made weather eggs work like that too
[12:24:35] <Marzo> It could be that weather eggs work differently, but we'd have to check
[12:25:15] <wjp> hm, I thought I did spot a weather reset switch somewhere
[12:25:32] <Dominus> the anti-magic egg definitely depends on distance to the egg
[12:26:28] <wjp> Game_window::emulate_cache does something related
[12:27:50] <Dominus> wjp, somehow that cache thing doesn't seem to trigger for me. at least not when teleporting away and walking around
[12:29:02] <Dominus> hmm, maybe it does :)
[12:30:25] <Dominus> but who knows what egg I triggered :)
[12:34:15] <Dominus> and interestingly when I jsut keep around that island with the cube generator and sleep there the anti-magic effect doesn't seem to turn off at all
[12:36:01] <Dominus> in the original the anti-magic effect fades very soon after the destruction of the generator
[12:54:51] --> TheCycoONE has joined #exult
[13:28:12] <-- wjp has left IRC (Ping timeout: 252 seconds)
[13:28:28] --> wjp has joined #exult
[13:29:47] --- ChanServ gives channel operator status to wjp
[13:38:16] <sh4rm4> wjp, do you think my patch is OK ?
[13:38:26] <sh4rm4> it seems to work
[13:39:22] --> WoLF2385 has joined #exult
[13:46:32] <sh4rm4> Dominus, thx, that did it
[13:47:34] <wjp> sh4rm4: it's roughly what I meant when I said 00:36 <@wjp> generating the .hh from the .h is probably safest
[13:48:12] <wjp> but I'll have to test it with a few configurations
[13:48:28] <sh4rm4> cool
[13:50:11] <-- WoLF2385 has left #exult ("Leaving")
[14:09:44] <-- Marzo has left IRC (Disconnected by services)
[14:09:44] --> Marzo1 has joined #exult
[14:14:10] <-- ParuNexus has left IRC (Ping timeout: 245 seconds)
[14:22:30] <Dominus> sh4rm4: is there anything else to do except that makefile.am change? So I can test it myself later on os x
[14:23:16] <wjp> should be all
[14:23:34] <Dominus> k, will do later tonight
[14:23:44] <wjp> you may have to do a 'make distclean' or remove ucparse.cc if you're using an existing tree
[14:24:12] <wjp> (maybe)
[14:24:28] <wjp> but for testing that would be good to do anyway of course
[14:25:56] <Dominus> good, will test thoroughly.
[14:45:27] --> ParuNexus has joined #exult
[15:16:37] <-- Marzo1 has left IRC (Ping timeout: 265 seconds)
[15:18:44] --> Marzo has joined #exult
[16:48:48] --> Rottingbeef has joined #exult
[16:51:08] <-- Rottingbeef has left IRC (Read error: Connection reset by peer)
[16:51:55] --> Rottingbeef has joined #exult
[17:28:09] <sh4rm4> thou wilt find this very pleasant
[17:28:55] <Rottingbeef> What?
[17:29:07] <sh4rm4> the ucparse.hh patch
[17:30:00] <sh4rm4> -- Erstam, thy devoted servant
[17:31:26] <Rottingbeef> What does the patch do?
[17:32:14] --> ShamblerDK has joined #exult
[17:32:19] <sh4rm4> it copies ucparse.hh to ucparse.h after the yacc pass, in case automake > 1.11 was used
[17:32:20] --> ShamblerDK_ has joined #exult
[17:32:48] <-- ShamblerDK has left IRC (Read error: Connection reset by peer)
[17:32:56] <sh4rm4> and in case automake <= 1.11 was used, it does nothing
[17:33:03] <Rottingbeef> As someone who doesn't actually do any programming or work on the project, that sentence is gloriously gobbledigooky!
[17:34:06] <sh4rm4> Rottingbeef, <Dominus> at http://stackoverflow.com/questions/16098509/automake-1-12-changes-bison-yacc-output-names-backwards-incompatible-change
[17:34:08] <sh4rm4> ^ context
[17:34:28] <Rottingbeef> k
[17:34:29] <Rottingbeef> !
[18:09:09] <-- Rottingbeef has left IRC ()
[18:17:52] <-- ParuNexus has left IRC (Ping timeout: 264 seconds)
[18:25:38] <sh4rm4> i often encounter the problem that i click once, but 2 clicks are registered in exult
[18:25:48] <sh4rm4> so it skips parts of the dialogue
[18:53:32] --> ParuNexus has joined #exult
[20:08:50] <Dominus> sh4rm4: that seems more like system problem or sdl rather than exult
[20:10:04] <sh4rm4> hmm i haven't seen this in other sdl apps tho
[20:10:16] <sh4rm4> maybe exult does some mouse speed hacks ?
[20:12:55] <sh4rm4> <sh4rm4> Program received signal SIGSEGV, Segmentation fault.
[20:12:59] <sh4rm4> <dalias> there's a SIGCHLD handler that's calling wait
[20:13:08] <sh4rm4> <ente> calling wait in a SIGCHLD handler sounds like a bad idea
[20:13:23] <sh4rm4> <dalias> which program is it ?
[20:13:24] <sh4rm4> <sh4rm4> exult
[20:13:24] <sh4rm4> <sh4rm4> it happens when you enable sound output
[20:13:24] <sh4rm4> <dalias> can you find where in the code it's installing the SIGCHLD handler?
[20:13:39] <sh4rm4> <sh4rm4> https://github.com/rofl0r/exult/blob/master/exult.cc#L285
[20:13:39] <sh4rm4> <sh4rm4> // a SIGCHLD handler to properly clean up forked playmidi processes (if any)
[20:13:39] <sh4rm4> <dalias> i would just remove that line
[20:13:39] <sh4rm4> <dalias> the proper way to cleanup the zombie is to save its pid and waitpid() for it at the appropriate time
[20:13:39] <sh4rm4> <dalias> not indiscriminately reap all child processes
[20:13:41] <sh4rm4> <dalias> but fixing that requires finding the code that's creating the playmidi processes
[20:13:55] <wjp> um, you shouldn't be using that midi backend
[20:14:14] <sh4rm4> problem is the SIGCHLD handler is always installed
[20:15:17] <wjp> perfect time to get rid of that midi backend I suppose
[20:17:06] <sh4rm4> ...and the faulty sigchld handler ^^
[20:17:55] * wjp sighs
[20:26:43] <Lightkey> SIGSIGH
[21:25:36] <sh4rm4> http://git.etalabs.net/cgit/musl/commit/?id=d8f1908b821098f7a2ff03fbf6b152fe13023057
[21:55:24] <-- TheCycoONE has left IRC (Quit: And then there were n-1)
[22:37:39] <-- Marzo has left IRC (Ping timeout: 272 seconds)
[23:06:15] --> Marzo has joined #exult
[23:07:15] <Dominus> wjp, sh4rm4: I get this error:
[23:07:35] <Dominus> /bin/sh test -e ucparse.hh && cp ucparse.hh ucparse.h
[23:07:36] <Dominus> /bin/test: /bin/test: cannot execute binary file
[23:08:26] <Dominus> automake 1.14
[23:10:22] <sh4rm4> Dominus, on mac ?
[23:10:27] <Dominus> yes
[23:10:57] <sh4rm4> what happens when you enter /bin/test in the shell ?
[23:10:59] <wjp> just remove the $(SHELL) I think
[23:11:17] <wjp> (you can't treat binaries as shell scripts)
[23:12:35] <sh4rm4> hmm iirc make needs some hint tho that what follows is a shell command
[23:13:01] <Dominus> wjp, that gets me past that point but halts at
[23:13:02] <Dominus> Undefined symbols for architecture x86_64:
[23:13:02] <Dominus> "vtable for Uc_switch_expression_case_statement", referenced from:
[23:13:03] <Dominus> yyparse() in ucparse.o
[23:13:03] <Dominus> NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
[23:13:42] <Dominus> with clang
[23:14:24] <Dominus> clang earlier complains about ucparse.yy but it's only a warning:
[23:14:27] <Dominus> ucparse.yy:796:33: warning: comparison of constant 'Class' (4) with expression
[23:14:27] <Dominus> of type 'bool' is always false
[23:18:14] <Dominus> btw. neither make clean or distclean gets rid of the ucparse.cc .hh. h and ucparse.output
[23:19:58] <sh4rm4> that's a bug
[23:21:54] <Dominus> testing... with older gcc and automake 1.12.5 it works. now testing whether it is newer automake or clang hitting a wall ther
[23:21:56] <Dominus> e
[23:22:54] <sh4rm4> the problem you're hitting is 100% unrelated to automake
[23:23:11] <sh4rm4> probably due to leftover files, or a clang incompatibility
[23:23:14] <Dominus> the test says it's clang :)
[23:24:17] <sh4rm4> mixing object files of gcc with clang ones will probably not work as well
[23:24:56] <Dominus> same automake version compiles with llvm-gcc-4.2 (4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6)) but fails with the above error with current clang
[23:25:04] <sh4rm4> (it would work with C, but C++ has not yet standardized name mangling...)
[23:25:27] <Dominus> clang --version Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
[23:26:36] <sh4rm4> i suspect it will work when you do a fresh svn checkout and apply the patch, then build with new clang
[23:26:53] <Dominus> why should that matter?
[23:27:13] <sh4rm4> due to left-over object files in the tree
[23:28:07] <Dominus> after make distclean there are no leftovers
[23:28:44] <sh4rm4> theoretically yes ;)
[23:28:59] <Dominus> in praxis as well
[23:29:23] <wjp> what's the exact link command that's failing?
[23:30:33] <Dominus> one moment...
[23:31:49] <Dominus> /bin/sh ../../libtool --tag=CXX --silent --mode=link /usr/bin/clang++ -arch i386 -w -I/opt/exult.i386/include -w -isysroot /Developer-old/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -arch i386 -m32 -O2 -msse -msse2 -force_cpusubtype_ALL -L/opt/exult.i386/lib -w -isysroot /Developer-old/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -arch i386 -m32 -O2 -msse -msse2 -force_cpusubtype_ALL -o ucc ucparse.o uclex.o
[23:31:50] <Dominus> ucmain.o ucclass.o ucexpr.o ucfun.o ucloc.o ucstmt.o ucsym.o ../libusecode.la -framework CoreFoundation -framework AudioUnit -framework AudioToolbox -framework CoreMID
[23:31:56] <wjp> try removing the inline on line 811 of ucstmt.cc
[23:32:35] <wjp> not sure if that'll have any impact though
[23:32:41] <wjp> (but it's strange)
[23:32:42] <Dominus> what's the inline?
[23:32:50] <wjp> inline Uc_switch_expression_case_statement::~Uc_switch_expression_case_statement
[23:32:53] <wjp> the word inline
[23:33:02] <wjp> my line numbers may be out of date
[23:33:37] <Dominus> aehm, yes :) (line 727)
[23:34:24] <Dominus> no, that's not it
[23:35:09] <Dominus> same error
[23:35:25] <Dominus> oops, one moment
[23:35:41] <Dominus> sorry, wjp, that worked
[23:36:13] <Dominus> I was in the wrong program when I hit cmd+s for saving the change to ucstmt.cc
[23:49:41] <Dominus> wjp, any idea who to blame? us or clang?
[23:55:02] <wjp> us. That inline doesn't make any sense