Re: [PATCH] Fix string prefix predicate in breadline egg

[Vasilij Schneidermann]

Hello siiky,

> In breadline's Scheme completion code, a length argument is given to
> substring=? that may be greater than the candidate string. This was
> previously unnoticed because substring=? did not check bounds; in the
> latest CHICKEN from master it results in an error.

thank you for the patch, I've applied it to the master branch for now.

Cheers
Vasilij


signature.asc
Description: PGP signature

[PATCH] #1779 reverse-list->string not exported by srfi-13 egg

[Vasilij Schneidermann]

Hello everyone,

Here's a trivial patch to fix #1779.

Vasilij
From d532f494346f010174e5bbb204aacacc9da16ebe Mon Sep 17 00:00:00 2001
From: Vasilij Schneidermann 
Date: Sun, 29 Aug 2021 21:14:02 +0200
Subject: [PATCH] Add missing reverse-list->string export

---
 srfi-13/0.3.1/srfi-13.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/srfi-13/0.3.1/srfi-13.scm b/srfi-13/0.3.1/srfi-13.scm
index 3b6a461..6d67e0f 100644
--- a/srfi-13/0.3.1/srfi-13.scm
+++ b/srfi-13/0.3.1/srfi-13.scm
@@ -10,6 +10,7 @@
  let-string-start+end
  kmp-step
  make-kmp-restart-vector
+ reverse-list->string
  string->list
  string-any
  string-append/shared
-- 
2.32.0



signature.asc
Description: PGP signature

[PATCH] Small chicken.h fix to make taglib compile on MinGW

[Vasilij Schneidermann]

Hello everyone,

I've tried installing the taglib egg on my MinGW setup today and found
that including chicken.h in C++ mode fails with "invalid conversion from
'void*' to 'char*' [-fpermissive]". The included patch fixes this
problem.

Vasilij
From 8c6be4bfbc07ac9255a2da2b9c3bca1cdd336e50 Mon Sep 17 00:00:00 2001
From: Vasilij Schneidermann 
Date: Mon, 19 Apr 2021 19:11:20 +0200
Subject: [PATCH] Cast the alloca result to make C++ on MinGW happy

---
 chicken.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/chicken.h b/chicken.h
