Re: What is a type error?
Marshall <[EMAIL PROTECTED]> wrote:
+---
| Joachim Durchholz wrote:
| > Actually SQL has references - they are called "primary keys", but they
| > are references nevertheless.
|
| I strongly object; this is quite incorrect. I grant you that from the
| 50,000 foot level they appear identical, but they are not.
+---
Agreed. The only thing different about "primary" keys from any other
key is uniqueness -- a selection by primary key will return only one
record. Other than that constraint, many databases treat them exactly
the same as non-primary keys [e.g., can form indexes on them, etc.].
+---
| To qualify as a reference, there need to be reference and dereference
| operations on the reference datatype; there is no such operation is SQL.
+---
Not in "ANSI SQL92", say, but there might be in most SQL databases!
[See below re OIDs. Also, SQL:1999 had a "REF" type that was essentially
and OID.]
+---
| Would you say the relational algebra has references?
+---
Don't confuse "SQL" & "relational algebra"!! You'll get real
relational algebraists *way* bent out of shape if you do that!
+---
| > (Some SQL dialects also offer synthetic "ID" fields that are
| > guaranteed to remain stable over the lifetime of a record.
|
| Primary keys are updatable; there is nothing special about them.
+---
I think he's probably talking about "OIDs" (object IDs). Most
current SQL-based databases provide them, usually as a normally-
invisible "system column" that doesn't show up when you say
"SELECT * FROM", but that *does* appear if you say "SELECT oid, *",
and may be used as a "primary" key even on tables with no actual
primary key:
rpw3=# select * from toy limit 4;
c1 | c2 | c3 | upd
+---++-
fall | tape | My Favorite Thanksgiving | 16
xmas | book | My Favorite Christmas | 2
xmas | video | The Grinch who Stole Christmas | 4
summer | book | Unusual 4ths of July | 17
(4 rows)
rpw3=# select oid, * from toy limit 4;
oid | c1 | c2 | c3 | upd
---++---++-
19997 | fall | tape | My Favorite Thanksgiving | 16
19998 | xmas | book | My Favorite Christmas | 2
1 | xmas | video | The Grinch who Stole Christmas | 4
2 | summer | book | Unusual 4ths of July | 17
(4 rows)
rpw3=# select * from toy where oid = 19998;
c1 | c2 | c3 | upd
--+--+---+-
xmas | book | My Favorite Christmas | 2
(1 row)
rpw3=# insert into toy values ('fall','book','Glory Road');
INSERT 32785 1
rpw3=# select oid, * from toy where oid = 32785;
oid | c1 | c2 | c3 | upd
---+--+--++-
32785 | fall | book | Glory Road | 21
(1 row)
rpw3=#
See <http://www.postgresql.org/docs/8.1/static/datatype-oid.html>
for how PostgreSQL treats OIDs [including some critical limitations].
-Rob
-
Rob Warnock <[EMAIL PROTECTED]>
627 26th Avenue http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Joachim Durchholz <[EMAIL PROTECTED]> wrote: +--- | INSERT cannot be expressed in terms of assignment. INSERT creates a new | record; there's no way that assignment in a language like C can create a | new data structure! The same goes for DELETE. +--- Well, what about "malloc()" & "free()"? I mean, if your "database" is a simple linked list, then INSERT is just: ROW *p = malloc(sizeof *p); p->field1 = value1; p->field2 = value2; ... p->fieldN = valueN; database = cons(p, database); /* Common Lisp's CONS */ and DELETE is just: ROW *p = find_if(predicate_function, database); /* CL's FIND-IF */ database = delete(p, database); /* CL's DELETE */ free(p); [There are single-pass methods, of course, but...] -Rob - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Rob Thorpe <[EMAIL PROTECTED]> wrote:
+---
| > So, will y'all just switch from using "dynamically typed" to "latently
| > typed", and stop talking about any real programs in real programming
| > languages as being "untyped" or "type-free", unless you really are
| > talking about situations in which human reasoning doesn't come into play?
|
| I agree with most of what you say except regarding "untyped".
|
| In machine language or most assembly the type of a variable is
| something held only in the mind of the programmer writing it, and
| nowhere else. In latently typed languages though the programmer can
| ask what they type of a particular value is. There is a vast
| difference to writing code in the latter kind of language to writing
| code in assembly.
|
| I would suggest that at least assembly should be referred to as
| "untyped".
+---
Another language which has *neither* latent ("dynamic") nor
manifest ("static") types is (was?) BLISS[1], in which, like
assembler, variables are "just" addresses[2], and values are
"just" a machine word of bits.
However, while in BLISS neither variable nor values are typed,
operators *are* "typed"; that is, each operator specifies how
it will treat its input machine word(s) and how the machine word(s)
of bits it produces should be interpreted. So "+" is (mod 2^wordsize)
[unsigned?] integer addition, and "FADR" is floating-point addition
with rounding (as opposed to "FADD", which truncates), and so on.
So this (legal but non-sensical!) BLISS:
x := .y FMPR (.x - 13);
would, in C, have to be written roughly like this:
((void*)x) = (void*)((float)(*(void*)y) * (float)((int)(*(void*)x) - 13));
On the PDP-10, at least, both of them would generate this assembler code:
move t1, x
subi t1, 13
fmpr t1, y
movem t1, x
So is BLISS "typed" or not? And if so, what is that kind of typing called?
-Rob
[1] "Basic Language for the Implementation of Systems Software",
see <http://en.wikipedia.org/wiki/BLISS>. Created at CMU,
added-to by DEC, used by CMU, DEC, and a few others for in
the 70's-80's.
[2] Well, approximately. A BLISS variable is, conceptually at least,
really a "byte-pointer" -- a triple of a word address, a byte-size,
and a byte-position-within-word -- even on target architectures
other than the DEC PDP-10 [which had hardware byte-pointer types].
The compiler (even on the PDP-10) optimizes away LDB/DPB accesses
into natively-addressible load/store sizes, when possible.
-
Rob Warnock <[EMAIL PROTECTED]>
627 26th Avenue http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall <[EMAIL PROTECTED]> wrote: +--- | Anton van Straaten wrote: | > 3. A really natural term to refer to types which programmers reason | > about, even if they are not statically checked, is "latent types". It | > captures the situation very well intuitively, and it has plenty of | > precedent -- e.g. it's mentioned in the Scheme reports, R5RS and its | > predecessors, going back at least a decade or so (haven't dug to check | > when it first appeared). | | Can you be more explicit about what "latent types" means? | I'm sorry to say it's not at all natural or intuitive to me. | Are you referring to the types in the programmers head, | or the ones at runtime, or what? +--- Here's what the Scheme Standard has to say: http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-4.html 1.1 Semantics ... Scheme has latent as opposed to manifest types. Types are assoc- iated with values (also called objects) rather than with variables. (Some authors refer to languages with latent types as weakly typed or dynamically typed languages.) Other languages with latent types are APL, Snobol, and other dialects of Lisp. Languages with manifest types (sometimes referred to as strongly typed or statically typed languages) include Algol 60, Pascal, and C. To me, the word "latent" means that when handed a value of unknown type at runtime, I can look at it or perform TYPE-OF on it or TYPECASE or something and thereby discover its actual type at the moment[1], whereas "manifest" means that types[2] are lexically apparent in the code. -Rob [1] I added "at the moment", since I remembered that in Common Lisp one may change the type of a value at runtime, specifically, a CLOS instance may change type "out from under you" if someone performs a CHANGE-CLASS on it or redefines its CLASS definition. [Though maybe the latter is more a change of the *type* itself rather than a change of the *object's* type per se.] [2] Usually of a variables or locations, but sometimes of expressions. - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Pillsy <[EMAIL PROTECTED]> wrote: +--- | hankhero wrote: | > Pythons advantages are: | > Faster startup-time which makes it a good scripting language. | | ... but on my machine, SBCL starts up and runs a "Hello World" | program a bit faster than Python, and CLisp really blows its doors off. +--- On my various machines, CMUCL startup is *slightly* faster than CLISP, but both are under 20 ms... I use Common Lisp for scripting a *lot*! -Rob - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin <http://[EMAIL PROTECTED]> wrote: +--- | Bill Atkins <[EMAIL PROTECTED]> writes: | > This is a silly claim. What observational experience are you talking | > about? Lisp is delightfully readable. In fact, I find it more | > readable than any other language. Why do you think that is? Could it | > be because I use Lisp on a daily basis? Could that also explain why | > Python seems more readable than Lisp to you? | | Python is more readable than Lisp because it stays readable even if | you don't use it on a daily basis. +--- Weird. This is exactly why I use *Lisp* -- because it stays completely readable even if you don't use it on a daily basis!!! [That's also why I *don't* use Perl, except when forced to...] -Rob - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano <[EMAIL PROTECTED]> wrote: +--- | Wolfram Fenske wrote: | > if Common Lisp didn't have CLOS, its object system, I could write my own | > as a library and it would be just as powerful and just as easy to use as | > the system Common Lisp already provides. Stuff like this is impossible | > in other languages. | | Dude. Turing Complete. Don't you Lisp developers know anything about | computer science? | | Anything any language can do is possible in any other language, | if you are willing to write your own libraries. And debug them. +--- Yes, true, but by then you've effectively reimplemented Lisp! ;-} http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule Greenspun's Tenth Rule of Programming [...]: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." -Rob - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Aahz <[EMAIL PROTECTED]> wrote:
+---
| Paul Rubin <http://[EMAIL PROTECTED]> wrote:
| >I think an editing program that balances parens automatically is near
| >indispensible for writing Lisp code. I can't stand writing Lisp
| >without Emacs.
|
| And that is why I will never write Lisp. I loathe Emacs.
+---
An appropriate version of "Vi" is sufficient. I prefer "nvi-1.79",
but have found that the "vim" at work is also adequate. Either will:
1. Flash matching parens on insert; jump back & forth between matching
parens on command ("%").
2. Deal with S-exprs as "objects" for shifting left/right, copying,
deleting, or pasting. [The shifting works best when you gloablly
"set sw=1" and then use "." to repeat the last shift.]
3. Minimal auto-indent, but "good enough" for my purposes [given #2].
That's pretty much all you need to code in Lisp. It's what *I* use.
So "I loathe Emacs" is *NOT* a believable excuse for avoiding Lisp...
-Rob
-
Rob Warnock <[EMAIL PROTECTED]>
627 26th Avenue http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
--
http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
John Thingstad <[EMAIL PROTECTED]> wrote: +--- | (If you want symbols to be case sensitive and default case to be lower | then most Lisp's allow that, but the ANSI spec dosn't give a standard way.) +--- What about (setf (readtable-case *readtable*) :invert)? That's in ANSI. -Rob - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Raffael Cavallaro <[EMAIL PROTECTED]'espam-s'il-vous-plait-mac.com>:
+---
| "George Sakkis" <[EMAIL PROTECTED]> said:
| > If you mistakenly select an extra parenthesis or omit one, it's
| > the same thing.
|
| Because you can't mistakenly select an extra paren or omit one in a
| lisp-aware editor. Whether its a commercial lisp IDE or emacs, you
| don't manually select s-expressions. You put your cursor/point at one
| paren and you tell the editor - with a keystroke or a mouse click - to
| find the matching paren and select everything contained between the two.
+---
And for any of you who are rejecting this because you don't want to
learn or use Emacs, Raffael's point is even true in the Vi family of
editors ("nvi" & "vim", at least). The "y%" command yanks (copies)
everything through the matching paren into the anonymous buffer;
"d%" deletes likewise [and saves in the anonymous buffer]; "p" (or "P")
pastes after (or before) the current location. All can be prefixed
with a buffer ("Q-register") name for more flexibility.
Lisp's parens really *do* make editing ever so much easier!
-Rob
-
Rob Warnock <[EMAIL PROTECTED]>
627 26th Avenue http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
--
http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin <http://[EMAIL PROTECTED]> wrote: +--- | CLTL2 is a model of precision and thoroughness compared | with any document that's ever been written about Python. +--- It's a great book, but one needs to be clear that CLtL2 is *not* the same as the ANSI Common Lisp standard, but was the author's best guess at the time as to where the standardization effort was going after CLtL1. You may find the following useful in marking up your copy of CLtL2 to be closer to the final standard: http://cbbrowne.com/info/commonlisp.html#AEN10499 http://bc.tech.coop/cltl2-ansi.htm But note the caveat therein: A doctored CLTL2 is NOT the ANSI standard. In fact, this FAQ has many known but minor omissions that are too awkward to add with pencil to CLTL2. The Common Lisp HyperSpec (CLHS), while also not the official ANSI standard per se, was created from "the same" TeX input as the ANSI standard (with permission from ANSI & X3), and is the reference most CL programmers use: http://www.lisp.org/HyperSpec/FrontMatter/index.html http://www.lispworks.com/documentation/HyperSpec/Front/index.htm For a downloadable tarball of the whole thing, there's a link near the bottom of this page: http://www.lispworks.com/documentation/HyperSpec/index.html -Rob - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Robert Uhl <[EMAIL PROTECTED]> wrote: +--- | "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: | > I have the code here (probably not the latest bcs I left the company | > when it was acquired), let's do a little experiment, for what it's | > worth: 89727 lines of Lisp code in 131 modules (lisp code files), 3306 | > "(defun" (by grep|wc), and 261 "(defmacro". [We did NOT use macros as | > functions!] [Note that lines of code doesn't really matter in Lisp.] | | Wow--my emacs install has 1,152,598 lines of code in 1,570 files, | 29,244 defuns and 1,393 defmacros. +--- Wow, indeed! The entire CMUCL-19c distribution is "only" 592081 lines of source code in 1192 files, with 10699 DEFUNs and 1839 DEFMACROs. I didn't realize CMUCL was so "small" compared to Emacs. ;-} [Of course, that doesn't include the number of DEFUNs & DEFMACROs which are defined *by* macros, or the total of 2809 DEFINE-VOPs in the various flavors of the compiler...] -Rob - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
<[EMAIL PROTECTED]> wrote:
+---
| Paul Rubin wrote:
| > [...] There are programs you can write in C but not in Lisp,
| > like device drivers that poke specific machine addresses.
|
| I should assume you meant Common Lisp, but there isn't really any
| reason you couldn't
| (poke destination (peek source))
| in some version of Lisp that was meant for writing device drivers
| (perhaps under a Lisp machine or something).
+---
I do this kind of thing *every day* in CMUCL!! It's my primary
user-mode hardware debugging tool. Here's a typical utility function:
;;; Used for things like polling for a "done" flag.
;;; BUG: Assumes contents of ADDR will change within fixnum polls.
(defun spin-until-change (addr)
(declare (optimize (speed 3) (debug 0) (safety 0)))
(loop with v0 of-type (unsigned-byte 32) = (r32 addr)
with counts fixnum = 0
while (= v0 (r32 addr))
do (setf counts (the fixnum (1+ counts)))
finally (return counts)))
+---
| SIOD actually has (%%% memref address) for peek.
+---
CMUCL has SYSTEM:SAP-REF-{8,16,32} and SETFs of same. The R32
above is just my convenience wrapper around SYSTEM:SAP-REF-32:
(declaim (inline r32))
(defun r32 (addr)
(declare (optimize (speed 3) (debug 0) (safety 0)))
(system:sap-ref-32 (system:int-sap addr) 0))
(defun w32 (addr &rest values)
(declare (optimize (speed 3) (debug 0) (safety 0)))
(loop for i fixnum from 0 by 4
and v of-type (unsigned-byte 32) in values
do (setf (system:sap-ref-32 (system:int-sap addr) i) v))
(values))
Most other Common Lisp implementations surely have something similar.
-Rob
-
Rob Warnock <[EMAIL PROTECTED]>
627 26th Avenue http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
--
http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Robert Uhl <[EMAIL PROTECTED]> wrote: +--- | However, the only two which matter are GNU emacs and XEmacs. | Both have supported a GUI for 16 years now. I don't have | XEmacs installed, so I cannot tell you if it has the tutorial. | I would be truly surprised if it didn't. +--- It does. And the default startup splash screen tells you how to access it. -Rob - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: Under the spell of Leibniz's dream
Twisted <[EMAIL PROTECTED]> wrote: +--- | > "Under the spell of Leibniz's dream" (2000) By Edsger W | > Dijkstrahttp://www.cs.utexas.edu/~EWD/ewd12xx/EWD1298.PDF | | A link to a copy in a non-toxic format would be nice. +--- Well, the fact of the matter is that the bulk of Dijkstra's "EWD" papers were written *long* before the web existed, typed on a favorite manual typewriter which he continued using for the remainder of his professional life. <http://www.cs.utexas.edu/~EWD/> has more details on the more than one thousand "EWD"s he wrote. Until very recently, the *only* source for these documents was either in hardback technical books (for the few that were published) or in the PDF bitmaps of scans of the original manually-typed pages, which the University of Texas at Austin has generously made [and even after Dijkstra's death continues to make] available on-line. However, a *few* but "growing number of the PDF bitmap documents have been transcribed to make them searchable and accessible to visitors who are visually impaired." If you would care to volunteer [as over sixty others have done] to contribute to the transcriptions, see <http://www.cs.utexas.edu/~EWD/transcriptions/invitation.html>. Otherwise, just count your blessings that these gems are available at all... -Rob - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: is laziness a programer's virtue?
Daniel Gee <[EMAIL PROTECTED]> wrote: +--- | You fail to understand the difference between passive laziness and | active laziness. Passive laziness is what most people have. It's | active laziness that is the virtue. It's the desire to go out and / | make sure/ that you can be lazy in the future by spending just a | little time writing a script now. It's thinking about time | economically and acting on it. +--- Indeed. See Robert A. Heinlein's short story (well, actually just a short section of his novel "Time Enough For Love: The Lives of Lazarus Long") entitled "The Tale of the Man Who Was Too Lazy To Fail". It's about a man who hated work so much that he worked very, *very* hard so he wouldn't have to do any (and succeeded). -Rob - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: The fundamental concept of continuations
David Kastrup <[EMAIL PROTECTED]> wrote: +--- | George Neuner writes: | > Upward continuations can be stack implemented. On many CPU's, using | > the hardware stack (where possible) is faster than using heap | > allocated structures. For performance, some Scheme compilers go to | > great lengths to identify upward continuations and nested functions | > that can be stack implemented. | | There is a Scheme implementation (I keep forgetting the name) which | actually does both: it actually uses the call stack but never returns, | and the garbage collection includes the stack. +--- You're thinking of "Chicken Scheme": http://www.call-with-current-continuation.org/ Chicken Scheme is actually using the C call stack *as* the heap[1], and thus all its continuations are *heap*-allocated, and thus not actually "stack-allocated" at all. But that's not what George Neuner is talking about, as I read it, but rather probably about such things as Kent Dybvig's PhD thesis: http://www.cs.indiana.edu/~dyb/papers/3imp.pdf "Three Implementation Models for Scheme" R. Kent Dybvig, UNC Chapel Hill, 1987 (thesis) (190pp) ... Chapter 4: The Stack-Based Model ... Early Scheme implementors believed that because of the need to support first class functions, the standard techniques used for block-structured languages were not suitable for Scheme. The need to optimize tail calls and support continuations further convinced early implementors that the standard stack techniques were unsuitable. However, as this chapter will show, these techniques can be made to work for Scheme with a few modications. The resulting implementation model allows most function calls to be performed with little or no allocation, and allows variable references to be performed in one or two memory references. Heap allocation remains necessary to support closures, assigned variables, and continuations. Since function calls and variable references are faster and heap allocation is limited, the running time for most programs is greatly decreased. ... -Rob [1] As suggested in: http://home.pipeline.com/~hbaker1/CheneyMTA.html "CONS Should Not CONS Its Arguments, Part II: Cheney on the M.T.A" Henry G. Baker (1994) - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Pisin Bootvong <[EMAIL PROTECTED]> wrote: +--- | No matter how scalable your language is, you cannot make a 100MHz/128MB | server serve 100,000 client a second over the internet. +--- Sure you can! That's ~1000 CPU cycles/request, which [assuming at least a 100BASE-TX NIC] is plenty to service 100K *small* requests/s... ;-} Of course, you might have to write it in assembler on bare metal, but the good news is that with only a 1000 cycle budget, at least the code won't be very large! ;-} -Rob [someone who remembers 0.5 MIPS DEC PDP-10s being used for >100 simultaneous commercial timesharing users] - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Pisin Bootvong <[EMAIL PROTECTED]> wrote: +--- | Rob Warnock wrote: | > | No matter how scalable your language is, you cannot make a | > | 100MHz/128MB server serve 100,000 client a second over the internet. | > +--- | > | > Sure you can! That's ~1000 CPU cycles/request, which [assuming at least | > a 100BASE-TX NIC] is plenty to service 100K *small* requests/s... ;-} | | Well, I was really asking for a service that really service something | complicate and useful though :-D +--- If "only" being useful is enough, 100 cycles is enough for a DNS server, or an NTP server, or even a stub HTTP server that delivers some small piece of real-time data, like a few realtime environmental sensors [temperature, voltages, etc.]. +--- | > Of course, you might have to write it in assembler on bare metal, | > but the good news is that with only a 1000 cycle budget, at least | > the code won't be very large! ;-} | | And donot forget to account for OS CPU time (well may be you can write | your own OS for it too :-D ) +--- Uh... What I meant by "bare metal" is *no* "O/S" per se, only a simple poll loop servicing the attention flags[1] of the various I/O devices -- a common style in lightweight embedded systems. -Rob [1] a.k.a. "interrupt request" bits, except with interrupts not enabled. - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Ketil Malde <[EMAIL PROTECTED]> wrote: +--- | Sometimes the best documentation is the code itself. | Sometimes the best name for a function is the code itself. +--- And there's no reason that an anonymous LAMBDA [even if compiled] couldn't store its source code in the "name" slot for debugging printouts [e.g., stack backtraces]. -Rob - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Ken Tilton <[EMAIL PROTECTED]> wrote: +--- | Having the reference implementation is the only thing that makes this | conceivably doable in a summer. What you are missing is something I have | often also gotten wrong: the core, cool functionality always comes easy | in the proof-of-concept stage. We make these ridiculous extrapolations | from that to a shipped product and come in five times over budget. +--- Or as Fred Brooks said it in "The Mythical Man-Month" [paraphrased], if a program takes one unit of effort, a programming *system* takes three units of effort, and a programming systems *product* takes nine units of effort. -Rob - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: The Importance of Terminology's Quality
the value to a standard
register [let's say "T0", just for concreteness], and if the callee
wanted to *set* an argument, it executed the *second* word pointed
to by the passed address, with the new value also in a defined place
[again, let's use T0]. So to implement "X := X + 1;" in the callee,
the compiler would emit code like this:
MOVE T1,{the arg (address) corresponding to "X"}
XCT 0(T1) ; fetch the current value of X into T0.
ADDI T0, 1 ; increment it
XCT 1(T1) ; execute the "setter" for X.
Now in the case where the actual parameter in the caller was a
simple global variable, call it "Y", then the address passed as
the arg could be the following "YTHNK" in static data space:
YTHNK: MOVE T0,.+2 ; one-instruction "getter"
MOVEM T0,.+1 ; one-instruction "setter"
Y: BLOCK 1 ; the actual place where the value "Y" lives
Whereas if the argument being passed were some more complicated
expression, such as an array reference or a reference to a local
procedure in the caller, then the 3-word arg block would be passed
on the stack and the passed address would point to this [possibly
dynamically-constructed] triple, where PUSHJ is the PDP-10 stack-
oriented subroutine call instruction:
PUSHJ P,{lambda-lifted getter code}
PUSHJ P,{lambda-lifted setter code}
EXP{lexical contour info needed for getter/setter to work}
Efficient for the simple case; slow-but-correct for the messy case.
-
Rob Warnock <[EMAIL PROTECTED]>
627 26th Avenue http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
--
http://mail.python.org/mailman/listinfo/python-list
Re: The Importance of Terminology's Quality
George Neuner wrote:
+---
| Common Lisp doesn't have "filter".
+---
Of course it does! It just spells it REMOVE-IF-NOT!! ;-} ;-}
> (remove-if-not #'oddp (iota 10))
(1 3 5 7 9)
> (remove-if-not (lambda (x) (> x 4)) (iota 10))
(5 6 7 8 9)
>
-Rob
-
Rob Warnock <[EMAIL PROTECTED]>
627 26th Avenue http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
--
http://mail.python.org/mailman/listinfo/python-list
Re: The Importance of Terminology's Quality
John W Kennedy <[EMAIL PROTECTED]> wrote: +--- | I said "machine language" and I meant it. I haven't touched a 1401 since | 1966, and haven't dealt with a 1401 emulator since 1968, but I can | /still/ write a self-booting program. +--- Heh! I never dealt with a 1401 per se [except when running a 1410 in 1401 emulation mode to run the Autoplotter program, which wasn't available for the 1410], but I still remember the IBM 1410 bootstrap instructions you had to type in on the console to boot from magtape. v v L%B12$N where the "v" accent is the "wordmark" indicator. That says to read in a whole tape record in "load" mode (meaning that wordmarks & groupmarks in memory are overwritten), synchronously (stop & wait), from tape drive 0, starting at memory location decimal 12, which, since the 1410 used *1*-based addressing, was the location just after the no-op at location 11 above. [Note that these are actual *machine* instructions, *not* "assember"!! Like the 1401, the 1410 was a *character* machine, not an 8-bit-byte binary machine. The bits in a character were named 1, 2, 4, 8, A, B, and W (wordmark). Oh, and C, but that was character parity -- the programmer couldn't set that separately.] What was the corresponding 1401 boot sequence? Oh, for the record, IMHO the DEC PDP-8 had a *much* simpler machine language and assembler than the IBM 1401/1410. ;-} -Rob - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: The Importance of Terminology's Quality
Martin Gregorie <[EMAIL PROTECTED]> wrote: +--- | I was fascinated, though by the designs of early assemblers: I first | learnt Elliott assembler, which required the op codes to be typed on | octal but used symbolic labels and variable names. Meanwhile a colleague | had started on a KDF6 which was the opposite - op codes were mnemonics | but all addresses were absolute and entered in octal. I always wondered | about the rationale of the KDF6 assembler writers in tackling only the | easy part of the job. +--- In the LGP-30, they used hex addresses, sort of[1], but the opcodes (all 16 of them) had single-letter mnemonics chosen so that the low 4 bits of the character codes *were* the correct nibble for the opcode! ;-} [Or you could type in the actual hex digits, since the low 4 bits of *their* character codes were also their corresponding binary nibble values... "but that would have been wrong".] -Rob [1] The LGP-30 character code was defined before the industry had yet standardized on a common "hex" character set, so instead of "0123456789abcdef" they used "0123456789fgjkqw". [The "fgjkqw" were some random characters on the Flexowriter keyboard whose low 4 bits just happened to be what we now call 0xa-0xf]. Even worse, the sector addresses of instructions were *not* right-justified in the machine word (off by one bit), plus because of the shift- register nature of the accumulator you lost the low bit of each machine word when you typed in instructions (or read them from tape), so the address values you used in coding went up by *4*! That is, machine locations were counted [*and* coded, in both absolute machine code & assembler] as "0", "4", "8", "j", "10", "14", "18", "1j" (pronounced "J-teen"!!), etc. - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: The Importance of Terminology's Quality
[EMAIL PROTECTED]> wrote:
+---
| [EMAIL PROTECTED] (Rob Warnock) wrote:
| >In the LGP-30, they used hex addresses, sort of[1], but the opcodes
| >(all 16 of them) had single-letter mnemonics chosen so that the
| >low 4 bits of the character codes *were* the correct nibble for
| >the opcode! ;-}
...
| >[1] The LGP-30 character code was defined before the industry had
| >yet standardized on a common "hex" character set, so instead of
| >"0123456789abcdef" they used "0123456789fgjkqw". [The "fgjkqw"
| >were some random characters on the Flexowriter keyboard whose low
| >4 bits just happened to be what we now call 0xa-0xf]. Even worse,
| >the sector addresses of instructions were *not* right-justified
| >in the machine word (off by one bit), plus because of the shift-
| >register nature of the accumulator you lost the low bit of each
| >machine word when you typed in instructions (or read them from
| >tape), so the address values you used in coding went up by *4*!
| >That is, machine locations were counted [*and* coded, in both
| >absolute machine code & assembler] as "0", "4", "8", "j", "10",
| >"14", "18", "1j" (pronounced "J-teen"!!), etc.
|
| Whats os interresting about all this hullabaloo is that nobody has
| coded machine code here, and know's squat about it.
+---
Think again! *BOTH* of the two examples I gave -- for the LGP-30 & the
IBM 1410 -- *WERE* raw machine code, *NOT* assembler!!! Please read again
what I wrote about the character codes for the instruction mnemonics
*BEING* the machine instruction codes. For the IBM 1410, the bootstrap
code that ones types in:
v v
L%B12$N
*IS* raw machine code, *NOT* assembler!! [See my previous post for
the meaning of the fields of that instruction.] The IBM 1410 is a
*character* machine, not a binary machine, so each memory location is
a (6+1 bit) character. As a result, one can [and *must*, during bootup!]
type absolute machine code directly into memory using the console
typewriter [an only-slightly-modified IBM Selectric, as it happens].
The fact that -- for the sake of user convenience -- the hardware
supports manual entry of machine code into memory by the operator
in a form that closely *resembles* assembler (but *ISN'T*!) was a
deliberate design feature.
Similarly, the characters you type for the LGP-30's opcodes *ARE* the
opcodes, at least by the time they get into the machine, since when
typing in code (or reading it from paper tape) one sets the I/O system
to "4-bit input mode", in which the upper bits of the characters are
stripped off by the I/O hardware during input. Thus when you type a
"Bring" (load) instruction such as this ["Bring" (load) location 0xd7c
(track 0xd, sector 0x31)]:
b0q7j
you're typing *RAW* machine code, *NOT* assembler!! You see, the
lower 4 bits of character "b" -- the "mnemonic" for "Bring" -- were
binary 0001, the *same* as the lower 4 bits of the digit "1" (and two
other characters as well). So when you typed a "b" in that position
in "4-bit input mode" you were typing the same thing as the character "1"
which was the same thing as *binary* 0001 which was the absolute machine
opcode for the ""Bring" instruction!! "No assembler required" (pardon
the pun).
+---
| I'm not talking assembly language.
+---
Neither was I. The fact that for the two machines I mentioned
absolute machine code was somewhat readable to humans seems to
have confused you, but that's the way some people liked to design
their hardware back in those days -- with clever punning of character
codes with absolute machine opcodes (for the convenience of the user).
+---
| Don't you know that there are routines that program machine code?
+---
What do you mean "routines"?!? For the above two machines, you can
enter machine code with *no* programs ("routines?") running; that is,
no boot ROM is required (or even available, as it happened).
+---
| Yes, burned in, bitwise encodings that enable machine instructions?
+---
The two machines mentioned above did not *HAVE* a "boot ROM"!!
You had to *manually* type raw, absolute machine code into
them by hand every time you wanted to boot them up [at least
a little bit, just enough to load a larger bootstrap program].
+---
| Nothing below that.
+---
You're assuming that all machines *have* some sort of "boot ROM".
Before the microprocessor days, that was certainly not always
the case. The "boot ROM", or other methods o
Re: The Importance of Terminology's Quality
Robert Maas, <[EMAIL PROTECTED]> wrote: +--- | > From: [EMAIL PROTECTED] (Rob Warnock) | > In the LGP-30, they used hex addresses, sort of[1], but the | > opcodes (all 16 of them) had single-letter mnemonics chosen so that | > the low 4 bits of the character codes *were* the correct nibble for | > the opcode! ;-} ... | By the way, do you remember exactly all the 16 opcodes, or have a | Web reference available? +--- There are quite a few out there; here's one: http://www.users.nwark.com/~rcmahq/jclark/lgp30.htm Some notes on the opcodes: - "Bring" (B) would be called "Load" in current parlance. - "Extract" (E) would be called "And" in current parlance. - "Unconditional Transfer" (U) would be called "Jump" or "Branch". - "Hold" (H) would be called "Store"; "Clear" (C) would be called "Store-and-Clear" (the "DCA" instruction of the DEC PDP-8). - There are two "Multiply" ops, "M" & "N", depending on whether the upper or lower bits (respectively) of the product are returned. - "Store Address" (Y) stores an address in the AC into the address field of the destination [yes, modifying the code in-place!! -- it was mostly used for indexing through arrays], whereas the "Return Address" (R) stores the current instruction address + 2 into the address field of the destination. The subroutine calling sequence is thus an "R/U" pair: R foo_last U foo where the FOO subroutine might be written as: foo: ... ... foo_last: U foo_last ; overwritten +--- | > The LGP-30 character code was defined before the industry had | > yet standardized on a common "hex" [sic, "hexadecimal", base 16 | > not base 6!!!] character set, ... | > they used "0123456789fgjkqw". | | That doesn't make sense. The low-order four bits of those letters | aren't consecutive ascending values from 9+1 to 9+6. Did you make a | typo, or did you explain something wrong? +--- No, what I wrote is correct. The low 4 bits of "0123456789fgjkqw" *are* 0 through 16 (or "0123456789abcdef" in current "hex")... IN THE *LGP-30 FLEXOWRITER* CHARACTER CODE, *not* in ASCII or EBCDIC or Baudot or any other standard code. Well, actually, it's a little more complex than that. The LGP-30 used a 6-bit "keyboard" code on the Flexowriter (and the paper tape reader & punch), but the machine could be put into either 6-bit or 4-bit input mode. In the latter, only the first four bits of each code got shifted into the accumulator. So I suppose you could say those were the *upper* 4 bits of each character, though when read into the accumulator in "4-bit input mode" they truly *were* the lower 4 bits. (Sorry for the confusion. It was an "interesting" machine.) +--- | (map 'list #'char-code "0123456789fgjkqw") | => (48 49 50 51 52 53 54 55 56 57 102 103 106 107 113 119) +--- That's ASCII. The LGP-30 did not use ASCII. The LGP-30 used Flexowriter keyboard code, see: http://ed-thelen.org/comp-hist/lgp-30-man-f002.gif -Rob p.s. The full programming manual for the LGP-30 can be found here: http://ed-thelen.org/comp-hist/lgp-30-man.html but good luck reading its archaic style. ;-} - Rob Warnock <[EMAIL PROTECTED]> 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: How to Write grep in Emacs Lisp (tutorial)
Harald Hanche-Olsen wrote:
+---
| [Icarus Sparry ]
| > The 'modern' way to do this is
| > find . -maxdepth 2 -name '*.html' -exec grep whatever {} +
|
| Actually, I think it should be
| find . -maxdepth 2 -name '*.html' -exec grep whatever /dev/null {} +
| because grep behaves differently when given only one filename as opposed
| to several.
+---
Yup. This is why it's also important to include that "/dev/null"
when using "find | xargs", too:
find . -maxdepth 2 -name '*.html' -print | xargs grep whatever /dev/null
Years & years ago, right after I learned about "xargs", I got burned
several times on "find | xargs grep pat" when the file list was long
enough that "xargs" fired up more than one "grep"... and the last
invocation was given only one arg!! IT FOUND THE PATTERN, BUT DIDN'T
TELL ME WHAT !@^%!$@#@! FILE IT WAS IN!! :-{
The trailing "/dev/null" fixes that. ;-}
-Rob
-
Rob Warnock
627 26th Avenue http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to Write grep in Emacs Lisp (tutorial)
Harald Hanche-Olsen wrote:
+---
| [Icarus Sparry ]
| > The 'modern' way to do this is
| > find . -maxdepth 2 -name '*.html' -exec grep whatever {} +
|
| Actually, I think it should be
| find . -maxdepth 2 -name '*.html' -exec grep whatever /dev/null {} + \;
| because grep behaves differently when given only one filename as opposed
| to several.
+---
Oh, wow! I just learned from this thread about the new (to me)
"{} +" option to "find"! That wasn't in "find" until relatively
recently, it seems. [At least, it wasn't in FreeBSD 4.6, though
it seems to be in FreeBSD 6.x and later...]
Thanks, guys!!
-Rob
-
Rob Warnock
627 26th Avenue http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
EXECUTIVE SUMMARY: 1 inch + 1 second = ~4.03e38 grams. GORY DETAILS: Tim Bradshaw wrote: +--- | Malcolm McLean said: | > he problem is that if you allow expressions rather than terms then | > the experssions can get arbitrarily complex. sqrt(1 inch + 1 Second), | > for instance. | | I can't imagine a context where 1 inch + 1 second would not be an | error, so this is a slightly odd example. Indeed I think that in | dimensional analysis summing (or comparing) things with different | dimensions is always an error. +--- Unless you convert them to equivalent units first. For example, in relativistic or cosmological physics, one often uses a units basis wherein (almost) everything is scaled to "1": http://en.wikipedia.org/wiki/Natural_units When you set c = 1, then: Einstein's equation E = mc2 can be rewritten in Planck units as E = m. This equation means "The rest-energy of a particle, measured in Planck units of energy, equals the rest-mass of a particle, measured in Planck units of mass." See also: http://en.wikipedia.org/wiki/Planck_units ... The constants that Planck units, by definition, normalize to 1 are the: * Gravitational constant, G; * Reduced Planck constant, h-bar; [h/(2*pi)] * Speed of light in a vacuum, c; * Coulomb constant, 1/(4*pi*epsilon_0) (sometimes k_e or k); * Boltzmann's constant, k_B (sometimes k). This sometimes leads people to do things that would appear sloppy or even flat-out wrong in MKS or CGS units, such as expressing mass in terms of length: Consider the equation A=1e10 in Planck units. If A represents a length, then the equation means A=1.6e-25 meters. If A represents a mass, then the equation means A=220 kilograms. ... In fact, natural units are especially useful when this ambiguity is *deliberate*: For example, in special relativity space and time are so closely related that it can be useful to not specify whether a variable represents a distance or a time. So it is that we find that the mass of the Sun is 1.48 km or 4.93 us, see: http://en.wikipedia.org/wiki/Solar_mass#Related_units In this limited sense, then, one could convert both 1 inch and 1 second to masses[1], and *then* add them, hence: 1 inch + 1 second = ~4.03e38 grams. ;-} ;-} -Rob [1] 1 inch is "only" ~3.41e28 g, whereas 1 second is ~4.03e38 g, so the latter completely dominates in the sum. - Rob Warnock 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
Martin Gregorie wrote: +--- | Lie Ryan wrote: | > Virtual Machine in Hardware... isn't that a contradiction? | | Nope. Several mainframes did that. | | Two that I knew well were both British - the ICL 1900 and 2900. | The Burroughs x700 series also used hardware virtualisation. +--- Circa 1965, the IBM 1410 did hardware emulation of the earlier IBM 1401. There was a front panel switch you could flip before you rebooted to set the mode. We needed it at Emory Univ. since the program that drove the Calcomp X-Y plotter only ean on the 1401. So we ran our Fortran programs in 1410 mode with output to a mag tape, then rebooted into 1401 mode to run the program that plotted the data on the tape, then rebooted back into 1410 mode for the next guy who needed the machine. -Rob ----- Rob Warnock 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
RG wrote: +--- | This reminds me of back when I was a kid and my dad was trying to teach | me basic physics. He kept saying that the acceleration of gravity was | 9.8 meters per second squared and I just couldn't wrap my brain around | what it meant to square a second. | | Now that I think about it, I still can't. :-) +--- Write it our longhand and it's easier to grok: 9.8 m/s^2 ==> 9.8 m/(s*s) ==> 9.8 m/(s*s) ==> (9.8 meters per second) per second. \ / \__ speed added __/ per second -Rob - Rob Warnock 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
RG wrote: +--- | [email protected] (Rob Warnock) wrote: | > Write it our longhand and it's easier to grok: | > 9.8 m/s^2 ==> 9.8 m/(s*s) ==> 9.8 m/(s*s) ==> | > (9.8 meters per second) per second. | > \ / | > \__ speed added __/ per second | | Oh, that part I get. It's the abstract squared second that's still a | deep mystery to me. +--- As far as I know, there is no "abstract squared second" anywhere, other than in formulae in which collecting the dimensions (as above) ends up having an exponent of "2". That is, acceleration really *is* "(distance / s) / s". It only gets to be "distance/(s^2)" when you collect terms. +--- | A squared length is easily visualized. But according to relativity | space and time are just two aspects of the same thing, so a squared | second should make some kind of physical sense. +--- Why should it?!? If you look way under the covers, I suspect that even the "c^2" in "E = mc^2" is a "collected" term in the above sense [that is, if I recall my classes in introductory special relativity correctly]. -Rob - Rob Warnock 627 26th Avenue http://rpw3.org/> San Mateo, CA 94403 (650)572-2607 -- http://mail.python.org/mailman/listinfo/python-list
