[PATCH] Fix make-custom-port in case encoding is #f

>From 72b85f8e6a369e6aef4c6bd6bb233c0cacb80b03 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Hannes=20M=C3=BCller?= <> Date: Sat, 21 Dec 2024 16:55:13 +0100 Subject: [PATCH] Fix make-custom-port in case encoding is #f * module/ice-9/custom-ports.scm (make-custom-port): Code fails if (fluid-ref %default

[PATCH v2] Fix make-custom-port in case encoding is #f

Hi Maxime, Thanks for hint with the explanation. I'm still learning.  Below the second try. Best Regards Hannes >From 5eb06c5d22799170289ab55ab5a8eab45a98b390 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Hannes=20M=C3=BCller?= <> Date: Sun, 2 Feb 2025 21:32:18 +0100 Subject: [PATCH v2] Fix make-cust

[PATCH] libguile/scm.h: fix BUILDING_LIBGUILE for -Werror=undef

>From 696151ca382c7b166d349f704812dd73bc2fa7a7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Hannes=20M=C3=BCller?= <> Date: Sat, 21 Dec 2024 19:20:17 +0100 Subject: [PATCH] libguile/scm.h: fix BUILDING_LIBGUILE for -Werror=undef *libguile/scm.h: BUILDING_LIBGUILE is not always defined. This is signale

Re: Including sjson (formerly (ice-9 json)) and fash.scm in guile proper?

Hi Chris, Christopher Allan Webber writes: > So a while ago, David Thompson submitted (ice-9 json) to Guile proper. > A few changes were requested, so it hadn't made it in. In the meanwhile > I began using it for a number of projects. I also added some > modifications and extensions: #nil becam

Re: Is the backtrace broken in 2.2.2?

Nala Ginrut writes: > On Wed, May 3, 2017 at 3:45 AM, Andy Wingo wrote: >> On Mon 01 May 2017 06:45, Nala Ginrut writes: >> >>> Hi all! >>> I'm using the latest Guile from git repo. >>> It seems something is wrong to print message of backtrace. >>> >>> ---cut

Re: Wisp as shipped language in Guile?

Hi Arne, Arne Babenhauserheide writes: > A few weeks ago I asked in IRC whether wisp[1] could be included with > Guile in modules/language/wisp to allow every guile users to run wisp > code from any Guile installation via > > > $ guile --language=wisp [] > > > Essentially this is about making

Re: Including sjson (formerly (ice-9 json)) and fash.scm in guile proper?

I wrote: > Most of the modifications you've made are good, but I'm very > uncomfortable with the use of #nil in this API. [...] Christopher Allan Webber writes: > Oh! No you got it backwards, the library *was* using #nil initially, > and I modified it to use 'null now instead. :) Ah, my mistak

Re: [PATCH] Add preliminary versions of the R7RS libraries along with documentation and tests

Hi Freja, Freja Nordsiek writes: > I went through the patch and cleaned up a lot of little things (line > length in documentation, two spaces between sentences in > documentation, trailing spaces, etc.), made a proper commit > comment/log, and replaced the very ugly bytevector output port hack >

Re: [PATCH] Add preliminary versions of the R7RS libraries along with documentation and tests

Hi Freja, Freja Nordsiek writes: > As far as splitting it into parts and discarding the scheme modules > and keeping the documentation, that sounds like a good idea. I just > did a quick perusal of the r7rs-wip branch and it does not seem to > have any R7RS unit tests. Did I miss any? If not, th

Re: [PATCH] On Hurd, don't use not implemented madvise()

Hi Manolis, manolis...@gmail.com writes: > From: Manolis Ragkousis > > On Hurd, because madvise() is not implemented we disable it. > > * libguile/vm.c (return_unused_stack_to_os): Don't use madvise() on Hurd. > --- > libguile/vm.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > >

Re: [PATCH] On Hurd, don't use not implemented madvise()

Manolis Ragkousis writes: > On 05/30/2017 10:41 PM, Mark H Weaver wrote: >> Is there a test we could perform at run-time to discover whether >> madvise() is implemented? If so, that would be greatly preferable. >> > Well madvise() on Hurd is a glibc no-op that f

Re: Tree-IL on let

