August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: 28 bit ought to be enough for anyone. 25 years, 10 months

Hrvoje Niksic

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > >> a) Add them as another datatype comletely separate from Elisp > >> fixnums, with explicit coercions back and forth. > >> > >> This, I believe, is possible with minimal changes to the Elisp > >> machine, even though it's still a sufficiently hairy job, 'cause > >> you need to interface with the garbage collector in a suitable > >> way. > > Hrvoje> Not hairy at all. Have you looked at > Hrvoje> DEFINE_LRECORD_IMPLEMENTATION? It allows you to specify a > Hrvoje> callback routine for the GC. > > I wasn't thinking about tracing, but rather about the fact that > (according to my totally naive view of how efficient bignum > arithmetic works), with some bignum operations, it may not be > possible to know the size of the result without actually computing > it. I still don't understand the problem. Even if it is true that the size of the resulting number is unknown (and I am not convinced in this!), you are still quite free to use realloc() and friends to adjust the size incrementally. > For example, can you shrink an object after creating it? What kind of object, and why would you want to do this? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- You have an unusual magnetic personality. Don't walk too close to metal objects which are not fastened down.

1 participants
0 comments

RE: PMG problems 25 years, 10 months

Amir J. Katz

Mea Culpa. Before I get flamed to death (:-), I was wrong. The attachment file 'welcome.png' file a was a GIF file, but I got confused and assigned it the type PNG because of the name. -- /* Amir J. Katz mailto:amir＠nuke-spam.com */ /* [For e-mail, replace 'nuke-spam' with 'ndsoft'] */ /* EagleEye Control Software, LTD. http://www.ndsoft.com */ /* 'Is "tired old cliche" one?' (Steven Wright) */

1 participants
0 comments

PMG problems 25 years, 10 months

Amir J. Katz

I enclose two PNG images: welcome.png - displays OK in xv 3.10a, fails in xemacs; opussum.png - displays OK in xemacs, fails in xv; Versions: libpng-1.0.2 zlib-1.1.3 Any idea? -- /* Amir J. Katz mailto:amir＠nuke-spam.com */ /* [For e-mail, replace 'nuke-spam' with 'ndsoft'] */ /* EagleEye Control Software, LTD. http://www.ndsoft.com */ /* 'Is "tired old cliche" one?' (Steven Wright) */

2 participants
1 comments

[OK] 21.0 "Finnish Landrace" XEmacs Lucid on i586-pc-linux 25 years, 10 months

Larry Ayers

Patched up from beta-52, using egcs-1.03 on a glibc Debian-2.0 machine. I'm still seeing this error when finder-inf.el is being compiled: Compiling /usr/local/src/xemacs-21.0-b54/lisp/finder-inf.el... While compiling toplevel forms in file \ /usr/local/src/xemacs-21.0-b54/lisp/finder-inf.el: !! Invalid read syntax ((". in wrong context")) The finder database appears to be empty. Aside from this, everything is working fine. > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /usr/local/src/xemacs-21.0-b54/Installation: > (Output from most recent run of ./configure) uname -a: Linux liatris 2.1.117 #7 Fri Aug 21 06:46:18 CDT 1998 i586 unknown ./configure '--prefix=/usr/local/xemacs-beta' '--with-site-lisp' '--package-path=/usr/local/xemacs-beta/lib/xemacs/packages' '--with-toolbars=no' '--gung-ho' '--with-xpm' '--with-tiff=no' '--with-dialogs=athena' '--error-checking=none' '--debug=no' '--with-pop' XEmacs 21.0 "Finnish Landrace" configured for `i586-pc-linux'. Where should the build process find the source code? /usr/local/src/xemacs-21.0-b54 What installation prefix should install use? /usr/local/xemacs-beta What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11/include Where do we find X Windows libraries? /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using POP for mail access Using Lisp_Objects with minimal tagbits. Using indexed lrecord implementation. > Contents of /usr/local/src/xemacs-21.0-b54/beta.err > keeping lines matching > "^--\[\[\|\]\]$\|make\[\|error\|warn\|pure.*$space\|size$\|hides\b\|strange\|shadowings\|^Compilation\|not\s-+found" > and then deleting lines matching > "confl.*with.*auto-inlining\|/usr/local/src/xemacs-21\.0-b54/lisp/[^ ]+ hides "

1 participants
0 comments

Re: PMG problems 25 years, 10 months

SL Baur

Amir J Katz <amir(a)ndsoft.com> writes in xemacs-beta(a)xemacs.org: > I enclose two PNG images: > welcome.png - displays OK in xv 3.10a, fails in xemacs; It only fails in TM. C-x C-f displays it. Perhaps the fact that it is a GIF with a .png extension has something to do with the failure. $ file /tmp/welcome.png /tmp/welcome.png: GIF image data, version 87a, 337 x 265, > opussum.png - displays OK in xemacs, fails in xv; > Versions: libpng-1.0.2 > zlib-1.1.3 > Any idea? I don't see a problem.

1 participants
0 comments

