Re: Guile with win32 cross compiling

2011-04-24 Thread Andy Wingo
Hi Volker,

On Sat 23 Apr 2011 18:10, Volker Grabsch  writes:

> Andy Wingo schrieb:
>> Hmmm.  Well.  We have other code generators in Guile's build system;
>> notably the configure script (via config.h and other output files).
>> What do folks think about the attached patch?
>
> Please drop me a note when you want me to check your patch,
> confirming that your work really solves the win32 cross issues.

Hmm, it should have applied to stable-2.0.  I can commit it if there are
no objections, as there do not appear to be.  It should fix the
gen-scmconfig issue.

Andy
-- 
http://wingolog.org/



Re: binary-port?

2011-04-24 Thread Ludovic Courtès
Hi Marco,

Marco Maggi  writes:

> Ludovic Courtès wrote:
>
 However,  I’m  wondering  whether  we  should  not  just
 squarely do away with the binary/textual distinction
>
> How would you handle port position?

Currently port position is in bytes for all kinds of ports (info
"(guile) Random Access").  It seems to be a valid implementation of R6
port positions, no?

[...]

>   IMHO this R6 statement:
>
>   (textual-port? port) procedure 
>   (binary-port? port) procedure 
>
> The  textual-port?  procedure  returns  #t  if  port  is
> textual,  and  returns  #f otherwise.  The  binary-port?
> procedure returns  #t if port is binary,  and returns #f
> otherwise.
>
> should be enough to derive that:
>
>   (cond ((binary-port? p)
>  ---)
> ((textual-port? p)
>  ---))
>
> and:
>
>   (cond ((textual-port? p)
>  ---)
> ((binary-port? p)
>  ---))
>
> must  be  equivalent;  if  they are  not,  confusion  arises
> because of violation of the rule of least surprise.

Yes, and that’s a problem.

OTOH, what I wonder is when in practice would you need to use such an
idiom, or to use these predicates at all?

Thanks,
Ludo’.



Re: Patch: New section "Invoking Guile" for chapter "Programming in Scheme"

2011-04-24 Thread Andy Wingo
On Sat 23 Apr 2011 21:46, Mark Harig  writes:

> Here is a set of patches to add the new section "Invoking Guile" to
> the chapter "Programming in Scheme."

They look good in general, though I have some comments.  I would like
Neil to look over them as well, or at least say he's OK with them.

First, your patches should be "atomic"; see
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#patch-series
for some commentary.  In particular see point 3.  The manual should be
working after each patch.

The commit logs are good.

> +@item -s @var{script} @var{arg...}
> +@cindex script mode
> +Read and evaluate Scheme source code from the file @var{script}, as the
> +@code{load} function would.  After loading @var{script}, exit.  Any
> +command-line arguments @var{arg...} following @var{script} become the
> +script's arguments; the @code{command-line} function returns a list of
> +strings of the form @code{(@var{script} @var{arg...})}.

The "-s" is actually optional, and only *needed* if your script starts
with a dash.  So please document "guile foo.scm" as the default, and
just mention "-s" in case of the script starting with a dash, or if you
are writing some other shell script.  Use @itemx in this case, I think.