Matt Wette writes: > In Tree-IL there is let, letrec and letrec* but not let*. Any reason > why? 'let*' is a trivial convenience macro for nested 'let', whereas 'letrec' and 'letrec*' are processed later in compilation, and neither one can be efficiently implemented in terms of the other. > I

Re: [PATCH] On Hurd, don't use not implemented madvise()

writes: > On Thu, Jun 01, 2017 at 07:29:03PM -0400, Mark H Weaver wrote: >> Manolis Ragkousis writes: > > [...] > >> > Also from my understanding not using madvise() ends up in slower >> > performance but it doesn't create problems to the program, righ

Re: Efficiency of `map`

Stefan Monnier writes: >> (define (map f l) >> (if (pair? l) >> (cons (f (car l)) >> (map f (cdr l))) >> '())) >> >> whereas we used to have to write code like this in order to support long >> lists without overflowing the stack: >> >> (define (map f l) >>

Re: Efficiency of `map`

Nala Ginrut writes: > Do you have any advice to optimize it without disable GC temperaly? Temporarily disabling the GC would merely postpone reclamation work that needs to be done eventually, and at the risk of allocating a potentially huge amount of garbage while the GC is disabled, in the worst

Re: #if __GNUC__ > 2 ..

Jan Nieuwenhuizen writes: > Hi Matt! > > When I use Nyacc to parse things like > > #if __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 96) > # define _GL_ATTRIBUTE_PURE __attribute__ ((__pure__)) > #else > # define _GL_ATTRIBUTE_PURE /* empty */ > #endif > > I get > >

Re: On adding Kawa/Chibi R7RS test-suite to the r7rs-wip branch

Hi Freja, Freja Nordsiek writes: > On Mark Weaver's suggestion, I looked up the Kawa and Chibi R7RS-small > test suites. Kawa uses Chibi's test-suite, though it is wrapped in a > bit of extra code at the top. Kawa's license is not likely to be a > problem, as it is a MIT license ( > https://www.

Re: [PATCH] Add preliminary versions of the R7RS libraries along with documentation and tests

Freja Nordsiek writes: > Also, I found one error in the get-output-bytevector procedure in > (scheme base), which was that the procedure discarded the bytes > already written. get-output-bytevector is not supposed to be > destructive to the bytes already written, but the R6RS output > bytevector

Re: [PATCH] Add preliminary versions of the R7RS libraries along with documentation and tests

Freja Nordsiek writes: > Hmm, just realized, to add on top of what you said, method has a major > thread-safety problem if the bytevector output port is accessed from > more than one thread. Definitely need to fix this. In Guile, port operations are not specified to include built-in thread synchr

Re: Including sjson (formerly (ice-9 json)) and fash.scm in guile proper?

Hi Chris, I'm terribly sorry for the long delay on this. For better or worse, I've become extremely concerned about computer security, and so I feel a heavy responsibility to be extra careful about code that is expected to parse hostile data. I was also looking for a cleaner way to express this

Re: Including sjson (formerly (ice-9 json)) and fash.scm in guile proper?

I wrote: > I was also looking for a cleaner way to express this parser, and to add > better error reporting, while allowing flexibility for users to > customize the Scheme representation. I forgot to mention that another goal was to minimize heap allocations, e.g. eliminating the allocation of in

Re: Including sjson (formerly (ice-9 json)) and fash.scm in guile proper?

I wrote: > and real numbers cannot simply be printed using 'display' because of > infinities and NaNs. ... and exact rationals. Mark

Re: [PATCH] r7rs-wip branch: Add reader and print options to support R7RS bytevector syntax.

commit 84aebcaecb78ac87b0039451becf9623e3ddcce4 Author: Mark H Weaver Date: Sun Jan 12 04:44:39 2014 -0500 bytevector=?: #vu8(1 2 3) is equal to #u8(1 2 3). * libguile/bytevectors.c (scm_bytevector_eq_p): Treat VU8 and U8 element types as equivalent. but I'm not sure it

Re: [PATCH] r7rs-wip branch: Add reader and print options to support R7RS bytevector syntax.

Freja Nordsiek writes: > Was fiddling around with using Chibi's R7RS test-suite in Guile and > found a major R7RS syntax feature currently missing from Guile. The > feature is R7RS bytevector notation, which uses the #u8 prefix like > SRFI-4 unsigned 8-bit integer vectors instead of the R6RS pref

Mistakes in the R7RS-small formal denotational semantics

Hi Alex and John, I believe I've found a few mistakes in the formal denotational semantics for R7RS-small. The scheme-reports mailing list seems to be gone, so I'm not sure where to send this. First, if I understand correctly, the 'pathup' and 'pathdown' auxiliary functions associate the wrong d

Re: [PATCH] r7rs-wip branch: Add reader and print options to support R7RS bytevector syntax.

Hi Freja, Freja Nordsiek writes: > That is a good point about the global effect of the reader and print > options. I saw that ports can have their own separate reader > options. Wondering i f there is a good way to set it on a per file > basis without using a #!r7rs line. It is easier with libra

Re: [PATCH] r7rs-wip branch: Add reader and print options to support R7RS bytevector syntax.

Freja Nordsiek writes: > I saw the stuff in the bytevectors code where the SRFI-4 u8 vectors > and bytevectors are essentially the same but with different > flavors. The reader option was to make #u8 make bytectors that are > exactly the same as #vu8. Right. If it turns out that merging the VU8

Re: Potential bug with SRFI-19 Time, seconds and nanoseconds flipped

Christopher Baines writes: > The seconds and nanoseconds fields seem to get swapped around, but I > can't quite work out how. Indeed. This was discovered shortly after the 2.2.2 release in April, and fixed here: https://git.savannah.gnu.org/cgit/guile.git/commit/?h=st

Re: Recovering from a bad installation

Ricardo Wurmus writes: > Hi Guix, Wrong mailing list :) Mark

Re: feature request: simple hashbang for executable scripts

j kalbhenn writes: > scripts of other languages usually need just one line to specify the > interpreter: > > #!/usr/bin/myinterpreter > > but with guile we have to add a final !# > > #!/usr/bin/guile !# The shebang above does not work, because the "!#" is interpreted by the kernel as an

Re: macro helpers

Hi Stefan, Stefan Israelsson Tampe writes: > Writing efficient macros is a bit difficult. Let me explain by using > an example. The background is that I maintaining a python compiler and > python like object system and would like to program a scheme macro > that would be the scheme counterpart t

Re: _writable_elements & empty vectors

Daniel Llorens writes: > There is a whole set of functions scm_TYPE_writable_elements in > Guile. In 2.2 these functions must be called with mutable containers. > > The problem is that empty vectors or arrays are immutable, so one is > forced to guard every call to scm_TYPE_writable_elements with

Re: [PATCH] Bring `bitwise-copy-bit' behavior back in line with R6RS.

Julian Graham writes: > It looks like there was a subtle but significant regression introduced > to the behavior of `bitwise-copy-bit' in `(rnrs arithmetic bitwise)' > back in 93da406f33. > > R6RS says [0] that function (with arguments EI1, EI2, EI3) should > transfer the EI2th bit from EI3 to EI

Re: [PATCH] Bring `bitwise-copy-bit' behavior back in line with R6RS.

Mark H Weaver writes: > Julian Graham writes: > >> It looks like there was a subtle but significant regression introduced >> to the behavior of `bitwise-copy-bit' in `(rnrs arithmetic bitwise)' >> back in 93da406f33. >> >> R6RS says [0] that

Re: Thread 1 "guile" received signal SIGPWR, Power fail/restart.

Amirouche Boubekki writes: > I have a guile crash that I can reproduce all the time so far that says: > > Thread 1 "guile" received signal SIGPWR, Power fail/restart. SIGPWR is used internally by libgc. If I recall correctly, it's done to suspend all threads within their signal handlers befor

Re: [PATCH] Recognize RISC-V compilation targets.

Hi Shea, sorry for the delay. Shea Levy writes: > * module/system/base/target.scm (cpu-endianness): Add case for "riscv" > variants. Applied in commit 08bb4628369cf3efe7c96a32919705c41a9ed9e9 of the stable-2.2 branch, so it will be included in Guile-2.2.4. Thank you for working on RISC-V. That

Re: Performance impact of top level definitions

Hi Brian, Brian writes: > Today I found that top level defines have a significant performance > impact on Guile (2.2.3). The following program takes about 108 seconds > to complete on my ThinkPad (an i5-5200U with Arch Linux): [...] > By simply wrapping that code in a lambda the program finished

Re: tracepoints/breakpoints and native compilation

Hi Andy, Andy Wingo writes: > A design question for everyone. I am wondering how to support > breakpoints, tracepoints, and the like in a Guile with native-code > compilation. If you are not familiar with what Guile does currently, > see: > > https://www.gnu.org/software/guile/manual/html_no

Bogus range calculations for bitwise operations in Guile 2.2

Hi Andy, While investigating , I've found several mistakes in the range calculations for bitwise operations in (language cps types). As a result, 'logand', 'logsub', 'logior' and 'logxor' would sometimes generate bad code. Andy Wingo writes: > wingo pushed a commit

Re: German translation of R5RS

Hi Florian, "pelzflorian (Florian Pelz)" writes: > Please accept my patches adding a German language info file for R5RS > and fixing some small errors in English R5RS. I believe the patches > to be reasonably correct. I very much appreciate this enormous amount of work that you've done! My pri

Re: About seq in Tree-IL

Hi, Tommi Höynälänmaa writes: > I use Tree-IL as an intermediate language for my own programming > language Theme-D and the generated Tree-IL files contain a huge nested > seq expression. Could we allow multiple toplevel expressions in a > Tree-IL file or have the Tree-IL begin expression back?

Re: A problem with licenses

Tommi Höynälänmaa writes: > I have published some guile-based software under GNU GPL and > LGPL. However, when I open the Debian packages with Ubuntu Software > Installation (18.04) the application claims that the software is > proprietary. How can I fix this? I don't know, it depends on how tha

Re: How to record source properties for all symbols?

Hi, Fis Trivial writes: > Can you give me some guidance for how to achieve the goal(record all > source information for every symbol). If it's theoretically impossible > or hard to achieve, can you give me some inside why and advises for > making best effort? I intend to help, so pointers to inte

Re: A Pango attribute deallocated twice

Hi, Tommi Höynälänmaa writes: > A Pango attribute gets deallocated twice in program calc-9.scm causing > the program to crash. The Scheme code calc-9.scm is generated from the > Theme-D program calc-9.thp. [...] > IMHO the variable attrlist should not be deallocated at all in the > position wh

Re: How to record source properties for all symbols?

Hi, Fis Trivial writes: > Mark H Weaver writes: > >> The problem is that there's no place to store the source information for >> symbols in the standard S-expression representation. >> >> The principal defining characteristic of symbols -- that "two s

Re: A Pango attribute deallocated twice

Hi, Tommi Höynälänmaa writes: > The reason of the bug is that the attribute argument to > pango_attr_list_insert has been declared caller owned. I changed > g-wrap so that WCT arguments can be callee owned and I modified > guile-gnome2 so that the second argument of pango_attr_list_insert is > de

Re: (n-for-each-par-map 16 store download (reverse (iota (max-id))))) crash

