Rationale behind the module paths in definition of the module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I am wondering, what is the advantage of having both the definition of the module and the invocation depending on the module path? One would think that the path in invocation [i mean `(use-modules (a path to module))' macro invocation], would be enough. This way, I could differentiate between the modules residing under different paths, but having the same name. However, hard-wiring a path , e.g, `(define-module (hard-wired path to module))' prevents me from easily moving the module code around (for example, during `make install'). -BEGIN PGP SIGNATURE- Version: OpenPGP.js v0.5.1 Comment: http://openpgpjs.org wsBcBAEBCAAQBQJUrk67CRC6Cm7u/wM3RwAAZo4H/0/A05fbuGV/vIAaLMNr TzuOplLMFQ9eRJZqqwgizcwU/NB/V4IKNwN12Ge+WrgGDFRUkT3x4lqv5xW9 iUlVeC2Y/OWXvs8fzhDUGju7PY8kRYA+f8WkxpOApkJXE9GNfZkhNBeTcRrN xdUZH32ufbfoknbQxEELgaAJaXmSiaaIcQY+J6wOdwlGAdg4tvuWfuGrJhLi 0YZlNeYv9Rg2m8izQ0llnVH34fVBORp+yfR3kpCPqaOOdUbSnJdlS0sx1XU/ uXtUidwDJvmoVD6ZVusLUjqgsoHKHGqCGtCohK2M3OA8Z8cKLdfUdpn1xGKs uRFQFjpq2PrmhVCnR2O0LRU= =JPXp -END PGP SIGNATURE-
Re: concerns when integrating C++ code into guile?
> On 8 Jan 2015, at 01:18, Chris Vine wrote: > > On Wed, 7 Jan 2015 23:15:07 +0100 > Hans Aberg wrote: >> >>> On 7 Jan 2015, at 21:24, Ludovic Courtès wrote: >>> >>> If Scheme code calls C++ code that throws an exception, then the >>> stack will be unwound by libstdc++ and Guile’s ‘dynamic-wind’ >>> handlers and such will not run. >> >> If one tries to pass a C++ exception through Guile code, it will not >> catch in C++ code above it, I think. >> >>> That’s probably the main difficulty. >> >> There is a gcc option, but someone said it does not work well, >> perhaps because any intermediate library and package functions must >> be recompiled as well. > > It may or may not work well with respect to unwinding the stack, but > that misses one half of the point. It won't cause dynwind handlers to > run, whatever recompilation you do. If you want that, they must be converted somehow. >> Another variation might be compile C as C++, i.e. writing Guile in >> the common C/C++ subset. The Bison skeleton file had that before >> making a genuine C++ one, though it proved too difficult to maintain, >> and in addition, one does not get access to C++ features. >> >>> Likewise when C++ code calls Scheme code. >> >> For this, I made a smob and convert Guile errors to a C++ exception. >> Might be an overhead problem, though. > > It is not just a matter of converting guile exceptions to C++ > exceptions. The issue is that guile propagates its exceptions via long > jumps up the stack, or the equivalent thereof. These will not run > non-trivial destructors for C++ objects taken out of scope by the jump > (and according to the C++ standard, it causes undefined behaviour). Right. > This means that any exception handling has to be localized. > > That is not impossible. There is not that much libguile code needed to > run scheme extension code in a C++ program, if that is what you want to > do. I decided to not pass C++ (non-PODs) objects or exceptions through Guile code. The FAQ I mentioned also deals with how to convert objects to proper C before passing them from C++.
Re: concerns when integrating C++ code into guile?
> On 8 Jan 2015, at 02:00, Matt Wette wrote: > > > On Jan 7, 2015, at 6:45 AM, Hans Aberg wrote: > >> >>> On 7 Jan 2015, at 14:52, Matt Wette wrote: >>> >>> Python is written in C yet Qt has been integrated in to produce PyQt. I >>> wonder how that is done. I will take a look. >> >> If Python can be compiled as C++, that might be one way. > > PyQt does not recompile Python in C++ so there must be some way to do it w/o > recompiling python (=> guile). > > TeXmacs is another application that embeds C++ (Qt) w/ guile (1.8, though). You can pass C++ objects to C code, cf. [1], but longjmp() is incompatible with C++ exceptions. So before passing the C++ object, convert it to POD (plain old data) and catch any exceptions. 1. https://isocpp.org/wiki/faq/mixing-c-and-cpp
Re: Rationale behind the module paths in definition of the module
When a program contains: (use-modules (foo bar)) Guile searches for a file named foo/bar.scm (or foo/bar) in its search path. The search path is defined by the user, using the GUILE_LOAD_PATH environment variable etc. (info "(guile) Load Paths"). So the source file of that module, foo/bar.scm, can be moved around on the file system, as long as GUILE_LOAD_PATH is adjusted to list the directory that contains this file. Does that answer your question? Ludo’.
Re: Rationale behind the module paths in definition of the module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015-01-08 10:17, l...@gnu.org wrote: When a program contains: (use-modules (foo bar)) Guile searches for a file named foo/bar.scm (or foo/bar) in its search path. The search path is defined by the user, using the GUILE_LOAD_PATH environment variable etc. (info "(guile) Load Paths"). So the source file of that module, foo/bar.scm, can be moved around on the file system, as long as GUILE_LOAD_PATH is adjusted to list the directory that contains this file. Does that answer your question? Ludo’. Hi Ludo', Sure, I am aware of that. I am just curious about the decision to embed path info in the module file itself. Perhaps there is something obvious I am missing about its advantages. It did happen before :) . The way I see it, without too much in depth consideration, the following would be preferable, (my-define-module (x) ...) ;location agnostic -- the module code does not need to know where it is ... ... ... and then (my-use-modules (a b c x)) ;client module is the one that has to know about ;the location [residing in $(SOME_USER_SITE_DIR_ADDED_TO_LOAD_PATH)/a/b/c] Or, if you want, what is wrong with the CPP approach #include and no hardcoded location info in the header.h itself? All the best. A0 -BEGIN PGP SIGNATURE- Version: OpenPGP.js v0.5.1 Comment: http://openpgpjs.org wsBcBAEBCAAQBQJUrmYZCRC6Cm7u/wM3RwAAGiQH/A5Kh8qqaJY9x3paVgvx 7lqdfUK4stKA9pzjIdD6aCNeru9av+7l785tkkXb5hsSzE1krb3LZJ1JZM1B RSHMVnEOcqnJF/7WsP6Kf7gwBLGEte2Ndvxd+VramzB1V97oYsLfp+jZv2M8 QQKVitKcquh8uB11PAlpe5Pnl23GF+j5GBLmPNvyE2G8aGNJu+VCsb+JYMSB iJFxWyrfZq2rFKDYJ+1QLVqQEVR75hU0v0StVO5B4mGtfkPtsPGUIXgL4sNI H9Ptkpn7yg/5BYeUV5mkugXi1IJ/GM7+xbc1Gyr0cPP6+IN3w2JWjRHpBjVB Htvs59Z336CdYUOi/0tytBg= =tUBG -END PGP SIGNATURE-
Re: Rationale behind the module paths in definition of the module
Alpha Omega writes: > I am just curious about the decision to embed path info in the module > file itself. The '(foo bar baz)' is not path info, it's the name of the module. :-) The filesystem path mimics the components of the module name. Taylan
Re: Rationale behind the module paths in definition of the module
I find this surprising too. IMO, it's not useful to declare the file a module at all. Similarly having to "export" or "re-export" procedures and variables is not helpful. Having everything exported by default makes development easier, even if it can lead to name clash, imports can be renamed. Indeed It's a detail -- that aligns with how other languages work with modules. That's said, this can be worked out a project basis by defining some macros. It's not my top priority "bug", having better traceback would be much more helpful. I started to look at it without success yet. On Thu Jan 08 2015 at 12:48:46 PM Taylan Ulrich Bayırlı/Kammer < taylanbayi...@gmail.com> wrote: > Alpha Omega writes: > > > I am just curious about the decision to embed path info in the module > > file itself. > > The '(foo bar baz)' is not path info, it's the name of the module. :-) > > The filesystem path mimics the components of the module name. > > Taylan > >
Re: Rationale behind the module paths in definition of the module
Amirouche Boubekki writes: > I find this surprising too. IMO, it's not useful to declare the file a > module at all. You can have single-name-component modules '(foo)' in corresponding files foo.scm if you want stand-alone files/modules. > Similarly having to "export" or "re-export" procedures and variables > is not helpful. Having everything exported by default makes > development easier, even if it can lead to name clash, imports can be > renamed. Indeed It's a detail -- that aligns with how other languages > work with modules. That's said, this can be worked out a project basis > by defining some macros. That sounds like a bad idea. A top-level definition is not necessarily part of a public API. Even C has a solution to this! :-) Taylan
Re: concerns when integrating C++ code into guile?
On Jan 7, 2015, at 5:00 PM, Matt Wette wrote: > PyQt does not recompile Python in C++ so there must be some way to do it w/o > recompiling python (=> guile). I looked into PyQt a bit. Only recent versions of Qt have exceptions. The bulk of the code is exception free. Also, PyQt uses a tool called "sip" to generate wrappers for the C++ code to be integrated into Python.
