Re: file names embedded in .go

() "Jose A. Ortega Ruiz" () Tue, 20 Apr 2010 21:15:25 +0200 It's an Emacs environment for Scheme similar to Slime: a repl and a bunch of utilities to edit, navigate and obtain information about the code. Among them, jumping to an identifier's definition: for that, i need guile to tell

Re: srfe records in reworked match

Hello Stefan, stefan writes: > I have started to code in some record recognition into the match construct Excellent! :-) Are you hacking Wright’s match as currently in Guile or Alex Shinn’s rewrite from ? > I need first to make sure that I grok the intention of

Re: port-filename and path canonicalization

Hi, Thien-Thi Nguyen writes: > Another idea is to conceptually separate "filename" to be "directory" > and "basename" and have file ports maintain the directory portion as a > file descriptor (or equivalent) internally, exposed through some kind of > opaque handle. I think open file ports shoul

Re: srfe records in reworked match

Hi, [Keeping the list CC’d.] Stefan writes: > Question? should we make it lean and just allow sfri-9 or perhaps > allow for both styles of records? Actually, record matching in Wright’s match assumes users follow a simple naming convention for the type predicate (only for the type predicate in

Re: a plan for native compilation

On Apr 18, 2010, at 07:41, Andy Wingo wrote: > Specifically, we should make it so that there is nothing you would want > to go to a core file for. Compiling Scheme code to native code should > never produce code that segfaults at runtime. All errors would still be > handled by the catch/throw mecha

Re: port-filename and path canonicalization

() l...@gnu.org (Ludovic Courtès) () Wed, 21 Apr 2010 10:49:05 +0200 I think open file ports shouldn’t grant any authority beyond access to the open file. Just like an open file descriptor doesn’t convey any authority beyond access to the underlying file (if we omit ‘..’ lookups on a

Re: Portability fixes for win32 cross compiling

Volker Grabsch schrieb: > Or, what about changing the generated code? Why does the generator > have to determine a number to be written into the generated code? > Instead, the generated "scmconfig.h" could contain code like this: > > #include > > ... > > #define SCM_ICONVEH_ERROR i

Code coverage reports for Scheme

Hello! Here’s a code coverage report for Guile’s Scheme code: http://www.fdn.fr/~lcourtes/software/guile/guile.lcov/ So here’s the idea: pick the red box of your choice and make it so that next time it’ll be bright green. :-) The report was generated using LCOV on data produced using (system

Re: port-filename and path canonicalization

Hi, Thien-Thi Nguyen writes: > That is, if a file port supports ‘file-port-directory’, then how > to use/restrict the resulting object is left up to higher layers, > where it belongs. I would put it the other way round: if an application wants to implement ‘file-port-directory’, then it’s its r