index 0b9c2613..7e51a38f 100644
--- a/chicken.h
+++ b/chicken.h
@@ -3523,7 +3523,7 @@ inline static int C_stat(const char *path, struct stat 
*buf)
 goto dircheck;
 
   if(slash && errno == ENOENT) {
-C_strlcpy((str = C_alloca(len + 1)), path, len + 1);
+C_strlcpy((str = (char *)C_alloca(len + 1)), path, len + 1);
 while(len > 1 && C_strchr("\\/", path[--len]))
   str[len] = '\0';
 if(stat(str, buf) == 0)
-- 
2.31.1



signature.asc
Description: PGP signature

Re: Default file creation mode for core/scsh-process sets executable bit

[Vasilij Schneidermann]

Hello Evan,

> I have created a change request and patch for this here:
> 
>   https://bugs.call-cc.org/ticket/1698

I've added another patch for scsh-process there which resolves the issue for
me.

Vasilij


signature.asc
Description: PGP signature

Conversion from invalid to valid utf8 strings

[Vasilij Schneidermann]

Hello,

I'm currently writing a Git repository viewer and stumbled upon this wonderful
repository with challenging file names [1].  After writing some code to
correctly encode links and labels I've realized that encoding UTF-8 strings
will incorrectly escape bytes inside sequences that correspond to non-ASCII
characters.  Therefore I've added an `(import utf8)` to my code and ran into a
hang when processing the filename consisting of all valid path characters.  See
the attachment for a minified example reproducing the hang.

Judging from ticket #1182 `string-length` hanging on an invalid utf8 string is
not considered an error and it's expected to use the (seemingly undocumented?)
`valid-string?` procedure first.  An alternative way of dealing with such
strings is encoding every invalid byte sequence using a replacement character
like \uFFFD.  I've added such a helper procedure to the attachment as well and
would be happy about feedback to further improve it and whether it's considered
useful enough for inclusion into the utf8 egg.

[1]: https://bitbucket.org/emg/tidbits/src/master/evilfiles/


test.scm
Description: Lotus Screencam


signature.asc
Description: PGP signature

Default file creation mode for core/scsh-process sets executable bit

[Vasilij Schneidermann]

Hello,

I've noticed that when using process redirection in the scsh-process egg,
they're always marked as executable.  Observe:

^_^ csi -R scsh-process -e '(run (ls -l) (> ls.txt))'
^_^ ls -l ls.txt 
-rwxr--r-- 1 wasa wasa 515 May  7 16:34 ls.txt

I've checked the output of `umask` and it's 022, meaning that the mode should
be `0777 & !022` for directories and `0666 & !022` for files, which are 0755
and 0644 respectively.  Digging a bit further this appears to be the fault of
scsh-process using `file-open` without the optional mode argument which
otherwise defaults to 0744 in posixunix.scm.  This is inconsistent with the
behavior of other procedures such as `open-output-file` (0644).

Which of the following options would you prefer?

1. Patching scsh-process to pass the correct file mask when using `file-open`.
2. Patching posixunix.scm to calculate a better default.

Vasilij


signature.asc
Description: PGP signature

Re: Exposing subsecond precision in current-seconds

[Vasilij Schneidermann]

On 04/29/20 at 06:38pm, Evan Hanson wrote:
> On 2020-04-27 21:26, felix.winkelm...@bevuta.com wrote:
> > > - Add a new procedure in `(chicken time)` or `(chicken time posix)` that 
> > > gives
> > >   you both seconds and nanoseconds, be it as values, list, vector, ...  
> > > Same
> > >   Windows considerations as previously apply.
> > 
> > Probably the best solution, I guess something based on "clock_gettime"
> > is the most precise and portable method, even though it may need librt on
> > some platforms.
> 
> This seems best to me as well.

Thanks for the considerations.  I could imagine going with the following API 
based on SRFI-174, with `current-time` returning timespec records:

(import (chicken base))
(import (chicken time posix))
(define now (current-time))
(print "Current time: " (timespec->inexact now))
(print "Current time: " (timespec-seconds now) "." (timespec-nanoseconds 
now))

Implementing the remaining parts of it should be no problem, the most tricky
part of it might be the `timespac-hash` procedure.  That way we'd have another
supported SRFI.

Vasilij


signature.asc
Description: PGP signature

Re: Exposing subsecond precision in current-seconds

[Vasilij Schneidermann]

Hello again,

Sorry, I meant to write microseconds.  For nanoseconds precision you'd need to
use `clock_gettime` which is harder to emulate on Windows than `gettimeofday`.
I also forgot including this reference: 


Vasilij


signature.asc
Description: PGP signature

Exposing subsecond precision in current-seconds

[Vasilij Schneidermann]

Hello,

Today on #chicken I've been reminded that `current-seconds` is unsuitable for
obtaining timestamps with millisecond precision.  Then there is
`current-milliseconds` which returns milliseconds since the process / OS start.
One might be tempted to combine both (as SRFI-19) does, but this is incorrect
as they have different offsets and there will be an unknown error up to a full
second.  Looking at the definition of both, `current-seconds` is using
`gettimeofday` on POSIX platforms which supports up to nanoseconds precision,
then discards it.  I can think of a few possible ways to improve this:

- Change `current-seconds` to use `gettimeofday` in a way that combines both
  seconds and nanoseconds into a double (that should be plenty precision).  On
  Windows a replacement could be defined like with PostgreSQL [1].  Or maybe
  don't bother giving Windows users an enhanced experience and return an
  integer here.
- Add a new procedure in `(chicken time)` or `(chicken time posix)` that gives
  you both seconds and nanoseconds, be it as values, list, vector, ...  Same
  Windows considerations as previously apply.
- Bonus: Make `current-seconds` return two values, the seconds and nanoseconds.
  Previously written code should continue to function unchanged.  I don't
  really like this idea though, it's a bit too magic and kind of cumbersome
  to use.

Vasilij


signature.asc
Description: PGP signature

Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling

[Vasilij Schneidermann]

Hello Matt,

> NOTE: Aside from the effort in porting the code there are still a few
> dependencies on eggs that have not been ported. Triming dependencies
> may eliminate some of these. A quick crude scan of use statements gave
> me this: [...]

I've ported the hostinfo egg and sent a patch to Jim, haven't heard back
from him yet.  There should be no need to port ports and tcp as they are
units in C4, not eggs.  I remember working on the csv or csv-xml egg,
but cannot find any evidence towards this.  If you need porting help,
feel free to let the mailing list know.

Vasilij


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] possible bug in simple-sha1

[Vasilij Schneidermann]

Hello Kristian,

