Re: Python Front-end to GCC
On Sunday, 20 October 2013 10:56:46 UTC-7, Philip Herron wrote: > Hey, > > > > I've been working on GCCPY since roughly november 2009 at least in its > > concept. It was announced as a Gsoc 2010 project and also a Gsoc 2011 > > project. I was mentored by Ian Taylor who has been an extremely big > > influence on my software development carrer. > > > > Gccpy is an Ahead of time implementation of Python ontop of GCC. So it > > works as you would expect with a traditional compiler such as GCC to > > compile C code. Or G++ to compile C++ etc. > > > > Whats interesting and deserves a significant mention is my work is > > heavily inspired by Paul Biggar's phd thesis on optimizing dynamic > > languages and his work on PHC a ahead of time php compiler. I've had > > so many ups and down in this project and i need to thank Andi Hellmund > > for his contributions to the project. > > http://paulbiggar.com/research/#phd-dissertation > > > > The project has taken so many years as an in my spare time project to > > get to this point. I for example its taken me so long simply to > > understand a stabilise the core fundamentals for the compiler and how > > it could all work. > > > > The release can be found here. I will probably rename the tag to the > > milestone (lucy) later on. > > https://github.com/redbrain/gccpy/releases/tag/v0.1-24 > > (Lucy is our dog btw, German Shepard (6 years young) loves to lick > > your face off :) ) > > > > Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd. > > (Although this is sparse partialy on purpose since i do not wan't > > people thinking this is by any means ready to compile real python > > applications) > > > > I've found some good success with this project in compiling python > > though its largely unknown to the world simply because i am nervous of > > the compiler and more specifically the python compiler world. > > > > But at least to me there is at least to me an un-answered question in > > current compiler implementations. AOT vs Jit. > > > > Is a jit implementation of a language (not just python) better than > > traditional ahead of time compilation. > > > > What i can say is ahead of time at least strips out the crap needed > > for the users code to be run. As in people are forgetting the basics > > of how a computer works in my opinion when it comes to making code run > > faster. Simply need to reduce the number of instructions that need to > > be executed in order to preform what needs to be done. Its not about > > Jit and bla bla keyword llvm keyword instruction scheduling keyword > > bla. > > > > I could go into the arguments but i feel i should let the project > > speak for itself its very immature so you really cant compare it to > > anything like it but it does compile little bits and bobs fairly well > > but there is much more work needed. > > > > There is nothing at steak, its simply an idea provoked from a great > > phd thesis and i want to see how it would work out. I don't get funded > > of paid. I love working on compilers and languages but i don't have a > > day job doing it so its my little pet to open source i believe its at > > least worth some research. > > > > I would really like to hear the feedback good and bad. I can't > > describe how much work i've put into this and how much persistence > > I've had to have in light of recent reddit threads talking about my > > project. > > > > I have so many people to thank to get to this point! Namely Ian > > Taylor, Paul Biggar, Andi Hellmund, Cyril Roelandt Robert Bradshaw, > > PyBelfast, and the Linux Outlaws community. I really couldn't have got > > to this point in my life without the help of these people! > > > > Thanks! > > > > --Phil -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
In article ,
Chris Kaynor wrote:
>-=-=-=-=-=-
>Global:
>
>int arr[10];
>int main()
>{
> int i;
> for (i = 0; i < 10; i++) {
>printf("arr[%d] = %d\n", i, arr[i]);
>}
>printf("\n");
>return 0;
>}
>
>As for a reference:
>http://stackoverflow.com/questions/1831290/static-variable-initialization
> and
>http://stackoverflow.com/questions/3373108/why-are-static-variables-auto-initialized-to-zero,
>both of which then reference the C++ standard.
Or even better:
#include
int arr[] = {1,2,3,4,5,6,7,8};
int main()
{
int i;
for (i = 0; i < sizeof(arr)/sizeof(int); i++) {
printf("arr[%d] = %d\n", i, arr[i]);
}
printf("\n");
return 0;
}
Output:
"
albert@cherry:/tmp$ a.out
arr[0] = 1
arr[1] = 2
arr[2] = 3
arr[3] = 4
arr[4] = 5
arr[5] = 6
arr[6] = 7
arr[7] = 8
"
This is the output of
objdump -x a.out (after stripping)
"
a.out: file format elf64-x86-64
a.out
architecture: i386:x86-64, flags 0x0112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00400450
Lots of segments.
23 .got.plt 0030 00600900 00600900 0900 2**3
CONTENTS, ALLOC, LOAD, DATA
24 .data 0040 00600940 00600940 0940 2**5
CONTENTS, ALLOC, LOAD, DATA
25 .bss 0010 00600980 00600980 0980 2**3
ALLOC
26 .comment 001c 0980 2**0
CONTENTS, READONLY
SYMBOL TABLE:
no symbols
"
Look at .data It is CONTENTS LOAD DATA, i.e. it has content
in the executable binary and this is loaded as such into memory
at startup.
You can also ask to dump the content of the sections:
objdump -s a.out
a.out: file format elf64-x86-64
...
Contents of section .data:
600940
600950
600960 0100 0200 0300 0400
600970 0500 0600 0700 0800
Contents of section .comment:
4743433a 20284465 6269616e 20342e34 GCC: (Debian 4.4
0010 2e352d38 2920342e 342e3500 .5-8) 4.4.5.
>
>
>>
>> --
>> Steven
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>-=-=-=-=-=-
>[Alternative: text/html]
>-=-=-=-=-=-
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
--
https://mail.python.org/mailman/listinfo/python-list
[OT] Re: Python Front-end to GCC
Steven D'Aprano pearwood.info> writes: > > On Fri, 25 Oct 2013 21:36:42 +0100, Mark Lawrence wrote: > > > Mind you, the thought of a bot with a Ph.D. is mind boggling. > > You can buy degrees on the Internet quite cheaply: > > http://en.wikipedia.org/wiki/List_of_animals_with_fraudulent_diplomas > > PhD's are more expensive, which leads me to think that Mark Jenssen is > being a tad flexible with the truth when he claims to have one. He could be an upper-class twit. He would certainly have his chance in the yearly competition ;-) Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-28, Chris Angelico wrote: > On Tue, Oct 29, 2013 at 1:21 AM, Grant Edwards > wrote: >> On 2013-10-26, Mark Lawrence wrote: >>> On 26/10/2013 22:25, Mark Janssen wrote: >>> >>> Please give it a rest Mark, nobody is falling for your pseudo >>> babel. >> >> I think you do him a disservice. I'm pretty sure it's genuine, >> bona-fide, 24K, dyed-in-the-wool, 99 and 44/100 pure babble. > > I think it's even better than that... maybe even 28.8K! >From my own bailiwick I'd say it's Grade A Medium Amber. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Tue, Oct 29, 2013 at 1:21 AM, Grant Edwards wrote: > On 2013-10-26, Mark Lawrence wrote: >> On 26/10/2013 22:25, Mark Janssen wrote: >> >> Please give it a rest Mark, nobody is falling for your pseudo babel. > > I think you do him a disservice. I'm pretty sure it's genuine, > bona-fide, 24K, dyed-in-the-wool, 99 and 44/100 pure babble. I think it's even better than that... maybe even 28.8K! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-26, Mark Lawrence wrote: > On 26/10/2013 22:25, Mark Janssen wrote: > > Please give it a rest Mark, nobody is falling for your pseudo babel. I think you do him a disservice. I'm pretty sure it's genuine, bona-fide, 24K, dyed-in-the-wool, 99 and 44/100 pure babble. -- Grant Edwards grant.b.edwardsYow! I have many CHARTS at and DIAGRAMS.. gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Monday, October 28, 2013 3:44:14 AM UTC+5:30, zipher wrote: > Otherwise, most of this, while sloppy, still stands. Yes All your quotes are unattributed So your discussion is both sloppy and meaningless -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
> I see the big man stepping in to answer for his homies After re-reading the discussion, I wish to retract what I'm saying here and apologize to John who seems like a decent guy. >, but while his > explanation satisfies their question of "well why do these magic > values get used then, if what Mark says is true?", it doesn't address > the real confusion: What is the difference between "script" code > (like Javascript and visual) made for the screen (where such magic > values are utilized) and compiled source (made for the machine)? And > that is where John, while benevolent, hasn't done the homework of > computer science. Ask him. Otherwise, most of this, while sloppy, still stands. Mark Janssen Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
> What a mess of a discussion. I see the big man stepping in to answer for his homies, but while his explanation satisfies their question of "well why do these magic values get used then, if what Mark says is true?", it doesn't address the real confusion: What is the difference between "script" code (like Javascript and visual) made for the screen (where such magic values are utilized) and compiled source (made for the machine)? And that is where John, while benevolent, hasn't done the homework of computer science. Ask him. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 26/10/2013 22:25, Mark Janssen wrote: Please give it a rest Mark, nobody is falling for your pseudo babel. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 26/10/2013 22:33, Mark Janssen wrote: Apologies will be accepted on the list. BTW, I can't resist pointing out that you guys are like a cup already full of (black) coffee -- too full to allow the pure water of clarity to enter. (cf. Buddhism) .. (boom) MarkJanssen Tacoma, Washington I took a look at your sourceforge page yesterday. I found it extremely sad that you'd clearly taken so many contaminated batches over so many years. Seriously. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 10/25/2013 12:18 PM, Mark Janssen wrote: >> As for the hex value for Nan who really gives a toss? The whole point is >> that you initialise to something that you do not expect to see. Do you not >> have a text book that explains this concept? > > No, I don't think there is a textbook that explains such a concept of > initializing memory to anything but 0 -- UNLESS you're from Stupid > University. > > Thanks for providing fodder... > > Mark Janssen, Ph.D. > Tacoma, WA What a mess of a discussion. First off, this is mostly a C/C++ issue, not a Python issue, because Python generally doesn't let you see uninitialized memory. Second, filling newly allocated memory with an illegal value is a classic debugging technique. Visual C/C++ uses it when you build in debug mode. Wikipedia has an explanation: http://en.wikipedia.org/wiki/Magic_number_%28programming%29#Magic_debug_values Microsoft Visual C++ uses 0xBAADF00D. In valgrind, there's a "-malloc-fill" option, and you can specify a hex value. There's a performance penalty for filling large areas of memory so it's usually done in debug mode only, and is sometimes causes programs with bugs to behave differently when built in debug vs. release mode. Sigh. John Nagle -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
> Apologies will be accepted on the list. BTW, I can't resist pointing out that you guys are like a cup already full of (black) coffee -- too full to allow the pure water of clarity to enter. (cf. Buddhism) .. (boom) MarkJanssen Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
[Getting back to some old comments]
>>> A language specification in BNF is just syntax. It doesn't say anything
>>> about semantics. So how could this be used to produce executable C code
>>> for a program? BNF is used to produce parsers. But a parser isn't
>>> sufficient.
>>
>> A C program is just syntax also. How does the compiler generate
>> executable machine code? Extrapolate into a Python front-end to C.
>
> Did you even read the paragraph you quoted above? The BNF specification
> does NOT completely describe a language, it only defines its syntax.
Computer Science 301 (a.k.a. "educating the python brogrammers who've
been too long using interpreted languages"):
C source ("blah.c") is broken down into a linear sequence of tokens
fed into a parser. The BNF definition for C takes those tokens/syntax
and produces a lexical graph of the source -- its grammatical form.
This becomes an abstract syntax *tree* because there is a "main"
function (without which I don't believe you can call a language
formally "Turing Complete" because one doesn't know where to begin to
feed the machine (wait for it boom)). In any case, this *roots*
the abstract lexical graph and forms the basis for compiling into
machine code.
> So
> if the only thing you knew about C was its BNF, you could certainly not
> write a C compiler. And neither could anyone else.
Well, now you're confusing everybody, because you're asking, in
essence: "what is the meaning of a symbol to a computer?", and since
there isn't one, then you should wonder: "how are you going to get it
to 'do the right thing?'" For that, you'll have to take Mark
Janssen's PHIL 444: "Epistemics of Quantity" (not offered from the
internet).
Now, please give credit to all the old-timers who paved the way for
all you to be partying in the easy-land of high-level languages like
Python. It's them who made the computer SCIENCE. You guys have been
so spoiled, you're taking it all for granted and confusing people with
all your claptrap about TYPES. The insane cannot tell that they're
insane. Remember that.
> Fortunately for the
> C community, the language specification included much more than a BNF
> grammar. At a minimum, you have to specify both the syntax and the
> semantics.
I will look forward to how you will give a semantic specification for
the C token "{": left bracket.
Apologies will be accepted on the list.
Mark J
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Fri, 25 Oct 2013 21:36:42 +0100, Mark Lawrence wrote: > Mind you, the thought of a bot with a Ph.D. is mind boggling. You can buy degrees on the Internet quite cheaply: http://en.wikipedia.org/wiki/List_of_animals_with_fraudulent_diplomas PhD's are more expensive, which leads me to think that Mark Jenssen is being a tad flexible with the truth when he claims to have one. He certainly hasn't *earned* a PhD in computer science, that is obvious from his posts. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Sat, Oct 26, 2013 at 8:37 AM, Mark Janssen wrote: > On Fri, Oct 25, 2013 at 2:07 PM, Ned Batchelder > wrote: >> (Offlist) You responded on-list to a private email that was even tagged as off-list. Please be more careful and courteous. Anyway, IEEE floating-point makes it pretty clear that any value that sets the exponent to all-ones and the mantissa to anything other than all-zeros is a NaN. So an all-ones hex pattern (0x) will flood the area with NaNs. You really don't understand IEEE 754 here. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Friday 2013 October 25 14:11, Mark Lawrence wrote: > Will you please do yourself a favour and get a new dealer before you do > some real damage, the batch you're currently on is definitely contaminated. Meet Mark Janssen: http://sourceforge.net/apps/mediawiki/pangaia/index.php?title=User:Average -- Yonder nor sorghum stenches shut ladle gulls stopper torque wet strainers. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 25/10/2013 22:37, Mark Janssen wrote: I'm still waiting on the binary-digit lexer, Ned. The whole Python world is still waiting on your response to this http://code.activestate.com/lists/python-ideas/19908/. You were asked three times originally to respond. I've referenced this twice yet you have conveniently ignored all five requests and will presumably ignore this. What's the problem, cat got your typing fingers? Or don't you have the guts to admit that you were talking bollocks? -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Fri, Oct 25, 2013 at 2:07 PM, Ned Batchelder wrote: > (Offlist) > > Mark, these conversations would go much more smoothly if you would make > direct statements about technical points. Your messages are usually > insinuating questions, or personal insults. Yes, thank you. That is correct. > For example, you said: > > Please give me the hex value for NaN so I can initialize with my array. > > I think what you meant by this was: "I don't think there is a hex value that > represents NaN." Why not say that? Why? Because I know there's not a hex value for NaN, otherwise it would confuse the abstraction of what a computer is. Any hex digit you could attempt to obscure would be translatable as a number, and therefore a contradiction. Is that a good enough reason for ya? > Then we could talk about your claim. How about we talk about my claim with facts instead of attempts at creating reality a la NovusOrdoSeclorum? > You could even go so far as to admit that others might know things you > don't, and ask, "is there a hex value that represents NaN, I didn't realize > there was?" How sweet. Do you like makeup? > We could have a discussion about the concepts involved. As it is, the > threads devolve into name calling, topic-changing non-sequiturs, and silly > sound effects. You seem to start with the assumption that you are right and > everyone else is wrong, and begin with snark. I'm still waiting on the binary-digit lexer, Ned. > There really are people on the list who know a lot about software and > computer science, including the people you are currently calling > known-nothings. I don't know if you are personally qualified for the latter, but agree somewhat on the part of "software". > These things are true: There are hex values that represent NaNs. Why don't you follow your own advice? Instead of "These things are true:" Why don't you say "These things could be true" OR "*I* believe that hex values could be used to represent NaN"? Tell us, which hex value is used to represent NaN? (thoughts to self: all-ones wouldn't make a very good magic number for finding errors, so I wonder what Ned will dream up (btw: I'm not gay)). Note that, just for the record, I was talking strictly about memory (RAM), not variable assignments. > Non-Turing-complete languages can be compiled to C. ASTs don't have enough > information to compile to machine code. Please tell us then, what IS enough information to compile to machine code? ...rather than just saying that "AST's don't have enough information to compile to machine code" > Data on punched cards can be > tokenized. All of these things are true. *rolls eyes* > You seem to be a seeker of truth. Why not listen to others? Yes, now listening -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 25/10/2013 22:02, Mark Janssen wrote: But OTOH, it can also be explained away entirely by (as you previously noted) the Dunning-Kruger effect, with the same uninformed responses trotted out to everything. It was rusi who first mentioned this, I merely replied in my normal dead pan way. Slight aside, I spelt your surname incorrectly a few minutes ago whilst replying elsewhere, I do apologise. What is this? The circle-jerk list? I make some points on the last couple of threads and you all get bent-out of shape, then gather around each other as if you're all in a cancer ward Will you please do yourself a favour and get a new dealer before you do some real damage, the batch you're currently on is definitely contaminated. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
>> But OTOH, it can also be explained away entirely by (as you previously >> noted) the Dunning-Kruger effect, with the same uninformed responses >> trotted out to everything. > > It was rusi who first mentioned this, I merely replied in my normal dead pan > way. > > Slight aside, I spelt your surname incorrectly a few minutes ago whilst > replying elsewhere, I do apologise. What is this? The circle-jerk list? I make some points on the last couple of threads and you all get bent-out of shape, then gather around each other as if you're all in a cancer ward -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 25/10/2013 21:48, Tim Delaney wrote: But OTOH, it can also be explained away entirely by (as you previously noted) the Dunning-Kruger effect, with the same uninformed responses trotted out to everything. It was rusi who first mentioned this, I merely replied in my normal dead pan way. Slight aside, I spelt your surname incorrectly a few minutes ago whilst replying elsewhere, I do apologise. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 26 October 2013 07:36, Mark Lawrence wrote: > I can't see it being a bot on the grounds that a bot wouldn't be smart > enough to snip a URL that referred to itself as a quack. > My thought based on some of the responses is that they seem auto-generated, then tweaked - so not a bot per-se, but verging on it. But OTOH, it can also be explained away entirely by (as you previously noted) the Dunning-Kruger effect, with the same uninformed responses trotted out to everything. Not necessarily a troll as I injudiciously claimed in my previous post (I'd just woken up after 4 hours sleep - my apologies to the list). Anyway, not going to get sucked into this bottomless hole. Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 25/10/2013 21:29, Mark Janssen wrote: We've been discussing *DEBUGGING*. Are you making it LOUD and *clear* that you don't know what you're talking about? Input: Yes/no no Now please explain what you do not understand about the data below that's been written by Oscar Benjamin, myself and Ned Batchelder, specifically the use of the word *DEBUGGING*. Is this a word that does not appear in your text books? Yes. And how do I explain what I do NOT understand? If that is in fact the case would you like one of the experienced practical programmers on this list to explain it to you? N/A Have you ever bothered to read "The Zen of Python", specifically the bit about "Practicality beats purity"? Yes, I have. And if you have read that, you know that preceding that is the rule "Special cases aren't enough to break the rules." You sir, have broken the rules, you should not be preaching "practicality" if you don't know the rules. Now take your choir boys there and sit down. Mark P.S. In his book "Writing Solid Code" Steve Maguire states that he initialises with 0xA3 for Macintosh programs, and that Microsoft uses 0xCC, for exactly the reasons that you describe above. I will be glad to discuss all these arcane measures, when you aren't all being asswipes. It's a useful debugging technique to initialize memory to distinctive values that should never occur in real data. As I said, you're going something wrong. Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer When you're ready to make Python the best programming language in the world, re-engage. Please show rather less arrogance. Or are you upset at me as I've reminded you and told everybody else that you've been referred to on a Python list as a quack? I do admit that in your case I find quack very suitable, it has a ring to it that far outweighs troll, which Tim Delany has used fairly recently. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 25/10/2013 21:11, Tim Delaney wrote: On 26 October 2013 06:18, Mark Janssen mailto:dreamingforw...@gmail.com>> wrote: > As for the hex value for Nan who really gives a toss? The whole point is > that you initialise to something that you do not expect to see. Do you not > have a text book that explains this concept? No, I don't think there is a textbook that explains such a concept of initializing memory to anything but 0 -- UNLESS you're from Stupid University. Thanks for providing fodder... I know I'm replying to a someone who has trolled many threads over multiple years ... or as I'm now starting to suspect, possibly a bot, but I'll give him (it?) this one chance to show the capability to read and learn. http://en.wikipedia.org/wiki/Hexspeak Search for 0xBAADF00D; 0xBADDCAFE; and (in particular) OxDEADBEEF. These are historical examples of this technique used by major companies. Tim Delaney I can't see it being a bot on the grounds that a bot wouldn't be smart enough to snip a URL that referred to itself as a quack. Mind you, the thought of a bot with a Ph.D. is mind boggling. Must have been an absolutely amazing sheep dip to have graduated from, but the Bruces were incredible professors :) Thanks for the link by the way. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 26 October 2013 06:18, Mark Janssen wrote: > > As for the hex value for Nan who really gives a toss? The whole point is > > that you initialise to something that you do not expect to see. Do you > not > > have a text book that explains this concept? > > No, I don't think there is a textbook that explains such a concept of > initializing memory to anything but 0 -- UNLESS you're from Stupid > University. > > Thanks for providing fodder... > I know I'm replying to a someone who has trolled many threads over multiple years ... or as I'm now starting to suspect, possibly a bot, but I'll give him (it?) this one chance to show the capability to read and learn. http://en.wikipedia.org/wiki/Hexspeak Search for 0xBAADF00D; 0xBADDCAFE; and (in particular) OxDEADBEEF. These are historical examples of this technique used by major companies. Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
>>> We've been discussing *DEBUGGING*. >> >> Are you making it LOUD and *clear* that you don't know what you're >> talking about? > > Input: Yes/no > > no > > Now please explain what you do not understand about the data below that's > been written by Oscar Benjamin, myself and Ned Batchelder, specifically the > use of the word *DEBUGGING*. Is this a word that does not appear in your > text books? Yes. And how do I explain what I do NOT understand? > If that is in fact the case would you like one of the > experienced practical programmers on this list to explain it to you? N/A > Have > you ever bothered to read "The Zen of Python", specifically the bit about > "Practicality beats purity"? Yes, I have. And if you have read that, you know that preceding that is the rule "Special cases aren't enough to break the rules." You sir, have broken the rules, you should not be preaching "practicality" if you don't know the rules. Now take your choir boys there and sit down. Mark P.S. >> In his book "Writing Solid Code" Steve Maguire states that he >> initialises with 0xA3 for Macintosh programs, and that Microsoft uses >> 0xCC, for exactly the reasons that you describe above. I will be glad to discuss all these arcane measures, when you aren't all being asswipes. >> It's a useful debugging technique to initialize memory to distinctive >> values that should never occur in real data. As I said, you're going something wrong. > Python is the second best programming language in the world. > But the best has yet to be invented. Christian Tismer When you're ready to make Python the best programming language in the world, re-engage. -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
>>> As for the hex value for Nan who really gives a toss? The whole point is >>> that you initialise to something that you do not expect to see. Do you >>> not have a text book that explains this concept? >> >> No, I don't think there is a textbook that explains such a concept of >> initializing memory to anything but 0 -- UNLESS you're from Stupid >> University. >> >> Thanks for providing fodder... > > We've been discussing *DEBUGGING*. Are you making it LOUD and *clear* that you don't know what you're talking about? Input: Yes/no MarkJanssen -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 25/10/2013 20:18, Mark Janssen wrote: As for the hex value for Nan who really gives a toss? The whole point is that you initialise to something that you do not expect to see. Do you not have a text book that explains this concept? No, I don't think there is a textbook that explains such a concept of initializing memory to anything but 0 -- UNLESS you're from Stupid University. Thanks for providing fodder... Mark Janssen, Ph.D. Tacoma, WA We've been discussing *DEBUGGING*. If you can't be bothered to read what's written please do not respond. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Saturday, October 26, 2013 12:39:09 AM UTC+5:30, zipher wrote: > On Fri, Oct 25, 2013 at 11:59 AM, rusi wrote: > > > > I dont see how thats any more relevant than: > > Whats the hex value of the add instruction? > > > You "don't see". That is correct. Btw, I believe the hex value for > the add instruction on the (8-bit) Intel 8088 is x0. Now what were > you saying? There are a dozen different (hex values) for the add instruction -- depending on operand sizes/directions/immediate-operand/special-registers etc. So just as there is one add instruction with many hex values there is one nan as a concept with many different hex values. Are you arguing for the sake of arguing? If so lets at least agree on what you are arguing about!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
> As for the hex value for Nan who really gives a toss? The whole point is > that you initialise to something that you do not expect to see. Do you not > have a text book that explains this concept? No, I don't think there is a textbook that explains such a concept of initializing memory to anything but 0 -- UNLESS you're from Stupid University. Thanks for providing fodder... Mark Janssen, Ph.D. Tacoma, WA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-25, Mark Janssen wrote: > OTOH why in particular would you want to initialise them with zeros? I > often initialise arrays to nan which is useful for debugging. >>> >>> Is this some kind of joke? What has this list become? >> >> It's a useful debugging technique to initialize memory to distinctive >> values that should never occur in real data. > > If you're doing this, you're doing something wrong. Pardon me if I don't take your word for it. > Please give me the hex value for NaN so I can initialize with my > array. Seriously? You haven't discovered google and wikepedia yet? http://www.google.com/ http://en.wikipedia.org/ Assuming you're using IEEE-754, all 1's is a quiet NaN: http://en.wikipedia.org/wiki/IEEE_floating_point http://en.wikipedia.org/wiki/NaN If you want a signaling NaN you've got to change one of the bits (see the above links). IIRC, the Pascal language required that using unintialized variables caused an error. intializing FP values to a signalling NaN is a very convenient way to do that. -- Grant Edwards grant.b.edwardsYow! I'm also against at BODY-SURFING!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Fri, Oct 25, 2013 at 11:59 AM, rusi wrote: > On Saturday, October 26, 2013 12:15:43 AM UTC+5:30, zipher wrote: >> Clearly the python list has been taken over by TheKooks. Notice he >> did not respond to the request. Since we are talking about digital >> computers (with digital memory), I'm really curious what the hex value >> for NaN is to initialize my arrays > > I dont see how thats any more relevant than: > Whats the hex value of the add instruction? You "don't see". That is correct. Btw, I believe the hex value for the add instruction on the (8-bit) Intel 8088 is x0. Now what were you saying? -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 25/10/2013 19:45, Mark Janssen wrote: OTOH why in particular would you want to initialise them with zeros? I often initialise arrays to nan which is useful for debugging. Is this some kind of joke? What has this list become? It's a useful debugging technique to initialize memory to distinctive values that should never occur in real data. If you're doing this, you're doing something wrong. Please give me the hex value for NaN so I can initialize with my array. It is clear that you know as much about debugging as you do about objects and message passing [...] can see why the BDFL described you as an embarrassment, and if he didn't, he certainly should have done. Clearly the python list has been taken over by TheKooks. Notice he did not respond to the request. Since we are talking about digital computers (with digital memory), I'm really curious what the hex value for NaN is to initialize my arrays All hail chairman Meow. Dismissed. Reinstating http://code.activestate.com/lists/python-ideas/19908/ where you're described as a quack, which I assume in this context makes you an expert on duck typing, which should obviously be abbreviated to ducking. As for the hex value for Nan who really gives a toss? The whole point is that you initialise to something that you do not expect to see. Do you not have a text book that explains this concept? -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Saturday, October 26, 2013 12:15:43 AM UTC+5:30, zipher wrote: > Clearly the python list has been taken over by TheKooks. Notice he > did not respond to the request. Since we are talking about digital > computers (with digital memory), I'm really curious what the hex value > for NaN is to initialize my arrays I dont see how thats any more relevant than: Whats the hex value of the add instruction? Presumably floating point numbers are used for FP operations FP operations barf on nans So a mis-initialized array in which a nan shows up can be easily caught Yes nans are not one value but a class http://docs.oracle.com/cd/E19957-01/806-3568/ncg_math.html but so what? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
>> OTOH why in particular would you want to initialise them with zeros? I >> often initialise arrays to nan which is useful for debugging. Is this some kind of joke? What has this list become? >>> >>> It's a useful debugging technique to initialize memory to distinctive >>> values that should never occur in real data. >> >> If you're doing this, you're doing something wrong. Please give me >> the hex value for NaN so I can initialize with my array. > > It is clear that you know as much about debugging as you do about objects > and message passing [...] can see why the > BDFL described you as an embarrassment, and if he didn't, he certainly > should have done. Clearly the python list has been taken over by TheKooks. Notice he did not respond to the request. Since we are talking about digital computers (with digital memory), I'm really curious what the hex value for NaN is to initialize my arrays All hail chairman Meow. Dismissed. -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 25/10/2013 19:26, Mark Janssen wrote: OTOH why in particular would you want to initialise them with zeros? I often initialise arrays to nan which is useful for debugging. Is this some kind of joke? What has this list become? It's a useful debugging technique to initialize memory to distinctive values that should never occur in real data. If you're doing this, you're doing something wrong. Please give me the hex value for NaN so I can initialize with my array. It is clear that you know as much about debugging as you do about objects and message passing, a summary here for the uninitiated http://code.activestate.com/lists/python-ideas/19908/. I can see why the BDFL described you as an embarrassment, and if he didn't, he certainly should have done. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
OTOH why in particular would you want to initialise them with zeros? I often initialise arrays to nan which is useful for debugging. >> >> Is this some kind of joke? What has this list become? > > It's a useful debugging technique to initialize memory to distinctive values > that should never occur in real data. If you're doing this, you're doing something wrong. Please give me the hex value for NaN so I can initialize with my array. -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 10/25/13 7:55 AM, Mark Janssen wrote: On Thu, Oct 24, 2013 at 8:40 PM, Mark Lawrence wrote: On 22/10/2013 18:37, Oscar Benjamin wrote: OTOH why in particular would you want to initialise them with zeros? I often initialise arrays to nan which is useful for debugging. Is this some kind of joke? What has this list become? It's a useful debugging technique to initialize memory to distinctive values that should never occur in real data. Perhaps it better to say, "pre-initialize". If the program is working correctly, then that data will be written over with actual initial values, and you'll never see the distinctive values. But if your program does encounter one of those values, it's clear that there's a bug that needs to be fixed. Additionally, if you have a number of different distinctive values, then the actual value encountered provides a clue as to what might have gone wrong. In an array of floats, initializing to NaN would be very useful, since NaNs propagate through calculations, or raise exceptions. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 25/10/2013 12:55, Mark Janssen wrote: On Thu, Oct 24, 2013 at 8:40 PM, Mark Lawrence wrote: On 22/10/2013 18:37, Oscar Benjamin wrote: OTOH why in particular would you want to initialise them with zeros? I often initialise arrays to nan which is useful for debugging. Is this some kind of joke? What has this list become? What did *I* write? Something about real world practical programming that a text book theorist such as yourself wouldn't understand. The only snag is you haven't quoted anything that I've written. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Fri, 25 Oct 2013 04:55:43 -0700, Mark Janssen wrote: > On Thu, Oct 24, 2013 at 8:40 PM, Mark Lawrence > wrote: >> On 22/10/2013 18:37, Oscar Benjamin wrote: >>> OTOH why in particular would you want to initialise them with zeros? >>> I often initialise arrays to nan which is useful for debugging. > Is this some kind of joke? What has this list become? We used to initialize RAM to 0xdeadbeef on CPU reset (and sometimes calls to free in a debugging environment) for the same reason: if a program crashesd, and I saw that value in one of the CPU registers, then I knew that some part of the program accessed "uninitialized" (or freed) memory. That pattern also sticks out like a sore thumb (insert your own C++/hammer joke here) in a core dump. That said, I seem to recall that somewhere along the way, ANSI C began to guarantee that certain static (in the technical sense) values were initialized to 0, or NULL, or something like that, on program startup, before any user-level code executed. Dan -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Thu, Oct 24, 2013 at 8:40 PM, Mark Lawrence wrote: > On 22/10/2013 18:37, Oscar Benjamin wrote: >> OTOH why in particular would you want to initialise them with zeros? I >> often initialise arrays to nan which is useful for debugging. Is this some kind of joke? What has this list become? -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
Antoine Pitrou, 22.10.2013 10:55: > Philip Herron writes: >> Its interesting a few things come up what about: >> exec and eval. I didn't really have a good answer for this at my talk at >> PYCon IE 2013 but i am going to say no. I am >> not going to implement these. Partly because eval and exec at least to me >> are mostly from developing >> interpreters as a debugging exercise so the test doesn't have to invoke >> the program properly and feed in >> strings to interpret at least thats what i have done in the past with an >> virtual machine i wrote before gccpy. > > If you don't implement exec() and eval() then people won't be able to use > namedtuples, which are a common datatype factory. FWIW, for Cython, I personally consider eval() and exec() more of a handy way to insert plain Python code (potentially even generated at runtime) into compiled code, so they are not currently compiled. You can see that from the low Mako benchmark results, for example. We may eventually add an option to compile that code at runtime (assuming you have Cython and a C compiler installed), but I doubt that people would want that as the default. Obviously, Cython has the advantage of being backed by a CPython runtime, so it's easy for us to choose one or the other. An independent Python implementation doesn't easily have that choice. > As for the rest: well, good luck writing an AOT compiler producing > interesting results on average *pure* Python code. It's already been tried > a number of times, and has generally failed. Cython mitigates the issue by > exposing a superset of Python (including type hints, etc.). Agreed, although the word "mitigate" makes it sound more like a work-around than the actual feature it represents. I've written down my thoughts on this topic a while ago. http://blog.behnel.de/index.php?p=241 Stefan -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 10/23/2013 12:25 AM, Philip Herron wrote: > On Wednesday, 23 October 2013 07:48:41 UTC+1, John Nagle wrote: >> On 10/20/2013 3:10 PM, victorgarcia...@gmail.com wrote: >> >>> On Sunday, October 20, 2013 3:56:46 PM UTC-2, Philip Herron >>> wrote: > Nagle replies: >> Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd. ... > > I think your analysis is probably grossly unfair for many reasons. > But your entitled to your opinion. > > Current i do not use Bohem-GC (I dont have one yet), You included it in your project: http://sourceforge.net/p/gccpy/code/ci/master/tree/boehm-gc > i re-use > principles from gccgo in the _compiler_ not the runtime. At runtime > everything is a gpy_object_t, everything does this. Yeah you could do > a little of dataflow analysis for some really really specific code > and very specific cases and get some performance gains. But the > problem is that the libpython.so it was designed for an interpreter. > > So first off your comparing a project done on my own to something > like cPython loads of developers 20 years on my project or something > PyPy has funding loads of developers. > > Where i speed up is absolutely no runtime lookups on data access. > Look at cPython its loads of little dictionaries. All references are > on the Stack at a much lower level than C. All constructs are > compiled in i can reuse C++ native exceptions in the whole thing. I > can hear you shouting at the email already but the middle crap that a > VM and interpreter have to do and fast lookup is _NOT_ one of them. > If you truely understand how an interpreter works you know you cant > do this > > Plus your referencing really old code on sourceforge is another > thing. That's where you said to look: http://gcc.gnu.org/wiki/PythonFrontEnd "To follow gccpy development see: Gccpy SourceForge https://sourceforge.net/projects/gccpy"; > And i dont want to put out bench marks (I would get so much > shit from people its really not worth it) but it i can say it is > faster than everything in the stuff i compile so far. So yeah... not > only that but your referncing a strncmp to say no its slow yeah it > isn't 100% ideal but in my current git tree i have changed that. So the real source code isn't where you wrote that it is? Where is it, then? > So i > think its completely unfair to reference tiny things and pretend you > know everything about my project. If you wrote more documentation about what you're doing, people might understand what you are doing. > One thing people might find interesting is class i do data flow > analysis to generate a complete type for that class and each member > function is a compiled function like C++ but at a much lower level > than C++. It's not clear what this means. Are you trying to determine, say, which items are integers, lists, or specific object types? Shed Skin tries to do that. It's hard to do, but very effective if you can do it. In CPython, every time "x = a + b" is executed, the interpreter has to invoke the general case for "+", which can handle integers, floats, strings, NumPy, etc. If you can infer types, and know it's a float, the run time code can be float-specific and about three machine instructions. > The whole project has been about stripping out the crap > needed to run user code and i have been successful so far but your > comparing a in my spare time project to people who work on their > stuff full time. With loads of people etc. Shed Skin is one guy. > Anyways i am just going to stay out of this from now but your email > made me want to reply and rage. You've made big claims without giving much detail. So people are trying to find out if you've done something worth paying attention to. John Nagle -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 23/10/2013 08:25, Philip Herron wrote: Personally I have no interest in your project but do wish you the best of luck with your endeavours. However I do have a personnal interest in my eyesite, which gets strained by reading posts such as yours. In order to assist me in looking after my health, would you please be kind enough to read, digest and action this https://wiki.python.org/moin/GoogleGroupsPython. TIA. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Wednesday, 23 October 2013 07:48:41 UTC+1, John Nagle wrote: > On 10/20/2013 3:10 PM, victorgarcia...@gmail.com wrote: > > > On Sunday, October 20, 2013 3:56:46 PM UTC-2, Philip Herron wrote: > > >> I've been working on GCCPY since roughly november 2009 at least in its > > >> concept. It was announced as a Gsoc 2010 project and also a Gsoc 2011 > > >> project. I was mentored by Ian Taylor who has been an extremely big > > >> influence on my software development carrer. > > > > > > Cool! > > > > > >> Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd. > > >> (Although this is sparse partialy on purpose since i do not wan't > > >> people thinking this is by any means ready to compile real python > > >> applications) > > > > > > Is there any document describing what it can already compile and, if > > possible, showing some benchmarks? > > > > After reading through a vast amount of drivel below on irrelevant > > topics, looking at the nonexistent documentation, and finally reading > > some of the code, I think I see what's going on here. Here's > > the run-time code for integers: > > > > http://sourceforge.net/p/gccpy/code/ci/master/tree/libgpython/runtime/gpy-object-integer.c > > > >The implementation approach seems to be that, at runtime, > > everything is a struct which represents a general Python object. > > The compiler is, I think, just cranking out general subroutine > > calls that know nothing about type information. All the > > type handling is at run time. That's basically what CPython does, > > by interpreting a pseudo-instruction set to decide which > > subroutines to call. > > > >It looks like integers and lists have been implemented, but > > not much else. Haven't found source code for strings yet. > > Memory management seems to rely on the Boehm garbage collector. > > Much code seems to have been copied over from the GCC library > > for Go. Go, though, is strongly typed at compile time. > > > >There's no inherent reason this "compiled" approach couldn't work, > > but I don't know if it actually does. The performance has to be > > very low. Each integer add involves a lot of code, including two calls > > of "strcmp (x->identifier, "Int")". A performance win over CPython > > is unlikely. > > > >Compare Shed Skin, which tries to infer the type of Python > > objects so it can generate efficient type-specific C++ code. That's > > much harder to do, and has trouble with very dynamic code, but > > what comes out is fast. > > > > John Nagle I think your analysis is probably grossly unfair for many reasons. But your entitled to your opinion. Current i do not use Bohem-GC (I dont have one yet), i re-use principles from gccgo in the _compiler_ not the runtime. At runtime everything is a gpy_object_t, everything does this. Yeah you could do a little of dataflow analysis for some really really specific code and very specific cases and get some performance gains. But the problem is that the libpython.so it was designed for an interpreter. So first off your comparing a project done on my own to something like cPython loads of developers 20 years on my project or something PyPy has funding loads of developers. Where i speed up is absolutely no runtime lookups on data access. Look at cPython its loads of little dictionaries. All references are on the Stack at a much lower level than C. All constructs are compiled in i can reuse C++ native exceptions in the whole thing. I can hear you shouting at the email already but the middle crap that a VM and interpreter have to do and fast lookup is _NOT_ one of them. If you truely understand how an interpreter works you know you cant do this Plus your referencing really old code on sourceforge is another thing. And i dont want to put out bench marks (I would get so much shit from people its really not worth it) but it i can say it is faster than everything in the stuff i compile so far. So yeah... not only that but your referncing a strncmp to say no its slow yeah it isn't 100% ideal but in my current git tree i have changed that. So i think its completely unfair to reference tiny things and pretend you know everything about my project. One thing people might find interesting is class i do data flow anaylsis to generate a complete type for that class and each member function is a compiled function like C++ but at a much lower level than C++. The whole project has been about stripping out the crap needed to run user code and i have been successful so far but your comparing a in my spare time project to people who work on their stuff full time. With loads of people etc. Anyways i am just going to stay out of this from now but your email made me want to reply and rage. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 10/20/2013 3:10 PM, victorgarcia...@gmail.com wrote: > On Sunday, October 20, 2013 3:56:46 PM UTC-2, Philip Herron wrote: >> I've been working on GCCPY since roughly november 2009 at least in its >> concept. It was announced as a Gsoc 2010 project and also a Gsoc 2011 >> project. I was mentored by Ian Taylor who has been an extremely big >> influence on my software development carrer. > > Cool! > >> Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd. >> (Although this is sparse partialy on purpose since i do not wan't >> people thinking this is by any means ready to compile real python >> applications) > > Is there any document describing what it can already compile and, if > possible, showing some benchmarks? After reading through a vast amount of drivel below on irrelevant topics, looking at the nonexistent documentation, and finally reading some of the code, I think I see what's going on here. Here's the run-time code for integers: http://sourceforge.net/p/gccpy/code/ci/master/tree/libgpython/runtime/gpy-object-integer.c The implementation approach seems to be that, at runtime, everything is a struct which represents a general Python object. The compiler is, I think, just cranking out general subroutine calls that know nothing about type information. All the type handling is at run time. That's basically what CPython does, by interpreting a pseudo-instruction set to decide which subroutines to call. It looks like integers and lists have been implemented, but not much else. Haven't found source code for strings yet. Memory management seems to rely on the Boehm garbage collector. Much code seems to have been copied over from the GCC library for Go. Go, though, is strongly typed at compile time. There's no inherent reason this "compiled" approach couldn't work, but I don't know if it actually does. The performance has to be very low. Each integer add involves a lot of code, including two calls of "strcmp (x->identifier, "Int")". A performance win over CPython is unlikely. Compare Shed Skin, which tries to infer the type of Python objects so it can generate efficient type-specific C++ code. That's much harder to do, and has trouble with very dynamic code, but what comes out is fast. John Nagle -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Wed, Oct 23, 2013 at 9:11 AM, Piet van Oostrum wrote: > Mark Janssen writes: > Is your language Turing complete? >>> >>> 1) No, it's not. >>> 2) So what? That should make it easier to compile to C, if anything. >>> 3) Don't change the subject. >> >> Well, if your language is not Turing complete, it is not clear that >> you will be able to compile it at all. That's the difference between >> a calculator and a computer. > > You think a language that is not Turing-complete cannot be compiled? > What nonsense is that. Please Mark, spare us your nonsense. HQ9+ can be compiled. By the simple technique of making the original source into a literal and appending the interpreter, you can make a compiler. Any language that has an interpreter can, therefore, be compiled, regardless of Turing completeness or any other attribute. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 23/10/2013 05:05, Michael Torrie wrote: On 10/22/2013 12:28 PM, Mark Janssen wrote: Thank you. You may be seated. Ranting Rick, is that you? I think that's unfair, rr can be very helpful when discussing IDLE type issues. In comparison all that appears to have eminated from Tacoma, Washington is inaccurate nonsense. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 23/10/2013 02:36, alex23 wrote: On 23/10/2013 4:40 AM, Ned Batchelder wrote: I've tried to be polite, and I've tried to be helpful, but I'm sorry: either you don't understand a lot of the terms you are throwing around, or you aren't disciplined enough to focus on a topic long enough to explain yourself. Either way, I don't know how else to move the discussion forward. You forgot to end with a well-warranted "Boom". Mark Janssen is rapidly becoming Xah Lee 2.0, identical down to the repugnant misogyny he expresses elsewhere. The only difference is one of verbosity. Wow, no punches pulled here. But IMHO thoroughly deserved. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 10/22/2013 12:28 PM, Mark Janssen wrote: > Thank you. You may be seated. Ranting Rick, is that you? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Wednesday, October 23, 2013 7:06:40 AM UTC+5:30, alex23 wrote: > On 23/10/2013 4:40 AM, Ned Batchelder wrote: > > > I've tried to be polite, and I've tried to be helpful, but I'm sorry: > > either you don't understand a lot of the terms you are throwing around, > > or you aren't disciplined enough to focus on a topic long enough to > > explain yourself. Either way, I don't know how else to move the > > discussion forward. > > You forgot to end with a well-warranted "Boom". > > Mark Janssen is rapidly becoming Xah Lee 2.0, identical down to the > repugnant misogyny he expresses elsewhere. The only difference is one of > verbosity. Hey! Time to stop punching up a guy -- even (because?) he's a nut -- rather a hard one tho -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 23/10/2013 4:40 AM, Ned Batchelder wrote: I've tried to be polite, and I've tried to be helpful, but I'm sorry: either you don't understand a lot of the terms you are throwing around, or you aren't disciplined enough to focus on a topic long enough to explain yourself. Either way, I don't know how else to move the discussion forward. You forgot to end with a well-warranted "Boom". Mark Janssen is rapidly becoming Xah Lee 2.0, identical down to the repugnant misogyny he expresses elsewhere. The only difference is one of verbosity. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-22, Mark Janssen wrote: >>> Is your language Turing complete? >>> >> >> 1) No, it's not. >> 2) So what? That should make it easier to compile to C, if anything. >> 3) Don't change the subject. > > Well, if your language is not Turing complete, it is not clear that > you will be able to compile it at all. Whether a language is turing complete or not has _NOTHING_ to do with whether it can be compiled or not. > That's the difference between a calculator and a computer. No, it isn't. > Thank you. You may be seated. Dunno what you're smoking, but you sure are getting your money's worth... -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
Mark Janssen writes: >>> Is your language Turing complete? >>> >> >> 1) No, it's not. >> 2) So what? That should make it easier to compile to C, if anything. >> 3) Don't change the subject. > > Well, if your language is not Turing complete, it is not clear that > you will be able to compile it at all. That's the difference between > a calculator and a computer. You think a language that is not Turing-complete cannot be compiled? What nonsense is that. Please Mark, spare us your nonsense. -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Wed, Oct 23, 2013 at 4:27 AM, Steven D'Aprano wrote: > On Tue, 22 Oct 2013 23:20:52 +1100, Chris Angelico wrote: > >> Considering that rapiding took about 1200ms (ish - again, cold cache) >> previously, adding even just 250ms is noticeable. > > Please excuse my skepticism, but in my experience, that would probably > mean in practice: > > ... rapiding took about 1200ms, plus or minus 200ms, plus 500ms if the > system is under load, plus 800ms if the developer vagued out for a > moment, plus 1900ms if he happened to be scratching an itch, plus 2700ms > if the anti-virus happened to be scanning something, plus 4100ms if the > dev decided this was a good time to take a sip of coffee, plus 437000ms > if he needed to make the coffee first, plus 7200ms if he was just > taking a moment to check something on Reddit or answer an email... Yes; and more importantly, at the times when it actually would be used, the cache will likely be warm. > You're right, of course, that 1/4 second is noticeable. I just find it > hard to credit that it's *significant* in the circumstances you're > describing. But I could be wrong. Yeah, but the problem here is a fundamental of human nature. I mentioned earlier that I was trying to "sell" the notion of an instant pre-check of the code. I use one myself, have done for ages, and it's helped me often enough that I don't care if it occasionally adds a second to my time. (I have a few such assistants that involve searching through recent git commit messages, so they can take multiple seconds if the cache is cold. I don't care; once it's in cache, it's way faster.) But imagine sitting beside a skeptical fellow developer and saying, "Enable this line here and it'll catch these sorts of bugs before you even spin it up in your testbox" - and he hits F7 and notices that it takes twice as long as he's used to. That's going to make it a pretty hard sell. That's why I wanted to get the time cost of the smoke test as low as I possibly could, even on a cold cache. (I'm used to tough sells at my workplace. It took years before we adopted source control yes, seriously. And even once we did, I had to fight to get other developers to make useful commits and commit messages. One in particular - who, fortunately, is no longer with us - saw the whole thing as a nuisance that got in the way of his genius, so he'd just commit once at the end of the day with a barely-useful message. But then, he was pretty astounding in a lot of other areas, too - really amazing... like using the For-Case paradigm in PHP with an off-by-one error...) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-22, Grant Edwards wrote: > C initializes to defined zero values. For most machines in use today, > those values _happen_ to be all-bits-zero. > > This makes the implementation trivial: chuck them all into some > pre-defined section (e.g. ".bss"), and then on startup, you zero-out > all the bits in the section without having to know what's where within > that section. If you design a machine such that integer, pointer, and > FP representations where 0, NULL, and 0.0 are all zero-bits, then life ^ not > get's tougher for the guys writing the compiler and startup code. -- Grant Edwards grant.b.edwardsYow! We are now enjoying at total mutual interaction in gmail.coman imaginary hot tub ... -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-22, Mark Lawrence wrote: > On 22/10/2013 20:27, Neil Cerutti wrote: >> On 2013-10-22, Piet van Oostrum wrote: >>> Neil Cerutti writes: Context-sensitive grammars can be parse, too. >>> >>> That's not English. Do you mean "parsed"? >> >> Thanks, yes, I meant parsed. >> >>> But context-sentitive grammars cannot be specified by BNF. >> >> Yes. I thought Mark might have had a misconception that all >> programming languages have to be defined in BNF. > > Please be kind enough to disambiguate Mark, as I would not wish > to be tarred with the same brush. Oops! I didn't notice he'd dropped out of the attributions. I was speculating about Mark Janssen, not you. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 22/10/2013 20:27, Neil Cerutti wrote: On 2013-10-22, Piet van Oostrum wrote: Neil Cerutti writes: Context-sensitive grammars can be parse, too. That's not English. Do you mean "parsed"? Thanks, yes, I meant parsed. But context-sentitive grammars cannot be specified by BNF. Yes. I thought Mark might have had a misconception that all programming languages have to be defined in BNF. Please be kind enough to disambiguate Mark, as I would not wish to be tarred with the same brush. TIA. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 22/10/2013 20:20, Piet van Oostrum wrote: Neil Cerutti writes: Context-sensitive grammars can be parse, too. That's not English. Do you mean "parsed"? But context-sentitive grammars cannot be specified by BNF. That's not English. Do you mean "context-sensitive"? :) -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-22, Piet van Oostrum wrote: > Neil Cerutti writes: >> Context-sensitive grammars can be parse, too. > > That's not English. Do you mean "parsed"? Thanks, yes, I meant parsed. > But context-sentitive grammars cannot be specified by BNF. Yes. I thought Mark might have had a misconception that all programming languages have to be defined in BNF. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
Neil Cerutti writes: > > Context-sensitive grammars can be parse, too. > That's not English. Do you mean "parsed"? But context-sentitive grammars cannot be specified by BNF. -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 10/22/13 1:50 PM, Mark Janssen wrote: So which of you is confused? I ask that in the inclusive (not exclusive OR) sense ;^) <-- face says "both". Could you please be less snarky? We're trying to communicate here, and it is not at all clear yet who is confused and who is not. If you are interested in discussing technical topics, then discuss them. Okay. The purpose of BNF (at least as I envision it) is to produce/specify a *context-free* "grammar". A lexer parses the tokens specified in the BNF into an Abstract Syntax Tree. If one can produce such a tree for any given source, the language, in theory, can be compiled by GCC into an executable. Boom. Hmm, I don't hear the boom yet. An Abstract Syntax Tree is a tree representation of a program. To use my previous example: the program "123 *!? 456" would become a tree: op: "*!?" num: 123 num: 456 There's still not enough information to compile this. The operator *!? needs to have a meaning assigned to it. That's the role of the semantic specification of a language. That has to be provided somehow. A BNF, or a grammar, or a syntax, or an AST can't provide the semantics. That was the original point: syntax isn't enough. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-22, Neil Cerutti wrote: > On 2013-10-22, Steven D'Aprano wrote: >> On Tue, 22 Oct 2013 14:04:57 +, Dave Angel wrote: >>> but here you go on to say the C code is unsafely skipping >>> initialization, which is not the case. >> >> Are you talking generically, or specifically about the C code >> referenced in the link I gave? >> >> "Memory is always zeroed" is one of the advantages of Go over C and C++, >> at least according to Rob Pike: >> >> http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially- >> more.html > > Go initializes variables to defined zero values, not simply to > all-bits zero as (I think) C does. C initializes to defined zero values. For most machines in use today, those values _happen_ to be all-bits-zero. This makes the implementation trivial: chuck them all into some pre-defined section (e.g. ".bss"), and then on startup, you zero-out all the bits in the section without having to know what's where within that section. If you design a machine such that integer, pointer, and FP representations where 0, NULL, and 0.0 are all zero-bits, then life get's tougher for the guys writing the compiler and startup code. But the language doesn't require or assume that initializer values are all-bits-zero. FP values have to be initizliaed to 0.0. Int's have to be initialized to integer value 0, pointers have to be initialized to (void*)0. Nowhere it the languauge is it required or assumed that any or all of those values are all represented by contiguous blocks of all-zero-bits. > This isn't as great a feature as it seems, since the zero value for > some built in types, e.g., map, is unusable without manual > construction. In addition, you can't define a zero value for your own > types. -- Grant Edwards grant.b.edwardsYow! Oh my GOD -- the at SUN just fell into YANKEE gmail.comSTADIUM!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 22/10/2013 19:40, rusi wrote: On Tuesday, October 22, 2013 11:53:22 PM UTC+5:30, Ned Batchelder wrote: A BNF doesn't provide enough information to compile a program to C. That's all I'm trying to help you understand. If you don't agree, then we have to talk about the meaning of the words BNF, compile, program, and C. I believe we need to talk about the Dunning-Kruger effect No need for me to discuss that as I used to be big headed but now I'm perfect. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-22, Steven D'Aprano wrote:
> On Tue, 22 Oct 2013 16:53:07 +, Frank Miles wrote:
>
> [snip C code]
>> What you're missing is that arr[] is an automatic variable. Put a
>> "static" in front of it, or move it outside the function (to become
>> global) and you'll see the difference.
>
> Ah, that makes sense. Thanks to everyone who corrected my
> misunderstanding.
>
> Well, actually, no it doesn't. I wonder why C specifies such behaviour?
> Why would you want non-global arrays to be filled with garbage?
Firstly, it's not non-global arrays that have undefined contents.
It's _auto_ arrays that have undefined contents.
void foo(void)
{
int a[4]; // non-global, _auto_ variable and has undefined contents
}
void bar(void)
{
static int a[4]; // non-global, _static_ variable initially 0's
}
As to _why_ it's that way, you'd have to ask the guys who decided
that. I supect it's because zeroing static variables involves very
little run-time overhead, while zeroing auto variables could cause
huge amounts of overhead if that auto variable is declared inside the
innermost of nested loops. [Presumably a good optimizing compiler
would not zero an auto variable that was always set before it was
referenced, but it takes a lot of smarts for compiler to figure that
out correctly 100% of the time -- probably more smarts than a PDP-11
had room for.]
--
Grant Edwards grant.b.edwardsYow! Let's send the
at Russians defective
gmail.comlifestyle accessories!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 22/10/2013 19:22, Mark Janssen wrote: Okay. The purpose of BNF (at least as I envision it) is to produce/specify a *context-free* "grammar". A lexer parses the tokens specified in the BNF into an Abstract Syntax Tree. If one can produce such a tree for any given source, the language, in theory, can be compiled by GCC into an executable. Boom. But you still need to specify the semantics. In my world, like writing pseudo-code or flow-charts, the AST *is* the semantics. What world are you guys from? The real world. :-) So what you're saying is that you generate an AST where there are certain pre-defined operations (primitives?) available? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Tuesday, October 22, 2013 11:53:22 PM UTC+5:30, Ned Batchelder wrote: > A BNF doesn't provide enough information to compile a program to C. > That's all I'm trying to help you understand. If you don't agree, then > we have to talk about the meaning of the words BNF, compile, program, and C. I believe we need to talk about the Dunning-Kruger effect -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 10/22/13 2:22 PM, Mark Janssen wrote: Okay. The purpose of BNF (at least as I envision it) is to produce/specify a *context-free* "grammar". A lexer parses the tokens specified in the BNF into an Abstract Syntax Tree. If one can produce such a tree for any given source, the language, in theory, can be compiled by GCC into an executable. Boom. But you still need to specify the semantics. In my world, like writing pseudo-code or flow-charts, the AST *is* the semantics. What world are you guys from? Mark, you started this by describing a program that compiled to C. Now you say you are in the world of pseudo-code and flow-charts. Which is it? In the world where actual programs get compiled and run, you need to have semantics, and they aren't expressed in an AST or a BNF. I think you think that an AST is enough, but it isn't. I'm also not sure what you actually think because we don't stay on a topic long enough to get into the details that would shed light. It's fun to feel like you are right, and it's easy if you change the topic when the going gets tough. You've done this a number of times. I've tried to be polite, and I've tried to be helpful, but I'm sorry: either you don't understand a lot of the terms you are throwing around, or you aren't disciplined enough to focus on a topic long enough to explain yourself. Either way, I don't know how else to move the discussion forward. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 10/22/13 2:16 PM, Mark Janssen wrote: So which of you is confused? I ask that in the inclusive (not exclusive OR) sense ;^) <-- face says "both". Could you please be less snarky? Okay. The purpose of BNF (at least as I envision it) is to produce/specify a *context-free* "grammar". A lexer parses the tokens specified in the BNF into an Abstract Syntax Tree. If one can produce such a tree for any given source, the language, in theory, can be compiled by GCC into an executable. Boom. Hmm, I don't hear the boom yet. An Abstract Syntax Tree is a tree representation of a program. To use my previous example: the program "123 *!? 456" would become a tree: op: "*!?" num: 123 num: 456 There's still not enough information to compile this. Is your language Turing complete? 1) No, it's not. 2) So what? That should make it easier to compile to C, if anything. 3) Don't change the subject. A BNF doesn't provide enough information to compile a program to C. That's all I'm trying to help you understand. If you don't agree, then we have to talk about the meaning of the words BNF, compile, program, and C. I applaud your interest in this topic. I think you need to learn more before you try to claim expertise, though. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
>> Is your language Turing complete? >> > > 1) No, it's not. > 2) So what? That should make it easier to compile to C, if anything. > 3) Don't change the subject. Well, if your language is not Turing complete, it is not clear that you will be able to compile it at all. That's the difference between a calculator and a computer. Thank you. You may be seated. Mark J Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
>> Okay. The purpose of BNF (at least as I envision it) is to >> produce/specify a *context-free* "grammar". A lexer parses the tokens >> specified in the BNF into an Abstract Syntax Tree. If one can produce >> such a tree for any given source, the language, in theory, can be >> compiled by GCC into an executable. >> >> Boom. >> > But you still need to specify the semantics. In my world, like writing pseudo-code or flow-charts, the AST *is* the semantics. What world are you guys from? -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-22, Mark Janssen wrote:
>>> So which of you is confused? I ask that in the inclusive (not
>>> exclusive OR) sense ;^) <-- face says "both".
>>
>> Could you please be less snarky? We're trying to communicate here, and it
>> is not at all clear yet who is confused and who is not. If you are
>> interested in discussing technical topics, then discuss them.
>
> Okay. The purpose of BNF (at least as I envision it) is to
> produce/specify a *context-free* "grammar".
Context-sensitive grammars can be parse, too.
> A lexer parses the tokens specified in the BNF into an Abstract
> Syntax Tree.
A lexer traditionaly reads the text and generates a stream of
tokens to the parser.
> If one can produce such a tree for any given source, the
> language, in theory, can be compiled by GCC into an executable.
What executable would GCC compile from a program that matched
this grammar?
spamgram = spam1, { ', ', more_spam }, '.'
spam1 = 'Spam'
more_spam = spam, { ', ', spam }
spam = 'spam'
--
Neil Cerutti
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
So which of you is confused? I ask that in the inclusive (not exclusive OR) sense ;^) <-- face says "both". >>> >>> Could you please be less snarky? >> >> Okay. The purpose of BNF (at least as I envision it) is to >> produce/specify a *context-free* "grammar". A lexer parses the tokens >> specified in the BNF into an Abstract Syntax Tree. If one can produce >> such a tree for any given source, the language, in theory, can be >> compiled by GCC into an executable. >> >> Boom. > > Hmm, I don't hear the boom yet. An Abstract Syntax Tree is a tree > representation of a program. To use my previous example: the program "123 > *!? 456" would become a tree: > > op: "*!?" > num: 123 > num: 456 > > There's still not enough information to compile this. Is your language Turing complete? -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 22/10/2013 18:50, Mark Janssen wrote: So which of you is confused? I ask that in the inclusive (not exclusive OR) sense ;^) <-- face says "both". Could you please be less snarky? We're trying to communicate here, and it is not at all clear yet who is confused and who is not. If you are interested in discussing technical topics, then discuss them. Okay. The purpose of BNF (at least as I envision it) is to produce/specify a *context-free* "grammar". A lexer parses the tokens specified in the BNF into an Abstract Syntax Tree. If one can produce such a tree for any given source, the language, in theory, can be compiled by GCC into an executable. Boom. But you still need to specify the semantics. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
Mark Janssen said: > Unattributed > > No its not like those 'compilers' i dont really agree with a compiler > > generating C/C++ and saying its producing native code. I dont really > > believe > > its truely within the statement. Compilers that do that tend to put in alot > > of type saftey code and debugging internals at a high level to get things > > working in other projects i am not saying python compilers here i havent > > analysed enough to say this. > > Hmm, well what I'd personally find interesting from a computer science > point of view is a app that will take a language specification in BNF > (complete with keywords and all) and output C code which is then > compiled to an executable as normal. This is how a front-end should > be designed. A middle-layer for translating common language elements > like lists, sets, etc, could make it easy. Taking this starting sortie I was going to try to justify what Mark is saying. Somewhat along the following lines. Things like lex and yacc (and equivalents in ecosystems other than C) give a kind of holy-grail in the following sense. When a writer of a lex/yacc spec does his thing, he does not need to think at the C level at all. Given that executable C is produced (and ignoring mishaps/bugs like shift-reduce conflicts etc) its a very ideal situation. The yacc-grammar (and its lex-helper) are completely declarative and yet they result in perfectly good ( O(n)) good C code. Taking this cue from the syntax domain one can treat it as a holy grail for semantics. ie can one specify the semantics of a language completely declaratively and have a lex/yacc *analogous* magic wand and get out a compiler/interpreter etc. Many people have pursued this holy grail but it remains elusive. Some examples: 1. Atribute grammars 2. Utrecht univs UUAG 3. Action semantics etc Note a key word above is "analogous" However when I see this: > Okay. The purpose of BNF (at least as I envision it) is to > produce/specify a *context-free* "grammar". A lexer parses the tokens > specified in the BNF into an Abstract Syntax Tree. If one can produce > such a tree for any given source, the language, in theory, can be > compiled by GCC into an executable. all I will say is "eyes-roll" -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Tue, Oct 22, 2013 at 12:50 PM, Mark Janssen wrote: > Okay. The purpose of BNF (at least as I envision it) is to > produce/specify a *context-free* "grammar". A lexer parses the tokens > specified in the BNF into an Abstract Syntax Tree. If one can produce > such a tree for any given source, the language, in theory, can be > compiled by GCC into an executable. Well, not quite. The lexer breaks the stream of characters up into tokens, which are fed to the parser, which produces an abstract syntax tree. From the WIkipedia entry: "In computer science, an abstract syntax tree (AST), or just syntax tree, is a tree representation of the abstract syntactic structure of source code written in a programming language. Each node of the tree denotes a construct occurring in the source code." Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
>> So which of you is confused? I ask that in the inclusive (not >> exclusive OR) sense ;^) <-- face says "both". > > Could you please be less snarky? We're trying to communicate here, and it > is not at all clear yet who is confused and who is not. If you are > interested in discussing technical topics, then discuss them. Okay. The purpose of BNF (at least as I envision it) is to produce/specify a *context-free* "grammar". A lexer parses the tokens specified in the BNF into an Abstract Syntax Tree. If one can produce such a tree for any given source, the language, in theory, can be compiled by GCC into an executable. Boom. -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 22/10/2013 18:23, Steven D'Aprano wrote: On Tue, 22 Oct 2013 16:53:07 +, Frank Miles wrote: [snip C code] What you're missing is that arr[] is an automatic variable. Put a "static" in front of it, or move it outside the function (to become global) and you'll see the difference. Ah, that makes sense. Thanks to everyone who corrected my misunderstanding. Well, actually, no it doesn't. I wonder why C specifies such behaviour? Why would you want non-global arrays to be filled with garbage? Static variables need be initialised only once, whereas auto variables exist on the stack, so they would need to be initialised repeatedly, which was considered too expensive, especially as they would be assigned to before use anyway (hopefully!). Of course, these days, with our much faster CPUs, we're not so bothered, and prefer to allocate on the heap. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-22, Steven D'Aprano wrote: > On Tue, 22 Oct 2013 16:53:07 +, Frank Miles wrote: > > [snip C code] >> What you're missing is that arr[] is an automatic variable. Put a >> "static" in front of it, or move it outside the function (to become >> global) and you'll see the difference. > > Ah, that makes sense. Thanks to everyone who corrected my > misunderstanding. > > Well, actually, no it doesn't. I wonder why C specifies such > behaviour? Why would you want non-global arrays to be filled > with garbage? Fish(enc)ey. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Tue, Oct 22, 2013 at 10:23 AM, Steven D'Aprano < steve+comp.lang.pyt...@pearwood.info> wrote: > On Tue, 22 Oct 2013 16:53:07 +, Frank Miles wrote: > > [snip C code] > > What you're missing is that arr[] is an automatic variable. Put a > > "static" in front of it, or move it outside the function (to become > > global) and you'll see the difference. > > Ah, that makes sense. Thanks to everyone who corrected my > misunderstanding. > > Well, actually, no it doesn't. I wonder why C specifies such behaviour? > Why would you want non-global arrays to be filled with garbage? > > Its a performance benefit, for cases where you are going to fill the array from other means, such as from a file or other sources such as literals. The global and static variables are effectively free to zero due to standard OS behaviours. The issue is actually more general than arrays, as the same behavior exists for all the types in C. Stack and heap variables have undefined value when initialized, while global and static variables (which are really the same thing, but with differing lexical scopes) are zero-filled. > > -- > Steven > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Tue, 22 Oct 2013 23:20:52 +1100, Chris Angelico wrote: > Considering that rapiding took about 1200ms (ish - again, cold cache) > previously, adding even just 250ms is noticeable. Please excuse my skepticism, but in my experience, that would probably mean in practice: ... rapiding took about 1200ms, plus or minus 200ms, plus 500ms if the system is under load, plus 800ms if the developer vagued out for a moment, plus 1900ms if he happened to be scratching an itch, plus 2700ms if the anti-virus happened to be scanning something, plus 4100ms if the dev decided this was a good time to take a sip of coffee, plus 437000ms if he needed to make the coffee first, plus 7200ms if he was just taking a moment to check something on Reddit or answer an email... I don't have a lot of sympathy for this sort of micro-optimization of interactive software, where the random variation from run to run is often larger than the time being optimized, and where the human element is usually one or two orders of magnitude greater still. Yes, developers complain when they have to wait for the computer for half a second, or at least the one time in thirty that they *notice* that they're waiting. The other 29 times the computer is actually waiting for them. Still, I'm probably no better. Only instead of optimizing code, I tend to "optimize" travel time with "short cuts" that are guaranteed[1] to shave off a minute from a journey that takes thirty minutes, plus or minus six minutes. Show me a way to avoid waiting at traffic lights for 30s, and I'll take it, even if it means waiting for a break in the traffic at a Give Way sign for three minutes. So I shouldn't mock too much :-) You're right, of course, that 1/4 second is noticeable. I just find it hard to credit that it's *significant* in the circumstances you're describing. But I could be wrong. [1] Guarantee void in the presence of rain, fog, heavy winds, light winds, police radar traps, industrial action, civil protests, riots, wars, earthquakes, acts of God, or other cars. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
Mark Janssen writes: > I love it. Watch this... > > [context] A language specification in BNF is just syntax. It doesn't say anything about semantics. So how could this be used to produce executable C code for a program? BNF is used to produce parsers. But a parser isn't sufficient. >>> >>> A C program is just syntax also. How does the compiler generate >>> executable machine code? Extrapolate into a Python front-end to C. > > [Dave Angel responds:] >> Did you even read the paragraph you quoted above? The BNF specification >> does NOT completely describe a language, it only defines its syntax. > > [Steven D'Aprano responds:] >> Like every other language, C programs are certainly not *just* syntax. >> Here is some syntax: >> >> &foo bar^ := > > Now, I don't know where y'all were taught Computer Science, but BNF > specifies not only syntax (which would be the *tokens* of a language), > but also its *grammar*; how syntax relates to linguistic categories > like keywords, and tokens relate to each other. Syntax is grammar. Tokens are part of the grammar (but often specified separately with a different grammar, usually regular expressions, which is a subset of BNF). So are you just confused or are you trollong? -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Tue, 22 Oct 2013 16:53:07 +, Frank Miles wrote: [snip C code] > What you're missing is that arr[] is an automatic variable. Put a > "static" in front of it, or move it outside the function (to become > global) and you'll see the difference. Ah, that makes sense. Thanks to everyone who corrected my misunderstanding. Well, actually, no it doesn't. I wonder why C specifies such behaviour? Why would you want non-global arrays to be filled with garbage? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-22, Steven D'Aprano wrote: > On Tue, 22 Oct 2013 14:04:57 +, Dave Angel wrote: >> but here you go on to say the C code is unsafely skipping >> initialization, which is not the case. > > Are you talking generically, or specifically about the C code > referenced in the link I gave? > > "Memory is always zeroed" is one of the advantages of Go over C and C++, > at least according to Rob Pike: > > http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially- > more.html Go initializes variables to defined zero values, not simply to all-bits zero as (I think) C does. This isn't as great a feature as it seems, since the zero value for some built in types, e.g., map, is unusable without manual construction. In addition, you can't define a zero value for your own types. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Tue, 22 Oct 2013 08:04:21 -0700, Mark Janssen wrote: A language specification in BNF is just syntax. It doesn't say anything about semantics. So how could this be used to produce executable C code for a program? BNF is used to produce parsers. But a parser isn't sufficient. >>> >>> A C program is just syntax also. How does the compiler generate >>> executable machine code? Extrapolate into a Python front-end to C. > > [Dave Angel responds:] >> Did you even read the paragraph you quoted above? The BNF >> specification does NOT completely describe a language, it only defines >> its syntax. > > [Steven D'Aprano responds:] >> Like every other language, C programs are certainly not *just* syntax. >> Here is some syntax: >> >> &foo bar^ := > > Now, I don't know where y'all were taught Computer Science, Melbourne University Computer Science Department. How about you? > but BNF > specifies not only syntax (which would be the *tokens* of a language), > but also its *grammar*; how syntax relates to linguistic categories > like keywords, and tokens relate to each other. I'm not about to get into a debate about the difference between syntax and grammar as they apply to computer languages, because it doesn't matter. Neither syntax nor grammar tell you what something *means*, the semantics of the code. The parser knows that (say) "x ^% y" is legal and (say) "x y ^%" is not, but it doesn't know what machine code to generate when it sees "x ^% y". That's not the job of the parser. I expect that some compilers -- ancient ones, or lousy ones, or simple ones -- have a single routine that do all the parsing, lexing, code generation, linking, optimizing, etc., rather than separate routines that do the parsing, the code generation, and so on. But even those compilers cannot just take a description of the syntax and intuit what it means. Syntax isn't enough. At some point, the compiler needs to know that "^" means to generate code to dereference pointers (like in Pascal), or perhaps it's bitwise or (like in C), or maybe even exponentiation (like in VisualBasic), or perhaps it's something completely different. > Dave is claiming that BNF only defines the syntax of a language, but > then Stephen goes on to supply some syntax that a BNF specification of > the language would not allow (even though Steven calls it "syntax" which > is what BNF in Dave's claim parses). I think you have misunderstood me. I gave an example of some invented syntax that your hypothetical language might choose to use. Here it is again: &foo bar^ := Since I didn't provide the BNF specification for that syntax, you aren't in a position to say it is illegal. You should assume that it is legal syntax. If you really insist, I'll waste my time and yours and generate a BNF specification that allows that as valid syntax, or you could just accept that it's legal for this imaginary language. Your task is to describe what the code does, and hence what machine code your hypothetical compiler will generate, when it sees that line of code. You should be asking "How the hell can I tell what that does?" Exactly. That's the point. Neither can the compiler, not from syntax alone. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Tue, 22 Oct 2013 16:40:32 +, Steven D'Aprano wrote:
> On Tue, 22 Oct 2013 15:39:42 +, Grant Edwards wrote:
>
>>> No, I was thinking of an array. Arrays aren't automatically
>>> initialised in C.
>>
>> If they are static or global, then _yes_they_are_. They are zeroed.
>
> Not that I don't believe you, but do you have a reference for this?
> Because I keep finding references to uninitialised C arrays filled with
> garbage if you don't initialise them.
>
> Wait... hang on a second...
>
> /fires up the ol' trusty gcc
>
>
> [steve@ando c]$ cat array_init.c
> #include
>
> int main()
> {
> int i;
> int arr[10];
> for (i = 0; i < 10; i++) {
> printf("arr[%d] = %d\n", i, arr[i]);
> }
> printf("\n");
> return 0;
> }
>
> [steve@ando c]$ gcc array_init.c
> [steve@ando c]$ ./a.out
> arr[0] = -1082002360
> arr[1] = 134513317
> arr[2] = 2527220
> arr[3] = 2519564
> arr[4] = -1082002312
> arr[5] = 134513753
> arr[6] = 1294213
> arr[7] = -1082002164
> arr[8] = -1082002312
> arr[9] = 2527220
>
>
> What am I missing here?
What you're missing is that arr[] is an automatic variable. Put
a "static" in front of it, or move it outside the function (to become
global) and you'll see the difference.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Tue, Oct 22, 2013 at 9:40 AM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
> On Tue, 22 Oct 2013 15:39:42 +, Grant Edwards wrote:
>
> >> No, I was thinking of an array. Arrays aren't automatically initialised
> >> in C.
> >
> > If they are static or global, then _yes_they_are_. They are zeroed.
>
> Not that I don't believe you, but do you have a reference for this?
> Because I keep finding references to uninitialised C arrays filled with
> garbage if you don't initialise them.
>
> Wait... hang on a second...
>
> /fires up the ol' trusty gcc
>
>
> [steve@ando c]$ cat array_init.c
> #include
>
> int main()
> {
> int i;
> int arr[10];
> for (i = 0; i < 10; i++) {
> printf("arr[%d] = %d\n", i, arr[i]);
> }
> printf("\n");
> return 0;
> }
>
> [steve@ando c]$ gcc array_init.c
> [steve@ando c]$ ./a.out
> arr[0] = -1082002360
> arr[1] = 134513317
> arr[2] = 2527220
> arr[3] = 2519564
> arr[4] = -1082002312
> arr[5] = 134513753
> arr[6] = 1294213
> arr[7] = -1082002164
> arr[8] = -1082002312
> arr[9] = 2527220
>
> What am I missing here?
>
The array you made there is an auto variable (stack), not a static or a
global. Try one of the following (neither has been tested):
Static:
int main()
{
int i;
static int arr[10];
for (i = 0; i < 10; i++) {
printf("arr[%d] = %d\n", i, arr[i]);
}
printf("\n");
return 0;
}
Global:
int arr[10];
int main()
{
int i;
for (i = 0; i < 10; i++) {
printf("arr[%d] = %d\n", i, arr[i]);
}
printf("\n");
return 0;
}
As for a reference:
http://stackoverflow.com/questions/1831290/static-variable-initialization
and
http://stackoverflow.com/questions/3373108/why-are-static-variables-auto-initialized-to-zero,
both of which then reference the C++ standard.
>
> --
> Steven
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 22/10/2013 17:40, Steven D'Aprano wrote:
On Tue, 22 Oct 2013 15:39:42 +, Grant Edwards wrote:
No, I was thinking of an array. Arrays aren't automatically initialised
in C.
If they are static or global, then _yes_they_are_. They are zeroed.
Not that I don't believe you, but do you have a reference for this?
Because I keep finding references to uninitialised C arrays filled with
garbage if you don't initialise them.
Wait... hang on a second...
/fires up the ol' trusty gcc
[steve@ando c]$ cat array_init.c
#include
int main()
{
int i;
int arr[10];
for (i = 0; i < 10; i++) {
printf("arr[%d] = %d\n", i, arr[i]);
}
printf("\n");
return 0;
}
[steve@ando c]$ gcc array_init.c
[steve@ando c]$ ./a.out
arr[0] = -1082002360
arr[1] = 134513317
arr[2] = 2527220
arr[3] = 2519564
arr[4] = -1082002312
arr[5] = 134513753
arr[6] = 1294213
arr[7] = -1082002164
arr[8] = -1082002312
arr[9] = 2527220
What am I missing here?
arr is local to main, not static or global.
--
Python is the second best programming language in the world.
But the best has yet to be invented. Christian Tismer
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Tue, 22 Oct 2013 15:39:42 +, Grant Edwards wrote:
>> No, I was thinking of an array. Arrays aren't automatically initialised
>> in C.
>
> If they are static or global, then _yes_they_are_. They are zeroed.
Not that I don't believe you, but do you have a reference for this?
Because I keep finding references to uninitialised C arrays filled with
garbage if you don't initialise them.
Wait... hang on a second...
/fires up the ol' trusty gcc
[steve@ando c]$ cat array_init.c
#include
int main()
{
int i;
int arr[10];
for (i = 0; i < 10; i++) {
printf("arr[%d] = %d\n", i, arr[i]);
}
printf("\n");
return 0;
}
[steve@ando c]$ gcc array_init.c
[steve@ando c]$ ./a.out
arr[0] = -1082002360
arr[1] = 134513317
arr[2] = 2527220
arr[3] = 2519564
arr[4] = -1082002312
arr[5] = 134513753
arr[6] = 1294213
arr[7] = -1082002164
arr[8] = -1082002312
arr[9] = 2527220
What am I missing here?
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Tue, Oct 22, 2013 at 8:04 AM, Mark Janssen wrote: > I love it. Watch this... > > [context] A language specification in BNF is just syntax. It doesn't say anything about semantics. So how could this be used to produce executable C code for a program? BNF is used to produce parsers. But a parser isn't sufficient. >>> >>> A C program is just syntax also. How does the compiler generate >>> executable machine code? Extrapolate into a Python front-end to C. > > [Dave Angel responds:] >> Did you even read the paragraph you quoted above? The BNF specification >> does NOT completely describe a language, it only defines its syntax. > > [Steven D'Aprano responds:] >> Like every other language, C programs are certainly not *just* syntax. >> Here is some syntax: >> >> &foo bar^ := > > Now, I don't know where y'all were taught Computer Science, but BNF > specifies not only syntax (which would be the *tokens* of a language), > but also its *grammar*; how syntax relates to linguistic categories > like keywords, and tokens relate to each other. > > Dave is claiming that BNF only defines the syntax of a language, but > then Stephen goes on to supply some syntax that a BNF specification of > the language would not allow (even though Steven calls it "syntax" > which is what BNF in Dave's claim parses). > > So which of you is confused? I ask that in the inclusive (not > exclusive OR) sense ;^) <-- face says "both". > I don't know where you were taught English, but syntax is " the way in which linguistic elements (as words) are put together to form constituents (as phrases or clauses) ", not the set of valid words (tokens) in a language. A grammar, such as those grammars written in BNF, describe the rules for the syntax of a language. And, as Steven said, it still doesn't describe the semantics of a language, which is the set of instructions described by the syntax. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 22/10/2013 16:46, Ned Batchelder wrote: Could you please be less snarky? We're trying to communicate here, and it is not at all clear yet who is confused and who is not. If you are interested in discussing technical topics, then discuss them. --Ned. Well put, particularly when considering that both Dave Angel and Steven D'Aprano, the targets of the snarkiness, have been regular, helpful contributors over many years. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
Steven D'Aprano pearwood.info> writes: > > On Tue, 22 Oct 2013 08:55:15 +, Antoine Pitrou wrote: > > > If you don't implement exec() and eval() then people won't be able to > > use namedtuples, which are a common datatype factory. > > Philip could always supply his own implementation of namedtuple that > doesn't use exec. > > But either way, if he doesn't implement eval and exec, what he has is not > Python, but a subset of Python. Perhaps an interesting and useful subset. If you go that way, we already have Cython (which is both a subset and superset of Python, although I don't know if it's still a strict subset these days). Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 10/22/13 11:04 AM, Mark Janssen wrote: I love it. Watch this... [context] A language specification in BNF is just syntax. It doesn't say anything about semantics. So how could this be used to produce executable C code for a program? BNF is used to produce parsers. But a parser isn't sufficient. A C program is just syntax also. How does the compiler generate executable machine code? Extrapolate into a Python front-end to C. [Dave Angel responds:] Did you even read the paragraph you quoted above? The BNF specification does NOT completely describe a language, it only defines its syntax. [Steven D'Aprano responds:] Like every other language, C programs are certainly not *just* syntax. Here is some syntax: &foo bar^ := Now, I don't know where y'all were taught Computer Science, but BNF specifies not only syntax (which would be the *tokens* of a language), but also its *grammar*; how syntax relates to linguistic categories like keywords, and tokens relate to each other. Mark, you had expressed interest in "an app that will take a language specification in BNF (complete with keywords and all) and output C code which is then compiled to an executable". I'm interested in how that app might work. Here's a BNF for a (very!) simple language: ::= ::= "*!?" | "--+" | "..:" That means these are three valid programs: 123 *!? 456 2 --+ 2 1001 ..: 4 What will the app output as C code for each of these? Dave is claiming that BNF only defines the syntax of a language, but then Stephen goes on to supply some syntax that a BNF specification of the language would not allow (even though Steven calls it "syntax" which is what BNF in Dave's claim parses). So which of you is confused? I ask that in the inclusive (not exclusive OR) sense ;^) <-- face says "both". Could you please be less snarky? We're trying to communicate here, and it is not at all clear yet who is confused and who is not. If you are interested in discussing technical topics, then discuss them. --Ned. Mark Janssen Tacoma, Washington. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-22, Steven D'Aprano wrote: > On Tue, 22 Oct 2013 14:04:57 +, Dave Angel wrote: > > [...] >> I agree with most of what you say in the message, > > Glad to hear I wasn't completely full of it. As a non-C developer, I'm > very conscious that a lot of what I know about C is second hand. > > >> but here you go on to >> say the C code is unsafely skipping initialization, which is not the >> case. > > Are you talking generically, or specifically about the C code > referenced in the link I gave? In C, static/global variables are always zeroed. > "Memory is always zeroed" is one of the advantages of Go over C and C++, > at least according to Rob Pike: > > http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html Perhaps he's talking about automatic variables or malloc()ed memory? You'd have to ask him. >> Perhaps you were thinking of an automatic variable, which is not >> initialized unless the programmer says so, and is then initialized with >> code. > > No, I was thinking of an array. Arrays aren't automatically initialised > in C. If they are static or global, then _yes_they_are_. They are zeroed. -- Grant Edwards grant.b.edwardsYow! I selected E5 ... but at I didn't hear "Sam the Sham gmail.comand the Pharoahs"! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 2013-10-22, Dave Angel wrote: > On 22/10/2013 08:00, Steven D'Aprano wrote: >> [quote] >> C does not require you to set static global arrays to ?0?, so the >> for loop in the main function can go... >> >> Wait a minute... Haskell, I'm pretty sure, zeroes memory. C doesn't. So > > Static int variables are in fact zeroed. However, most C compilers > do it by putting four bytes (or whatever) into the image of the > executable so it has no runtime cost. No, that's not how gcc works (nor is it how any other C compiler I've ever seen works). Static variables get located in a "bss" section[1], which is zeroed out at run-time by startup code that gets executed before main() is called. The ELF executable contains headers that describe the size/location of bss section, but the object file contains no actual _data_. [1] IIRC, the name "bss" is a historical hold-over from the PDP-11 assembler directive that is used to declare a section of memory that is to be filled with zeros. Not all compilers use that section name, but they all use the same mechanism. > int myvar = 34 * 768; > > it'll put the product directly in the executable image, and no > runtime code is generated. That is true. -- Grant Edwards grant.b.edwardsYow! My EARS are GONE!! at gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Tue, 22 Oct 2013 14:04:57 +, Dave Angel wrote:
[...]
> I agree with most of what you say in the message,
Glad to hear I wasn't completely full of it. As a non-C developer, I'm
very conscious that a lot of what I know about C is second hand.
> but here you go on to
> say the C code is unsafely skipping initialization, which is not the
> case.
Are you talking generically, or specifically about the C code referenced
in the link I gave?
"Memory is always zeroed" is one of the advantages of Go over C and C++,
at least according to Rob Pike:
http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-
more.html
> By the way, a C compiler typically handles any initialization of a
> static variable the same way. So if you declare and initialize a static
> variable as
>
> int myvar = 34 * 768;
>
> it'll put the product directly in the executable image, and no runtime
> code is generated.
Yes, that's a keyhole optimization, CPython does the same sort of thing:
py> import dis
py> dis.dis(compile("myvar = 34 * 768", "", "exec"))
1 0 LOAD_CONST 3 (26112)
3 STORE_NAME 0 (myvar)
6 LOAD_CONST 2 (None)
9 RETURN_VALUE
> Perhaps you were thinking of an automatic variable, which is not
> initialized unless the programmer says so, and is then initialized with
> code.
No, I was thinking of an array. Arrays aren't automatically initialised
in C.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
I love it. Watch this... [context] >>> A language specification in BNF is just syntax. It doesn't say anything >>> about semantics. So how could this be used to produce executable C code >>> for a program? BNF is used to produce parsers. But a parser isn't >>> sufficient. >> >> A C program is just syntax also. How does the compiler generate >> executable machine code? Extrapolate into a Python front-end to C. [Dave Angel responds:] > Did you even read the paragraph you quoted above? The BNF specification > does NOT completely describe a language, it only defines its syntax. [Steven D'Aprano responds:] > Like every other language, C programs are certainly not *just* syntax. > Here is some syntax: > > &foo bar^ := Now, I don't know where y'all were taught Computer Science, but BNF specifies not only syntax (which would be the *tokens* of a language), but also its *grammar*; how syntax relates to linguistic categories like keywords, and tokens relate to each other. Dave is claiming that BNF only defines the syntax of a language, but then Stephen goes on to supply some syntax that a BNF specification of the language would not allow (even though Steven calls it "syntax" which is what BNF in Dave's claim parses). So which of you is confused? I ask that in the inclusive (not exclusive OR) sense ;^) <-- face says "both". Mark Janssen Tacoma, Washington. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On 22 October 2013 13:00, Steven D'Aprano
wrote:
> On Tue, 22 Oct 2013 10:14:16 +0100, Oscar Benjamin wrote:
>
>> On 22 October 2013 00:41, Steven D'Aprano
>> wrote:
>>>
>>> Are you suggesting that gcc is not a decent compiler?
>>
>> No.
>>
>>> If "optimize away
>>> to the null program" is such an obvious thing to do, why doesn't the
>>> most popular C compiler in the [FOSS] world do it?
>>
>> It does if you pass the appropriate optimisation setting (as shown in
>> haypo's comment). I should have been clearer.
>
> "C can do nothing 10 times faster than Python!" -- well, okay, but what
> does that tell you about my long-running web server app? Benchmarks at
> the best of time are only suggestive, benchmarks for null programs are
> even less useful.
This is precisely my point. They should show a benchmark that is not
semantically equivalent to the null program. I modified their example
to do that so that it wasn't simply a case of removing dead code and
then found that the C version performed 6-7 times faster than the PyPy
version. Had they simply stated that I would have been impressed.
At the bottom of this post I show a much better benchmark that shows
how PyPy can come very close to C performance for intensive floating
point computation. Note that although it is simple the benchmark
actually produces a result and none of the computation can be skipped
as dead code (why would I put that in?). Also note that both the C
binary and the script produce exactly the same numeric output. It's
also a simple example of numerical integration - something that is
often a bottleneck in scientific computation.
For the benchmark I find that the gcc -O3 binary runs in 4.6s and PyPy
runs the script in 6.9s (CPython 2.7 takes 600 seconds). That is
impressive and makes me think that there may be no need for me to use
C for things like that. To be sure I'd have to scale it up a bit to
see what happens when I break it apart into many functions and use
lists in PyPy vs arrays in C.
> [...]
>> They are more than carefully crafted. They are useless and misleading.
>> It's reasonable to contrive of a simple CPU-intensive programming
>> problem for benchmarking. But the program should do *something* even if
>> it is contrived. Both programs here consist *entirely* of dead code.
>
> But since the dead code is *not* eliminated, it is actually executed. If
> it's executed, it's not really dead, is it? Does it really matter that
> you don't do anything with the result? I'm with Maciej on this one --
> *executing* the code given is faster in PyPy than in C, at least for this
> C compiler. Maybe C is faster to not execute it. Is that really an
> interesting benchmark? "C does nothing ten times faster than PyPy does
> something!"
I don't think it is reasonable to compare those things and I was
joking when I said that the optimised C version was 600 times faster
because this is an absurd benchmark - see the much better one below.
> Given a sufficiently advanced static analyser, PyPy could probably
> special-case programs that do nothing. Then you're in a race to compare
> the speed at which the PyPy runtime environment can start up and do
> nothing, versus a stand-alone executable that has to start up and do
> nothing. If this is a benchmark that people care about, I suggest they
> need to get out more :-)
Like Chris I have also had situations where startup time mattered and
it can vary substantially between different interpreters and binaries.
I have GNU Octave on Windows and it literally takes 20 seconds to
start up. Matlab is worse: it takes about 1 minute so I don't tend to
use it for CLI scripts much.
Oscar
The benchmark:
$ cat euler.py
#!/usr/bin/env pypy
import math
def main():
x = 1
v = 0
t = 0
T = 1
dt = 2**-30
while t < T:
dxdt = v
dvdt = - x
x += dt * dxdt
v += dt * dvdt
t += dt
print('t = %.2e' % t)
print('x = %.2e' % x)
print('v = %.2e' % v)
print('x_err = %.e' % (x - math.cos(t)))
print('x_err = %.2e' % (v + math.sin(t)))
main()
$ time pypy euler.py
t = 1.00e+00
x = 5.40e-01
v = -8.41e-01
x_err = 3e-10
x_err = -3.92e-10
real0m6.907s
user0m0.076s
sys 0m0.045s
$ cat euler.c
#include
#include
int main()
{
double x = 1;
double v = 0;
double t = 0;
double T = 1;
double dt = pow(2, -30);
double dxdt, dvdt;
while (t < T)
{
dxdt = v;
dvdt = - x;
x += dt * dxdt;
v += dt * dvdt;
t += dt;
}
printf("t = %.2e\n", t);
printf("x = %.2e\n", x);
printf("v = %.2e\n", v);
printf("x_err = %.e\n", x - cos(t));
printf("x_err = %.2e\n", v + sin(t));
return 0;
}
$ gcc -O3 euler.c
$ time ./a.exe
t = 1.00e+000
x = 5.40e-001
v = -8.41e-001
x_err = 3e-010
x_err = -3.92e-010
real0m4.609s
user0m0.015s
sys 0m0.000s
$ time python euler.py # CPython 2.7
t = 1.00e+00
x = 5.40e-01
v = -8.41e-01
x_err = 3e-10
x_err = -3.92e-10
rea
Re: Python Front-end to GCC
On 22/10/2013 08:00, Steven D'Aprano wrote: > On Tue, 22 Oct 2013 10:14:16 +0100, Oscar Benjamin wrote: > > Here's an example: responding to a benchmark showing a Haskell compiler > generating faster code than a C compiler, somebody re-wrote the C code > and got the opposite result: > > http://jacquesmattheij.com/when-haskell-is-not-faster-than-c > > Again, I can't judge the validity of all of the changes he made, but one > stood out like a sore thumb: > > [quote] > C does not require you to set static global arrays to ‘0’, so the > for loop in the main function can go... > > Wait a minute... Haskell, I'm pretty sure, zeroes memory. C doesn't. So Static int variables are in fact zeroed. However, most C compilers do it by putting four bytes (or whatever) into the image of the executable so it has no runtime cost. > But eventually[1] you will need to fix the security > vulnerability by adding code to zero the memory, exactly as Haskell and > other more secure languages already do. So *not* zeroing the memory is > cheating. It's not something you'd do in real code, not if you care > about security and correctness. I agree with most of what you say in the message, but here you go on to say the C code is unsafely skipping initialization, which is not the case. By the way, a C compiler typically handles any initialization of a static variable the same way. So if you declare and initialize a static variable as int myvar = 34 * 768; it'll put the product directly in the executable image, and no runtime code is generated. Perhaps you were thinking of an automatic variable, which is not initialized unless the programmer says so, and is then initialized with code. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
