IRC channel logs


back to list of logs

<rlb>I suppose I'll try 3.0.1->3.0.2 first, and if that doesn't work then perhaps --enable-jit=no for ppc64el too, and see what happens.
<rlb>(unless that test is just known to be sketchy)
<soda__hobart>hey everybody, i am trying to use guile as the scripting interface for a 2D game engine i'm making with c++. is there any documentation on how to wrap a c++ object instance with guile? all the functions for my interface are generally procedural, but i need some sort of reference to my "GameLoop" instance. can i use a pointer or something?
<Aurora_iz_kosmos>soda__hobart: That'd be mentioned around these parts:
<soda__hobart>so the foreign object types part is what i should look at? i don't even need any real object-oriented kind of stuff for my API, just a reference to the GameLoop object that i can pass procedurally
<rlb>soda__hobart: unless things have changed, you'll likely want to write a C-ish "shim" interface and wrap that.
<soda__hobart>yep, that's what i was intending to do
<rlb>i.e. for foo->bar(), you'll provide a foo_bar(this), etc.
<rlb>or something equivalent.
<soda__hobart>cool, glad to hear that that's a viable way to do it
<rlb>There may be some helper tools, but up to a certain point, I'd likely just do it by hand.
<Aurora_iz_kosmos>Hm. He could tie it into GOOPS too.
<rlb>(i.e. reduce dependencies)
<soda__hobart>yeah, i mean it's just to expose some of the primitive methods used by my engine
<rlb>And while Guile does have runtime ffi, and that might be what you want, writing an actually C dynamic lib has the advantage that you can lean on the compiler to make sure you get the types/sizes/etc. right.
<soda__hobart>so for something like "jump" or "move", i can define those in guile
<Aurora_iz_kosmos>Also means you don't have JIT warmup, no?
<rlb>If you're using autotools, the existing macros can help set up the right vars, and then you can just rely on libtool (if you like).
<soda__hobart>i'm using cmake
<soda__hobart>maybe i should use autotools, though
<soda__hobart>what's JIT warmup?
<rlb>Ahh, not sure then. But if you can make a "proper" .so, then you can load it from some module (I usually have a scheme side module wrapper) like this (as the docs mention I assume): (load-extension "" "init_your_lib")
<Aurora_iz_kosmos>soda__hobart: Newer Guile versions have JIT to improve performance. But like most JIT implementations, optimization of calls & such requires using code paths a few times unoptimized first.
<rlb>iirc guile might not have the more substantial kind of "warmup" you might imagine, (if you're coming from the jvm world, for example), i.e. guile's currently a template based jit.
<Aurora_iz_kosmos>Interesting. I may be overestimating it, indeed.
<rlb>i.e. I don't know that it does that kind of analysis.
<rlb>But indeed, sometimes "it's a thing" :)
<Aurora_iz_kosmos>soda__hobart: Anyway, the contrast I was building to was that optimized C/C++ code starts as fast as it'll get.
<rlb>soda__hobart: and note that you can also use SCM_DEFINE and the "snarfer" etc. to automatically handle scheme side docstrings, and much of the contents of your init() function.
<rlb>(The stuff you'd write explicitly via PyArg_ParseTuple() in say python.)
<rlb>soda__hobart: you may find libguile/*.c in guile itself useful for some examples, though of course some of what it does is "not for public consumption" :)
<rlb>but there are plenty of bits that look just like what you might want to do.
<soda__hobart>yeah, i don't need an interactive shell, it would be nice to have eventually, but ATM, i'm just trying to be able to script the game event loop with guile, so that stuff can get loaded in at runtime
<rlb>well once you have the functions you care about "published" to guile, you may be able to just run guile and then (use-modules (my stuff)) and start calling your code. (Assuming a suitable LD_LIBRARY_PATH).
<rlb>as a very simple example wrt SCM_DEFINE and libguile:
<soda__hobart>hm, yeah, i still have a lot of research and reading to do, of course. my thinking was that i was going to do a GoF-style template method thing, where there are event callbacks, which in the game implementation are function pointers, and the functions themselves will be built out of various primitive functions and methods provided by the physics engine (Box 2D). so my idea was that a .scm file could basically be used to configure a
<soda__hobart>factory for producing those template methods.
<Aurora_iz_kosmos>weechat also has Guile code.
<soda__hobart>yeah, looking at source code of other projects has been very helpful
<rlb>I imagine you would, but keeping the "granularity" in mind can be helpful too -- i.e. not sure how much overhead there is right now for a scm->c crossing, but I assume it has some cost.
<soda__hobart>yeah, i was kinda thinking that each template object that wraps the defined (by scheme) function would only have to be initialized once, when the simulation/level thing loads.
<soda__hobart>like the scheme module is just supposed to be an interface to a factory method, so there would only be primitive data types. and if you have to do anything with a specific data type, just use a string key because they're all stored in a hash map anyways.
<rlb>Depending on what you mean, you can wrap your objects more directly/cheaply with foreign object types:
<rlb>s/can/may be able to/
<daviid>str1ngs: fwiw (not exactly your 'usage' but ...), I pushed a series of patches to G-Golf, so it is now possible to override GI imported def when necesssary/applicable, and now, this list-store (minimalist) example works as expected -
<daviid>it needs (g-golf) a second step (see the last pragraph of the last commit if interrested) so that functions and methods that use 'out arguments and need to be overridden, such as gtk-tree-model-get-value for example, would also work - which I hope to implement in one or few days at most (it's not exactly easy, hence may take more then a day, I'll see ...)
***apteryx_ is now known as apteryx
<str1ngs>daviid great thanks, will check this out.
***rekado_ is now known as rekado
***vup2 is now known as vup
<dsmith-work>{appropriate time} Greetings, Guilers
<dsmith-work>civodul: What C compiler are you using?
<civodul>GCC 7
<dsmith-work>Ok, I've got 8.3
<dsmith-work>civodul: What happens when you run guile with GUIlE_JIT_THRESHOLD=0
<civodul>on ARMv7?
<civodul>oh, it segfaults
<civodul>not every time, it seems
<dsmith-work>Bah! rr only is for intel.
<dsmith-work>Intermitent are the worst.
<civodul>now that i've done "ulimit -c unlimited" it no longer crashes :-/
<civodul>were you able to grab a stack trace?
<dsmith-work>I have a core
<civodul>cool, can you run gdb on it and send what you have to bug-guile?
<dsmith-work>So, I got Illegal instruction (SIGILL), not segfault.
<dsmith-work>And the bad code is my old friend
<dsmith-work>=> 0x73b144d8: 04 f0 1f e5 ; <UNDEFINED> instruction: 0xf004e51f
<dsmith-work>Which is
<dsmith-work>=> 0x73b144d8: 04 f0 1f e5 ldr pc, [pc, #-4] ; 0x73b144dc
<dsmith-work>in Arm mode
<dsmith-work>Which loads the PC from the next 4 bytes.
<dsmith-work>I'm going to clean everything. Some of my old testing code might have slipped in somehow.
<dsmith-work>Well fouey
<dsmith-work>I was getting some segfaults during the build, so I set GUIlE_JIT_THRESHOLD=-1
<dsmith-work>make check passed. (default threshold)
<dsmith-work>And now I can't get it to segfault or illegal instruction!
<dsmith-work>This is with that arm patch.
<dsmith-work>Ok, make check with the threshold =0 does segfault on some tests.
***drakonis1 is now known as drakonis