July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: tar-mode and crypt revisted 26 years, 1 month

Neal D. Becker

Actually, it's stranger than that. When I visit a .tar.gz, it sometimes works correctly and sometimes doesn't. It seems to depend on the loading of other packages - but I haven't isolated it further.

2 participants
1 comments

JDE & EFS... 26 years, 1 month

Blob, Dave

Hi, I downloaded 21.1.3 and the sumo tarball and had problems editing remote java files. It looks to be a problem with JDE - specifically where it tries to find the project file (jde-find-project-file or jde-root-dir). I think adding successive ../'s is never giving a final root directory, but this is just a guess. In the meantime, since I don't really need it, I disabled jde. I don't need any resolution - I just thought I'd point it out. Thanks, Dave

2 participants
1 comments

Re: pgnus commandeers emacs to check mail 26 years, 1 month

Rajesh Godbole

>>>>> Olivier Galibert writes: > Oh yeah ? I'm really interesting in how using gtk/glib will > make our _LISP_ code thread-safe. Why do I get the feeling that I've opened a can of worms. Okay, here's my $0.02. In order for threading to work with emacs-lisp the following things need to happen. (We're talking relatively long term here, hence the word roadmap.) o The OS First off, the OS itself needs to "support" threads. Most industrial strength OSes do so. Examples, DG/UX, HP/UX, AIX, Linux, Windoze, Sun. o [x]emacs [x]emacs would need to use a threaded library in order to support multiple threads of execution within the same process. gtk/glib would be _one_ solution. Its used extensively in gnome and mozilla. xemacs code would need to be made mt-safe by mutex-locking out critical sections of the code. gtk/glib could provide a new widget set to replace existing ones, but that's another debate. o emacs-lisp the base emacs-lisp would need to provide extended lisp functionality to interface with the low-level threads library. This would probably be a package that provides mutex o emacs-lisp applications Applications like gnus, w3 which can potentially do multiple asynchronous fetches in the background would, probably benefit from an mt emacs-lisp. Issues like how many threads (eg. 1 per newsgroup?) synchronization, mutual exclusion etc would probably be counter-balanced by improvement in performance and functionality. A context switch between two threads in a single process is considerably cheaper than a context switch between two processes. Also, all data except for stack and registers are shared between threads. This makes threading interesting for such apps. _LISP_ code wouldn't magically become mt-safe, it would need to be modified to make it so. One would, of course, have the option to use only a single thread of execution, so existing apps should work with even with mt emacs-lisp. > Do your homework before > spitting such nonsense damnit. Now now, there's no need for foul language. Go stand in the corner.

3 participants
2 comments

Re: pgnus commandeers emacs to check mail 26 years, 1 month

Karl M. Hegbloom

>>>>> "argv" == Rajesh Godbole <argv(a)Sun.COM> writes: >>>>> Olivier Galibert writes: argv> Why do I get the feeling that I've opened a can of worms. Trolling? argv> o The OS argv> First off, the OS itself needs to "support" threads. Most argv> industrial strength OSes do so. Examples, DG/UX, HP/UX, argv> AIX, Linux, Windoze, Sun. Guile uses a user space thread library that doesn't require OS threads. It only works on systems for which the assembler part has been written. It does stack-switching.

1 participants
0 comments

Re: pgnus commandeers emacs to check mail 26 years, 1 month

William M. Perry

Rajesh Godbole <argv(a)Sun.COM> writes: > >>>>> Olivier Galibert writes: > > > Oh yeah ? I'm really interesting in how using gtk/glib will > > make our _LISP_ code thread-safe. > > Why do I get the feeling that I've opened a can of worms. > > Okay, here's my $0.02. In order for threading to work with emacs-lisp > the following things need to happen. (We're talking relatively long > term here, hence the word roadmap.) > > o The OS > First off, the OS itself needs to "support" threads. Most industrial > strength OSes do so. Examples, DG/UX, HP/UX, AIX, Linux, Windoze, > Sun. > > o [x]emacs > [x]emacs would need to use a threaded library in order to support > multiple threads of execution within the same process. gtk/glib > would be _one_ solution. Its used extensively in gnome and mozilla. > > xemacs code would need to be made mt-safe by mutex-locking out > critical sections of the code. > > gtk/glib could provide a new widget set to replace existing ones, > but that's another debate. > > o emacs-lisp > the base emacs-lisp would need to provide extended lisp > functionality to interface with the low-level threads library. > This would probably be a package that provides mutex The _real_ problem is making the interpreter thread safe, not just adding the primitives to make the actual lisp _programs_ thread safe. -bp

1 participants
0 comments

Re: [patch] "config.values" belongs in --docdir 26 years, 1 month

