<buenouanq>what is the benefit in using something like #\\" vs "\\"" ? <lloda>daviid: I did pull your patch but the problem was rather my path, so I cannot tell you if the patch solved anything on my side. It did no harm at least. Re: guile-cairo sorry that address is for the unsolved bugs. Re: doc thanks, I'll keep poking now and then. Re: release I don't know how to make a release but I'll look into that. <lloda>wingo: did you see my question about the doc system? <wingo>i did but i don't have anything paged into my memory :) <lloda>so there are hardcoded paths in the Makefile.am <lloda>just can't run it, not very specific <lloda>like this one in doc/Makefile.am <lloda>cairo_docbook_xml_wildcard = ~/src/gnome2/cairo/doc/public/xml/cairo*.xml <lloda>but daviid says it's the same system in guile-gnome, so I'll look there <roelj>Is there a way to set breakpoints and run code until that breakpoint for Guile? I'm using Emacs.. <wingo>breakpoints were broken early in 2.2 fwiw; fixed now i think <roelj>Thanks. I don't know what a recursive REPL is, but I guess I can find that in the manual as well. ***guile-guest6 is now known as rcm
<daviid>lloda: I can 'guide' you make your first guile-cairo release, nothing difficult, just a matter of time really (and doing the first, you'll build your own 'release todo/steps list ...'; I order to 'save' distro and guile-gnome[clutter] users, I uploaded a prerelease, in 2016, here http://download.savannah.nongnu.org/releases/grip/guile-cairo/ (just for info, there is no usefull info there for you) <daviid>lloda: I think that guile-cairo binds 1.10, as it is, not sure what your plans are, but it would be nice to try to catch and reach the latest, 1.15, which does not sounds like too much work <daviid>guilers, any has an example of an autotooled projects which has a default install location (other then /usr/local) and/but properly handles the --prefix arg? civodul maybe? <OrangeShark>daviid: so to be able to have `./configure --prefix=/usr/` and it installs everything in in /usr/? <OrangeShark>oh, you don't want the default to be /usr/local? but still obey the prefix arg <spk121>daviid: re autotools. I've tried various ways of installing. guile-ncurses installs things in SITE_DIR etc by default and requires a flag <spk121>to install in --prefix directories. <spk121>guile-curl installs its files in the --prefix directories, but, gives advice at the end of configure of what flags would actually make it install in SITE_DIR <spk121>That seems to be uncontroversial, but, anyone that tries ./configure && make && make install gets a non-working system <spk121>until they set a lot of environment variables <daviid>spk121: what you do for guile-ncurses is what I need: if no --prefix, source code goes in GUILE_GLOBAL_SITE_DIR (I wrote a macro extension to get that instead of having to run guile -c ...) and compiled modules in GUILE_SITE_CCACHE_DIR, if the user pass --prefix, then it goes in $prefix/share/guile/site and $prefix/lib/guile/@VERSION@/site-ccache <daviid>actually the source code goes in $prefix/share/guile/site if compatible with all guile version >= 2.0.14, othrwise (it's per project to decide oof course) it goes in $prefix/share/guile/site/@VERSION@ <daviid>doc goes in $prefix/share/doc/<project-name> <daviid>lloda: civodul could you confirm that this is the right thing to do for guile-lib, thanks <daviid>spk121: I wonder why it was unpopular? it is exactly what I would want as a user afaic <daviid>have to go afk for a few hours now, bbl <daviid>local hospital called me to give blood, a apatient needs my type ... <taylan>what's the best way in guile to determine what CPU architecture one is running on? <civodul>sneek: later tell daviid it's share/guile/site/@GUILE_EFFECTIVE_VERSION@ <civodul>taylan: there's %host-type, and there's (system base target) <civodul>but are you sure you want to use that? :-) <taylan>what should I be using to decide which ABI the platform is using? <taylan>civodul: this is for bytestructures in case it wasn't obvious ;-) <taylan>working on ARM now. can't believe I just forgot ARM. <civodul>there's usually a "processor supplement" of the SysV ABI for each CPU <civodul>well actually the one we use is called "gnueabihf" <civodul>there's an ARMv7 ABI and an ARMv8 (aarch64) ABI i suppose <taylan>it seems that I need to check whether (target-cpu) begins with "arm" or with "aarch64", based on which I'll use the alignments specified in the 32-bit or 64-bit ABIs linked to in the page above... <civodul>yes, but i'm not sure you need that information <civodul>for instance, the bit about aggreates assuming the alignment of their most strictly aligned component may be in the general SysV ABI document <civodul>were you able to compare the offsets and alignments with those produced by gcc? <civodul>i think that'd be a good starting point, finding out where they differ <taylan>civodul: I need to know the alignment of scalar types, which differ across i386, amd64, arm and aarch64. the offset and size calculation of structs is indeed always the same.