<alextee[m]>im reading guile's website and it says: In addition to Scheme, Guile includes compiler front-ends for ECMAScript <alextee[m]>and does this mean that if my C code supports running Guile scheme I can also pass it a piece of javascript code and it will run as well? <alextee[m]>also "support is underway for Lua" this sounds great too but same question <alextee[m]>my code basically does scm_call_0() on a function returned by scm_c_lookup() <alextee[m]>so is it like scheme so that if you define a function in ECMAscript like "myfunction" then scm_c_lookup() on "myfunction" and scm_call_0() will work? <daviid>alextee[m]: no idea, others will shime in hopefully ... <rlb>alextee[m]: I'm not sure how easy it'll be to do whatever specific thing you have in mind, but yes, guile does support different dialects, including elisp and "javascript", though I suspect the dialects vary in features/completenes. In case you hadn't seen, you can switch languages at the repl:. <rlb>scheme@(guile-user)> ,L ecmascript <rlb>Happy hacking with ECMAScript! To switch back, type `,L scheme'. <rlb>ecmascript@(guile-user)> <rlb>ecmascript@(guile-user)> 2 + 2; <rlb>Of course integrating that with whatever else you're doing may require more. <alextee[m]>well I'm mostly interested in extensibility for my app using user scripts <rlb>I'm familiar with some of it since I've been working on a clj dialect, but I don't know much about the ecmascript support. <alextee[m]>i already support scripts written in scheme and it seems to work pretty well <rlb>Right, that should "just work". <alextee[m]>but is the scm_call_*() api targeted at only scheme? or is it supposed to work with user scripts in other languages like ECMAscript? <rlb>Not sure for js -- for my dialect, it'll work perfectly. <rlb>i.e. the way I arranged things, a clojure namespace *is* a guile module. <alextee[m]>yeah I'd assume if this worked you'd have to write the code in a specific way to mimic modules and stuff <rlb>And there's no difference atm between a clojure defined function and a scheme defined function in terms of binding, invocation, etc. They just do different things when called. <alextee[m]>would be nice to have example scripts somewhere in various languages <rlb>There might be, just don't know too much about the js side. <rlb>But you could also probably use the "language tower" functions, but I'll have to go look that up for you, and might not get to it until later, but feel free to ping me if I don't get back to you in a day or so (assuming someone else doesn't). <rlb>Oh, and if the js side just binds the js functions in a guile module, then the call functions might work fine, plus or minus getting the right data types for args (if any of those are special). <rlb>(after you get the fn ref from the right module) <rlb>But yes, completely agree we could do with more elaborate documentation on that front. <alextee[m]>my idea of guile (at least from the website and GNU pushing it as an extensions language) is that it's main purpose is for extending programs so yeah it would make sense to have some more docs on that front <rlb>And note that guile can compile not just to a file (for future execution), but also to an actual "live" function, etc. that you can call. I believe that's mentioned in the info pages somewhere too. <rlb>alextee[m]: yeah, as a simple example, this works: <rlb> scheme@(guile-user)> (use-modules ((language ecmascript parse) #:select (read-ecmascript))) <rlb> scheme@(guile-user)> (compile (call-with-input-string "2 + 3;" read-ecmascript) #:from 'ecmascript #:to 'value) <rlb>Basically just a distilled version of what ecmascript.test is doing, but perhaps gives you a general idea. <alextee[m]>ah, maybe i could just wrap scripts written in ecmascript in a guile script that does that with the string.. <rlb>...worst case, you could perhaps do a read-compile-eval loop on the input file, but there might be a better way. <rlb>rather read/compile/call or whatever. <rlb>But assuming js supports it (and it may), you could also compile to files first (timestamp based or wahtever as scheme and the clj dialect do), and then load the compiled code. That'll be more efficient for static files of course, if it suits. <rlb>The real work happens, after the timmestamp checking, in "compile-it". <alextee[m]>interesting, i'll dig around a bit more, thanks! <apteryx>that change was catering to Guix, which is more demanding in terms of Guile path installation customization: it uses a versioned site dir (e.g.: share/guile/site/3.0) that is non-standard <apteryx>with guile-lib, I don't currently have a mean to configure it for Guix without resorting to hacking the build system files; out of the box it installs the souces to the non-versioned $datadir/guile-lib; when using --with-guile-site=yes it tries to install to Guile's own location, which fails on Guix as packages are individually prefixed and not writable <apteryx>anyway, I'm happy with the release, but I thought I'd try to explain the rationale behind the patch 6 linked above <daviid>apteryx: did you read the commit message and comment about the changes introduced in 0.2.6? <apteryx>Yes I've done so before writing the above; perhaps I've missed an important bit? <daviid>apteryx: hum, the reason, I was hoping, for the changes i introduced in 0.2.6, based on a few valid users claims, fix the situation, which your patch would bring us back to, which for me, is a severe gregression <apteryx>the patch didn't change the default behavior of the configure script but provided more knobs to tweak, or at least that was the idea <daviid>apteryx: the problem is, in the absence of any configure option, that the package isntalls itself following the gnu coding standard, that is outside guile's tree and in $prefix blabla, all this is weel explained in the commit, the release and in the <apteryx>I agree that the default when not specifying any configure flag should following the GNU standards, but unless I'm missing something the patch was not touching that default <daviid>apteryx: there is no need to patch guile-lib wrt to all this <daviid>it is perfect as it is - the only discussion we may have is about the versioninng or none versioning location when the option is given, i think any guile scheme code that is agnostic must be installed in the guile's global site dir, hence what i did <apteryx>OK; I see flexibility as a win, but perhaps the added complexity was not worth it if Guix is the only user, this I can understand. <apteryx>We'll have to keep a simple patch in Guix, that's all. <daviid>apteryx: let's agree to disagree, and hack on more important things, but thanks for the patch - on the form though i thought it wuld have been nice if you did talk to me or us here, it would also have saved a of your pressious time ... <apteryx>sure, I can check here before writing something new in the future, to gage the interest/pertinence of it. <daviid>apteryx: tx, talk to you later... ***apteryx is now known as Guest6344
***apteryx_ is now known as apteryx
<manumanumanu>sneek: later tell davexunit I have been working on a wrapper around srfi-64 that implements a large chunk of (chibi test)... ***DadeBonetti1 is now known as DadeBonetti
<apteryx>daviid: I've made one last check with a fresh mind, to make ensure what I said yesterday is accurate, and it seems to be: the default install directory is unchanged with patch 6: https://paste.debian.net/1190139/; so even withouth the new switches, at least you may want to drop the m4/guile-ext.m4 file, which appears redundant with guile.m4. <mwette>apteryx: unpack, cd examples; source env.sh; then start guile; ,L nx-javascript or ,L nx-mlang or ,L nx-tcl ; <yoctocell>Hi, has anyone had exprience with guile-wm? I looks like a cool project but doesn't seem to be maintained anymore :( <mwette>yoctocell: yea looks cool, but also requires xcb, which looks cool too <mwette>and guile-xcb has xcb/xml/sample/tiny-wm.scm which is a sample WM <mwette>no, just took a look inspired by you mentioning it <spk121>janneke: I'm about to pull these patches, and I wonder if the mingw patch might be simpler if scm_t_inum -> intptr_t <spk121>although I guess a lot of these functions are SCM_API, so that would be a theoretical, (but not real) API break <spk121>I take that back. You didn't change any SCM_API functions, so that makes it simpler <daviid>apteryx: i won't remove guile-ext.m4, which holds aditional defs that are not in guile.m4 ... <gurjeet>^^ I'm essentially trying to build GnuTLS _with_ Guile bindings, but the build command fails. <spk121>gurjeet: this is a known problem with 3.0.5, and there is a patch for it in the soon-to-be-released 3.0.6 <mwette>gurjeet: I had issues w/ gnutls --enable-guile on macos. I ended up needing to first build/install w/o --enable-guile then redo w/ --enable-guile. I think when libgnutls.so is in the build dir the guile module does not see it. <gurjeet>spk121, the latest in nixpkgs is 2.2, I believe. Even if it is some other version, I am explicitly asking for 2.2 to be used in my patch to Nixpkgs. <spk121>gurjeet: oh, sorry. I've got no idea then <gurjeet>mwette, thanks for the hint. Given that nix-env command tries to build in a clean environment, so I don't know how to make the second invocation of nix-env command to use the output of the first invocation. <apteryx>mwette: thank you for the multiple lang examples! <mwette>gurjeet: Can you maybe update appropriate env vars (e.g., LD_LIBRARY_PATH) to point to where the file is built prior to install? <gurjeet>spk121, sorry I misunderstood your message. I'm trying to use _Guile_ version 2.2. The GnuTLS version being built is 3.6.15. <gurjeet>Did you mean to say 3.0.5 has a known issue. Did you mean to say 3.5? Which latest version of GnuTLS is known to produce Guile bindings? I'll try to use that specific version of GnuTLS. <apteryx>daviid: guile-ext.m4 provides these two macros: GUILE_GLOBAL_SITE_DIR and GUILE_SITE_CCACHE_DIR; the first one can be replaced by GUILE_SITE_DIR from guile.m4, and the second one by GUILE_SITE_CCACHE from guile.m4. Seems we're covered? <apteryx>the only difference is in how they are implemented; guile-ext.m4 queries guile itself, while guile.m4 uses pkg-config <lispmacs>hi, I was looking for an easy way to plot 3d plots of complex functions of time <lispmacs>I was wondering if anybody had any ideas with guile or some other tool <lispmacs>I was checking with the maxima guys in another channel <lispmacs>like f(t) = e^(st) where s is a complex number <rlb>lispmacs: no idea specifically, but of course there's gnuplot, matplotlib, and the whole python/jupiter notebook world. <rlb>...wrt to "jupiter" that might be https://jupyter.org though I think it may have become somewhat of a more generic term. *wingo grumbles that gitlab seems to prohibit icecat users <heloaoba1>is there an equivalent in scheme/guile to python's os.path.join for safely joining path components? <wingo>apparently installing a user-agent-switching extension and pretending to be firefox 82 or 83 rather than 78 is enough to get by <janneke>spk121: if intptr_t makes it simpler, then by all means <wingo>janneke: do you mind if i review your patch on gitlab? <janneke>wingo: i'm not sure how that works, i think i would prefer emacs/email; i'm a bit clumsy with webby clicky things; but please do what works for you! <janneke>wingo: also, please feel free to "just change things" as you like, if that makes it easier for us <janneke>i'm primarily happy that i found a way that works <wingo>ok. well i guess a first-order feedback would be that when converting SCM inums to C integers, intptr_t is the good type i think <wingo>civodul: does that sound ok with you? <janneke>sure, i doubted between long long and intptr_t <janneke>it seems sometimes "long" means: an int where a void* (or int*) fits, and on other times it seems to mean: the largest integer type (something like: long long) <janneke>on the one hand, the extra types do not help, on the other hand i liked having a signed and unsigned pair <janneke>(unsigned long long) => scm_t_unum, (long long) => scm_t_inum <janneke>so yuck in a way to scm_t_inum,/unum; nice in an other way... yes, a mess <janneke>and then we also have scm_t_bits and scm_t_signed_bits! <wingo>i guess i am generally hoping that stdint.h types can satisfy our needs. it's hard enough doing C integers without introducing new types whose definition isn't obvious <janneke>so, we go for scm_t_inum => intptr_t, and scm_t_unum => uintptr_t <civodul>wingo: fixnums to intptr_t sounds good to me <wingo>janneke: sounds like a plan! <janneke>great, i'll do that first and see how that goes! <janneke>i'm kind of happy that we don't have to introduce new types, feels a lot better if that works *janneke wonders whether that will also work for mini-gmp, intptr_t and uintptr_t; guess i'll try to do it there too <pkill9>dustyweb: do you have an example of how to organise pages into categories and/or tags in haunt? <daviid>apteryx: there is no need to change anything there, and certainly not removing guile-ext.m4, i told you yesterday, please move on to something else, tx <janneke>wingo, spk121: updated patch, sent v2 to guile-devel <spk121>janneke: of the patches, the only one I don't think could be pushed is "Fix 'absolute-file-name?' and others for cross-build" There some sort of order dependency. If I modify boot-9 after and rebuild, it fails. The rest could go, after pulling out _mingw_debug_p. I'm so glad you took the time to work on this sad errand. <spk121>Building on MinGW is slow, so testing the patches took forever... <janneke>spk121: yes, i just found that "Fix 'absolute-file-name?' " is broken, at least partially <janneke>i'm pretty sure it worked it the mingw cross build, but i could have fooled myself there... <janneke>maybe it only breaks while BOOTSTRAP'ping? <janneke>before, i had this "HACK boot-9.scm: hard-code absolute-file-name? ..."; i was so glad i thought i fixed it properly...oh well :) <spk121>janneke: it would not surprise me if it were different in bootstrap <janneke>yeah, i only tested it out-of-band, in a foo.scm file <spk121>But let's get the rest of patches is master. I'll try it all again after dinner.