<ArneBab>manumanumanu: so I could use (in-file "path" read-line) ? <wingo>manumanumanu: two ways: LICM and loop peeling + CSE <wingo>vector-length will generally be hoisted out of a loop, if not by LICM then by peeling. but compile and disassemble to see. <wingo>the issue is that vector-length can throw an exception and may not always be executed in the loop body. in that case it won't be hoisted unless it is always evaluated the first time through the loop (that's the effect of peeling) ***wxie1 is now known as wxie
<roelj>What is the difference between 'get-bytevector-n!' and 'get-bytevector-some!'? <civodul>roelj: the former waits until it has read N bytes or EOF has been reached <civodul>while the latter reads as much as can be read without blocking <ane>is it possible to throw 3.0 style exceptions from C? <ane>oh, scm_raise_exception ***sneek_ is now known as sneek
<anon9002>With GOOPS, I noticed that if I add a new method to the generic add-method!, it will stop working properly even if all I did was just calling (next-method). More specifically, it will always raise an exception in the form "X is not a valid generic function". Is this a bug, or I'm just doing something wrong? <anon9002>(define-method (add-method! (generic <generic>) (method <method>)) (next-method)) <anon9002>After that point, the exception is raised. <daviid>anon9002: you don't (shouldn't) (re)define add-method!, it is part of the protocol (unless you really know what you are doing), you should 'just' use it <daviid>bah, i will never ever remember how to talk to our bot :):) <daviid>dsmith-work: help, goops tutorial please ... tx <daviid>anon9002: in the last part of the tutorial, 'Further remarks', there is an example of what you are trying to acheive ... <anon9002>My use case is actually a bit unusual. I'm working on Guile bindings for a game engine (godot), and the engine wants to know where each method is defined in the code. I'm trying to get this information by capturing the stack each time add-method! is called and inspect frames to figure out where each method is being defined. Is there a better way to do this? <anon9002>I think I figured out what went wrong. I thought that when you define a method, and another method with the same set of specializers already exist, the new method will be added to the list of methods for that generic. What actually happens is that the new method just replaces the old one. So I tried looking up the original add-method! manually and call it instead of (next-method), and this time everything <manumanumanu>ArneBab: You may also do, at least in my private branch: (:for enumerated-lines (in-enumerated (in-file "path" read-line))). That will give you pairs of (0 . line-1), (1 . line-2) etc. That however has the cost of reading the file through a generator. Everything that cannot be easily done in the iterator protocol is handled through generators. Currently that is (in-cycle ...) for things that are not lists and <ATuin>hi, is there any library to encrypt/decrypt using RSA for guile? ***jonsger1 is now known as jonsger
<ArneBab>manumanumanu: enumerated lines sounds great! Are you going for getting merged into guile proper?