Matt Creenan <[EMAIL PROTECTED]> wrote:
> hash_4.exe crashes, trying to read memory at 0x when running tests
> for hash.
Yep. Thanks - fixed.
On linux this silently segfaults. Shouldn't the test system report an
error in case of a SIGSEGV?
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ autorun of loaded byte code ]
>>But how to pass arguments then? Init code might need some.
> What arguments, though? This is just a chance to give the segment an
> initialization run, nothing more.
I don't. I don't know, what the autorun should initiali
On Sep-23, Leopold Toetsch wrote:
> Steve Fink <[EMAIL PROTECTED]> wrote:
>
> > Just to be sure we're talking about the same thing:
>
> > sub f ($a, $b, $c) { ... }
> > $x = phase_of_moon('waxing') ? \&f : \&CORE::print;
> > $x->(3, [EMAIL PROTECTED], [EMAIL PROTECTED]);
>
> I don't expect
Hi,
I'd like to add one more to the library of trivia languages. It is not
as strange as Bf or Ook! and it is actually a real (teaching) language.
Enter: URM
URM is a "language" at least used in German universities to teach the
basic principles of programming. URM stands for Universal Register
M
hash_4.exe crashes, trying to read memory at 0x when running tests
for hash.
t/src/hash..NOK 5# Failed test (t/src/hash.t at line 163)
# got: 'Can't spawn ".\t\src\hash_4.exe": Bad file descriptor at
lib/Parrot/Test.pm line 61.
# '
# expected: ''
# '.\t\src\hash_4.
Andy --
Thanks. That was a strange one. No complaint by my Perl, even with
"use warnings 'all';", but its definitely a typo (and now fixed, too).
Regards,
-- Gregor
On Mon, 2003-09-22 at 06:21, Andy Dougherty wrote:
> On Thu, 18 Sep 2003, Gregor N. Purdy wrote:
>
> > Andy --
> >
> > I didn't
At 11:13 PM +0200 9/23/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
I see we've got dynamically loaded bytecode segments. Good. What we don't
have is those segments automatically running, something I think we need to
have happen.
When a bytecode segment is loaded, control
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I see we've got dynamically loaded bytecode segments. Good. What we don't
> have is those segments automatically running, something I think we need to
> have happen.
> When a bytecode segment is loaded, control should pass to the first
> executable instruc
I see we've got dynamically loaded bytecode segments. Good. What we don't
have is those segments automatically running, something I think we need to
have happen.
When a bytecode segment is loaded, control should pass to the first
executable instruction in it, and proceed until it hits an end. (
As we don't have any libs yet, I thought, I start with an important one.
It works like Acme::DWIM.
Here is a sample run:
$ cat hello.imc
.pcc_sub _main prototyped
.include "DWIM.imc"
add $I0, 20, 22
print $I0
print "\nHello Parrot!\n"
end
.end
$ parrot hello.imc
42
Hello Parr
The Perl 6 Summary of the week ending 20030921
Deadlines, I love the sound they make as they fly past.
Those of you who receive this summary via mail may have noticed that
this summary is a little late, with any luck it will make up for its
tardiness by being inaccurate and badly w
"Brent Dax" <[EMAIL PROTECTED]> writes:
> Steve Fink:
> # > Following things were done:
> # > - s,/,\${slash},g
> #
> # Ugh. How difficult would it be to have Configure do this rewriting
> # automatically? (Or rewrite to whatever it is you need, instead)? This
> # just clutters up the makefiles a
"Brent Dax" <[EMAIL PROTECTED]> wrote:
> # > The result would mean that something like:
> # > pmc->vtable->add
> #
> # > Might become:
> # > pmc->vtable->math->add
> #
> # Seems too expensive to me for the normal math stuff.
>
> Perhaps, although one dereference doesn't seem to painful to me.
Is t
On Tue, 23 Sep 2003, Brent Dax wrote:
> Leopold Toetsch:
> # That's what happening anyway. All unimplemented stuff has a default
> hook
> # throwing an exception.
>
> The indirection would allow for a default set. It's the difference
> between eight default pointers per vtable (to default sectio
Leopold Toetsch:
# Dan was talking about one vtable slot, holding another vtable for trig
# and log functions. The newly added vtable->data seems to be that. This
# trig_log (or data) pointer is shared by all scalar classes. So that
# takes one additional pointer per vtable and one additional
trig_
I've not got time yet to write this up formally, but
There's no difference between calling a sub PMC with parameters and
invoking a return continuation with return values. The return values for
that continuation are just sent as parameters, as if you were calling it
as a function.
Yes, tha
Okay, it's time to deal with a particularly unpleasant
topic--cross-language namespace management.
This is *only* for those cases where we need to look things up by name in
some namespace (either global or lexical), and doesn't affect what we do
with the PMC we get back once we've done that.
> Here are some unit tests for the hash.h interface which are PerlHash
> free. It could be argued that they're superfluous, but given that there
> may well be other hash PMCs that use this code eventually, it might be
> worth testing it independently.
Tests are always welcome. Thanks, applied.
>
On Tue, 23 Sep 2003, Leopold Toetsch wrote:
> Steve Fink <[EMAIL PROTECTED]> wrote:
>
> > You seem to be suggesting something like:
>
> No. My suggestion didn't cover splat arrays. When you don't know, what
> sub you are calling, you just have to flatten the splatted args -
> currently.
>
> Ano
Just a reminder to the CVS committers -- when checking in code provided by
someone else, please make sure to credit them with a line:
Courtesy of: person
The colon's optional, but a good idea. It facilitates retrieving the
contact information of the person who contributed the patch. (I've us
On Mon, 22 Sep 2003, Gregor N. Purdy wrote:
> On a related note, I wonder how all this fits in with
> methods and multimethods?
One-arg vtable methods don't have to do multimethod stuff, since you're
calling the vtable method on the argument, so it can do the right thing
without checking.
Two
On Mon, Sep 22, 2003 at 04:08:24PM -0600, Luke Palmer wrote:
> And let's not forget our handy trig identities. We definitely don't
> need all those vtable. Technically, all we need are sine and arccosine.
I believe that atan2() is more useful than arccosine, as it returns
information about whic
Michael Scott <[EMAIL PROTECTED]> wrote:
> On OS X 10.2.6 (gcc 3.3) make dies with:
> perl build_nativecall.pl call_list.txt
> nci.c
> nci.c: In function `pcf_i_42p':
> nci.c:454: error: invalid lvalue in unary `&'
I see. Thanks fixed.
leo
The short story: We have really too much leaks, everywhere:
Failed 33/57 test scripts, 42.11% okay. 291/903 subtests failed, 67.77%
okay.
(A test is considered failing above, when it has more then 3 leaks
(which are known to leak currently - the stdio handles))
The longer story:
Parrot has si
Steve Fink <[EMAIL PROTECTED]> wrote:
> Just to be sure we're talking about the same thing:
> sub f ($a, $b, $c) { ... }
> $x = phase_of_moon('waxing') ? \&f : \&CORE::print;
> $x->(3, [EMAIL PROTECTED], [EMAIL PROTECTED]);
I don't expect such contrived functions calls happen too often, bu
Brent Dax <[EMAIL PROTECTED]> wrote:
> Okay, reality check. How often are we going to use acosh? Is it really
> worth the space in the vtable for that few calls? And why can't we just
> use find_method?
Dan was talking about one vtable slot, holding another vtable for trig
and log functions. T
On OS X 10.2.6 (gcc 3.3) make dies with:
perl build_nativecall.pl call_list.txt
nci.c
nci.c: In function `pcf_i_42p':
nci.c:454: error: invalid lvalue in unary `&'
On Sep-22, Leopold Toetsch wrote:
> Steve Fink <[EMAIL PROTECTED]> wrote:
> >> Then we need code from HLL to see, how efficient (or not) parameter
> >> passing does look like.
>
> > I've been trying to implement A6 for languages/perl6. My first cut was
> > to have all calls, prototyped or not, tak
28 matches
Mail list logo
