Jonathan Worthington [EMAIL PROTECTED] wrote:
Hi,
This is a no-go for places where sizeof(INTVAL) is the same as
sizeof(FLOATVAL).
I know. It'll be replaced RSN.
Jonathan
leo
On Thu 25 Mar 2004 07:42, Jarkko Hietaniemi [EMAIL PROTECTED] wrote:
Larry Wall wrote:
On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote:
: I'd like to propose the following optimisation:
: if an attempt is made to load anything over the network
: (without cryptographic
Hello,
Tell me please where $PConfig{'i_pthread'} is defined?
I want use this paramet into t/pmc/threads.t for detect that parrot has
being built with thread on NetBSD.
Nick.
I'm trying to write some documentation for the ops2c system at the
moment and have a question.
In Parrot::OpsFile::read_ops() a Parrot::Op's type is set to 'inline'
or 'function', yet in Parrot::Op type is expected to be 'auto' or
'manual'.
Auto ops have a 'goto NEXT()' appended to their
Dan Sugalski [EMAIL PROTECTED] wrote:
Right. That's why the stack frames have to be garbage collected--only
the DOD knows when one's truly not used any more.
Done (again).
leo
Nick Kostirya [EMAIL PROTECTED] wrote:
Hello,
Tell me please where $PConfig{'i_pthread'} is defined?
It's missing in our config system. Wanted.
Nick.
leo
[EMAIL PROTECTED] (Dan Sugalski) writes:
At 5:48 PM -0500 3/23/04, Joe Schaefer wrote:
[...]
IMO, the advantage would be that parrot apps will have a better idea
of what security model is appropriate.
Well... maybe.
Parrot apps don't get a whole lot of say here--this is more on the
Larry Wall [EMAIL PROTECTED] writes:
On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote:
: just system(rm -rf /;halt)
Sorry, that won't work correctly, since the rm will remove the halt
program.
Not necessarily. There's a chance it will remove 'rm' and 'rmdir'
before 'halt'.
[EMAIL PROTECTED] wrote:
It can be safe. Normally, PCC works by certifying the code during
compilation, and attaching the machine-checkable certificate with the
resulting compiled code (be that bytecode, machine code or whatever).
During runtime, a certificate checker then validates the
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi guys,
http://www.cs.purdue.edu/homes/hosking/690M/urc-oopsla-2003.pdf
Two-line summary:
* gives as good performance as the best generational garbage
collectors today, with
All these generational collectors don't work with Parrot
On 25/03/2004, at 9:01 PM, Leopold Toetsch wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi guys,
http://www.cs.purdue.edu/homes/hosking/690M/urc-oopsla-2003.pdf
Two-line summary:
* gives as good performance as the best generational garbage
collectors today, with
All these
Ok. if I change that line, the program no longer infinite loops.
However, argv is still trounced.
On Thursday, March 25, 2004, at 02:59 AM, Leopold Toetsch wrote:
Will Coleda [EMAIL PROTECTED] wrote:
Is there a bug in my code?
Yes.
invokecc P2
Your are destroying the callers return
Tell me please where $PConfig{'i_pthread'} is defined?
It's missing in our config system. Wanted.
Oh, looks like I said it wrong.
I do have package Parrot::Config :-).
Please let me know at which moment $PConfig{'i_pthread'} value is set and
where in the code I can find it.
Use of grep gave
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On 25/03/2004, at 9:01 PM, Leopold Toetsch wrote:
All these generational collectors don't work with Parrot objects. We
guarantee that objects don't move around.
Oh, I didn't see a mention of this in a PDD. What's the reason for why
you provide
At 1:06 PM -0500 3/24/04, Joe Schaefer wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
At 5:48 PM -0500 3/23/04, Joe Schaefer wrote:
[...]
IMO, the advantage would be that parrot apps will have a better idea
of what security model is appropriate.
Well... maybe.
Parrot apps don't get a
Will Coleda [EMAIL PROTECTED] wrote:
Ok. if I change that line, the program no longer infinite loops.
However, argv is still trounced.
Ah sorry, I did miss that in your first post. First, exceptions are
really very experimental, especially when they resume. Anyway, the
PerlArray (in P5) is
Nick Kostirya [EMAIL PROTECTED] wrote:
Tell me please where $PConfig{'i_pthread'} is defined?
It's missing in our config system. Wanted.
Oh, looks like I said it wrong.
I do have package Parrot::Config :-).
Please let me know at which moment $PConfig{'i_pthread'} value is set and
where
You might have got an entry from your perl5, which is of no use for
Parrot.
Thank you.
I see!
It's config/auto/headers.pl have
for (keys %Config) {
next unless /^i_/;
Configure::Data-set($mapping{$_}||$_, $Config{$_});
}
There is no PConfig option that some threading
I've fixed up the dependency problem in the makefile generation that
was getting in the way of multithreaded makes. Shouldn't cause any
problems, but it never hurts to double-check these things elsewhere.
Also, as I've been poking around in the make code, I'm finding myself
less and less
Do bear in mind that Perl can execute bits of code as it's compiling,
so if a bit of code is untrustworthy, you shouldn't be compiling it
in the first place, unless you've prescanned it to reject Cuse,
CBEGIN, and other macro definitions, or (more usefully) have hooks
in the compiler to catch and
Dan Sugalski [EMAIL PROTECTED] wrote:
2) The stack entry has to look something like:
struct {
struct IntStackFrame *prev;
INTVAL Registers[REGSPERFRAME];
} IntStackFrame;
Ok, now we something like that:
typedef struct Stack_Chunk {
pobj_t obj;
int
So, I'm doing these, because I need 'em, and we might as well get the
things in now. For the record, these things will be called as
functions (not methods), with three parameters, so the signature
looks like:
.pcc_sub thingie prototyped
.param pmc left
.param pmc right
.param
Leopold Toetsch [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On 25/03/2004, at 9:01 PM, Leopold Toetsch wrote:
All these generational collectors don't work with Parrot objects. We
guarantee that objects don't move around.
Oh, I didn't see a mention of this in a PDD.
Larry Wall wrote in perl.perl6.internals :
Do bear in mind that Perl can execute bits of code as it's compiling,
so if a bit of code is untrustworthy, you shouldn't be compiling it
in the first place, unless you've prescanned it to reject Cuse,
CBEGIN, and other macro definitions, or (more
How do you make the copy/move of the object from one location in memory and
the update of the pointer to the pointer ATOMIC? If you don't, it doesn't
matter how many layers of indirection you have, it will still be a problem
;^)
-Original Message-
From: Piers Cawley [mailto:[EMAIL
Rafael Garcia-Suarez wrote:
prevent
eval 'while(1){}'
or
eval '$x = take this! x 1_000_000'
Or hog both (for a small while):
eval 'while([EMAIL PROTECTED],0){}'
or my personal favourite, the always funny
eval 'CORE::dump()'
unless you set up a very restrictive set of
At 11:35 PM +0200 3/25/04, Jarkko Hietaniemi wrote:
Rafael Garcia-Suarez wrote:
prevent
eval 'while(1){}'
or
eval '$x = take this! x 1_000_000'
Or hog both (for a small while):
eval 'while([EMAIL PROTECTED],0){}'
Which, if the interpreter's running with quotas, will be caught
Gerald Butler [EMAIL PROTECTED] wrote:
[ message history rearranged - please don toppost - I hope that got the
right levels of indentation ]
From: Piers Cawley [mailto:[EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] writes:
PMCs are passed on to (external) C code. When inmidst of C
Butler, Gerald [EMAIL PROTECTED] writes:
How do you make the copy/move of the object from one location in
memory and the update of the pointer to the pointer ATOMIC? If you
don't, it doesn't matter how many layers of indirection you have, it
will still be a problem ;^)
You only do it
# New Ticket Created by Will Coleda
# Please include the string: [perl #27959]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27959
With the thought that anything more frequent than every six months is
good,
# New Ticket Created by Matt Fowles
# Please include the string: [perl #27961]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27961
All~
The subject says it all.
Matt
Index: src/register.c
# New Ticket Created by Will Coleda
# Please include the string: [perl #27962]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27962
Here's an untested patch to fix the split op's warning.
Index: ops/string.ops
Would a patch be accepted that let split work on non empty strings (not
treated as REs) as a stopgap until RE support?
On Thursday, March 25, 2004, at 10:51 PM, Will Coleda (via RT) wrote:
# New Ticket Created by Will Coleda
# Please include the string: [perl #27962]
# in the subject line of
I knew I should have updated to cvs latest before issuing a tcl
release. =)
(go ahead and apply that patch, I'll get things fixed as soon as I can.)
If I run a very short tcl program, ala:
set a(b) whee
puts -
I get a crash in parrot, ala:
Exception: EXC_BAD_ACCESS (0x0001)
Codes:
On Tue, 2004-03-23 at 13:11, Goplat wrote:
@(...) is the list context operator in S3. I hope array references won't
explode in list context, that would be very annoying when making
multi-dimentional arrays:
@foo = ([1, 2], [3, 4]) # oops, would be (1, 2, 3, 4)
@foo = ($([1, 2]),
Aaron Sherman writes:
I would expect [] to force itself into scalar context anyway. Is there
ever a reason to want otherwise? Clearly the entire point of [] is to
create a scalar array ref from a list of arguments.
More to the point is there ever a reason to want any array ref in list
On Thu, Mar 25, 2004 at 08:42:53AM -0700, Luke Palmer wrote:
: Aaron Sherman writes:
: More to the point is there ever a reason to want any array ref in list
: context to NOT explode other than []? I can't think of any.
:
: push @a, $b
:
: Is it too non-obvious that if $b is an array
Larry Wall wrote:
say @bar.elems; # prints 1
Csay? Not Cprint?
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
On Thu, Mar 25, 2004 at 11:35:46AM -0800, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall wrote:
: say @bar.elems;# prints 1
:
: Csay? Not Cprint?
It's just a println spelled Huffmanly.
Larry
# New Ticket Created by Will Coleda
# Please include the string: [perl #27966]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27966
.sub main
.param pmc argv
$S0 = argv[1]
$I2 = $S0
$P2 = new
# New Ticket Created by Will Coleda
# Please include the string: [perl #27969]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27969
This rather dodgy bit of code
.sub main
$S0 = read $P1, 1
end
.end
Causes
Ah. this appears to be the same stack trace already noted by: Mitchell
N Charity
On Thursday, March 25, 2004, at 11:56 PM, Will Coleda wrote:
I knew I should have updated to cvs latest before issuing a tcl
release. =)
(go ahead and apply that patch, I'll get things fixed as soon as I
can.)
Here's version 0.01 of ParrotUnit, my port of the xUnit testing
framework to Parrot. It allows you to write your tests for parrot
applications using object oriented parrot. Untar it in your parrot
directory then do
$ parrot t/test.imc
1..3
ok 1 testTemplateMethod
ok 2
Will Coleda (via RT) wrote:
One patch with changes:
Doesn't apply:
patching file languages/tcl/lib/commands/array.imc
Reversed (or previously applied) patch detected! Assume -R? [n]
$ grep ^Index tcl_20030325.patch | grep array
Index: languages/tcl/lib/commands/array.imc
Index:
Will Coleda [EMAIL PROTECTED] wrote:
I knew I should have updated to cvs latest before issuing a tcl
release. =)
... and before sending bug reports ;)
The hash/_dumper interaction bug vanished ...
$ parrot hash-bug.imc 1000 | tail -3
998 = undef,
999 = undef
}
... as very likely the
Will Coleda [EMAIL PROTECTED] wrote:
Here's an untested patch to fix the split op's warning.
Thanks, applied.
leo
I'm still seeing both bugs, with a cvs update, make realclean; perl
Configure.pl, make. (if I do a cvs diff in my repo, the only changed
files are tcl related.)
What other intel do you need to help duplicate the bugs?
FWIW, I do see that Mitchell's program is not segfaulting, so while my
47 matches
Mail list logo
