On Sep-07, Leopold Toetsch wrote:
> Steve Fink <[EMAIL PROTECTED]> wrote:
>
> > This patch introduces something that feels suspiciously like libtool,
> > despite the fact that libtool has never been very kind to me. But for
> > now I am targeting this only at the dynamic PMC generation problem; th
Dan,
sorry, although I'm a long term perl user I'm not that familiar with the
internals of the perl development process that I know all the old
stories ;)
The plan looks good, but some things are still unclear to me:
> *) Person building runs platform-specific script
Platform specific means
When I try to run one of the SDL examples (any of them), I get:
SDL::fetch_layout warning: layout 'Pixels' not found!
Segmentation fault
When I edit runtime/parrot/library/SDL.imc and add the call to
_set_Pixels_layout in at line 60, I remove that warning, but still get
the seg-fault:
Program re
On Tue, 7 Sep 2004, Leopold Toetsch wrote:
> > [*] Unless it's a _feature_ that given tied $a,
> >($a = "aaa") =~ s/a/b/g
> > would call STORE four times ("aaa", "baa", "bba", "bbb").
>
> I'd expect two stores here. One for the initial setting of the value and
> one for the final result
On Tuesday 07 September 2004 03:47 pm, Nicholas Clark wrote:
> On Tue, Sep 07, 2004 at 10:52:01AM -0400, Aaron Sherman wrote:
> > Seriously, I've never come across any system that lacked autoconf
> > support AND which a high level language like those that would target
> > Parrot, ran on. If you're
Or, rather, the const_string function.
Simple thing, looks like:
STRING *foo = const_string(interpreter, c-style string constant);
Easy, right? Yeah. Easy. What it does is create a new parrot string,
set to the constant C string you pass in. Handy. Even marks the
string as constant and extern
This argument's old. Very old, so it may be unfamiliar to many
people. The subject generates enough heat that I don't want to go
there again.
We are not using autoconf. Period.
Parrot's build process, when shipped will be:
*) Person building runs platform-specific script
*) Script builds minipar
On Tue, 2004-09-07 at 11:59, Andrew Dougherty wrote:
> Both autoconf and metaconfig assume a unix-like environment. Ambitious
> plans for parrot's configure include non-unix environments too, such as
> VMS and all the ports where perl5 uses a manually-generated config.*
> template.
autoconf assu
Hi,
the examples in examples/streams are not working with --gc-debug,
FileLines.imc crashes even without it.
Any idea why?
jens
On Tue, Sep 07, 2004 at 10:52:01AM -0400, Aaron Sherman wrote:
> Seriously, I've never come across any system that lacked autoconf
> support AND which a high level language like those that would target
> Parrot, ran on. If you're referring to the number of systems that have
autoconf supports Win3
On Tue, 2004-09-07 at 09:26, Dan Sugalski wrote:
> *) Namespaces are hierarchical
>
> So we can have ["foo"; "bar"; "baz"] for a namespace. Woo hoo and all
> that. It'd map to the equivalent perl namespace of foo::bar::baz.
[...]
It's also possible to hoist a sub-space up a few levels, so that t
On Tue, Sep 07, 2004 at 04:11:18PM +, Herbert Snorrason wrote:
> So ... it's actually happening? There's really going to *be* a Perl6?
> It's not just an april fool's gone wrong, like Parrot? ;)
Mark my words: There will be a Perl 6.
Pm
i've made some good progress on mod_parrot. since so much has changed
in the past year, i decided to rewrite the thing from scratch. here's
what i've been able to implement so far:
* rewrite for apache 2 (might as well start with the latest)
* per-process interpreter persistence (using prefork M
On Tue, Sep 07, 2004 at 09:26:14AM -0400, Dan Sugalski wrote:
> Time to nail this.
>
> We need namespaces. Duh. We talked about this in the past.
I've reordered these to put the simple/fundamental things first:
> *) Namespaces are hierarchical
> *) The top-level namespace ["__INTERNAL"] is taken
For the case that someone does not know how to subscribe:
just send a mail to [EMAIL PROTECTED]
jens
So ... it's actually happening? There's really going to *be* a Perl6?
It's not just an april fool's gone wrong, like Parrot? ;)
On Tue, 7 Sep 2004 11:57:23 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The list... is open. It's meant for discussion of the perl 6 compiler
> specifically. Perl6-i
On Tue, Sep 07, 2004 at 10:52:01AM -0400, Aaron Sherman wrote:
> Ok, this is probably a moot conversation because Metaconfig
> (http://www.linux-mag.com/2002-12/compile_03.html) was written by Larry
> Wall for rn, and the Perl community has some serious social inertia when
> it comes to switching t
On Tue, 7 Sep 2004, Aaron Sherman wrote:
> On Tue, 2004-09-07 at 08:00, Jens Rieks wrote:
> > On Tuesday 07 September 2004 07:52, Robert Schwebel wrote:
> > > Would autoconf/automake be an option for the C part of parrot?
> > No, its only available on a few systems.
>
> Ok, this is probably a moot
The list... is open. It's meant for discussion of the perl 6 compiler
specifically. Perl6-internals (which will get renamed
parrot-internals... some day) is for parrot discussion. At some point
reasonably soon I'm told that parrot-compilers will be up and running
as well, for the discussion of
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> "imcc/imcc.l", line 852:
> warning: improper pointer/integer combination: arg #2
Is already fixed.
> Still, it's probably a good step forward.
Ok.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:27 AM +0200 9/3/04, Leopold Toetsch wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>> At 12:16 PM +0200 8/31/04, Leopold Toetsch wrote:
Pclass = getclass, "Foo"
Pobjnew = Pclass."__new"(args) # Pnew is an OUT argument
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> *) Namespaces are hierarchical
What do we do against collisions? During Pie-thon hacking I came along
this problem:
class C():
pass
c = C()
"C" ought to be now a "global" classname (that's what the bytecode
indicates) and it should be its own na
On Tue, 7 Sep 2004 10:50:49 -0400 (EDT), Andy Dougherty
<[EMAIL PROTECTED]> wrote:
> Still, it's probably a good step forward. We might eventually decide we
> need pre- and post- triggers or other enhancements, but this is probably a
> good basis to start with.
Pre and post triggers would be pret
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:55 PM +0200 9/2/04, Leopold Toetsch wrote:
>>- do we keep these opcodes?
> Yes.
Ok.
>> If yes some permutations are missing.
> Yeah. I'd as soon leave them out until we need them.
Well, the asymmetry makes it harder for compilers to emit proper
On Tue, 2004-09-07 at 08:00, Jens Rieks wrote:
> On Tuesday 07 September 2004 07:52, Robert Schwebel wrote:
> > Would autoconf/automake be an option for the C part of parrot?
> No, its only available on a few systems.
Ok, this is probably a moot conversation because Metaconfig
(http://www.linux-ma
On Tue, 7 Sep 2004, Leopold Toetsch wrote:
> Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > On Sun, 5 Sep 2004, Clayton O'Neill wrote:
>
> >> This adds support for setting triggers on specific config variables.
>
> > I'd be inclined to call that particular routine solaris_gccversion_cb,
>
> Should
At 8:03 AM -0600 9/7/04, Luke Palmer wrote:
Dan Sugalski writes:
Time to nail this.
We need namespaces. Duh. We talked about this in the past.
So, here's what I'm proposing. It'll be formalized into a PDD once we
hash things out.
*) Namespaces are hierarchical
So we can have ["foo"; "bar"; "b
At 11:27 AM +0200 9/3/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 12:16 PM +0200 8/31/04, Leopold Toetsch wrote:
Pclass = getclass, "Foo"
Pobjnew = Pclass."__new"(args) # Pnew is an OUT argument
and that be special-cased to call VTABLE_new according to calling
co
Dan Sugalski writes:
> Time to nail this.
>
> We need namespaces. Duh. We talked about this in the past.
>
> So, here's what I'm proposing. It'll be formalized into a PDD once we
> hash things out.
>
> *) Namespaces are hierarchical
>
> So we can have ["foo"; "bar"; "baz"] for a namespace. Woo
At 10:59 PM -0400 9/6/04, Chip Salzenberg wrote:
Just across the hall from m// is s/// ...
Considering the semantics of m// and especially s/// at the user
level, we'll probably[*] want to take snapshots of dynamic strings
(think P5's "FETCH" or overload '""'), and apply all the pattern
operations
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> For Topaz, Scalar's interface included a function that would basically
> open the Scalar's hood, giving you a Buffer you could manipulate; then
> when you were done working with the Buffer, its modifications (if any)
> were propagated back down into the
Time to nail this.
We need namespaces. Duh. We talked about this in the past.
So, here's what I'm proposing. It'll be formalized into a PDD once we
hash things out.
*) Namespaces are hierarchical
So we can have ["foo"; "bar"; "baz"] for a namespace. Woo hoo and all
that. It'd map to the equivale
At 6:55 PM +0200 9/2/04, Leopold Toetsch wrote:
We still have a lot of unhooked ops w/o a definite opcode number.
These are mainly the non-branching compare opcodes currently located
in ops/experimental.ops.
These opcodes have some limited usefullness for e.g.
bool_val = (a < b) && (c > d)
i.e
On Tue, Sep 07, 2004 at 02:00:14PM +0200, Jens Rieks wrote:
> On Tuesday 07 September 2004 07:52, Robert Schwebel wrote:
> > Would autoconf/automake be an option for the C part of parrot?
> No, its only available on a few systems.
How do you mean that? You surely don't want to run the compiler dir
On Tuesday 07 September 2004 07:52, Robert Schwebel wrote:
> Would autoconf/automake be an option for the C part of parrot?
No, its only available on a few systems.
Some months ago, I tried to cross compile Parrot to ARM (Zaurus), and to
compile Parrot directly on the Zaurus, with no success (mos
Just across the hall from m// is s/// ...
Considering the semantics of m// and especially s/// at the user
level, we'll probably[*] want to take snapshots of dynamic strings
(think P5's "FETCH" or overload '""'), and apply all the pattern
operations to that snapshot. *However*, in the usual case
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi all,
> there are now two new examples:
Great.
> Minesweeper freezes after you have created some new fields (by clicking onto
> the smiley). I think it is a GC bug, because minesweeper does not even start
> with --gc-debug.
Repeatedly clicking the smile
Steve Fink <[EMAIL PROTECTED]> wrote:
> This patch introduces something that feels suspiciously like libtool,
> despite the fact that libtool has never been very kind to me. But for
> now I am targeting this only at the dynamic PMC generation problem; this
> solution could be expanded to ease port
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> On Sun, 5 Sep 2004, Clayton O'Neill wrote:
>> This adds support for setting triggers on specific config variables.
> I'd be inclined to call that particular routine solaris_gccversion_cb,
Should the patch go in?
> Thanks.
> Andy Dougherty
39 matches
Mail list logo