I'd rather not reuse that file as is because who knows what other edits
they made.  Another thing to consider is that we most certainly made at
least one of our own adjustments, like using the C_LITTLE_ENDIAN feature
to detect the endianness instead of BYTE_ORDER.  For this reason I've
attached a three-line patch to my previous email, it should be easy to
apply with both `git` and `patch`.

Vasilij


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] possible bug in simple-sha1

[Vasilij Schneidermann]

Hello Kristian,

I cannot reproduce the bug if I use sha1-base.c directly with a C
program that feeds small chunks instead of doing it in one go.  florz
pointed out a dodgy piece of code in the SHA1Update function, I've
updated it to the latest version found on GitHub [1] and the bug went
away.

You'll also want to update the sha1 egg while you're at it.  Peter Bex
pointed out it's using the same sha1-base.c file, the fix should apply
for it as well.

Vasilij

[1]: https://raw.githubusercontent.com/clibs/sha1/master/sha1.c
From 035522f8c742a0cfe3413570173da4818d6088dc Mon Sep 17 00:00:00 2001
From: Vasilij Schneidermann 
Date: Sun, 2 Jun 2019 18:08:16 +0200
Subject: [PATCH] Increment counter correctly for large len values

---
 sha1-base.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sha1-base.c b/sha1-base.c
index 545ac04..ca64e8c 100644
--- a/sha1-base.c
+++ b/sha1-base.c
@@ -134,7 +134,8 @@ SHA1Update(SHA1_CTX *context, const uint8_t *data, size_t 
len)
 
 j = context->count[0];
 if ((context->count[0] += len << 3) < j)
-   context->count[1] += (len>>29)+1;
+context->count[1]++;
+context->count[1] += len >> 29;
 j = (j >> 3) & 63;
 if ((j + len) > 63) {
i = 64 - j;
-- 
2.21.0



signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Some questions about CHICKEN 5 eggs and modules

[Vasilij Schneidermann]

> So the basic problem is to install multiple sets of files, in separate
> steps? I think for "scheme-include" components this should be possible,
> but (as far as I can see) this is not currently possible for "c-include"
> components (but could be added).

It's for more than that.  SPOCK for instance installs its Scheme *and*
JS runtime into PREFIX/lib/chicken/8/spock/.  The latter is neither a
scheme-include nor a c-include.  Feathers installs itself into
PREFIX/share/chicken/feathers.tcl.  I'm not sure what I'd categorize
these as, but I suspect these eggs cannot be ported until you can
specify a PREFIX-relative destination directory (as opposed to
specifying the type of file to be installed).

Vasilij

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] C lost -D on chicken-install

[Vasilij Schneidermann]

Hey Peter,

> I didn't even know the old chicken-install even had that.  What do you
> use it for?

The opengl-glew egg uses it to conditionally build with GLES support.
There should be more eggs, but it's tricky to tell which.

> It doesn't seem very discoverable to me (for users) [...]

Agreed, the only way to find out is studying the documentation of the
egg closely.  Maybe looking for unusual cond-expand forms.

> "everyone" is a bit strong; we already have 144 eggs that have been ported,
> some of which are quite complex, and so far I haven't heard this complaint.

I've expected to eventually run into this and even planned on eventually
using the feature.  Then I found that it's mostly useless to me as I
only use Linux these days and haven't run into a different usecase for
conditional compilation so far.

Vasilij

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] csc-options in .eg file

[Vasilij Schneidermann]

Hey Jörg

> Any reasons this is not a good idea (TM).

The string syntax allows things such as easily specifying several
libraries to link.  Compare ("-L" "-lfoo -lbar") with (-L -lfoo -lbar).
The latter is an error as it's interpreted as three separate arguments
and the -l invocation syntax has been deprecated.  I'd therefore
vote for keeping the string syntax in any case.

Vasilij

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Introduce XDG directories

[Vasilij Schneidermann]

Hello Kooda,

> This patch is about using the XDG spec for configuration and cache
> directories (XDG_CONFIG_HOME and XDG_CACHE_HOME
> environment variables).

thanks for working on this ticket! Patch looks good, I believe the only
improvements possible are about handling errors (such as XDG_CONFIG_HOME
set to a relative path which is why the code snippet I've attached to
the ticket tests that the path starts with a slash) and being more
user-friendly (the basedir spec suggest creating non-existent
directories when writing a file).

Vasilij

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] )PATCH( Lookup program argument to feathers properly and show error on failure

[Vasilij Schneidermann]

Hello all,

I've tested the patch with chicken-4 and it works as described for me,
both for programs found and not found.

Vasilij

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers