Re: L2R/R2L syntax
Simon Cozens [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Mr. Nobody) writes: Unicode operators in the core are a very, very, very, very, very, very, very, very, very, very, very, very, very bad idea. We've done that. Yeah, but not with quite so many 'very's. I think you'll find that that makes all the difference. -- Piers
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Wed, Jan 15, 2003 at 10:50:57PM -0500, Dan Sugalski wrote: At 12:05 AM + 1/16/03, Simon Cozens wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. I was shooting for the good old days of sarcasm that people noticed, but alas I missed. I think dry, unlabled sarcasm may be unwise, considering the number of crazy ideas that have been put forward in all seriousness. Some have even been adopted, and hence redefined as inspired. Nicholas Clark
Re: Objects, finally (try 1)
If memory serves me right, Jonathan Sillito wrote: x = a.f # get the method, a limited form of currying # since the first arg (a==self) is stored x() # output: A.f() setattr(A, f, g) # replace A's f with g a.f()# output: g() x() # output (still): A.f() !!! Which shows that the dispatch (i.e. selecting which method to call) can happen before the invocation. This makes sense let me put it in this way x_mthdptr=a.__dict__[f] a.__dict__[f]=g_mthdptr x_mthdptr() The dispatch vs invocation looks childishly simple when written this way.. (and I hope I'm right about that ... :) Underneath the high level language most things are really simple ... The Python compiler should work around all these language quirks and generate appropriate Parrot code ... In bytecode it should look direct, simple and fast !. Gopal -- The difference between insanity and genius is measured by success
pretty pictures
I was playing with doxygen (www.stack.nl/~dimitri/doxygen/index.html) (think javadoc for C++) and thought I'd pass along some random pictures. Doxygen unfortunately doesn't handle perl code, and even has problems with parrot's C. (IMHO, the world needs a wrapper hack which allows you to run all these variously broken code analysis tools, and then gloms their outputs together into something browsable. Ah well. Todo list.) Attached are the interpreter.h include tree, and the PMC and Arena datastructure graphs. (Why not Interp? See previous paragraph). GraphVis (www.graphviz.org) did the actual drawing. Hmm. Maybe a picture of the complete include graph would be useful introductory material... Mitchell interpreter_8h__dep__incl.pngstructPMC__coll__graph.pngstructArenas__coll__graph.png
Re: pretty pictures
--- Mitchell N Charity [EMAIL PROTECTED] wrote: Doxygen unfortunately doesn't handle perl code, and even has problems with parrot's C. You might be interested in autodia, it handles perl. http://droogs.org/autodia/ (IMHO, the world needs a wrapper hack which allows you to run all these variously broken code analysis tools, and then gloms their outputs together into something browsable. Ah well. Todo list.) The goal of the introspector is to publish a RDF/XML ontology of the various systems and thier dumps. Then you can merge the ontologies on a logical level and transform them between each other. Well what exactly do you need? I will be looking in running the introspector over the parrot code. That will produce a rdf file of the entire parrot source code. I would like to also figure out how to extract the high-level infomration from perl. The next step for the introspector was B::ToXML and to get that running. But for Perl6, i wonder what that best way to get at the data? The assembler does not contain any high level information. GraphVis (www.graphviz.org) did the actual drawing. Yes, that is on major goal of the introspector project to replace this funky non-free graphvis with the VCG. I hope to port VCG to GTK this year, and integrate it with DIA for a nice graph editor. http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html Hmm. Maybe a picture of the complete include graph would be useful introductory material... the graphs you doxygen produces are great. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Mr. Nobody [EMAIL PROTECTED] wrote: --- Austin Hastings [EMAIL PROTECTED] wrote: [... Massive elision ...] Right now almost all of us are in that boat. And we're talking about trigraph ops, like ~ and ~ and |~ and [+=] and whatever. As we get better, more Unicapable, whatever, we'll move on to full Unicode ops. trigraphs are actually better, even if you are unicode capable. ~ is far easier to type than ctrl-u-15F9E2A01 or whatever it is. Likewise, it wasn't possible until recently to EASILY type an accented vowel, or an n-tilde, from a US keyboard. Now, however, there's an IME that converts APOS + a into á (accented small a). Likewise, someone could write a Perl IME that converted TILDE+GREATER into Unicode-wiggly-right-arrow. And then it would be trivial, and you'd wonder what the fuss was about back in K2 ... =Austin
Re: L2R/R2L syntax (was Re: Everything is an object.)
[Note: I originally sent this to Mr. Nobody alone, but that wasn't my intent. I'm re-sending it here, where I wanted it to go in the first place. -- bmb] Mr. Nobody wrote: trigraphs are actually better, even if you are unicode capable. ~ is far easier to type than ctrl-u-15F9E2A01 or whatever it is. Maybe, maybe not On my machine right now, it is very easy for me to type various accented letters, like a, e, etc, making words like resume (or is that resume) nearly as fast to type as the non-accented version resume. I can also type or relatively easily as well. (I have no idea how well those will be transmitted on this list. I typed hiragana using the hiragana script, and katakana in katakana, two of the standard character sets of Japan. I'm not sure why I have my computer at work set up to allow me to input Japanese, since I'm not ? ?? nor do I speak ???) But the techniques for typing in funky characters is well known, and easy. Most likely, in the future when I have to work in Perl 6, my editor will be set up so that typing the Unicode squiggly-arrow character will be as simple as typing the two characters '~' and '', just like typing a Spanish N is as easy as typing '~' and 'N' right now. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
Buddha Buck wrote: Maybe, maybe not On my machine right now, it is very easy for me to type various accented letters, like a, e, etc, making words like resume (or is that resume) nearly as fast to type as the non-accented version resume. Hmmm, that's not what I wrote... On my machine, I had accents on the a and the e, and in the first two forms of resume. There are now four copies of the message in my sent folder (one to Mr. Nobody, one to the list, and two to myself), all of which have the proper characters in it. It appears that an intermediate relayer is converting my utf-8 formatted 8bit messages to us-ascii 7bit messages for no good reason. The Japanese came out badly, as well
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Thu, Jan 16, 2003 at 04:59:43PM -0500, Buddha Buck wrote: Buddha Buck wrote: Maybe, maybe not On my machine right now, it is very easy for me to type various accented letters, like a, e, etc, making words like resume (or is that resume) nearly as fast to type as the non-accented version resume. Hmmm, that's not what I wrote... On my machine, I had accents on the a and the e, and in the first two forms of resume. There are now four copies of the message in my sent folder (one to Mr. Nobody, one to the list, and two to myself), all of which have the proper characters in it. It appears that an intermediate relayer is converting my utf-8 formatted 8bit messages to us-ascii 7bit messages for no good reason. The Japanese came out badly, as well This would be one of the reasons why I don't think utf-8 perl6 scripts are a good idea. The headers I received make no mention of character set - does your mailer mark the message in any way? If not, then STMP will assume it's good old 7 bit ASCII Nicholas Clark
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Thu, Jan 16, 2003 at 10:07:13PM +, Nicholas Clark wrote: The headers I received make no mention of character set - does your mailer mark the message in any way? If not, then STMP will assume it's good old 7 bit ASCII Thus we are back to using uuencode :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. It's very much like the good old days of trigraphs. But on the plus side, once all the losers get their fonts/xterms/editors up-to-speed on extended character sets, the trigraphs will die a forgotten death. Oh, glorious future ... =Austin
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 8:08 AM -0800 1/16/03, Austin Hastings wrote: --- Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. It's very much like the good old days of trigraphs. But on the plus side, once all the losers get their fonts/xterms/editors up-to-speed on extended character sets, the trigraphs will die a forgotten death. And keyboards, don't forget keyboards. These pesky primitive ones we have now would require a lot of shift-control-alt-meta-cokebottle key sequences... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: L2R/R2L syntax (was Re: Everything is an object.)
Dan Sugalski [EMAIL PROTECTED] wrote: And keyboards, don't forget keyboards. These pesky primitive ones we have now would require a lot of shift-control-alt-meta-cokebottle key sequences... And vt100 consoles ! There are still sysadmins that struggle with a buggy perl script, having rebooted in single user mode, on a production box at 23:15 pm. But this has been already said...
Re: L2R/R2L syntax (was Re: Everything is an object.)
On 2003-01-16 at 11:41:56, Dan Sugalski wrote: And keyboards, don't forget keyboards. These pesky primitive ones we have now would require a lot of shift-control-alt-meta-cokebottle key sequences... Unicode may have thousands of characters, but how many of them do you think you'll use often enough to need as keys? Even if Perl6 adopted all the Unicode operators suggested so far and several more, you should easily be able to make them one-modifier or at worst two-modifier keyboard macros. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Austin Hastings [EMAIL PROTECTED] wrote: --- Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. It's very much like the good old days of trigraphs. But on the plus side, once all the losers get their fonts/xterms/editors up-to-speed on extended character sets, the trigraphs will die a forgotten death. Oh, glorious future ... =Austin How about people who can't? Lots of people don't own the computer they're using, so to upgrade stuff they'd have to ask the sysadmin. And you know what happens when you annoy the sysadmin... __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
RE: L2R/R2L syntax (was Re: Everything is an object.)
Mr. Nobody:
# --- Austin Hastings [EMAIL PROTECTED] wrote:
# It's very much like the good old days of trigraphs. But on the plus
# side, once all the losers get their fonts/xterms/editors
# up-to-speed
# on extended character sets, the trigraphs will die a
# forgotten death.
#
# How about people who can't? Lots of people don't own the
# computer they're using, so to upgrade stuff they'd have to
# ask the sysadmin. And you know what happens when you annoy
# the sysadmin...
I suspect that was sarcasm.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
RE: L2R/R2L syntax (was Re: Everything is an object.)
--- Brent Dax [EMAIL PROTECTED] wrote: Mr. Nobody: # --- Austin Hastings [EMAIL PROTECTED] wrote: # It's very much like the good old days of trigraphs. But on the plus # side, once all the losers get their fonts/xterms/editors # up-to-speed # on extended character sets, the trigraphs will die a # forgotten death. # # How about people who can't? Lots of people don't own the # computer they're using, so to upgrade stuff they'd have to # ask the sysadmin. And you know what happens when you annoy # the sysadmin... I suspect that was sarcasm. Which was? Mine or Austin's? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Thursday, January 16, 2003, at 08:57 AM, Mark J. Reed wrote: On 2003-01-16 at 11:41:56, Dan Sugalski wrote: And keyboards, don't forget keyboards. These pesky primitive ones we have now would require a lot of shift-control-alt-meta-cokebottle key sequences... Unicode may have thousands of characters, but how many of them do you think you'll use often enough to need as keys? Even if Perl6 adopted all the Unicode operators suggested so far and several more, you should easily be able to make them one-modifier or at worst two-modifier keyboard macros. Well, I don't know about anyone else, but *I'm* planning on making many, many Unicode synonyms, to make my code shorter and more readable. For example, Cfor is too long, so I want to just make it curly-f, (ƒ). And Cwhen is even longer, so I'm going to use something else, probably lowercase omega (ω). The numbers-in-a-circle characters can be used for array options. Instead of @array[3], I'll be saying @array➌. And @array③ will mean every element of the array except for the third. I'm still looking for the Unicode sad-faced-clown-on-fire character. When I find it, I think I'm gonna make it mean Cshift. Well, that or Cunshift, I can't decide. It depends on how sad the clown looks. MikeL
Re: L2R/R2L syntax (was Re: Everything is an object.)
Glad to see someone heeded that warning about unrecognizable sarcasm; no danger of misinterpretation here . . . :) On 2003-01-16 at 10:01:04, Michael Lazzaro wrote: Well, I don't know about anyone else, but *I'm* planning on making many, many Unicode synonyms, to make my code shorter and more readable. For example, Cfor is too long, so I want to just make it curly-f, (ƒ). And Cwhen is even longer, so I'm going to use something else, probably lowercase omega (ω). The numbers-in-a-circle characters can be used for array options. Instead of @array[3], I'll be saying @array➌. And @array③ will mean every element of the array except for the third. I'm still looking for the Unicode sad-faced-clown-on-fire character. When I find it, I think I'm gonna make it mean Cshift. Well, that or Cunshift, I can't decide. It depends on how sad the clown looks. MikeL -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Michael Lazzaro [EMAIL PROTECTED] wrote: Well, I don't know about anyone else, but *I'm* planning on making many, many Unicode synonyms, to make my code shorter and more readable. For example, Cfor is too long, so I want to just make it curly-f, (Æ). And Cwhen is even longer, so I'm going to use something else, probably lowercase omega (Ï). The numbers-in-a-circle characters can be used for array options. Instead of @array[3], I'll be saying @arrayâzcaron. And @array⢠will mean every element of the array except for the third. I'm still looking for the Unicode sad-faced-clown-on-fire character. When I find it, I think I'm gonna make it mean Cshift. Well, that or Cunshift, I can't decide. It depends on how sad the clown looks. MikeL I think this is a great idea. Until now, it's been possible to read other people's code, so companies can fire a programmer and still have people who can read their code. Now employees will be able to be as bad as they want and nobody will be able to fire them. Job security through Unicode! (Yes, that was sarcasm.) __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Mr. Nobody [EMAIL PROTECTED] wrote: --- Michael Lazzaro [EMAIL PROTECTED] wrote: Well, I don't know about anyone else, but *I'm* planning on making many, many Unicode synonyms, to make my code shorter and more readable. For example, Cfor is too long, so I want to just make it curly-f, (Æ). And Cwhen is even longer, so I'm going to use something else, probably lowercase omega (Ï). The numbers-in-a-circle characters can be used for array options. Instead of @array[3], I'll be saying @arrayâzcaron. And @array⢠will mean every element of the array except for the third. I'm still looking for the Unicode sad-faced-clown-on-fire character. When I find it, I think I'm gonna make it mean Cshift. Well, that or Cunshift, I can't decide. It depends on how sad the clown looks. MikeL I think this is a great idea. Until now, it's been possible to read other people's code, so companies can fire a programmer and still have people who can read their code. Now employees will be able to be as bad as they want and nobody will be able to fire them. Job security through Unicode! (Yes, that was sarcasm.) Argh, I just realized the original was probably sarcastic too. Now I look like an idiot. Well, moreso than before. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
[EMAIL PROTECTED] (Mr. Nobody) writes: Argh, I just realized the original was probably sarcastic too. Now I look like an idiot. Well, moreso than before. There has been more than a touch of sarcasm about nearly every post in this thread in the last two days. -- So i get the chance to reread my postings to asr at times, with a corresponding conservation of the almighty leviam00se, Kai Henningsen. -- Megahal (trained on asr), 1998-11-06
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Mr. Nobody [EMAIL PROTECTED] wrote: --- Austin Hastings [EMAIL PROTECTED] wrote: --- Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. It's very much like the good old days of trigraphs. But on the plus side, once all the losers get their fonts/xterms/editors up-to-speed on extended character sets, the trigraphs will die a forgotten death. Oh, glorious future ... =Austin How about people who can't? Lots of people don't own the computer they're using, so to upgrade stuff they'd have to ask the sysadmin. And you know what happens when you annoy the sysadmin... You remember that stoner kid who always sat at the back of the class and pretty much C/D/F'ed every class? That's what trigraphs are for -- the middle-to-bottom of the curve. If you can't upgrade, and your admin won't upgrade, then you learn to use the trigraphs. Right now almost all of us are in that boat. And we're talking about trigraph ops, like ~ and ~ and |~ and [+=] and whatever. As we get better, more Unicapable, whatever, we'll move on to full Unicode ops. Look at MIME -- once, the only way to email a binary file was with uuencode. A few short years later, presto! Every pinhead in the marketing department is attaching 4 gigabyte pdf files to their corporate spam. It's the same thing -- if people want to do something, and can benefit from it, then they'll drive it to happen. Think about what would have happened if someone argued that NO files should be binary, because we couldn't email binary files -- there'd be no downloadable internet porn. :-( A vote for Unicode is a vote for naked chicks! Go us! =Austin
Re: (AUTORESPONSE)Re: L2R/R2L syntax (was Re: Everything is an object.)
Whoever is working for qlcomm.com tech support and subscribed from work should probably unsubscribe and use a personal account, unless your boss wants 20+ messages per day coming in to your corporate mailbox. --- Administrator [EMAIL PROTECTED] wrote: Dear Customer, Your query has been received. Our Tech Support team will be reverting to you within 8 business hours (India time). You can chat with our Tech Support team via Yahoo Messenger Our ID is qlc_tech. we are online on all working days 9:30 a.m. to 6:30 p.m. (Indian Standard Time) As a long term solution, you could also consider purchasing an Annual Maintainence Contract. PostMaster is supported onsite in over 60 Indian cities. Thank you. At your service, PostMaster Tech Support. QuantumLink Communications Pvt. Ltd. +91 22 24986445-50 CONFIDENTIALITY NOTICE: If you have received this e-mail in error, please immediately notify the sender by e-mail at the address shown. This e-mail transmission may contain confidential information. This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance. -- QuantumLink Communications Pvt Ltd, Bombay, India
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Austin Hastings [EMAIL PROTECTED] wrote: --- Mr. Nobody [EMAIL PROTECTED] wrote: --- Austin Hastings [EMAIL PROTECTED] wrote: --- Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. It's very much like the good old days of trigraphs. But on the plus side, once all the losers get their fonts/xterms/editors up-to-speed on extended character sets, the trigraphs will die a forgotten death. Oh, glorious future ... =Austin How about people who can't? Lots of people don't own the computer they're using, so to upgrade stuff they'd have to ask the sysadmin. And you know what happens when you annoy the sysadmin... You remember that stoner kid who always sat at the back of the class and pretty much C/D/F'ed every class? That's what trigraphs are for -- the middle-to-bottom of the curve. If you can't upgrade, and your admin won't upgrade, then you learn to use the trigraphs. Right now almost all of us are in that boat. And we're talking about trigraph ops, like ~ and ~ and |~ and [+=] and whatever. As we get better, more Unicapable, whatever, we'll move on to full Unicode ops. Look at MIME -- once, the only way to email a binary file was with uuencode. A few short years later, presto! Every pinhead in the marketing department is attaching 4 gigabyte pdf files to their corporate spam. It's the same thing -- if people want to do something, and can benefit from it, then they'll drive it to happen. Think about what would have happened if someone argued that NO files should be binary, because we couldn't email binary files -- there'd be no downloadable internet porn. :-( A vote for Unicode is a vote for naked chicks! Go us! =Austin trigraphs are actually better, even if you are unicode capable. ~ is far easier to type than ctrl-u-15F9E2A01 or whatever it is. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
On 2003-01-16 at 16:42:15, Buddha Buck wrote: [Note: I originally sent this to Mr. Nobody alone, but that wasn't my intent. I'm re-sending it here, where I wanted it to go in the first place. -- bmb] This came in with a content type text/plain, charset=us-ascii. US-ASCII is by definition 7 bits only, so if you're planning on sending Latin-1 accented characters, or UTF-8, or anything else that requires that 8th bit not to be stripped and assumed 0, your email program has to set the headers properly. Doesn't matter what it looks like in your outbox; all the transfer points along the way have to know how to treat the contents, too. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: optimising, and per file flags
On Mon, Jan 13, 2003 at 09:22:07AM -0800, Steve Fink wrote: On Jan-12, Nicholas Clark wrote: IIRC Leo added an option to Configure.pl to turn on optimising. Prior to this, on IRC Dan said to me that we need to avoid the hack that perl5 found itself in, when it had to retro-fit the ability to change the compiler flags per file. Would it be better to do it the other way around? We could put a marker at the end of each source file (mixed in with the emacs/vi flag section?) that specifies a set of compiler flags (or nothing at all if the default is ok.) If so, then I'd probably also use named sets (big-jumptable-flags) or maybe even named modifiers (default but violates-aliasing and trips-gcc2.95-O3-bug). This would allow better descriptions of why the flags were being modified, and allow each compiler to deal with the situation differently (for violates-aliasing, gcc would add -fno-strict-aliasing, lcc wouldn't do anything.) I don't think that this will fly. The sort of flags we need to change are things like this (Unicos): if /etc/cpu -i | grep -q cfp then ccflags=$ccflags -h rounddiv fi # Avoid an optimizer bug where a volatile variables # isn't correctly saved and restored --Mark P. Lutz pp_ctl_cflags='ccflags=$ccflags -h scalar0 -h vector0' # Otherwise the unpack %65c checksums will fail. pp_pack_cflags='optimize=$ccflags -h scalar0 -h vector0' or this (Irix 6, based on a test of compiler version) # workaround for an optimizer bug # Made to work via UU/config.sh thing (or, rather, config.sh, since we're in # a callback) from README.hints, plus further stuff; doesn't handle -g still, # unfortunately - Allen case `$cc -version 21` in *7.2.*) test -z $op_cflags echo op_cflags=\optimize=$optimize -O1 config.sh test -z $op_cflags op_cflags=optimize=\\$optimize -O1\ test -z $opmini_cflags echo opmini_cflags=\optimize=$optimize -O1 config.sh test -z $opmini_cflags opmini_cflags=optimize=\\$optimize -O1\ ;; *7.3.1.*) test -z $op_cflags echo op_cflags=\optimize=$optimize -O2 config.sh test -z $op_cflags op_cflags=$op_cflags optimize=\\$optimize -O2\ test -z $opmini_cflags echo opmini_cflags=\optimize=$optimize -O2 config.sh test -z $opmini_cflags opmini_cflags=optimize=\\$optimize -O2\ ;; esac and other evil to work round compiler bugs found mainly by sweating blood. (I don't know about the Irix bugs, but I do remember that working out what the cause of Unicos bugs were wasn't fun. And I was mostly following along at home by e-mail, not being able to offer Mark much more than moral support. When unpack is going into an infinite loop on a Cray 6000 miles away that you don't have any access to, there isn't much more you can do) I'm assuming the Configure system extracts the information from the source files and generates a makefile entry per source file with the appropriate compiler flags. I'm also assuming a makefile entry for all source files with non-default compiler flags, and a .c$(OBJ_EXT): rule for the default So I'm thinking that we'll have a lot of per platform compiler specific cruft that will need to be generalised programatically. But more importantly we need a way for anyone to manually configure parrot with wacky flags for a single file. Otherwise responses to perl6bug are going to be along the lines of edit the section in the source file, and add a new (complex) rule that will trigger on your platform. Then reconfigure. Then check the Makefile to see if that rule really did trigger. Nicholas Clark
[CVS ci] eval #1
So I did it. Check in the first version of eval. First of all, I changed pdd06_pasm, the compile and compreg opcodes didn't fit really well into - well - my scheme of objects. A compiler is now a Parrot class, derived from NCI, living in interpreter-Parrot_compreg_hash. This also needed a change to the NCI code. Parrot_new_nci() is gone, the way to go now is: create a new NCI/Compiler object and then call its set_string_keyed() method to set the start address and the signature. This is somewhat hackish but consistent with Sub.pmc's set_integer() call to set the address of a parrot sub. Please, have a look at the changes in core.ops and interpreter.c for the construction of these objects. A parrot interpreter class would fit in this scheme too - and it allows for early anchoring the PMC. The return value of a compile call is currently - due to the lack of byte code segments - a plain pointer to the generated code. For PDB_compile() this is a static variable space, meaning: you should invoke this code before compiling new one. For imcc the code gets appended to the code-byte_code of the interpreter, which might cause reallocation and segfaults, when returning from the evaled code. So this code is not really usable until multiple code segments are done too. Test status: make test succeeds, as well as -P, running the eval progs with JIT or with -t (trace)/-b (bounds) option fails, probably related to messing with the byte code. Imcc notes: As the evaled code runs in its own runloop it must be terminated with an 'end' opcode. Imcc could provide one if needed. Missing and left for an exercise for Joe Other Parrothacker: build_nativecall.pl lacks to handle an 'I' signature type, the interpreter should be pushed on the stack. Also the signature pIt is missing. So eval runs only on jit/i386 now. Finally: please do a make realclean after checkout. Have fun leo PS diffstat: MANIFEST |2 classes/csub.pmc |2 classes/default.pmc| 19 - classes/nci.pmc| 30 -- classes/sub.pmc|5 core.ops | 35 ++ debug.c| 22 + docs/pdds/pdd06_pasm.pod | 18 + dod.c |2 include/parrot/debug.h |1 include/parrot/interpreter.h |2 include/parrot/method_util.h |1 interpreter.c | 40 +++ jit/i386/jit_emit.h|3 languages/imcc/imcc.l |7 languages/imcc/imclexer.c | 421 - languages/imcc/main.c |2 languages/imcc/parser.h|3 languages/imcc/parser_util.c | 75 + languages/imcc/pbc.c | 17 - method_util.c | 18 - parrot-leo/languages/imcc/t/syn/eval.t | 39 +++ parrot-leo/t/pmc/eval.t| 42 +++ 23 files changed, 521 insertions(+), 285 deletions(-)
RE: pretty pictures
I have a Perl program that processes Perl source and generates fake C++ headers that doxygen will process. Doxygen doesn't have a hook for adding a new parser, so this is the only way to hack it. The doxygen way of doing things depends pretty heavily on special comments. My doxygen hack pulls a lot of stuff automatically _without_ special comments, but is highly dependent on my coding style. I can only recommend it as an example, it's not like supported or anything. Having said all that, I am in fact a fan of doxygen. I find it in use all the time on various open source projects. mma -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 5:30 PM To: [EMAIL PROTECTED] Subject: pretty pictures I was playing with doxygen (www.stack.nl/~dimitri/doxygen/index.html) (think javadoc for C++) and thought I'd pass along some random pictures. Doxygen unfortunately doesn't handle perl code, and even has problems with parrot's C. (IMHO, the world needs a wrapper hack which allows you to run all these variously broken code analysis tools, and then gloms their outputs together into something browsable. Ah well. Todo list.) Attached are the interpreter.h include tree, and the PMC and Arena datastructure graphs. (Why not Interp? See previous paragraph). GraphVis (www.graphviz.org) did the actual drawing. Hmm. Maybe a picture of the complete include graph would be useful introductory material... Mitchell
is, has, and does (more object stuff)
I still have most of yesterday's p6i mail to dig through (and probably won't until this evening), but one thing that's struck me (courtesy of an ill-timed grumble about objects) is that there are really three ways to do inheritance, and most languages sort of do them, with varying amounts of dancing around. The three, as I see it, are: *)is - The standard parent/child thing, where the derived class is a more specialized version of the parent class. This seems to be a fallback mechanism when others might be more appropriate. This is done with straight inheritance. *)has - This is the container/delegation thing, where a class isn't really a more specialized version of another class, but instead a container of sorts. This is done via delegation. *)does - This is the interface/guaranteed behaviour thing, where a class just promises that it has a certain set of methods Everyone does them all in half-hearted ways, but I'm thinking we need to formally support all three, since it'll make doing things properly easier. (And if a language has built-in hacks to do one of them another way, that's fine--we don't have to fix that, they just won't get the engine advantages) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: pretty pictures
The ability to download autodia off of the primary site and the mirror is unfortunately broken. -Tupshin James Michael DuPont wrote: --- Mitchell N Charity [EMAIL PROTECTED] wrote: Doxygen unfortunately doesn't handle perl code, and even has problems with parrot's C. You might be interested in autodia, it handles perl. http://droogs.org/autodia/ (IMHO, the world needs a wrapper hack which allows you to run all these variously broken code analysis tools, and then gloms their outputs together into something browsable. Ah well. Todo list.) The goal of the introspector is to publish a RDF/XML ontology of the various systems and thier dumps. Then you can merge the ontologies on a logical level and transform them between each other. Well what exactly do you need? I will be looking in running the introspector over the parrot code. That will produce a rdf file of the entire parrot source code. I would like to also figure out how to extract the high-level infomration from perl. The next step for the introspector was B::ToXML and to get that running. But for Perl6, i wonder what that best way to get at the data? The assembler does not contain any high level information. GraphVis (www.graphviz.org) did the actual drawing. Yes, that is on major goal of the introspector project to replace this funky non-free graphvis with the VCG. I hope to port VCG to GTK this year, and integrate it with DIA for a nice graph editor. http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html Hmm. Maybe a picture of the complete include graph would be useful introductory material... the graphs you doxygen produces are great. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
[perl #20355] [PATCH] Incorrect ifdef nesting in cpu_dep.c
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #20355]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=20355
I don't think the ifdef logic is quite right in cpu_dep.c. Specifically,
if either __sparc or __ia64__ is defined, then *both* the cpu-dependent
register flushing *and* the setjmp-using register flushing tricks are
used.
This actually shows up as a syntax error on the frivolous tinderbox.
The enclosed patch changes the logic to what I suspect was actually
intended.
--- parrot-current/cpu_dep.cSat Jan 4 03:00:09 2003
+++ parrot-andy/cpu_dep.c Thu Jan 16 13:49:32 2003
@@ -26,7 +26,7 @@
trace_system_areas(struct Parrot_Interp *interpreter)
{
-#ifdef __sparc /* Flush register windows */
+#if defined(__sparc) /* Flush register windows */
static union {
int insns[4];
double align_hack[2];
@@ -42,10 +42,8 @@
static void (*fn_ptr)(void) = (void (*)(void))u.align_hack[0];
fn_ptr();
-#endif
-
-#ifdef __ia64__
+#elif defined(__ia64__)
struct ucontext ucp;
void *current_regstore_top;
--
Andy Dougherty [EMAIL PROTECTED]
Re: [perl #20355] [PATCH] Incorrect ifdef nesting in cpu_dep.c
At 7:29 PM + 1/16/03, Andy Dougherty (via RT) wrote: The enclosed patch changes the logic to what I suspect was actually intended. Applied, thanks. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [CVS ci] eval #1
Leopold Toetsch wrote: So I did it. Check in the first version of eval. Test status: make test succeeds, as well as -P, running the eval progs with JIT or with -t (trace)/-b (bounds) option fails, probably related to messing with the byte code. Fixed. bug in -j was triggered by garbage memory in the opcode lookup hash bug with -b/-t was due to wrong/missing bounds of the eval code segment leo
[perl #20358] [BUG] disassemble still
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #20358]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=20358
disassemble sometimes takes huge amounts of mem and dies.
I'm using disassemble to get a test coverage of ops with this shell script:
#!/bin/sh
# op-stat
DIS=disassemble
[ -e .op-list1 ] rm .op-list1
[ -e op-list-all ] rm op-list-all
[ -e op-list-s ] rm op-list-s
find . -name '*.pbc' -fprint /dev/stderr -exec $DIS {} \; |
sed -e's/^[[:blank:]]*L[0-9]*://' | \
sed -e's/^[[:blank:]]+//' | cut -d\ -f1 .op-list1
sort .op-list1 | uniq -c | sort -rg op-list-all
sort .op-list1 | sed -e's/_.*//' | uniq -c | sort -rg op-list-s
echo
T=`grep NAME lib/Parrot/OpLib/core.pm | wc -l`
S=`grep NAME lib/Parrot/OpLib/core.pm | sort | uniq | wc -l`
echo total ops $T
echo ops types $S
echo op usage stat
wc -l op-list* | head -2
