2015/09/06
Small REPL info improvement
You could browse info document from REPL (ref:info), but it showed entire info page containing the searched entry. Even though it uses the pager, it's sometimes inconvenient if the page is lengthy.
I improved it a bit by the last commit. Now (1) info function
shows only the entry searched for, and (2) you can invoke info
function using top-level command.
gosh> ,info filter
-- Function: filter pred list
-- Function: filter! pred list
[SRFI-1] A procedure PRED is applied on each element of LIST, and
a list of elements that PRED returned true on it is returned.
(filter odd? '(3 1 4 5 9 2 6)) => (3 1 5 9)
`filter!' is the linear-update variant. It may destructively
modifies LIST to produce the result.
gosh>
If you still wants to view the entire page, info-page
function does the same job as the previous info function did
(I didn't make it toplevel REPL command yet.)
2015/08/19
Top-level REPL commands
Another little feature I'm playing for REPL improvements.
S-expression is great to represent tree structure, but it's a bit cumbersome to give simple commands in interactive shell; If the command line is short, the relative verbosity added by open and close parentheses gets in a way. Also in many cases simple commands take string arguments (e.g. to change working directory or to load file) and that require extra double quotes.
I'm not the only one to feel that way. In Allegro CL, if you
type a line begins with :, it is interpreted as special
toplevel command. Scheme 48 has similar command mode, beginning
with ,. I guess there are other implementations with
similar features.
So I started adding Scheme 48-ish command syntax. If the first
thing you type in the REPL prompt is a comma, an entire line is
read by read-line and parsed as a toplevel command,
instead of being read with read.
You can see current directory or move around:
gosh> ,pwd /home/shiro/src/Gauche/src gosh> ,cd "/home/shiro" gosh> ,cd src/Gauche "/home/shiro/src/Gauche"
You can run apropos:
gosh> ,a cons %tree-map-check-consistency (gauche) acons (gauche) cons (scheme) cons* (gauche) define-constant (gauche) lcons (gauche) lcons* (gauche) gosh> ,a trim srfi-13 string-trim (srfi-13) string-trim-both (srfi-13) string-trim-right (srfi-13)
or describe:
gosh> ,d 31415926 31415926 is an instance of class <integer> (#x1df5e76, ~ 29Mi, 1970-12-30T14:38:46Z as unix-time)
You can omit the argument for describe, in which case it takes the last value of REPL. Whenever you want to see the details of the last evaluation result, just type comma-d:
gosh> (sys-stat "Makefile") #<<sys-stat> 0x14e01e0> gosh> ,d #<<sys-stat> 0x14e01e0> is an instance of class <sys-stat> slots: type : regular perm : 436 mode : 33204 ino : 3295167 dev : 2097 rdev : 0 nlink : 1 uid : 500 gid : 500 size : 4599 atime : 1440031322 mtime : 1440031177 ctime : 1440031177
I'll gradually add more commands. Let me know your ideas.
2015/08/07
Write control variables
Oh well. More than a year since the last entry. So many things has loaded into HEAD and I have to wrap it up as 0.9.5. Some small issues to address, though.
As a part of improving REPL experience, I implemented CL-like
write control variables. Those like *print-length*. In
Gauche it looks like a parameter.
gosh> (parameterize ((print-length 5)) (write (iota 10))) (0 1 2 3 4 ...)#<undef>
I wanted them every time I accidentally evaluated huge data structure on REPL and just waited Emacs to finish showing it until the end (Ctrl-C can stop Gauche printing it, but it's mostly Emacs that's taking time to fill the buffer, especially when font-lock mode is on.)
By the way, print-base comes handy as desktop calculator
for base conversion:
gosh> (print-base 16) a gosh> (print-radix #t) #f gosh> 4758375874 #x11b9f0dc2
Now I've implemented four of various CL's printer control variables, and sit back and am thinking. Are they really useful as they seem to be?
The global nature of those controls is the problem. I'd like to
limit print-length on REPL output to avoid excessive output.
But doing so globally affects every operation, such as
serialization to file or network connection, which is almost certainly
undesirable. I can create a custom printer for REPL that changes
the controls only when it prints the result, but then I need
another set of API to set those values REPL would use.
Worse, now every routine that writes out values expecting it to
be read back must be wrapped with parameterize to ensure
those control variables are in the default value, otherwise it
can be broken accidentally when called with print-level set to 5.
The more I think, the more dubious I became about the CL's choice of making them dynamic variables.
Another idea I had before is to have a "context" object that packages
those controls, and you can set it to a parameter, instead of
parameterizing individual controls (the name ScmWriteContext in the
source was somewhat intended for that, but ended up for different
purpose.) With that, the REPL can have just one
repl-default-context and use that for just printing.
Recently I got yet another idea; let a port have those controls. We already have port-attributes to associate key-value pairs to ports. For serialization you'll usually create a fresh ports so the chance of inadvertent interference is very low. For REPL output, we can create a wrapper port connected to stdout so that it can have separate attributes, and use it for printing the results.
Some more pondering.
2014/07/20
Oops - gauche-package regression
Alert for those who start writing new extention package
with Gauche 0.9.4. When you create the skeleton files
by gauche-package generate, you need to tweak the
generated files to make them work.
Before going into details, I just describe what to do:
After generating skeleton files, edit configure
script to add the following stuff right after ;; Output
line:
(use gauche.package)
(let1 gpd-file #"~(cf$ 'PACKAGE_NAME).gpd"
(with-output-to-file gpd-file
(cut write-gauche-package-description
(make <gauche-package-description>
:name (cf$ 'PACKAGE_NAME)
:version (cf$ 'PACKAGE_VERSION)
:configure (string-join (command-line))))))
And in Makefile.in, remove configure from the
rule of maintainer-clean target, as shown in this patch.
maintainer-clean : clean - rm -rf $(CONFIG_GENERATED) configure VERSION + rm -rf $(CONFIG_GENERATED) VERSION
Now, the explanation.
0.9.4 is shipped with new gauche.configure module,
which attempts to replace autoconf-based configuration
to build Gauche extensions.
Autoconf is well-built system,
but it makes great effort to make configure scripts work
on a minimal environment. In order to do so, it requires an
extra step for developers to generate configure script
from configure.ac etc. It is reasonable for distributing
basic tools to the destination platform that lacks them.
However, when installing Gauche extensions, we know for sure that the destination platform already have Gauche installed, so the configure script doesn't need to be restricted in the minimal shell features. In fact, we can write configure script itself as a Gauche script, eliminating the step for developers to generate configure script from other files.
Nowadays more and more projects don't bother to create distribution tarballs and ask users to just pull from repository. Making configure script a source, not something to be generated, has advantage for not requiring users to run autoconf.
So I migrated the default skeleton files to use new configure features. But I forgot to cover a couple of points, as shown above.
The .gpd file is to keep metadata of the extension package.
In the old skeleton configure.ac file, it is generated by
calling gauche-package make-gpd. My plan is to provide
an easier API in gauche.configure, which will be in the
next version of Gauche.
And of course, we no longer need to remove configure in
maintainer-clean!
Autoconf has comprehensive feature tests gauche.configure can't
match. If you need advanced feature tests, you may still want to use
autoconf-based configuration. Just give --autoconf option
to gauche-package generate, and it gives you configure.ac.
gauche-package generate --autoconf YOUR-PACKAGE-NAME
Tags: 0.9.4, Extension, gauche-package
2014/07/20
0.9.4 is out!
Thanks for those who tested release candidates.
Tarball:
- http://prdownloads.sourceforge.net/gauche/Gauche-0.9.4.tgz
- http://prdownloads.sourceforge.net/gauche/Gauche-0.9.4.tgz.asc (signature)
Windows installer (including Gauche-gl):
- http://prdownloads.sourceforge.net/gauche/Gauche-mingw-0.9.4.msi
- http://prdownloads.sourceforge.net/gauche/Gauche-mingw-0.9.4.msi.asc (signature)
Release notes:
Comments (0)