> +strings, even those that are written as numerals.  (Note that here we
> +are referring to names and values that are defined in the operating
> +system shell from which Guile is invoked.  This is not the same as a
> +Scheme environment that is defined within a running instance of guile.

"Guile", I think.

> +How to set environment variables before starting Guile depends on the
> +operating system, and especially the shell that you are using.  For
> +example, here's how to set the environment variable @env{ORGANIZATION}
> +to @samp{not very much} using Bash:
> +
> +@example
> +export ORGANIZATION="not very much"
> +@end example
> +
> +@noindent
> +and here's how to do it in csh or tcsh:
> +
> +@example
> +setenv ORGANIZATION "not very much"
> +@end example

Perhaps the tcsh example is superfluous.  Perhaps we should also mention
the way to set env vars for one invocation: "GUILE_AUTO_COMPILE=0
guile".

> +If you wish to retrieve or change the value of the shell environment
> +variables that effect the run-time behavior of Guile from within a
> +running instance of guile, see @xref{Runtime Environment}.

"affect"

> +@item GUILE_HUSH
> +@vindex GUILE_HUSH
> +The @code{#/} notation for lists provokes a warning message from Guile.
> +This syntax will be removed from Guile in the near future.
> +
> +To disable the warning message, set the @env{GUILE_HUSH} environment
> +variable to any non-empty value.

This variable does not exist.

> +@item GUILE_INIT_MALLOC_LIMIT
> +@vindex GUILE_INIT_MALLOC_LIMIT
> +@item GUILE_MIN_YIELD_MALLOC
> +@vindex GUILE_MIN_YIELD_MALLOC
> +@cindex garbage collecting
> +@item GUILE_MAX_SEGMENT_SIZE
> +@vindex GUILE_MAX_SEGMENT_SIZE
> +@item GUILE_INIT_SEGMENT_SIZE_2
> +@vindex GUILE_INIT_SEGMENT_SIZE_2
> +@item GUILE_INIT_SEGMENT_SIZE_1
> +@vindex GUILE_INIT_SEGMENT_SIZE_1
> +@item GUILE_MIN_YIELD_2
> +@vindex GUILE_MIN_YIELD_2

Since switching to the BDW GC, these variables are not used any more.

GC_FREE_SPACE_DIVISOR is parsed by Guile though.  The GC itself does
appear to do a number of getenv calls, but we can't really document
those in Guile I don't think.

> +@item GUILE_SYSTEM_LOAD_COMPILED_PATH
> +@item GUILE_SYSTEM_PATH
> +@item GUILE_SYSTEM_LTDL_PATH

These are paths that Guile itself uses to look up .go, .scm, and .so
files, respectively.  They have default values, relative to $prefix, but
can be overridden if you really know what you're doing.  This is only
really useful when building Guile itself.

> +@item GUILE_INIT_SEGMENT_SIZE_1
> +@item GUILE_MIN_YIELD_1
> +@item GUILE_INIT_SEGMENT_SIZE_2
> +@item GUILE_MIN_YIELD_2
> +@item GUILE_MAX_SEGMENT_SIZE
> +@item GUILE_INIT_HEAP_SIZE_1
> +@item GUILE_INIT_HEAP_SIZE_2

Not used any more.

> +@item GUILE_WARN_DEPRECATED
> +@vindex GUILE_WARN_DEPRECATED
> +Please provide a description of me.

@ref to Deprecation.

wingo@unquote:~/src/guile$ meta/guile
GNU Guile 2.0.0.202-514ff6
Copyright (C) 1995-2011 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (feature? 'foo)
$1 = #f
scheme@(guile-user)> 

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
wingo@unquote:~/src/guile$ GUILE_WARN_DEPRECATED=detailed meta/guile
GNU Guile 2.0.0.202-514ff6
Copyright (C) 1995-2011 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This prog

Re: Patch: New section "Invoking Guile" for chapter "Programming in Scheme"

2011-04-24 Thread Andy Wingo
Hi Mark,

Thanks for the revisions.

On Sun 24 Apr 2011 22:36, Mark Harig  writes:

> On Sun, Apr 24, 2011 at 04:33:44PM +0200, Andy Wingo wrote:
>> your patches should be "atomic"
>
> "3. No patch introduces a regression: after applying any
> initial part of the series, the resulting project still
> compiles and works, and has no bugs that it didn’t have
> before."

Right, at the end of applying all of your patches, I'm sure that's the
case; however the first patch adds an @include without adding the
appropriate file, so applying just the first patch without the following
two would yield a project that doesn't compile.  I just meant that you
need to squish the first two or three of them together.  I can do that
when I apply them, though.

By @itemx I just meant to do instead of:

> +@item -s @var{script} @var{arg...}

you would

@item @var{script} @var{arg...}
@itemx -s @var{script} @var{arg}

The other option would be

@item [-s] @var{script} @var{arg}

which is not as clear IMO.  I feel that it's important to have a good
example up there, and making it clear that it's OK to just invoke Guile
as "guile foo.scm" is important.  But your description is good too.

> +For compatibility with some versions of Guile 1.4, you can also use the
> +form @code{(symbol ...)} (that is, a list of only symbols that doesn't
> +start with @code{@@}), which is equivalent to @code{(@@ (symbol ...)
> +main)}, or @code{(symbol ...)  symbol} (that is, a list of only symbols
> +followed by a symbol), which is equivalent to @code{(@@ (symbol ...)
> +symbol)}.  We recommend to use the equivalent forms directly since they
> +correspond to the @code{(@@ ...)}  read syntax that can be used in
> +normal code.  See @ref{Using Guile Modules} and @ref{Scripting
> +Examples}.

Again, probably worth eliding the deprecated 1.4 stuff...

> +@item --auto-compile
> +Compile source files automatically (default behavior).
> +
> +@vnew{2.0}
> +
> +@item --no-auto-compile
> +Disable automatic source file compilation.
> +
> +@vnew{2.0}

Need --fresh-auto-compile here too

> +@item GUILE_AUTO_COMPILE
> +@vindex GUILE_AUTO_COMPILE

Need to note GUILE_AUTO_COMPILE=fresh, and @ref to Compilation

Best regards,

Andy
-- 
http://wingolog.org/



Re: Patch: New section "Invoking Guile" for chapter "Programming in Scheme"

2011-04-24 Thread Mark Harig



On Sun, Apr 24, 2011 at 11:00:16PM +0200, Andy Wingo wrote:
> Hi Mark,
> 
> Thanks for the revisions.
> 
> On Sun 24 Apr 2011 22:36, Mark Harig  writes:
> 
> > On Sun, Apr 24, 2011 at 04:33:44PM +0200, Andy Wingo wrote:
> >> your patches should be "atomic"
> >
> > "3. No patch introduces a regression: after applying any
> > initial part of the series, the resulting project still
> > compiles and works, and has no bugs that it didn’t have
> > before."
> 
> Right, at the end of applying all of your patches, I'm sure that's the
> case; however the first patch adds an @include without adding the
> appropriate file, so applying just the first patch without the following
> two would yield a project that doesn't compile.  I just meant that you
> need to squish the first two or three of them together.  I can do that
> when I apply them, though.
> 

What do guile developers normally do when generating the
patches?  ('git format-patch origin' is generating three
separate files.  Do you concatenate the patch files that
'git' emits?)  Please let me know if there is a documented
recipe that guile-devel uses that I can follow for future
changes.

> By @itemx I just meant to do instead of:
> 
> > +@item -s @var{script} @var{arg...}
> 
> you would
> 
> @item @var{script} @var{arg...}
> @itemx -s @var{script} @var{arg}
> 
> The other option would be
> 
> @item [-s] @var{script} @var{arg}
> 
> which is not as clear IMO.  I feel that it's important to have a good
> example up there, and making it clear that it's OK to just invoke Guile
> as "guile foo.scm" is important.  But your description is good too.

Thanks for the clarification.  I will add the two-line @item/@itemx pair.

> 
> > +For compatibility with some versions of Guile 1.4, you can also use the
> > +form @code{(symbol ...)} (that is, a list of only symbols that doesn't
> > +start with @code{@@}), which is equivalent to @code{(@@ (symbol ...)
> > +main)}, or @code{(symbol ...)  symbol} (that is, a list of only symbols
> > +followed by a symbol), which is equivalent to @code{(@@ (symbol ...)
> > +symbol)}.  We recommend to use the equivalent forms directly since they
> > +correspond to the @code{(@@ ...)}  read syntax that can be used in
> > +normal code.  See @ref{Using Guile Modules} and @ref{Scripting
> > +Examples}.
> 
> Again, probably worth eliding the deprecated 1.4 stuff...
> 

It's not clear to me what you mean here.  Please provide the
text that you would like.  (I did not review the
"command-line options" section for content because my
original proposal was to keep that section and add a missing
"environment variables" section.)

> > +@item --auto-compile
> > +Compile source files automatically (default behavior).
> > +
> > +@vnew{2.0}
> > +
> > +@item --no-auto-compile
> > +Disable automatic source file compilation.
> > +
> > +@vnew{2.0}
> 
> Need --fresh-auto-compile here too
> 
> > +@item GUILE_AUTO_COMPILE
> > +@vindex GUILE_AUTO_COMPILE
> 
> Need to note GUILE_AUTO_COMPILE=fresh, and @ref to Compilation
> 

I do not know what that option does (other than a guess).
There has been no update to the Guile manual page or the
reference manual mentioning it.

It appears that this "fresh" feature (no pun intended) has
been added since Guile 2.0.0.  'guile --help' does not
mention it for Guile 2.0.0.  I will add the text to update
my patches, if wanted, but I need for someone to provide me
with the text that they would like (i.e., the specification
for what the user should know).  Alternatively, they could
be added independently by a separate patch.

Once the "environment variables" section has been added to
the Guile Reference Manual, developers should be able to add
updates about them as part of an "atomic" patch that
describes the new feature and implements it.  Depending on
the change, this might involve updating:

   1) The text of the Guile Reference Manual
   2) The text provided by Guile's "--help" option
   3) The text of the Guile manual page
   4) The NEWS file: to describe new features and mark
   features as deprecated or obsolete.

