Re: Guile and Curses
Mike Gran <[EMAIL PROTECTED]> writes: > [3] http://gano.sourceforge.net/ Hi Mike, Gano is very interesting. I agree with you that it would make a great "toy" program. Are you aware of the Emacs Lisp translation code in 1.8.x, in lang/elisp/* ? I haven't touched it for a while, but in principle (and when completed) it would allow an editor such as Gano to reuse Emacs Lisp libraries - as long as the editor and Guile jointly provide a sufficient set of Emacs-like primitives. (This doesn't mean that Gano would have to be an exact clone of base Emacs, just that it has to provide equivalent function. We can write code for any primitive mapping that is needed.) One detail I couldn't understand: how does the use of GtkTextBuffer go with being a console application? Regards, Neil ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: Guile and Curses
--- Neil Jerram <[EMAIL PROTECTED]> wrote: > Are you aware of the Emacs Lisp translation code in 1.8.x, in > lang/elisp/* ? I haven't touched it for a while, but in principle > (and when completed) it would allow an editor such as Gano to reuse > Emacs Lisp libraries - as long as the editor and Guile jointly > provide > a sufficient set of Emacs-like primitives. > I haven't looked at it before. I'll check it out. > One detail I couldn't understand: how does the use of GtkTextBuffer > go > with being a console application? > GtkTextBuffer just stores the text of a buffer (as a B-Tree) and also holds a list of "tags", which are generic attributes assigned to characters, lines, or paragraphs. It is the "model" of the model-view-controller. That's the part I'd port over. GtkTextView is the "view", which I'd end up replacing. Thanks, Mike Gran ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
(system cmd) not working after slib
Gentle guile users, I wonder if one of you could help me. I am thrilled to find that use of (ice-9 slib) has been improved in guile 1.8.3. I am confused about its behavior, though. The (system) command works fine before I load slib. After I load slib, guile no longer understands what "system" means. (system "ls"); works (use-modules (ice-9 slib)) ; works (system "ls"); no longer works I enclose a short transcript below. Any suggestions would be appreciated. Thanks, Scott Walck [EMAIL PROTECTED]:~/computer/notes]$ guile --version Guile 1.8.3 Copyright (c) 1995, 1996, 1997, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation Guile may be distributed under the terms of the GNU General Public Licence; certain other uses are permitted as well. For details, see the file `COPYING', which is included in the Guile distribution. There is no warranty, to the extent permitted by law. [EMAIL PROTECTED]:~/computer/notes]$ guile guile> (system "ls") DataTransfer.txt guile.txt networking PrinterDrivers success DataTransfer.txt~ installation.txt networking~ PrinterDrivers~ Zip250.txt GarberPrinting installation.txt~ ppp printing Zip250.txt~ GarberPrinting~lvcweb.txt ppp~ printing~ 0 guile> (use-modules (ice-9 slib)) WARNING: (guile-user): imported module (ice-9 slib) overrides core binding `gentemp' guile> *slib-version* "3a4" guile> (system "ls") Backtrace: In current input: 4: 0* (system "ls") :4:1: In expression (system "ls"): :4:1: Unbound variable: system ABORT: (unbound-variable) guile> ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: Why there's no debugger?
On Tue, Oct 23, 2007 at 01:41:57PM +0100, Neil Jerram wrote: > Josef Wolf <[EMAIL PROTECTED]> writes: > > I followed the suggestion from the info pages and put following into my > > ~/.guile file: > > Which info pages were those? The info for 1.6.7 does not mention > (ice-9 debugger breakpoints ...), because those modules are not > included in 1.6.7. > > To do debugging with 1.6.7, you need to download and install the > latest guile-debugging tarball/.deb from > http://download.gna.org/guile-debugging/. Please see the README file > there for an explanation of how guile-debugging relates to Guile CVS, > and for where to look for guile-debugging documentation. > > (To confuse matters, the manual of recent Guile 1.8.x releases > incorrectly documents these features, which are not actually present > in Guile 1.8.x. The manual should be fixed for the next 1.8.x release.) Thanks for the answer, Neil. You are right, I read it on a guile 1.8 installation. At the time I wrote the mail, I had 1.6.7 and I failed to remember that I read it on the other box. Sorry for the confusion! I guess the debugging will be included in some future guile release? ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Anyone relying on "break-at" breakpoints?
This email pertains to the debugging and breakpoint infrastructure in
Guile CVS, which has so far only been released as part of my
guile-debugging package. If you've never looked at or used this
infrastructure, you can safely skip the rest of this message.
I've been wrestling for a while with specifying and documenting
exactly how "break-at" breakpoints should behave, and have concluded
that the problem arises from how these breakpoints are defined.
Therefore I'm looking at removing them (in their current form), and
hence this email to check if anyone would be inconvenienced by that.
A break-at breakpoint is defined by a file name, a line number and a
column number, and it means that Guile should break when executing the
code from the named file whose opening parenthesis is at the specified
line and column. It should work both if the relevant code was loaded
before the breakpoint was defined, and if the code is loaded after the
breakpoint is defined. In other words, it's the Guile equivalent of
GDB's "break :" for C.
The trouble is that Guile (unlike C) is an interactive environment.
Someone might write a first version of a function:
(define (my-func . args)
(let ((a (car args))
...)
...))
then evaluate and try it, then decide that it works better with an
internal definition:
(define (my-func . args)
(define (helper arg1)
...)
(let ((a (car args))
...)
...))
then evaluate the new version, and so on. Suppose that when trying
out the first version, the coder defined a break-at breakpoint at the
position of the "(let". Then after the redefinition (and assuming the
current specification and implementation of break-at breakpoints), the
breakpoint would be in the wrong place: it would apply to the
"(define", and would not apply to the "(let" in its new position.
This is a simple example, but there are many possible variations and
complications of it (for example, lambda-constructing code, which has
the consequence that we cannot say that there is only one "correct"
version of the source code at a given time), which make finding a nice
general solution very difficult.
By way of contrast, the other kind of breakpoint ("break-in") does not
suffer from this problem, because it is defined in a way that relates
more persistently to the code (even as the code changes). A break-in
breakpoint is defined as
break-in []
and means break at the start of that procedure.
It could be argued that break-at breakpoints are fine for the "static"
case - i.e. for debugging a program and not changing it at the same
time - and hence we should keep them for this. But I'd much rather
develop a better conceptual solution that works equally well for both
the static and interactive cases.
Therefore, I'm planning to simply drop "break-at" breakpoints (and the
associated trap), and then to reconsider the scenarios
for which I thought "break-at" was the solution, to work out better
solutions instead.
If there are scenarios that you (anyone!) are actually using and
relying on, please let me know, so that I can make sure that I have an
alternative solution ready for you. If you have any questions,
suggestions or concerns about all this, please let me know those too.
Thanks for reading; I hope it all made some kind of sense. :-)
Regards,
Neil
___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
Re: Why there's no debugger?
Josef Wolf <[EMAIL PROTECTED]> writes: > Thanks for the answer, Neil. You are right, I read it on a guile 1.8 > installation. At the time I wrote the mail, I had 1.6.7 and I failed > to remember that I read it on the other box. Sorry for the confusion! No problem. A lot of the confusion stems from my slowness working on this, I'm afraid. > I guess the debugging will be included in some future guile release? Well that's more likely than being in a past release. :-) More seriously: I strongly want to get this area (debugging and Emacs interface) to a state where it is complete (for the immediate use cases that occur to me), coherent and fully documented; and I hope to achieve that in the next few months. Then we can look at what makes sense in terms of releases. Regards, Neil ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
