IRC channel logs
2023-03-24.log
back to list of logs
<old>gtz_: these are REPL commands <gtz_>old, it says they can be used outside the REPL, too <gtz_>old, I also tried using them in the REPL and I get the same error <old>try: > ,trace (map 1+ (iota 10)) <gtz_>okay old okay I forgot the comma... <old>for calling trace as a function, (use-modules (ice-9 time)) <old>hmm trace is not in it <gtz_>old, yeah only time is in there <gtz_>old, so the docs are wrong <gtz_>old, do you know where trace and profile are? <old>(use-modules (system vm trace)) <old>(call-with-trace (lambda () (map 1+ (iota 10)))) <old>(use-modules (statprof)) <acdw>guilers! can someone explain to me the %variable naming convention? i've seen it in FFI, records, and like, global variables I think? <acdw>i also need to learn more about records <acdw>can i compile a guile project to an executable? <acdw>`guild compile hello.scm -o hello` doesn't let me do ./hello <acdw>i'm guessing it'd be somewhat complicated to implement? or it'd already be implemented <old>there've several discussion on the subject here. Mainly related to game development <old>I don't think it would be difficult. Statically link everything, including the compiled Scheme (.go) into a single binary and resolve the modules in itself should be doable <acdw>i'm guessing that's why CHICKEN compiles to C? to piggy-back on C's compilation? <dthompson>particularly "linking multiple modules together" and "linking a single executable" <dthompson>a statically linked guile executable + those 2 things would yield a single executable. most real-world guile applications require the FFI, though, so usually you'd still need to distribute more than a single executable anyway. <acdw>this is all stuff i know very little about <dthompson>note that this is all without native compilation. I probably shouldn't have mentioned it earlier <dthompson>because it's kind of orthogonal to single executable <dthompson>a single executable with natively compiled code sure would be great, though <mwette>step forward would be to have multiple .go's bound in a single .elf <dthompson>it would be really nice to perform whole program compilation on such a thing <dthompson>so that all unused code is removed. that would make for a much smaller executable. <dthompson>the hack I currently do is to a coarse form of tree-shaking that removes all modules that are unused by the program. <dthompson>that trick made a huge difference in total download size. <mwnaylor>I built guile 2.2.7. emacs geiser requires at least v2.2.x. After creating and installing the package, this is the error I got attempting to start guile: Throw to key misc-error with args ("primitive-load-path" "Unable to find file ~S in load path" ("ice-9/boot-9") #f) <mwnaylor>Running Slackware 14.2. Default version of guile is 2.0.11. No higher version available from official Slackware binary repositories. <mwette>trumped by redhat8, which has v 2.0.14 <mwette>can you run your guile at the command line w/o that error? <mwnaylor>No, that is the error I copied from the command line. <mwnaylor>I may have messed up the --prefix options. I'm a bit rusty creating packages manually for Slackware. <dsmith>run the guile with `strace -efile` and see where it is and is not looking.. <mwette>download guile-tar.gz file; ./configure --prefix=/path/to/instdir; make ; sudo make install <mwnaylor>I think I need to examine the makefile options more closely. In order to build the packed, the binaries were not installed in the final destination; package built in a temporary directory. Final destination by installpkg. <ArneBab>Will Guile on wasm also give us strict ecmascript on wasm? <mwnaylor>Pulled slackbuild from slackbuilds.org. I think I needed to set a DESTDIR to have binaries installed in my package building directory. <dthompson>ArneBab: as in the ecmascript as currently implemented in guile? since guile on wasm will be compiling cps to wasm, any languages that compiles to cps will compile to wasm. it may not compile if it relies on something that doesn't work on the wasm target. <dthompson>for example, if you have a scheme program that uses the POSIX API, that won't be a valid program for compiling to wasm <mwette>ArneBab: emacscript encodes ints into floating point format (as NaNs), right?, and code points are 16 bits, vs guiles 8 or 32 bit <mwette>so emacsscript in GUile is not 100% emacscript, and I wonder about some of the other things (like lexical scoping, switch statement semantics, etc) <singpolyma>I'm not sure I would say it's not 100% -- not the whole stdlib is there by a long shot, but I think the language is basically right? <drakonis>will the r7rs implementation be a complete one? <drakonis>before tackling the guile specific features? <drakonis>the recent batch of srfis are quite nice and contain supersets of features guile has <dthompson>drakonis: the goal is to implement r7rs-small <drakonis>because a significant chunk of srfis target it at this point and r7rs-large will built on it <drakonis>so it should be much easier to get there <cow_2001>when will we finally have a guile on the web? itching. <ArneBab>mwnaylor: ecmascript I’m not sure, but it would just be great fun :-) <dthompson>cow_2001: in less than 6 months guile should run in web browsers in some basic capacity <cow_2001>oh, someone mentioned wasm just above me <mwnaylor>ArneBab: had to kill my erc session, missed the ecmascript thread. <lilyp>speaking of which, this might be heresy to some, but do we *really* need a garbage collector in scheme? <mwette>mwnaylor: check the logs on the web <lilyp>I think most forms (cons, car, cdr, ...) could be compiler-checked or refcounted most of the time <lilyp>obviously with cons there's the big issue of cycle detection, but let's just thing regular lists for now <mwnaylor>mwette: thanks. I mostly hang out on #emacs, which discourages logging. <pinoaffe>is there like a well-defined road to add an srfi module to guile? <ArneBab>mwnaylor: my question was whether we can get ecmascript on wasm when guile is ported to wasm, and it sounds like yes! <haugh><pinoaffe> "is there like a well-defined..." <- Depends on what exactly you're asking about here, and also on the particular SRFI. If you look through the native SRFI support you can see that SRFIs are often merged in interesting ways or extended with great consideration; I don't follow the core dev process so maybe someone else can elaborate. In terms of using them as third-party libraries there are several guix packages that can give you an idea of <haugh>pinoaffe, if you just want the functionality for yourself, you might be surprised by how easy it can be to wrap a SRFI implementation in a Guile module. Here's my SRFI-197 wrapper for example: http://vpaste.net/nBTLd