Re: What will the Perl6 code name be?

On Mon, Oct 23, 2000 at 08:27:52PM -0400, Dan Sugalski wrote: > At 12:33 AM 10/24/00 +0100, Simon Cozens wrote: > >On Mon, Oct 23, 2000 at 03:40:26PM -0700, Peter Scott wrote: > > > >Don't forget that those BEGIN blocks are *supposed* to be instructions > > > >to the compiler. > > > > > > Er, but

Re: TIL redux (was Re: What will the Perl6 code name be?)

Uri Guttman <[EMAIL PROTECTED]> writes: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > DS> At 12:48 AM 10/24/00 +0100, Simon Cozens wrote: > >> On Mon, Oct 23, 2000 at 05:18:15PM -0400, Uri Guttman wrote: > >> > basically the emitted machine code for TIL is very simplified C

Re: What will the Perl6 code name be?

On 23 Oct 2000, at 15:40, Peter Scott wrote: > At 09:54 PM 10/23/00 +0100, Simon Cozens wrote: > >On Mon, Oct 23, 2000 at 04:38:12PM -0400, Dan Sugalski wrote: > > > Runtime string eval, do, and require are a serious pain in the butt. > > > They're the one set of things that'll force a real inter

new to perl

Hi, I have this perl script that grabs new information from GuardianUnlimited site. But the problem is that I get an internal server error and as I am new to this I have no idea what it means. I tried the error log file but I cannot understand anything there. The error is "Internal Server Err

Re: Perl6 the platform-dependent bits...

On Tue, Oct 24, 2000 at 01:11:21AM -0400, Dan Sugalski wrote: > I like the idea of returning multiple results in multiple registers. Pity > nothing on the planet could link to us if we did that... :( not quite. On the ARM compiler [targeted at arm chips :-)] if you declare a function __value_in_

Re: TIL redux (was Re: What will the Perl6 code name be?)

Ariel Scolnicov <[EMAIL PROTECTED]> writes: [ A bunch of stuff ] Er, chaps, not wishing to tread on Skud's moderatorial toes and all, but shouldn't all this be in perl6-internals? Reply-To: set. -- Piers

Re: My reading list

On Mon, Oct 23, 2000 at 06:25:44PM -0700, Ask Bjoern Hansen wrote: > :-) For those who haven't read them the Steve Maguire books are > really really good. Hallo, no matter what you think of the software > they shrinkwrap and sell they must (as a huge software company) have > thought quite a bit a

Re: What will be the Perl6 code name ?!!

> What will be the Perl6 code name ? ]- OK what about Velociraptor ;") - It is animal - continuing the tradition ... - it is one of the CLEVEREST dinos. (only truodont!! is thought that is clever) - it is PREDATOR - will hunt all other "languages" - small - little bigger than human ... (leane

Re: What will the Perl6 code name be?

At 01:10 PM 10/24/00 +0200, Philip Newton wrote: >On 23 Oct 2000, at 15:40, Peter Scott wrote: > > What about introducing a pragma which either (a) promises not to use such > > things, or (b) throws an exception if the program does use such > constructs, > > and say "if you want your programs to

Re: new to perl

[ Cc'd to OP ] On Tue, Oct 24, 2000 at 12:00:48PM +0100, Ajdin Brandic wrote: > I have this perl script Your message is completely off-topic on this mailing list. Please do not abuse mailing lists like that. This mailing list is for discussion of Perl *6* (note the mailing list name). Pe

Re: My reading list

Nicholas Clark wrote: > > On Mon, Oct 23, 2000 at 06:25:44PM -0700, Ask Bjoern Hansen wrote: > > :-) For those who haven't read them the Steve Maguire books are > > really really good. Hallo, no matter what you think of the software > > they shrinkwrap and sell they must (as a huge software comp

Re: new to perl

On Tue, Oct 24, 2000 at 03:35:31PM +0100, Ajdin Brandic wrote: > Uff! > > How are you feeling now? Has your anger gone or is still there? > Why is there a mailing list for perl6 up and running before the version is > out? To co-ordinate efforts to develop it. > Why is it when you check for per

Re: new to perl

On Tue, Oct 24, 2000 at 03:35:31PM +0100, Ajdin Brandic wrote: > Uff! > > How are you ^^^ Off-topic correspondence directed at an individual should be sent to the individual, not to the mailing list. You have (twice!) wasted the time of hundreds of busy people. I ask you again to p

