Aaron Sherman <[EMAIL PROTECTED]> wrote:
> rand/srand
Arent ops (yet[1]) but "methods" of the Random PMC, I've put in some time
ago. It's not too much documentated though, but you can get random ints
in a range or numbers between 0 and 1 and do a srand. See
F and F.
> sqrt
Seems rea
At 5:38 PM -0400 4/23/04, Aaron Sherman wrote:
I'm trying to write some code, and I'm not finding certain ops.
rand/srand
sqrt
Those are both missing, which is odd--I thought we had them in at one
point, and there's support code for random numbers in utils.c. There
is a random nu
On Fri, 2004-04-23 at 14:38, Aaron Sherman wrote:
> I'm trying to write some code, and I'm not finding certain ops.
> rand/srand
> sqrt
I was surprised not to see something like signbit. It's in my
config/gen/platform/generic/math.h.
Then again, I tend to skim documentation. :)
-
Hi,
I'm kinda tied up with stuff, but just to flag up a Win32 build issue...
src\global_setup.c
global_setup.c
NMAKE : fatal error U1073: don't know how to make 'src\interpreter.str'
Stop.
Is tacked on. Note that we *do* have to support as core languages
which don't force unicode universally (perl 5, python, and ruby)
*and* we have to support the writing of stream filters in pure
parrot, so the goal of 100% pure unadulterated Unicode except at the
very edge isn't attainable, no m
I'm trying to write some code, and I'm not finding certain ops. Now,
perhaps this is just that I don't know how to look for them, or perhaps
they have yet to be written, so please pardon my ignorance. These are
things that seem fairly atomic, and which exist in the C library. If
they truly don't ex
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-04-23 at 14:52, Leopold Toetsch wrote:
>>
>> I'd posted that as well. Here again with an O3 build of parrot:
> Oops, missed that. Thanks! I'm shocked by the difference in
> performance... it makes me wonder how efficient the optimization+JIT
On Fri, Apr 23, 2004 at 03:14:47PM -0400, Dan Sugalski wrote:
: It also depends on whether the type is on the name or the container.
: Which is your call. :-P (Though, given my druthers, I'd leave it on
: the container)
We should certainly leave them on the container. The sin of rebinding
a nam
At 3:25 PM -0400 4/23/04, Aaron Sherman wrote:
That I did not know about, but noticed Dan pointing it out too. I'm
still learning a lot here,
It might be best, for everyone's peace of mind, blood pressure, and
general edification, to take a(nother) run through the documentation.
The stuff in docs
Nick Glencross <[EMAIL PROTECTED]> wrote:
> The problem is that $I13 has become *I16*, not (say) I17, so the line
> $I13 = word & 0xff00
> has actually had the side effect of changing 'word'.
Well C and C<$I13> or some such is the same for the compiler. Both
need a Parrot register allocatio
On Fri, 2004-04-23 at 14:52, Leopold Toetsch wrote:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
>
> > What might be interesting is to compare Parrot to Parrot doing this with
> > and without a hyper-operator. That's all I was trying to say.
>
> I'd posted that as well. Here again with an O3 build
At 11:53 AM -0700 4/23/04, Larry Wall wrote:
On Fri, Apr 23, 2004 at 11:47:28AM -0700, Jeff Clites wrote:
: That's my worry--whether we have a problem. (No problem with typed
: values, of course.) If variables are typed, _and_ that typing is
: lexically scoped, then I think that we don't have a pro
At 7:04 PM +0100 4/23/04, Simon Cozens wrote:
[EMAIL PROTECTED] (Jeff Clites) writes:
So what does "$foo = 12" in that context actually mean in Perl6?
Another interesting question is "in Perl 6, are variables typed, values typed,
or a little of both?"
It seems that Parrot has been working primaril
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> What might be interesting is to compare Parrot to Parrot doing this with
> and without a hyper-operator. That's all I was trying to say.
I'd posted that as well. Here again with an O3 build of parrot:
$ time parrot ih.imc
6060
real0m0.214s
user
On Fri, Apr 23, 2004 at 11:47:28AM -0700, Jeff Clites wrote:
: That's my worry--whether we have a problem. (No problem with typed
: values, of course.) If variables are typed, _and_ that typing is
: lexically scoped, then I think that we don't have a problem, and it can
: be handled at the compi
On Fri, Apr 23, 2004 at 12:46:04PM -0400, Dan Sugalski wrote:
: Sure, that's doable, as are a number of other things. Depends on the
: semantics of assignment to uninitialized types, though that's on a
: per-type basis. This all gets somewhat messy when you mix in objects
: and types, since what
On Apr 23, 2004, at 11:04 AM, Simon Cozens wrote:
[EMAIL PROTECTED] (Jeff Clites) writes:
So what does "$foo = 12" in that context actually mean in Perl6?
Another interesting question is "in Perl 6, are variables typed,
values typed,
or a little of both?"
It seems that Parrot has been working pr
Leopold Toetsch wrote:
Well. That's it. Just use $I10 ... $I13 and they will stay what they
were. Put a print thereafter for debugging which uses these regs.
I should have emphasised the oddity a bit better.
'word' has mapped to I16 correctly, and I17 has been used for
$I10..$I12. That's fin
At 2:09 PM -0400 4/23/04, Aaron Sherman wrote:
As for the DOD: you have an excellent point, but it extends far beyond
the hyper-operators. I'm starting to think that front-ends like the
Python compiler or the Perl 6 compiler are going to need controls over
the DOD for just the reasons you cite. Aft
Nick Glencross <[EMAIL PROTECTED]> wrote:
> $I10 = word & 0x00ff
> $I11 = word & 0xff00
> $I12 = word & 0x00ff
> $I13 = word & 0xff00
> and the resulting code becomes
> band I17, I16, 0x00ff
> band I17, I16, 0xff00
> band
Note: We've moved past hyper-ops (I hope!), but there are still some
details in this post that deserve a response on tangential topics.
On Wed, 2004-04-21 at 11:52, Leopold Toetsch wrote:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > That's unrealistic.
>
> No. A real test.
Sorry, I was not c
[EMAIL PROTECTED] (Jeff Clites) writes:
> So what does "$foo = 12" in that context actually mean in Perl6?
Another interesting question is "in Perl 6, are variables typed, values typed,
or a little of both?"
It seems that Parrot has been working primarily on the assumption that it's
values that a
At 7:02 PM +0100 4/23/04, Nick Glencross wrote:
Ok, so doing a 'parrot -d 8' shows that word doesn't seem to
interfere with $I13 as far as it is concerned ...
Dumping the Interf. graph:
---
...
word -> $I10 $I11 $I12 (3)
...
$I10 -> word (1)
$I11 -> word (1
At 10:35 AM -0700 4/23/04, Jeff Clites wrote:
On Apr 23, 2004, at 8:54 AM, Larry Wall wrote:
On Fri, Apr 23, 2004 at 08:42:28AM -0400, Dan Sugalski wrote:
: Since any type potentially has assignment behaviour, it has to be a
: constructor. For example, if you've got the Joe class set such that
:
Ok, so doing a 'parrot -d 8' shows that word doesn't seem to interfere with
$I13 as far as it is concerned ...
Dumping the Interf. graph:
---
...
word -> $I10 $I11 $I12 (3)
...
$I10 -> word (1)
$I11 -> word (1)
$I12 -> word (1)
$I13 -> (0)
...
I won
On Apr 23, 2004, at 8:54 AM, Larry Wall wrote:
On Fri, Apr 23, 2004 at 08:42:28AM -0400, Dan Sugalski wrote:
: Since any type potentially has assignment behaviour, it has to be a
: constructor. For example, if you've got the Joe class set such that
: assigning to it prints the contents to stderr,
>>This works as long as people (a) know of (b) stick to the policy
>>("Interp for internal use only") (c) No application embedding Parrot
>>has defined "Interp" themselves. Experience has shown that none of
>>these is likely to happen and/or stay that way for long :-)
>
>
> (c) is the reason for
I've now reduced the code down to this, a much simpler example [don't expect
it to run!]
Regards,
Nick
.sub _md5_create_buffer
.param string str
.local int word
$I0 = length str
$I1 = $I0 / 64
$I2 = $I0 % 64
$I3 = 64 * $I1
word = 0
md5_create_buffer_loop:
At 8:03 PM +0300 4/23/04, Jarkko Hietaniemi wrote:
Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
I hope it's not in there in the first place. The prefix needs to stay.
The declaration has been (along the lines of)
typedef struct Parrot_Interp {
...
} Interp;
for
Guys,
I'll log a bug for this if need be, but I'd rather solve the problem myself
(with some help). I'm in the middle of writing a routine (MD5 hashing for
fun), and stumbled upon the following code generation problem in imcc.
In the attached code, I've got
$I10 = word & 0x00ff
$
Brent 'Dax' Royal-Gordon wrote:
> Dan Sugalski wrote:
>
>>I hope it's not in there in the first place. The prefix needs to stay.
>
>
> The declaration has been (along the lines of)
>
> typedef struct Parrot_Interp {
> ...
> } Interp;
>
> for years. The Interp typedef is in
At 9:30 AM -0700 4/23/04, chromatic wrote:
On Fri, 2004-04-23 at 05:42, Dan Sugalski wrote:
Since any type potentially has assignment behaviour, it has to be a
constructor. For example, if you've got the Joe class set such that
assigning to it prints the contents to stderr, this:
my Joe $f
Leopold Toetsch wrote:
Jens Rieks wrote:
I've prepared a patch for it.
Why do you change all to the longest declaration of Parrot_Interp?
We have in decreasing length
struct parrot_interp_t *
struct Parrot_Interp *
Parrot_Interp
Interp *
We need the structure declaration which could be 1) or
On Fri, 2004-04-23 at 05:42, Dan Sugalski wrote:
> Since any type potentially has assignment behaviour, it has to be a
> constructor. For example, if you've got the Joe class set such that
> assigning to it prints the contents to stderr, this:
>
> my Joe $foo;
> $foo = 12;
>
> should p
At 9:19 AM -0700 4/23/04, Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
At 6:48 PM +0300 4/23/04, Jarkko Hietaniemi wrote:
>>>You're welcome to try it again, though...while you're at it, you might
as well make all internal Parrot functions take an Interp * instead of a
I hope there's #u
Dan Sugalski wrote:
At 6:48 PM +0300 4/23/04, Jarkko Hietaniemi wrote:
>>>You're welcome to try it again, though...while you're at it, you
might
as well make all internal Parrot functions take an Interp * instead
of a
I hope there's #undef Interp in there somewhere.
I hope it's not in the
At 6:48 PM +0300 4/23/04, Jarkko Hietaniemi wrote:
>>>You're welcome to try it again, though...while you're at it, you might
as well make all internal Parrot functions take an Interp * instead of a
I hope there's #undef Interp in there somewhere.
I hope it's not in there in the first place. The pr
At 12:45 AM +0200 4/23/04, Jens Rieks wrote:
Hi,
On Thursday 22 April 2004 17:59, Brent 'Dax' Royal-Gordon wrote:
Nicholas Clark wrote:
> Pain being due to these two:
>
> struct Parrot_Interp;
>
> typedef struct Parrot_Interp *Parrot_Interp;
>
>
> This doesn't seem right.
It is and it is
On Fri, Apr 23, 2004 at 08:42:28AM -0400, Dan Sugalski wrote:
: At 11:29 PM +0100 4/22/04, Simon Cozens wrote:
: >[EMAIL PROTECTED] (Dan Sugalski) writes:
: >> my Joe $foo;
: >>
: >> emits the code that, at runtime, finds the class ID of whatever Joe's
: >> in scope, instantiates a new object o
>>>You're welcome to try it again, though...while you're at it, you might
>>>as well make all internal Parrot functions take an Interp * instead of a
I hope there's #undef Interp in there somewhere. Or maybe even possibly
#ifdef Interp
#error EEEK SOMEONE ELSE HAS DEFINED Interp.
#endif
In othe
On Apr 23, 2004, at 5:42 AM, Dan Sugalski wrote:
At 11:29 PM +0100 4/22/04, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
my Joe $foo;
emits the code that, at runtime, finds the class ID of whatever
Joe's
in scope, instantiates a new object of that class
Uh, is that right?
Okay, I give. Against my better judgement, I'm declaring Unicode the
One True Character String Encoding Set Stuff Thingie. It's not quite
going to be as simple as that, as folks will likely track me down and
beat me if we utf-8 decode their JPEG data, and there's plenty of
non-Unicode data out
On Fri, 2004-04-23 at 08:42, Dan Sugalski wrote:
> Since any type potentially has assignment behaviour, it has to be a
> constructor. For example, if you've got the Joe class set such that
> assigning to it prints the contents to stderr, this:
>
> my Joe $foo;
> $foo = 12;
>
> should p
At 11:29 PM +0100 4/22/04, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
my Joe $foo;
emits the code that, at runtime, finds the class ID of whatever Joe's
in scope, instantiates a new object of that class
Uh, is that right? I don't think that "my" is a constructor, more a ty
[EMAIL PROTECTED] (Dan Sugalski) writes:
> my Joe $foo;
>
> emits the code that, at runtime, finds the class ID of whatever Joe's
> in scope, instantiates a new object of that class
Uh, is that right? I don't think that "my" is a constructor, more a typing
declarator.
--
Hi, this is Ken. Wh
Hi,
Leopold Toetsch wrote:
> Jens Rieks wrote:
> > I've prepared a patch for it.
>
> Why do you change all to the longest declaration of Parrot_Interp?
because Brent 'Dax' Royal-Gordon wrote:
: The naming conventions say that struct
: Parrot_Interp should really be struct parrot_interp_t, but tha
Jens Rieks wrote:
I've prepared a patch for it.
Why do you change all to the longest declaration of Parrot_Interp?
We have in decreasing length
struct parrot_interp_t *
struct Parrot_Interp *
Parrot_Interp
Interp *
We need the structure declaration which could be 1) or 2) and we want a
short typ
47 matches
Mail list logo
