d by Ron Garret.
> > @http://www.youtube.com/watch?v=_gZK0tW8EhQ
>
> RG mentions giving a more technical version to a Lisp User Group. Any
> chance that this talk is publicly available?
Nope. It wasn't recorded. Sorry.
> Thanks for the talk, Ron, I really enjoyed it, and wish y
In article ,
r...@rpw3.org (Rob Warnock) wrote:
> 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 c
me dimensions.
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,
In article <8hl3grfh2...@mid.individual.net>,
Gregory Ewing wrote:
> RG wrote:
> > Even an interest
> > rate of 0.1 radians makes sense if for some unfathomable reason you want
> > to visualize your interest payment as the relative length of a line
> > segme
>
> The formula: circumference = 2 x pi x radius is taught
> in primary schools, yet it's actually a very difficult
> formula to prove!
What's to prove? That's the definition of pi.
rg
--
http://mail.python.org/mailman/listinfo/python-list
n arc.
> (I have also
> vague memories of a mathematical presentation of angles that clearly
> distinguished angles from numbers used to represent them).
That would be interesting. If you find a pointer please pass it along.
rg
--
http://mail.python.org/mailman/listinfo/python-list
In article ,
Keith Thompson wrote:
> "BartC" writes:
> > "RG" wrote in message
> > news:rnospamon-20651e.17410012102...@news.albasani.net...
> [...]
> >> Likewise, all of the following are the same number written in different
> >> not
In article ,
"BartC" wrote:
> "RG" wrote in message
> news:rnospamon-20651e.17410012102...@news.albasani.net...
> > In article ,
> > "BartC" wrote:
> >
> >> "Thomas A. Russ" wrote in message
>
> >> > B
27;t units either, any more than a percentage is a unit. They
are just different ways of writing numbers.
All of the following are the same number written in different notations:
0.5
1/2
50%
Likewise, all of the following are the same number written in different
notations:
pi/2
In article
<1a172248-8aab-42f0-a8a2-3f00168f9...@u13g2000vbo.googlegroups.com>,
Keith H Duggar wrote:
> On Sep 29, 9:01 pm, RG wrote:
> > That the problem is "elsewhere in the program" ought to be small
> > comfort. But very well, try this instead:
&g
In article ,
Seebs wrote:
> On 2010-10-01, RG wrote:
> > Again, you can't have it both ways. Either a warning is a "compiler
> > error" according to the claim at issue (see below) or it is not. If it
> > is, then this is a false positive.
>
>
In article ,
Seebs wrote:
> On 2010-09-30, RG wrote:
> > That gives (what I would consider to be) false positives, e.g.:
>
> > [...@mighty:~]$ cat foo.c
>
> > void foo(long x) {}
>
> > int main() { foo(1); }
> > [...@mighty:~]$ gcc -Wconve
In article <87tyl63cag@mail.geddis.org>,
Don Geddis wrote:
> Keith Thompson wrote on Thu, 30 Sep 2010:
> > RG writes:
> >> You're missing a lot of context. I'm not trying to criticize C, just to
> >> refute a false claim that was made about
In article ,
Keith Thompson wrote:
> RG writes:
> > In article ,
> > Seebs wrote:
> >
> >> On 2010-09-30, Lie Ryan wrote:
> >> > On 09/30/10 16:09, TheFlyingDutchman wrote:
> >> >> Dynamic typed languages like Python fail in this
In article ,
Seebs wrote:
> On 2010-09-30, RG wrote:
> > In article ,
> > Seebs wrote:
> >> And that's the magic of static typing: It is not a false positive to
> >> warn you that "2L" is not of type int.
>
> > We'll have
In article
<0390e2b4-fa28-49b3-a867-39be6d668...@w19g2000yqb.googlegroups.com>,
ImpalerCore wrote:
> On Sep 29, 9:01 pm, RG wrote:
>
>
>
> > [...@mighty:~]$ cat foo.c
> > #include
> >
> > int maximum(int a, int b) { return a > b ? a : b; }
&
In article <7xr5gbxfry@ruckus.brouhaha.com>,
Paul Rubin wrote:
> RG writes:
> > Yes, I know I could have used lint. But that misses the point. For any
> > static analyzer, because of the halting problem, I can construct a
> > program that either contains an e
In article ,
Seebs wrote:
> And that's the magic of static typing: It is not a false positive to
> warn you that "2L" is not of type int.
We'll have to agree to disagree about that. The numerical value 2 can
safely be represented as an int, so I would consider t
to that will be that because of the halting
problem, for any static analyzer that you present, I can construct a
program that either contains an error that either your analyzer will not
catch, or for which it will generate a false positive. It just so
happens that constructing such examples for standard C is very easy.
rg
--
http://mail.python.org/mailman/listinfo/python-list
In article ,
Seebs wrote:
> On 2010-09-30, RG wrote:
> > You can't have it both ways. Either I am calling it incorrectly, in
> > which case I should get a compiler error,
>
> You get a warning if you ask for it. If you choose to run without all
> the type che
In article ,
Keith Thompson wrote:
> RG writes:
> [...]
> > You can't have it both ways. Either I am calling it incorrectly, in
> > which case I should get a compiler error, or I am calling it correctly,
> > and I should get the right answer. That I got neit
't have it both ways. Either I am calling it incorrectly, in
which case I should get a compiler error, or I am calling it correctly,
and I should get the right answer. That I got neither does in fact
falsify the claim. The only way out of this is to say that
maximum(8589934592, 1) returning 1 is in fact "correct", in which case
we'll just have to agree to disagree.
rg
--
http://mail.python.org/mailman/listinfo/python-list
In article ,
Seebs wrote:
> On 2010-09-30, RG wrote:
> > Of course. Computers always do only exactly what you ask of them. On
> > this view there is, by definition, no such thing as a bug, only
> > specifications that don't correspond to one's intentions.
(Though C does make it notoriously easy to sneak buggy code
> past the compiler.)
Let's just leave it at that then.
rg
--
http://mail.python.org/mailman/listinfo/python-list
In article ,
Keith Thompson wrote:
> RG writes:
> [...]
> > That the problem is "elsewhere in the program" ought to be small
> > comfort.
>
> I don't claim that it's comforting, merely that it's true.
>
> > But very
In article ,
Keith Thompson wrote:
> RG writes:
> > In article ,
> > Keith Thompson wrote:
> >
> >> RG writes:
> >> > In article
> >> > <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
>
In article ,
Keith Thompson wrote:
> RG writes:
> > In article
> > <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
> > Squeamizh wrote:
> >> On Sep 29, 3:02 pm, RG wrote:
> [...]
> >> > This is a red h
In article
<07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
Squeamizh wrote:
> On Sep 29, 3:02 pm, RG wrote:
> > In article
> > <996bd4e6-37ff-4a55-8db5-6e7574fbd...@k22g2000prb.googlegroups.com>,
> >
> >
> >
> >
&
@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
> > > > RG writes:
> > > > > In article
> > > > > <7df0eb06-9be1-4c9c-8057-e9fdb7f0b...@q16g2000prf.googlegroups.com>,
> > > > > TheFlyingDutchman wrote:
> >
>
tdout. That fails,
> and it silently ignores the error.
>
> FWIW, this is fixed in Python 3.
Guess it's time to upgrade. :-)
Thanks!
rg
--
http://mail.python.org/mailman/listinfo/python-list
Everything still works
print s2
%%% /&%%%
sys.ps1 = s1 # If we reset sys.ps1 we get our prompt back
%%% %%% sys.ps1 = '>>> '
>>> sys.ps1 = u'>>> '
>>>
So... why does having a non-ascii character in sys.ps1 make the prompt
vani
In article ,
Benjamin Kaplan wrote:
> On Wed, Aug 11, 2010 at 6:21 PM, RG wrote:
> > I thought it was hard-coded into the Python executable at compile time,
> > but that is apparently not the case:
> >
> > [...@mickey:~]$ python
> > Python 2.6.1 (r261:67515
eractive device.
>
> POSIX says essentially the same thing:
>
> <http://www.opengroup.org/onlinepubs/9699919799/functions/stdin.html>
This doesn't explain why "cat | cat" when run interactively outputs
line-by-line (which it does). STDIN to the first cat is a T
works fine when Python runs interactively. So how can I make this
work?
Thanks,
rg
--
http://mail.python.org/mailman/listinfo/python-list
In article ,
RG wrote:
> In article ,
> Tim Harig wrote:
>
> > On 2010-08-11, RG wrote:
> > > In article ,
> > > Tim Harig wrote:
> > >
> > >> On 2010-08-11, RG wrote:
> > >> > I'm writing a system in a differe
In article ,
Tim Harig wrote:
> On 2010-08-11, RG wrote:
> > In article ,
> > Tim Harig wrote:
> >
> >> On 2010-08-11, RG wrote:
> >> > I'm writing a system in a different language but want to use a Python
> >> > library. I
In article ,
Tim Harig wrote:
> On 2010-08-11, RG wrote:
> > I'm writing a system in a different language but want to use a Python
> > library. I know of lots of ways to do this (embed a Python interpreter,
> > fire up a python server) but by far the easiest to imp
In article ,
Peter Otten <__pete...@web.de> wrote:
> Grant Edwards wrote:
>
> > On 2010-08-11, Tim Harig wrote:
> >> On 2010-08-11, RG wrote:
> >>> When stdin is not a tty, Python seems to buffer all the input through
> >>> EOF before pr
In article ,
Cameron Simpson wrote:
> On 11Aug2010 00:11, RG wrote:
> | When stdin is not a tty, Python seems to buffer all the input through
> | EOF before processing any of it:
> |
> | [...@mickey:~]$ cat | python
> | print 123
> | print 456
> | 123
> | 456
>
,
rg
--
http://mail.python.org/mailman/listinfo/python-list
40 matches
Mail list logo