--
 


Re: Patch: New section "Invoking Guile" for chapter "Programming in Scheme"

2011-04-24 Thread David Pirotte
Le Sun, 24 Apr 2011 23:00:16 +0200,
Andy Wingo  a écrit :

> Hi Mark,
> 
> Thanks for the revisions.
> ..

Hello Mark,
Andy,

While you are at the manual, may I point to some suggestion I made about the
structure and contents of the indexes which still is, IMHO, valid today. 
[wanted to
actually really point the email in guile-devel archive but but it didn't let me 
parse
before october 2009 ...]

I didn't and still don't have [yet] the skill to fluently and bug freely 
manipulate
large doc written in texinfo, otherwise I would have done it.

Cheers,
David

;;;
;;; here below, the 'most appropriate' email from the thread, I think
;;;

From: "Neil Jerram" 
To: "David Séverin" 
Cc: guile-devel 
Subject: Re: Plan for 2.0
Date: Mon, 5 Jan 2009 13:47:00 +

2009/1/4 Neil Jerram :
> 2009/1/4 David Séverin :  
>> Hi Guilers,
>>
>> It might be a small thing [and of course not a priority at all], but I'd 
>> love to
>> see a small evolution of the manual index structure in order to separate 
>> scheme
>> procedures from others, scheme variables from others...:
>>
>>* Concept Index
>>* Scheme Prodedure Index* C Procedure Index
>>* Scheme Variable Index * C Variable Index
>>* Scheme Type Index * C Type Index
>>* R5RS Index
>>
>> Being a scheme 'only' programmer, I'd love not to have to scroll through
>> gh_* and scm_* ... when I am looking for something in an index.  
>
> Thanks for this idea!
>
> I'm not persuaded by the procedure/variable/type separation  

