Introduction
I have a very alpha patch to add a parrot backend to the CHICKEN compiler.
CHICKEN is a scheme to C compiler, and parrot is a continuation (rather
than stack) based virtual machine. There are several design issues
mapping chicken construct
Salvador Ortiz Garcia wrote:
In the ghc docs I found that "-Dsymbol=value" does not affect -D macros
passed to the C compiler when compiling via C, the mode used when
optimization is on.
So the perl5 ccflags defined must be passed using -optc.
[...]
-$ccdlflags .= qq[ -optl "$_" ]
On Jul 7, 2005, at 11:28 PM, Larry Wall wrote:
On Thu, Jul 07, 2005 at 09:28:04PM -0400, Michal Wallace wrote:
: What I'd want is to be able to download the language
: specific extensions as a library from cpan. Better
: yet if users can do it themselves without having
: to bug me.
Hmm...
My ne
On Thu, Jul 07, 2005 at 09:28:04PM -0400, Michal Wallace wrote:
: What I'd want is to be able to download the language
: specific extensions as a library from cpan. Better
: yet if users can do it themselves without having
: to bug me.
Hmm...
: Sure, I'd probably install as much as I could, but
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> to go with everyone else's preferences:
LW> use self "."
LW> use self "`"
LW> use self "·"
LW> use self ".."
LW> use self "^."
LW> use self "i."
LW> use self "o."
LW> use self "¤."
LW>
On Thu, Jul 07, 2005 at 06:15:03PM -0700, Paul Hodges wrote:
:
:
: --- Larry Wall <[EMAIL PROTECTED]> wrote:
: > Arguably, we could probably admit
: >
: > $fh.pos = 10`bytes
: >
: > for the case of seeking from the begining. But I'd kind of like
: >
: > $fh.pos = 10
: >
: > to be con
The basic problem is that I always hated looking at C++ and not knowing
whether I was looking at a function or a method, so I'm not going to
make standard Perl work like that. On the other hand, there's always
use self "";
to go with everyone else's preferences:
use self "."
use sel
On 7/8/05, Robin Redeker <[EMAIL PROTECTED]> wrote:
> Hi,
>
> i just wanted to ask what was about the method calling syntax on
> $self, and why does
>
>method ()
>
> not work for calling a method on $self? (like in C++)
IIRC, Larry wants to be able to distinguish method calls from sub
calls
On Thu, Jul 07, 2005 at 05:58:53PM -0700, Larry Wall wrote:
> $fh.pos = $fh.pos + 10`lines
I'm sorry if this has been discussed, but is the ` going to be in
Perl 6? I like it. :) How does it work, though?
sub *infix:<`> (Num $amount, Unit $class) { $class.new($amount) }
Or so?
Now I'm t
On Thu, 7 Jul 2005, Roger Browne wrote:
Leopold Toetsch wrote:
Well, if you have some mixed environment, you'd probably build parrot on
all machines with the PMC's needed. Something like:
perl Configure.pl --with-tcl --with-python
to get these PMCs built on it.
I'm thinking of situations
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> Arguably, we could probably admit
>
> $fh.pos = 10`bytes
>
> for the case of seeking from the begining. But I'd kind of like
>
> $fh.pos = 10
>
> to be considered an error.
It seems a logical extension also to say
$fh.pos += 10`byte
Hi all,
In the ghc docs I found that "-Dsymbol=value" does not affect -D macros
passed to the C compiler when compiling via C, the mode used when
optimization is on.
So the perl5 ccflags defined must be passed using -optc.
The following change in Makefile.PL fixed it:
--- /tmp/Perl6-Pugs-6.2.
On Thu, Jul 07, 2005 at 02:15:19PM -0600, Paul Seamons wrote:
: > We should approach this from the perspective that $fh is an iterator, so
: > the general problem is "how do we navigate a random-access iterator?".
:
: Well - I kind of thought that $fh was a filehandle that knew how to behave
:
On Thu, Jul 07, 2005 at 04:08:17PM -0500, Jonathan Scott Duff wrote:
> On Thu, Jul 07, 2005 at 10:32:37PM +0200, Robin Redeker wrote:
> > Hi,
> >
> > i just wanted to ask what was about the method calling syntax on
> > $self, and why does
> >
> >method ()
> >
> > not work for calling a metho
On Thu, July 7, 2005 11:40 am, Roger Browne said:
> Matt Diephouse wrote:
>> Should as much functionality as possible be put into the core PMCs?
>
> I'd like to see parrot include a set of core PMCs that implement fairly
> pure abstractions, without any language-specific stuff (such as
> automatic
On 7/7/05, wolverian <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 07, 2005 at 08:18:40PM +0300, wolverian wrote:
> > I'm a pretty high level guy, so I don't know about the performance
> > implications of that. Maybe we want to keep seek() low level, anyway.
>
> Sorry about replying to myself, but I wa
PGE is now updated in the leo_ctx5 branch of parrot, using the
new calling conventions. All tests pass.
Pm
On Thu, Jul 07, 2005 at 10:32:37PM +0200, Robin Redeker wrote:
> Hi,
>
> i just wanted to ask what was about the method calling syntax on
> $self, and why does
>
>method ()
>
> not work for calling a method on $self? (like in C++)
Because perl can't distinguish between the method foo() and
Hi,
i just wanted to ask what was about the method calling syntax on
$self, and why does
method ()
not work for calling a method on $self? (like in C++)
cya,
Robin
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
Robin Redeker
On Thu, Jul 07, 2005 at 08:18:40PM +0300, wolverian wrote:
> I'm a pretty high level guy, so I don't know about the performance
> implications of that. Maybe we want to keep seek() low level, anyway.
Sorry about replying to myself, but I want to ask a further question on
this.
Would it be possibl
> We should approach this from the perspective that $fh is an iterator, so
> the general problem is "how do we navigate a random-access iterator?".
Well - I kind of thought that $fh was a filehandle that knew how to behave
like an iterator if asked to do so. There are too many applications tha
Wolverian wrote:
Or maybe we don't need such an adverb at all, and instead use
$fh.seek($fh.end - 10);
I'm a pretty high level guy, so I don't know about the performance
implications of that. Maybe we want to keep seek() low level, anyway.
Any thoughts/decisions?
We should approach thi
On Jul 7, 2005, at 18:16, Matt Diephouse wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Matt Diephouse wrote:
perl Configure.pl --with-tcl --with-python
to get these PMCs built on it.
Yes, but the point is that sometimes you don't have that power.
Err, and that was answered in
Hello,
gaal is porting the Perl 5 filehandle functions to a Perl 6 OO
interface. The Perl 5 interface with global constants from Fcntl strikes
me as severely lacking in elegance and OO.
$fh.seek(-10, SEEK_END);
Instead of globals, how about a :from adverb?
$fh.seek(-10, :from);
Or mayb
Dan wrote:
> I was hoping we'd see hybrid PMCs -- that is, language specific
> PMCs that were fully implemented both in pure bytecode and in C.
Huh? Parallel maintenance of duplicate complex implementations?
On _purpose_?
"That trick *never* works!"
> I'd like to see parrot include a set of cor
HaloO Larry,
you wrote:
: Could you explain what exactly 'run-time lazy type aliasing' is?
: I mean what does it achieve and how does it compare to type
: instanciation and parametric contraint checking?
It achieves guaranteed *late* binding of types, whereas generics/roles
are biased towards e
Leopold Toetsch wrote:
> Well, if you have some mixed environment, you'd probably build parrot on
> all machines with the PMC's needed. Something like:
>
>perl Configure.pl --with-tcl --with-python
>
> to get these PMCs built on it.
I'm thinking of situations like web hosting, where the pro
On Jul 7, 2005, at 18:02, Chip Salzenberg wrote:
Say a new bit
":opt_count", which means that the given register should be assigned
the count?
.sub "foo"
.param int beta
.param string gamma :optional
.param string delta :optional
.param int optc :opt_co
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Diephouse wrote:
> > Dan wrote an entry on his blog yesterday entitled "WWIT: Universal
> > bytecode":
> >
> > http://www.sidhe.org/~dan/blog/archives/000421.html
> >
> > In it, he talks (surprise, surprise) about being able to run bytecode
> >
On Thu, Jul 07, 2005 at 12:11:53PM -0400, Chip Salzenberg wrote:
> Thus, this is probably better:
>
> .sub "foo"
> .param int beta
> .param string gamma :optional(have_gamma)
> .param string delta :optional(have_delta)
> .param pmc epsilon :slurpy
As y
And I just realized my proposal fails to address something important.
But I'm not entirely sure it's Parrot's job to do the important thing
in question. Still, the possibility exists. Thus:
On Thu, Jul 07, 2005 at 12:02:40PM -0400, Chip Salzenberg wrote:
> .sub "foo"
> .param int b
On Thu, Jul 07, 2005 at 12:02:40PM -0400, Chip Salzenberg wrote:
> On Thu, Jul 07, 2005 at 10:43:45AM -0500, Patrick R. Michaud wrote:
> > With something like
> >
> > .sub "foo"
> > .param int beta
> > .param string gamma :optional
> > .param string delta :optional
> >
Patrick R. Michaud wrote:
... get_argc (which perhaps should be called something
else)
Better names are welcome.
So, all we really need is something that can tell us how many :optional
arguments were filled in.
Sounds reasonable.
op optional_count(out INT)
Another question: do we want
On Thu, Jul 07, 2005 at 10:43:45AM -0500, Patrick R. Michaud wrote:
> With something like
>
> .sub "foo"
> .param int beta
> .param string gamma :optional
> .param string delta :optional
> .param pmc epislon :slurpy
>
> So, all we really need is something that
Matt Diephouse wrote:
Dan wrote an entry on his blog yesterday entitled "WWIT: Universal bytecode":
http://www.sidhe.org/~dan/blog/archives/000421.html
In it, he talks (surprise, surprise) about being able to run bytecode
across machines without the need of a compiler. If you look at the
co
Sam Vilain wrote:
> Maxim Sloyko wrote:
>
>> But this is not the point. The point was that usage of some file with
>> passwords by *DEFAULT* is not the way to go, IMHO. It raises more
>> problems than it solves.
>
>
> Can you give an example of such a problem that wasn't already there?
>
> J
On Thu, Jul 07, 2005 at 10:43:45AM -0500, Patrick R. Michaud wrote:
> In fact, this might be greatly preferable, since if
> I later decide I need another non-optional parameter
>
> .sub "foo"
> .param int beta
> .param int omega
> .param string gamma :optional
>
On Thu, Jul 07, 2005 at 11:22:27AM -0400, Chip Salzenberg wrote:
> On Thu, Jul 07, 2005 at 10:09:27AM -0500, Patrick R. Michaud wrote:
> > On Thu, Jul 07, 2005 at 11:05:00AM -0400, Chip Salzenberg wrote:
> > > On Thu, Jul 07, 2005 at 10:57:40AM -0400, Will Coleda wrote:
> > > > To manage varargs-st
Dan wrote an entry on his blog yesterday entitled "WWIT: Universal bytecode":
http://www.sidhe.org/~dan/blog/archives/000421.html
In it, he talks (surprise, surprise) about being able to run bytecode
across machines without the need of a compiler. If you look at the
comments, I asked what thi
Chip Salzenberg wrote:
On Thu, Jul 07, 2005 at 03:36:01PM +0200, Leopold Toetsch wrote:
Instead we have the new opcode:
get_argc(out INT)
which returns the argument/result count of the recent call/return.
Why do we need this?
To know, if :optional args where passed in or not.
leo
On Thu, Jul 07, 2005 at 10:09:27AM -0500, Patrick R. Michaud wrote:
> On Thu, Jul 07, 2005 at 11:05:00AM -0400, Chip Salzenberg wrote:
> > On Thu, Jul 07, 2005 at 10:57:40AM -0400, Will Coleda wrote:
> > > To manage varargs-style subroutines?
> >
> > But that's what :slurpy is for.
>
> But :slurp
On Thu, Jul 07, 2005 at 11:05:00AM -0400, Chip Salzenberg wrote:
> On Thu, Jul 07, 2005 at 10:57:40AM -0400, Will Coleda wrote:
> > To manage varargs-style subroutines?
>
> But that's what :slurpy is for.
But :slurpy always pulls things into a PMC (and creates PMCs
along the way).
We need get_ar
On Thu, Jul 07, 2005 at 10:57:40AM -0400, Will Coleda wrote:
> To manage varargs-style subroutines?
But that's what :slurpy is for.
--
Chip Salzenberg <[EMAIL PROTECTED]>
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #36480]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36480 >
This seems to be a core Parrot bug:
harmony:~/Projects/parrot/languages/tcl mdiep$ g
To manage varargs-style subroutines?
On Jul 7, 2005, at 10:55 AM, Chip Salzenberg wrote:
On Thu, Jul 07, 2005 at 03:36:01PM +0200, Leopold Toetsch wrote:
Instead we have the new opcode:
get_argc(out INT)
which returns the argument/result count of the recent call/return.
Why do we n
On Thu, Jul 07, 2005 at 03:36:01PM +0200, Leopold Toetsch wrote:
> Instead we have the new opcode:
> get_argc(out INT)
> which returns the argument/result count of the recent call/return.
Why do we need this?
--
Chip Salzenberg <[EMAIL PROTECTED]>
When I go to the donation page and attempt to make a donation, the
drop-down box does not give DBI as a valid recipient. Is it possible
several people may not have donated as they noticed the same results, or
maybe they did and it all went into the Perl Development Fund instead?
> -Or
On Thu, Jul 07, 2005 at 09:13:47PM +0800, Autrijus Tang wrote:
> On Thu, Jul 07, 2005 at 07:52:31AM -0400, Michal Wallace wrote:
> > I'm the guy running the pirate project (python-on-parrot). Leo says
> > that you and I ought to chat, and I think he's right. :)
>
> Wonderful. Cc'ing both pirate a
On Thu, Jul 07, 2005 at 03:36:01PM +0200, Leopold Toetsch wrote:
> I've now implement full type conversions, thus making argument passing
> strictly positional. This also implies that we don't need separate
> argument counts per register type, these are gone now.
>
> Instead we have the new opco
I've now implement full type conversions, thus making argument passing
strictly positional. This also implies that we don't need separate
argument counts per register type, these are gone now.
Instead we have the new opcode:
get_argc(out INT)
which returns the argument/result count of the r
On Thu, Jul 07, 2005 at 12:13:04PM +0200, Leopold Toetsch wrote:
> I've just misinterpreted this para and thought that we convert only
> to/from PMCs but not between native types. I'll fix that.
That will be *very* nice.
> >Lastly, while on the topic of calling conventions, has there been
> >an
On Thu, Jul 07, 2005 at 07:52:31AM -0400, Michal Wallace wrote:
> I'm the guy running the pirate project (python-on-parrot). Leo says
> that you and I ought to chat, and I think he's right. :)
Wonderful. Cc'ing both pirate and p6c as I'm sure both lists will
find this discussion fruitful. :-)
>
On Thu, Jul 07, 2005 at 12:43:58PM +0200, Leopold Toetsch wrote:
> To me it seems, however you declare the "emit" function (with mixed
> optional native types), it either isn't following the principle of
> strict positional argument passing, or it does the wrong thing due to
> type conversions.
The uploaded file
Test-Unix-Group-0.01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/N/NI/NIKC/Test-Unix-Group-0.01.tar.gz
size: 6455 bytes
md5: 497cba10cde46dcfb8f48b1de7238f8e
From the docs:
SYNOPSIS
use Test::Unix::Group tests => 4;
group_ok({ name => 'wheel
The uploaded file
Test-Unix-User-0.01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/N/NI/NIKC/Test-Unix-User-0.01.tar.gz
size: 7007 bytes
md5: c3506dce32b5f841b1e6e7e351757556
From the docs:
SYNOPSIS
use Test::Unix::User tests => 2;
user_ok({ name => 'nik', uid
Sam Vilain wrote:
Maxim Sloyko wrote:
But this is not the point. The point was that usage of some file with
passwords by *DEFAULT* is not the way to go, IMHO. It raises more
problems than it solves.
Can you give an example of such a problem that wasn't already there?
Just to be clear, the
Patrick R. Michaud wrote:
With the new PIR calling conventions, emit() is to be written
with ":optional" on the optional parameters, like so:
.sub "emit" method
.param pmc code # accumulating code object
.param string out # string to output
During the Pugs Hackathon at YAPC::NA 2005, I managed to get various
unspecced tests and features reviewed by Larry, and posted them in my
journal. The original notes is attached; I'd be very grateful if you or
other p6l people can find tuits to work them back into the relevant
Synopses. :-)
Than
Patrick R. Michaud wrote:
Also, I've been working under the assumption that it's generally
better (faster/more efficient) for frequently used integer and
string values to be held and manipulated in I and S registers rather
than PMCs. Perhaps this assumption is invalid.
The assumption is of c
Jeff Horwitz wrote:
mod_parrot is running into a bit of trouble calling subs written in PIR
with the new calling conventions.
[ ... ]
this may all be premature, as leo's branch is still brand-spanking new,
Yep, very premature. I'd be glad to get some test cases, though.
-jeff
Thanks,
60 matches
Mail list logo