Hi, Amirouche Boubekki writes: > I have a program that try to download hackernews locally. > > What it does is simple, it fetch the max identifier and > http-get each json value starting with the most recent > item. I use n-for-each-par-map with 16 threads I have > 8 cores. > > Here is the full

Re: (n-for-each-par-map 16 store download (reverse (iota (max-id))))) crash

Hi, Amirouche Boubekki writes: > On 2018-07-05 20:30, Mark H Weaver wrote: >> Amirouche Boubekki writes: >> >>> (define (store pair) >>> (if (null? pair) >>> (format #t "X\n") >>> (let ((port (open-file "hn.scm&q

Re: tree-il begin deprecated?

Hi Matt, Matt Wette writes: > I noticed that from 2.0 to 2.2 the reference manual section on compiling > to tree-il replaced `begin' with `seq'.  Is `begin' going to be deprecated? It's not merely deprecated, is no longer part of tree-il in 2.2. However, 'parse-tree-il' still handles 'begin', a

Re: Incorrect documentation for system, system*, and/or waitpid?

Hi Chris, Chris Marusich writes: > I was reading about the "system" and "system*" procedures in the Guile > manual, and it seems like the actual behavior of Guile seems to > contradict what the manual says. I'm using Guile version 2.2.4. > > The Guile manual says that these procedures return th

Re: Incorrect documentation for system, system*, and/or waitpid?

Hi Chris, Chris Marusich writes: > Mark H Weaver writes: > >>> scheme@(guile-user)> (status:exit-val $1) >>> $5 = 0 >>> scheme@(guile-user)> (status:exit-val $3) >>> $6 = 0 >> >> Right, these procedures are meant

Re: Incorrect documentation for system, system*, and/or waitpid?

Hi Chris, Chris Marusich writes: > Mark H Weaver writes: > >> [...] I wonder if it would be enough to simply change "process status >> code" to "integer status value" [...]. > > I agree. I've attached a new patch that makes the change. It also

Re: [PATCH] Let (format) used in exceptions be overriden

Hi Daniel, daniel.llor...@bluewin.ch writes: > From: Daniel Llorens > > * module/ice-9/boot-9.scm (exception-format): new variable. Globally > replace uses of (format) by (exception-format). What's the rationale for this proposed change? All but one of the occurrences of 'format' that you re

Re: Add dependency on texinfo in README

Mikael Djurfeldt writes: > Does this make sense (see attached patch)? > > Forgetting to install the texinfo packages has bitten myself several times. Sure, looks good to me. Thanks! Mark > From 732fe1af508aeb65588981839dfc01172ec79f0e Mon Sep 17 00:00:00 2001 > From: Mikael Djurfeld

Re: Bootstrap optimization

Hi Mikael, Mikael Djurfeldt writes: > I find that the attached patch saves a few minutes for parallel builds > on a four core machine. What it does is to build both eval.go and > psyntax.pp.go serially before the rest is built in parallel (when make > is given -j). > > Here's an attempt at expla

Officially require GNU Make to build Guile? (was Re: Bootstrap optimization)

Hi Mikael, Mikael Djurfeldt writes: > OK, here's a new patch. OK to apply it? > > This actually also fixes the existing problem of all bootstrap objects > being rebuilt of eval.scm is touched. Very nice! I didn't know about this feature in GNU Make. > The patch is verified to give a faster bu

Re: Proposal for a new (ice-9 history)

Hi Mikael, Mikael Djurfeldt writes: > I'd like to rewrite (ice-9 history) to conform to the full GDB value > history syntax. This is because I find that I miss being able to refer > to "the last value" etc. Yes, I've also missed this! > Currently we have: > > $ the N:th value from the start >

Re: Proposal for a new (ice-9 history)

Mikael Djurfeldt writes: > The interface of (value-history) would instead have a lazy-binder > which provides a syntax transformer for every $... actually being > used. The $... identifier would expand into a list-ref into the value > history. A few more suggestions: If I write (define (foo x)

Re: Officially require GNU Make to build Guile? (was Re: Bootstrap optimization)

Hi Mikael, Mikael Djurfeldt writes: > But, as you concluded, Guile currently uses GNU Make specific > functionality. $(filter-out ...) in bootstrap/Makefile.am is such a > case and also the vpath and %-thingies in am/bootstrap.am. I guess you're right. > Probably, you should start out by makin

Re: Proposal for a new (ice-9 history)

Hi Mikael, Mikael Djurfeldt writes: > On Tue, Oct 30, 2018 at 1:26 AM Mark H Weaver wrote: > > Mikael Djurfeldt writes: > > > The interface of (value-history) would instead have a lazy-binder > > which provides a syntax transformer for every $... actua

Re: Feature request: Expose `ellipsis?' from psyntax.ss

Hi Marc, Marc Nieper-Wißkirchen writes: > Guile includes a mechanism to specify a custom ellipsis for > `syntax-case' macros. For macro writers it would be nice if there were > a way to check whether a given identifier is the current (custom) > ellipsis. > > The `ellipsis?' procedure in psyntax.

Re: Feature request: Expose `ellipsis?' from psyntax.ss

Hi Marc, Marc Nieper-Wißkirchen writes: > Am Mi., 14. Nov. 2018 um 20:11 Uhr schrieb Mark H Weaver : > > > The `ellipsis?' procedure in psyntax.ss does exactly this, but it > > isn't available to user code. Re-implementing it is not possible > > without a

Re: Feature request: Expose `ellipsis?' from psyntax.ss

Hi Marc, Marc Nieper-Wißkirchen writes: > > So what we actually need is a procedure of > > two arguments: `(ellipsis? e ctx)' returns `#t' if the identifier `e' > > is the current ellipsis in the lexical environment of the identifier > > `ctx'. > > Hmm. I don't actually see a need for the

Re: Feature request: Expose `ellipsis?' from psyntax.ss

Hi Marc, Marc Nieper-Wißkirchen writes: > > Let's assume we are writing a macro that reimplements syntax (or some > > variation thereof) and which has to check whether identifiers are > > ellipses. For example, the following could be given: > > > > (with-ellipsis e > > (my-syntax a e) >

Re: Feature request: Expose `ellipsis?' from psyntax.ss

Hi Marc, Marc Nieper-Wißkirchen writes: > Am Fr., 16. Nov. 2018 um 01:01 Uhr schrieb Mark H Weaver : > > With this in mind, let's examine your example above more closely. The > ellipsis binding for 'e' is only in the transformer environment when the > 'sy

Re: Compiling guile-2.2.4 for mingw

Mike Gran writes: > On Tue, Nov 20, 2018 at 06:16:32PM +0100, Christoph Buck wrote: >> Is there currently no way to get guile running under mingw-64bit? My plan >> was to integrate guile in a project of mine which currently only builds >> under 64bit. > > Well anything is possible, of course. Her

Re: Feature request: Expose `ellipsis?' from psyntax.ss

Hi Marc, Marc Nieper-Wißkirchen writes: > > Let's run the following example: > > > > (eval-when (expand) > > (define-syntax bar > > (syntax-rules () > > ((_ stx) > >(syntax-case stx () > > ((_ a (... ...)) > > #'#t) > > ((_ a b c) > >

Re: Feature request: Expose `ellipsis?' from psyntax.ss

Hi Marc, Marc Nieper-Wißkirchen writes: > Am Mi., 21. Nov. 2018 um 04:38 Uhr schrieb Mark H Weaver : > > > Ellipsis identifiers are a bit more tricky, because unlike other > > bindings, the user-visible ellipsis identifiers are not actually > > substituted.

Re: Feature request: Expose `ellipsis?' from psyntax.ss

Hi Marc, Marc Nieper-Wißkirchen writes: > Am Mi., 21. Nov. 2018 um 04:38 Uhr schrieb Mark H Weaver : > > I'm not aware of any language in the R[567]RS that makes it clear > whether '...' should be recognized as an ellipsis if it is bound to a > variable. The

Re: [PATCH] Support ~N in SRFI-19 string->date

+++ b/test-suite/tests/srfi-19.test > @@ -176,6 +176,16 @@ incomplete numerical tower implementation.)" >(equal? "Sun Jun 05 18:33:00+0200 2005" >(date->string date > > + (pass-if "string->date understands nanoseconds (1)"

Re: [PATCH] Support ~N in SRFI-19 string->date

nanoseconds (1)" > +(time=? (date->time-utc (string->date "2018-12-10 10:53:24.189" > + "~Y-~m-~d ~H:~M:~S.~N")) > +(date->time-utc (make-date 18900 24 53 10 10 12 2018 3600 > + > + (pass-

Re: make-c-struct and pointer->string

Hi David, David Pirotte writes: > Hello, > > guile 2.2.4.1-cdb19 > > ,use (system foreign) > > ;; this fails > > scheme@(guile-user)> (make-c-struct (list '* '*) (list (string->pointer > "hello ") (string->pointer "there!"))) > $16 = # > scheme@(guile-user)> (parse-c-struct $16 (list '* '

Re: make-c-struct and pointer->string

Hi David, David Pirotte writes: >> 'make-c-struct' copies the C pointers from those foreign pointer objects, >> but not >> not keep a reference to the objects themselves. > > To me, this sounds very counter intuitive, actually, it sounds like a bug, > make-c-struct should be holding a referenc

Re: make-c-struct and pointer->string

Hi David, David Pirotte writes: >> 'make-c-struct' copies the C pointers from those foreign pointer objects, >> but not >> not keep a reference to the objects themselves. > > To me, this sounds very counter intuitive, actually, it sounds like a bug, > make-c-struct should be holding a referenc

Re: Unexpectedly low read/write performance of open-pipe

. See below for a draft reimplementation of the OPEN_BOTH mode of open-pipe* based on R6RS custom binary input/output. On my machine it increases the speed of your test by a factor of ~1k. Let me know how it works for you. Regards, Mark >From 4612e23994a012ef97e345a927fe9d0f232e78

Re: Unexpectedly low read/write performance of open-pipe

Hi Rob, Rob Browning writes: > Mark H Weaver writes: > >> See below for a draft reimplementation of the OPEN_BOTH mode of >> open-pipe* based on R6RS custom binary input/output. On my machine it >> increases the speed of your test by a factor of ~1k. > > Hah,

Re: Unexpectedly low read/write performance of open-pipe

Hi Chris, Chris Vine writes: > On Tue, 09 Apr 2019 04:35:38 -0400 > Mark H Weaver wrote: >> >> I think it's probably fine for 2.2, although a more careful check should >> be made for differences in behavior between the old and new >> implementations, and

Re: Unexpectedly low read/write performance of open-pipe

Chris Vine writes: > On Tue, 09 Apr 2019 04:35:38 -0400 > Mark H Weaver wrote: >> >> I think it's probably fine for 2.2, although a more careful check should >> be made for differences in behavior between the old and new >> implementations, and tests should be

Re: Unexpectedly low read/write performance of open-pipe

Hi again, Earlier, I wrote: > I'm not sure off-hand what would be required to re-implement custom > ports in suspendable Scheme code. I finally dug into this code, and was delighted to find that Andy Wingo has already laid the groundwork to avoid going through C code in our custom port handlers,

Re: [PATCH] Fix gc.test "after-gc-hook gets called" failures

Hi Andrea, Andrea Azzarone writes: > "after-gc-hook gets called" test randomly fails as reported > downstream, for example: > - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31776 > - https://bugs.launchpad.net/ubuntu/+source/guile-2.2/+bug/1823459 > > I'm attaching a patch that seems to fix the

Re: Unexpectedly low read/write performance of open-pipe

ector-some', although I haven't yet given them much testing. Mark >From 271cbbc3acc40926c8311e8dcca757285a53f00d Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Sun, 14 Apr 2019 17:43:30 -0400 Subject: [PATCH] DRAFT: Add a suspendable implementation of 'get-bytevector-some'. --- module/ice-9/s

Re: Undefined Behavior sanitizer findings

ee are issues in libguile, which I have fixed in commit 6b1de860ab2360e8679205aecdc1c837744a4b9c on the stable-2.2 branch: https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.2&id=6b1de860ab2360e8679205aecdc1c837744a4b9c The last was an issue in libffi, in this code: https://

Re: Unexpectedly low read/write performance of open-pipe

pendable I/O support for custom binary ports, and in particular for these OPEN_BOTH pipe ports. Note that I've not yet done much testing of these patches, besides running the Guile test suite. Mark >From 14dec723707ee766642397962fa93124d9c86811 Mon Sep 17 00:00:00 2001 From: Ma

Re: Startup locale and environ_locale_charset

Hi Mike, Mike Gran writes: > Starting in the 2.2.x series, the Guile executable calls > setlocale(LC_ALL,"") on startup except when the GUILE_INSTALL_LOCALE > environment variable is set to '0'. > > This leads to a call to scm_shell that converts command line arguments > to Guile strings using t

Re: [PATCH] Add current-suspendable-io-status parameter

Hi Nala, Nala Ginrut writes: > Here's a patch to add current-suspendable-io-status: > Its result is a pair: (finished-bytes . rest-bytes) > > This is useful for designing a proper scheduler algorithm for > suspendable I/O operations. > For example, the server-core based on delimited-continuation

Re: [PATCH] Add current-suspendable-io-status parameter

Hello again, Previously I wrote: > I also have doubts about the utility of the information provided. > 'start' seems completely irrelevant, since it merely indicates the > position within the read/write buffer. It's easier to make a case that > 'count' might be relevant, but it's not a reliable i

Re: Failed to configure Guile due to dirty iConvert

Hi Jeffrey, Jeffrey Walton writes: > I'm attempting to test GnuTLS using Asan. All dependent libraries need > to be built with Asan, too. That caught Guile in the net. > > Guile 2.2.4 is failing to configure due to resource leaks in the M4 > macro for iconv. See below. Fixed in commit 65d98d8fd2

Re: [PATCH] Add current-suspendable-io-status parameter

Hi Nala, Nala Ginrut writes: > On Tue, May 14, 2019 at 7:01 AM Mark H Weaver wrote: >> I guess what you want is the ability to see incremental reports on the >> progress of your large I/O operations. Is that right? If we are going >> to add an API for this, it need

Re: [PATCH] Add current-suspendable-io-status parameter

Hi Nala, Nala Ginrut writes: > I think your approach works for the cases which use put-bytevector* directly. > Are you assuming the server-core only handles suspendable-port with > put-bytevector in http-read or http-write? > If so, then your approach is not enough. If you're not using 'put-byt

Re: Bringing back gc-live-object-stats

Amirouche Boubekki writes: > I am stuck with a memory leak. I think gc-live-object-stats [0] would help. > > [0] > https://www.gnu.org/software/guile/manual/html_node/Garbage-Collection-Functions.html#index-gc_002dlive_002dobject_002dstats > > Can some explain to me how to bring it back? I don'

Re: [PATCH] Add current-suspendable-io-status parameter

Hi Nala, Nala Ginrut writes: > On Thu, May 16, 2019 at 8:59 AM Mark H Weaver wrote: > >> What about when we write something more structured, such as writing a >> large S-expression using 'write', or serializing XML from SXML. In >> those cases, it's eve

Immediate doubles (up to 2^256) and rationals coming to Guile 3

ns. For now, I've pushed my preliminary work to the 'wip-new-tagging' branch on Savannah. https://git.savannah.gnu.org/cgit/guile.git/log/?h=wip-new-tagging Give it a try and let me know what you think. Mark

Re: Immediate doubles (up to 2^256) and rationals coming to Guile 3

Earlier I wrote: > There's also a nice way to extract the denominator from a fixrat: mask > out the sign bit, shift right 5 bits, and interpret it as an IEEE > double. The denominator will be the integer part of the resulting > value, with the numerator in the fraction bits. Simply cast this dou

Re: guile-2.9.2 and threading

Hi Linas, Linas Vepstas writes: > I'm trying to understand how scm_jit_enter_mcode leads to > scm_timed_lock_mutex ... This simply means that 'lock-mutex' was called from Scheme, and specifically from Scheme code that has been compiled to machine code by our JIT compiler. > I want to know who

Re: guile-2.9.2 and threading

Mark H Weaver writes: >> Two are stuck here: >> >> #0 __lll_lock_wait () at >> ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 >> #1 0x7f343ca69bb5 in __GI___pthread_mutex_lock ( >> mutex=mutex@entry=0x7f343d4f0f40 ) >>

Re: Immediate doubles (up to 2^256) and rationals coming to Guile 3

Mark H Weaver writes: > Here's the format of fixrats on 64-bit systems: > > Srrx0111 > |\/\___/\__/ > | | |

Re: GNU Guile 2.9.2 Released [beta]

Hi Andy, I finally got a chance to look closely at your recent work on Guile 3, and I just wanted to say that the code looks great, a pleasure to read and hack on. Thanks again for your sustained injection of awesomeness into Guile and our community. I probably don't say that enough. Mark

Re: Immediate doubles (up to 2^256) and rationals coming to Guile 3

Hi Ludovic, Ludovic Courtès writes: > As Dave Thompson wrote on IRC yesterday, this can make a significant > difference for applications such as graphics and game engines. Yes, it's especially important to be able to avoid heap allocation in games, where GC pauses can be painful. However, any a

Re: Immediate doubles (up to 2^256) and rationals coming to Guile 3

I should mention that I'm very open to suggestions Andy might have about any of this. The new approach I'm currently working on with tagged pair pointers requires changes to both the VM and the compiler, and I'm not confident that I've made the best choices there. I've made some preliminary choic

Re: Immediate doubles (up to 2^256) and rationals coming to Guile 3

Hi Ludovic, Ludovic Courtès writes: > Though an immediate, like a fixnum or an iflo, is still something > different from a tagged heap object like a pair, right? So I would > expect SCM_THOB_P to be a different test, not a drop-in replacement for > SCM_NIMP, is that correct? That's right. It's

  1   2   3   4   5   6   7   8   9   10   >