Re: [PATCH] Fix error messages containing format strings

[lloda]

> On 23 Apr 2024, at 10:54, Michael Käppler  wrote:
> 
> Hi all,
> I recently posted a bug report together with a patch to bug-guile, but
> received no response at all:
> 
> https://lists.gnu.org/archive/html/bug-guile/2024-04/msg0.html
> 
> I don't know what the preferred way of reporting bugs and proposing
> patches for Guile is, so
> I'm retrying here on guile-devel.

Hi Michael,

Thanks for looking at this. I think it might be cleaner to use something like

(define (error/args fmt . args)
  (error (apply simple-format #f  fmt args)))

instead of repeating the pattern every time.

On the other hand it's bad to add more definitions to (ice-9 boot) since 
they're globally visible. Maybe someone else can suggest a better solution.

regards

  Daniel

Re: Close 10519, and, how to close bug on debbugs?

[lloda]

> On 18 Jul 2023, at 18:20, Mike Gran  wrote:
> 
> Hi,
> 
> I was looking at https://debbugs.gnu.org/db/pa/lguile.html
> and saw that 10519 (add mini-gmp) should be closed.
> 
> How do you actually close a bug?
> 
> Thanks,
> Mike Gran

An email to -done @ debbugs.gnu.org will close the bug. This is explained 
in https://elpa.gnu.org/packages/doc/debbugs-ug.html

Regards

  Daniel

Re: Add internal definitions to derived forms

[lloda]

Guile already allows mixed definitions and expressions in let bodies (since 
2.9.4), which isn't in any of the Scheme reports. It's up to authors to avoid 
or isolate Guile extensions if they want to remain rnrs compatible, and this 
patch doesn't change that.

Being able to put definitions in the body of let but not in the bodies of these 
other forms is an artificial restriction. Some forms still aren't fixed, like 
match. I believe we should eventually fix those as well.

I think the root of the issue is (begin), but the patch goes in the right 
direction.

Regards

  Daniel

Re: Add internal definitions to derived forms

[lloda]

> On 24 Jan 2023, at 10:02, Ludovic Courtès  wrote:
> 
> Hi!
> 
> lloda  skribis:
> 
>>>> @lisp
>>>> -(@var{test} @var{body} @dots{})
>>>> +(@var{test} @var{body})
>>> 
>>> I think removing dots is incorrect here because it suggests, according
>>> to the typographic conventions used in the document, that there can only
>>> be a single expression.
> 
> [...]
> 
>> This was actually the main thing I wanted to fix in this patch. Linus' patch 
>> had ‘body ...’ but that clearly means ‘zero or more bodies’, which doesn't 
>> work because there's exactly one ‘body’. I.e. ‘body’ isn't an expression 
>> that is tagged ‘body’, it's, well, a ‘body’.
> 
> Yeah, ‘body’ is a bit confusing here; in the example above, I’d have
> written:
> 
>  (@var{test} @var{exp} @dots{})
> 
> because that’s what the “body” is: one or more expressions.

Hmm, it would seem so, but the way the Scheme reports use ‘expression’, it's 
not.

I've added an explicit definition of what the let-expression body is in the 
updated patch, I hope that reads better. Also tried to address your other 
comments.
 
Thanks

  Daniel

>> The Scheme reports use one ‘’ and no dots in all these definitions. 
>> See also the definition of let in the linked section ‘Local Bindings’, which 
>> again uses ‘body’ and no dots. I hoped that section would count as 
>> definition of ‘body’, and the section on ‘Internal Definitions’ explains 
>> precisely what can go into ‘body’, so I linked to that as well. I see that 
>> isn't clear enough. Maybe ‘body’ should be explicitly defined in one of 
>> these sections?
> 
> Damn it, I hadn’t realized this was a widespread convention, but yeah,
> R5RS and parts of the Guile manual follow this convention.  So hmm, the
> change you propose makes a lot of sense to me now.
> 
> So yeah overall I guess we should always write one of:
> 
>  (something @var{body})
> 
> or:
> 
>  (something @var{exp} @dots{})
> 
> Using @var{body} like you do in this patch is consistent with other
> parts of the manual, so it LGTM.
> 
> Thanks,
> Ludo’.



0002-Document-multiple-value-returns-in-forms-taking-a-le.patch
Description: Binary data

Re: Add internal definitions to derived forms

[lloda]

Hi Ludovic,

> On 23 Jan 2023, at 23:13, Ludovic Courtès  wrote:
> 
> Hi Daniel,
> 
> Chiming in late in the discussion…
> 
> lloda  skribis:
> 
>> From 7aea299373f7370f31c9701035260ad412763724 Mon Sep 17 00:00:00 2001
>> From: Daniel Llorens 
>> Date: Thu, 19 Jan 2023 16:23:29 +0100
>> Subject: [PATCH 2/2] Fix documentation for forms taking lambda-like bodies
>> 
>> * doc/ref/api-control.texi (Conditionals): Use 'body' in the syntax
>>  description of when, unless, cond, case.
>> * doc/ref/api-binding.texi (Local Bindings): Normalize description of
>>  body return values.
>>  (Multiple values): Normalize use of 'body' and description of body
>>  return values.
> 
> What about:
> s/Fix documentation…/doc: Document multiple-value returns in let, cond, etc./
> ?
> 
> (That would clarify what’s being fixed.)

Ok.

> 
>> +++ b/doc/ref/api-binding.texi
>> @@ -128,6 +128,8 @@ expressions has a few properties which are well worth 
>> knowing.
>> 
>> The most basic local binding construct is @code{let}.
>> 
>> +@cindex body
> 
> That’s not a great index entry because there’s no context.  Maybe:
> 
>  @cindex body, of a @code{let} expression
> 
> ?

Ok. I think the word is only used in this sense in the manual, but it might too 
generic to be used alone.

>> +with the special forms @code{when} and @code{unless}.  As an added
>> +bonus, these forms take a @ref{Local Bindings,lambda-like body}, which can
>> +contain @ref{Internal Definitions,internal definitions} and multiple 
>> statements
>> +to evaluate.
> 
> “Lambda-like body” is not defined; I guess it’s “lambda-like” in the
> wrt. to local ‘define’, but it’s not “lambda-like” for the more crucial
> aspect of defining a procedure, so I’d avoid that phrase.  WDYT?

Yes, I thought lambda-like was a tad distracting, so I went with 'body' alone...

> Also, @ref in the middle of sentences may render poorly in Info (info
> "(texinfo) @ref").  I’d suggest “(@pxref{Whatever})” at the end of the
> sentence or proposition.

Ok.

>> Each @code{cond}-clause must look like this:
>> 
>> @lisp
>> -(@var{test} @var{body} @dots{})
>> +(@var{test} @var{body})
> 
> I think removing dots is incorrect here because it suggests, according
> to the typographic conventions used in the document, that there can only
> be a single expression.
> 
>> @var{key} may be any expression, and the @var{clause}s must have the form
>> 
>> @lisp
>> -((@var{datum1} @dots{}) @var{body} @dots{})
>> +((@var{datum1} @dots{}) @var{body})
> 
> Ditto.
> 
>> and the last @var{clause} may have the form
>> 
>> @lisp
>> -(else @var{expr1} @var{body} @dots{})
>> +(else @var{body})
> 
> Ditto.
> 
>> -@deffn {library syntax} receive formals expr body @dots{}
>> +@deffn {library syntax} receive formals expr body
> 
> Likewise.

This was actually the main thing I wanted to fix in this patch. Linus' patch 
had ‘body ...’ but that clearly means ‘zero or more bodies’, which doesn't work 
because there's exactly one ‘body’. I.e. ‘body’ isn't an expression that is 
tagged ‘body’, it's, well, a ‘body’.

The Scheme reports use one ‘’ and no dots in all these definitions. See 
also the definition of let in the linked section ‘Local Bindings’, which again 
uses ‘body’ and no dots. I hoped that section would count as definition of 
‘body’, and the section on ‘Internal Definitions’ explains precisely what can 
go into ‘body’, so I linked to that as well. I see that isn't clear enough. 
Maybe ‘body’ should be explicitly defined in one of these sections?

> Otherwise LGTM; it’s certainly an improvement to have multiple-value
> returns properly documented!
> 
> Thanks,
> Ludo’.

Re: GNU Guile 3.0.9rc1 available for testing!

[lloda]

lgtm, no other issues on mac os.

thanks

  Daniel

Re: GNU Guile 3.0.9rc1 available for testing!

[lloda]

This looks like https://debbugs.gnu.org/60971  
on mac os.

Regards

Daniel

Re: Add internal definitions to derived forms

[lloda]

> On 19 Jan 2023, at 18:54, lloda  wrote:
> 
> Attached a patch that applies after yours and refers to the explanation of 
> bodies elsewhere in the manual. Wdyt?

Second version, fixes text for the same type of body for other forms.

Regards

  Daniel



0002-Fix-documentation-for-forms-taking-lambda-like-bodie.patch
Description: Binary data

Re: Add internal definitions to derived forms

[lloda]

Attached a patch that applies after yours and refers to the explanation of 
bodies elsewhere in the manual. Wdyt?

Regards

 Daniel




0001-Fix-doc-for-conditional-forms-taking-lambda-like-bod.patch
Description: Binary data

Re: [PATCH] Document R7RS bytevector functions

[lloda]

Hi Ludovic, 

thanks for the review. Second version attached.

> We should keep the manual in sync with docstrings in bytevectors.c.
> 
> Thus, my suggestion would be to not insert comments and footnotes about
> R7RS in the existing sections, but instead to do that in the new section.

Following this, I've removed the footnotes & references to R7RS in the main 
section.

Patch aside:

I still think the links are useful, so I'd like to find a way to put them back. 
I think someone who finds their way into the doc for r6rs bytevector-copy 
should be told that there are in fact different versions of this procedure. 
Just in general, I think there should be many more links in the doc.

Regards

  Daniel




0001-Document-R7RS-functions-related-to-bytevectors.patch
Description: Binary data

[PATCH] Document R7RS bytevector functions

[lloda]

Hi

Right now the manual just mentions (scheme base), but not the contents. This 
patch at least makes sure that at least the bytevector-related R7RS functions 
appear in the index.

The patch documents a first group of purely bytevector functions and a second 
group of binary I/O that are not elsewhere in Guile/R6RS or that exist but have 
different definitions.

Regards

  Daniel




0001-Document-R7RS-functions-related-to-bytevectors.patch
Description: Binary data

Re: [EXT] [PATCH] Add 'bytevector-slice'.

[lloda]

> On 12 Jan 2023, at 23:27, Ludovic Courtès  wrote:
> 
> lloda  skribis:
> 
>>> On 11 Jan 2023, at 18:37, Thompson, David  wrote:
>>> 
>>> On Wed, Jan 11, 2023 at 12:34 PM Ludovic Courtès  wrote:
>>>> 
>>>> What could be convenient though is ‘bytevector-copy’ (no bang), which
>>>> would combine ‘make-bytevector’ + ‘bytevector-copy!’.
>>> 
>>> 'bytevector-copy' already exists, or do you mean some different
>>> implementation of it?
>>> 
>>> - Dave
>> 
>> The current bytevector-copy takes a single argument.
> 
> Right, what I had in mind is one that would take an offset and size; I
> hadn’t realized the name was already taken.
> 
> Thanks,
> Ludo’.

Actually (scheme base) from r7rs already defines (bytevector-copy bytevector 
start end), this is of course r7rs's convention. This is hidden in Guile's 
manual, which only lists the 1-argument version from r6rs.

Re: [EXT] [PATCH] Add 'bytevector-slice'.

[lloda]

> On 11 Jan 2023, at 18:37, Thompson, David  wrote:
> 
> On Wed, Jan 11, 2023 at 12:34 PM Ludovic Courtès  wrote:
>> 
>> What could be convenient though is ‘bytevector-copy’ (no bang), which
>> would combine ‘make-bytevector’ + ‘bytevector-copy!’.
> 
> 'bytevector-copy' already exists, or do you mean some different
> implementation of it?
> 
> - Dave

The current bytevector-copy takes a single argument. I would extend it in the 
same way the srfi4 copy functions were extended recently in the following commit

http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=6be51f9bbf47692ee5747b2cac6b372df65de970
 


Regards

  Daniel

Re: The mysterious ‘SCM_F_BYTEVECTOR_CONTIGUOUS’

[lloda]

> On 11 Jan 2023, at 19:51, lloda  wrote:
> 
> Contiguity is a trivial check.

I mean if bytevectors even had a stride field.

Re: The mysterious ‘SCM_F_BYTEVECTOR_CONTIGUOUS’

[lloda]

I think this flag has no use and you should just remove all references to it 
and deprecate it. Contiguity is a trivial check.

We removed a similar flag in the array type not long ago.

Regards

  Daniel

Re: [PATCH] Recognize LoongArch compilation targets.

[lloda]

Pushed to f3ea8f7fa1d84a559c7bf834fe5b675abe0ae7b8.

Thank you!

Re: [PATCH v3] Add tests for warning locations.

[lloda]

Pushed to 02f69c1d84126c35900c5743a712b1e7d07e449d.

Thank you!

Re: [PATCH] Avoid 'frame-local-ref' errors when printing backtrace.

[lloda]

Pushed to c7fa78fc751eb336bcfafbb5ac59c460ee2c5d7a.

Thank you!

Re: Add internal definitions to derived forms

[lloda]

Hi Linus,

I don't understand the following change since at least one expression is 
required in these clauses.

 @lisp
 (@var{test} => @var{expression})
@@ -217,7 +217,7 @@ result of the @code{cond}-expression.
 @var{key} may be any expression, and the @var{clause}s must have the form
 
 @lisp
-((@var{datum1} @dots{}) @var{expr1} @var{expr2} @dots{})
+((@var{datum1} @dots{}) @var{body} @dots{})
 @end lisp

Regards

  Daniel

Re: [PATCH] Properly display locations in "source vector" form.

[lloda]

Ah this one has been bugging me. Applied in 
eb5ecf4944cd646341f7e47dda5396cf96a4b8a3.

Thank you!

Re: [PATCH] Documentation typo fix

[lloda]

Applied in 68aeffe8dda02ae3248a9fc035cea73384ee7b6c. Thanks!

> On 15 Feb 2022, at 23:40, Vijay Marupudi  wrote:
> 
> Hello!
> 
> I have attached a patch that fixes the simple example of defining (unless
> ...) with a macro.
> 
> ~ Vijay
> 
> From 42c830b3d14106d18df154d9a34fff2a9ffa532e Mon Sep 17 00:00:00 2001
> From: Vijay Marupudi 
> Date: Tue, 15 Feb 2022 17:36:08 -0500
> Subject: [PATCH] Typo fix: Use correct variable name in example
> 
> * doc/ref/api-control.texi
> ---
> doc/ref/api-control.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/ref/api-control.texi b/doc/ref/api-control.texi
> index 9860457fa..88dea5623 100644
> --- a/doc/ref/api-control.texi
> +++ b/doc/ref/api-control.texi
> @@ -154,7 +154,7 @@ documentation:
> (define-syntax-rule (when test stmt stmt* ...)
>   (if test (begin stmt stmt* ...)))
> 
> -(define-syntax-rule (unless condition stmt stmt* ...)
> +(define-syntax-rule (unless test stmt stmt* ...)
>   (if (not test) (begin stmt stmt* ...)))
> @end example
> 
> -- 
> 2.35.1
> 

Re: guile array different than srfi 25

[lloda]

Guile arrays were implemented before srfi-25 existed and aren't supposed to be 
compatible with it. There are many other array srfis all with incompatible 
syntaxes...

However srfi-25 is tiny so it should be really simple to implement it on top of 
Guile arrays. If you or anyone else submits a patch, I'm sure it will be 
considered.

Regards

Daniel


> On 11 Jan 2022, at 12:19, Damien Mattei  wrote:
> 
> hello,
> 
> why guile array differs from SRFI 25:
> make-array syntax :
>  https://www.gnu.org/software/guile/manual/html_node/Array-Procedures.html 
> 
> 
> (make-array 'ho 2 3) ⇒ #2((ho ho ho) (ho ho ho))
> 
> 
> different than srfi 25:
> 
> https://srfi.schemers.org/srfi-25/srfi-25.html 
> 
> 
> (make-array shape obj)
> 
> 
> Returns a newly allocated array whose shape is given by
> shape.  If obj is provided, then each element is
> initialized to it. Otherwise the initial contents of each element is
> unspecified. The array does not retain a dependence to
> shape.
> 
> 
> it creates incompatibilties in code .
> 
> Damien

Re: [PATCH] New function array-mutable?

[lloda]

> On 25 Nov 2021, at 19:56, lloda  wrote:
> 
> 
> 
>> On 25 Nov 2021, at 19:22, Maxime Devos  wrote:
>> 
>> lloda schreef op do 25-11-2021 om 17:40 [+0100]:
>>> +Arrays with empty roots are not considered immutable because
>>> +@code{array-set!} operations with valid indices won't fail (since
>>> there
>>> +are no valid indices).
>>> +
>>> +@example
>>> +(array-mutable? #()) @result{} #t
>>> +@end example
>>> +@end deffn
>> 
>> By this logic, shouldn't empty subarrays (*) with a possibly mutable
>> and non-empty root be considered mutable as well?
>> 
>> (*) called ‘shared arrays’ in the manual
>> 
>> Greetings,
>> Maxime
> 
> That would make sense, I think.
> 
> The test in the patch is the same one that is used to validate 
> array_handle_xxx_writable_elements(), which looks only at the root and not at 
> the array dimensions. Those two tests should be the same, so I'll have to 
> change the test in array_handle_xxx_writable_elements().
> 
> Thanks
> 
>   Daniel

Another option would be to rename the function to array-root-mutable?. Then the 
condition would remain as is. This also makes sense because mutability isn't a 
property of the array descriptor, rather it's a property of the root.

Re: [PATCH] New function array-mutable?

[lloda]

> On 25 Nov 2021, at 19:19, Maxime Devos  wrote:
> 
> lloda schreef op do 25-11-2021 om 17:40 [+0100]:
>> [...]
> 
> Suggestion: add a few tests to test-suite/tests/arrays.test:
> 
> (pass-if-equal "new"
>  #t
>  (array-mutable? (make-array #f '(1 2) '(3 4
> 
> (pass-if-equal "empty (two-dimensional)"
>  #t
>  (array-mutable? (array-copy #1(
> 
> (pass-if-equal "empty (two-dimensional)"
>  #t
>  (array-mutable? (array-copy #2(() ()
> 
> (pass-if-equal "immutable copy"
>  #f
>  (array-mutable? (immutable-array-copy #2((h) (h)
> 
> This requires a currently non-existent procedure ‘make-immutable-
> array’, copying an array into a new immutable array.
> 
> Greetings,
> Maxime

I think literal arrays are always immutable, and one could base the test on 
that.

Is such a function useful in some other context? If one has an array which is 
already immutable, it can be referenced freely and copying it seems 
unnecessary. If one has a mutable array, is there any reason why one would want 
to make an immutable copy?

regards

Daniel

Re: [PATCH] New function array-mutable?

[lloda]

> On 25 Nov 2021, at 19:22, Maxime Devos  wrote:
> 
> lloda schreef op do 25-11-2021 om 17:40 [+0100]:
>> +Arrays with empty roots are not considered immutable because
>> +@code{array-set!} operations with valid indices won't fail (since
>> there
>> +are no valid indices).
>> +
>> +@example
>> +(array-mutable? #()) @result{} #t
>> +@end example
>> +@end deffn
> 
> By this logic, shouldn't empty subarrays (*) with a possibly mutable
> and non-empty root be considered mutable as well?
> 
> (*) called ‘shared arrays’ in the manual
> 
> Greetings,
> Maxime

That would make sense, I think.

The test in the patch is the same one that is used to validate 
array_handle_xxx_writable_elements(), which looks only at the root and not at 
the array dimensions. Those two tests should be the same, so I'll have to 
change the test in array_handle_xxx_writable_elements().

Thanks

Daniel

[PATCH] New function array-mutable?

[lloda]

Doesn't seem there was any simple way to check this from either Scheme or C.




0001-New-function-array-mutable.patch
Description: Binary data

Re: how to submit error in documentation

[lloda]

Hi,

I just fixed this in git, thanks for the report.

But yeah, if you have more, like Arun says, ideally send it to bug-guile. That 
way if no one gets to it immediately at least it will be tracked.

Regards

Daniel

> On 22 Nov 2021, at 11:47, Arun Isaac  wrote:
> 
> 
> Hi Damien,
> 
>> for example here:
>> https://www.gnu.org/software/guile/manual/html_node/while-do.html
>> 
>> the result of :
>> 
>> (do ((i 1 (1+ i))
>> (p 3 (* 3 p)))
>>((> i 4)
>> p)
>>  (format #t "3**~s is ~s\n" i p))
>> 
>> is not 789
>> 
>> but 243:
> 
> Good catch!
> 
>> what it is the good place or way to submit or correct errors and typos in
>> guile documentation?
> 
> You can send a patch (created using `git format-patch') to
> bug-gu...@gnu.org.
> 
> Regards,
> Arun

Re: [PATCH] Support C99 complex types in (system foreign)

[lloda]

Applied with some style changes in 496f69dba2fdf1720b40349932fcdecd444107c3.

[PATCH] Support C99 complex types in (system foreign)

[lloda]

0001-Support-C99-complex-types-in-system-foreign.patch
Description: Binary data

Re: more advanced bytevector => supervectors

[lloda]

A problem is that Guile doesn't really provide a god set of fast rank 1 ops. 
None of them have strides!=1 for example (this is ok for regular vectors, but 
it hurts for general arrays), and some are missing start/end or you have to 
write wrappers yourself, like for the typed vectors (other than u8). So in some 
cases you have to do the loop in Scheme. That's fine when the body of the loop 
is Scheme ops but if it's something like copy or fill it really hurts compared 
to C.


> On 11 Sep 2021, at 19:03, Stefan Israelsson Tampe  
> wrote:
> 
> I did some test ands wingo's superb compiler is about equally fast for a hand 
> made scheme loop as the automatic dispatch for getter and setter. It e.g. can 
> copy from 
> e.g. u8 to i16 in about 100 op's / second using native byte order. However 
> compiling it in C lead to nasty 2 Go ops / second. So for these kind of 
> patterns
> it is still better to work in C as it probaly vectorises the operation quite 
> well. Supervectors supports pushing busy loops to C very well and I will 
> probably 
> enable fast C code for some simple utility ops.
> 
> On Wed, Sep 8, 2021 at 9:18 AM lloda  <mailto:ll...@sarc.name>> wrote:
> 
> 
>> On 8 Sep 2021, at 04:04, Stefan Israelsson Tampe > <mailto:stefan.ita...@gmail.com>> wrote:
>> 
> 
> ...
> 
>> So using get-setter typically means
>> ((get-setter #f bin1 #f 
>>(lambda (set) (set v 2 val)))
>> 
>>#:is-endian 'little  ;; only consider little endian setters like 
>> I know 
>>#:is-unsigned  #t ;; only use unsigned
>>#:is-integer  #t ;; only use integer representations
>>#:is-fixed  #t;; do not use the scm value vector versions
>> )
>> So a version where we only consider handling nonegative integers of up to 
>> 64bit. The gain is faster compilation as this ideom will dispatch
>> between 4 different versions of the the loop lambda and the compiler could 
>> inline all of them or be able to detect the one that are used and hot 
>> compile that version
>> (a feature we do not have yet in guile) now whe you select between a ref and 
>> a set you will similarly end up with 4*4 versions = 16 different loops that. 
>> full versions
>> is very large and a double loop with all featurs consists of (2*2 + 3*2*2*2 
>> + 4 + 1)**2 = 33*33 ~ 1000 versions of the loop which is crazy if we should 
>> expand the loop
>> for all cases in the compilation. Now guile would just use a functional 
>> approach and not expand the loop everywhere. We will have parameterised 
>> versions of
>> libraries so that one can select which versions to compile for. for example 
>> the general functions that performs transform form one supervector to 
>> another is a general
>> ideom that would use the full dispatc which is not practical, 
> 
> I'm curious where you're going with this.
> 
> I implemented something similar (iiuc) in 
> https://github.com/lloda/guile-newra/ 
> <https://github.com/lloda/guile-newra/>, specifically 
> https://github.com/lloda/guile-newra/blob/master/mod/newra/map.scm 
> <https://github.com/lloda/guile-newra/blob/master/mod/newra/map.scm> , where 
> the lookup/set methods are inlined in the loop. The compilation times indeed 
> grow exponentially so I'm forced to have a default 'generic' case. 
> 
> The idea for fixing this was to have some kind of run time compilation cache 
> so only a fixed number of type combinations that actually get used would be 
> compiled, instead of the tensor product of all types. But I haven't figured 
> out, or actually tried to do that yet.
> 
> Regards
>   
>   Daniel
> 

Re: more advanced bytevector => supervectors

[lloda]

> On 8 Sep 2021, at 04:04, Stefan Israelsson Tampe  
> wrote:
> 

...

> So using get-setter typically means
> ((get-setter #f bin1 #f 
>(lambda (set) (set v 2 val)))
> 
>#:is-endian 'little  ;; only consider little endian setters like I 
> know 
>#:is-unsigned  #t ;; only use unsigned
>#:is-integer  #t ;; only use integer representations
>#:is-fixed  #t;; do not use the scm value vector versions
> )
> So a version where we only consider handling nonegative integers of up to 
> 64bit. The gain is faster compilation as this ideom will dispatch
> between 4 different versions of the the loop lambda and the compiler could 
> inline all of them or be able to detect the one that are used and hot compile 
> that version
> (a feature we do not have yet in guile) now whe you select between a ref and 
> a set you will similarly end up with 4*4 versions = 16 different loops that. 
> full versions
> is very large and a double loop with all featurs consists of (2*2 + 3*2*2*2 + 
> 4 + 1)**2 = 33*33 ~ 1000 versions of the loop which is crazy if we should 
> expand the loop
> for all cases in the compilation. Now guile would just use a functional 
> approach and not expand the loop everywhere. We will have parameterised 
> versions of
> libraries so that one can select which versions to compile for. for example 
> the general functions that performs transform form one supervector to another 
> is a general
> ideom that would use the full dispatc which is not practical, 

I'm curious where you're going with this.

I implemented something similar (iiuc) in https://github.com/lloda/guile-newra/ 
<https://github.com/lloda/guile-newra/>, specifically 
https://github.com/lloda/guile-newra/blob/master/mod/newra/map.scm 
<https://github.com/lloda/guile-newra/blob/master/mod/newra/map.scm> , where 
the lookup/set methods are inlined in the loop. The compilation times indeed 
grow exponentially so I'm forced to have a default 'generic' case. 

The idea for fixing this was to have some kind of run time compilation cache so 
only a fixed number of type combinations that actually get used would be 
compiled, instead of the tensor product of all types. But I haven't figured 
out, or actually tried to do that yet.

Regards

Daniel

Re: [PATCH] foreign-library: fix darwin detection

[lloda]

Patch is applied in 1f100a4f20c3a6e57922fb26fce212997e2a03cb, thanks.

However I cannot build Guile on macos at the moment bc of an error in 
lib/basename-lgpl.h, this seems caused by the last gnulib update :-\


> On 2 Sep 2021, at 07:38, Aleix Conchillo Flaqué  wrote:
> 
> Without this change dynamic libraries in macOS are not loaded
> properly. This has happened since 3.0.6.
> 
> scheme@(guile-user)> %host-type
> $1 = "x86_64-apple-darwin20.5.0"
> 
> 
> 
> scheme@(guile-user)> (use-modules (git))
> While compiling expression:
> In procedure git_libgit2_init: Function not implemented
> 
> 
> 
> scheme@(guile-user)> (use-modules (system foreign))
> scheme@(guile-user)> (dynamic-link "/usr/local/lib/libgit2")
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure load-foreign-library: file: "/usr/local/lib/libgit2",
> message: "file not found"
> 
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]>
> 
> 
> 
> After this fix:
> 
> scheme@(guile-user)> (use-modules (system foreign))
> scheme@(guile-user)> (dynamic-link "/usr/local/lib/libgit2")
> $2 = #< filename: "/usr/local/lib/libgit2" handle:
> #>
> 
> On Wed, Sep 1, 2021 at 10:28 PM Aleix Conchillo Flaqué
>  wrote:
>> 
>> * module/system/foreign-library.scm (system-library-extensions): fix
>> darwin host detection. darwin host types have "-darwin" but not
>> "-darwin-".
>> ---
>> module/system/foreign-library.scm | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/module/system/foreign-library.scm 
>> b/module/system/foreign-library.scm
>> index d53e293ef..dc426385f 100644
>> --- a/module/system/foreign-library.scm
>> +++ b/module/system/foreign-library.scm
>> @@ -48,7 +48,7 @@
>> 
>> (define system-library-extensions
>>   (cond
>> -   ((string-contains %host-type "-darwin-")
>> +   ((string-contains %host-type "-darwin")
>> '(".bundle" ".so" ".dylib"))
>>((or (string-contains %host-type "cygwin")
>> (string-contains %host-type "mingw")
>> --
>> 2.33.0
>> 
> 

Re: [PATCH v2] Parse #{{}}# properly.

[lloda]

Applied in c78c130b1ddef6d6c290533f74ce1fbd51a4b19d. Thank you!


> On 20 Jul 2021, at 12:54, Maxime Devos  wrote:
> 
> Maxime Devos schreef op zo 18-07-2021 om 21:47 [+0200]:
>> It turns out that the test fails when the patch
>> is applies to guile@3.0.7.  I'll rebase and try
>> to figure things out.
> 
> With the revised patch, tests succeed and the Guile
> library now compiles successfully.
> 
> Greetings,
> Maxime.
From 40b0b29c05d521cd8901988fa2bc71547f917f48 Mon Sep 17 00:00:00 2001
From: Maxime Devos 
Date: Sun, 18 Jul 2021 19:59:32 +0200
Subject: [PATCH] ice-9/read: Parse #{}}# properly.

This is a regression since Guile 3.0.2 and breaks compilation
of a Guile library.

* module/ice-9/read.scm
  (%read)[read-parenthesized]: When SAW-BRACE? is #t but CH isn't
  #\#, don't eat CH.
* test-suite/tests/reader.test
  ("#{}#): Add four test cases.
---
 module/ice-9/read.scm| 7 +--
 test-suite/tests/reader.test | 5 +
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/module/ice-9/read.scm b/module/ice-9/read.scm
index ac407739f..283933064 100644
--- a/module/ice-9/read.scm
+++ b/module/ice-9/read.scm
@@ -556,12 +556,15 @@
 (string->symbol
  (list->string
   (let lp ((saw-brace? #f))
-(let ((ch (next-not-eof)))
+(let lp/inner ((ch (next-not-eof))
+   (saw-brace? saw-brace?))
   (cond
(saw-brace?
 (if (eqv? ch #\#)
 '()
-(cons #\} (lp #f
+;; Don't eat CH, see
+;; .
+(cons #\} (lp/inner ch #f
((eqv? ch #\})
 (lp #t))
((eqv? ch #\\)
diff --git a/test-suite/tests/reader.test b/test-suite/tests/reader.test
index 1481a0a5d..ad7c6d575 100644
--- a/test-suite/tests/reader.test
+++ b/test-suite/tests/reader.test
@@ -536,6 +536,11 @@
 
 (with-test-prefix "#{}#"
   (pass-if (equal? (read-string "#{}#") '#{}#))
+  ;; See 
+  (pass-if (equal? (read-string "#{}}#") (string->symbol "}")))
+  (pass-if (equal? (read-string "#{}}}#") (string->symbol "}}")))
+  (pass-if (equal? (read-string "#{{}}#") (string->symbol "{}")))
+  (pass-if (equal? (read-string "#{{}b}#") (string->symbol "{}b")))
   (pass-if (not (equal? (read-string "(a #{.}# b)") '(a . b
   (pass-if (equal? (read-string "#{a}#") 'a))
   (pass-if (equal? (read-string "#{a b}#") '#{a b}#))
-- 
2.32.0

Re: Add ‘expt’ to the list of effect-free primitives

[lloda]

Applied to main, thanks.

Re: Unable to build Guile on macOS

[lloda]

> On 9 Apr 2021, at 00:10, Aleix Conchillo Flaqué  wrote:
> 
> On Thu, Apr 8, 2021 at 1:10 PM lloda  wrote:
>> 
>> 
>> 
>>> On 8 Apr 2021, at 06:43, Aleix Conchillo Flaqué  
>>> wrote:
>>> 
>>> The following recent Gnulib commit fixes the issue:
>>> 
>>> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=fc6d7d850bdebfed81e9212910f44edf99dd7743
>>> 
>>> If someone could update Gnulib to a more recent version I'd really
>>> appreciate it.
>>> 
>>> Thanks!
>>> 
>>> Aleix
>> 
>> I pushed an update to branch wip-gnulib-update. Could you give that a try? I 
>> tested on macos 10.15.7 and I had two test failures, in async.test and 
>> filesys.test, but I'm not sure those didn't happen before.  (Everything was 
>> fine on Debian).
>> 
> 
> It builds fine now on macOS 11.2.3. I'm getting 2 errors as well (I
> don't see async.test though):
> 
> FAIL: 00-socket.test: setsockopt AF_INET: IPPROTO_TCP TCP_NODELAY
> FAIL: filesys.test: mkdtemp: invalid template
> 
> 
> Totals for this test run:
> passes: 44240
> failures:   2
> unexpected passes:  0
> expected failures:  24
> unresolved test cases:  70
> untested test cases:1
> unsupported test cases: 1
> errors: 0
> 
> FAIL: check-guile
> ==
> 1 of 1 test failed
> Please report to bug-gu...@gnu.org
> ==


Thanks for checking, for the record, this is what I got myself:

FAIL: 00-socket.test: setsockopt AF_INET: IPPROTO_TCP TCP_NODELAY

ERROR: asyncs.test: preemption via sigprof - arguments: ((wrong-type-arg #f 
"Wrong type (expecting ~A): ~S" ("resumable continuation" #) (#)))

FAIL: filesys.test: mkdtemp: invalid template

Totals for this test run:
passes: 44240
failures:   2
unexpected passes:  0
expected failures:  24
unresolved test cases:  69
untested test cases:1
unsupported test cases: 1
errors: 1

Regards

Daniel

Re: Unable to build Guile on macOS

[lloda]

> On 8 Apr 2021, at 06:43, Aleix Conchillo Flaqué  wrote:
> 
> The following recent Gnulib commit fixes the issue:
> 
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=fc6d7d850bdebfed81e9212910f44edf99dd7743
> 
> If someone could update Gnulib to a more recent version I'd really
> appreciate it.
> 
> Thanks!
> 
> Aleix

I pushed an update to branch wip-gnulib-update. Could you give that a try? I 
tested on macos 10.15.7 and I had two test failures, in async.test and 
filesys.test, but I'm not sure those didn't happen before.  (Everything was 
fine on Debian).

Regards

Daniel


> 
> On Wed, Mar 31, 2021 at 11:25 PM Aleix Conchillo Flaqué
>  wrote:
>> 
>> Hi there,
>> 
>> After this Gnlib update, I am no longer able to build Guile on macOS:
>> 
>> commit a91b95cca2d397c84f8b9bbd602d40209a7092ce
>> 
>> There are other softwares with the same issue:
>> https://www.mail-archive.com/bug-wget@gnu.org/msg09941.html
>> 
>> I haven't had time to see if the issue is fixed already or not.
>> 
>> This is the error I'm getting:
>> 
>>  CC   time_rz.lo
>>  CC   timegm.lo
>>  CC   malloc/dynarray_at_failure.lo
>> In file included from regex.c:74:
>> In file included from ./regexec.c:1362:
>> ./malloc/dynarray-skeleton.c:195:13: error: expected identifier or '('
>> __nonnull ((1))
>>^
>> ./malloc/dynarray-skeleton.c:195:13: error: expected ')'
>> ./malloc/dynarray-skeleton.c:195:12: note: to match this '('
>> __nonnull ((1))
>>   ^
>> ./malloc/dynarray-skeleton.c:205:40: error: expected identifier or '('
>> __attribute_maybe_unused__ __nonnull ((1))
>>   ^
>> ./malloc/dynarray-skeleton.c:205:40: error: expected ')'
>> ./malloc/dynarray-skeleton.c:205:39: note: to match this '('
>> __attribute_maybe_unused__ __nonnull ((1))
>>  ^
> 

Re: [PATCH] Add string-replace-substring to (ice-9 string-fun)

[lloda]

> On 5 Jan 2020, at 13:12, Jan Nieuwenhuizen  wrote:
> 
> Andy Wingo writes:
> 
>> On Fri 20 Dec 2019 18:32, lloda  writes:
>> 
>>> This patch adds string-replace-substring that wingo posted to the
>>> mailing list to (ice-9 strings). This is a commonly used function and a
>>> good implementation isn't trivial, so I think it deserves inclusion.
>> 
>> I didn't know that this module existed :)  Sure, why not.  Please fix
>> the commit message when you push.
> 
> That's great!  This is one of the things that has always amazed and
> annoyed me to be missing and I have written several half-baken
> implementations of it when I needed something like it.
> 
> Would it be too much to ask for some documentation to go with it, so
> that we will be able to find it?

Sure, I'll include that in the fixed patch.

Regards

Daniel

[PATCH] Add string-replace-substring to (ice-9 string-fun)

[lloda]

This patch adds string-replace-substring that wingo posted to the mailing list 
to (ice-9 strings). This is a commonly used function and a good implementation 
isn't trivial, so I think it deserves inclusion.




0001-Add-string-replace-substring-to-ice-9-string-fun.patch
Description: Binary data

[PATCH] Extend-core-vector-fill-to-handle-a-range.patch

[lloda]

This patch moves vector-fill! from srfi-43 into core, replacing the old 
vector-fill!. This is a compatible extension. I haven't touched the C binding 
vector_fill_x, so that is still limited to the full vector.

Regards

Daniel





0002-Extend-core-vector-fill-to-handle-a-range.patch
Description: Binary data