On Nov 15, 2005, at 4:28, Chip Salzenberg wrote:
On Sun, Nov 13, 2005 at 11:33:07AM +0100, Leopold Toetsch wrote:
OK, call frame as PMC looks like a non-starter. Consider it rescinded.
Autrijus mentioned on #parrot that we'd need weak pointers at some
time. Then we can reconsider callfra
On Sun, Nov 13, 2005 at 11:33:07AM +0100, Leopold Toetsch wrote:
> On Nov 13, 2005, at 4:45, Chip Salzenberg wrote:
> > $P0 = callframe 1
>
> We already have this kind of introspection: $ grep caller t/pmc/sub.t
OK, the Interpreter PMC interface is certainly flexible enough to
handle the introsp
On Nov 13, 2005, at 4:45, Chip Salzenberg wrote:
{ First, let's have a little applause for Leo for implementing the new
lexical scheme in, what, a week? He says it was only a half-day's
work, too. Nice work, dude! }
It was just half a day. The rest of the week was spent on unicode
improvem
{ First, let's have a little applause for Leo for implementing the new
lexical scheme in, what, a week? He says it was only a half-day's
work, too. Nice work, dude! }
First some background for those of you who haven't read pdd20:
* Read pdd20.
But if you don't have time:
* LexPads are PMCs
On Thu, 28 Jul 2005 15:46:14 +0300, Yuval Kogman
<[EMAIL PROTECTED]> wrote:
[...]
> I like your Pack object - that is the parsed template, but I'd also
> like to be able to generate these templates with a programmatic
> interface that isn't string concatenation...
>
> Is it just a simple data st
I have a fundamental disagreement with what pack used to be - it's
too stringish... =)
the printf and unpack syntaxes always bothered me because they are
akin to 'eval'ing, more than they are to quasi quoting.
I like your Pack object - that is the parsed template, but I'd also
like to be able to
Last night I had an idea about a possable pack API. Most likely when
Pugs gets signifigently powerfull I will attempt to implement it.
However I would like everyones input, below is a draft of its POD.
=head1 NAME
Pack - (un)pack structures as defined by a Template
=head1 SYNOPSIS
my Pack
Peter Hickman wrote:
> If we wrote a GUI library in parrot, a sort of Tkinter, and
> our widgets compiled down to parrot then we would have
> a consistent GUI library where widgets could be shared
> across languages and across platforms.
How about wxWindows?
http://www.wxwindows.org
Chec
> If we wrote a GUI library in parrot, a sort of Tkinter, and our
> widgets compiled down to parrot then we would have a consistent GUI
> library where widgets could be shared across languages and across
> platforms. Unlike the present situation where Tk widgets from Perl
> have to be rewritten f
At 10:39 AM + 2/4/02, Simon Cozens wrote:
>Peter Hickman:
>> If we wrote a GUI library in parrot, a sort of Tkinter, and our widgets
>> compiled down to parrot then we would have a consistent GUI library
>> where widgets could be shared across languages and across platforms.
>
>mmm. Nice, i
Peter Hickman:
> If we wrote a GUI library in parrot, a sort of Tkinter, and our widgets
> compiled down to parrot then we would have a consistent GUI library
> where widgets could be shared across languages and across platforms.
mmm. Nice, isn't it? Apple Carbon libraries first, though, I wan
A thought has occured to me.
If we wrote a GUI library in parrot, a sort of Tkinter, and our widgets
compiled down to parrot then we would have a consistent GUI library
where widgets could be shared across languages and across platforms.
Unlike the present situation where Tk widgets from Perl
12 matches
Mail list logo