Re: Macros: Scheme vs Common Lisp 25 years, 10 months

Michael Sperber

>>>>> "Clemens" == Clemens Heitzinger <cheitzin(a)rainbow.studorg.tuwien.ac.at> writes: Clemens> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> Sure, but there's no guarantee that a given macro has hygienic >> behavior. Generally, maintaining hygiene this way is pretty tedious, >> which is why programmers usually don't go to the necessary lengths. >> >> Also, a macro might refer to bindings whose names are free in the >> macro definition. There's no guarantee that you'll get the same >> bindings for a use that you referred to at the point of definition. Clemens> Maintaining hygiene is *not* pretty tedious. If you want your CL macro Clemens> to be hygienic, use Clemens> (defmacro with-hygienic-variables (var &body body) Clemens> `(let ,(loop for var in vars collect Clemens> `(,var (make-symbol ,(symbol-name var)))) Clemens> ,＠body)) I'm not sure what you're trying to do. The macro, as it stands, is buggy. I assume you mean "vars" instead of "var" in the argument list. Even then, it's not clear what you're trying to do. It looks just like some syntactic sugar around renaming variables. Clemens> Therefore, in situations where non-hygienic macros have advantages, Clemens> use a non-hygienic macro. When you want hygienic variables, use the Clemens> macro above (or write your own define-hygienic-macro, which uses the Clemens> above). It is as simple as that. Unfortunately, no. If used correctly, WITH-HYGIENIC-VARIABLES, can only prevent inadvertent capture problems. To do this, you still have to list the variables to be renamed explicitly, and you still need to get the unquoting right to actually make use of them. Thus, it makes maintaining hygiene only marginally easier. You still need all annotations you needed originally, they just become smaller. Hygiene, however, means that variables in macros obey the same scoping rules as the rest of the language. WITH-HYGIENIC-VARIABLES gives you no help whatsoever referring to lexical bindings of the macro. CL macros are not hygienic, period. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: PMG problems 25 years, 10 months

Amir J. Katz

Should be 'PNG problems'. Oops. -- /* Amir J. Katz mailto:amir＠nuke-spam.com */ /* [For e-mail, replace 'nuke-spam' with 'ndsoft'] */ /* EagleEye Control Software, LTD. http://www.ndsoft.com */ /* 'Is "tired old cliche" one?' (Steven Wright) */

1 participants
0 comments

Re: Bug: Customize open-up.png glyph is getting confused with W3 25 years, 10 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > The function `widget-glyph-find' in wid-edit.el uses a suboptimal > algorithm to find glyphs. It puts `widget-glyph-directory' or > (locate-data-directory "custom") at the front of a search path, > then adds `data-directory-list'. This would be fine except that it > then proceeds to search for a list of formats across the whole > search path with priority going first to .xpm, then to .gif, .png, > .jpg, and .xbm. NOTE 1: I would argue that .png should go to the > head, followed by .xpm, .gif, .jpg and .xbm. You are right. The correct solution is to not use `locate-file' (<whimper>), but to hand-code the loop like this: (loop across directories (loop across formats ... if found, exit the outer loop ...)) Current code essentially reverses the loops, which really is suboptimal in this case. > Noting also that the `widget-glyph-cache' only caches the basename, > not the path, it seems like all glyph names across XEmacs and Lisp > extensions must be unique. I don't believe this is a restriction we > can or should enforce. This is no restriction -- if you request a glyph named "foo", it is only logical that you get the same thing next time. If you use "/foo/bar/foo.png", you'll get what you want. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Reporter: Mr Gandhi, what do you think of Western Civilization? Gandhi: I think it would be a good idea.

1 participants
0 comments

Re: 28 bit ought to be enough for anyone. 25 years, 10 months

Simon Josefsson

karlheg(a)inetarena.com (Karl M. Hegbloom) writes: > Simon> Since my lack of knowledge of XEmacs internals prevents me > Simon> from doing it properly, I just wanted bignums for doing > Simon> some authentication/encryption stuff. The `calc' package > Simon> will be enough for me until I want performance. In this > Simon> case, a native bignum implementation or a elisp-library > Simon> that uses GMP is equally good for my purposes. > > Or you could call out to an external program to do the math, couldn't > you? That's not hard to do. My point was having a native GSSAPI/Kerberos5 implementation written in Elisp. I will write a API for the bignum stuff so I can switch between Calc/GMP/externalprogram/whatever without breaking anything else, so if calc turns out to be too slow even for developing I could do something like this. (Yeah, I know, I will never be finished with this until Kerberos 10 is out, but it's great hack value and I'll probably learn a lot)

1 participants
0 comments

[Success] 21.0 "Finnish Landrace" XEmacs Lucid on i686-pc-linux 25 years, 10 months

Hayashi Tanaka

Patched up from beta53. It seems working fine. (BTW, now Emacs-20.3 is annoying me. :-) > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /home/tanaka/src/xemacs-21.0-b54/Installation: > (Output from most recent run of ./configure)

1 participants
0 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 August 1998