v
>
><[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
>
>
>
> ___
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/gcl-devel
>
>
>
--
Camm Maguire
l)
>
> GCL causes a read error but should not as far as I can see.
>
> Bob
>
>
>
>
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth
it we can make
use of atlas tuned blas copy routines. You can confirm/refute in
part by doing objjdump -d gbc.o | grep xmm
3) I'd love to see a breakdown preferably by routine of the run-gbc
time improvements. I don't suppose icc speaks gprof?
Take care,
>
>
}
> }
>
> See the sbcl-devel thread "Memory randomization problems coming" for
> some more information on this.
>
> --
> Juho Snellman
>
>
>
> _______
> Gcl-devel maili
7;m trying to debug it now but I thought I'd mention it in case
> anyone already knows why.
>
> Tim
>
>
>
--
Camm Maguire[EMAIL PROTECTED]
==
it was still
> rather more slow than sbcl or cmucl. I'd like to see where
> the performance bottleneck is for further tuning.
>
> Paul
>
>
> _______
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://
er more slow than sbcl or cmucl. I'd like to see where
> the performance bottleneck is for further tuning.
>
> Paul
>
>
> _______
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/gcl-devel
>
>
inate all but the fast one when len
is declared or autodeclared appropriately.
Lastly, we need to ensure that 2.7 is at least as fast as 2.6.7,
whatever that means :-).
Take care,
> Paul
>
>
>
> ___
> Gcl-deve
Take care,
> Allegro, Clisp, and CMU all return nil.
>
>
> 2. ``(,@,@nil) causes an error. Quite a number of the backquote forms in the
> clisp test suite cause GCL to cause an error.
>
>
>
>
>
--
Camm Maguire
Greetings! Am I correct in assuming that I can make all arrays simple
arrays?
Take care,
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankin
Greetings, and thanks for this tip!
Need one parse toplevel forms other than let and let*?
Take care,
[EMAIL PROTECTED] writes:
> Quoting Camm Maguire <[EMAIL PROTECTED]>:
>
> > Greetings, and thanks for the pointer!
> >
> > We may be able to address the non-nul
ompiled and debugging is off, then one will either overrun the C
stack with a segfault or proceed forevever depending on whether GCL
has eliminated the recursion. One can see explicitly what is going on
by examining the compiler notes. I think Tim may be patching the GCL
sour
m/gcl-devel@gnu.org/msg00287.html
> > So maybe there is still a problem lurking out there?
>
> That depends on the Axiom interpreter/compiler. Since Common Lisp
> doesn't guarantee proper tail recursion, it isn't an error that
> tail recursive code can run out of stack spac
mailing list
> Gcl-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/gcl-devel
>
>
>
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its c
CL-TEST::BIT-VECTOR-IS-NOT-SIMPLE-VECTOR,
CL-TEST::SIMPLE-BIT-VECTOR-IS-NOT-SIMPLE-VECTOR.
Take care,
> Paul
>
>
> ___
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/gcl-devel
>
&
Greetings!
"Paul F. Dietz" <[EMAIL PROTECTED]> writes:
> Camm Maguire wrote:
>
> > Yes, it does seem as a construct to aid in array compilation
> > optimization. The point to me is that I don't see the overwhelming
> > benefit given the definit
Greetings!
Camm Maguire <[EMAIL PROTECTED]> writes:
> Greetings!
>
> Is there anything you know in the test suite, possibly with other
> #+gcl macros, which can describe what is going on here?
>
Please disregard this -- I found the pcl bug fixed separately in cmucl
and ap
ert attempt
> >
> > cc1.exe: unrecognized option `-fno-zero-initialized-in-bss'
> >
> > Error: (SYSTEM "gcc -c -Wall -DVOL=volatile -fsigned-char -pipe
> > - -fno-zero-initialized-in-bss -mms-bitfields -march=i386
> > - -IC:/PROGRA~1/ACL2-2.9.2/lib/gcl-2.6.6/
> > unixpo
(EQ (CDR DECL-BODY) 'NIL)
> (IF (EQ # #) (# # BINDINGS FORM) 'NIL))
> 'NIL)
> 'NIL),
> for LET* failed.
> -end of response --
>
>
> On Fri, 2 Sep 2005, Camm Maguire wrote:
>
> > Greetings, and pleas
n, please let me know.
Take care, and thanks for your work on Axiom!!!
BTW, is there an FC4 fix I can apply to the code, or does FC4 require
root disabling of certain randomization via
echo 0 > /proc/sys/kernel/randomize_va_space
?
May need a sm
(unsigned
char) for each size type. This is what I've implemented at
present, and I'm passing all relevant tests. I'd obviously like to
support the minimum number of types possible, if for no other
reason than it slows down subtypep et. al. on (array *).
Tak
Greetings!
Vanuxem Grégory <[EMAIL PROTECTED]> writes:
> Le lundi 05 septembre 2005 à 13:42 +0200, Vanuxem Grégory a écrit :
> > Le dimanche 04 septembre 2005 à 23:38 -0400, Camm Maguire a écrit :
> > > Greetings!
> > >
> > > What is '(array ni
t; to nil. This looks like it may be a bug in
> gcl's EVAL function.
>
> Camm, if you could look at this and tell me
> what's happening, I'd appreciate it. If I
> use MACROEXPAND to expand the setf form, the
> tests pass, even under EVAL.
&
he interim -- I will try to retrieve them from there is
necessary.
Take care,
"Paul F. Dietz" <[EMAIL PROTECTED]> writes:
> Camm Maguire wrote:
> > Greetings!
> > 1) I've checked in my recent stuff. Bug list diff below. If you
> > have
> >
ou want to investigate these recent changes, I'd recommend the
switches above.
Take care,
"Paul F. Dietz" <[EMAIL PROTECTED]> writes:
> Camm Maguire wrote:
> > Greetings!
> > 1) I've checked in my recent stuff. Bug list diff below. If you
> > have
Greetings! Please disregard the earlier note re: optimization. Was a
problem in the cltl1 image, which is now fixed. Am releasing a debian
gclcvs package.
Take care,
"Paul F. Dietz" <[EMAIL PROTECTED]> writes:
> Camm Maguire wrote:
> > Greetings!
> > 1) I'
CTED]> writes:
> Camm Maguire wrote:
> > Greetings!
> > 1) I've checked in my recent stuff. Bug list diff below. If you
> > have
> >a moment, please check that I haven't messed it up through omission
> >or commission.
>
> Wow! Lots o
s well. The earlier call was a 'personality set'. Do you
have any idea of an analogous syscall here?
Take care,
> Tim
>
>
>
--
Camm Maguire[EMAIL PROTECTED]
Greetings! Have retored connectivity now. Am wondering if no news is
good news :-)
Take care,
"Paul F. Dietz" <[EMAIL PROTECTED]> writes:
> Camm Maguire wrote:
> > Greetings!
> > 1) I've checked in my recent stuff. Bug list diff below. If you
> &g
(emit-1-t-dlap (car wrappers) 'miss value-reg))
>(t
> (emit-1-nil-dlap (car wrappers) 'miss)))
> (return-from dfun ,hit))
> miss
> (return-from dfun ,miss))
>
>
>
--
Camm Maguire
TED]@#`cat ../minvers | cut -f1 -d.`#1" \
> -e "[EMAIL PROTECTED]@#`cat ../majvers`#1" \
> -e "[EMAIL PROTECTED]@#\"gcc -c -Wall -DVOL=volatile -fsigned-char -
> pipe \"#1" \
> -e "[EMAIL PROTECTED]@#\"gcc -
>
> Thank you for suggestions and comments,
>
> Nicolas.
>
> P.S.: I have tried also porting Femlisp to ECL, but got stuck with other
> problems. Hmmm, it looks as if the source codes of GCL and ECL have really
> diverged a lot.
>
>
> __
rous TCL/TK variables culled from the tkConfig.sh and tclConfig.sh
> # if these are found.
> TK_CONFIG_PREFIX=
> TK_LIBRARY=
> TCL_LIBRARY=
> TK_XINCLUDES=
> TK_INCLUDE=
> TCL_INCLUDE=
> TK_LIB_SPEC=
> TK_BUILD_LIB_SPEC=
> TK_XLIBSW=
> TK_XINCLUDES=
> TCL_LIB_SPEC=
? I was thinking about just one
pass, and building up a network of linked type-setter functions as you
go, but this appears too ambitious at present.
Take care,
--
Camm Maguire[EMAIL PROTECTED
g over while trying to allocate within
> gcl:
>
>
>
> Thanks,
> Mark
>
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one coun
o alternate definitions, one with 0 args,
one with 1.
Take care,
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens.&q
to /bin/bash
> Kernel: Linux 2.6.12-3-32bit
> Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8)
>
>
>
>
--
Camm Maguire[EMAIL PROTECTED]
==
"Th
ans, debian-devel as this issue appears commensurate with libc and
gcc version change transition planning, etc.
> On Tue, Sep 20, 2005 at 10:09:03AM -0400, Camm Maguire wrote:
> > Greetings!
> >
> > Do we have a plan or policy regarding packages which need to depend on
> >
segment __LINKEDIT at 0xdd5000 - 0xeb65b8 (sz:0xe15b8)
> Writing LC_LOAD_DYLINKER command
> Writing LC_LOAD_DYLIB command
> Writing LC_LOAD_DYLIB command
> Writing LC_SYMTAB command
> Fixed u
t;
> For example, (apply #'+ (list* 1 2 3)), which GCL now says is 6, causes an
> error in Allegro, CMU, and Clisp. Even in Emacs Lisp.
>
> Why do I care? If you get rid of dotnil, that will make type_of one
> instruction faste
Using
'gethostbyname' in statically linked applications requires at runtime the
shared libraries from the glibc version used for linking
etc.
We could either
1) ignore the situation
2) omit the functionality if possible
3) try to provide static functionality.
Suggestions?
Take care,
-
ons, such as `getwd', as well as the
subroutines for division and remainder, modify g3 and g4. g1 and g2
are local temporaries.
On the 68000, a2 ... a5 should be suitable, as should d2 ... d7. Of
course, it will not do to use more than a few of those.
==
shed loading gazonk1.o
#
NIL
NIL
>(setq foo (make-list 1000) bar nil)
NIL
>(time (me 10 foo))
real time : 1.140 secs
run-gbc time: 1.140 secs
child run time : 0.000 secs
gbc time: 0.000 secs
NIL
>(time (me 'a foo))
real time :
s of
course begs the question whether equal optimizations have any meaning
if one can change the function definition, etc. Are symbols in
certain packages sacrosanct in this sense?
Take care,
--
Camm Maguire
7;m aining at the functions on the sequence page of
the spec.
Take care,
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens.&qu
:217.580 secs
>
> 2376.85
>
> Thanks,
>
> Bob
>
>
>
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and m
pair in a type-and hash table.
This appears to save only one cons per lookup over the equal hash
strategy, so the main benefit must be speed, which is remarkable,
i.e. that three eq lookups are faster than one equal lookup. Are
these assumptions of mine misguid
has to decide when to "forget" or death from memory exhaustion will
> ensue. But it's not very clear in general when to flush. compile-file might
> provide a good beginning/end pair for the forgetting process.
>
P.S. we flush the cache on each compile-file now in cvs HEAD
gy
for types, though it might be nice to get a sense on where the
transition point is someday.
Just committed a first stab at type memoization (based on equal
hashing) in the compiler together with a few other type fixes. I
think you should see some performance g
Greetings!
"Paul F. Dietz" <[EMAIL PROTECTED]> writes:
> Camm Maguire wrote:
> > Greetings!
> > What is '(array nil) suposed to mean?
>
> It's the type of arrays with element type nil.
>
> These arrays are specialized to hold nothing at all
Greetings!
Vanuxem Grégory <[EMAIL PROTECTED]> writes:
> > -Message d'origine-----
> > De : Camm Maguire [mailto:[EMAIL PROTECTED]
> > Envoyé : mardi 6 septembre 2005 16:05
> > À : Vanuxem Grégory
> > Cc : gcl-devel@gnu.org
> > Objet
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer
> -I/home/dietz/gcl/o -I../h -I../gcl-tk multival.c
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer
> -I/home/dietz/gcl/o -I../h -I../gcl-t
Greetings! What is logl? What kind of machine is this? C references
to log apparrently reference both log and logl as external symbols.
No logl on my system.
Take care,
"Paul F. Dietz" <[EMAIL PROTECTED]> writes:
> Camm Maguire wrote:
> > Greetings, and thanks!
Greetings!
"Paul F. Dietz" <[EMAIL PROTECTED]> writes:
> Camm Maguire wrote:
> > Greetings! What is logl? What kind of machine is this? C references
> > to log apparrently reference both log and logl as external symbols.
> > No logl on my system.
>
>
hope that this will
always force addresses to be placed in the symbol table of the
executable.
Take care,
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country
Greetings, and great to hear this.
Nicolas Neuss <[EMAIL PROTECTED]> writes:
> Nicolas Neuss <[EMAIL PROTECTED]> writes:
>
> > Camm Maguire <[EMAIL PROTECTED]> writes:
> >
> >> Greetings!
> >>
> >> Please try gclcvs -50, now in un
binutils is upgraded to 2.16, and built locally in Debian by
default.
5)Certain improvements to optimization when using compile as
opposed to compile-file have been made. compile, unlike
compile-file, must ref
Greetings!
Nicolas Neuss <[EMAIL PROTECTED]> writes:
> Camm Maguire <[EMAIL PROTECTED]> writes:
>
> > I'll try to get equalp hashing into head in the next few days.
> > Hopyfully we should have a t6 tag and another debian upload soon.
>
> Wonderful!
there is a hardoded heap max somewhere which does not scale with
the configuration settings.
2) The SGC problem is the same you were diagnosing when we last
corresponded. The records are all in gcl-devel. If memory serves,
you found that the sgc_type_map values were not be
tch please.
>
> Perhaps we could keep such a picture in CVS as a binary file for future
> reference?
>
> Cheers
>
> Mike Thomas.
>
>
> -Original Message-
> From: Mike Thomas [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 11 August 2005 7:52 AM
> T
table) are most welcome.
>
> I'm quite happy to just grab 2.7.0 and take my chances. I keep the last
> version of 2.7.0 I have grabbed that worked around just in case the new one
> is broken.
>
> Thanks,
>
> Bob
>
>
>
--
Camm Maguir
33 writable)..(T=32).GC finished]
> [SGC for 20062 CONS pages..(23067 writable)..(T=55).GC finished]
> [SGC for 32563 CONS pages..(35568 writable)..(T=86).GC finished]
> [SGC for 51314 CONS pages..(54319 writable)..(T=140).GC finished]
> [SGC for 79441 CONS pages..(82446 writable)..
my part of the meaning of those macros.
>
> Cheers
>
> Mike Thomas.
>
>
>
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one coun
t;[EMAIL PROTECTED]> writes:
> You might consider sort, remove, and nconc.
>
> Thanks,
>
> Bob
>
>
--
Camm Maguire[EMAIL PROTECTED]
==
d be some sort of race condition.
BTW, are you using cvs HEAD or t5? If the former, does it clear your
performance anomaly?
Take care,
> Regards,
> Mark
--
Camm Maguire[EMAIL PROTECTED]
=
downward
> cstack alignment: 16 bytes
> cstack max: 2097152 bytes
> immfix start: 0xc000
> immfix size: 536870912 fixnums
>
> >(si::allocate 'cons 502043 t)
>
> T
>
> >(/ (* 502043 4096) 8)
>
> 257046016
>
variable *break-prompt*? We have to be a bit
careful as we actually have two break-levels -- the one in clcs/
overwrites the function to include ansi restarts. In fact, it is on
my todo list to track down some conflict here which makes backtraces
much slower in the ansi build in cvs, and even pos
Greetings!
"Paul F. Dietz" <[EMAIL PROTECTED]> writes:
> Camm Maguire wrote:
>
> > Also inlined are: length and reverse, endp and identity are expanded,
> > the former to throw an error only when safety >=1.
> > There is an unused heap sort in the code
Greetings! Should have mentioned -- if anyone wants to expermiment
with disabling certain inlining/expansions, they should remove the
compiler::compiler-macro-prop property from the symbol in question.
Eventually no-inline declarations should do this.
Take care,
--
Camm Maguire
t;{tailp}{list}{a proper list or a dotted list}
>{ldiff}{list}{a proper list or a dotted list}
>{ldiff, tailp}{list}{a proper list or a dotted list}
>{butlast, nbutlast}{list}{a proper list or a dotted list}
>{endp}{list}{a list}
> {lis
t. But CAR, CDR and friends handle it just fine. Do you
> want someone to give you a list that includes CAR, CDR, and friends? It will
> be long.
Your other list has sufficed quite fine -- the dotnil removed version
fails 15 more ansi tests, which I will fix and then upload.
Take car
to be made at runtime at 0x4000
even when using static linking. ACL2 does this via its call to our
user-homedir-pathname function. Without this call, or if I can figure
out how to get same without the above system calls, you should be good
for 2gb on 32bit machines.
Take care,
--
Camm Ma
GPL'ed components: (BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
>
> Use (help) to get some basic information on how to use GCL.
>
> >
>
>
>
--
Camm Maguire
t's amazing
> that Camm tracked this down as the source of the problem we were having.
>
> Bob
>
>
>
>
--
Camm Maguire[EMAIL PROTECTED]
=
Greetings!
"Paul F. Dietz" <[EMAIL PROTECTED]> writes:
> Camm Maguire wrote:
>
> > Just my thoughts, Feeback most welcome.
>
> subtypep doesn't appear to be particularly slow, as judged by
> the speed of the random subtypep tester (it appears to be
Greetings!
Nicolas Neuss <[EMAIL PROTECTED]> writes:
> Camm Maguire <[EMAIL PROTECTED]> writes:
>
> > OK, preliminary equalp hashing is in CVS head. Are you comfortable
> > compiling from there, or do you prefer to wait for Debian package
> > migration.
eck
of the evaluation of these forms under all eval-when scenarios, What
we have now might not be quite hardened yet.
Take care,
Nicolas Neuss <[EMAIL PROTECTED]> writes:
> Camm Maguire <[EMAIL PROTECTED]> writes:
>
> > Thank you for this. This is indeed a reproducible b
and
vectors, character traits, setf gethash interpreter fix, make-hash-
table ansi fixes, simple-vector-p ansi fix, print-symbol fixes, set-
syntax-from-char fixes, rework loose package syntax, prohibit loose
right paren in reader
Take care,
--
Camm Magu
little
clarification on how SET-SYNTAX-FROM-CHAR.SHARP.1 and the remaining
failures in print.symbol.random.? are supposed to behave if you have a
moment.
Take care,
> Paul
>
> Camm Maguire wrote:
> > Greetings! There appears to be a small problem with the commit I
> > n\made last
-zxf ${ZIPS}/${GCLVERSION}.tgz
> > <>
> > @echo 13 finished system build on `date` | tee >gcldir
> >
> > ccldir: ${LSP}/ccl/Makefile
> > @echo 14 building CCL
> > @mkdir -p ${INT}
ne :-). Am a bit tight on time at the moment though.
> I don't know much about Debian, but I understand that there is
> some utility for accessing Debian products on "alien" linuxes.
> Has anyone tried using this approach to install Axiom on other
> platforms?
Creation date: |) t)
> |; Creation date: |
> |; Creation date: |
>
> >
>
>
>
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its c
>
> To: Robert Boyer <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], gcl-devel@gnu.org
> Subject: Re: case insensitivity issue for package names
> References: <[EMAIL PROTECTED]>
> From: Camm Maguire <[EMAIL PROTECTED]>
> Date: 09 Aug 2005 01:45:28 -0400
> In-R
(*read-base* 10.)
> (*package* *keyword-package*))
> (read stream t nil t)))
> (let ((*read-suppress* t)) (read stream t nil t) (values))
> (values (read stream t nil t
>
> (set-dispat
ssarily one that would be valid for use as
> a name in defun or function, for example. By convention, nil is used to mean
> that function has no name. Any implementation may legitimately return nil as
> the name of any function.
>
> ...
>
> Although implementations are free to return ``nil, true
Greetings! Hmm, I'm getting (1), which is not nil and therefore
correct -- do we have a skew issue?
Take care,
Robert Boyer <[EMAIL PROTECTED]> writes:
> According to the ANSI manual,
>
> (typep #c(1 1) '(complex (eql 1))) => true
>
> but 2.7.0 now say
ested at
http://people.debian.org/~igloo/status.php?email=camm%40enhanced.com
Take care,
> Thanks to all of you again for your help.
>
> Best regards,
>
> Renaud
>
>
>
>
--
Camm Maguire
Greetings, and please excuse the delay.
Nicolas Neuss <[EMAIL PROTECTED]> writes:
> Hello,
>
> Camm Maguire <[EMAIL PROTECTED]> writes:
>
> >> 1. The declaration of return values is probably NYI:
> >>
> >> (defun foo ()
> >>
p with SSE instructions a
la icc, make sure we beat the other implementations on relevant
bechmarks then release :-).
Take care,
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth i
have
managed to avoid thus far. Am I overlooking something hoefully much
more simple?
Take care,
> Bob
>
>
>
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth is
t Robin Milner had the final say on everything. There
> is something to be said for benevolent dictatorship, even in software. But
> not much.
>
Thanks for the above well taken points. Wonder what the best way is
to design a language. I'
see you've accomplished the case lowering without me having to
backport readtable case, which is now in CVS head, into a stable gcl
release. Hope this is adequate. readtable case can now be made
available if not.
Take care,
--
Camm Maguire[
ly get back all the lambdas!
Otherwise, you need to keep the source and compiled files together, and no
one has ever been able to do that really right, though I suspect it can be
done. Maybe MD5 to the rescue, so you can be "sure" you have relocated the
right damn source file?
=
Yes,
at the coarse grained level much easier. If
memory serves they recommend predistribution of the processes via mpi.
Take care,
> On Sat, Jul 23, 2005 at 03:11:36AM -0400, Camm Maguire wrote:
> > Greetings! Please excuse my delay, and thank you *so* much for
> > working on this
we may be able
to boil it down to a few primitives. Just thought I'd solicit ideas
on the best behavior during overflow from those expressing related
interests in the past.
Take care,
--
Camm Maguire
ead, point to a location on the stack which points to the binding
-- this should automate the 'spaghetti-stack' concept. Finally, put a
global lock around the gc, though the mark phase should be able to
proceed threaded.
Just ideas at this stage. Comments and thoughts most welcome.
m David Rager (a student of mine) and I have been
> working on a bit.
>
> David has been attempting to parallelize ACL2 computations using
> OpenMCL. After various conversations with Gary Byers (the "Camm
> Maguire" of OpenMCL), we learned that Gary had to very carefully
(si::close-fasd x)))
r)
=
Polling the socket via #'listen is available.
Take care,
--
Camm Maguire[EMAIL PROTECTED]
enhanced
color solid 24")
))
-(defvar $viewps_command "(ghostview \"~a\")")
+(defvar $viewps_command "(gv \"~a\")")
;;(defvar $viewps_command "(gs -I. -Q ~a)")
=
Take care,
Cam
(LIST* '(DM2B X1 (((INCF X2) X3 X4))
>X5 X6)
> X1
> 'INCF X2) X3 X4)) (SETQ X2 (+ X2 1)) (X3 X4) 5 (X5 X6))),
> T
> (let ((x1 5))
>(macrolet ((segundo (x) `(cadr ,x)))
> (dm2b x
301 - 400 of 2033 matches
Mail list logo
