<daviid>clutter_image_set_data is wrapped! this is an essential step for guile-clutter because it's the new [and only] way of loading and playing with textures. ***DeeEff_ is now known as DeeEff
<dat_eye_socket>Don't you sometimes feel that rms only likes lisp because of its dynamic typing. <dat_eye_socket>A lot of the arguments he eems to put forth in support of it seems to be mostly featured in about any language with dynamic typing. ***dat_eye_socket is now known as phallic_elbegast
<wingo>i finally got done explaining the n^2 thing *wingo needs to fix 32-bit on master, humm <phallic_elbegast>wingo, but you never got done implementing a silent option that doesn't give you the recompile message. =( <civodul>phallic_elbegast: you know, we're all equal in that respect, so everyone can come up with a patch :-) <civodul>wingo has been busy with other things, for instance <phallic_elbegast>Yeah but that would require me to actually look through the code and stuff. =( <civodul>eventually one of us will get there, hopefully <civodul>there's been a preliminary patch for that <phallic_elbegast>I hear it is very requaested, probably because I at first could not believe there was no flag, it seems kind of obvious. <phallic_elbegast>I often put a --donothing command line argument in some of my guile shell scripts just to force it to compile once if I need it to not have that output <civodul>i typically pre-compile everything, and use --no-auto-compile for the startup script (which must be small), or 'load-compiled' <phallic_elbegast>pre-compiling everything for a shell script kind of defeats the idea of a shell script, in that case I can just compie I guess which nets me an extra file. <phallic_elbegast>I have this ~/.scripts folder where I put them and added it to the $PATH <phallic_elbegast>THat does simple things like make a screenshot or checks email or something like that <wingo>dsmith-work: hopefully fixed that 32-bit compile error ***phallic_elbegast is now known as phallicAndPaedan
***phallicAndPaedan is now known as phallic_elbegast
<wingo>did you see (language cps intset) ijp <wingo>i thought you might like it, though who knows ;) <ijp>I have not seen it yet <ArneBab>I’ve been watching my system with guile-2.0.11 installed and I think the incompatibility with guile-1.8 is creating real problems. <ArneBab>lilipond, gnucash and gtk-gnutella all failed to build since I installed guile-2.0.11, and that could become a big turnoff for potential new users. <ArneBab>“I use guile. Now they updated and my program does not work anymore” ← this is a story we definitely don’t want to see spreading. <ArneBab>advertising the use as shared library and then breaking the API (actually changing the language) is very, very dangerous. <davexunit>ArneBab: when major API changes were made, the major version number was bumped to 2. <ArneBab>My personal thought is that it needs at least one of two measures: (1) providing a simple way to install guile 1.x and guile 2.x side-by-side without interfering with each other, or (2) creating a guile-1.9 which is just like guile-1.8.8, but with big deprecation warnings, so developers can change their code to run under both versions. <davexunit>guile 2.0's API has been stable. These developers are *years* behind the curve. <ArneBab>(and adding incompatibility warnings to 2.x that certain features won’t work in 1.x) <ArneBab>davexunit: that does not help all those people who want to use these now broken programs. I witnessed the python-2 to python-3 transition and it wasn’t pretty (it still isn’t). <davexunit>guile 1.8 can be installed along side guile 2.x <ArneBab>Essentially those programs who use guile 1.x are the early adopters, and alienating them is the worst guile can do. <ArneBab>davexunit: is that the default (separate installation directories)? <civodul>ArneBab: the LilyPond and i think Gnucash people have been working on upgrading <ArneBab>… hm, my system says guile/2.0 ← why do the 1.x programs try to use that? <davexunit>I think we need to help those upgrading as best we can. <davexunit>but I don't think we should hold back progress. <davexunit>it doesn't help that Debian ships very outdated guile versions. <ArneBab>one of the ways to do that would be deprecation warnings in 1.x <ArneBab>(so developers can code for 1.8 and 2.0 at the same time) <ArneBab>that does not sound nice, but this is what happened for Python after the Python developers fought this dual-coding tooth-and-nail <ArneBab>civodul: so guile 2.x warns when I use something which does not work in guile 1.8? <civodul>but 1.8 has been unmaintained for some years <ArneBab>civodul: as long as it’s in debian stable, it needs to be addressed, I think… (but then, I’m not the one who knows which code would be necessary for that nor the one who can do it…) <ArneBab>civodul: the core of the problem here is that guile is used as shared library, so programs use what the system provides (and the blame naturally goes to guile in the end) <ArneBab>(because the blame always goes to the one who changed something) <Fulax>ArneBab: technically having both versions installed is possible. I did the slotting stuff for Gentoo in the lisp overlay <ArneBab>Fulax: so I could actually install both? (I use Gentoo) <Fulax>the only file conflict is guile.m4 <Fulax>ArneBab: you can, but it creates more problems :) building guile-dependent application is a pain, as they suppose the 'guile' binary is 1.8 <dsmith-work>I think the limitation is you can only have one *-dev package installed. <ArneBab>Fulax: could we just make the guile-2.x binary be called guile2? <dsmith-work>So you can have parallel .so's, but not parallel headers. <Fulax>ArneBab: actually the ebuild in the lisp-overlay does that, it use ./configure's --program-suffix option to append -2.0 or -1.8 <Fulax>and I wrote an eselect module <Fulax>ArneBab: I haven't touch that stuff for a year or two, so i don't know how it works currently *ArneBab will install guile 1.8 again to see whether gtk-gnutella 1.0.1 works again then <Fulax>(Since my last gentoo box died)