I'm sorry, that's complete nonsense, as we already have the
procedure/variable/type separation.

So in fact now I completely agree with what you've suggested.

Regards,
Neil




Re: Indexing Scheme and C identifiers separately

2011-04-24 Thread Mark Harig


On Sun, Apr 24, 2011 at 07:09:07PM -0300, David Pirotte wrote:

> While you are at the manual, may I point to some
> suggestion I made about the structure and contents of the
> indexes which still is, IMHO, valid today. [wanted to
> actually really point the email in guile-devel archive but
> but it didn't let me parse before october 2009 ...]
> 
> I didn't and still don't have [yet] the skill to fluently
> and bug freely manipulate large doc written in texinfo,
> otherwise I would have done it.
> 
> Cheers,
> David
> 

> >> Hi Guilers,
> >>
> >> It might be a small thing [and of course not a priority
> >> at all], but I'd love to see a small evolution of the
> >> manual index structure in order to separate scheme
> >> procedures from others, scheme variables from
> >> others...:
> >>
> >>* Concept Index
> >>* Scheme Prodedure Index* C Procedure Index
> >>* Scheme Variable Index * C Variable Index
> >>* Scheme Type Index * C Type Index
> >>* R5RS Index
> >>
> >> Being a scheme 'only' programmer, I'd love not to have
> >> to scroll through gh_* and scm_* ... when I am looking
> >> for something in an index.

I do not know how you are reading the Guile Reference
Manual, but the printed version is about 809 pages long.  At
present, the indices run from page 755 to 809, so the
revision that is suggested, above, would not be small.

What would be of some help to get this project started is a
list of the identifiers:

  1) A list of all Scheme procedure names
  2) A list of all C procedure names
  3) A list of all Scheme variable names
  4) A list of all C variable names
  5) A list of all Scheme type names
  6) A list of all C type names

