How can I determmine the package that a script belongs to?
For example, I would like to update 'makeinfo' to whatever version is in
pre-release. Which package would I downnload and, more importantly, how
would I figure that out?
--
Jake Colman -- XEmacs Tinkerer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Soren Feodor Nielsen writes:
> I do have a file named 'core' but it is dated 2001-10-25. Do you want me
> to send it to you?
No, thank you. Core files generally are not very useful unless you
have access to both the machine on which they were generated and the
original binary that generated them. And something from that long ago
is almost surely not relevant to the current problems.
I've heard from people who have had problems with font changing
before, but have little idea how to address the issue at this point.
Thanks for your use and support of XEmacs!
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
On Feb 1, 2008 3:56 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
> That's a good way to convince me to do the opposite. (Sorry, couldn't
> resist taking a poke at Java. :-)
>
> Seriously, nor does Scheme AFAIK. In theory all Scheme objects are
> eternal, but you can GC their memory images in a process if there are
> no remaining references to them. You don't have to.
It's the only sane model for a garbage collected system where you are
not imposing a particular garbage collection algorithm. Think about
defining a time when a finalizer MUST be run and the object garbage
collected. It's too dependent on the design of the garbage collector.
A generational GC, for example, will answer that question much
differently from a mark-and-sweep GC.
> True. However, in many cases we do have external resources needing
> finalization (databases and network connections need closing, fds need
> flushing, etc), and if we allow the finalizers to do that work and
> guarantee that finalizers get run before a normal exit, there's that
> much less work that application programmers need to do.
Stop me if I'm wrong, but don't we already flush all streams on exit?
As long as all data has been pushed into the OS layer, it doesn't
matter if the OS or the application does the actual closing. In fact,
I'll go so far as to claim that we don't need guaranteed finalizer
runs at all, as long as we guarantee that all streams are flushed.
> How do Java and RnRS treat such external objects that need finalization?
Java doesn't. You can't use finalizers for guaranteed cleanup
purposes. You use try { ... } finally { ... } blocks to do that. I
don't know RnRS well enough to say.
> Surely we can come up with a way to tag certain classes as having
> "important" finalizers in that sense, and guarantee that they be run
> even at exit. (Isn't there a class of LRECORD_WITHOUT_FINALIZER
> already?) Or we could separate finalization into a two stage process,
> the first stage finalizes external resources, and is always done. The
> second stage finalizes resources that the OS would clean up for us at
> shutdown, and can be omitted at shutdown. But such omission is an
> optimization; it can wait if necessary.
I don't think we need to do this.
> People who are in a hurry for a given instance to start and stop can
> run XEmacs as a server process and do all their editing via gnuclient.
> (Really, XEmacs proper should have no UI; all UIs should be clients of
> the editor. :-)
Wow, deja vu all over again. I'll have to fork this off as a separate
thread, or maybe even take it private if nobody else cares, but that
parenthetical remark really resonates with me. I've had idle dreams
for several years now of ways in which I'd like to transform the
design of XEmacs. I've even sketched up primitive designs for some of
them, but haven't had time to take them any farther. For example,
I've considered a file block caching system to deal with large files,
a layered "view" of data with well-defined transformers up and down so
that it is easy, for example, to switch between a hex view (no hexl
needed!), a character view, and a display view of an HTML file, and
allow edits in any view to propagate to the others. Separating the
data handling piece from the presentation piece(s) was something I
considered as well. You could attach to a single instance from a TTY,
a GNOME session, etc. without having to "blend" the displays like we
do now. And then there's the extension language. There are so many
to choose from, and ... well, Elisp just doesn't cut it anymore.
Sorry, guys! In any case, there should be a clean separation of the
extension language from the rest of the application. (X)Emacs C code
is full of Elisp dependencies.
I've never had time to pursue any of this before, but I find that I
have actual free time now that I'm not an academic. I've been working
on some other projects that have been waiting for love and attention
[1] [2], but sometime next fall, I should be able to get serious about
some of these ideas. If they sound threatening, start maneuvering now
to head me off. :-) In any case, every single one of them will
involve touching gigantic gobs of C and Lisp code, so none of them
will be pulled off quickly.
Footnotes:
[1] http://jjames.fedorapeople.org/
[2] Imagine a C code checker that (1) can parse and reason about
unpreprocessed C code, (2) understands features introduced in C99, and
(3) processes source files in a variety of character encodings. It's
partially built. I'll need a few more months to build it up to where
it's minimally usable, and still more time after that to implement all
the features I envision. If you find yourself drooling over the
thought of working on that code base, let me know and maybe I'll find
somewhere to host it ... right after I decide on the license under
which I want to distribute it. Choices, choices, ...
--
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
Michael Sperber writes:
> Not the tagging: You create a named branch, make all the changes you
> need to do, cut the beta release from that. *Then* you merge your
> branch back into the mainline, and *then* tag on the mainline.
This means that in the case in point (a concurrent commit to the
mainline) the tagged revision *will* be a merge turd and *will*
include code that is undocumented in the release (at best, and in the
process you suggest, the tag *will* include code that is not in the
tarballs).
No, thank you.
I really don't understand what your point is. We have the free fire
zone over on the xemacs branch. Why does it matter if the xemacs-beta
branch has a ceasefire for a few hours? It only affects you and Vin.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
So, how are we gonna do this? Looks to me like the only sane way to
go is to declare a commit freeze until the release is complete.
Question ... do I have the needed commit privilege?
No big hurry, I've got other fish to fry this week, but maybe next
week I'll be thinking about 21.5.29.
Comments?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Applied, thanks!
On Dec 10, 2007 3:55 AM, FKtPp <m_pupil(a)yahoo.com.cn> wrote:
> Hi Aidan,
>
> Sorry for bring confusion to you...
>
> But that patch is not related to indent setting, the extra point moving
> occurs when you using `C-c C-i' to insert if-else template. The
> minibuffer initial-string initialized in the way people have to type
> extra keys to avoid shell script syntax error.
>
> Say if I want to insert a:
>
> if [ -z "$ABC" ]; then
> echo "gocha!"
> fi
>
> I just type `C-c C-i' and the minibuffer initialized as "condition: [
> ]"(point on character `]') and I continue type in `-z "$ABC"<RET><C-]>'
> will result in:
>
> if [ -z "$ABC"]; then
>
> fi
>
> Note the sytax error at `ABC"]; then', character `"' and `]' should be
> seperated by a space. To avoid this error, I always have to type in
> `<C-b> -z "$ABC"<RET><C-]>' or `-z "$ABC" <RET><C-]>' etc.
>
> With my patch while you type `C-c C-i' the minibuffer initialized as
> "condition [ ]"(point just at the space character before `]'
> character). And this will save some extra key strocks.
>
>
> --- Aidan Kehoe <kehoea(a)parhasard.net> wrote:
>
> >
> > Dear FKtPp,
> >
> > Ar an seachtú lá de mí na Nollaig, scríobh FKtPp:
> >
> > > The variable sh-test defined in package sh-script sh-script.el
> > make me feel uncomfortable while editing sh/ksh files.
> > >
> > > The default value make it move the point to the end of the initial
> > prompt string, and it make me always have to move back/delete one
> > character when inserting `if' clause in sh/ksh shell-script mode.
> >
> > This is a little confusing. Normally, one does not see the initial
> > prompt
> > string in shell-script-mode; prompt strings are limited to shell-mode
> > and
> > other modes associated with comint. And when, in shell-script mode, I
> > type
> >
> > if [ -f
> >
> > enter, and then tab, I get eight spaces, both with and without your
> > patch. What exactly are you seeing--please give us example
> > inputs--and what
> > exactly would you like to see?
> >
> > Bye,
> >
> > Aidan
> >
> > > It will be much better if the default value be as this:
> > >
> > > --- sh-script.el~ Wed Nov 28 17:03:20 2007
> > > +++ sh-script.el Fri Dec 07 16:45:44 2007
> > > @@ -600,8 +600,8 @@
> > > "Word to delimit here documents.")
> > >
> > > (defvar sh-test
> > > - '((sh "[ ]" . 3)
> > > - (ksh88 "[[ ]]" . 4))
> > > + '((sh "[ ]" . 2)
> > > + (ksh88 "[[ ]]" . 3))
> > > "Initial input in Bourne if, while and until skeletons. See
> > `sh-feature'.")
> >
> > --
> > ¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
> > precipitadamente de la aldea por culpa de la escasez de rinocerontes?
> >
>
>
>
> ____________________________________________________________________________________
> Never miss a thing. Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
>
> _______________________________________________
> XEmacs-Beta mailing list
> XEmacs-Beta(a)xemacs.org
> http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
>
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta