Re: "cannot coerce inexact literal to fixnum"

[Peter Bex]

On Sat, Feb 10, 2024 at 04:07:12PM +0200, Al wrote:
> On 2024-02-10 15:38, Peter Bex wrote:
> 
> > That's because you're using fixnum mode.  As I explained, using literals
> > that might be too large for fixnums break the fixnum mode's premise that
> > everything must be a fixnum.
> 
> Oh. So it refuses to emit C code that might break on 32-bit at runtime
> (silent truncation of atoi result, presumably), preferring instead to
> definitely break during Scheme compilation on any platform. OK, I get the
> rationale.

Yup.  Like I said, it might be doable to add some sort of mode where it
could be used to compile in fixnum mode exclusively for 64-bit
platforms, but someone would have to spend the time to do so.

> > That's because string->number gets constant-folded and evaluated at
> > compile-time.
> 
> Obviously; and I suppose there's no simple way to prevent that for just one
> line, not the entire unit?

Not really.  The foreign-value you've been using is a good hack because
it performs exactly the conversion that you're looking for under the hood.
It also forms an optimization barrier so the constant can't be
precalculated.

Note that foreign-value can still return bignums on 32-bit platforms if
the value doesn't fit in a fixnum (this is done by C_unsigned_int_to_num
in chicken.h) and you're using integer32.  The int32 version doesn't do
this and assumes it'll just fit into a fixnum.

> I did mention twice that I'm using them to implement int->u32.

That should only be needed if you generated values bigger than 32-bit.
Again, these could still be bignums when run on a 32-bit platform
(that's why the return type of s32vector-ref is defined as "integer" and
not "fixnum")

> There are also places where I need to increment-and-wrap int32's by 
> INT32_MIN. I'm
> writing a Forth compiler incidentally (which may or may not have been a good
> idea). I store values in s32vector's, but they get turned into Scheme
> numbers by s32vector-ref. I guess I'd prefer native s32int/u32int types,
> complete with wrap-around and meaningful conversion to Scheme ints, but I
> don't think that exists.

Unfortunately, no.

Another way of accomplishing what you want is to use the fx operations
directly.  AFAICT those aren't constant-folded.

So something like this should work:

(define (->32bit x) (fxand (- (fxshl 1 32) 1) x))

Alternatively, put the conversion code (including big-fixnum literals)
in a separate Scheme file which is compiled *without* fixnum mode, and
call it from the file that is compiled in fixnum mode.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: "cannot coerce inexact literal to fixnum"

[Peter Bex]

On Sat, Feb 10, 2024 at 02:32:16PM +0200, Al wrote:
> That would be fine but where does that happen? csc actually barfs on my
> Scheme code (as per the subject line), instead of emitting C code to
> encode/decode into a string at runtime, as you mention.

That's because you're using fixnum mode.  As I explained, using literals
that might be too large for fixnums break the fixnum mode's premise that
everything must be a fixnum.

> It won't even let me use string->number by hand.

That's because string->number gets constant-folded and evaluated at
compile-time.

