At 7:07 PM -0700 4/30/04, Jeff Clites wrote:
On Apr 30, 2004, at 10:22 AM, Dan Sugalski wrote:
At 2:57 AM +1000 5/1/04, Andre Pang wrote:
Of course Parrot should have a function to reinterpret something
of a string type as raw binary data and vice versa, but don't mix
binary data with strings: t
On Apr 30, 2004, at 9:02 AM, Larry Wall wrote:
On Fri, Apr 30, 2004 at 08:38:18AM -0700, Jeff Clites wrote:
: On Apr 28, 2004, at 5:01 AM, Dan Sugalski wrote:
:
: >At 3:17 AM -0700 4/28/04, Jeff Clites wrote:
: >>On Apr 23, 2004, at 2:43 PM, Dan Sugalski wrote:
: >>
: >>>For example, consider the
On Apr 30, 2004, at 10:22 AM, Dan Sugalski wrote:
At 2:57 AM +1000 5/1/04, Andre Pang wrote:
Of course Parrot should have a function to reinterpret something of a
string type as raw binary data and vice versa, but don't mix binary
data with strings: they are completely different types, and raw
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> If you want, you could think of the S-register strings as mini-PMCs.
> The encoding and charset stuff (we'll ignore language semantics for
> the moment) are essentially small vtables that hang off the string,
I think its the cleanest way of implementing a
At 4:15 PM -0400 4/30/04, Bryan C. Warnock wrote:
On Fri, 2004-04-30 at 15:34, Dan Sugalski wrote:
If you want, you could think of the S-register strings as mini-PMCs.
The encoding and charset stuff (we'll ignore language semantics for
the moment) are essentially small vtables that hang off the
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> If I understand this correctly, then this is far more restrictive than the
> perl5 embedding interface.
This is *one* way to start things up. You can start the app with
Parrot_run_native. You can set the stack top. You can register each PMC
with dod_reg
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 30, 2004 at 06:25:50PM +0200, Leopold Toetsch wrote:
>> register each PMC with C.
> But I suspect that there will be embedders of parrot who want to do this -
> register only 1 or 2 PMCs
Th
At 2:58 PM -0400 4/30/04, Bryan C. Warnock wrote:
On Fri, 2004-04-30 at 13:53, Dan Sugalski wrote:
Parrot, at the very low levels, makes no distinction between strings
and buffers--as far as it's concerned they're the same thing, and
either can hang off an S register. (Ultimately, when *I* talk
On Apr 30, 2004, at 9:35 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
Yes, my intention there was for read-as-strings, you'd push a
string-ification layer onto the stack. For byte-wise IO, you wouldn't.
Ok. I/O maintainers, please jump in.
And my thoughts in this regard, to b
At 12:18 PM -0400 4/30/04, Butler, Gerald wrote:
A string is what Dan described in his various postings on strings. Nuff
said.
Gerald Butler responds:
Yes, I know a "String" is what Dan described. He described a thingy
made up of 32-bit Values where each value represented a "Code-Point". Now,
-Original Message-
From: Aaron Sherman [mailto:[EMAIL PROTECTED]
Sent: Friday, April 30, 2004 11:58 AM
To: Butler, Gerald
Cc: Perl6 Internals List
Subject: RE: Bit ops on strings
On Fri, 2004-04-30 at 09:47, Butler, Gerald wrote:
> If I may interject for a moment:
Let me start by sayin
At 2:57 AM +1000 5/1/04, Andre Pang wrote:
Of course Parrot should have a function to reinterpret something of
a string type as raw binary data and vice versa, but don't mix
binary data with strings: they are completely different types, and
raw binary data should never be able to be put into a s
On Fri, Apr 30, 2004 at 06:25:50PM +0200, Leopold Toetsch wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > This is true. And yes you need to set a stack top if you're expecting the
> > stack walking to find things you own. But I'm thinking about the case where
> > the embedding app registe
On 30/04/2004, at 11:47 PM, Butler, Gerald wrote:
1. String - low-level, abstract, base class (or in Perl6 terms role --
I think) which represents a "logically" contiguous series of Parrot Int
2. BinaryString - inherits from String, represents a "logically"
contiguous series of "by
On Fri, 2004-04-30 at 12:18, Butler, Gerald wrote:
> Now, we
> have people talking about doing "LSL/LSR" on "Strings". That is 100%
> inconsistent with that definition of a "String".
Not at all, and keep in mind that I didn't propose this out of the blue.
"bands", "bxors" and "bors" are existing
On Fri, Apr 30, 2004 at 06:25:50PM +0200, Leopold Toetsch wrote:
> Well, Parrot does DOD/GC. It'll not start refcounting ... But I really
> don't think, that this is an issue. You just need to start your app like
> this:
>
> main() {}
> void *stack_top;
> return real_main(stack_top); /
On Fri, 2004-04-30 at 05:48, Dan Sugalski wrote:
> If it alters the way things look to bytecode, just make sure to
> update the docs and patch up the existing wrapping libraries.
I'll take a look at Leo's new docs and patch everything with an
offending signature in src/call_list.txt.
Anyone who
Jeff Clites <[EMAIL PROTECTED]> wrote:
> Yes, my intention there was for read-as-strings, you'd push a
> string-ification layer onto the stack. For byte-wise IO, you wouldn't.
Ok. I/O maintainers, please jump in.
leo
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 30, 2004 at 01:54:58PM +0200, Leopold Toetsch wrote:
> And instead the perl regression tests that use SIGHUP fail.
> (There are also tests on SIGUSR1, but not SIGUSR2, it seems)
Argh. I grepped through all perl 5.8.0 tests and didn't find SI
On Fri, Apr 30, 2004 at 08:59:55AM -0700, Jeff Clites wrote:
: >I can't imagine that
: >we use a different data type, this would totally mess with Perl
: >compatibility.
:
: Not necessarily (or, that wasn't my intention). For Ponie, we can do
: this:
Anded or ored?
: 1) Just always implicitly a
On Fri, Apr 30, 2004 at 01:54:58PM +0200, Leopold Toetsch wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
>
> > 1: Right now, would it be possible for parrot only to install its signal
> >handlers when it starts the runloop?
> >(given that ponie isn't using the runloop)
>
> Currently P
Chromatic <[EMAIL PROTECTED]> wrote:
> Following up on the idea Leo and I discussed this morning, here's a
> patch that expects integer out parameters to be wrapped in some sort of
> INTVALy PMCs.
Thanks, applied + changed '2' and '4' too + JIT/i386.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> If it alters the way things look to bytecode, just make sure to
> update the docs and patch up the existing wrapping libraries.
Docs are adapted. Needed code changes:
old for signature "i3i":
I5 = arg1
I6 = arg2
new
new P5, .PerlInt
P5 = arg1
On Fri, Apr 30, 2004 at 08:38:18AM -0700, Jeff Clites wrote:
: On Apr 28, 2004, at 5:01 AM, Dan Sugalski wrote:
:
: >At 3:17 AM -0700 4/28/04, Jeff Clites wrote:
: >>On Apr 23, 2004, at 2:43 PM, Dan Sugalski wrote:
: >>
: >>>For example, consider the following:
: >>>
: >>> use Unicode;
: >>> ope
On Apr 28, 2004, at 11:25 PM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
On Apr 28, 2004, at 4:57 AM, Bryan C. Warnock wrote:
Does (that which the masses normally refer to as) binary data
fall inside or outside the scope of a string?
Some languages make this very clear by prov
On Fri, 2004-04-30 at 09:47, Butler, Gerald wrote:
> If I may interject for a moment:
Let me start by saying that I have not drunk the Unicode cool-aid. I'm
not at all certain that the overhead required to do all of what Parrot
wants to do is warranted, BUT that's beside the point.
Parrot is doin
On Apr 28, 2004, at 5:01 AM, Dan Sugalski wrote:
At 3:17 AM -0700 4/28/04, Jeff Clites wrote:
On Apr 23, 2004, at 2:43 PM, Dan Sugalski wrote:
For example, consider the following:
use Unicode;
open FOO, "foo.txt", :charset(latin-3);
open BAR, "bar.txt", :charset(big5);
$filehandle = 0;
Besides fixing a bug in the PMC compiler, this changes bxor_p_p_p to use
MMD. Nothing fancy yet, just to see, what's needed in the PMC compiler.
BTW registering the default for [.PerlInt, 0] segfaults, so this isn't
done yet. (perlint.pmc:class_init)
Dan, can you please have a look at the segfa
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> 1) Mark the overload subs as special and change their calling conventions
Different calling conventions are not really pleasant for the
compiler(s). But doable.
> 2) Wrap the overload subs in some bytecode that Does The Right
> Thing--takes a continuatio
On Fri, 2004-04-30 at 10:42, Dan Sugalski wrote:
> Bitstring operations ought only be valid on binary data, though,
> unless someone can give me a good reason why we ought to allow
> bitshifting on Unicode. (And then give me a reasoned argument *how*,
> too)
100% agree. If you want to play gam
If I may interject for a moment:
-Original Message-
From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]
Sent: Friday, April 30, 2004 9:08 AM
To: Dan Sugalski
Cc: Perl6 Internals List
Subject: Re: Bit ops on strings
On Thu, 2004-04-29 at 13:04, Dan Sugalski wrote:
> I think left and right sh
At 9:07 AM -0400 4/30/04, Bryan C. Warnock wrote:
On Thu, 2004-04-29 at 13:04, Dan Sugalski wrote:
I think left and right shift of strings should work the same way that
shifts on ints works--that is, it doesn't grow, bits just fall off
the end. You can decide whether to sign-extend or 0-extend,
At 7:44 AM +0200 4/30/04, Leopold Toetsch wrote:
Chromatic <[EMAIL PROTECTED]> wrote:
Following up on the idea Leo and I discussed this morning, here's a
patch that expects integer out parameters to be wrapped in some sort of
INTVALy PMCs.
This solves my problem rather nicely.
Good. As soon a
At 11:35 AM +0200 4/30/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
If we go MMD all the way, we can skip the bytecode->C->bytecode
transition for MMD functions that are written in parrot bytecode, and
instead dispatch to them like any other sub.
Not really. Or not w/o sign
At 10:39 AM +0200 4/30/04, Leopold Toetsch wrote:
- There is only an is_equal vtable but an MMD_STREQ define and
default function
- {eq,ne}_{str,num} opcodes are using VTABLE_cmp, which is fine but
could be inefficient especially for strings
- cmp/cmp_num is handled by the same MMD slot
Yeah, we
At 9:37 AM -0400 4/29/04, William Coleda wrote:
Leopold Toetsch wrote:
- TclInt
- TclFloat
- TclObject
- TclString
This is a small subset of PMCs enumerating *current* scalars. I can't
imagine that e.g. tcl is happy, when a tcl scalar falls back to a morphing
variant of a Perl scalar. OTOH just do
On Thu, 2004-04-29 at 13:04, Dan Sugalski wrote:
> I think left and right shift of strings should work the same way that
> shifts on ints works--that is, it doesn't grow, bits just fall off
> the end. You can decide whether to sign-extend or 0-extend, either
> one's OK.
Have we[1] finished work
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> 1: Right now, would it be possible for parrot only to install its signal
>handlers when it starts the runloop?
>(given that ponie isn't using the runloop)
Currently Parrot installs just one handler (SIGHUP) for testing only.
See src/events.c. So
Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> Here's a first tentative test result on win32, with VC 7.1 and
>> nmake, ICU 2.8 (win32 binary build). Is any of this unexpected?
>> Failed Test Stat Wstat Total Fail Failed List of Failed
>> --
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> 'libnci.so' is used for testing the native call interface. However I noticed
> that the tests in t/pmc/nci.t were skipped, because 'libnci.so' wasn't built
> by default. The attached patch adds that library to the target 'all'.
Good. Do we have cu
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> ... Operator overloading has to
> have some cost :)
$ ./bench -b=over#[1]
Numbers are relative to the first one. (lower is better)
p-j-Oc perl-th perlpython ruby
overload100%151%131%- -
Not too bad,
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> If we go MMD all the way, we can skip the bytecode->C->bytecode
> transition for MMD functions that are written in parrot bytecode, and
> instead dispatch to them like any other sub.
Not really. Or not w/o significant overhead for MMD functions
implemented
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #29257]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29257 >
Hi,
'libnci.so' is used for testing the native call interface. However I not
Leopold Toetsch wrote:
- TclInt
- TclFloat
- TclObject
- TclString
This is a small subset of PMCs enumerating *current* scalars. I can't
imagine that e.g. tcl is happy, when a tcl scalar falls back to a morphing
variant of a Perl scalar. OTOH just doing the math operations would be
fine. So wha
> Here's a first tentative test result on win32, with VC 7.1 and
> nmake, ICU 2.8 (win32 binary build). Is any of this unexpected?
> Failed Test Stat Wstat Total Fail Failed List of Failed
> ---
> t\pmc\perlnum.t1
I checked out the development copy of ICU from CVS and am now able to get
parrot to statically link to ICU. It however coredumps everytime parrot
is invoked.
My guess is either parrot's internals are too focused on the 2.6.1 of ICU
or I haven't really had as much success as I thought with ICU.
I
- There is only an is_equal vtable but an MMD_STREQ define and default
function
- {eq,ne}_{str,num} opcodes are using VTABLE_cmp, which is fine but
could be inefficient especially for strings
- cmp/cmp_num is handled by the same MMD slot
leo
47 matches
Mail list logo
