<jcowan>For whatever reason, I can't get Guile to see the R6RS module I have written. It compiles successfully, but when I import it, I get "no code for (foo bar)". The file foo/bar.sls exists and there is a corresponding .go file in the cache. <daviid>jcowan: from a repl, cld you see what %load-path gives you? <jcowan>$1 = ("/usr/local/Cellar/guile/2.2.4/share/guile/2.2" "/usr/local/Cellar/guile/2.2.4/share/guile/site/2.2" "/usr/local/Cellar/guile/2.2.4/share/guile/site" "/usr/local/Cellar/guile/2.2.4/share/guile") <jcowan>so I need to add . to this path? Can that be done in a persistent way? <daviid>jcowan: is you module in one of thoe? <daviid>no sure guile handles different extension name then ".scm" though, never tried, maybe someone else knows ... <jcowan>I assume that's add-to-load-path <jcowan>assuming that's $HOME/.guile also <daviid>probbly because of the exension nam <daviid>then once happy put the solutun in .gule and restart guile ... <daviid>np! maybe ther is an option somewhere to allow diff extension <jcowan>no, works at the repl, fails from the test program <daviid>what works in a repl that does not work running a program? tha's probably a different issue <daviid>yoyr test prg starts guile using a shebang? (it loads your $HOME/.guile anyway) <daviid>jcowan: but 'just in case, if your "tests" is a guile script, try adding (add-to-load-path ".") before the import module sexp <jcowan>no shebang, no, run it as "guile foo/bar-tests.scm" <jcowan>part of a general script that tries various Schemes <daviid>try guile -L "." foo//bar-tests.scm <jcowan>'ll have it do add-to-load-path with a cond-expand <jcowan>oh, actually I can live with that, yes <daviid>maybe you'll need to specify the ull path thpugh <jcowan>that works, and the tests are passing, but I'm not sure if my code is running! <jcowan>this is a portable replacement for (rnrs bytevectors) called (r6rs bytevectors) <daviid>put a (pk "hi there") somwhere in tests <jcowan>and apparently (rnrs bytevectors) is being implicitly imported <jcowan>because all the identifiers are reported as being doubly defined, and this is just a warning, so I don't know which ones are running. <jcowan>the tests are running, but they may be testing the native module rather than mine <daviid>jcowan: they way to know and specify that in at module def time <daviid>look in the manual for #:duplicates <jcowan>the point is, R6RS-compliant programs shouldn't implicitly import stuff <jcowan>I'll see if an #!r6rs makes the problem go away <jcowan>Guile apparently isn't separating R6RS programs from (non-R6RS) scripts. <daviid>jcowan: but anyway, you are redefining exiting functionality <daviid>so you need to inform the module system how you want this t be handled <daviid>let me find the manual section for you <jcowan>Existing functionality, but in a different name. That's the point. I want to make sure that the same tests run against both the native and the portable module <daviid>and use (pk "what ever") to double check <daviid>you would nt have warnings at import time if names were different <jcowan>I do not want (rnrs bytevectors) to be imported <jcowan>yes, it's implementing the same interface <jcowan>I'll wrap the tests in a library and import the library, see if that works <jcowan>WARNING: (guile-user): `u8-list->bytevector' imported from both (r6rs bytevectors) and (rnrs bytevectors) <jcowan>there is no (rnrs bytevectors) in the import statement <daviid>does guile import (rnrs bytevectors) 'as core functonality' maybe <daviid>so, somewhere/somehow you import (rnrs bytevectors) <daviid>jcowan: to convince yourself, start a new repl and enter u8-list->bytevector, you'll get an error <jcowan>I agree that it's not working from the REPL, but wrapping it in a library (that exports nothing) provokes all kinds of not-defined errors from the tests <daviid>tests can see and therefore not use anything defined in a module of your that does not export its names (public interface) <daviid>test can not see ... anything not exported <jcowan>Maybe things really are working and these are just unwanted warnings <jcowan>I'll modify the library to jabber at me <daviid>jcowan: the first thing is that you have imported, somewhere, (rnrs bytevectors), otherwise you would not have any warnings of those <daviid>jcowan: and you should export the publc iterface of your rewrite of this bytvectors things <jcowan>WARNING: (guile-user): `u8-list->bytevector' imported from both (r6rs bytevectors) and (rnrs bytevectors) <daviid>something as imported it, as the repl test shows <daviid>which is not a problem anyway jcowan , just tell the module system how to deal with that <daviid>one of tose port bytevectors I guess <jcowan>I imported both of those at the REPL but that does not cause the rnrs bytevectors identifiers to be exposed <jcowan>and I was able to prove that my code is being suppressed by the warning <daviid>(default-duplicate-binding-handler) <jcowan>(replace warn-override-core warn last) <daviid>jcowan: your code s not supressed, you are not exporting your functionality ... <jcowan>no, the export statement does the right thing <jcowan>anyhow, I think I found the problem; I cleared the cache and it went away <jcowan>"The two hardest problems in computer science are naming things, cache invalidation, and off-by-one errors" <PuercoPop>Does anyone know why does guile-xcb Make script depends on aclocal-1.14? I've been trying to make it work with 1.15 (the one available on Ubuntu 16.04) to no avail <daviid>though from what you said, foo/bar.scm does not export, and tests tries to use its functionality ... maybe I mssunderstood, but that's ok, I'm glad you solved this problem the way you want ... <daviid>PuercoPop: I don't think guile-xcb is properly maintained, but in any case, you can locally edit its configure.ac file and safely change that< I think <PuercoPop>daviid: I just want to be able to run it to understand how the codebase to see if I can pilfer something. Don't see any direct reference to aclocal, guess I'll have to learn the basics of autotools. Thanks! <mwette>is xcb same as libx11-xcb (on apt)? <mwette>(define-ffi-module (ffi x11-xcb) <mwette> #:inc-filter (lambda (file-spec path-spec) <mwette> (string-contains path-spec "/xcb/" 0))) <daviid>lloda: lloda2, how are things wrt guile-cairo make distcheck? (I haven't had the time to look at it yet) <daviid>by the way, my advice to remove INSTALL from the tree was not a good advice, sorry: though it is regenerated at ./configure time, it better in the tarball imo <daviid>which is what I do for all my projects (also because I do change the content f this file compared to the traditional one ... as I said, I was not exactly 'up-and-running' when I suggested this... not a big deal either ... fwiw, I copy (in org mode) the content of the install web pages of my projects, so users who did download the tarball but are with no internet at install time can proceed .... voilà! :) <daviid>PuercoPop: did you succeed? (I had to change 'space', so when off a little...) <PuercoPop>AM_AUTOMAKE_VERSION from aclocal.m4 from 1.14.1 to 1.5 ***Server sets mode: +nt
<PuercoPop>Btw any pro tips how to 'trace the execution' of the custom reader provided by guile-xcb? <daviid>PuercoPop: maybe yu should consider installing Guix, on 'top off' Ubunto, it will help you a lot not loosing all this time ... <daviid>PuercoPop: yes, guile-xcb is in Guix <daviid>PuercoPop: I highly recommend yu that root, but as you wish of course <PuercoPop>daviid: I've actually been thinking of giving Guix a go when I buy a new PC. Earlier this year at work I looked into Nix, read through tons of documentation, the design seemed solid but I wasn't able to build a script on my own so we end up passing on it. Having scheme as the language to write/describe the recipes should be more straight forward to me. How is the documentation story? Better than Nix? <daviid>lloda: one of the problem is that to unofficially release guile-cairo 1.10, I worked on master (here locally), and now I have 11 unmerged patches to origin master (and off course unpulled the ones you and andy wrote ..) <daviid>lloda: however, (I was sure of that, but wanted to locally try first), my local master branch runs 'make distcheck' perfectly <daviid>... ==================================================== <daviid>guile-cairo-1.10.0 archives ready for distribution: <daviid>lloda: I wanted to merge, at the time, of course, and asked commit right (which still is there), but neger got it :(, so I decided to release unofficially (guile-clutter needs that version...) now, no blame, no anger, I'd be happy to help, but my git-fu is pathetically low <daviid>PuercoPop: no need to 'wait' for a new PC though, just install guix as a host distro... I suggest you tlk to #guix, I know a few guiers how uses ubuntu and guix ... <daviid>PuercoPop: the #guix channel is extremely friendly and helpfull <daviid>jcowan: for info "6.20.3 Creating Guile Modules" is worth a quick read, it explains possible options for the #:duplicates entry, among other things ... <jcowan>thanks, I no longer have that problem <wingo>automatic JIT compilation working :-)) <lloda>sneek: later tell daviid I mailed guile-user with the problems I have. If you have a separate branch that works please post a link and I'll try to merge myself <lloda>sneek: later tell daviid Also please request commit access again <lloda>hi wingo, I'm building your last commit <lloda>so I don't need %jit-compile any longer? <lloda>ah I see GUILE_JIT_COUNTER_THRESHOLD <lloda>ok, it's still slower than stable-2.2 *sometimes* <lloda>2x faster some other times :D <wingo>tiering up from within loops still isn't implemented fwiw *wingo just pushed a couple changes, note that the equivalent of the old "threshold 100" is now 200 <wingo>now setting threshold to 0 will compile *everything* <wingo>it's slower for various reasons of course <lloda>GUILE_JIT_COUNTER_THRESHOLD=0 ~/sys/guile3/bin/guile -q -L mod -s test.scm <lloda>jit.c:685: fatal: assertion failed <lloda>this is -O2, it doesn't happen with -O1 :-\ <lloda>I never remember how to run Guile's own benchmarks <wingo>i mostly run the compiler when i need a benchmark <lloda>;;; (what! #<stack 4e8d120>) <wingo>not sure, i think it's in statprof when it doesn't understand why it's getting what it's getting <wingo>statprof needs a couple fixes <wingo>lloda: added ability to tier up from within loops <wingo>next up, fix the code allocator to not allocate whole pages for each function <lloda>wingo: in fact just starting up with GUILE_JIT_COUNTER_THRESHOLD=0 guile gives me <lloda>jit.c:685: fatal: assertion failed <lloda>> GUILE_JIT_COUNTER_THRESHOLD=0 guile -s empty.scm <lloda>;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 <lloda>;;; or pass the --no-auto-compile argument to disable. <lloda>;;; compiling /home/danielo/Prog/test/empty.scm <lloda>if I do the same with GUILE_JIT_COUNTER_THRESHOLD!=0 it does work and if I try again with GUILE_JIT_COUNTER_THRESHOLD=0 w/o clearing the cache it works too <lloda>all this with -O2, -O1 seems to work whatever I try <lloda>so the backtraces don't look helpful ***asterope_ is now known as asterope
<asterope>How would I go about separating a guile script into modules? `use-modules` doesn't want to load modules that are in the main script's folder... <lloda>you can call $GUILE with -L . <lloda>or add (add-to-load-path (getcwd)) before use-modules <lloda>eventually you have to define some kind of directory structure for your modules and set %load-path <asterope>I tried with the `(add-load-path (getcw))`, but it won't load the second script <asterope>idk why, but (use-modules (other)) can't find my second script <asterope>I changed the module name, and it works now... so nvmd ***rekado_ is now known as rekado
<outtabwz>does guile have something similar to racket's check-expect? <wingo>the aborts/segfaults you found, were they assertion failures? <wingo>i do get some assertion failures in GUILE_JIT_THRESHOLD=0 guile -c '(compile-file "/tmp/empty.scm")' <wingo>i do get some assertion failures in GUILE_JIT_COUNTER_THRESHOLD=0 guile -c '(compile-file "/tmp/empty.scm")' <wingo>lloda: just pushed a fix for that fwiw <wingo>still working on making the test suite pass tho :P ***daviid is now known as Guest75565
***Guest75565 is now known as daviid