Another interesting idea from emacs-devel.
dhruva writes:
> If we are looking at concurrency, there is another paradigm based on
> maintaining multiple internal function call stacks which a scheduler
> can schedule in some fair fashion. I am talking of stackless Python
> implementation. You really do not have multiple threads but get
> simulated concurrency through stack switching. For IO intensive usage
> using async IO with stackless might make a good candidate.
>
> -dhruva
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Jerry James writes:
> The word "stackless" appears to be a misnomer. Any idea where that
> came from?
>From a particular implementation of Python called "Stackless Python".
It's been around for many years, but Guido consistently refuses to put
it into CPython, I don't know why offhand. It has a number of
supporters besides its author, though, and is well-debugged.
> 1. You have to choose between two painful alternatives.
> a. [...]
> b. A scheduler that only runs inside of well-defined functions, meaning
> that a given stack can hog the CPU for arbitrary amounts of time.
It's not obvious to me that this wouldn't be a big win in XEmacs.
This isn't a realtime OS where you need to discipline badly-behaved
threads; it's a single-user application where judicious use of
cooperative multithreading might permit big wins from a few tweaks.
> 2. If you choose 1a, then you wind up doing all the work you would have
> to do for a "real" thread library anyway.
Agreed.
> 3. There are several mature, well-debugged thread libraries out there. Why
> ignore them and start the development and debugging process all over
> again?
Because threads are hard. I could see using threads for certain
subsystems (eg, redisplay, and assuming Marcus and Olivier are up for
it, GC), but having true threads in the Lisp interpreter will be hard
(unless we're willing to replace the whole thing).
> 5. The world is going multi-core. Intel is talking about having 80-core
> processors available in 2 years.
Why wait for Intel? You probably already have a couple lying around
(cf this month's ACM Queue---wow! an interview with Tom Duff and he's
not even the focus of attention? Yikes!)
> I am interested in having a discussion on what it would take to
> switch from our Reactor-based architecture to a multithreaded one.
> Such a switch would have serious implications for the Lisp engine
> and the garbage collector, for example.
Well, I have to admit that I will have very little useful to
contribute, but I'd be happy to watch and cheer from the sidelines!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
I was just running a Java debug session with JDE. When I stepped past
line 999, the line numbers started showing up with commas in them
(e.g., "line 1,200"). The function jde-jdb-string-to-int in
jde-jdb.el is supposed to strip those commas out. It didn't, and as a
result I was stuck looking at line 1. I had to apply the patch below
to make my debug session usable. Do we not support the use of
[:digit:]?
Index: xemacs-packages/jde/lisp/jde-jdb.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/jde/lisp/jde-jdb.el,v
retrieving revision 1.6
diff -u -r1.6 jde-jdb.el
--- xemacs-packages/jde/lisp/jde-jdb.el 26 Nov 2007 15:16:47 -0000 1.6
+++ xemacs-packages/jde/lisp/jde-jdb.el 28 Apr 2008 19:37:29 -0000
@@ -353,7 +353,7 @@
(if (string-match
(concat "^ \\["
(oref debuggee :stack-depth)
- "\\] .*(\\([^\$\n]*\\).*:\\([0-9]*[^[:digit:]]?[0-9]+\\))")
+ "\\] .*(\\([^\$\n]*\\).*:\\([0-9]*[^0-9]?[0-9]+\\))")
output)
(let ((marker (match-string 0 output))
(class (match-string 1 output))
@@ -1869,7 +1869,7 @@
(defun jde-jdb-string-to-int(number)
"This method removes punctuation from a string, e.g, 1,200 (1.200 in Danish),
and converts the result to an integer."
- (if (string-match "[^[:digit:]]" number)
+ (if (string-match "[^0-9]" number)
(setq number (replace-match "" nil nil number)))
(string-to-int number))
--
Jerry James
http://loganjerry.googlepages.com/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
John Paul Wallington writes:
> On 27 Apr 2008, at 23:59, Stephen J. Turnbull wrote:
>
> > D'oh. It *is* redundant, isn't it. Unless somebody comes up with a
> > good reason not to, I'm just going to get rid of the const nil and
> > parent choice widget, too.
>
> FWIW, although it's strictly redundant I think offering the choice
> makes for a better user experience and would leave Alan's patch as-is.
I tend to disagree because I think of this as an interface to a (Lisp)
list, and because it makes customizing this variable slower than it
need be. Can you say why having the "none" option works for you?
My point is that consistency is presumably a good thing, and if having
a choice of "none" is good for this list-that-might-be-empty, wouldn't
it be a better idea to have that built-in to the `repeat' widget?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
On Sun, 27 Apr 2008, Mike Kupfer wrote:
> >>>>> "Tim" == Tim Connors <tconnors(a)astro.swin.edu.au> writes:
>
> Tim> so that when I open a file in ~/thesis/..., it goes to
> Tim> <directory>/thesis/....
>
> Do you already have a ~/thesis? If not, just make it a symbolic link
> pointing at <directory>/thesis. (If you're using Windows, doesn't it
> have some sort of shortcut thingie that works like symbolic links?)
It's more that I'm being overly complicated and want some way of forcing
the xemacs process on one machine (machine 1) to use one filesystem,
except for when it is invoked by the gnuclient process on another machine
(machine 2; I don't want to just run the xemacs process on machine 2,
because machine 2 is maintained by central ITS who are useless
morons^W^Wrun several year old unmaintained versions of linux). Since a
wrapper around gnuclient pointing back to machine 1 is my $EDITOR of
choice on machine 2, I can't just put a symlink in for ~/thesis on machine
1, because sometimes I really do want to edit other files on machine 2.
Probably more of an ill thought-out idea than something worth persuing.
Never mind me :)
--
Tim Connors
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Michael Sperber writes in a commit notice on XEmacs Patches:
Hg log:
> Fix window-configuration problem.
This greatly improves, maybe eliminates, the anomolies I've been
seeing in VM summary buffers with random point movement. This is an
X-enabled build but in a TTY over ssh. Can other VM testers update to
tip of "xemacs" (or if you're following "xemacs-beta", it should be
there in a day or two -- my build was clean FWIW) and report if you
see an improvement, or continuing anomolies?
In a quick test, it does *not* fix issue303 for me (but I have not
done a full rebuild with the patch yet, just a "make").
Mike, Jerry, the following issues in the tracker may be related.
issue134, Infinite loop in ecb, apparently in current-window-configuration
issue227, Infinite loop in ecb, apparently in current-window-configuration
issue303, [Bug: 21.5-b28] Bogus motion of modeline
I've assigned them to Mike but 134 and 227 might better be assigned to
Jerry and/or closed if they've been fixed. If 134 and 227 are the
same issue, please close one as superseded by the other. I think 227
has more information, so 134 is the better candidate for that.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
I saw this fix that was posted on comp.emacs.xemacs in December 2007.
It doesn't appear to have been applied yet. It fixes a bug that I
introduced in 2002-01-16. Mea culpa!