Hello everyone,
(Please correct me if this is the wrong list for my proposal.)
I was wonder if it would be possible / usefull to add a hibernation
functionality to the Perl 6 Language, possibly via a Module.
(but the core would have to provide the needed low level functions)
"Hibernate" would s
Hi, All.
Configure.pl 2.0 does not want run on Win32 (windows NT 4.0, AcrivStatPerl
5.6.1, VC 6).
Prior version ask me: what linker I want use.
This do not ask, and variable $ld is undefined (module
parrot/lib/Parrot/Configure/Step.pm, sub cc_build).
Best regards, Nick.
Nick Kostirya wrote:
> Prior version ask me: what linker I want use.
> This do not ask, and variable $ld is undefined (module
> parrot/lib/Parrot/Configure/Step.pm, sub cc_build).
Have you tried
configure.pl --ask
?
--
Sebastian Bergmann
http://sebastian-bergmann.de/
Nick Kostirya:
# Configure.pl 2.0 does not want run on Win32 (windows NT 4.0,
# AcrivStatPerl 5.6.1, VC 6). Prior version ask me: what linker
# I want use. This do not ask, and variable $ld is undefined
# (module parrot/lib/Parrot/Configure/Step.pm, sub cc_build).
Configure now doesn't ask que
> Configure now doesn't ask questions by default. You can tell it to ask
> questions by passing in the "--ask" switch on the command line. You can
> also tell it the linker's name directly by passing in
> "--ld=(linker-name)".
Oh.
Sorry to trouble you.
It's inattention.
Thank you very much.
(Please CC me on replies)
I don't often express many opinions on Perl 6 these days, but I feel I have to
warn people about what I see as a potential loss of direction.
I'm becoming somewhat disillusioned with Perl 6 these days; sometimes because
it's too radical, more often than not because it's
> The binary image should represent the interpreters
> internal state and the compiled bytecode, as straight
> as possible.
Internal state is a problem.
> example:
>
> if (my $binary = hibernate) {
> print "Feelin sleepy... Good Night.";
> save_to_disk($binary, "~/myscript.pl.sleeps");
>
Folks,
I've checked a draft copy of Apocalypse 5 into the repository. It'll
get yanked once the final is released (and I think we may start
checking in the final apocalypses and exegeses, but that's for later)
but it's there now.
Please note: This is so we can start writing the regex parser.
*** core.ops.~1.146.~ Tue Jun 4 11:55:32 2002
--- core.opsTue Jun 4 14:18:31 2002
***
*** 739,745
MAKE_KEY(key, $2, enum_key_int, int_val);
! $1->vtable->set_pmc_keyed(interpreter, $1, &key, $3, NULL);
goto NEXT();
}
--- 739,745
MAK
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.60
diff -u -r1.60 assemble.pl
--- assemble.pl 3 Jun 2002 23:22:45 - 1.60
+++ assemble.pl 4 Jun 2002 13:56:25 -
@@ -662,6 +6
On Tue, Jun 04, 2002 at 10:43:02AM +0100, Simon Cozens wrote:
> (Please CC me on replies)
>
> I don't often express many opinions on Perl 6 these days, but I feel I have to
> warn people about what I see as a potential loss of direction.
>
> I'm becoming somewhat disillusioned with Perl 6 these
Cross-posted to p6l and cardinal.
Parrot Intermediate Compiler (or Intermediate Representation)
See parrot/languages/imcc
Just another round of commits, supporting more directives and
instructions. Correctly handling indexed use of strings ala:
str[0] = "A"
ch = str[0]
Will have this working
Dave Mitchell:
> > (Please CC me on replies)
Actually, now I come to think of it, please don't CC on replies. One thing I
really hated about Perl 6 was the number of people sniping from the sidelines
providing no useful contribution. And now I've become one. Urgh.
> One word: CPAN.
I understand
Dan Sugalski:
# I've checked a draft copy of Apocalypse 5 into the repository. It'll
# get yanked once the final is released (and I think we may start
# checking in the final apocalypses and exegeses, but that's for later)
# but it's there now.
#
# Please note: This is so we can start writing
Simon Cozens:
# I'm becoming somewhat disillusioned with Perl 6 these days;
# sometimes because it's too radical, more often than not
# because it's not radical enough, and quite often because it's
# more than a year behind schedule and still slipping. But that
# last point is by the by; with
On 6/4/02 8:13 AM, "Simon Cozens" <[EMAIL PROTECTED]> claimed:
> Yes, there's a lot of legacy crap out there. Much of the important parts of it
> are XS, which we can't hope to support. (No, Dan, be realistic) So, let's go
> through the CPAN argument:
Personally, I'm still really jazzed about
On Tue, Jun 04, 2002 at 04:13:36PM +0100, Simon Cozens wrote:
Hmm, June 4. Independence day, with an off by 1 error. Must be a C
program involved somewhere. :-)
In brief, I'm with Damien on this one. IMHO C++ is an ugly bastard of
a programming language because they cut the cord ineffective
On Tue, 4 Jun 2002, Simon Cozens wrote:
: Dave Mitchell:
: > > (Please CC me on replies)
:
: Actually, now I come to think of it, please don't CC on replies. One thing I
: really hated about Perl 6 was the number of people sniping from the sidelines
: providing no useful contribution. And now I'
Steve Simmons:
> We have said that perl5 will be *mostly* mechanically translatable into
> perl6.
And we shall keep saying this until we believe that it is true?
--
Hubris is when you really do have it, enough so only the gods slap you
down. Pretentiousness is when you don't have it, and everyo
On Tue, Jun 04, 2002 at 05:40:08PM +0100, Simon Cozens wrote:
> Steve Simmons:
> > We have said that perl5 will be *mostly* mechanically translatable into
> > perl6.
> And we shall keep saying this until we believe that it is true?
*grin*
My apologies for using the wrong name, Simon. Doh!
--
On Tue, 4 Jun 2002, Simon Cozens wrote:
: Steve Simmons:
: > We have said that perl5 will be *mostly* mechanically translatable into
: > perl6.
:
: And we shall keep saying this until we believe that it is true?
No, we'll keep saying this until we make it true. Faith without
works is dead.
La
On Tue, 4 Jun 2002, Simon Cozens wrote:
> Steve Simmons:
> > We have said that perl5 will be *mostly* mechanically translatable into
> > perl6.
>
> And we shall keep saying this until we believe that it is true?
As a Perl user (the kind of guy who uses Perl at work for everything
humanly possibl
On 6/4/02 12:22 PM, David Wheeler wrote:
> I think that if we can agree to forego backwards compatibility, we might
> also be in a better position to set up a CP6AN with much better quality
> control. All of the most important modules will be ported very quickly
> (e.g., the DBI), and a lot of the
On Tue, 4 Jun 2002, Dave Mitchell wrote:
> Having said that, I have real, real doubts that Perl 6 will ever be able
> to execute Perl 5 code natively. Its not just a case a writing a new
> parser and some P5-specific ops; P5 has so many special features, boundary
> conditions and pecularies, that
Larry Wall:
> That's exactly what I've been arguing for all along. Grr
Thank you. Now I'm somewhat less concerned. And that makes the implementation
much easier. It was just when people were saying that the parser needed to
be sufficiently flexible to parse both languages that I got the heeb
On 6/4/02 9:59 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed:
> 1b. 6PAN modules comply with an informal contract to maintain
> backward-compatibility within all N.MM versions, where N is constant. In
> other words, incompatible API changes are only allowed by incrementing the
> "major version
On 6/4/02 12:34 PM, Steve Simmons wrote:
> As for CPAN . . . don't get me started. CPAN is a blessing, but has
> become a curse as well. It's contents need to be razed to the ground
> and better/more conistant rules set up for how to do installations
> into and out of the standard trees. If you
On 6/4/02 1:11 PM, David Wheeler wrote:
> On 6/4/02 9:59 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed:
>> 1b. 6PAN modules comply with an informal contract to maintain
>> backward-compatibility within all N.MM versions, where N is constant. In
>> other words, incompatible API changes are only
At 5:40 PM +0100 6/4/02, Simon Cozens wrote:
>Steve Simmons:
>> We have said that perl5 will be *mostly* mechanically translatable into
>> perl6.
>
>And we shall keep saying this until we believe that it is true?
Coming from the man who wrote part of a Python->Perl converter?
>Hubris is when y
On Tue, 4 Jun 2002, John Siracusa wrote:
: On 6/4/02 12:22 PM, David Wheeler wrote:
: > I think that if we can agree to forego backwards compatibility, we might
: > also be in a better position to set up a CP6AN with much better quality
: > control. All of the most important modules will be porte
On Tue, 4 Jun 2002 10:06:44 -0700 (PDT) Larry Wall <[EMAIL PROTECTED]> wrote:
>It's really not that difficult to run two interpreters in the
>same process. I already made Perl and Java run together nicely.
Agree.
>Scaffolding is supposed to be ugly. You wouldn't believe how ugly
>the transiti
On 6/4/02 10:21 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed:
> Well, there are already "suggested" conventions for version number formats.
>
> Anyway, CPAN is supposed to be organized! It's not a free-for-all dumping
> ground for modules. Let the version numbering and API anarchists use
>
On 6/4/02 1:26 PM, Larry Wall wrote:
> : Speaking of "CPAN for Perl 6" (or "CP6AN", or "6PAN"), what's the status of
> : this effort? Do we even have a vague idea of the requirements? Or does
> : everyone think CPAN (and module distribution/installation in general) as it
> : exists now it pretty
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> :
> : 1a. Modules may be "use"-ed in several ways (syntax ignored for
> now):
> :
> : # Note "...installed on this system" is implied at the end
> : # of each of the following descriptions
> :
> : "Use the latest stable version of module
On Tue, Jun 04, 2002 at 12:59:38PM -0400, John Siracusa wrote:
> In the spirit of Simon's desire to see "radical changes" when appropriate, I
> propose the following high-level goals for 6PAN . . .
> 1. Multiple versions of the same module may be installed on a single system
> with no possibilit
On 29 May 2002, Mike Lambert wrote:
> # New Ticket Created by Mike Lambert
> # Please include the string: [netlabs #634]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=634 >
>
>
> Peter recently submitted a patch to RT
On 6/4/02 12:59 PM, "Steve Simmons" <[EMAIL PROTECTED]> claimed:
>> It shouldn't be required that all tests pass, however. A statement showing
>> what platforms they pass on and what platforms they don't at the top of the
>> download page would be good enough. But the tests have got to be there.
On 6/4/02 3:59 PM, Steve Simmons wrote:
>> : 1c. Distinctions like "alpha", "beta", and "stable" need to be made
>> : according to some convention (a la $VERSION...perhaps $STATUS?)
>>
>> Can probably burn that bridge when we get to it.
>
> Frankly, I'd argue that nothing in 6PAN ought to be in
On Tue, Jun 04, 2002 at 03:53:18PM +0100, Dave Mitchell wrote:
> One word: CPAN.
For what it's worth, I'm looking forward to porting my 50-odd modules to
Perl 6. In a lot of cases, I'll finally be able to remove some awful hacks.
--
This sig file temporarily out of order.
Schwern wrote:
> For what it's worth, I'm looking forward to porting my 50-odd modules to
> Perl 6. In a lot of cases, I'll finally be able to remove some awful hacks.
And I'll be porting most of my 30 or so (not the Perl6:: ones, obviously).
There. Nearly 3% of the CPAN ported in two fell swo
Damian Conway:
# Schwern wrote:
#
# > For what it's worth, I'm looking forward to porting my
# 50-odd modules
# > to Perl 6. In a lot of cases, I'll finally be able to remove some
# > awful hacks.
#
# And I'll be porting most of my 30 or so (not the Perl6::
# ones, obviously).
#
# There. N
On 6/4/02 4:08 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed:
> Why bother? You've already put P::RD and T::B effectively in the core!
> ;^)
And Switch. And Next? And Q::S? Larry, have you decided on that one yet?
:-)
Regards,
David
--
David Wheeler AIM:
Brent wrote:
> # And I'll be porting most of my 30 or so (not the Perl6::
> # ones, obviously).
>
> Why bother? You've already put P::RD and T::B effectively in the core!
Not to mention Switch and Attribute::Handlers and Class::Contract and
Class::Multimethods and Filter::Simple and Inline::Fi
[This seems like a good time to post something that's been on my mind for
some time.]
SUMMARY
The world needs a really easy CPAN client. Here's one design for such a
thing.
DETAILS
A few brief philosphical points:
1) People like languages that have tons of built-in
doohickeys. See PH
Hmm... I like it. It took me a good 6 months before I learned how to use
CPAN. I don't see how your proposal is that different from:
alias cpan='perl -MCPAN -e shell'
But I get the idea. Someone (well, you've inspired me now, so I) could
write a perl5 equivilent, because command line is qui
On Tue, Jun 04, 2002 at 10:48:06PM -0600, Luke Palmer wrote:
> Hmm... I like it. It took me a good 6 months before I learned how to use
> CPAN. I don't see how your proposal is that different from:
>
> alias cpan='perl -MCPAN -e shell'
CPAN.pm already installs a cpan program for you that's ex
On Tue, 4 Jun 2002, Luke Palmer wrote:
> On Tue, 4 Jun 2002, Miko O'Sullivan wrote:
>
> > No configuration files (.e.g .cpan) are necessary. However, you can use a
> > configuration file if you want tp indicate a .cpan-like file
> >
> >cpan --conf ~/.cpan load Date::EzDate
>
> What about n
Fixes the problem where the toplevel makefile can't descend into lib/Parrot
to do the build necessary for PackFile and friends. Also I think the
single cd .. may potentially be a bug for other platforms as well.
Apply this and re-run Configure.pl and all is well.
--- config/gen/makefiles/root
"Where am I?" "In the CPAN."
"What do you want?" "Keyed acess."
"Whose side are you on?" "That...would be telling. We want...keyed
access."
"You won't get it." "By hack or by crack... We will."
"Who are you?" "The new pumpking."
"Who is number 2?"
"You are Version Six."
"I am not a version, I am t
49 matches
Mail list logo