(By "all names", I mean "all names included in the Guile
Reference Manual", not, for example, "all C function names
in Standard C".)

To make the project more manageable, it could be done in
"atomic" sets.  

   1) Set 1 would be all Scheme and C procedure names
   2) Set 2 would be all Scheme and C variable names
   3) Set 3 would be all Scheme and C type names

Each of these sets could be added to the manual
independently over a period of time.

Also useful would be more suggestions for the Concept Index.
If you are using the reference manual and attempt to look
something up via the `Info-index' or `Info-virtual-index'
commands and are not able to locate what you are looking
for, then that is a good candidate for a report to the
bug-guile mailing list.  A `@cindex' entry can then be added
to the appropriate locations in the manual, making it more
useful and easier to use.

--
 


Re: Indexing Scheme and C identifiers separately

2011-04-24 Thread Noah Lavine
Hello,

> I do not know how you are reading the Guile Reference
> Manual, but the printed version is about 809 pages long.  At
> present, the indices run from page 755 to 809, so the
> revision that is suggested, above, would not be small.
>
> What would be of some help to get this project started is a
> list of the identifiers:
>
>   1) A list of all Scheme procedure names
>   2) A list of all C procedure names
>   3) A list of all Scheme variable names
>   4) A list of all C variable names
>   5) A list of all Scheme type names
>   6) A list of all C type names
>
> (By "all names", I mean "all names included in the Guile
> Reference Manual", not, for example, "all C function names
> in Standard C".)

Perhaps I am misunderstanding you, but I am afraid that you are not
aware that the indices are generated automatically. The relevant file
is "/doc/ref/indices.texi. It contains three
"@printindex" commands, which I suspect generate the indices.

Therefore the way to do this is not to remake the indices ourselves,
but to change the texinfo code that generates them for us.
Unfortunately, I do not know enough about texinfo to know what is
involved in this.

So the good news is that it will be much less work than it might seem
to re-do this. The bad news is that someone has to learn texinfo,
unless one of us already knows it.

Noah



Re: New feature proposal: Support C-code inline?

2011-04-24 Thread nalaginrut
> Well, is the code a piece of string ? Does that mean we'll have code
> generation on-the-fly facilities? ^_^
> 

yes. you don't need to convert var's type, this module does it automatic
for you.

> By the way,  do you like the idea of some kind of inline C-code
> "segments" embed in scm files? (Just like preprocessor blocks in C)

I think there're many new ideas worth trying, and your "C-code segment
embedded" is good for designing some bigger hybrid programming with
C&guile(this C-code inline is better for small code embedded). We may
add more convenient feature, for a instance, typedef/include/C macro. 
But as I said, this simple solution is a temporary substitute before AOT
compiler came out. Embedded big C-code into guile program is not a good
idea. If we really want to do that, the better way is to write an
extension just like Guile always does.

-- 
GNU Powered it
GPL Protected it
GOD Blessed it

HFG - NalaGinrut

--hacker key--
v4sw7CUSMhw6ln6pr8OSFck4ma9u8MLSOFw3WDXGm7g/l8Li6e7t4TNGSb8AGORTDLMen6g6RASZOGCHPa28s1MIr4p-x
 hackerkey.com
---end key---