Adrian Aichner

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Adrian Aichner <aichner(a)ecf.teradyne.com> writes in xemacs-beta(a)xemacs.org: >> I will have to make some adjustments for the Windows NT native build >> then. sb> Go ahead. The patch has been approved. Steven, I have come to the conclusion that xemacs.mak does not need to change after all. I have synched xemacs95.mak with xemacs.mak along the way to build the info target on Windows 95 as well. Will provide a patch for xemacs95.mak against 21.1.4. Regards, Adrian sb> -- sb> $B6}F~$l6}=P$7(B (Garbage in, Garbage out)

1 participants
0 comments

Re: pgnus commandeers emacs to check mail 26 years, 1 month

Rajesh Godbole

>>>>> Didier Verna writes: DV> Last time I checked, it wasn't, but this might have DV> changed. However, getting multithreading "for free" is a bit DV> optimistic. You get multithreading at the langage level, DV> yes. But that's probably not the most difficult thing to DV> achieve. The major part of the work is properly designing the DV> way you'll use multithreading: how many threads ? To do what ? DV> Threads for user commands ? and so on, with all the non DV> obvious problems it brings, like synchronisation, mutual DV> exclusion, resources protection etc. There's also a libgthread that's part of glib. If [x]emacs were to be based on glib/gtk, "free" threading could become available. FAQ: http://www.serpentine.com/~bos/threads-faq/ is also quite useful.

2 participants
1 comments

Re: package standards version 1.1 26 years, 1 month

Karl M. Hegbloom

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> If there's anything else that someone needs changed regarding sb> info in the package-info.in files, now would be a good time to sb> request it ... A `long-description' field would be nice, with a paragraph or more describing the package. I want to try and auto-generate the debian control file information from the package-info stuff. We use a description field, with one ~65 char line then a paragraph or so... You can read about it here: <URL:http://bittersweet.sysc.pdx.edu/doc/packaging-manual/packaging.html/c...> I have begun to write a few of them, and can send patches... but I am not satisfied with it the way I've got it now. I just added a `long-description' key and a one-long-line inside quotes. But the Debian descriptions can be several paragraphs, and it is often useful to have them contain bulletted lists and suchlike. We can't just use HTML since W3 is unbundled, right? Any Ideas? (I need to have a look at what other things I might need for the autogen of control files too... I'll spend a little time on that today.)

1 participants
0 comments

Re: Tabs 'n widgets screenshot 26 years, 1 month

William M. Perry

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Ben Wing <ben(a)666.com> writes: > > > This is real cool, but looking at this, it's clear that it doesn't look the > > way tab widgets are supposed to work. In particular, of course, they should > > have the proper borders around the stuff displayed. I've attached a screen > > shot of a typical Windows dialog box with a tab widget in it. The problem > > lies with this "expanded gutter" concept. Tabs are *NOT* extra > > graphical > > I think in this case the extra border would just be wasted space. The > buffer tabs are more like the tabs used to select between various sheets > in modern spreadsheets. They also do not use extra borders. But they are themselves much different visually than the tabs that were used in the screenshot, and oriented differently. :) For the typical 'property sheet' type of widgets that andy is using, a border around them to show the area of control of the tab widget is normal and desired. If you do not, then the tab widget is really no different than a row of buttons placed on top of an arbitrary screen area. Now, if there was some way to use the smaller, triangular, bottom-oriented tab widgets, then I would agree that the extra border space is not needed _as much_. I'd still like to be able to see it as an option though. >From a gut reaction to thee screenshot, I'd say cool concept but no way in #%!＠! I'd use it on a daily basis. I would hope you could turn it off. I typically have so many buffers open that it would quickly get pretty nasty with the large tabs. Using the smaller ones typically seen in spreadsheets, etc, would be better, but could still get pretty cluttered. > Anyone remember the text base DOS IDE's that did MDI in text mode, > wasting a character on every side of the text window, so that you > actaully had a 50x10 window to edit in? Well, this isn't text mode though. It would only take a few pixels. And doesn't everyone run in 32bit 1600x1200 ? :) -bp

2 participants
1 comments

Re: pgnus commandeers emacs to check mail 26 years, 1 month

Karl M. Hegbloom

>>>>> "Michael" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "argv" == Rajesh Godbole <argv(a)Sun.COM> writes: argv> Is threading on the roadmap/TODO list? Is someone actively argv> working on this? IMHO it would be a very desirable feature. Michael> This is not a feature at all: it would constitute an Michael> overhaul affecting just about every part oft the current Michael> system. As far as I know, no. I guess if someone wanted to research it and learn how it might be done, Guile Scheme might be a good place to look. Certainly there are other schemes and lisps with threading... guile, rscheme, ecolisp, scheme48 I'm a few years away from that study, I've found. I tried... and am actually on the track, but it's a tall pile of books.

1 participants
0 comments

2025

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 July 1999