Re: Guile with win32 cross compiling
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?
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"
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"
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"
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"
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
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
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?
> 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---