<nalaginrut_>oops, I did it wrong, it should use 'guile --tjit' for it ***nalaginrut_ is now known as nalaginrut
<jmd>Is there a procedure designed for dumping scheme code? pretty-print would do, but I can't make it put comments in. <wingo>there is no scheme datum representation for comments <vlad__>Hi! Is there an equivalent of python's help(foo) or shell's type foo / declare -f foo in gulie? I'd like to get function's prototype from the repl (or at least some metadata: is it a builtin or a user defined function, etc.) <vlad__>scheme@(guile-user)> (define a (lambda (b) (+ b 1))) <vlad__>scheme@(guile-user)> ,d use-modules <wingo>it means "sloppy person who made ,d command did not implement a kind of fallback documentation" ;-) <vlad__>so it gives you annotations, just like python's help <lloda>,d only works on the current module <lloda>try (help foo) for library stuff <void-pointer>Got a question that was not in the manual as far as I could find in guile <void-pointer>Guile supports docstrings for procedures as their first item after (define <davexunit>void-pointer: define-syntax and define-syntax-rule can have docstrings <davexunit>define-syntax and syntax-case are what you should use <void-pointer>I recently (as in very recently) started to use define-syntax with syntax-rules <void-pointer>I did start out using define-macro since that was what some of the scheme tutorials used and I had a bit of knowledge and experience with it from a time I tried to learn common lisp <void-pointer>Darn, why can't my browser's text boxes use emacs keybindings <OrangeShark>I have seen some plug-ins for browsers that have vim keybindings, I wonder if there is one for emacs <void-pointer>It is a window manager written in common lisp by common lispers who like emacs and slime <void-pointer>Cool thing about it was that you could connect to it and hack it while it was running from emacs <void-pointer>Let's just say that that WM was a little more configurable than most <paroneayea>void-pointer: yeah I'm excited that stumpwm is in guix now <paroneayea>but I'm waiting on the security issue around swank being localhost+port only to be fixed before I use it again <void-pointer>There are a few solutions I have been able to think of for situations where a TCP port must be used <void-pointer>In the case of where slime or some other thing actually starts up the program in question, it is just a matter of passing an additional argument that is filled with a random string that is the expected prefix for all input commands to be sent. If a command doesn't start with that, it is rejected. And have a limit on the number of rejections before it quits. Even a short random string without that much randomness would be enough <void-pointer>Only problem is that something that can see the proc table can see the input arguments and get the prefix. <void-pointer>To go the next step, instead of passing it as an input argument, pass it on the command line as input when starting up the program <ArneBab_>void-pointer: do you know itsalltext? ← open text boxes in the browser with emacs <ArneBab_>vlad__: sorry, just saw that lloda was faster :) <void-pointer>Now reminded of the window manager done in emacs (as in, in elisp with some C code to help do the function calls) <janneke>ACTION had breakthrough with mes, now trying to hook-up/grok sc-expand <amz3>jmd: you are a strong person! <amz3>My comment might be mis interpreted <void-pointer>I'm having trouble finding a scheme implementation generic way to do exception handling that will handle all exceptions on a given implementation <amz3>on a given type? or implementation? <void-pointer>SRFI-34 (tested) and R6RS exceptions (manual explained) won't catch all Guile exceptions. Only catch does. But catch is Guile specific. <void-pointer>Basically, how to write portable scheme code that can handle excpetions. <mark_weaver>in recent versions of guile, R6RS exceptions will catch them all. we should do the same for SRFI-34. <void-pointer>If that is so, then the manual needs updating since the 2.1.4 manual says <void-pointer>"Like SRFI-18 and SRFI-34, R6RS exceptions are implemented on top of Guile’s native throw and catch forms, and use custom “throw keys” to identify their exception types. As a consequence, Guile’s catch form can handle exceptions thrown by these APIs, but the re- verse is not true: Handlers registered by the with-exception-handler procedure described below will only be called on exceptions thrown by the corresponding rais <mark_weaver>void-pointer: for now, what you could do is this: define your own macro within 'cond-expand', so it has a different implementation on different schemes. <mark_weaver>the SRFI-64 reference implementation arranges to catch all exceptions within several different schemes. <mark_weaver>void-pointer: indeed, that's out of date w.r.t. R6RS exceptions. can you email bug-guile@gnu.org about it? <amz3>mark_weaver: I was thinking about something, is it possible to re-throw an exception and have the callstack of the first exception somehow? <void-pointer>Also makes it doable to work out how to handle keyword arguments (or to bail on the idea) <mark_weaver>I don't see a sane way to implement keyword arguments in a portable way, short of just using symbols instead. <mark_weaver>keywords have never appeared in any scheme standard, nor even in any SRFI afaik. <mark_weaver>and the ones that do implement them, implement them with very different semantics. <void-pointer>Only things I have using them are macros for the most part. Symbol based ones are easy to handle with define-syntax as long as there are not many <void-pointer>Also, would have figured that they would be more widely used since common lisp has them <amz3>void-pointer: did you publish you code? <mark_weaver>I could find the answer, but right now I'm busy with another high-priority task. <void-pointer>amz3: code is not published yet. Still in a state of flux. Got to finish the documentation and try to make it more portable <amz3>I publish everything I do on github and framagit nowdays and sometime delete repos, but I have bad feeling about deleting stuff, now I regret <void-pointer>well, the patch is in 2.1.4 it seems. Just the documentation needs to be updated <void-pointer>amz3: I usually publish a lot of what I am working on. But I often try to get something at least partially working before the first commit, idealy fairly polished up before the initial commit. <mark_weaver>something similar should be done with SRFI-34 exceptions, and probably SRFI-34 and R6RS exceptions should simply be merged into the same thing, although first we'd need to understand the differences between those two APIs. <mark_weaver>but that would require first comparing+merging SRFI-35 and R6RS conditions. <void-pointer>That, and being new to scheme, have to do a bit more work before I am comfortable showing the world my code (like, for example, I realized today that a lot of my messy (let ((a '())) ... (set! a afaif) ... in all sorts of ugly nested forms would be better handled by good use of continuations <void-pointer>Well, SRFI-18 and SRFI-35 are already close to equivalent to each other in guile accordin to the manual <mark_weaver>it's a multithreading library, whereas srfi-35 is a conditions library (data structure for describing exceptions) <amz3>void-pointer: I wait and more and more before publlishing, that said, Once i start a project I usually bootstrap it from a repository created online (using git clone) <void-pointer>It's exception API (not the rest of it of course) looks pretty similar <amz3>(I even publish "Ok" comments in git log ;) <void-pointer>Perhaps I will share it this weekend. Want to at least make a good stab at making it run on another R6RS scheme and get some more documentation done. <void-pointer>Also, I have to separate it out from project it was written as a tool for into its own project <amz3>void-pointer: "to separate it out from project", my goal is to avoid that but I do it nonetheless for small proof of concepts <amz3>start in another repository and then merge the work in the main repo <amz3>I'd like to see how big it can become <amz3>this is bad for sharing somehow... to help with that, I try to make single file "miniprojects" self-contained that can be easily copy/pasted (even the test suite is the file, it's run if CHECK=t in env bash env) <amz3>this make me think that I should update the documentation of the main project <ft>Seems like a good choice to try things out. :) <void-pointer>Hmm, got some ideas for procedures to add based on what your module included <void-pointer>Namely, the inverses of my own procedures (e.g. test-eq-not) <ft>void-pointer: sure. I thought it was a fun coincidence. :) <void-pointer>ft: but I am also trying to make mine a lot better than it is now <void-pointer>I have two different syntax-rules macros that are 100 lines long <amz3>I never write more than a few lines macros and I don't recall from the top of my head what kind of macro it is :) <amz3>the phone is plugged on VR, I think she has virtual keyboard <amz3>without virtual keyboard it's not possible IMO <ft>void-pointer: Scheme style macros took me a while to feel comfortable with; especially syntax-case. <void-pointer>Was originally trying to do everything in define-macro style macros <void-pointer>Did get them to minimally work, but minimally and htey were fragile <void-pointer>So switched to syntax-rules style macros, which really made a difference <void-pointer>Not sure if syntax-case will help more than it hurts with difficulty, but I have to learn them to find out <void-pointer>I did learn today that using continuations would really make a lot of my code in that module a lot simpler <ft>syntax-case is complex but powerful, since you basically get to program the compiler using all of scheme and not "just" a pattern matcher.