IRC channel logs


back to list of logs

<lloda-home>sirkmatija1: (ice-9 arrays) wasn't an installed module before 2.2.3. If you need (array-copy) you can define it yourself like in here (search);a=blob;f=module/ice-9/arrays.scm
<daviid>sneek: later tell djcb here is another msg I wrote, easier for you to read and understand ( I think) then the previous link I posted:
<sneek>Got it.
<buenouanq>what is the benefit in using something like #\\" vs "\\"" ?
<rain1>well they are not the same
<rain1>char vs string
<buenouanq>oh ok, duh
<buenouanq>silly me
<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: ah I see doc/release
<lloda>wingo: did you see my question about the doc system?
<lloda>doc generation system
<wingo>i did but i don't have anything paged into my memory :)
<wingo>heh, no prob
<lloda>so there are hardcoded paths in the
<lloda>just can't run it, not very specific
<lloda>like this one in doc/
<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..
<turlando>roelj apparently geiser can't do that
<wingo>breakpoints were broken early in 2.2 fwiw; fixed now i think
<wingo>the repl interface is
<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 (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
<OrangeShark> this can change the default prefix location
<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>That was rather unpopular
<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>OrangeShark: ^^
<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
<Labu>Hello all
<Labu>Hi daviid
<daviid>spk121: I wonder why it was unpopular? it is exactly what I would want as a user afaic
<daviid>hi Labu
<daviid>have to go afk for a few hours now, bbl
<daviid>local hospital called me to give blood, a apatient needs my type ...
<daviid>need to run
<stis>heya guilers!
<amz3>hej stis
<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>heya taylan
<taylan>hidy :)
<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>so i suppose there's one for ARM
<civodul>well actually the one we use is called "gnueabihf"
<civodul>lemme see
<taylan>the "ARM Procedure Call Standard" (APCS) seem to define the type alignments on 32 and 64-bit ARM: not sure if they're supposed to be same on all 32-bit and 64-bit ARMs...
<civodul>i ended up on the same URL
<civodul>there's an ARMv7 ABI and an ARMv8 (aarch64) ABI i suppose
<taylan>v7 is 32-bit?
<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...
<taylan>does that sound about right?
<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.
<civodul>ah, right