From csr21 at cam.ac.uk Mon Apr 4 09:37:02 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 04 Apr 2005 10:37:02 +0100 Subject: [climacs-devel] interactor / minibuffer redraw Message-ID: Hi, It is my suspicion that there is a problem in climacs' toplevel loop, such that the minibuffer contents aren't preserved over certain interactions. It could of course be a problem in a lower layer... To see the problem, arrange such that there is a climacs window with the minibuffer area able to be obscured by another window -- something like +--------------------+ | | +---| climacs | | | | | +--------------------+ | xterm | +----------+ then type (for instance) M-x Set Bring the xterm to the front, obscuring the climacs minibuffer, then bring the climacs window back. Type SPC Sy SPC and note that the second SPC completes "Syntax" for you, but then prints "No such command" in the minibuffer. The particular instance of this that I would dearly love to see fixed -- but I suspect that it's the same problem in any case -- is that this makes the use of the possible completions gesture (C-/) useless in the context of C-x C-f: create a small text file in /tmp/ by other means, and then do C-x C-f /t C-/ a (partial) completions window pops up: choose /tmp/, and then attempt to select your file; I get debugger invoked on a SIMPLE-ERROR in thread 12565: # is not contained in #. from CLIM:ERASE-OUTPUT-RECORD Any ideas? (I'd love a quick fix, but... I appreciate that this may not be easy) Cheers, Christophe From csr21 at cam.ac.uk Tue Apr 5 20:44:35 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 05 Apr 2005 21:44:35 +0100 Subject: [climacs-devel] more context-sensitive parsing Message-ID: Hi, In prolog, there are so-called operator directives, of the basic form: :- op(=@=,100,xfy). such that this defines a right-associative operator named =@=. In order to parse the rest of the file properly, it would be good, on parsing this directive, to alter the parser to recognize this kind of construct. I have hooks in prolog-syntax.lisp for this -- the FIND-DEFINED-OPERATOR function -- but given that in principle we could be visiting several prolog files at once, defined operators should really be buffer-local. So the logical place to stash information about such a user-defined operator would be the syntax, I think, but I don't have access to the syntax from a grammar rule (or do I?) Any ideas, suggestions? The other possibility, I suppose, is to make the user do this, maybe through a Climacs command Define Operator. (This probably isn't the most urgent of issues, but I do have a large amount of prolog code with many operator definitions, and no other real code to test my parser against). Cheers, Christophe From strandh at labri.fr Wed Apr 6 05:56:59 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 6 Apr 2005 07:56:59 +0200 Subject: [climacs-devel] latest progress Message-ID: <16979.31275.3405.782418@serveur5.labri.fr> Dear Mailing-list member, Nearly three weeks have gone by since the previous progress report. The main reason for that is that I have had some computer trouble (my main development computer was pirated, and I decided to reinstall a newer OS), and some other difficulties that I won't bore you with. The net result is that there has not been as much progress on Climacs from me as I had hoped. Nevertheless, Christophe Rhodes and Aleksandar Bakic have been making great progress in my absence. Perhaps the most exciting thing that happened is that Christophe Rhodes write a syntax module for Prolog. This work, together with the oddities of Prolog syntax, has exposed some limitations to the current parsing framework (based on a modified Earley parsing algorithm), but generally confirmed that writing a syntax module using this framework is not exceptionally hard. There is still some code factoring needed, especially with respect to parse-stack-driven redisplay. And I still don't know how to write a general-purpose protocol for exploiting the parse stack in interesting ways other than for redisplay. Here is a list of what happened since the previous report: * Improved the parsing framework by abstracting out certain features from html-syntax.lisp to syntax.lisp in order to make them more generally useful. Also did some code factoring. * Implementation of the undo protocol for the persistent buffer implementation. (thanks to Aleksandar Bakic) * Made several improvements to HTML-mode. Now, the add-rule macro is used so as to regroup all aspects of an HTML construct instead of having the grammar rule close to the code for creating the grammar. Introduced a macro `add-html-rule' inspired by the work of Christophe Rhodes on the Prolog syntax. Added grammar rules for recognizing string and the DIR and LANG attributes. Improved the code for recognizing the HREF attribute. * Fixed a file-order problem in climacs.asd (thanks to Aleksandar Bakic) * Syntax module for the Prolog programming language (see above). (thanks to Christophe Rhodes) * Fixed a redisplay bug reported by Christophe Rhodes. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Wed Apr 6 06:17:23 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 6 Apr 2005 08:17:23 +0200 Subject: [climacs-devel] more context-sensitive parsing In-Reply-To: References: Message-ID: <16979.32499.667309.652476@serveur5.labri.fr> Hello, Christophe Rhodes writes: > > In prolog, there are so-called operator directives, of the basic form: > > :- op(=@=,100,xfy). > > such that this defines a right-associative operator named =@=. > > In order to parse the rest of the file properly, it would be good, on > parsing this directive, to alter the parser to recognize this kind of > construct. That is one thing the Earley parsing framework is good for. > I have hooks in prolog-syntax.lisp for this -- the > FIND-DEFINED-OPERATOR function -- but given that in principle we could > be visiting several prolog files at once, defined operators should > really be buffer-local. So the logical place to stash information > about such a user-defined operator would be the syntax, I think, Or you could make a copy of the grammar for each buffer and add new rules to the grammar. Though that is a bit tricky, because if you delete that line, you do want the rule to be removed as well. I haven't given it enough thought, but it seems like the right way to handle this an similar on-the-fly grammar modifications is to have each parse state contain a reference to the grammar to be used for further parsing, and to make state transitions allow for a modified version of the grammar to be passed on to the next state. Such a mechanism could also be used for switching grammars for situations such as SQL embedded in C or PHP embedded in HTML. > but I > don't have access to the syntax from a grammar rule (or do I?) No, not at the moment. You don't even have access to the grammar, I think. But that could be fixed. > Any ideas, suggestions? The other possibility, I suppose, is to make > the user do this, maybe through a Climacs command Define Operator. > (This probably isn't the most urgent of issues, but I do have a large > amount of prolog code with many operator definitions, and no other > real code to test my parser against). Well, if it is not urgent, I would suggest you (and others) start thinking about the more general idea outlined above. The more general problem of switching grammars in the middle of a buffer has one incompatibility with the incremental lexer that is used for HTML syntax (and that will be used for CL syntax as well), namely that the lexer might have to change as well when the grammar changes. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Tue Apr 12 18:11:03 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 12 Apr 2005 19:11:03 +0100 Subject: [climacs-devel] cached grammar Message-ID: Hi, Is the attached what you (Robert) were thinking of for cacheing some portions of HANDLE-ITEM? If so, well, here it is, along with an optimization to ITEM-EQUAL. Unfortunately, it's still too slow -- in the attached prolog file in Prolog Syntax, typing in the comment at the top of the buffer has noticeable lag on my 2.8GHz x86. About 50% of the time is spent in HANDLE-ITEM and callees, according to sb-sprof, of which about half is in ITEM-EQUAL. Any ideas? (Can other people reproduce this kind of performance characteristic, for one?) Is it possible that the grammar is in some way badly formed, and is there a way of checking this automatically? Cheers, Christophe -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: grammarhash.diff URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: foo.pl Type: text/x-prolog Size: 456 bytes Desc: foo.pl URL: From strandh at labri.fr Wed Apr 13 04:20:42 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 13 Apr 2005 06:20:42 +0200 Subject: [climacs-devel] cached grammar In-Reply-To: References: Message-ID: <16988.40474.289718.861864@serveur5.labri.fr> Christophe Rhodes writes: > Hi, > > Is the attached what you (Robert) were thinking of for cacheing some > portions of HANDLE-ITEM? Yes, except that I was not going to be as brutal about recomputing the cache at each time. I was thinking add-rule should do: 1. For each symbol of the right hand side of the new rule If the symbol is not a key in the hash table then add it by setting the entry to '() loop for each existing rule if lhs of existing rule is compatible with symbol then push rule onto the list 2. Loop for all entries in the hash table If the lhs of the new rule is compatible with the key in the entry then push the new rule on that entry > If so, well, here it is, along with an optimization to ITEM-EQUAL. > Unfortunately, it's still too slow -- Ouch. > in the attached prolog file in > Prolog Syntax, typing in the comment at the top of the buffer has > noticeable lag on my 2.8GHz x86. About 50% of the time is spent in > HANDLE-ITEM and callees, according to sb-sprof, of which about half is > in ITEM-EQUAL. This is very strange. Normally, the previous algorithm was quadratic and this one no longer is. Of course, if the problem is item-equal, that's a different story. I am guessing that the speedup is significant, though perhaps not enough, and that the bottleneck is now in item-equal. > Any ideas? (Can other people reproduce this kind of performance > characteristic, for one?) HTML syntax is too slow as well (before the patch). But I am having trouble with incremental redisplay, so it is hard to tell what is slower, redisplay or parsing. > Is it possible that the grammar is in some > way badly formed, and is there a way of checking this automatically? If that were the case, you would get some kind of quadratic or cubic behavior (in the size of the input). This can happen for certain grammars. In that case, you would get terrible performance on a long input buffer even when using a relatively small window at the end of it. That is a fairly easy test to make. You could also count the number of items in various parser states to see whether it grows linearly with the position in the buffer. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Wed Apr 13 04:25:28 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 13 Apr 2005 06:25:28 +0200 Subject: [climacs-devel] cached grammar In-Reply-To: References: Message-ID: <16988.40760.568398.738834@serveur5.labri.fr> Christophe Rhodes writes: > -(defmethod item-equal ((item1 incomplete-item) (item2 incomplete-item)) > +(defun item-equal (item1 item2) > + (declare (optimize speed)) > (and (eq (rule item1) (rule item2)) > - (eq (length (parse-trees item1)) (length (parse-trees item2))) > - (every #'parse-tree-equal (parse-trees item1) (parse-trees item2)))) > + (do ((trees1 (parse-trees item1) (cdr trees1)) > + (trees2 (parse-trees item2) (cdr trees2))) > + ((and (null trees1) (null trees2)) t) > + (when (or (null trees1) (null trees2)) > + (return nil)) > + (when (not (parse-tree-equal (car trees1) (car trees2))) > + (return nil))))) Are you sure this is an improvement? If parse-tree-equal is relatively slow and there is a prefix of the parse trees that are equal but the length of the two lists is not equal, then many unnecessary tests for parse-tree-equal are made. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Wed Apr 13 04:31:02 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 13 Apr 2005 06:31:02 +0200 Subject: [climacs-devel] cached grammar In-Reply-To: References: Message-ID: <16988.41094.608058.641227@serveur5.labri.fr> Christophe Rhodes writes: > About 50% of the time is spent in > HANDLE-ITEM and callees, according to sb-sprof, of which about half is > in ITEM-EQUAL. Another suggestion for improving performance is this: item-equal is called on each item that is valid from a particular state to another state and those items are stored in a linear list. If there are many items, it might be better to store them in a hash table indexed by (say) the left-hand side. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Wed Apr 13 10:51:23 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 13 Apr 2005 11:51:23 +0100 Subject: [climacs-devel] cached grammar In-Reply-To: <16988.40474.289718.861864@serveur5.labri.fr> (Robert Strandh's message of "Wed, 13 Apr 2005 06:20:42 +0200") References: <16988.40474.289718.861864@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Christophe Rhodes writes: > > Is the attached what you (Robert) were thinking of for cacheing some > > portions of HANDLE-ITEM? > > Yes, except that I was not going to be as brutal about recomputing the > cache at each time. I was thinking add-rule should do: > > 1. For each symbol of the right hand side of the new rule > If the symbol is not a key in the hash table > then add it by setting the entry to '() > loop for each existing rule > if lhs of existing rule is compatible with symbol > then push rule onto the list > 2. Loop for all entries in the hash table > If the lhs of the new rule is compatible with the key in the entry > then push the new rule on that entry Yeah. Since for me ADD-RULE is a load-time operation, I thought I wouldn't spend too much time making its effects incremental, and went for the sledgehammer rather than the scalpel. > > in the attached prolog file in > > Prolog Syntax, typing in the comment at the top of the buffer has > > noticeable lag on my 2.8GHz x86. About 50% of the time is spent in > > HANDLE-ITEM and callees, according to sb-sprof, of which about half is > > in ITEM-EQUAL. > > This is very strange. Normally, the previous algorithm was > quadratic and this one no longer is. > > Of course, if the problem is item-equal, that's a different story. I > am guessing that the speedup is significant, though perhaps not > enough, and that the bottleneck is now in item-equal. I think about 20% of the total time is spent in item-equal. Another 20% is spent in handle-item but not item-equal. I'm pretty sure that the modification to item-equal is a net win, at least for sbcl, because parse-tree-equal (which simply compares the results of two class-ofs) is not a time consuming operation at all -- an insignificant amount of time is spent in parse-tree-equal, according to my traces. Cheers, Christophe From csr21 at cam.ac.uk Wed Apr 13 11:41:23 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 13 Apr 2005 12:41:23 +0100 Subject: [climacs-devel] cached grammar In-Reply-To: <16988.40760.568398.738834@serveur5.labri.fr> (Robert Strandh's message of "Wed, 13 Apr 2005 06:25:28 +0200") References: <16988.40760.568398.738834@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Christophe Rhodes writes: > > -(defmethod item-equal ((item1 incomplete-item) (item2 incomplete-item)) > > +(defun item-equal (item1 item2) > > + (declare (optimize speed)) > > (and (eq (rule item1) (rule item2)) > > - (eq (length (parse-trees item1)) (length (parse-trees item2))) > > - (every #'parse-tree-equal (parse-trees item1) (parse-trees item2)))) > > + (do ((trees1 (parse-trees item1) (cdr trees1)) > > + (trees2 (parse-trees item2) (cdr trees2))) > > + ((and (null trees1) (null trees2)) t) > > + (when (or (null trees1) (null trees2)) > > + (return nil)) > > + (when (not (parse-tree-equal (car trees1) (car trees2))) > > + (return nil))))) > > Are you sure this is an improvement? If parse-tree-equal is relatively > slow and there is a prefix of the parse trees that are equal but the > length of the two lists is not equal, then many unnecessary tests for > parse-tree-equal are made. Here is some relevant profiling data, from a run where I've typed in the top comment of foo.pl, in climacs with my patch applied. Self Cumul Total Nr Count % Count % Count % Function ------------------------------------------------------------------------ 1 110 17.9 111 18.0 110 17.9 (SB-C::XEP (LAMBDA (SB-PCL::.ARG0.))) 2 34 5.5 227 36.9 144 23.4 (SB-PCL::FAST-METHOD CLIMACS-SYNTAX::HANDLE-ITEM (CLIMACS-SYNTAX::INCOMPLETE-ITEM T T)) 3 34 5.5 74 12.0 178 28.9 CLIMACS-SYNTAX::ITEM-EQUAL 4 33 5.4 33 5.4 211 34.3 "no debug information for frame" 5 29 4.7 31 5.0 240 39.0 (SB-C::HAIRY-ARG-PROCESSOR GETHASH) 6 19 3.1 19 3.1 259 42.0 "foreign function closure_tramp" 7 18 2.9 31 5.0 277 45.0 (SB-C::XEP (LAMBDA (SB-PCL::.ARG0. SB-PCL::.ARG1. "#<...>" . "#<...>"))) 8 17 2.8 17 2.8 294 47.7 "foreign function sigprocmask" 9 16 2.6 17 2.8 310 50.3 (SB-C::TL-XEP SB-KERNEL:SUB-GC) 10 15 2.4 15 2.4 325 52.8 (SB-C::TL-XEP SB-KERNEL::%%TYPEP) 11 13 2.1 20 3.2 338 54.9 (SB-C::TL-XEP SB-KERNEL:VALUES-SPECIFIER-TYPE) [...] 85 1 0.2 2 0.3 558 90.6 CLIMACS-SYNTAX::PARSE-TREE-EQUAL So PARSE-TREE-EQUAL takes up an apparently insignificant amount of time compared with ITEM-EQUAL and HANDLE-ITEM (INCOMPLETE-ITEM T T). One might wonder what %%TYPEP and VALUES-SPECIFIER-TYPE are doing there. They come in because the class definitions and prolog grammar rules are in the same file: defclass at compile-time does not provide the type system with complete information about the forthcoming class, so typep on those class names cannot be compiled efficiently. If the file is recompiled, these calls will go away, but since they collectively account for only 5% of the total time, it's not the bottleneck in any case. Cheers, Christophe From csr21 at cam.ac.uk Wed Apr 13 13:40:20 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 13 Apr 2005 14:40:20 +0100 Subject: [climacs-devel] #\Tab mistreatment Message-ID: Hi, Tabs in buffers seem mistreated in html syntax (as well as Prolog syntax, which copies the behaviour): the horizontal cursor position does not reflect the presence of tabs on a given line, so that a buffer containing ab in html syntax will misdraw the cursor when it is logically at the position of the b. Cheers, Christophe From csr21 at cam.ac.uk Wed Apr 13 17:24:02 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 13 Apr 2005 18:24:02 +0100 Subject: [climacs-devel] cached grammar In-Reply-To: <16988.40474.289718.861864@serveur5.labri.fr> (Robert Strandh's message of "Wed, 13 Apr 2005 06:20:42 +0200") References: <16988.40474.289718.861864@serveur5.labri.fr> Message-ID: Robert Strandh writes: > This is very strange. Normally, the previous algorithm was > quadratic and this one no longer is. Isn't it still quadratic in the number of incomplete items, thanks to the FIND ITEM ... in the first test of the COND? Cheers, Christophe From amoroso at mclink.it Wed Apr 27 16:19:52 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Wed, 27 Apr 2005 18:19:52 +0200 Subject: [climacs-devel] Re: [climacs-cvs] CVS update: climacs/cl-syntax.lisp In-Reply-To: <20050427140204.943F188030@common-lisp.net> (Pascal Fong Kye's message of "Wed, 27 Apr 2005 16:02:04 +0200 (CEST)") References: <20050427140204.943F188030@common-lisp.net> Message-ID: <878y3442fr.fsf@plato.moon.paoloamoroso.it> pfong at common-lisp.net (Pascal Fong Kye) writes: > Update of /project/climacs/cvsroot/climacs > In directory common-lisp.net:/tmp/cvs-serv19847 > > Modified Files: > cl-syntax.lisp > Log Message: > cl-syntax > Date: Wed Apr 27 16:02:03 2005 Would it be possible to have slightly less terse and more informative log messages? Thanks anyway, Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From pfongkye at yahoo.com Wed Apr 27 18:56:52 2005 From: pfongkye at yahoo.com (fongkye pascal) Date: Wed, 27 Apr 2005 19:56:52 +0100 (BST) Subject: [climacs-devel] Re: [climacs-cvs] CVS update: climacs/cl-syntax.lisp In-Reply-To: 6667 Message-ID: <20050427185652.86981.qmail@web40424.mail.yahoo.com> --- Paolo Amoroso wrote: > Would it be possible to have slightly less terse and > more informative > log messages? Thanks anyway, > > > Paolo > -- > Lisp Propulsion Laboratory log - > http://www.paoloamoroso.it/log > _______________________________________________ > climacs-devel mailing list > climacs-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/climacs-devel > I'm sorry but we have been doing some clean-ups like good indentations, making the code a bit more representative of a lisp code in a way... Anyway thanks for your remarks, I will do better next time... Cheers Pascal Send instant messages to your online friends http://uk.messenger.yahoo.com From strandh at labri.fr Thu Apr 28 05:49:36 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 28 Apr 2005 07:49:36 +0200 Subject: [climacs-devel] latest progress Message-ID: <17008.31088.264466.546394@serveur5.labri.fr> Dear mailing-list member, There is no doubt that the most exciting thing that has happened since the previous progress report is that Climacs now has a syntax module for Common Lisp. A group of four students: Nada Ayad, Julien Cazaban, Pascal Fong Kye, and Bruno Mery, have been working for the past two months or so to get this working. The first commits were made last week (just in time for me to announce it at the Amsterdam Lisp meeting), and we have seen a steady stream of improvements since then. In theory, the project is due tomorrow, so there is definitely the possibility that this stream will stop after that. So feel free to play around with the features, submit patches, add new features, etc. I am discovering the features myself now, so I am sure I do not yet have the full picture. Yesterday, I tested some of the syntax highlighting features, and I am already impressed. For instance, trying to use a digit that is not valid for the radix in the CL #nrxxx construct makes the token change colors. There are still some problems, of course, that may or may not be fixed by tomorrow. I advice against major modifications on your part before that. Other improvements since the previous progress report: * Improvements to Prolog syntax. (thanks to Christophe Rhodes) * Improvements to HTML syntax (organize the grammar around concepts in the standard, more elements, performance improvements). * Performance improvements of the Earley Parser in the form of precomputed prediction rules and a faster test for whether a rule has been predicted. Also avoid generic-function dispatch on functions that are called frequently. (thanks in part to Christophe Rhodes) The next speed improvement to the parsing framework might be to allow for a "manual" test to determine whether a rule is valid for prediction. To illustrate this idea for CL syntax: currently, whenever an expression is expected, all rules that handle the dispatch macro character #\# will be predicted. However, most often, the next lexeme is not #\#, so these predictions will not be used further. They must, however, be traversed when the completer searches this state for valid incomplete items. All this is costly. A simple test that makes it possible to test the next lexeme when a rule is about to be predicted could cut down on this work considerably. A similar phenomenon will occur in HTML mode when each inline element will be predicted for each word in an ordinary paragraph of text. Keep up the good work. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From ignas.mikalajunas at gmail.com Thu Apr 28 10:23:31 2005 From: ignas.mikalajunas at gmail.com (Ignas Mikalajunas) Date: Thu, 28 Apr 2005 13:23:31 +0300 Subject: [climacs-devel] Bugs reporting :) Message-ID: Hi, i like the idea of Common lisp emacs like editor, and i would like to test it, but it seemsso unuseable to me that i just can't even test it :(, the bugs i have managed to encounter in like 3 minutes of using climacs were: 1. C-x C-f Ret It tries to open my home directory and of course fails (I know there is no dired, but crashing my editor because of that is evil) 2. C-x C-f /home/ignas/test.lisp , then Alt+Tab to another window (covering the climacs window), Alt+Tab back, Ret * (climacs-gui::climacs) debugger invoked on a SIMPLE-ERROR in thread 17344: # is not contained in #. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. ((SB-PCL::FAST-METHOD CLIM:ERASE-OUTPUT-RECORD (T CLIM:STANDARD-OUTPUT-RECORDING-STREAM)) # # # # NIL) 0] :backtrace 0: ((SB-PCL::FAST-METHOD CLIM:ERASE-OUTPUT-RECORD (T CLIM:STANDARD-OUTPUT-RECORDING-STREAM)) # # # # NIL) 1: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::FINALIZE (GOATEE:GOATEE-INPUT-EDITING-MIXIN T)) # # # #) 2: ((FLET #:CLEANUP-FUN-677)) 3: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING (CLIM:EXTENDED-INPUT-STREAM T T T T)) # # # # # "" CLIM:STANDARD-INPUT-EDITING-STREAM) 4: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING :AROUND (CLIM:EXTENDED-OUTPUT-STREAM T T T T)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (5)) :ARG-INFO (5)) # # # "" CLIM:STANDARD-INPUT-EDITING-STREAM) 5: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.DFUN-REST-ARG.)) # # # CLIMACS-GUI::COMPLETABLE-PATHNAME (:PROMPT "Find File")) 6: (CLIM:ACCEPT CLIMACS-GUI::COMPLETABLE-PATHNAME :PROMPT "Find File") 7: (CLIMACS-GUI::COM-FIND-FILE) 8: ((SB-PCL::FAST-METHOD CLIM:EXECUTE-FRAME-COMMAND :AROUND (CLIMACS-GUI::CLIMACS T)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) # (CLIMACS-GUI::COM-FIND-FILE)) 9: ((FLET CLIMACS-GUI::DO-COMMAND) (CLIMACS-GUI::COM-FIND-FILE)) 10: (CLIMACS-GUI::CLIMACS-TOP-LEVEL # :COMMAND-PARSER # :COMMAND-UNPARSER # :PARTIAL-COMMAND-PARSER # :PROMPT #) 11: (CLIMACS-GUI::CLIMACS-TOP-LEVEL #) 12: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL (CLIM:APPLICATION-FRAME)) # # # #) 13: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND (CLIM:APPLICATION-FRAME)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) # NIL) 14: (SB-INT:EVAL-IN-LEXENV (CLIMACS-GUI::CLIMACS) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((COMPILATION-SPEED . 1) (DEBUG . 1) (INHIBIT-WARNINGS . 1) (SAFETY . 1) (SPACE . 1) (SPEED . 1) (SB-C::STACK-ALLOCATE-DYNAMIC-EXTENT . 3)))) 15: (INTERACTIVE-EVAL (CLIMACS-GUI::CLIMACS)) 16: (SB-IMPL::REPL-FUN NIL) 17: ((LAMBDA NIL)) 18: ((LAMBDA NIL)) 19: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #) 20: (SB-IMPL::TOPLEVEL-REPL NIL) 21: (SB-IMPL::TOPLEVEL-INIT) 22: ((FLET SB-IMPL::RESTART-LISP)) 3. Alt+x is not invoking "Extended command", only Esc+x did that ... 4. Common Lisp syntax mode is only coloring the first line of the buffer, (the rest are highlighted as if they were comments) in cmucl, and is highlighting everything up-to first ";" in sbcl. Ignas Mikalaj?nas From csr21 at cam.ac.uk Thu Apr 28 19:04:30 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 28 Apr 2005 20:04:30 +0100 Subject: [climacs-devel] Bugs reporting :) In-Reply-To: (Ignas Mikalajunas's message of "Thu, 28 Apr 2005 13:23:31 +0300") References: Message-ID: Ignas Mikalajunas writes: > Hi, i like the idea of Common lisp emacs like editor, and i would like > to test it, but it seemsso unuseable to me that i just can't even test > it :(, the bugs i have managed to encounter in like 3 minutes of using > climacs were: Just so you know, this is the third draft of a response to your e-mail: the previous two were deleted on grounds of excessive temperature. This is of course my fault for reacting badly to what you wrote, but you might be interested that it provoked that reaction. Put bluntly: climacs doesn't really need testers at the moment: it needs people who will do more than use it for just like 3 minutes, by fixing the problems that they encounter rather than simply recounting them. Testing and posting bug reports has a certain value, but there simply isn't the manpower to fix bugs in any kind of timely manner without more effort on the reporter's part, say by providing a patch to fix the bad behaviour. > 1. C-x C-f Ret > > It tries to open my home directory and of course fails (I know there > is no dired, but crashing my editor because of that is evil) > > 3. Alt+x is not invoking "Extended command", only Esc+x did that ... Both of these, I would guess, would be easy to fix. It is entirely reasonable for now, say, to provide an ABORT restart inside the climacs command loop so that errors can restart the loop, rather than aborting to top level. Fixing your Alt key would involve slightly more work: playing around with xev and finding out what it actually generates, for instance; in both of these cases, though, I suspect it would take less time than it did to send your report. > 4. Common Lisp syntax mode is only coloring the first line of the > buffer, (the rest are highlighted as if they were comments) in cmucl, > and is highlighting everything up-to first ";" in sbcl. Common Lisp syntax mode is, until tomorrow (I believe), a project being undertaken by students at the University of Bordeaux as part of their degree. Given this, I would expect it to be under development by those students, and would refrain from commenting too much on it until past their submission deadline. > 2. C-x C-f /home/ignas/test.lisp , then Alt+Tab to another window > (covering the climacs window), Alt+Tab back, Ret > > * (climacs-gui::climacs) > > debugger invoked on a SIMPLE-ERROR in thread 17344: > # is not > contained in # {9861BF9}>. Now this one is annoying; it has caused me problems, too. No-one seems to know why it happens, so here is your chance to elucidate a mystery... Cheers, Christophe From csr21 at cam.ac.uk Fri Apr 29 15:06:54 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 29 Apr 2005 16:06:54 +0100 Subject: [climacs-devel] Bugs reporting :) In-Reply-To: (Christophe Rhodes's message of "Thu, 28 Apr 2005 20:04:30 +0100") References: Message-ID: Christophe Rhodes writes: > Just so you know, this is the third draft of a response to your > e-mail: the previous two were deleted on grounds of excessive > temperature. And, guess what, in the cold light of day, even this, along with some of the elided content, looks too harsh. I'm sorry I lost my temper like that, and can only plead exhaustion in mitigation. Bug reports are indeed welcome (but still those with patches are better! :-) Cheers, Christophe From ignas.mikalajunas at gmail.com Fri Apr 29 16:23:54 2005 From: ignas.mikalajunas at gmail.com (Ignas Mikalajunas) Date: Fri, 29 Apr 2005 19:23:54 +0300 Subject: [climacs-devel] Bugs reporting :) In-Reply-To: References: Message-ID: On 4/28/05, Christophe Rhodes wrote: > Ignas Mikalajunas writes: > > > Hi, i like the idea of Common lisp emacs like editor, and i would like > > to test it, but it seemsso unuseable to me that i just can't even test > > it :(, the bugs i have managed to encounter in like 3 minutes of using > > climacs were: > > Just so you know, this is the third draft of a response to your > e-mail: the previous two were deleted on grounds of excessive > temperature. This is of course my fault for reacting badly to what > you wrote, but you might be interested that it provoked that reaction. > > Put bluntly: climacs doesn't really need testers at the moment: it > needs people who will do more than use it for just like 3 minutes, by > fixing the problems that they encounter rather than simply recounting > them. Testing and posting bug reports has a certain value, but there > simply isn't the manpower to fix bugs in any kind of timely manner > without more effort on the reporter's part, say by providing a patch > to fix the bad behaviour. I am really sorry for the tone of my message, i should have tried to fix at least some of the issues i found before ranting. I am not very good with lisp yet, so most of the time i am reluctant to write patches to a project run by better programmers than i am. And i don't have enough time to get acquainted with the internal architecture/ programming guidelines of a project so I could write code that can become a part of it. > > > 1. C-x C-f Ret > > > > It tries to open my home directory and of course fails (I know there > > is no dired, but crashing my editor because of that is evil) > > > > 3. Alt+x is not invoking "Extended command", only Esc+x did that ... > > Both of these, I would guess, would be easy to fix. It is entirely > reasonable for now, say, to provide an ABORT restart inside the > climacs command loop so that errors can restart the loop, rather than > aborting to top level. Index: gui.lisp =================================================================== RCS file: /project/climacs/cvsroot/climacs/gui.lisp,v retrieving revision 1.128 diff -u -r1.128 gui.lisp --- gui.lisp 19 Mar 2005 22:08:31 -0000 1.128 +++ gui.lisp 29 Apr 2005 15:20:24 -0000 @@ -696,9 +696,12 @@ (setf (syntax buffer) (make-instance 'basic-syntax :buffer (buffer (point pane)))) ;; Don't want to create the file if it doesn't exist. - (when (probe-file filename) - (with-open-file (stream filename :direction :input) - (input-from-stream stream buffer 0))) + (handler-case (when (probe-file filename) + (with-open-file (stream filename :direction :input) + (input-from-stream stream buffer 0))) + (error () (progn (beep) + (display-message (format nil "Could not open file \"~A\"!" filename)) + (return-from com-find-file nil)))) (setf (filename buffer) filename (name buffer) (pathname-filename filename) (needs-saving buffer) nil) I guess this should at least make it a bit more forgiving than it was. Though i am not sure it is a bearable solution. I know GNU/Emacs creates a new buffer with the chosen file-name anyway, even though Emacs is not capable of reading the contents of the file. (that would yield a crash when saving the file i guess though). I can try to reproduce that behaviour in climacs if you think that would be right. > Fixing your Alt key would involve slightly > more work: playing around with xev and finding out what it actually > generates, for instance; in both of these cases, though, I suspect it > would take less time than it did to send your report. I'll look into it as soon as I'll have time. I am not very good with low level stuff though, but i guess i can scrape something. Ignas Mikalaj?nas From d.lewis at gold.ac.uk Fri Apr 29 15:59:22 2005 From: d.lewis at gold.ac.uk (David Lewis) Date: Fri, 29 Apr 2005 16:59:22 +0100 Subject: [climacs-devel] Fwd: Insert file Message-ID: <1b374c0ebdbc1bee268006379b9d24a3@gold.ac.uk> Hi, I've had to implement an insert-file command for my own work (helped by Christophe). Hope it's useful. Change to gui.lisp: @@ -707,6 +710,20 @@ ;; resets the low and high marks after redisplay (redisplay-frame-panes *application-frame*))) +(define-named-command com-insert-file () + (let ((filename (accept 'completable-pathname + :prompt "Insert File")) + (pane (current-window))) + (when (probe-file filename) + (setf (mark pane) (clone-mark (point pane) :left)) + (with-open-file (stream filename :direction :input) + (input-from-stream stream + (buffer pane) + (offset (point pane)))) + (psetf (offset (mark pane)) (offset (point pane)) + (offset (point pane)) (offset (mark pane)))) + (redisplay-frame-panes *application-frame*))) + (defun save-buffer (buffer) (let ((filename (or (filename buffer) (accept 'completable-pathname @@ -1419,6 +1436,7 @@ (c-x-set-key '(#\t :control) 'com-transpose-lines) (c-x-set-key '(#\w :control) 'com-write-buffer) (c-x-set-key '(#\x :control) 'com-exchange-point-and-mark) +(c-x-set-key '(#\i) 'com-insert-file) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;; ;;; Ta, David Lewis From pfongkye at yahoo.com Fri Apr 29 20:13:39 2005 From: pfongkye at yahoo.com (fongkye pascal) Date: Fri, 29 Apr 2005 21:13:39 +0100 (BST) Subject: [climacs-devel] some modifications in cl-syntax... In-Reply-To: 6667 Message-ID: <20050429201340.58315.qmail@web40423.mail.yahoo.com> Hi, we have made balanced comment work a bit better, also fun-expr and vect-expr. still have problems with line-comment.. For example when a semicolon is included in between double quotes, we have to type a line-feed and close the double quotes so that it is recognized as a string... Cheers Nada, Julien, Pascal, Bruno Send instant messages to your online friends http://uk.messenger.yahoo.com