> The only thing that worked was
> 
> (cond-expand
>   (csi
>     (define  INT32_MAX  #x7fff)
>     (define  INT32_MIN #x-8000)
>     (define UINT32_MAX  #x)
>     )
>   (else
>     ; chicken csc only does 31-bit literals in fixnum mode
>     (define INT32_MIN  (foreign-value "((int32_t)  0x8000)" integer32))
>     (define INT32_MAX  (foreign-value "((int32_t)  0x7fff)" integer32))
>     (define UINT32_MAX (foreign-value "((uint32_t) 0x)"
> unsigned-integer32))
>     )
>   )

It would help if you tried to explain exactly _what_ you're trying to do
here, instead of _how_ you're trying to do it.  Why do you need these
constants?

> ... and I'm not sure what the implications of using a "foreign value"
> further down in my program are. If I assign them to another variable, does
> that variable also become a "foreign value"?

A foreign value is simply a value that gets calculated using the FFI.
The value itself, once calculated, won't be "special" in any way.  It's
just another fixnum.

> How about if I do (bitwise-and
> IMAX32 int)  to truncate a signed number to unsigned32 (which is what I'm
> actually using them for)?

Again, what are you trying to accomplish?

> > There's (currently) no option to force fixnum mode in a way that ignores
> > the existence 32-bit platforms.  Theoretically, it should be possible to
> > compile your code assuming fixnums (so it emits C integer literals) and
> > make it barf at compilation time if one tried to build for a 32-bit
> > platform using a #ifdef or something.  We just don't have the required
> > code to do this, and I'm not sure this is something we'd all want.
> 
> Well if csc emitted string->number code in fixnum mode when necessary, that
> would at least work.

It does that (more or less), as I explained.  And it *wouldn't* work,
because it can't make the assumption it won't be compiled on a system
that's 32 bits.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: (declare (pure ...))

[Peter Bex]

On Sat, Feb 10, 2024 at 12:24:36PM +, Pietro Cerutti wrote:
> This is not how I reason about referential transparency. It is a property of 
> functions applied to values, not variables.
> The fact that you can define x to different values or even rebind it in the 
> scope of a let binding doesn't make (lambda (x) (+ x 1)) less referentially 
> transparent.
> If you change the value of a slot of a vector, then the vector has a 
> different value than before, even if the same name binds to the value.

This might be true in an abstract sense, but it isn't true for the
CHICKEN type system.  The same vector (e.g. eq? returns #t) is always
the same "value", for purposes of the type system.

It can have different values inside its slots, which is why we have
to differentiate between pure and clean functions (see my other mail).

Cheers,
Peter


signature.asc
Description: PGP signature

Re: (declare (pure ...))

[Peter Bex]

On Sat, Feb 10, 2024 at 11:12:04AM +, siiky via wrote:
> Hi Al,
> 
> > On a practical level, I would be sad if vector-ref, for example, was
> > "impure", and thus compiling a vector-ref invalidated all previously-
> > checked globals for the current scope. Likewise, I would prefer to
> > declare a procedure using vector-ref as pure, to let csc know that it
> > does not modify globals (or the filesystem etc).
> 
> The function vector-ref doesn't stop being pure (i.e. referentially
> transparent) depending how you use it. The function is always referentially
> transparent -- the expression (vector-ref some-global-vec) isn't. Quoting
> from "Functional Programming in C++" by Ivan Čukić:

CHICKEN's type system differentiates between "pure" and "clean".  A "pure"
function has no side effects and will always return the same value given
the same input (excluding the environment).

A "clean" function does not modify any state, but may return different
values at different times depending on the value.

That's why vector-ref is marked as "clean" and not "pure" in types.db.
A procedure like "not" and all type predicates are marked as "pure".

Hope this clears things up a bit!

Cheers,
Peter


signature.asc
Description: PGP signature

Re: "cannot coerce inexact literal to fixnum"

[Peter Bex]

On Sat, Feb 10, 2024 at 08:12:38AM +0200, Al wrote:
> On 2024-02-10 02:42, Al wrote:
> 
> > ... if I enable fixnum, csc chokes on both the third and fourth
> > display's with: "Error: cannot coerce inexact literal `2147483647' to
> > fixnum". It compiles and runs fine if those lines are commented out (or
> > if fixnum is disabled).
> 
> So the error comes from a check for (big-fixnum?) in chicken-core/core.scm.
> It is defined in chicken-core/support.scm:
> 
>  (define (big-fixnum? x) ;; XXX: This should probably be in c-platform
>     (and (fixnum? x)
>  (feature? #:64bit)
>  (or (fx> x 1073741823)
>  (fx< x -1073741824) ) ) )
> 
>   (define (small-bignum? x) ;; XXX: This should probably be in c-platform
>     (and (bignum? x)
>  (not (feature? #:64bit))
>  (fx<= (integer-length x) 62) ) )
> 
> Maybe the condition in big-fixnum should be negated? Apply the restrictive
> #x3fff limit only when NOT (feature? #:64bit) ?

No, this code is correct.  It emits a literal into the C code.  That C code
must be able to be compiled on either 32-bit platforms or 64-bit platforms.

That's why on 64-bit platforms, we can't simply assume that a fixnum is
small enough to fit in a machine word - if the same code will be
compiled on a 32-bit machine it wouldn't fit in a fixnum.  These
so-called "big-fixnums" are compiled into a string literal which gets
decoded on-the-fly at runtime into either a fixnum (on 64-bit) or a
bignum (on 32-bit).

So you see, this wouldn't work with (declare fixnum) mode because that
must be able to assume fixnums throughout, regardless of target platform.

There's (currently) no option to force fixnum mode in a way that ignores
the existence 32-bit platforms.  Theoretically, it should be possible to
compile your code assuming fixnums (so it emits C integer literals) and
make it barf at compilation time if one tried to build for a 32-bit
platform using a #ifdef or something.  We just don't have the required
code to do this, and I'm not sure this is something we'd all want.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: on the distribution of import.so files

[Peter Bex]

On Fri, Jan 12, 2024 at 02:37:03AM +0100, Erica Z wrote:
> hello! i am packaging chicken for a linux distribution, and i have a
> question about the libraries that end in import.so; what is their exact
> role? under which circumstances are they loaded? would they need to be
> available to a distributed program that links to chicken?

Hi Erica,

In normal use, when a program is compiled, it doesn't need the
.import.so files because the import libraries are only consulted to
find out what identifiers are exported by the module being loaded,
and the compiler loads these files when it compiles the program.
In this situation they have a role not unlike header files in C.

The .import.so files are needed when a program dynamically loads a
module.  This happens obviously at the REPL (interactive use) but
there are also some eggs that try to conditionally load extensions,
like for example openssl for optional SSL support.  For such eggs or
programs, the import.so file would still be needed.

Programs that load user code (on a REPL or for configuration purposes)
would also likely need the import.so files, if the user wants to import
modules.

In short, you're probably best off including the import.so files in all
CHICKEN-related packages.

Note that it's also possible to statically compile programs.  In those
cases you wouldn't need *any* .so files.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Deprecated current-milliseconds

[Peter Bex]

On Thu, Dec 07, 2023 at 12:48:34PM +0100, Vasilij Schneidermann wrote:
> Hello,
> 
> the openssl egg does no longer produce the warning in version 2.2.5 by either 
> importing the new or old identifier, depending on whichever is available. 
> Feel free to use that approach in the other egg and consider that it may skew 
> the grep results.

So does the sendfile egg.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: [PATCH] Re: Eggs not installing on msys-mingw32

[Peter Bex]

On Mon, Oct 30, 2023 at 05:45:28PM -0400, Matt Welland wrote:
> Well, maybe there is a silver lining here, I can currently reliably
> reproduce the problem!

That's excellent!  Do you have to do any special steps, or does it
simply always happen?

> One hypothesis I'm looking at is replacing calls using with-input-from-file
> and with-output-to-file with open-*-file ... close loops for the reading
> and creation of the egg-info files.

You're probably on the wrong track there.  AFAICT, egg-info files are
only *created* in the foo.install.sh / foo.install.bat file, at the very
end where (on *nix) it uses cat(1) to write into it.

If the file is already empty, changing how it's read won't make a
difference.

The only way it would fail that I can see is if one presses ^C to abort
installation at a very unlucky time.  This sounds like a race condition
but depending on the shell, it might be that it will process that signal
after evaluating the line that redirects stdout to the egg-info file,
but before actually invoking cat.  Dunno, grasping at straws here :)

Since you're using mingw, it's a UNIX shell at least.  Could you try
inserting a sync(1) call at the end of the .install.sh file to see if
that fixes things?

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Startup failure in Windows XP

[Peter Bex]

On Sat, Oct 21, 2023 at 09:12:08AM -0700, igors wrote:
> Hello!
> chicken 5.x under Windows XP when running, for example csi.exe, error: 
> function GetFinalPathNameByHandle not found, because it appeared in Windows 
> Vista. Is it possible to replace this function, for example with 
> NtQueryInformationFile or something else to be able to run on Windows XP?
> location: posixwin.c -> fd_to_path()

Hello,

According to Wikipedia, "Mainstream support for Windows XP ended on
April 14, 2009, and extended support ended on April 8, 2014".
I don't think it's reasonable to expect support on a system that even
its manufacturer hasn't been willing to support, even for businesses
that were paying for "extended support", for over 9 years.

It sucks, but in this case I'm afraid you're on your own.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Question about how to check a symbol is bound

[Peter Bex]

On Wed, Jun 28, 2023 at 09:32:36PM +0200, felix.winkelm...@bevuta.com wrote:
> But I still think that keeping an expansion/compile-time registry and
> accessing it using procedure macros (via "strip-syntax"ed identifiers
> to drop all renaming artifacts) is a possible solution.

I agree, that's how I would approach it too.
I don't think you need to strip-syntax everything, though.

Alaric, if you provide a stripped down, *actually working* (except for
the bit you're struggling with, of course) piece of code I might be
able to help you there.

Cheers,
Peter 


signature.asc
Description: PGP signature

Re: Question about how to check a symbol is bound

[Peter Bex]

On Fri, Jun 23, 2023 at 04:01:40PM +0800, Pan Xie wrote:
> For example, if I want to do things shown in following codes, it is useful to 
> get the
> interned symbols from their names and also get their bound procedures:

...[code elided]...

> I think it is a very common idiom in languages from Lisp family. So it is 
> important to know
> how to check symbol is bound and get its value. Every scheme implementation 
> means for
> business seriously should have the ability.

That's a bit of a roundabout way of doing things - you're defining a
static record type and then dynamically accessing the fields, which kind
of defeats the point of defining the fields statically.  Your code
*almost* amounts to doing 

 (define (getter f)
   (eval (symbol-append 'egg-info f)))

If the fields are supposed to be dynamic, it'd make more sense to use
a hash table or alist and access the fields that way.

Or, if you insist on using a record type, perhaps a tiny bit of
macrology would help, like so:

 (import (chicken format))

 (define-record egg-info
   name author desc)
 (define (show-egg-info egg)
   (let-syntax ((fields->accessors
 (er-macro-transformer
  (lambda (e r c)
(let ((fields (cdr e))
  (%list (r 'list))
  (%cons (r 'cons)))
  `(,%list ,@(map (lambda (f)
`(,%cons ',f ,(symbol-append 'egg-info- 
f)))
  fields)))
 (for-each (lambda (name)
 (let ((field-name (car name))
   (field-accessor (cdr name)))
  (format #t "~a: ~a~%"
  field-name
  (field-accessor egg
   (fields->accessors name author desc

 (show-egg-info (make-egg-info
 "F-operator"
 "Kon Lovett"
 "Shift/Reset Control Operators"))

This way, you're dynamically generating the code to access the record
type statically and you don't have to do low-level symbol groveling.

In Scheme, identifiers are typically not considered "global" like in
Common Lisp because of the strong module system - they can be imported
under a different name etc.  For instance, I can make a module in which
the "global" variable "list" means something entirely different.

However, CHICKEN does maintain a global symbol table with fully
qualified symbols.  So scheme#list refers to the "global" list procedure
from the "scheme" module.  But again, that's an implementation detail
you don't want to rely on in general.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Question about how to check a symbol is bound

[Peter Bex]

On Fri, Jun 23, 2023 at 03:32:38PM +0800, Pan wrote:
> Ah, that make sense. It seems I can just use the '##sys#slot' procedure to
> accomplish all that tasks.

Please don't use ##sys#slot unless you know what you're doing - the
procedure is unsafe and will cause segmentation faults when used on
non-block objects.  Anything that starts with ##sys# or ##core# etc
is intentionally undocumented because it's not meant for user code.

> Would you please elaborate about the "transformed
> name"?  I see there are codes reference symbols like "##sys#slot" or
> "scheme#list", but I can't find document describe them. Is there any
> document I can look into? More specifically, how can I transfer "list" to
> "scheme#list"? Is there procedure can do that?

scheme#list is the fully qualified symbol that means it's the "list"
procedure from the "scheme" module.  If you do "(import scheme)" and then
just use "list" without prefix, it will get rewritten under the hood.

Again, this is an implementation detail and not meant to be used
directly.

Perhaps if you can explain why you need to know if a symbol is bound or
unbound, we might be able to help you better achieve your goal.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Different versions of syntax-rules

[Peter Bex]

On Thu, Apr 20, 2023 at 11:58:50PM +0200, felix.winkelm...@bevuta.com wrote:
> > Is there a desire to stick to r5rs features only in the chicken-core
> > expander, or is the intention to fold the R7RS / SRFI 46 features back
> > into the chicken-core expander at some point in the future?
> 
> I haven't thought about it, and the extensions for R7RS are from Peter
> (I think). We could add them in a future version of the core system,
> I'd say. Peter, what do you think?

I seem to remember that in R7RS, an underscore matches anything, which
is not entirely compatible with R5RS, where you could actually use an
underscore as a variable name.

Besides that one nitpick, I'd be fine with copying it over to core.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: I'm missing something obvious about (chicken conditions)

[Peter Bex]

On Tue, Mar 07, 2023 at 04:40:15PM -0500, T. Kurt Bond wrote:
> I've got two programs, edited down from other slightly larger programs
> for clarity.  They use condition-case to handle exceptions.  I'm
> interested in handling a (mine) condition and a (mine too)
> differently.  One of the program *does* distinguish between the two
> exceptions; one of them doesn't.  I can't figure out why.

Yeah, took me a while to spot the difference as well.  Let me highlight
the relevant lines:

> (define mine-two (condition '(mine) '(two)))
> 
...
>   (condition-case (thunk)
> [ex (mine too)
> (format #t "This is a (mine too) condition: ~s~%" ex)]
...
> (check (lambda () (signal mine-two)))
> (check (lambda () (signal (condition '(mine) '(two)

Note that in the condition-case you have "mine too", while here it's
"mine two".  One letter difference :)

Cheers,
Peter


signature.asc
Description: PGP signature

Re: mingw32-make: *** [chicken-defaults.h] Error 1

[Peter Bex]

On Wed, Mar 08, 2023 at 01:50:24PM +0800, Patrickpwq wrote:
> and here is my command:
> ```
> C:\Program Files (x86)\chicken-5.3.0mingw32-make PLATFORM=mingw 
> PREFIX="C:\Program Files (x86)\chicken-5.3.0"
> ```
> I wonder where is the problem, I'm a freshman studying CS in China, 
> appreciate your kind help!

Hi Patrickpwq,

Try replacing the backslashes in your paths with forward slashes.
This is a common "gotcha" on Windows (it's mentioned in the README).

Make sure to extract a fresh tarball before changing these options, or
run "make confclean".

Cheers,
Peter


signature.asc
Description: PGP signature

Re: New egg: CHICKEN Transducers

[Peter Bex]

On Wed, Jan 04, 2023 at 06:48:56PM -0700, Jeremy Steward wrote:
> I've been somewhat bothered by the fragmentation in a certain aspect of
> Scheme / Lisp: notably that there isn't really something akin to Rust's
> Iterator trait in Scheme, and as a result working across various collections
> and data types is a pain.

Arguably that's a feature - in Scheme you'll always be sure of the
performance characteristics of the type you're working with, and you'll
always know what type you're working with.  Also, by not having generics
for collection types you avoid quite a performance overhead related to
dispatch. But I understand many people disagree that this is desirable.

> So I introduce to you - Transducers! These are very similar to Clojure's
> transducers, but add one more parameter: a fold procedure. I was unhappy
> with SRFI-158 (Generators & Accumulators) and also unhappy with SRFI-171
> (mostly because of how sparse the API is).

This looks quite nice and well done!

> And I've written a short blog post outlining some of my frustrations that
> led me to writing this egg:
> 
> 

Excellent observations, especially regarding the fold argument inconsistency,
that's so cringeworthy it isn't even funny.  I thoroughly enjoyed reading
the post.  Even if it's critical of Scheme, it's done in a loving way,
as you mention ;)  I also agree with you that SRFI has probably had its
best time.

Besides just being "etched in stone", the SRFI process has been hijacked
by a small group of people and is producing SRFIs at breakneck speed with
perhaps not enough community input.  Usually by the time I learn about a
SRFI about a subject I find interesting, it's already finalized ;)
That makes SRFIs rather "take it or leave it".  And often they're not
especially ergonomic either.

> Happy to engage with the rest of the community on what the next priority for
> such a library should be. My hope is that this library helps us all move
> away from XXX-map and XXX-filter procedures for each individual type.

Well, like I said I kinda prefer having the type-specific procedures.
I rarely deal with situations where I don't know the type on which I'm
operating.  I usually treat generic code with suspicion, as it's not
going to be as fast as it could be, and higher-order code tends to be
more difficult to follow than necessary.

However, transducers offer one thing that the type-specific procedures
do not - pipelining without accumulating lots of intermediate results.
For me that's the killer feature of transducers.
 
> First things first: I'll probably keep trying to add more common data type
> support (SRFI 146 mappings and SRFI 69 hash-tables come to mind) as I can.
> Let me know if you find this useful!

Sounds good - the more native types are supported, the more useful a
"generic" transducer is.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: define-er-syntax* new egg

[Peter Bex]

On Fri, Oct 28, 2022 at 08:50:04AM +0200, Sandra Snan wrote:
> Can any one add https://idiomdrottning.org/define-er-syntax.release-info to 
> egg-locations, please?
> I know that the last three times I asked, I forgot to actually put any 
> releases in there.
> I found them in my fridge next to all the lettuce and pickle jars.
> Thank you♥

Added! Sorry that you had to ask four times, that sucks :(

Cheers,
Peter


signature.asc
Description: PGP signature

Re: http-client egg and authentication

[Peter Bex]

On Mon, Sep 26, 2022 at 12:15:10AM +0200, Christian Himpe wrote:
> Dear All,
> 
> so I found this recent StackOverflow issue: 
> https://stackoverflow.com/questions/72904388/how-do-i-use-http-basic-auth-with-http-client
>  based on which I tried to use `make-uri` and pass the URI record (including 
> credentials) to the http-client. This also gives a 403 reply from the server. 
> I also tried manually encoding `"myuser:mypass"` as base64 without use.

Hi there,

I had a look since I didn't really remember and couldn't get it to work
either.  But after some re-reading of RFC2617, it made sense to me:

Normally, a server should respond with 401 Unauthorized and a
WWW-Authenticate header containing the acceptable authentication types,
and, in case of digest authentication, a challenge.

Given a username and password, http-client can't really (in general)
simply send a basic auth header to the server.  This would be needlessly
insecure in case the server accepts (only) digest auth.  And of course,
sending a digest auth header is impossible since it requires receiving
a challenge nonce first.

So I guess you're (somewhat) out of luck, if your server doesn't
correctly respond with a 401 response on the initial request, you
can't rely on the builtin authentication mechanism.

Instead, you'd have to pass in an intarweb request object instead of an
URI, and construct the Authorization header yourself.

> As a sidenote, using `uri-common`, I was not able to get a slash between port 
> and path from `make-uri`; I had to use `(update-uri (uri-reference ...) ...)`.

You probably forgot to use a list with a slash symbol at the start.
That makes a path absolute.  '(/ "foo" "bar") is /foo/bar, whereas
'("foo" "bar") is foo/bar.  It's a bit awkward, but that's how it works.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: New Egg: TOML wrapper

[Peter Bex]

On Mon, Sep 05, 2022 at 09:53:11PM +0200, Daniel Ziltener wrote:
> Hmm, right... I have never sent in an egg with a submodule. Seems like Gitea
> cannot pack submodules so far. So what I did for now is to add a "generated
> source" to the egg file that triggers a "git clone" of a hardcoded commit of
> tomlc99. I ran "test-new-egg" on it which succeeded. I hope this is an
> acceptable approach?

Not really - that way "chicken-install -retrieve" would be unable to
retrieve the entire sources.  The idea is that chicken-install's build
process should be possible to run entirely offline.

Instead, you could generate the tarballs yourself and host them
somewhere.  Or you could use git's subtree feature instead of submodule,
perhaps Gitea *can* pack those.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Bare-Metal Suitability

[Peter Bex]

On Fri, Jun 24, 2022 at 03:20:36PM -0600, Paul Whittington wrote:
> I'm a total Chicken noob.  Is Chicken suitable for use in bare-metal
> applications?

Hello Paul,

I don't think it's very suitable - CHICKEN relies on libc and most
of POSIX syscalls being present.  Maybe an experienced CHICKEN hacker
might be able to make it work with less stuff, but as a beginner
you're probably better off finding an implementation that requires
less of an OS footprint.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Chicken 5 on Cygwin

[Peter Bex]

On Fri, Mar 04, 2022 at 01:07:21PM -0500, Claude Marinier wrote:
> Allô,
> 
> I see that Cygwin includes Chicken 4. This is not a problem at home where I
> can compile from sources. At work, I am working on approval for Cygwin as a
> whole. It would be nice if Cygwin included Chicken 5.
> 
> Who is responsible for this? Is it the Chicken community?

I think it's the Cygwin project.  We are only responsible for ensuring
that it builds and runs correctly on Cygwin.  But I'm sure they'll
accept a patch if one of us sends it to them.

The real problem is keeping it up to date.  Just updating it to 5.3.0
should be a matter of sending a patch, but keeping it up to date,
following up when things break etc is something that really requires
someone who actively uses CHICKEN from Cygwin.

> Assuming we have to do this ourselves. How difficult is it to upgrade?

Shouldn't be too hard.  Build instructions are almost identical for
CHICKEN 4 and 5.

Cheers,
Peter


signature.asc
Description: PGP signature

[ANN] CHICKEN 5.3.0 has been released

[Peter Bex]

Dear CHICKEN users,

We are pleased to announce the immediate availability of CHICKEN 5.3.0
at the following URL:
https://code.call-cc.org/releases/5.3.0/chicken-5.3.0.tar.gz

This tarball has the following SHA256 checksum:
c3ad99d8f9e17ed810912ef981ac3b0c2e2f46fb0ecc033b5c3b6dca1bdb0d76

This is a bugfix release which fixes several important issues, and
it is highly recommended to update to this version.

Irregex has been updated to the latest upstream (0.9.10), which fixes
a few issues with bol handling and irregex-replace/all with positive
lookbehind replaces all matches rather than just the first.

A few bugs in the module system's handling of reexport have been fixed,
as well as a few bugs in the optimization of using argvector directly
in rest arguments, and a nasty issue where mutated parameters would be
reset if the mutation happened in a signal handler.

A nice improvement is that to build CHICKEN, on most platforms you no
longer need to provide the PLATFORM variable to Make; we auto-detect
the platform you're building on.  Of course, for cross-compilation
you'll still have to set it.

We tweaked the garbage collector to avoid thrashing when the heap was
almost full.  This should drastically improve performance for certain
usage patterns that trigger this pathological behaviour.

Finally, we fixed a few issues on Windows.  There were some misbehaviours
when using a different shell when building core versus during usage and
the test suite now should pass again under Windows.

Thanks to everyone who helped to test this release.

For a full list of the changes since 5.2.0, see the NEWS file:
https://code.call-cc.org/releases/5.3.0/NEWS

Kind regards,
The CHICKEN Team


signature.asc
Description: PGP signature

[ANN] CHICKEN 5.3.0 release candidate 4 available

[Peter Bex]

Hello all,

The fourth release candidate for CHICKEN 5.3.0 is now available for
download:

  https://code.call-cc.org/dev-snapshots/2021/10/06/chicken-5.3.0rc4.tar.gz

The sha256sum of that tarball is:

  ba8da800e708c423c0e6e812fa2a93b947c731e52d115988b0c0f84406040e14

The list of changes since 5.2.0 and 5.3.0rc4 is available here:

  https://code.call-cc.org/dev-snapshots/2021/10/06/NEWS

This release candidate fixes a regression that happened somewhere
between 5.2.0 and 5.3.0 which meant static linking was broken for
programs that used certain builtin modules (#1788).

It also introduces a safety check in the setters for current-user-id,
current-effective-user-id and current-group-id to ensure that only
fixnums are passed in (#1787).

Please give this new release candidate a try and report your findings
to the mailing list.  Here's a suggested test procedure:

  $ make PREFIX= install check
  $ /bin/chicken-install pastiche

If you can, please let us know the following information about the
environment on which you test the RC:

  Operating system: (e.g., FreeBSD 12.0, Debian 9, Windows 10 mingw-msys under 
mingw32)
  Hardware platform: (e.g., x86, x86-64, PPC)
  C Compiler: (e.g., GCC 6.4.0, clang 5.0.0)
  Installation works?: yes or no
  Tests work?: yes or no
  Installation of eggs works?: yes or no

Thanks in advance!

The CHICKEN Team


signature.asc
Description: PGP signature

[ANN] CHICKEN 5.3.0 release candidate 3 available

[Peter Bex]

Hello all,

The third release candidate for CHICKEN 5.3.0 is now available for
download:

  https://code.call-cc.org/dev-snapshots/2021/09/20/chicken-5.3.0rc3.tar.gz

The sha256sum of that tarball is:

  298ad5eab42ea56c3cc3fcc7343a510e0c41fc13d3b5bdd2f4b1a636458f8f67

The list of changes since 5.2.0 and 5.3.0rc3 is available here:

  https://code.call-cc.org/dev-snapshots/2021/09/20/NEWS

This release candidate makes it possible to build with tcc again
and fixes two issues on Windows: egg installation scripts were mixing
uses of msys tools and Windows cmd directives and the test suite has
some failures on Windows.

Please give this new release candidate a try and report your findings
to the mailing list.  Here's a suggested test procedure:

  $ make PREFIX= install check
  $ /bin/chicken-install pastiche

If you can, please let us know the following information about the
environment on which you test the RC:

  Operating system: (e.g., FreeBSD 12.0, Debian 9, Windows 10 mingw-msys under 
mingw32)
  Hardware platform: (e.g., x86, x86-64, PPC)
  C Compiler: (e.g., GCC 6.4.0, clang 5.0.0)
  Installation works?: yes or no
  Tests work?: yes or no
  Installation of eggs works?: yes or no

Thanks in advance!

The CHICKEN Team


signature.asc
Description: PGP signature

Re: Windows vs Linux Performance, windows host 4-6x slower than linux guest vm

[Peter Bex]

On Mon, Sep 06, 2021 at 01:26:26PM +0100, Mark Fisher wrote:
> I'm seeing quite a difference in performance between the two; windows host
> is running about ~4-6x slower than a VM that's running on the same machine.

hm, that's odd indeed.  Perhaps it's something to do with the different C
calling conventions the two OSes use?

I remembered that we used to define C_fcall as __fastcall under Windows
with MSVC back when we still supported it.  That's when x86 was still
very common.  It looks like Mingw also supports it nowadays (or maybe it
always has?)

See also https://docs.microsoft.com/en-us/cpp/cpp/fastcall?view=msvc-160
I don't know if it makes a big difference - that page says it's ignored
by compilers targeting arm or x64 architecture, so maybe it won't buy you
anything.

But if you feel like trying it out, you can add something like the
following to the top of chicken.h (or chicken-config.h):

#define C_fcall __fastcall

and then recompile CHICKEN itself and your code, and see if that makes
a noticable difference.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging

[Peter Bex]

On Fri, Aug 27, 2021 at 08:00:22PM +0100, Mark Fisher wrote:
> I have traced where my copy is crashing, but I don't know why.

Hi Mark,

Could you give 5.3.0rc2 a quick spin?  In it, we've simply
dropped the custom implementation of opendir and readdir.

Also, since it is pre-translated to C, it doesn't need a
preinstalled CHICKEN and any patching, which reduces the
chance of errors due to rebuilding.

Cheers,
Peter


signature.asc
Description: PGP signature

[ANN] CHICKEN 5.3.0 release candidate 2 available

[Peter Bex]

Hello all,

The second release candidate for CHICKEN 5.3.0 is now available for
download:

  https://code.call-cc.org/dev-snapshots/2021/08/31/chicken-5.3.0rc2.tar.gz

The sha256sum of that tarball is:

  1736f68006564c5690ce8f844f1c6052046b0bf15a6436aa2ec0d59534ae608b

The list of changes since 5.2.0 and 5.3.0rc1 is available here:

  https://code.call-cc.org/dev-snapshots/2021/08/31/NEWS

This release candidate fixes two issues: The srfi-17 module had an
incomplete export list, and an issue was found with Windows where
the chicken-install -update-db process would hang.

Please give this new release candidate a try and report your findings
to the mailing list.  Here's a suggested test procedure:

  $ make PREFIX= install check
  $ /bin/chicken-install pastiche

If you can, please let us know the following information about the
environment on which you test the RC:

  Operating system: (e.g., FreeBSD 12.0, Debian 9, Windows 10 mingw-msys under 
mingw32)
  Hardware platform: (e.g., x86, x86-64, PPC)
  C Compiler: (e.g., GCC 6.4.0, clang 5.0.0)
  Installation works?: yes or no
  Tests work?: yes or no
  Installation of eggs works?: yes or no

Thanks in advance!

The CHICKEN Team


signature.asc
Description: PGP signature

Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging

[Peter Bex]

On Thu, Aug 26, 2021 at 01:38:42PM +0100, Mark Fisher wrote:
> I always ran clean/confclean between any builds to regenerate the
> chicken-config file and would
> watch for its generation when I built it, so I don't think it was that.
> I'm pretty sure I never mixed and matched PLATFORM= values between runs,
> and never ran just "mingw".

OK, we can rule that out then.

> This is exactly what I was expecting too, although the "mingw-msys"
> build I would expect to be from a "MSYS2 MinGW 64bit" shell to be
>  specific (as opposed to "MSYS2 MSYS" shell) when running make.

I don't understand what you're getting at here.  Could you clarify?

> I never ran a build from a windows cmd shell, so I don't understand the
> file path/xcopy errors. Interestingly this is one of the problems in
> the chocolatey build, it's using "cp" in a windows cmd shell instead
> of xcopy.

Well, if you build with msys, it expects to be able to use the msys
tools, regardless how the program is being invoked.  Perhaps we need
to make chicken-install be smarter so that it can detect whether it
is being called from CMD or from bash, but that would complicate things
quite a bit.

Perhaps always invoking bash on the generated script explicitly in an
msys build might be a simpler way?

It looks like Chocolatey uses msys2, so it makes sense that it would
emit egg build scripts that rely on msys2 tools.

> Also, I think the platform auto-detection ought to work with 5.3.0,
> > so you don't even need to pass in PLATFORM.
> 
> I only just came across the detect Makefile.
> 
> So, just running make on its own, with no PLATFORM (after running
> clean/confclean).

Yep, that should work.

> - - -  run 1 MSYS2/MINGW64 shell - - -
> shell = MSYS2/MINGW64
> gcc=gcc.exe (Rev5, Built by MSYS2 project) 10.3.0
> make=GNU Make 4.3, Built for x86_64-pc-msys
> 
> make clean confclean
> touch *.scm # force rebuild of c files
> make
> make DESTDIR=/tmp/chicken-build/001 install
> 
> The resultant binary has the following problem (which I've seen before but
> can't remember if I mentioned in this thread):
> 
>  $ /tmp/chicken-build/001/usr/local/bin/chicken-install -update-db
> loading import libraries ...
> generating database ...
> 
> Error: (open-output-file) cannot open file - No such file or directory:
> "/usr/local/lib/chicken/11\\modules.db"
> 
> So it's mixing windows paths in.

It kind of makes sense - there is no default for PREFIX under Windows,
and the /usr/local stuff is all "fake" - not visible to Windows itself,
only within the MSYS tools.

I believe the way we use libc bypasses the msys POSIX directory stuff,
so we don't see /usr/local etc.  I wouldn't worry about the backslash
in the path, that should be fine, as that's Windows' native path
separator.

So perhaps you can retry this same thing, but pass in a PREFIX using a
native Windows path (using a drive letter and slashes instead of
backslashes, like the README says).

> - - -  run  MSYS2 shell - - -

Again, I don't understand how this is different from an MSYS2/MINGW64
shell.

> So currently, I still can't produce working binaries in the MINGW64/MSYS
> environment.
> The `\\` seems to be the problem at the moment.

That's a red herring.  The problem is that there's no /usr/local path
in Windows (it is there in mingw, being faked around by the msys tools,
and that's what throwing you off).

Hope this helps!

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging

[Peter Bex]

On Wed, Aug 25, 2021 at 08:34:47PM +0100, Mark Fisher wrote:
> I've finally been able to get chicken installed and working, but I had to
> pretend to be cygwin.
> I think there's errors in the mingw-msys Makefile, or my assumptions about
> it are wrong.
> I would expect:
>   - "Makefile.mingw" to produce files for MingW64 in a windows cmd shell
>   - "Makefile.mingw-msys" to produce files for MingW64 in msys2 shells
> (bash etc with unix paths)
>   - "Makefile.cygwin" to require some kind of cygwin setup, which I don't
> have

Those assumptions are all correct.  Looking at your other mail, I think I
understand what might be going wrong here.

My guess is that you either tried to use PLATFORM=mingw from an msys
shell (i.e., msys2 bash), which would explain the error about XCOPY,
or you used PLATFORM=... with make, then aborted the compilation and
then switched to a different PLATFORM.  That won't work because the
PLATFORM is written into chicken-config.h.  So it may appear to work
because the build works fine, but the resulting binaries will have
settings wired into them that don't match the platform you're building
for.

Be sure to run the make from the type of shell you want to run the
resulting binaries from.  So mingw-msys from a bash prompt if you
want to use CHICKEN from msys' bash prompt, or plain mingw from a 
Windows CMD prompt if you want to use CHICKEN from that.

Also, I think the platform auto-detection ought to work with 5.3.0,
so you don't even need to pass in PLATFORM.

> I found this site:
> https://github-wiki-see.page/m/accidentalrebel/rebel-game-engine/wiki/Building-and-running-the-engine-for-Windows-%28using-Msys2%29

This is really wrong and I have no idea who came up with this, but the
described actions are mixing up MSYS and Cygwin concepts.  The Makefiles
should be named correct and don't mix things up on the CHICKEN side,
but CHICKEN can't really prevent the user from mixing things up on
their side.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging

[Peter Bex]

On Sat, Aug 21, 2021 at 12:14:51PM +0100, Mark Fisher wrote:
> The compilation works fine, but when I run the install phase, the
> "chicken-install -update-db" just hangs

Hello Mark,

I seem te remember something like this caused by Windows Defender (the
virus scanner thing in Windows).  If you turn it off, does that fix
things?

Also, if you have the time, please try the new 5.3.0 release candidate,
to see if this works better.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: [ANN] CHICKEN 5.3.0 release candidate available

[Peter Bex]

On Sat, Aug 14, 2021 at 08:25:21PM +0200, Sven Hartrumpf wrote:
> Hi.
> 
> The segmentation violation disappeared after cleaning my build script for 
> chicken.
> (It contained an old "-mpreferred-stack-boundary=4" in 
> C_COMPILER_OPTIMIZATION_OPTIONS,
> which I dropped now.)

hm, I have to wonder: why does that break things?

> So, the RC looks good to me.

Thanks for double-checking!

Cheers,
Peter


signature.asc
Description: PGP signature

Re: [ANN] CHICKEN 5.3.0 release candidate available

[Peter Bex]

On Fri, Aug 13, 2021 at 08:18:39AM +0200, Sven Hartrumpf wrote:
> Hi.
> 
> gcc 10.3.0, amd64, Ubuntu 21.04
> 
> I am getting a new "Error: segmentation violation", when I add (time .)
> around my main function mf call:
> (time (mf (cons (car (argv)) (command-line-arguments
> The error happens after this mf call is finished.
> Worked for 5.2 (and earlier).
> 
> I hope someone has a minimal example, because mine is huge.

Hi Sven,

Thanks for testing!

Perhaps you can try compiling CHICKEN with DEBUGBUILD=1 and then
re-compiling and running your program.  This will add lots of
inline checks, making the program run very slowly, but it will
hopefully raise an early error rather than just segfaulting.

This should make it easier to pinpoint where it's going wrong.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: [ANN] CHICKEN 5.3.0 release candidate available

[Peter Bex]

On Thu, Aug 12, 2021 at 09:44:11PM -0300, Ariela Wenner wrote:
> 
> Hi all, I seem to be running into a weird issue with this rc when trying to
> install the pigeon-hole egg (might happen with other eggs too, I tested a 
> bunch
> and it only happened with pigeon-hole though).
> 
> Link to log output:
> https://paste.call-cc.org/paste?id=96c654c6b97cd5268c6006e19c78739e19bbde42

Hi Ariela,

Thanks for testing!

It looks like the problem you ran into is caused by a bug in the egg
that was always there, but got exposed by the changes we made to
topological-sort.  This has already been fixed in the egg's master
branch but there doesn't seem to be a corresponding release for it.

So I just filed this ticket with the egg maintainer:
https://github.com/0-8-15/pigeon-hole/issues/4

Cheers,
Peter


signature.asc
Description: PGP signature

[ANN] CHICKEN 5.3.0 release candidate available

[Peter Bex]

Hello everyone,

We are happy to announce the first release candidate of the upcoming
CHICKEN 5.3.0.

CHICKEN 5.3.0rc1 is now available at this location:
https://code.call-cc.org/dev-snapshots/2021/08/12/chicken-5.3.0rc1.tar.gz

The SHA256 sum of that tarball is
61d59cb4f3ca226995d7dca3510c7a646c2cf1e28ebc771bf6c5177e28d14c81

This is bugfix release which takes care of several important issues.

Irregex has been updated to the latest upstream (0.9.10), which fixes
a few issues with bol handling and irregex-replace/all with positive
lookbehind replaces all matches rather than just the first.

A few bugs in the module system's handling of reexport have been fixed,
as well as a few bugs in the optimization of using argvector directly
in rest arguments, and a nasty issue where mutated parameters would be
reset if the mutation happened in a signal handler.

A nice improvement is that to build CHICKEN, on most platforms you no
longer need to provide the PLATFORM variable to Make; we auto-detect
the platform you're building on.  Of course, for cross-compilation
you'll still have to set it.

Finally, we tweaked the garbage collector to avoid thrashing when the
heap was almost full.  This should drastically improve performance for
certain usage patterns that trigger this pathological behaviour.

The complete list of changes since version 5.2.0 is available here:
https://code.call-cc.org/dev-snapshots/2021/08/12/NEWS

Please give it a test and report your findings to the mailing list.

Here's a suggested test procedure:

  $ make PREFIX= install check
  $ /bin/chicken-install pastiche

If you want to build CHICKEN with a compiler other than the default one,
just use C_COMPILER= (e.g., C_COMPILER=clang) on the make
invocation.

Of course, feel free to explore other supported build options (see the
README file for more information) and actually use CHICKEN 5.3.0rc1 for
your software.

If you can, please let us know the following information about the
environment you tested the RC tarball on:

Operating system: (e.g., FreeBSD 12.0, Debian 9, Windows 10 mingw-msys under 
mingw32)
Hardware platform: (e.g., x86, x86-64, PPC)
C Compiler: (e.g., GCC 6.4.0, clang 5.0.0)
Installation works?: yes or no
Tests work?: yes or no
Installation of eggs works?: yes or no

Thanks in advance!

The CHICKEN Team


signature.asc
Description: PGP signature

Re: Chicken 5 compilation, coerced inexact literal number warning. What am I missing here?

[Peter Bex]

On Wed, Apr 07, 2021 at 10:42:39PM -0700, Matt Welland wrote:
> There is a .h file in hostinfo and I didn't catch the error message.
> Presumably that somehow put the compiler into fixnum mode.

hm, if possible could you figure out what exactly did that?
A C header file shouldn't change the compiler's mode!

Glad to hear you figured out how to solve the issue though!

Cheers,
Peter


signature.asc
Description: PGP signature

Re: port of xml-rpc to Chicken 5

[Peter Bex]

On Wed, Apr 07, 2021 at 06:41:30PM -0700, Chris Brannon wrote:
> Mario Domenech Goulart  writes:
> 
> > Just double-checking to avoid misunderstandings: have you contacted
> > Peter Bex (maintainer of the egg for CHICKEN 4) about taking over the
> > maintenance of xml-rpc?
> 
> Hi Mario,
> I'm sorry; I should have been more explicit about that.  Peter was the
> one who gave me the idea:
> 
> "I would of course accept a patch to port XML-RPC to C5,
> but I'm not using it anymore, so if you'd like to take over maintainership 
> that
> would be even more excellent :)"

Yeah, that was my idea :)

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Chicken 5 compilation, coerced inexact literal number warning. What am I missing here?

[Peter Bex]

On Tue, Apr 06, 2021 at 09:37:32PM -0700, Matt Welland wrote:
> This one I sort of understand but it does seem annoying:
> 
> Warning: coerced inexact literal number `9e+99' to fixnum
> 848859130765266355329578537025198862586562510896759102769772101980841694466750283776

I don't get this, unless I use -fixnum-arithmetic.  The message
is a bit misleading because that number is (obviously) not a fixnum.
However, if I compile it and I get that warning, it errors out with

  Error: [internal compiler error] bad immediate (prepare)

This makes sense because that's not a fixnum.  Maybe something we
could "fix" by making the number overflow, or something.

> but the following I don't understand:
> 
> This line:
> (define megatest-version 1.6584)
> 
> generates this warning:
> Warning: literal is out of range - will be truncated to integer: 1.6584

I don't get that unless I compile with -fixnum-arithmetic.

> But a small test program works fine:
> 
> $ cat testit.scm
> (module testit
> *
> (import scheme)
> (define abc 1.2345)
> )
> 
> (import testit)
> (print (/ abc 2))
> $ csc testit.scm
> $ ./testit
> 0.61725

If I compile that as "csc -fixnum-arithmetic testit.scm" I get the
same warning and it prints zero.  If I compile it without flags,
I get the expected output, like you.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Segmentation Fault with IUP on chicken 5.2.0

[Peter Bex]

On Thu, Feb 25, 2021 at 05:04:14PM -0700, Jeff Moon wrote:
> Any ideas what could be causing this, or what I could do to track
> it down?

Hi Jeff,

This sounds like there might be a bug at the toplevel of IUP, which
might explain why re-importing works (it shouldn't re-evaluate the
toplevel).

There are a few things you can do.

I would first simply run the program under gdb and see if you can track
down in which file and which C function it crashes.  Then, see which
function this corresponds to in the Scheme code.  You will need to
compile IUP with the -k option to keep the generated C sources
(try CSC_OPTIONS=-k on the chicken-install command line).

If that doesn't give you anything useful, you can try using a debugbuild
of CHICKEN.  This includes many extra runtime safety checks which may
cause an earlier crash via an assertion fail.  These checks are done at
the generated C level as well, so again you'll need to compile IUP and
anything related with -k.

To get a debugbuild, recompile CHICKEN itself with DEBUGBUILD=1, install
it somewhere else and then build IUP and your program, then run it.  If
it causes an assertion trigger it will crash with some message like this:

[panic] Low-level type assertion C_blockp((C_word)C_VAL1(C__PREV_TMPST.n1))=#t 
failed at library.c:48051 - execution terminated.

If this is still not useful enough, try running the program under gdb
and put a breakpoint on "usual_panic", then run it again.  This will
give you a stack trace, so hopefully you can tell by the flow of calls
where the program crashed.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Adding deprecation notices to CHICKEN 4 egg docs?

[Peter Bex]

On Tue, Feb 02, 2021 at 02:45:58PM +, Diego wrote:
> > This has now been done. Cheers, Peter
> 
> Thanks! I was thinking relatedly that C5 search results should be preferred 
> over C4 results, and somewhat along the same line, maybe title matches for 
> searches should come up first.
> 
> I'd be willing to give this a shot if someone could point me to where the 
> wiki search is implemented.

Hi Diego,

Sure, this is at
https://bugs.call-cc.org/browser/project/release/5/qwiki/trunk/qwiki-search.scm

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Adding deprecation notices to CHICKEN 4 egg docs?

[Peter Bex]

On Tue, Jan 26, 2021 at 02:24:29PM +0100, Peter Bex wrote:
> I'm thinking, maybe we should do something similar for CHICKEN 4
> documentation now. [...]
> Also I noticed we didn't do this for the manual itself.  I think it's
> a good idea to that now, too.

This has now been done.

Cheers,
Peter


signature.asc
Description: PGP signature

Adding deprecation notices to CHICKEN 4 egg docs?

[Peter Bex]

Hi all,

I've noticed that the documentation for CHICKEN 3 eggs (and also for
CHICKEN 2 eggs, where we have them) contain a "OUTDATED EGG" warning
at the top, to warn people away from them.

I'm thinking, maybe we should do something similar for CHICKEN 4
documentation now.  CHICKEN 5 is now just over 2 years old[1] so it's
about time, even though some eggs may not have been ported yet.

Also I noticed we didn't do this for the manual itself.  I think it's
a good idea to that now, too.

Thoughts?  Comments?

Cheers,
Peter

[1] https://lists.gnu.org/archive/html/chicken-announce/2018-11/msg1.html


signature.asc
Description: PGP signature

Re: freeBSD chicken port

[Peter Bex]

On Thu, Jan 14, 2021 at 08:42:04PM -0700, Duke Normandin wrote:
> > You can see the binaries in /usr/local/bin.
> > chicken5 csc5 and csi5.
> > You can generalize begin using most FreeBSD packages.
> 
> I discovered all of that already! But WHY change from csc and csi
> to csc5 and csi5? So next next Chicken upgrade will be csc6 and
> csi6? Why this complication? Thanks for your input!

Presumably they did this so you can install CHICKEN 4 and 5 alongside.
This is also commonly done by package maintainers for Python 2 and 3,
Perl 4 and 5, and Ruby as well I think.

Given that this is Ports, maybe there's an option you can set during
build to not do that?

Cheers,
Peter


signature.asc
Description: PGP signature

Re: static builds

[Peter Bex]

On Mon, Dec 21, 2020 at 12:24:10PM +0100, Henrik Holst wrote:
> Hi Community
> 
> I am trying to build a static build using the Chicken Scheme compiler.  Is
> it possible to do?

Hi Henrik,

This is possible indeed.  The -static option will only statically
link CHICKEN libraries and extensions (as the manual says).

If you want to link fully statically you can add "-L -static" to
make your intentions known to the OS linker, as well.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Bad request error when using uri-common

[Peter Bex]

On Sun, Sep 20, 2020 at 04:16:55PM +, Brian Hughes wrote:
> This first fragment throws an error:
> 
> (form-urlencoded-separator "&")
> (define foo (make-uri scheme: 'https
>   host: "graph.facebook.com"
>   path: `(,my-facebook-id)
>   query: `[(fields . "name")
>(access_token . ,(get-app-access-
> token))]))

Hi Brian,

The path in the snippet above is not an absolute path.

> (display (with-input-from-request foo #f read-json))
> 
> Output:
> $ csi -s fb.scm 
> 
> Error: (call-with-input-request) Client error: 400 Bad Request: "
> https://graph.facebook.com100055065685451?fields=name_token= >"

Note the missing slash between .com and 100055...

You can fix this by using path: `(/ ,my-facebook-id)

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Using a pipe in chicken 5

[Peter Bex]

On Thu, Aug 06, 2020 at 12:01:40PM +0100, Mark Fisher wrote:
> Hi Chicken Users,
> 
> I'm a new user of chicken, and am using it to learn scheme.

Hello and welcome, Mark!

> I've got an issue with using pipes.
> >From various sources I've created the following example, but when run
> I get an exception.
> 
> ;; example.scm
> (import (chicken process))
> (import (chicken file posix))
> (import srfi-18)
> 
> (let-values ([(in out) (create-pipe)])
>   (print " in: " in)
>   (print "out: " out)
>   (let ([p-out (open-input-file* out)])
> (thread-wait-for-i/o! out #:input)
> (let ([data (read p-out)])
>   (print "data: " data

It looks like you swapped the meaning of in and out; you are trying to
open the "out" descriptor for reading by converting it to an input port.

Try this instead:

(import (chicken process))
(import (chicken file posix))
(import srfi-18)

(let-values ([(in out) (create-pipe)])
  (print " in: " in)
  (print "out: " out)
  (let ([p-in (open-input-file* in)])
(thread-wait-for-i/o! in #:input)
(let ([data (read p-in)])
  (print "data: " data


Cheers,
Peter


signature.asc
Description: PGP signature

Re: chicken.irregex bug with positive lookbehinds

[Peter Bex]

On Fri, Jul 10, 2020 at 09:21:37AM -0400, masukomi wrote:
> Thanks Peter.
> Is there a good/easy way to determine where the source repo is for various
> `chicken.foo` pieces of code?

Not really.  Almost all of the core code is our own.  There are some
srfis which are taken from the reference implementation but then hacked
on a lot.  There are some other bits and pieces taken from other places.
The origin usually is stated in a comment above the code.

Irregex is the only really big piece of code which we import from
elsewhere.

But it's fine to report it to us, we can always decide what needs to
be reported upstream and what doesn't.  It helps that I also have commit
rights to the irregex repo.  We're all one big Schemely family :)

Cheers,
Peter


signature.asc
Description: PGP signature

Re: chicken.irregex bug with positive lookbehinds

[Peter Bex]

On Thu, Jul 09, 2020 at 09:51:51PM -0400, masukomi wrote:
> (If there's a ticketing system I've somehow missed please let me know and
> I'll file this there)

Hi Kay,

Thanks for the report!  I've filed it in the upstream repo for you:

https://github.com/ashinn/irregex/issues/21

We'll also need to fix it in CHICKEN, of course, but the usual workflow
for irregex is to fix it upstream and then merge the change back into
CHICKEN.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: openssl static compile issue

[Peter Bex]

On Tue, May 12, 2020 at 03:07:34PM -0400, nemo1...@gmail.com wrote:
> csc -static filename.scm -L -lssl -L -lcrypto
> 
> which removes all errors and allows the code to compile. However, when ran
> the compiled code generates the following http-client egg error:
> 
> "Unable to connect over HTTPS. To fix this, install the openssl egg and try
> again."
> 
> Can anyone advise on how to properly compile a statically linked binary
> using the openssl egg?

I think this is due to the fact that http-client will dynamically
try to import the openssl library.  This happens through eval, which
means you must also explicitly link in openssl's import library, at
least I *think* that's what's happening here.

Please give that a try.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: CHICKEN 5.2.0 has been released

[Peter Bex]

On Wed, Mar 04, 2020 at 03:20:58PM -0600, Daniel Ortmann wrote:
> make PLATFORM=linux PREFIX=/usr/local/chicken-5.2.0 install
> $ cat /etc/oracle-release
> Oracle Linux Server release 7.7
> $ cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 7.7 (Maipo)

Hi Daniel,

How is the home directory mounted (or the cache dir under it)?
It might be mounted noexec, which can cause this kind of error
(see also https://bugs.call-cc.org/ticket/1218).

I also know RHEL has SELinux enabled by default, which can cause
all sorts of unexplainable issues because it messes with the standard
UNIX permission model.

Cheers,
Peter


signature.asc
Description: PGP signature

CHICKEN 5.2.0 has been released

[Peter Bex]

Dear CHICKEN users,

We are pleased to announce the immediate availability of CHICKEN 5.2.0
at the following URL:
https://code.call-cc.org/releases/5.2.0/chicken-5.2.0.tar.gz

This tarball has the following SHA256 checksum:
819149c8ce7303a9b381d3fdc1d5765c5f9ac4dee6f627d1652f47966a8780fa

This is mostly a maintenance and bugfix release, and it is recommended
to update to this version if you're already running CHICKEN 5.  Of
course, if you're still running CHICKEN 4, now is also a great time to
switch to 5 :)

One important change might cause breakage of existing code: CHICKEN will
now error out when you use -c with multiple files (see #1655 for more
info).

Thanks to everyone who helped to test this release.

For a full list of the changes since 5.1.0, see the NEWS file:
https://code.call-cc.org/releases/5.2.0/NEWS

Kind regards,
The CHICKEN Team


signature.asc
Description: PGP signature

[ANN] CHICKEN 5.2.0 release candidate 2 available

[Peter Bex]

Hello all,

The second release candidate for CHICKEN 5.2.0 is now available for
download:

  https://code.call-cc.org/dev-snapshots/2020/02/16/chicken-5.2.0rc2.tar.gz

The sha256sum of that tarball is:

  27d324b54aeda7163dbdb8a98d973752947e6f472336592435a788b3ba7daff2

The list of changes since 5.1.0 is available here (which is the
same as that of 5.2.0rc1):

  https://code.call-cc.org/dev-snapshots/2020/02/16/NEWS

This release candidate fixes a few build issues found during testing,
and a proper bug that was filed and considered important enough to make
it into the next release:

- A code generation issue was found by Sven Hartrumpf, which caused the
  compiler to emit incorrect C code in certain very specific situation.
- The interpreter would crash on ",r" due to a declaration of flonum
  arithmetic which was invalid.
- The build on Cygwin was broken due to an invalid macro declaration
  of C_mkfifo().
- When compiling with an inline file for cross-module inlining, the
  compiler would insert calls to external static functions (#1665).

Please give this new release candidate a try and report your findings
to the mailing list.  Here's a suggested test procedure:

  $ make PLATFORM= PREFIX= install check
  $ /bin/chicken-install awful

If you can, please let us know the following information about the
environment on which you test the RC:

  Operating system: (e.g., FreeBSD 10.1, Debian 8, Windows 7 mingw-msys)
  Hardware platform: (e.g., x86, x86-64, PPC)
  C Compiler: (e.g., GCC 4.9.2, clang 3.6)
  Installation works?: yes or no
  Tests work?: yes or no
  Installation of eggs works?: yes or no

Thanks everyone!
The CHICKEN Team


signature.asc
Description: PGP signature

Re: csirc when transitioning from chicken 4 to 5

[Peter Bex]

On Wed, Jan 15, 2020 at 11:00:02AM -0700, Matt Welland wrote:
> I have not been able to figure out how to make a .csirc that works for both
> chicken 4 and 5.
> 
> (import (chicken platform)) is not legal for chicken 4 but
> (chicken-version) is not available in chicken 5 until you've done the
> import. Chicken and egg :)

Try cond-expand;

(cond-expand
  (chicken-5
(import (chicken platform)))
  (chicken-4
(use extras)))

Cheers,
Peter


signature.asc
Description: PGP signature

Re: [ANN] CHICKEN 5.2.0 release candidate available

[Peter Bex]

On Wed, Jan 15, 2020 at 08:32:05AM +0100, Sven Hartrumpf wrote:
> Hi.
> 
> The RC1 generates uncompilable C code for my Scheme code.
> This code worked for all previous Chicken versions (tested
> today: 5.1.0).
> If I use csc -O3 (-O2 is ok), I get 19 gcc errors, e.g.
> 
> nallch.c:1395027: error: void value not ignored as it ought to be
>  av2[3]=C_rest_arg_out_of_bounds_error(C_fix(0),C_fix(0),C_fix(0));

Hi Sven,

Thanks for reporting.  I'll try to whip up a minimal test case.  Fixing
shouldn't be too hard (though it is a bit annoying; ideally this should
be both noreturn and void).

Cheers,
Peter


signature.asc
Description: PGP signature

Re: [ANN] CHICKEN 5.2.0 release candidate available

[Peter Bex]

On Sun, Jan 12, 2020 at 01:29:06PM +0100, Peter Bex wrote:
> If you can, please let us know the following information about the
> environment you tested the RC tarball on:

I tested on FreeBSD again.

Works with gcc:

Operating system: FreeBSD 12.0
Hardware platform: x86-64
C Compiler: GCC 9.2.0
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes

And clang also works:

Operating system: FreeBSD 12.0
Hardware platform: x86-64
C Compiler: clang 6.0.1
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes

Cheers,
Peter


signature.asc
Description: PGP signature

[ANN] CHICKEN 5.2.0 release candidate available

[Peter Bex]

Hello everyone,

We are happy to announce the first release candidate of the upcoming
CHICKEN 5.2.0.

CHICKEN 5.2.0rc1 is now available at this location:
https://code.call-cc.org/dev-snapshots/2020/01/12/chicken-5.2.0rc1.tar.gz

The SHA256 sum of that tarball is
bf651739d7b1588b9f8b860975171987cb81566627f6fbcdf956637d35089bdc

This is mostly a maintenance and bugfix release.

One important change might cause breakage of existing code: CHICKEN will
now error out when you use -c with multiple files (see #1655) for more
info.

Another change that might expose bugs in existing code, thereby
possibly breaking it is that modules won't pollute the global namespace
anymore when imported.  This may expose missing imports in macro code,
because an import won't make the imports available for compile-time code.
See #1548 for more info.

The complete list of changes since version 5.1.0 is available here:
https://code.call-cc.org/dev-snapshots/2020/01/12/NEWS

Please give it a test and report your findings to the mailing list.

Here's a suggested test procedure:

  $ make PLATFORM= PREFIX= install check
  $ /bin/chicken-install pastiche

If you want to build CHICKEN with a compiler other than the default one,
just use C_COMPILER= (e.g., C_COMPILER=clang) on the make
invocation.

Of course, feel free to explore other supported build options (see the
README file for more information) and actually use CHICKEN 5.2.0rc1 for
your software.

If you can, please let us know the following information about the
environment you tested the RC tarball on:

Operating system: (e.g., FreeBSD 12.0, Debian 9, Windows 10 mingw-msys under 
mingw32)
Hardware platform: (e.g., x86, x86-64, PPC)
C Compiler: (e.g., GCC 6.4.0, clang 5.0.0)
Installation works?: yes or no
Tests work?: yes or no
Installation of eggs works?: yes or no

Thanks in advance!

The CHICKEN Team


signature.asc
Description: PGP signature

Re: Missing Eggs in Chicken 5

[Peter Bex]

On Fri, Jan 03, 2020 at 09:02:10AM +0100, Peter Bex wrote:
> I'll give porting crypt a shot this weekend.  The build is rather custom
> which can complicate things a bit.

Hi again,

I've ported the egg.  It should be available as version 1.0 of
crypt.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Missing Eggs in Chicken 5

[Peter Bex]

On Thu, Jan 02, 2020 at 11:46:31PM -0700, Jeff Moon wrote:
> Update: We'll be updating the dbi repo.  What do we need to do to get it
> recognized by the chicken 5 eggs system?

Same as for CHICKEN 4: send a message to the list with the release-info
file and someone can add it to the coop.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Missing Eggs in Chicken 5

[Peter Bex]

On Thu, Jan 02, 2020 at 04:49:34PM -0700, Jeff Moon wrote:
> Matt Welland and I are porting some existing code to chicken 5.  We ran
> into some eggs that we are using that we would like in chicken 5:
> 
> csv-xml
> crypt

Hi Jeff,

I'll give porting crypt a shot this weekend.  The build is rather custom
which can complicate things a bit.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Gosling: This year's CHICKEN event

[Peter Bex]

On Thu, Dec 12, 2019 at 07:58:33AM +0100, Kristian Lein-Mathisen wrote:
> Hi everyone!
> 
> I've decided to try to host another Chicken even, and I'm hoping you will
> attend! Please see the wiki for information:
> 
> http://wiki.call-cc.org/event/gosling-2020

I just booked my ticket!  Looking forward to it.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: How to solve this import in an eval problem?

[Peter Bex]

On Mon, Nov 11, 2019 at 10:43:44PM -0700, Matt Welland wrote:
> I'm working toward porting my various projects to chicken 5 and for one
> project I first want to convert a bunch of compilation units to modules.
> This has mostly gone well but I'm stuck on exposing module code in an eval.
> Without modules this worked great as everything was visible to the eval.
> 
> It actually works ok if I run in the directory where the .import.scm file
> lives but fails when the exe is run from a different directory.

Hi Matt,

That makes sense; to import a module at run-time, that module needs to be
available, so it must be in the module search path (which is the chicken lib
dir and the current directory).

I've tried your test case, and tweaked it a bit to make it work on C5.
The way to make this work without requiring the module to be in the search
path would be to bake it into the executable.

To do that, you can compile the import library into a .o file and include
it in the final binary, much like you did with the main code of a.scm.

I added this recipe to the Makefile:

a.import.o: a.import.scm a.o
csc -unit a.import -c a.import.scm -o $*.o

And then I added (declare (uses a.import)) to the top of c.scm to ensure
that the import library's toplevel gets invoked.  Also, add dependencies
as needed for Make to do its thing.

This way, the module registration is also done inside the executable, and
because the module is already known, the run-time import won't cause it to
be looked up at runtime.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: Why has the language reference been removed?

[Peter Bex]

On Sun, Nov 03, 2019 at 07:59:09PM +0100, Kristian Lein-Mathisen wrote:
> Hi Cleverson,
> 
> Oh your're right - I didn't realize there is no
> http://wiki.call-cc.org/man/4/The%20R5RS%20standard equivalent for C5. The
> core team can probably clarify why this is (moving towards R7RS?).

The reason is that we wanted to make it clearer in which module each
identifier occurs (also for the sake of chickadee).

> Meanwhile, maybe http://api.call-cc.org/5/doc/scheme can help you?

This is basically where we moved all the stuff from the old R5RS page.

Cheers,
Peter


signature.asc
Description: PGP signature

Re: [Chicken-users] Debian 9 amd64 chicken-bin 4.11.0-1 cannot import from undefined module process-context

[Peter Bex]

On Tue, Sep 17, 2019 at 11:00:17PM -0700, David Christensen wrote:
> The current release of Chicken appears to be 5.1.0:
> 
> https://code.call-cc.org/

Correct.

> I do not see a Debian backport:
> 
> https://packages.debian.org/search?keywords=chicken=names=all=stretch-backports

Yeah, Debian...  I think I asked for a CHICKEN 5.0.0 port when it came
out but nobody was interested in packaging it.

> Does anyone have any experiencing compiling, installing, and running Chicken
> 5.1.0 from a source tarball on Debian 9?  Can I do this with a normal user
> account?

I used to do it all the time.  I still do, but now I run Debian 10.
You don't need to be root if you set PREFIX to a user-writable directory.

Cheers,
Peter


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

Re: [Chicken-users] on generating types files for compound libraries of multiple modules

[Peter Bex]

On Wed, Aug 14, 2019 at 08:23:51AM +0200, Marco Maggi wrote:
> Ciao,
> 
>   I see  there is  no declaration  specifier for  "-emit-types-file", is
> there   a   reason?I   would   appreciate   something   similar   to
> "emit-import-library".

I don't know, but it might be just a matter of nobody having had a use
case yet.  I've made a ticket for this: https://bugs.call-cc.org/ticket/1644

>   Also: how do  you handle types files for shared  libraries composed by
> multiple modules?   Should I generate a  types file for each  module and
> install all of them along the shared library?  I doubt this is correct.

No, as far as I know you simply load the types database using -types or
-consult-types-file and that accepts any filename.  The core types
database (types.db) also contains type information for several modules.
So when you emit the types file you can just write it to a single file.

Actually, I don't think there's even functionality in place to separate
out the types per module.  So what you're trying to do sounds perfectly
fine.

>   I have shared  libraries with multiple modules compiled  in.  Only one
> module is the "public" one (exporting the public API), the others export
> some "public" syntactic bindings  and some "private" syntactic bindings.
> Is this case currently supported by CHICKEN?

That should be fine.  It's not completely standard, so you might need to
do a few things here and there to make it work, but I don't see any
problem with it.  If you're running into specific problems, let us know
and we'll try to find out what's going wrong.

Cheers,
Peter


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

Re: [Chicken-users] retrieving a structure's symbol name

[Peter Bex]

On Thu, Jul 25, 2019 at 07:36:04AM +0200, Marco Maggi wrote:
> I am writing a library that mimics R6RS records.  Every R6RS record-type
> can  be associated  to a  unique identifier  (UID), which  is a  symbol.
> Defining the  same record-type  in multiple modules  is fine,  under the
> correct conditions.
> 
>   Using the  UID as  struct type  name, and  so implementing  records as
> simple CHICKEN structs, seems an efficient way to do it.

I had a quick look at the R6RS page and god that shit is ugly :)
But you're right, using these low-level constructors seems the best way
to do this.  Maybe you can use gensyms or uuids for the record names.
uuids probably work better if you later want to generate a types database
for the library.

Cheers,
Peter


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

Re: [Chicken-users] retrieving a structure's symbol name

[Peter Bex]

On Wed, Jul 24, 2019 at 07:22:45PM +0200, Marco Maggi wrote:
> Mh.   If I  understand correctly  this is  to avoid  collisions for  the
> record printers,  and stuff like that.

It is to avoid collisions for all accessors and predicates.  If I define
a record type X of 2 slots in module A, and in module B, I define a record
type also called X of 1 slot, then "X?" would return #t for both records.
And if I want to access the second slot of the record in module A, but
pass in an X of module B (which has only one slot), this will cause an
unsafe memory access.  That's because we can't safely check first if the
record is of the correct type.

>   If I define my  own record-type
> constructor, and I want to  use the built-in record printers facilities:
> is  CHICKEN expecting  me  to qualify  the name  with  the module?   The
> symbols I want to use are expected to be unique...

No, you can use unqualified symbols.  We still do that in core itself too,
for SRFI-4 vectors and for ports and so on.  But this is really low-level
stuff, and there's usually a better way.  What exactly are you trying to
accomplish?

Cheers,
Peter


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

Re: [Chicken-users] retrieving a structure's symbol name

[Peter Bex]

On Wed, Jul 24, 2019 at 03:49:13PM +0200, Marco Maggi wrote:
> Ciao,
> 
>   I know  that it is  dirty, but is it  possible to retrieve  the symbol
> name of  a structure  from the  block object?  If  I create  a structure
> with:
> 
>(define (make-it)
>  (##sys#make-structure 'spiffy))
> 
>(define O
>  (make-it))
> 
> can  I extract  "spiffy"  from the  structure object  bound  to "O"?   I
> searched "library.scm" in CHICKEN's 5.1.0 source without success.

You can access slot 0 to get it:

(##sys#slot (##sys#make-structure 'foo) 0) => foo

There's no official way to get at it.  But, if you are on CHICKEN 5.1
the define-record-type type name will contain it:

#;3> (define-record-type foo (make-foo) foo?) 
#;4> foo   
foo

And it will be namespaced with the module if it is defined in a module.
But beware, we might change the representation of record types to be
objects instead of symbols at some point so we can add introspection
to records.

Cheers,
Peter


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

Re: [Chicken-users] Easiest way to find origin repos of Chicken eggs

[Peter Bex]

On Tue, Jul 23, 2019 at 04:54:14PM +0300, Lassi Kortela wrote:
> Is there a global index (one file or web page) that links to the git/hg
> origin repo of every Chicken egg?

The master list used by our mirrors is
https://bugs.call-cc.org/browser/release/5/egg-locations

This is trawled by https://wiki.call-cc.org/eggref/5/henrietta-cache
which you can also run locally to obtain all releases of eggs in a
file like that.

Cheers,
Peter


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

Re: [Chicken-users] how the second argument to ERROR is handled

[Peter Bex]

On Sun, Jul 21, 2019 at 09:03:33AM +0200, Marco Maggi wrote:
> Ciao,
> 
>   with CHICKEN 5.1.0, is the following correct:
> 
>   (import (scheme) (chicken base) (chicken condition))
> 
>   (call/cc
>   (lambda (escape)
> (with-exception-handler
> (lambda (E)
>   (escape (list (get-condition-property E 'exn 'location)
> (get-condition-property E 'exn 'message)
> (get-condition-property E 'exn 'arguments
>   (lambda ()
> (error 1 2 3)
>   => '(#f 1 (2 3))
> 
> or should the "message" property be #f?

Hi Marco,

This looks fine to me.  The first argument to "error" should always
be the message.  You could argue that it should check for it to be
a string, but I'm not sure that's required.

The docs seem to suggest that the reason string is optional.  I think
this is wrong.

Cheers,
Peter


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

Re: [Chicken-users] wrong number of arguments to continuation when escaping?

[Peter Bex]

On Thu, Jul 18, 2019 at 08:13:53AM +0200, Marco Maggi wrote:
> Not sure if I understand.  The problem  lies in the context in which the
> call to DOIT is performed?

Yes, exactly.

> it expects any number of values in:
> 
>(call-with-values
>doit
>  (lambda args (apply values args)))
> 
> so no error?

Right.  call-with-values sets up a different type of continuation,
one that accepts an arbitrary number of values.  Standard continuations
allow only one argument.

Cheers,
Peter


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

Re: [Chicken-users] wrong number of arguments to continuation when escaping?

[Peter Bex]

On Thu, Jul 18, 2019 at 06:43:06AM +0200, Marco Maggi wrote:
> I do not understand why some place expects 1 argument.  The problem goes
> away if I replace:
> 
>(escape)
> 
> with:
> 
>(escape 1)

Hi Marco,

This is a known "issue", see #1390 and #1601.  Improving this so
that such non-explicit "value" continuations accept different argument
counts would have a big impact on performance because every single
continuation would then need to start checking its argument count.

It's unfortunate, but easy to fix; just use something like "receive"
or "call-with-values" to explicitly allow the continuation to handle
multiple values.

Cheers,
Peter


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

Re: [Chicken-users] importing a syntactic binding for level -1

[Peter Bex]

On Sat, Jul 13, 2019 at 02:12:48PM +0200, Marco Maggi wrote:
> Peter Bex wrote:
> 
> > This won't work.  "rename" is operating in the syntactic environment
> > of the transformer.  You can pass it as a procedure to some other module,
> > but that won't change its internal state.
> 
> So, is RENAME closed upon  the environment in which ER-MACRO-TRANSFORMER
> is called?  So I can do something like:

Yes, that's how it should work.

>   I'm  not  trying   to  inject  syntactic  bindings   in  the  original
> environment, I just want to put as much as possible of a macro body into
> a separate library to be imported "for syntax".

Personally, I find that confusing, because the module containing the
macro definition determines the available identifiers.  If you then move
the actual expansion code to another module, that doesn't give a clue as
to which identifiers are available in the expansion.

So for stylistic reasons I'd avoid that.  You can still move processing
code to another module, but I would pass the renamed identifiers to the
helper procedure, instead of the "rename" procedure itself.

Cheers,
Peter


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

Re: [Chicken-users] importing a syntactic binding for level -1

[Peter Bex]

On Sat, Jul 13, 2019 at 08:26:56AM +0200, Marco Maggi wrote:
>   I would like to write such macro as:
> 
> (import (scheme)
> (chicken fixnum))
> (import-for-syntax (scheme)
>(only (chicken syntax)
>  er-macro-transformer)
>(only (my-lib)
>  doit))
> 
> (define-syntax spiffy
>   (er-macro-transformer
> (lambda (input-form.stx rename compare)
>   (define %fx+ (doit rename))
>   ---)))
> 
> and in the library "(my-lib)" I have:
> 
> (define (doit rename)
>   (rename 'fx+))
> 
> but for  this to work  cleanly: in "(my-lib)"  I should import  "fx+" at
> level -1?  Is it right?

Hi Marco,

This won't work.  "rename" is operating in the syntactic environment
of the transformer.  You can pass it as a procedure to some other module,
but that won't change its internal state.

>   This is possible with R6RS implementations.  How about CHICKEN?

That is very surprising to me.  It should not be possible.  You're
probably comparing apples and oranges (syntax-case works differently
from ER macros).

Cheers,
Peter


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

Re: [Chicken-users] thoughts on alternate "posits" / "unums" instead of traditional floats?

[Peter Bex]

On Tue, Jul 09, 2019 at 12:25:12PM -0500, Daniel Ortmann wrote:
> I am probably the last to run across this alternate floating point
> format ... but now I am curious.
> 
> If these posits were implemented in Chicken, what sort of work would be
> required?
> Would they replace the traditional floats?

It sounds like they would replace traditional floats, yes.

> Or would they be an optional part of the numeric stack?

They could be, but Scheme does not really allow for multiple types
of inexact numbers.  It would also slow everything down even further
due to even more dispatching.  Right now, if we know something's a
float/inexact, we can simply inline calls.

We rely quite a lot on the C compiler to do flonum code.

> https://www.nextplatform.com/2019/07/08/new-approach-could-sink-floating-point-computation/

From this article:

   Better yet, he claims the new format is a “drop-in replacement” for
   standard floats, with no changes needed to an application’s source code.

So it sounds like a modified C compiler and/or FPU would be the way to go
for this.  CHICKEN can then transparently make use of that via the C type
"double".

Cheers,
Peter


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

Re: [Chicken-users] Segmentation violation with chicken 5.1.0

[Peter Bex]

On Sun, Jun 23, 2019 at 02:33:10PM +0200, Peter Bex wrote:
> [panic] Low-level type assertion 
> C_blockp((C_word)C_VAL1(C__PREV_TMPST.n1))=#t failed at chickenprob3.c:93488 
> - execution terminated

Here's a minimal reproducible testcase:

(define (test-it)
  (let loop ((done #f))
(if done
'()
(cons  (or (read) 0.0) (loop #t)

(print (test-it))

This generates exactly the same construct:
f0=C_flonum_magnitude((C_truep(t1)?t1:lf[1]));

If you type in a fixnum integer, this will break too.

I've filed a bug to track this: https://bugs.call-cc.org/ticket/1624


A quick workaround for your program might be to return the 0.0 from a
foreign lambda, like so:

(define return-zero
  (foreign-lambda* float () "C_return(0.0);"))

(define (test-it)
  (let loop ((done #f))
(if done
'()
(cons  (or (read) (return-zero)) (loop #t)

(print (test-it))

It's stupid, but it works.

Cheers,
Peter


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

Re: [Chicken-users] Segmentation violation with chicken 5.1.0

[Peter Bex]

On Sat, Jun 22, 2019 at 05:50:30PM +0200, Sven Hartrumpf wrote:
> Hello.
> 
> I have a strange problem with legacy code that works in many
> other Schemes and Chicken 5 csi, but the binary compiled with Chicken 5 
> crashes.

It looks like the bug happens in lookup_prob in the let*.

(value (or (phashtable-get current_hashtable current_tokens) 0.0)) is
compiled to f0=C_flonum_magnitude((C_truep(t1)?t1:lf[3]));, but that's
wrong because t1 is a fixnum.  It's easy to find if you compile this
with a DEBUGBUILD version of CHICKEN, it says:

[panic] Low-level type assertion C_blockp((C_word)C_VAL1(C__PREV_TMPST.n1))=#t 
failed at chickenprob3.c:93488 - execution terminated

I have yet to find out exactly what's going on, but my bet is on this
change in core: 79cf7427638eebf695f2be54731bb6bbf4d0fff2 (the lfa2 unboxing
pass)

Cheers,
Peter


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

Re: [Chicken-users] [ANN] CHICKEN 5.1.0 has been released

[Peter Bex]

On Thu, Jun 20, 2019 at 01:33:24PM +0200, Jörg F. Wittenberger wrote:
> Dear CHICKENers,
> On Jun 18 2019, Peter Bex wrote:
> 
> > The other important new features are the new cond-expand, c-object and
> > object forms in .egg files.
> 
> The last two forms did not make it into the documentation yet, did they?

Crap, I accidentally deleted them when I synced changes made on the wiki
back to the manual in git.  I've restored them in master as well as on
the wiki.  Thanks for pointing this out!

Cheers,
Peter


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

[Chicken-users] [ANN] CHICKEN 5.1.0 has been released

[Peter Bex]

Dear CHICKEN users,

We are pleased to announce the immediate availability of CHICKEN 5.1.0
at the following URL:
https://code.call-cc.org/releases/5.1.0/chicken-5.1.0.tar.gz

This tarball has the following SHA256 checksum:
5c1101a8d8faabfd500ad69101e0c7c8bd826c68970f89c270640470e7b84b4b

The most important change since 5.0.0 is a breaking one: Keywords are
now completely distinct from symbols.  Keywords are no longer accepted
as identifiers nor as type names, which may mean you'll need to
pipe-quote them or disable keyword syntax on your projects.

The other important new features are the new cond-expand, c-object and
object forms in .egg files.

The only change since the first release candidate is a small bug found
by John Cowan: srfi-4 did not export list->s64vector.  This bug was also
present in 5.0.0.

For a full list of the changes since 5.0.0, see the NEWS file:
https://code.call-cc.org/releases/5.1.0/NEWS

Kind regards,
The CHICKEN Team


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

Re: [Chicken-users] [ANN] CHICKEN 5.1.0 release candidate available

[Peter Bex]

Hi all,

I tested on my old Debian/Hurd image.

Operating system: Debian/Hurd 0.9
Hardware platform: x86
C Compiler: gcc 8.2.0
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes

Cheers,
Peter


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

Re: [Chicken-users] [ANN] CHICKEN 5.1.0 release candidate available

[Peter Bex]

Hi all,

I've tested on Haiku.  Everything worked, except for the fact that
the timestamps of extracted files from tarballs are still messed up.
So, I had to occasionally touch(1) a few .c files in order to avoid
it trying to call "chicken" to recompile some Scheme files.

This is a known issue with Haiku's file system.

Operating system: Haiku r1beta1
Hardware platform: x86-64
C Compiler: 7.3.0
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes

Cheers,
Peter


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

Re: [Chicken-users] [ANN] CHICKEN 5.1.0 release candidate available

[Peter Bex]

Hi all,

Tested on FreeBSD:

Operating system: FreeBSD-11.2
Hardware platform: x86-64
C Compiler: clang 6.0.0
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes

Operating system: FreeBSD-11.2
Hardware platform: x86-64
C Compiler: gcc 8.2.0
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes

Cheers,
Peter


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

Re: [Chicken-users] [ANN] CHICKEN 5.1.0 release candidate available

[Peter Bex]

On Sun, Jun 09, 2019 at 10:23:14PM -0400, John Cowan wrote:
> The output of "make test" was over 20,000 lines, some of which do have the
> string "fail" in them.  I've posted it at
>  if anyone wants to take a look.

Hi John,

That's normal.  There are many tests which are testing the compiler and
which will print a warning like "foo in (if foo (error "assertion failed"))
 is always true".  There are also a few tests which check that something
fails, so it says "blabla failed, as it should".  And finally there's the
reports of some tests which simply say "0 assertions failed".

If the tests really fail, make will exit with an error.

Cheers,
Peter


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

Re: [Chicken-users] [ANN] CHICKEN 5.1.0 release candidate available

[Peter Bex]

On Sun, Jun 09, 2019 at 11:15:59PM +0200, ipc...@arcor.de wrote:
> Hi,
> 
> I failed to build 5.1.0rc1.
> 
> log:
> 
> http://paste.call-cc.org/paste?id=049edb2b007bd9a1859362a6e99818a282aa5201
> 
> I know I forgot to set the LINKER flag, but setting it doesn't change
> anything. Likewise, using GCC doesn't work either, neither does building
> without chicken-belt.

Hi Heinz,

It looks like you did "make spotless" or something.
Look for the line that starts with
rm -f batch-driver.c build-version.c 

This is deleting the pregenerated C files.  You can see later on it's
calling chicken to rebuild those.  That's where it went wrong.

Try again to build the tarball from scratch.

Cheers,
Peter


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

Re: [Chicken-users] [ANN] CHICKEN 5.1.0 release candidate available

[Peter Bex]

On Sat, Jun 08, 2019 at 03:07:34PM +0200, Peter Bex wrote:
> Please give it a test and report your findings to the mailing list.

I've done some testing on Windows 7.

Operating system: Windows 7 mingw-msys under mingw32
Hardware platform: x86
C Compiler: gcc
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes

Operating system: Windows 7 mingw32
Hardware platform: x86
C Compiler: gcc
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes

Operating system: Windows 7 cygwin
Hardware platform: x86
C Compiler: gcc
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes


Cheers,
Peter


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

Re: [Chicken-users] file-exists? is missing

[Peter Bex]

On Sat, Jun 08, 2019 at 07:48:54PM +, Mathieu wrote:
> Hi Schemers,
> 
> Just noticed that the following :
> 
> (import (chicken file))
> (file-exists? "anything")
> 
> Gives the following error at runtime :
> 
> unbound variable: chicken.file#file-exists?
> 
> Using csc5 under FreeBSD.

Hi Mathieu,

I can't reproduce this.  Can you try rebuilding from scratch?

Cheers,
Peter


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

[Chicken-users] [ANN] CHICKEN 5.1.0 release candidate available

[Peter Bex]

Hello everyone,

We are happy to announce the first release candidate of the upcoming
CHICKEN 5.1.0.

CHICKEN 5.1.0rc1 is now available at this location:
https://code.call-cc.org/dev-snapshots/2019/06/08/chicken-5.1.0rc1.tar.gz

The SHA256 sum of that tarball is
d520bf83e446b67508768de90768724b8a2ebb1953e6ece873ce790162a1b671

The most important change is a breaking one: Keywords are now completely
distinct from symbols.  Keywords are no longer accepted as identifiers
nor as type names, which may mean you'll need to pipe-quote them or
disable keyword syntax on your projects.

The other important new features are the new cond-expand, c-object and
object forms in .egg files.

The complete list of changes since version 5.0.0 is available here:
https://code.call-cc.org/dev-snapshots/2019/06/08/NEWS

(Note that I accidentally left the entry for 5.0.1 under 5.1.0.  5.1.0
includes those changes as well, this will be fixed in the next RC or in
the final release)

Please give it a test and report your findings to the mailing list.

Here's a suggested test procedure:

  $ make PLATFORM= PREFIX= install check
  $ /bin/chicken-install pastiche

If you want to build CHICKEN with a compiler other than the default one,
just use C_COMPILER= (e.g., C_COMPILER=clang) on the make
invocation.

Of course, feel free to explore other supported build options (see the
README file for more information) and actually use CHICKEN 5.1.0rc1 for
your software.

If you can, please let us know the following information about the
environment you tested the RC tarball on:

Operating system: (e.g., FreeBSD 12.0, Debian 9, Windows 10 mingw-msys under 
mingw32)
Hardware platform: (e.g., x86, x86-64, PPC)
C Compiler: (e.g., GCC 6.4.0, clang 5.0.0)
Installation works?: yes or no
Tests work?: yes or no
Installation of eggs works?: yes or no

Thanks in advance!

The CHICKEN Team


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

Re: [Chicken-users] matchable egg: error while reporting error?

[Peter Bex]

On Mon, Jun 03, 2019 at 09:25:51AM +0200, Marco Maggi wrote:
> I understand  this.  But  the problem  looks like  MATCH-SYNTAX-ERROR is
> used with  an invalid  syntax by  the "matchable"  internals themselves.
> What I  expected is an error  during the expansion of  MATCH, not during
> the expansion of MATCH-SYNTAX-ERROR.

Oh, I see.  matchable is written as portable Scheme, and it "abuses"
match-syntax-error by deliberately passing an invalid number of arguments
to raise an error when it sees something that goes wrong.  This is just a
consequence of having a portable implementation like that.

But that's just my opinion, if you feel strongly about it I would make a
ticket for the egg's author.

Cheers,
Peter


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

Re: [Chicken-users] matchable egg: error while reporting error?

[Peter Bex]

On Mon, Jun 03, 2019 at 06:21:56AM +0200, Marco Maggi wrote:
> Ciao,
> 
>   with CHICKEN  5.0.0 this  form using  MATCH from  "matchable" (updated
> right now):
> 
> (match '(#:a #:b c d)
>   (((? keyword? k*) ... (? symbol? s*) ...)
>(pretty-print k*)
>(pretty-print s*))
>   (_
>(pretty-print 'no)))
> 
> fails with:
> 
> Error: during expansion of (match-syntax-error283 ...) - no rule matches 
> form: (match-syntax-error "multiple ellipsis patterns not allowed at same 
> level")
> 
> which looks like an error while reporting an error.

Hi Marco,

It's complaining about your pattern, which is ambiguous.  Well,
you could say it's not strictly ambiguous, but the pattern matcher
doesn't know that.

It expands to a syntax-rules pattern, which cannot contain multiple
ellipsis at the same level.  The reason?

How should 
(syntax-rules ()
  ((foo bar "haha" more ... "haha" even-more ...)
   (list even-more ...)))
match
(blah 1 "haha" 2 3 4 "haha" 5 6 7 "haha" 8 9 10 "haha")?

It could return either (5 6 7 "haha" 8 9 10 "haha"),
(8 9 10 "haha") or ().

Normally one would solve this by saying it could be greedy or
non-greedy (like in regexes), but the spec doesn't specify, so
strictly speaking this is an error.  That's what gets reported.

>   By  the way:  should this  be reported  directly on  the bugs  server,
> without previous confirmation by someone else?   Of is it fine to report
> it here first?   And do I really  need to privately contact  a person to
> get an account on the bugs server?

If you still think this is a bug, it's a bug in matchable.  I think
there's no upstream repository for it (just the code on synthcode.com)
So you can report it on bugs.call-cc.org, assign it to "ashinn" (that's
matchable's author).

Cheers,
Peter


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

Re: [Chicken-users] A Thank You to all the chicken-scheme contributors

[Peter Bex]

On Sun, May 26, 2019 at 01:09:08PM +0100, Richard Huxton wrote:
> I'm unlikely to ever become a scheme guru or even make a living writing it.
> 
> I am however enjoying exploring chicken scheme and have found it to be a
> clean, practical distribution with well thought out tools and suprisingly
> good documentation.
> 
> Given all the publicity around recent languages backed by big companies, it
> is reassuring to find that a small community can still create a modern
> system for writing practical tools.
> 
> Thank you to all involved.

Hello Richard,

Thank you for your kind words!  A simple note of appreciation like this
means a lot to me and it certainly is a motivation booster :)

Cheers,
Peter


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

Re: [Chicken-users] for those who have interest in procedure objects decoration

[Peter Bex]

On Wed, May 22, 2019 at 03:05:44PM +0200, Marco Maggi wrote:
> Peter Bex wrote:
> > This looks pretty cool!  One request though: could you please add some
> > blatant warnings that this stuff is not meant to be relied upon in user
> > code?  These are internals instead of an official API for a reason; we
> > can change them at will (this has happened in the past, and will happen
> > in the future).
> 
> Yes.  I will add it in the document overview.

Thanks!

> > So it's acceptable to use these, but only if there's no alternative, and
> > you may end up having to use cond-expand for various different versions.
> 
> Speaking of which!  "chicken-doc" does not know about COND-EXPAND! I get
> a blank page when I try it (the same with UNQUOTE and UNQUOTE-SPLICING).

Hm, that's interesting.  Unquote and unquote-splicing are not actually
bound to anything; they're only available inside quasiquote, so they can't
be imported or renamed or anything:

  (module foo () (import (only scheme quasiquote +)) `(foo ,(+ 1 2)))

So it makes sense they don't have a separate entry.  It's like having =>
as a separate entry; it doesn't exist either except in cond and case
forms.

For cond-expand, that's another story we should find out where to
document it.  It's available inside empty modules too, because it needs
to be available before even importing anything.  It's not from any
module, that's probably why we dropped it.  Perhaps under "Extensions to
the standard"?

Cheers,
Peter


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

Re: [Chicken-users] for those who have interest in procedure objects decoration

[Peter Bex]

On Wed, May 22, 2019 at 10:59:17AM +0200, Marco Maggi wrote:
> Ciao,
> 
>   I'm composing unofficial documentation  for CHICKEN internals that are
> usable from client code.   As part of this I have  added a section about
> decorating procedure objects:
> 
> 

Hi Marco,

This looks pretty cool!  One request though: could you please add some
blatant warnings that this stuff is not meant to be relied upon in user
code?  These are internals instead of an official API for a reason; we
can change them at will (this has happened in the past, and will happen
in the future).

So it's acceptable to use these, but only if there's no alternative, and
you may end up having to use cond-expand for various different versions.

Cheers,
Peter


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

Re: [Chicken-users] what does "##core#check" do?

[Peter Bex]

On Tue, May 14, 2019 at 07:05:41AM +0200, Marco Maggi wrote:
> Ciao,
> 
>   in the "record-variants" egg there is:
> 
>(##core#check (##sys#check-structure x ',original-name))
> 
> I understand what:
> 
>(##sys#check-structure x ',original-name)
> 
> does,  but  what  is  the  "##core#check" for?   In  other  code  I  see
> "##sys#check-structure" uses without it.

It's an annotation in the core language (see core.scm) that causes the
expression inside to be eliminated in unsafe mode.  In normal mode, it
will just walk the expression as if the ##core#check wasn't there.

Cheers,
Peter


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

Re: [Chicken-users] Defining defmacro using define-syntax

[Peter Bex]

On Mon, May 13, 2019 at 07:11:40PM +0100, Martin Ward wrote:
> Chicken scheme does not appear to have defmacro or define-macro
> but does have define-syntax.
> 
> Is there a way to define defmacro using define-syntax?

This is of course highly discouraged (because defmacro is
inherently unhygienic), but you can do:

(import (chicken syntax))

(define-syntax defmacro
  (syntax-rules ()
((_ ?name ?args ?body ...) 
 (define-syntax ?name
   (er-macro-transformer
 (lambda (e r c)
   (apply (lambda ?args ?body ...) (cdr e

Cheers,
Peter


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

Re: [Chicken-users] on the usage of the unsafe operations ##sys##slot and similar

[Peter Bex]

On Sun, May 12, 2019 at 11:10:51AM +0200, Marco Maggi wrote:
> Ciao,
> 
>   sorry  for  peeking  under  the  skirt; I'm  trying  to  get  a  basic
> understanding of the  core usage and memory layout of  Scheme values

Hi Marco,

If you're interested in this, perhaps you find this blog post of mine
useful: https://www.more-magic.net/posts/internals-data-representation.html
It explains how values are represented in memory at the low level.

> is it correct that:
> 
> * We can  use ##sys#setislot to  store any  immediate value in  a Scheme
>   vector?

That's correct.  It's faster than ##sys#setslot because it doesn't
check if it's an immediate.  ##sys#setslot will track mutations to
non-immediate values so that the garbage collector knows that the
object is still being used.

> * We   can  use   the  system   operations  ##sys#slot,   ##sys#setslot,
>   ##sys#setislot , ##sys#size on every Scheme object whose memory layout
>   is similar to the one of Scheme vectors?

Yeah, it can be used on any compound Scheme object.  Basically, any
non-immediate that's not a bytevector.  On bytevectors, ##sys#size
works too, but it will return the size in bytes rather than the number
of slots in the object.

Cheers,
Peter


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

Re: [Chicken-users] Is it possible to change the list of included modules when compiling Chicken?

[Peter Bex]

On Sat, May 11, 2019 at 08:28:23PM -0300, Jeronimo Pellegrini wrote:
> Hello,
> 
> I was wondering if it is possible to remove or add modules to
> the list of default included modules that come with Chicken.
> 
> I am compiling it for wireless routers, and so far I could not yet
> package csc -- so getting modules with chicken-install doesn't
> work for me.

Hi Jeronimo,

I'm not sure what you're trying to do, but are statically linked
binaries of your program not an option for you?  This would be one
single binary file you can just put onto the router.

> Would it be possible to
> 
> - get the source of a couple of eggs, and put them somewhere with
>   the Chicken sources,
> - add their name/path to a list,
> 
> and have them compiled and included in $PREFIX/lib/chicken/9/
> when Chicken is compiled?

Technically this should be possible I think, but I don't know of an
easy way to do this currently.

Cheers,
Peter


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

Re: [Chicken-users] Statically compiling with additional eggs in Chicken 5

[Peter Bex]

On Tue, May 07, 2019 at 01:06:09PM -0700, Jeff Moon wrote:
> I'm using chicken 5.0.0.  I've used it to create a handful of apps that I
> have distributed as static binaries, and it seems to be working very well.
> However, when I try to include certain eggs, the static builds do not seem
> to work.  I'm wondering if anybody has gotten static compiles to work with
> any of the following eggs: postgresql, sqlite3, or sql-de-lite?

Hi Jeff,

To get the correct linking options for linking in the libraries you can
use something like:

$ pkg-config --static --libs sqlite3
-lsqlite3 -lm -ldl -lpthread

Then, you can link the program:

$ csc -static -L -lsqlite3 -L -lm -L -ldl -L -lpthread test.scm

You'll note that the libraries are still linked dynamically (with `ldd`).
To make it fully static, use -L -static:

$ csc -static -L -static -L -lsqlite3 -L -lm -L -ldl -L -lpthread test.scm

For PostgreSQL, I used pkg-config --static --libs pq, but this told me
to use -lgssapi_krb5 and there is no static version of that library in
Debian at least.  So I think you can't link it statically on Debian.

Cheers,
Peter


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

Re: [Chicken-users] is it possible to define expand-time values?

[Peter Bex]

On Sat, May 04, 2019 at 09:06:08PM +0200, Marco Maggi wrote:
> That  example just  shows the  mechanism, and  it is  not really  a good
> example (I wrote it).  What I  am thinking of, as reference scenario, is
> an infix-to-prefix macro  with infrastructure that allows  to define new
> binary operators, in which the operator name is not necessarily equal to
> the name of the function that implements the operation itself.
> 
>   So it should go like this:
> 
>(define (spiffy-operation X Y)
>  (do-something-spiffy-with X Y))
> 
>(define-infix-binary-operator spiffy
>  (right-binding-power 55)
>  ...
>  (procedure spiffy-operation))
> 
>(infix 2 * 3 + 88 spiffy 99)

I don't quite understand this example.  Nevertheless, I still get
the feeling that this is a concept that's unnecessary.

Cheers,
Peter


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

Re: [Chicken-users] is it possible to define expand-time values?

[Peter Bex]

On Sat, May 04, 2019 at 03:56:12PM +0200, Marco Maggi wrote:
> ...  in CHICKEN  5.0.0  or in  a  future release?   I  can find  nothing
> relevant on the CHICKEN Wiki.  Here what they should do:
> 
> 
> 
> it would open a can of worms^H^H^H^H^H possibilities.

Hi Marco,

This seems like a superfluous feature to me.

To give an example of the first example on the page you linked,
I would use this in a begin-for-syntax, like so:

(begin-for-syntax
  (define obj1 (+ 1 2 3)))

(define-syntax get-obj1
  (er-macro-transformer
(lambda (e r c)
  obj1)))

(get-obj1) => 6

Maybe I'm missing something, but this seems much simpler to me.

Cheers,
Peter


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

[Chicken-users] [ANN] Development snapshot 5.0.2 now available

[Peter Bex]

Hi all!

A new development snapshot (5.0.2) is now available:
https://code.call-cc.org/dev-snapshots/2019/05/02/chicken-5.0.2.tar.gz

This is the second snapshot in the 5.x release series.  The most
important change is that this version completes the previous change
of how "qualified" symbols are read.  Keywords were still encoded with
a leading NUL byte, so if you tried to read or convert a string to a
symbol which started with a NUL byte, it would be interned and seen as
a keyword, even though it was a symbol.

This caused problems when printing non-qualified symbols that contained
NUL bytes.  See https://bugs.call-cc.org/ticket/1576 for more
information.  Changing this representation is backwards-incompatible,
which means that the git version of CHICKEN must now be built with a
CHICKEN that's from this snapshot or newer.

Related to this change is the fact that keywords (unlike "real" symbols)
no longer have a plist.  If you try to access a keyword's plist, it will
raise a runtime error with condition types (exn type).

Another backwards-incompatible change is that we reverted the change of
how all "standard" continuations were allowed to accept multiple values
for #1390.  This caused a lot of trouble due to assumptions made
throughout the compiler that standard continuations accept exactly one
value, found out in #1601.  This basically restores the behaviour to
how it was in CHICKEN 4, so hopefully nobody has started to rely on
this behaviour that was new to CHICKEN 5.0.0.

An important bug fix is that the perm/* permission constants from the
(chicken file posix) module have been fixed; they were all defined as
the "usr" versions, even the "grp" and "oth" ones (#1602).

There's a complete list of changes since the 5.0.1 release in the
NEWS file: https://code.call-cc.org/dev-snapshots/2019/05/02/NEWS

We would encourage all of our more adventurous users to try running
their code under this snapshot.  If you run into any problems with
the new snapshot, please let us know.

Regards,
The CHICKEN Team


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

Re: [Chicken-users] Anyone know why I can't split with an empty string in (chicken irregex)?

[Peter Bex]

On Wed, May 01, 2019 at 11:18:31PM -0500, joshua wrote:
> I can't seem to figure out how to split a string into individual characters.

Hi Joshua,

The canonical way to do that would be string->list.

> I could swear this worked before, in Chicken 4.
> I'm now using Chicken 5.0.0 running on Void Linux.
> 
> #;1> (import (chicken irregex))
> ; loading /usr/lib/chicken/9/chicken.irregex.import.so ...
> #;2> (irregex-split (irregex ",") "foo,bar,baz")
> ("foo" "bar" "baz")
> #;3> (irregex-split (irregex " ") "foo bar baz")
> ("foo" "bar" "baz")
> #;4> (irregex-split (irregex "") "foobarbaz")
> () ; wat

Hm, that is somewhat surprising.  I checked irregex upstream,
but as far as I can tell, this has never worked.  In extremely
old versions this would raise an internal error and in newer
versions it returns the empty list.

I can take a look but I'm not even sure what the correct behaviour is
supposed to be.

Cheers,
Peter


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

Re: [Chicken-users] Print asymmetry with coops

[Peter Bex]

On Fri, Apr 26, 2019 at 09:11:02AM +, EfraimVagner wrote:
> Hi,
> 
> I've started to work on a small project for fun in scheme, and I wanted to 
> use a class for one thing. I saw that there is the coops extension, that does 
> what I want, but my problem is that when printing an object i get 
> #. I saw I can use describe-object to get a better 
> description of the object. Another thing that I would like to have, is that 
> in sbcl, for example (I think any common lisp implementation acts the same), 
> when using defstruct, the printed version of the new object can be used to 
> create another object. For example:
> 
> (defstruct point x y)
> 
> (make-point :x 1 :y 2) ;; Will print #S(POINT :X 1 :Y 2)
> 
> (setq p1 #S(POINT :X 10 :Y 0)) ;; p1 will be a point with x=10 and y=0
> 
> I don't like the way it works in scheme because it looses the symmetry of 
> lisp. My question is then, how can I restore the symmetry? (btw, I'm using 
> chicken scheme if it matters)

Hi Efraim,

You can define a custom record printer using define-record-printer:
https://wiki.call-cc.org/man/5/Module%20(chicken%20base)#define-record-printer

The example here also uses define-reader-ctor to read back the record.
If you prefer custom read syntax like in Common Lisp, you could also
use set-[sharp-]read-syntax! from (chicken read-syntax):
http://wiki.call-cc.org/man/5/Module%20(chicken%20read-syntax)#set-read-syntax

I think you should also be able to define custom read syntax for coops
instances as well.

Hope this helps,
Peter


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