IRC channel logs
2017-06-25.log
back to list of logs
<daviid>paroneayea: heya! fwiw i personally really don't see the fact that guile-gnome still uses gtk 2.4 as a 'strong' limitation, and I would be curious to know what viod_pointer is looking for in terms of GUIwidgets and so... especially if you compare to tk, guile-gnome, in its state, is an order of mag superios, imo at least :) <void_pointer>As far as GUIwidgets, I don't need anything too complicated. Basic radio buttons and text boxes. Only complicated one is a table view widget, though I can imitate one with a rich text box <void_pointer>I did end up deciding to go with python, or well, more specifically Cython. I did some rough calculations and some tests and what I am trying to do turned out to be numerically intensive enough that straight up Python would definitely not do nor would Guile. So Cython looked to be a decent balance for what I needed on that end. <void_pointer>Though now that I have a Cython implementation of the computations that works well I could easily port to C or Fortran and then use some other language to wrap it if I choose. <void_pointer>Would be kind of fun to port that part to Fortran and then wrap it in Guile. <daviid>void_pointer: yu definitely want to use guile-gnome then, imo <daviid>void_pointer: you can design the interface i glade by the way <void_pointer>That is one of the things about GTK+ that I do like. Haven't used Glade in nearly a decade <daviid>void_pointer: you need an old version of glade, 3.8.5, but grab the tarball it compiles like a charm <daviid>you may look at GNU Foliot for a 'real' example (the code needs love, but you'll get the idea...) nd ask here I'll be happy to help <void_pointer>Not sure if I will since I got so much already done. Just need add the GUI and the GUI logic since the core underneath it is already there <daviid>void_pointer: oh, I thought you were starting and lookig to be able to do the all thing in guile ... <void_pointer>Was thinking about it. Had some spare time so decided to see how expensive the computations were going to be and realized that whatever was underneath needed nearly C/C++/Fortran speed <void_pointer>And might still port over to a Guile + C/C++/Fortran version at some later time <void_pointer>Learning these things here will help for later. I will try to remember GNU Foliot as an example to look at <androclus>Hey, all. This is probably obvious. But if I wanted to calculate pi to 100 places via (* 4 (atan 1)), I would get an answer, but it is only out to 15 decimal places. Is it possible to tell guile I want more decimal places than that? I have been scouring the Numbers section of the manual (https://www.gnu.org/software/guile/manual/guile.html#Numbers) but I don't see anything. Must be blind. <magnicida>got a question: is there an easy way to export in a module all functions defined in an extension? <magnicida>some of my extension functions are generated (via C++ templates) and it would be tedious to list them all in the .scm module <magnicida>maybe I should use scm_c_define module and scm_c_export in the extension code <magnicida>but then how should I make this module visible in the Scheme world (i.e what should I put in the .scm file that loads the extension)? <void_pointer>androclus: I checked Guile's source code and it looks like GMP is only used for bigints and rationals (I think on this one), but not multi-precision floating point. Unless there is another atan defined somewhere in a way grep couldn't find, it is using libc atan for doubles. So, there is no builtin way to get pi to 100 digits. Best bet would be to use GMP directly, I think. <void_pointer>androclus: or use a different way to get the digits of pi that you need <void_pointer>magnicida: one non-elegant hack way to do it would be have the scheme code just open the extension code each time and parse it to find what to export and then export everything that finds. An improvement would be to do something similar with a scheme in the building process (after the C/C++ is compiled) and then store it in the target scheme file that will be the final module. Essentially, build part of the scheme source file for <magnicida>ok, I'll try... I'm having other problems, i think related to having multiple guile installations <void_pointer>magnicida: I would suggest waiting around for better answers than I provided. I am sure there must be a better way of doing it. I am a Guile newbie. What I suggested are "if all else fails" methods to resort to in desperation <void_pointer>magnicida: on the off chance there is no better way (unlikely, but who knows) <magnicida>actually my other problem is very strange, with guile 2.2 I get ERROR: In procedure dynamic-link: file: "..." message: "file not found" <magnicida>but with guile 2.0 it works (but then fails because I am using the foreign object api which is not available there) <magnicida>I installed guile 2.2 via guix, but I am running Debian <magnicida>I think I have all the PATH=... LD_LIBRARY_PATH=... etc in place for Guix to work <void_pointer>Other than LD_LIBRARY_PATH issues, I don't know where to start (haven't gotten guix to work yet on my system) <void_pointer>Hmm, just something to try. What happens if you put a symlink to the library in the same directory as you are running Guile, or the same directory that your scheme module is in, or the same directory that the Guile executable resides in? <void_pointer>Or give the absolute path to the library to dynamic-link <void_pointer>Not good solutions, but they might help you figure out the problem <magnicida>also the library is actually in the same directory than the module <magnicida>I tried both with full path and otherwise, with .so at the end and without it <magnicida>weird that it works in guile2.0 but not in 2.2 <magnicida>just double checked and also it seems to be picking the right 2.2 stuff at build time <spk121>magnicida: when you have mysterious "file not found" errors, it is often because one shared object can't find another shared object. On Linux, there is an environment varioable that you can set "LD_DEBUG=all" which make a huge debug output that will tell you the source of your dynamic linking problems. <magnicida>I did not have libstdc++ installed in my guix profile <void_pointer>Didn't know that there was such a thing as that. I will surely find that useful in the future <magnicida>I am using the new foreign-object API as suggested by the docs <magnicida>but it seems to me that with this API I need to make two allocations whenever I build a value (one for the data, other for the foreign-object wrapper) <magnicida>something that maybe didn't happen with the SMOB? <magnicida>are there any performance considerations when considering the smob vs the foreign-object api? <amz3>I was redirected to foreign object API (also called dynamic ffi) from SMOB API without rational AFAIR <amz3>magnicida: what is your previous question regarding export C++ objects via the SMOB API, you do not require to list the exported functions in scheme they will be imported and visible in scheme as long as you link to the C shared library that export the needed function <magnicida>amz3: thanks, yeah I was just trying that (calling scm_export from the extension) and that seems to be enough to export the functions from the module loading the extension <magnicida>I am still curious about the performance implications of foreign-objects vs smob... I am using foreign objects but my api is kinda performance sensitive and immutable (every methods returns a new object) so I'd like to save allocations <magnicida>and other potential overheads (it also says that foreign types are GOOPS classes, which seems overkill for my use-case) <magnicida>but it also says SMOBs are to be deprecated, so... <amz3>magnicida: is your C/C++ publicly visible? <amz3>yeah SMOB are deprecated that's what I understood <amz3>then, if it official it's prolly because performance wise it has little impact? <magnicida>to bring clojure-like persistent vectors, but with log(n) concatenation and other nicetise <magnicida>yeah, I guess that's it, I was curious if someone could give some details <amz3>fwiw magnicida, the doc look good <amz3>paroneayea: how is related 8sync with scheme terminte and erlang? <amz3>oh! erlang has a database built in <jlicht>catonano: looking at how you approached guile-freexl helped me get my project started! Thanks for the pointers <amz3>janneke: congrats for the release, the release message is very readable <catonano>jlicht: whhere is yor project ? I want to take a lookk at it ! <jlicht>catonano: First push will be tonight. No working code yet, first creating all the tests ;-)