On Thu, 30 Oct 2003, Melvin Smith wrote:
> At 12:09 AM 10/31/2003 +, Nicholas Clark wrote:
> >On Thu, Oct 30, 2003 at 01:54:24AM -0500, Melvin Smith wrote:
> > > Parrot fetched its first web page tonight. Its a baby step, but hey... :)
> >
> >Can we do IPv6?
>
> Some of the changes are pretty
> So... Configure.pl needs to be able to build a makefile that has
> per-C-file flags, and those flags need to be overridable per-file at
> configure time by the platform configuration module.
Does the makefile need to be a typical 'make' makefile or is an all-perl
solution viable?
--
Dave
Isa. 4
On Tue, 3 Jun 2003, Matt Fowles wrote:
> Most of the ref counting systems provide for very simple ref counting
> containers and, essentially, provide timely destruction for the simple
> case where a variable is not placed into some more complicated
> container. It seems to me that if we are worri
On Tue, 31 Dec 2002, Dan Sugalski wrote:
> >I don't think any ops do that presently (that would take a PMC** param).
> Oh, sure, lots do. Remember the ops get a pointer to the PMC
> register, which is itself a pointer. Whatever you stuff in there is
> what the register is set to.
Right, I meant P
On Tue, 31 Dec 2002, Dan Sugalski wrote:
> At 1:29 PM -0500 12/31/02, David Robins wrote:
> >Maybe I missed it in the original thread, but what was the resolution on how
> >to create and return a new PMC in PMC ops that take a "PMC* dest" param?
>
> If the op defin
Maybe I missed it in the original thread, but what was the resolution on how
to create and return a new PMC in PMC ops that take a "PMC* dest" param?
Should I submit my pmc_placement_new() (also in that thread) as a patch?
(morph isn't sufficient because I don't want to coerce the destination into
On Tue, 31 Dec 2002, Jim Cromie wrote:
> pardon the lack of clue I reveal here, but..
>
> on 32 bit box, a void* has 3 values which are illegal/unaligned;
>
> void* ptr;
> if (ptr & 0x00) {
ITYM if(!(ptr & 0x3))
> /* ok */
> } else {
> /* some exceptional situation */
> }
> is there any
On Thu, 19 Dec 2002, Leopold Toetsch wrote:
> David Robins wrote:
> > This method is primarily used when the interpreter has need of
> > coercing a PMC to a particular type, and isn't meant as a general
> > purpose casting tool. Compilers should only emit valid
>
On Thu, 19 Dec 2002, Leopold Toetsch wrote:
> David Robins wrote:
> > On Wed, 18 Dec 2002, Leopold Toetsch wrote:
> >>morph "dest" to be a "ret"?
> >>unimplemented, unused, but your examples seems to be a typical test case.
> > "des
On Wed, 18 Dec 2002, Leopold Toetsch wrote:
> David Robins wrote:
> > if(value->vtable == &Parrot_base_vtables[enum_class_Vec2D_in_Y_plane]) {
>
> always compare ids (vtables may change) - yes, many pmc's do like above,
> but will need changes too.
What
What's the cleanest way to return a new PMC from an op?
e.g. Suppose I have a Vec2D_in_X_plane and a Vec2D_in_Y_plane and I add them
and want to always produce a Vec3D - is this correct (and is it efficient?):
void add(PMC* value, PMC* dest) {
if(value->vtable == &Parrot_base_vtables[enum_
On Tue, 17 Dec 2002, K Stol wrote:
> After doing some reading about Parrot, I got very interested. I'd like to
> write some kind of compiler for my Bacherlor's in Computer Science. I'm
> thinking of a compiler for Tcl which produces Parrot Assembly code, but
> the source language (which will be com
On Mon, 9 Dec 2002, Dan Sugalski wrote:
> At 12:27 AM + 12/7/02, Alex Gough wrote:
> >That is to say, in "if ( !exp1 ) { ... }", !exp1 merely has to be true
> >or false, while $foo = !exp1 leaves !exp1 needing to be all manner of
> >things.
>
> D'oh! Now it's obvious.
> I've been conflating th
On Sat, 7 Dec 2002, Alex Gough wrote:
> [Fri, Dec 06, 2002 at 05:01:21PM -0500: Dan Sugalski]
> > >- have not P0, P1 set P0 to $1->get_bool ? true : false
> >
> > Sure, that works. I can't think of a good reason to have PMCs be able
> > to return something fancier than true or false when
On Fri, 6 Dec 2002, Dan Sugalski wrote:
> At 5:47 PM -0500 12/3/02, David Robins wrote:
> >Adding an extra knob doesn't seem like all that good a solution (seems
> >you'd run into weird issues, like a boolean PMC that was both true and
> >false at the same t
I'd been looking for an option to IMCC to generate the PBC directly,
figuring from list postings that it was there, but didn't find it (-c) until
reading the recently updated ChangeLog. It's not in the syntax message IMCC
prints (with no args or -h or bad args), probably should be added.
Any answ
On Tue, 3 Dec 2002, Andy Dougherty wrote:
> On Thu, 21 Nov 2002, Leon Brocard wrote:
>
> > ps You might be concerned about the name. Well, CPAN has a module
> >which matches /fuck/ too. However, if everyone really thinks
> >it is a problem, I don't see a problem with s/fuck/funk/g
>
> Well
On Tue, 3 Dec 2002, Dan Sugalski wrote:
> At 4:29 PM -0500 12/3/02, David Robins wrote:
> >Enlightenment appreciated as always.
>
> This is something that'll come up with perl 6 reasonably soon as
> well. The solution for us is to have truth and falsehood be an
> optiona
Yes, me again
Most of the time, in the PMC logical_not method, one can write:
void logical_not (PMC* dest) {
dest->vtable->set_integer_native(INTERP,dest,NOT_SELF);
}
where NOT_SELF is 0 if we're "true" and 1 if we're "false". Or just leave
it out and let default blow up if
The hash_destroy function is in include/parrot/hash.h but not defined (or
invoked) anywhere. I presume this is because hashes are GC'd, so
hash_destroy can now be removed from the header file?
I take it the design of lexicals is still undecided, as
examples/assembly/lexicals.pasm coughs up errors
These all using the 2002-12-02_16 snapshot.
1. Can't ret early from .subs - looks like the parser sees a ret and figures
that's the end of the sub.
..sub foo
$P0 = 1
if $P0 goto bar
ret
bar:
print "BAR"
ret
Parse error at 'bar'.
2. Most things can only be done in a sub.
$P0 =
On Mon, 25 Nov 2002, Leopold Toetsch wrote:
> Dan Sugalski wrote:
>
> >> $1 = (INTVAL)((char)($1));
> >> The INTVAL could be a "long long".
> >
> > That one needs a sizeof(char) check. chars are *not* 8 bits everywhere.
>
> AFAIK are chars 8 bits by defintion, i.e. C standard. The machine
> repr
On Sun, 24 Nov 2002, Dan Sugalski wrote:
> At 9:20 AM -0500 11/24/02, Andy Dougherty wrote:
> >On Sat, 23 Nov 2002, David Robins wrote:
> >> When's the long double "KNOWN ISSUE" going to be fixed? What's the work
> >It's (at least partly) a
When's the long double "KNOWN ISSUE" going to be fixed? What's the work
around, just to build a perl with NV==double? I've looked around, can't
find anything about it except in KNOWN_ISSUES (only match in RT is
"Parrot_sprintf-related stuff"). Scan of the archives turns up nothing.
Thanks,
Dav
24 matches
Mail list logo