Re: TIL redux (was Re: What will the Perl6 code name be?)

Uri Guttman wrote: > if i want TIL and lose builtin overloading, that is > a fine tradeoff to me. No, no, no! That is one of the things that absolutely must be fixed in the next major version of Perl! -- John Porter

Re: TIL redux (was Re: What will the Perl6 code name be?)

> "JP" == John Porter <[EMAIL PROTECTED]> writes: JP> Uri Guttman wrote: >> if i want TIL and lose builtin overloading, that is >> a fine tradeoff to me. JP> No, no, no! That is one of the things that absolutely must be JP> fixed in the next major version of Perl! i was referrin

Re: Perl6 the platform-dependent bits...

At 10:22 AM 10/24/00 +0100, Nicholas Clark wrote: >On Tue, Oct 24, 2000 at 01:11:21AM -0400, Dan Sugalski wrote: > > I like the idea of returning multiple results in multiple registers. Pity > > nothing on the planet could link to us if we did that... :( > >not quite. On the ARM compiler [targeted

RE: new to perl

Uff! How are you feeling now? Has your anger gone or is still there? Why is there a mailing list for perl6 up and running before the version is out? Why is it when you check for perl mailing lists on perl.com only mailing lists for perl6 come up? Thanks Ajdin -Original Message- From:

Re: new to perl

On Tue, Oct 24, 2000 at 03:35:31PM +0100, Ajdin Brandic wrote: > Uff! Da. > Why is there a mailing list for perl6 up and running before the version is > out? Someone's gotta *write* it. I hear there's a mailing list for Linux 2.4. -- I _am_ pragmatic. That which works, works, and theory can g

RE: new to perl

Today around 3:35pm, Ajdin Brandic hammered out this masterpiece: : How are you feeling now? Has your anger gone or is still there? Tad is feeling fine, I'm sure. Unless he doesn't like your quoting style ;-) : Why is there a mailing list for perl6 up and running before the version is : out?

[not quite an RFC] shared bytecode/optree

Firstly, by "bytecode" I mean a .pmc and by "optree" I mean the perl6 VM's internal form that it goes through executing. It seems to me that one thing that the perl6 bytecode implementation _should_ do (in the interests of being light and fast, as well as meshing well with MT) is be position-inde

Re: [not quite an RFC] shared bytecode/optree

On Tue, Oct 24, 2000 at 04:41:38PM -0700, Benjamin Stuhl wrote: > It seems to me that one thing that the perl6 bytecode > implementation _should_ do (in the interests of being light > and fast, as well as meshing well with MT) is be > position-independant. Fancy offering a patch to RFC310? -- I

Recommended Reading List Updated

Hello, I just finished updating the Perl Recommended Reading list. Have a look: http://www.perldoc.com/readinglist.pl Things to Note: 1. Added Nathan's books to the list (thanks Nat) 2. Added a link to the Perl6 Mailinglists Archive (as suggested by Ask) 3. Added a 'why??' link to each book tha

Re: Special syntax for numeric constants [Was: A tentative list of vtable functions]

Ken Fox <[EMAIL PROTECTED]> wrote: > David Mitchell wrote: > > Now of course if we have the luxury of deciding that core perl 'knows' > > about complex numbers, then of the parser can be made to recognise ... > > The core doesn't need to know -- that was my point. All the core needs > is the bas

Re: Special syntax for numeric constants [Was: A tentative list of vtable functions]

At 02:34 PM 10/24/00 +0100, David Mitchell wrote: >Ken Fox <[EMAIL PROTECTED]> wrote: > > David Mitchell wrote: > > > Now of course if we have the luxury of deciding that core perl 'knows' > > > about complex numbers, then of the parser can be made to recognise ... > > > > The core doesn't need t

Re: Threaded Perl bytecode (was: Re: stackless python)

> "AT" == Adam Turoff <[EMAIL PROTECTED]> writes: >> Wouldn't just the appearance of *foo = \&other_foo, be enough to tell >> the compiler to treat all foo's (or perhaps if there were some dataflow >> analysis some region of code) to use indirection? AT> You're forgetting eval "*foo = \&othe

Re: Threaded Perl bytecode (was: Re: stackless python)

> "JvV" == John van V <[EMAIL PROTECTED]> writes: JvV> If this is the case, the code underlying the treading would utilize normal functions to poll the concurrent event streams and programmers could JvV> choose between the threads and functions depending on their levels of comfort. JvV> Th

Threads vs. Threaded Inlince code (was Re: Threaded Perl bytecode)

along the lines of a perl6 project code name, we run into the name collision of process threads and threaded inline code (TIL). these 2 concepts have nothing to do with each other other than overloading the same word. please be clear which one you are refering to when unless your post is in an em

Re: Acceptable speeds (was Re: TIL redux (was Re: What will thePerl6 code name be?))

Most of the time, perl's performance is a total non-issue for me. When it is, I'm generally doing the same things as Dan (ie, things resembling dd if=/dev/hda | perl -e ...). I posted some vague benchmarky ideas to perl6-meta at one point. Here they are again: - You did ask at one point for

RE: Perl6 the platform-dependent bits...

From: Garrett Goebel > From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > > (Though if someone comes up with a way to make the > > platform-dependent bits really small and isolated I'm all for it) > [mention of C--] > > From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > > I do

Re: Threaded Perl bytecode (was: Re: stackless python)

This thread seems to be winding down fttb**, Judging from the below, perl multithreading [ I am guessing ] is simply syntatic sugar much the same as Koch C++ is a wrapper for regular cc compiler. This sounds nice, > Threading Perl bytecode would be nice about 98% of the time, and > sho

Re: Perl6 the platform-dependent bits...

On Tue, Oct 24, 2000 at 02:52:53PM -0500, Garrett Goebel wrote: > > It's a good idea, but it really Isn't There Yet. > > Fair enough... Hey, I'm not Dan. There should have been big tags around that previous mail. -- God gave man two ears and one tongue so that we listen twice as much as we s

RE: Perl6 the platform-dependent bits...

From: John Porter [mailto:[EMAIL PROTECTED]] > > Garrett Goebel wrote: > > > > I'm sure you won't be surprised by this, but I recall John > > Porter as being a C-- fan. Now why is he being mysteriously silent? > > Nope, wasn't me. Never heard of it until someone brought it > up earlier. I do

Re: Perl6 the platform-dependent bits...

At 09:08 PM 10/24/00 +0100, Simon Cozens wrote: >On Tue, Oct 24, 2000 at 02:52:53PM -0500, Garrett Goebel wrote: > > > It's a good idea, but it really Isn't There Yet. > > > > Fair enough... > >Hey, I'm not Dan. There should have been big tags around that >previous mail. Luckily for me, I am. (I

Re: Perl6 the platform-dependent bits...

On Tue, Oct 24, 2000 at 12:54:26PM -0500, Garrett Goebel wrote: > Everyone seems to have their favorite laundry list of the failings of C, and > an accompanying list of complex and/or fragile solutions. I'm coming to the rapid conclusion that C-- is yours. (complicated and fragile solution.) Whi

RE: Perl6 the platform-dependent bits...

From: Simon Cozens [mailto:[EMAIL PROTECTED]] > > On Tue, Oct 24, 2000 at 12:54:26PM -0500, Garrett Goebel wrote: > > Everyone seems to have their favorite laundry list of the > > failings of C, and an accompanying list of complex and/or > > fragile solutions. > > I'm coming to the rapid concl

Re: Perl6 the platform-dependent bits...

Garrett Goebel wrote: > > I'm sure you won't be surprised by this, but I recall John > Porter as being a C-- fan. Now why is he being mysteriously silent? Nope, wasn't me. Never heard of it until someone brought it up earlier. I do admit, it sounds intriguing. > I just wanted to mention it, a

Re: new to perl

Simon Cozens wrote: > > I hear there's a mailing list for Linux 2.4. The mosix people regularly look forward to having their feature set experimentally included in linux 2.7 -- David Nicol 816.235.1187 [EMAIL PROTECTED] At some level, e

Re: Threaded Perl bytecode (was: Re: stackless python)

On Tue, Oct 24, 2000 at 10:55:29AM -0400, Chaim Frenkel wrote: > I don't see it. > > I would find it extremely akward to allow > > thread 1: *foo = \&one_foo; > thread 2: *foo = \&other_foo; > [...] > > copy the &foo body to a new location. > replace the old