On Thu, Mar 11, 2004 at 01:09:59AM -0500, Austin Hastings wrote:
:
:
: > -Original Message-
: > From: Damian Conway [mailto:[EMAIL PROTECTED]
: > Sent: Wednesday, 10 March, 2004 09:48 PM
: > To: [EMAIL PROTECTED]
: > Subject: Re: Mutating methods
: >
: >
: > Brent "Dax" Royal-Gordon wrote
> -Original Message-
> From: Damian Conway [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 10 March, 2004 09:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Mutating methods
>
>
> Brent "Dax" Royal-Gordon wrote:
>
> >> / $foo:=(abc) $bar:=(def) /
> >
> > Am I misreading, or are you suggesti
On Wed, Mar 10, 2004 at 10:46:05PM -0500, matt wrote:
: I was thinking along the lines of...
:
: String $foo = "hello";
: $foo.scramble!
That would be $foo.=scramble in the current scheme of things.
: print "$foo\n";
: $foo = "hello"
: print $foo.scramble ~ "\n";
: print $foo;
:
: OUTPUT (or cl
I was thinking along the lines of...
String $foo = "hello";
$foo.scramble!
print "$foo\n";
$foo = "hello"
print $foo.scramble ~ "\n";
print $foo;
OUTPUT (or close):
elhlo
hloel
hello
Also, along these same things.. is there a way to apply a method to all
variables/objects of a certain type (e.g.
Brent "Dax" Royal-Gordon wrote:
/ $foo:=(abc) $bar:=(def) /
Am I misreading, or are you suggesting that $foo may contain 'abc' after
running this example, even if the match wasn't successful?
No. I re-checked with Larry this morning and he confirmed that all bindings in
rules only "stick" if
We've gone back and forth on this before, and it's time to go for yet
another round.
Right now, we can create new PMCs by calling the class init method.
It takes no parameters which somewhat limits the utility of the thing
as a true initializer. There's an init vtable method that takes a
prope
On Wed, Mar 10, 2004 at 09:59:32AM -0500, Dan Sugalski wrote:
: That means we can't convert to TAI, since that needs leap second info
: we don't have, so base time can't be TAI.
That part is only half true. Or maybe less than half, if UTC decides
to cut loose from astronomical time and ends up t
At 4:32 PM -0800 3/10/04, Larry Wall wrote:
On Wed, Mar 10, 2004 at 10:58:14AM -0500, Dan Sugalski wrote:
: *) Times (create, modify, access)
Just a reminder that ctime on Unix is not "create" time, but time of
last inode change. I wish there were a create time on Unix, but there
ain't.
Yup, tha
On Wed, Mar 10, 2004 at 10:58:14AM -0500, Dan Sugalski wrote:
: *) Times (create, modify, access)
Just a reminder that ctime on Unix is not "create" time, but time of
last inode change. I wish there were a create time on Unix, but there
ain't.
Larry
[EMAIL PROTECTED] (Dan Sugalski) writes:
[...]
> It's an ongoing fight between the "go get the libs and install them"
> folks and the "self-contained distribution" folks. I'm in the latter
> category. :)
As Larry said, "self-contained" is good for users. For developers
(and CVS) "go get the libs
> >
> > That depends if google properly supports "moderated" newsgroups.
>
> Sounds like they don't ...
>
> In any case we don't currently support posting via nntp through
> anything but nntp.perl.org.
Actually, I think we need to get the uunet.uu.net folks to setup some
entries for us. But I
Hi,
this time a funny bug :-)
1. create a file main.imc with the following content:
.sub _main
print "A\n"
load_bytecode "hello.imc"
print "B\n"
end
.end
2. create a file hello.imc with the following content:
.emit
.pcc_sub @LOAD _onload:
print "foo\n"
end
.eom
.sub _hel
Damian Conway wrote:
/ $foo:=(abc) $bar:=(def) /
Am I misreading, or are you suggesting that $foo may contain 'abc' after
running this example, even if the match wasn't successful?
--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been at war with Easta
Luke Palmer wrote:
I understand the association with C<$?foo>. But most of the time, when
I'm writing a grammar, I'm catching these rules in order to stick them
in the parse tree, not to do tests on them later on in the rule. The
very essence of rules is hypotheticality, where nothing is permane
At 11:12 AM -0800 3/10/04, Brent \"Dax\" Royal-Gordon wrote:
Dan Sugalski wrote:
Which, unfortunately, will end up making things a hassle, since
there's no platform-independent way to spawn a sub-process, dammit.
:(
Unixen seem to support system().
D'oh! It's C89 standard. I'm getting stuck in th
At 12:53 PM -0500 3/10/04, Josh Wilmes wrote:
It's also quite possible that miniparrot is a waste of time. I'm pretty
much of the opinion myself that it's an academic exercise at this point,
but one which keeps us honest, even if we don't use it.
Nope, not a waste of time at all. It is part of the
Larry Wall writes:
> On Wed, Mar 10, 2004 at 12:42:00PM -0700, Luke Palmer wrote:
> : I can think of a couple that I like better:
> :
> : <^foo>
> : <*foo>
> :
> : <^foo> is my favorite at the moment (even though <*foo> is more
> : visually pleasing), because it looks like it's transferri
On Wed, Mar 10, 2004 at 12:42:00PM -0700, Luke Palmer wrote:
: > (Also, these days you have to say to collect the results into $0.)
:
: Hooray! That was something I had been worried about.
:
: But C doesn't seem to fit visually. What's "questionable" about
: that?
It's questionable insofar as
Luke Palmer wrote:
Hooray! That was something I had been worried about.
But C doesn't seem to fit visually. What's "questionable" about
that?
Nothing questionable, but
everything hypothetical:
captures to the
$?foo hypothetical variable
Damian
Larry Wall writes:
> On Wed, Mar 10, 2004 at 11:19:52AM -0800, Brent Dax Royal-Gordon wrote:
> : Luke Palmer wrote:
> : >The reason we couldn't just decalre it with C is because its
> : >right hand side is not a usual expression.
> :
> : Isn't that what macros are for?
> :
> : macro infix:.=
On Wed, Mar 10, 2004 at 11:19:52AM -0800, Brent Dax Royal-Gordon wrote:
: Luke Palmer wrote:
: >The reason we couldn't just decalre it with C is because its
: >right hand side is not a usual expression.
:
: Isn't that what macros are for?
:
: macro infix:.= ($lhs, $rhs) is parsed(//) {
Metho
On Wed, Mar 10, 2004 at 05:39:33PM +0100, Juerd wrote:
: Perlists,
:
: In Perl 5, lc, lcfirst, quotemeta, uc and ucfirst don't mutate.
: chomp and chop do mutate.
:
: I imagine these will all be methods in Perl 6:
:
: $foo.lc
: $foo.quotemeta
: $foo.chomp
:
: I'd like a mutating ver
Luke Palmer wrote:
The reason we couldn't just decalre it with C is because its
right hand side is not a usual expression.
Isn't that what macros are for?
macro infix:.= ($lhs, $rhs) is parsed(//) {
return Perl::assignment_expression.new(
lhs => $lhs,
rhs => Per
Dan Sugalski wrote:
Which, unfortunately, will end up making things a hassle, since there's
no platform-independent way to spawn a sub-process, dammit. :(
Unixen seem to support system(). So does Windows. I suspect that most
OSes we want to run on have something pretty equivalent, even if it
d
Juerd writes:
> Perlists,
>
> In Perl 5, lc, lcfirst, quotemeta, uc and ucfirst don't mutate.
> chomp and chop do mutate.
>
> I imagine these will all be methods in Perl 6:
>
> $foo.lc
> $foo.quotemeta
> $foo.chomp
>
> I'd like a mutating version of lc, and a non-mutating version of
At 10:11 AM -0800 3/10/04, Brent \"Dax\" Royal-Gordon wrote:
Josh Wilmes wrote:
It's also quite possible that miniparrot is a waste of time. I'm
pretty much of the opinion myself that it's an academic exercise at
this point, but one which keeps us honest, even if we don't use it.
Miniparrot, or
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Time to nail down some method syntax for IMCC. So, what I'd like (and
> this is open to discussion) is:
> Calling a method:
> object.variable(pararms)
Ok.
> object."literal name"(params)
A currently already implemented variant is:
object.la
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:00 PM +0100 3/9/04, Leopold Toetsch wrote:
>>While I see that's necessary it's not that simple ...
> Oh, sure it is. :)
> Well, from what I've seen so far, you're slamming all subs into the
> base namespace, so that if I have IMCC code that does:
>
Josh Wilmes wrote:
It's also quite possible that miniparrot is a waste of time. I'm pretty
much of the opinion myself that it's an academic exercise at this point,
but one which keeps us honest, even if we don't use it.
Miniparrot, or something very much like it, is the final build system.
--
B
I have no opinion either way on this opcode or the date/time ones, but I
would like to remind folks about miniparrot- if we want it to work again,
there needs to be a smooth way to exclude opcodes or PMCs which are
not expecially portable on its platform (pure c89, no threads, etc).
This means
Time to nail down some method syntax for IMCC. So, what I'd like (and
this is open to discussion) is:
Calling a method:
object.variable(pararms)
object."literal name"(params)
that is, if the method is referenced with a string register or .local
you use the first form and just name the r
At 11:39 AM +0100 3/10/04, Leopold Toetsch wrote:
Proposal C opcode and interface
While we need to do this, what you've got here's far too
platform-specific. From long, hard, unpleasant experience I can
guarantee that starting with a Unix view of this is going to generate
vast amounts of pain in
At 9:00 PM +0100 3/9/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
While we still need to nail down the final bits of namespace stuff,
I'm running into the need for it in IMCC code, so its time to finally
deal with it.
I don't really care what the syntax looks like, so I'm
In an attempt to drain the swamp...
So far as I can see, we need, in descending order of importance (and
speed) (And if there's stuff missing, add them):
1) A timestamp value
2) A way to chop the timestamp to pieces
3) A way to turn the timestamp into a string
4) A way to turn pieces to a timest
Perlists,
In Perl 5, lc, lcfirst, quotemeta, uc and ucfirst don't mutate.
chomp and chop do mutate.
I imagine these will all be methods in Perl 6:
$foo.lc
$foo.quotemeta
$foo.chomp
I'd like a mutating version of lc, and a non-mutating version of chomp.
With some nice syntax, if poss
I have expanded the parser a bit:
obj.method(args)
ret = obj.method(...)
(retvals) = obj.method(...)
C is a label. It's not yet stored in the classes namespace. s.
imcc/t/syn/objects.t
And plain function calls work now with variables too:
.local pmc the_sub
the_sub = global "_sub"
t
Hi all,
attached is an object orientated version of library/dumper.imc.
(it needs libraray/objecthacks.imc from yesterday)
I made the following changes:
- the third (optional) parameter of _dumper ('indent)' behaves a little bit
different. The string is now repeated for each indention level.
- U
Hi,
On Wednesday 10 March 2004 12:54, Leopold Toetsch wrote:
> Jens Rieks <[EMAIL PROTECTED]> wrote:
> > ... It is usefull for constructor calling, to make sure that
> > all base classes are initialized in the proper order.
>
> I've checked in a small change to objects. __init get's now called on
Jens Rieks <[EMAIL PROTECTED]> wrote:
> ... It is usefull for constructor calling, to make sure that
> all base classes are initialized in the proper order.
I've checked in a small change to objects. __init get's now called on
all parent classes in reverse search order. Then __init on the class
i
Op een druilerige winterdag (Wednesday 10 March 2004 12:00), schreef Rafael
Garcia-Suarez:
> Abe Timmerman wrote in perl.daily-build :
> >> The recent smoke failures noticed by Merijn are reproducible with
> >> the environment variables
> >> PERL_UNICODE=""
> >> LC_ALL=fr_FR.utf8 (or anot
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi,
> On Tuesday 09 March 2004 21:17, Leopold Toetsch wrote:
>>
>> what about:
>>
>>(retvals) = obj.methodname(...)
> Yes that would be the best solution. I had a cursory look at the IMCC
> sources, but found no obvious way to implement it.
I'll have a
Sebastian Riedel <[EMAIL PROTECTED]> wrote:
>>
> Attached patch should fix that all.
Thanks, applied - just updated the sample conf.
leo
Proposal C opcode and interface
1) ops
stat (out PMC, in STR, in INT)
stat (out PMC, in PMC, in INT)
Return a new array-like[1] PMC $1 with file stats from file (PIO or
string) $2,
or PerlUndef, if file doesn't exist, $3 are flags:
.PARROT_STAT_NO_FOLLOW_LINK
The array(-like) has keyed
Hi,
On Tuesday 09 March 2004 21:17, Leopold Toetsch wrote:
> Jens Rieks <[EMAIL PROTECTED]> wrote:
> > The attached file has some helper functions to make object usage
> > easier. It is used by the new object orientated Data::Dumper
> > implementation as well as my EBNF parser generator. I submi
On Tue, 9 Mar 2004, Edward S. Peschko wrote:
> > >> This sort of creeping featuritis is why date formatting and especially
> > >> parsing do NOT belong as opcodes. It's too big a problem to solve in the
> >
> > I agree.
>
>
> And the more I think about it, the more I think this concern is misplace
On Tue, 9 Mar 2004, Edward S. Peschko wrote:
> On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote:
> > "Not an opcode" doesn't mean "balkanized." There is a parrot/stdlib
> > directory.
>
> fair enough, but then where does the distinction lie? Why put gmtime, et al.
> in opcodes? As
On Sat, 6 Mar 2004, Jared Rhine wrote:
> It'd be nice if the first item, "gmclock" wasn't defined in terms of
> "UTC". Regardless of the future fate of UTC leap seconds, any
> UTC-based clock would need to account for leap seconds going back,
> right? So it seems that GMT should be preferred in
On Sat, 6 Mar 2004, Jared Rhine wrote:
> It'd be great, if possible, to get a statement here from the DateTime
> group sanctioning one or another particular Parrot clock interfaces as
> "efficient, complete, and preferred". I haven't poked over to see
> if they are chatting about this Parrot issu
On Mar 9, 2004, at 11:56 PM, Robert Spier wrote:
Edward S. Peschko wrote:
(
ps - on a side note, is the news gateway through google working in
posting
to the list? I tried posting via google, and although it shows up on
google, it didn't show up in the archives...
)
That depends if google p
That depends if google properly supports "moderated" newsgroups.
Without knowing what they're doing, it's hard to guess what's going on
or where your message got eaten.
Your message _shouldn't_ show up on google unless it comes through a
proper newsfeed. This might mean that google's upstream (
50 matches
Mail list logo
