October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [somewhat offtopic] quesion on shell output redirection 26 years, 1 month

Greg Klanderman

Thank's to everyone who pointed out that stdout and stderr are not synchronized, as I confirmed with a simple test program: #include <stdio.h> #include <stdlib.h> int main(void) { int i; for (i = 0; i < 50000; i++) fprintf(((rand()&1) ? stdout : stderr), "<--%d-->\n", i); return 0; } >>>>> "Malcolm" == Malcolm Box <malcolm(a)brownale.demon.co.uk> writes: Malcolm> Malcolm> Greg Klanderman wrote: >> >> Anyway the question is, if I redirect stdout and stderr as follows >> (in /bin/sh): >> >> % some_command > output.txt 2>&1 Malcolm> Malcolm> Why do you need to redirect the output, rather than just slurping it Malcolm> into an XEmacs buffer and processing it there, either from the Malcolm> process-filter or process-sentinel? Yes, that's what I would actually do. Malcolm> Redirection is pretty broken on Malcolm> Windows systems, so you might find this less robust than you hope. Malcolm> Since the cvs messages themselves are always sensible (ie they don't Malcolm> appear intermingled) it would also seem to me that this would remove the Malcolm> worries about synchronisation. Unless someone has seen cvs produce Malcolm> garbled output on a terminal :-) Well, after some sleuthing, it seems that CVS goes to some trouble to keep its stdout and stderr synchronized. So I am proceeding with the change to pcl-cvs I suggested and have M-x cvs-status working correctly even recursing down subdirectories. If this weren't the case, we'd have problems. On unix you can bind process-connection-type to t around the call to start-process to have it to use a pty, which appears to cause stdout to get put in line-buffered mode. NT does not appear to use this variable, and so I can only assume this would not have been a workable solution. Running (let ((process-connection-type nil)) (start-process "test" "*test*" "/path/to/my/test/program")) should demonstrate the output being garbled. greg

1 participants
0 comments

wrong 'open-up' button image in custom 26 years, 1 month

Gunnar Evermann

In 21.2-beta3 when I open a cutomization buffer the wrong image is displayed for the 'OPEN' button in the 'up' position. Specificially '/usr/local/lib/xemacs/xemacs-packages/etc/w3/open-up.xpm' is used instead of '~evermann/src/XEmacs/xemacs-20/etc/custom/open-up.png' As there is no corresponding open-down in W3, the right image is used when I click on the button. This didn't happen in 21.0 Norwegian. Gunnar

1 participants
0 comments

Re: wrong 'open-up' button image in custom 26 years, 1 month

Colin Rafferty

G Evermann writes: > In 21.2-beta3 when I open a cutomization buffer the wrong image is > displayed for the 'OPEN' button in the 'up' position. > Specificially > '/usr/local/lib/xemacs/xemacs-packages/etc/w3/open-up.xpm' > is used instead of > '~evermann/src/XEmacs/xemacs-20/etc/custom/open-up.png' What is the value of data-directory-list? Specifically, does your home directory come before /usr/local/lib? I fixed a bug a while ago in 21.0 where it was using the wrong order. It may not have made it into 21.2 yet. -- Colin

1 participants
0 comments

Re: Call for discussion: DLL handling 26 years, 1 month

Hrvoje Niksic

"J. Kean Johnston" <jkj(a)sco.com> writes: > I like option (C) too, but I forgot to mention a 4th option. We *COULD* > change all the existing calls to DEFUN() to use a C-like string, No, we couldn't. Some preprocessors can't handle long strings. This is why we started using comments in the first place. In fact, if you take a closer look at FSF Emacs, you'll notice that they use comments in some places where strings don't cut it. Look at the FSF docstrings of mode-line-format, buffer-display-table, buffer-undo-list (all in src/buffer.c) and some others. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Depression is merely anger without enthusiasm.

2 participants
1 comments

Re: Debian bug tracking system contains patch for GPM C-z hang 26 years, 1 month

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Problem #2: a while ago, they "froze" Debian with Wget 1.4.4. Just so you know: They just froze again. > However, I soon released a bugfix 1.4.5, which fixed two or perhaps > three 1.4.5 bugs. They never bothered to add 1.4.5 to the > distribution, because the only updates were [sic!] bugfix-only. This is weird. The freeze is there to make sure ONLY bugfixes come in. Maybe the problem is that bugfixes in this case seems to be defined more narrowly as "fixes for things as reported in the Debian bug databsse". (Note that [possible due to your complaints] their stable version does contain 1.4.5. The frozen version contains 1.5.3. The recent SUSE 5.3 for instance ships with 1.5.2) > > Does it bother anyone, apart from me, that that here psfrag 3.0 is > > disabled in favor of 2.0 in teTeX although the psfrag authors would > > like very much to see it die, etc etc? > > If I were psfrag author, it would bother the hell out of me. So it does for me (it broke more than half of our exercise sets), so I reverted it back again in our group setup. Thank god for symlinks. However it still another case where there is a difference of opinion about a design decision between the package author and our users/sysadmins. In this case our sysadmins decided (rightly or wrongly) to change this in our local version (in this case by reverting to the old version). I think that the world is full of these local hacks by sysadmins and that phenomenon of Linux distributions is just increasing this to another level. > Yup. I believe there should be a closer relation between author and > distribution maintainer of a program, especially when the author is > willing to cooperate. Yes. In particular the distribution-freeze method has severe problems when the author also does freeze cycles. For instance Debian 2.1 will still ship with 20.4. In this case this is not such a problem as 21.0 is too major a change to just follow. But imagine if this were a 21.0-21.1 thing and we release 21.1 just after the freeze. What should be happening is that the distribution is tracking our bug fix betas in their unstable branch, i.e. their freeze equals our freeze. Also the term "bugfix" is very vague: The reading of stdin I reimplemented in gnuclient recently, was that a new feature of a bug fix? I have long been intending to write something up for this to sent to Debian (and maybe others) "officially", but have not got arround to this. Jan

1 participants
0 comments

Re: Call for discussion: DLL handling 26 years, 1 month

Hrvoje Niksic

"J. Kean Johnston" <jkj(a)sco.com> writes: > On Tue, Oct 20, 1998 at 02:51:35PM +0200, Hrvoje Niksic wrote: > > <offtopic>Have you looked at the second round of my remarks? I > > haven't received a response from you?</offtopic> > Hmmmm I thought I had posted one. Yes, I have done the > unwind_protect() stuff and made things more Mule-friendly. I must have missed it, sorry. But that is excellent news. Where can I find the latest incarnation of your code? > > Anyway, we should be careful not to run into problems with Mule... > > Yes I agree, but these variables have an extremely low-level > requirement, and are not *REALLY* meant to be user-visible, although > the dll-list-modules function will list the information. For this > kind of highly specialized purpose, is it really that much of an > issue to use a char *? I'd prefer to keep things as simple as > possible. OK, if they are not user-visible, char * is fine. > > I would much prefer having several functions to having to build a big > > cemacs_init() with a giant `switch' statement. What's wrong with > > having more of them? > > Absolutely nothing ... I just got lazy and only wanted to futz about with > one function pointer :-) Let's please use separate functions then. If we do, we also get the convenience of each function receiving the appropriate number of arguments, etc. > > The biggest benefit of this approach is that the packages will be able > > to choose between "loadable module" and "built-in" modes of operation > > with a simple #ifdef. It will also allow us to support a > > "--build-with-all" switch on systems that don't support dynamic > > loading, such as Ultrix. > > Producing foo-$$.c is no different to init.c except in name ... Oh. OK, sorry for misunderstanding you. :-) > stated the same concept with a different file name :-) All that is > important is that the build process is suitably simple. What I was > actually envisioning was having the ellcc script be really smart, > and build the documentation .o behind the scenes at the time you > invoke ellcc to create the .so. The script would determine all of > the object names, use that to pass on to make-docfile, produce a > temporary .c file which is compled and then linked in with the .so. Yup. > > Oh, and XEmacs is just as much Emacs as is FSF Emacs. > > No, its not. XEmacs is a useful editor with a future. FSF Emacs is > ... well, <politically_acceptable_mode>just the progenitor of a > useful editor :-) </politically_acceptable_mode> Heh, you're right. :-) But we still shouldn't promote the notion that #ifdef EMACS is FSFmacs only, and #ifdef XEMACS is XEmacs-only. It's Stallmanism. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- We are all just prisoners here of our own MAKEDEV.

1 participants
0 comments

Re: Call for discussion: DLL handling 26 years, 1 month

Pete Ware

> (A) Use DSO specific macros such as CDEFUN(), CDEFVAR_LISP() etc. To move code into XEmacs at compile time, one can merely define CDEFXXX() to be DEFXXX() with elimination of the document string. Modify make-docfile to understand both a string and a comment as arguments as args to CDEFXXX() and DEFXXX(). --pete

2 participants
1 comments

Re: Call for discussion: DLL handling 26 years, 1 month

Hrvoje Niksic

"J. Kean Johnston" <jkj(a)sco.com> writes: > Before going into the actual mechanisms, it is priudent to examine > WHY we think we need or want DSOs in XEmacs. It is already possible > to extend the editor using Lisp, and it is also possible to extend > it in C when you are compiling the editor. What makes DSOs > important is the fact that compiled C code can be selectively loaded > into the editor if and when it is needed. This will allow us to > (potentially) move parts of the editor into DSOs, thus making the > core editor smaller and faster to load, while retaining the ability > to extend its functionality. It is important to be able to write > some extensions in C, rather than Lisp, for speed purposes. While > the Lisp engine is fairly quick, there are cases (such as the HTML > parser) where a great benefit can be gained from writing it in C. > But not everyone wants to use their editor for a browser, so not > everyone should have their editor weighted down with an HTML parser. > Hence the need for DSOs. Agreed. Note, however, that we will have to be very careful with the third-party modules that are bound to be written. We must make it clear that the C interface is open to changes, or otherwise we'll be stuck. > What I have done is to flesh out dll.c to provide an actual working > implementation of DSO loading, using a variety of different models. <offtopic>Have you looked at the second round of my remarks? I haven't received a response from you?</offtopic> > CONST char *cemacs_mod_name = "whatever"; > This variable is used to give the module a short tag or name, which is > used later in resolving inter-module dependancies. This should be > limited to 8 characters or less, and contain no spaces. [...] Note: perhaps these should be Lisp_Objects rather than char pointers. But that would make them harder to initialize... Anyway, we should be careful not to run into problems with Mule... > If any of these three strings is not present, the loader will reject > the module as invalid. The last check for module validity is a C > function, which is declared as: > int cemacs_init (int task, char *arg) I would much prefer having several functions to having to build a big cemacs_init() with a giant `switch' statement. What's wrong with having more of them? > In the existing code, the developer uses the DEFUN() macro to define > a new C level subroutine. This results in a static structure being > set up and populated with static values. This model does not lend > itself well to supporting DSOs, due to the way PIC addresses are > stored in shared objects. (If you need more details on why this is > an issue, please feel free to contact me outside the scope of this > discussion. For now, please just accept my word that there is a > problem here). Accepted. :-) > A third alternative (and one I have not implemented) is to have > variables and functions defined exactly the way they currently are, > using DEFUN(), DEFVAR_LISP() etc, with their comments in C as they > currently are, and then to extend the module build process to > include calls to make-docfile or some other suitable documentation > snarfer that can write out a special init.c I would vote for this, only without the `init.c' file. For example, the object build procedure might look like this: obj-build foo.c --> start documentation snarfer, snarf the code, add it to the existing code and write it to foo-$$.c --> gcc -c foo-$$.c -o foo.so ... oodles of flags ... The biggest benefit of this approach is that the packages will be able to choose between "loadable module" and "built-in" modes of operation with a simple #ifdef. It will also allow us to support a "--build-with-all" switch on systems that don't support dynamic loading, such as Ultrix. > One of the biggest issues facing us is how we can co-exist at a > source code level with GNU Emacs. I will refrain from commenting on this, except for "I don't care." Kyle was definitely right about Stallman, us, and boat anchors. Oh, and XEmacs is just as much Emacs as is FSF Emacs. > To summarise, the three choices are: > (A) Use DSO specific macros such as CDEFUN(), CDEFVAR_LISP() etc. > (B) Use the existing DEFUN() and DEFVAR_() macros and have documentation > handled during task code 3, or > (C) Keep everything exactly as it is and extend the DSO build scripts to > snarf the documentation strings correctly and construct a .c file. I definitely vote for (C). It's the only sensible solution, as far as I can tell. > One last thing. Do we want shared objects loaded from the normal > Lisp load path, or do we want to set up a new variable to contain > the shared objects, perhaps having the default be in the OS > dependant directory? A new variable. Even if we make them conceptually similar to elisp files, loadable modules are still implementationally quite different. > Should I send this stuff on to Stallman to look at too, and get him > in on the comment loop, or do we just make a choice and present > everything to him for integration into GNU Emacs feit acompli? I think consulting with Stallman beforehand might be a waste of time because Stallmacs handles some things differently (such as docstrings), and I don't think he will have any understanding whatsoever for our points of view. > I am "FSF-friendly", in that my copyright assignments are on file at > the FSF, so I can appease that fear at the very least by assigning > copyright to them. It's OK to have the contributions assigned. Mine are also assigned. Anyway, thanks a bunch for your contributions and your code. It will be very good to have them in 21.2. :-) -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- - Now what did we learn from this? - I learned what my liver looks like!

2 participants
1 comments

Re: Call for discussion: DLL handling 26 years, 1 month

Didier Verna

"J. Kean Johnston" <jkj(a)sco.com> writes: > To summarise, the three choices are: > (A) Use DSO specific macros such as CDEFUN(), CDEFVAR_LISP() etc. > (B) Use the existing DEFUN() and DEFVAR_() macros and have documentation > handled during task code 3, or Please don't use this solution. We all know it's already rather difficult to keep the docs up-to-date, and I think it would be better to use mechanisms as close to the existing ones as possible anyway. > (C) Keep everything exactly as it is and extend the DSO build scripts to > snarf the documentation strings correctly and construct a .c file. > One last thing. Do we want shared objects loaded from the normal Lisp load > path, or do we want to set up a new variable to contain the shared objects, > perhaps having the default be in the OS dependant directory? IMHO, it's important to put them somewhere else. I hope I have convinced the package-stuff guys to move the packages under an architecture-independant directory, namely under share/. However, lib/ is the place to put object code. OTOH, a new question arises: it's likely that many of those "dynamically loadable packages" will come not only with shared objects, and but with accompanying elisp code too. In that case, should we split the installation under different places, eg share/ and lib/. Personally, I think we can afford replicating the elisp code installation in that case. > Comments, suggestions and questions welcome. One other general remark. I like this functionality very much, and I think that in terms of user-interface, this and the current package system should stay really synchronized. In particular, this means envision the problems of loading/unloading, concurrent version management, custom-based installation etc etc. Otherwise, all of this sounds really neat. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

2 participants
1 comments

Re: Call for discussion: DLL handling 26 years, 1 month

Marat Boshernitsan

"J. Kean Johnston" <jkj(a)sco.com> writes: [ ... ] > Before going into the actual mechanisms, it is priudent to examine WHY we > think we need or want DSOs in XEmacs. It is already possible to extend the > editor using Lisp, and it is also possible to extend it in C when you are > compiling the editor. What makes DSOs important is the fact that compiled > C code can be selectively loaded into the editor if and when it is needed. > This will allow us to (potentially) move parts of the editor into DSOs, > thus making the core editor smaller and faster to load, while retaining the > ability to extend its functionality. It is important to be able to write > some extensions in C, rather than Lisp, for speed purposes. While the Lisp > engine is fairly quick, there are cases (such as the HTML parser) where a > great benefit can be gained from writing it in C. But not everyone wants > to use their editor for a browser, so not everyone should have their editor > weighted down with an HTML parser. Hence the need for DSOs. Another reason is to be able to import functionality of some existing library into XEmacs by writing a thin glue layer in C that provides lisp-level interface to the library. (I am working on a program analysis engine that will use XEmacs as its editor front-end in precisely this manner) [ ... ] > To summarise, the three choices are: > (A) Use DSO specific macros such as CDEFUN(), CDEFVAR_LISP() etc. > (B) Use the existing DEFUN() and DEFVAR_() macros and have documentation > handled during task code 3, or > (C) Keep everything exactly as it is and extend the DSO build scripts to > snarf the documentation strings correctly and construct a .c file. Solution (A) is objectionable if you ever want to be able to optionally compile same module together with XEmacs or separately into a DSO. In my work, however, knowing that I will never, ever want to compile my library into XEmacs I don't mind using CDEFUN/CDEFVAR_LISP. In light of the above, I believe the alternative (C) is better, although I would much rather prefer (A), because it makes my "make" scripts less complicated. Another point to consider: I'd like to be able to download a standard distribution of XEmacs (not the source) and be able to compile my modules. This means that the standard distribution must include the appropriate .h headers as well as the appropriate incarnation of "make-docfile". Right now, cemacs.h depends on config.h generated during build... > One last thing. Do we want shared objects loaded from the normal Lisp load > path, or do we want to set up a new variable to contain the shared objects, > perhaps having the default be in the OS dependant directory? My vote is for an OS-dependent directory. Marat.

2 participants
1 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta October 1998