IRC channel logs


back to list of logs

<daviid>wingo: done, just posted a release ...
<daviid>wingo: will release guile-gnome, last call, you have no hard feelings commenting (temporarily at least) corba and gnome-vfs?
***siel_ is now known as siel
<reepca>procedures can be shadowed, right?
<reepca>should it be making a difference if the procedure being shadowed is in another module (but exported)?
<daviid>reepca: you should really be careful about this, a tipical source of 'heisen' bugs
<daviid>but yes, the modyle system will consider the last definition has the valid one ... see the documentation, where this is well explained
<reepca>Is there a way to invoke a custom port's WRITE! function directly? I'm trying to generate a wrapper around an output port that will record how many bytes are written to it (since the port itself doesn't provide a GET-POSITION procedure).
<brendyn>davexunit: I want this in Chikadee please xD
<janneke>Morning Guile!
***darthlukan_ is now known as darthlukan
<Apteryx>Hello! What is the best debugger command to know where I'm at in the sources? So far it looks like ",frame" is the best option?
<Apteryx>Also, I can't get ,break-at-source to work for me. It always return for example: ERROR: No procedures found at ~a:~a. "/home/maxim/src/guix/scripts/environment.scm" 543
<spk121>Apteryx: break-at-source is problematic. You might have better luck with ,break
<spk121>,break (@@ (module path) funcname)
<Apteryx>spk121: I got it working with just ,break, thanks. But I was trying to have finer grain control, but it seems it doesn't know about syntax symbols.
<Apteryx>spk121: Should I report a bug about ,break-at-source not working? I don't see any opened issue on the tracker.
<spk121>Apteryx: I did file a bug a few months ago about how trace doesn't work any more. I wonder if they're related?
<Apteryx>I'll have a look.
<spk121>Apteryx: in any case, it is a minor bug that the error line still has "~a:~a" instead of propertly formatting the error
<spk121>As an aside, I've been using macros like this in my source to print local variables. It has been pretty useful.
<Apteryx>spk121: Isn't ,locals suppose to do something similar to your macro?
<spk121>It is supposed to do the same thing, but, I have trouble getting the debugger to break at the line I am interested in.
<Apteryx>sneek: later tell spk121 I see! That seems a good workaround.
<Apteryx>sneek: botsnack
<paroneayea>wingo: it may be possible to even adjust the web server so that even the vanilla guile server is able to handle large file uploads, even without Fibers or 8sync.
<paroneayea>wingo: if you could pass in a parameter allowing it to *not* read the entire body as a bytevector, you could continue reading from the port, and simply pass in the port as a body (or access via `request-port')
<wingo>good evening :)
<paroneayea>hi wingo !
<paroneayea>wingo: I'm not totally sure if what I said is correct though
<wingo>yes you could certainly do that. without fibers/etc it would block any other request of course
<paroneayea>because maybe the port needs to be entirely read from until it could get to the end
<wingo>yeah dunno
<paroneayea>to know when to stop reading
<paroneayea>wingo: hm okay :)
<wingo>you could disable pipelining for uploads in that case
<paroneayea>wingo: even if using 8sync / fibers, I wonder what the right approach is
<paroneayea>would you still want to "pass over" a port?
<paroneayea>or maybe a soft port that wraps another port
<paroneayea>that way you don't exceed the bounds of the request
<paroneayea>you could pass over snippets of bytevectors
<paroneayea>but that doesn't seem nice
<wingo>yeah dunno :)
<paroneayea>it may be that the "routing" layer needs to be the layer that glues together the web server and the actual view/controller
<paroneayea>and decide what kind of value to give
<paroneayea>whether it passes over a bytevector or a port
<paroneayea>but, the generic thing is, you could always just pass a port, and the routing layer can do the transformation.
<paroneayea>wingo: well thanks for listening :)
<paroneayea>wingo: eventually something will be figured out
<paroneayea>in the meanwhile
<paroneayea>I can upload small media files
<paroneayea>to pubstrate
<wingo>i agree fwiw that ports are the fundamental thing
<wingo>the issue is whether or how to hand off control back to the generic server
<wingo>after the response has been read or discarded or whatever
<wingo>a simple sequential model for requests/responses on a port works well. but without concurrency that means blocking. duno
<wingo>guile's web server right now sits in between things, having a poll facility for switching between "request is available" / not available but otherwise no serious concurrency
<wingo>also guile's web server wants synchronous handling, threading "monadic" seeds through sequential invocations of the handler
<wingo>again, a problem if the posted body is not read in full
<wingo>so it seems to me that adopting some other web server framework / server-side application split could be appropriate