Hi.
Using PerlArray PMC, if I use
new P0, .PerlArray
set P1, P0
P1 becomes a 'pointer' to the same array as P0. Now the question is, and
if I want a new copy? If all PerlArray elements are
integer/number/string I think that should be easy to do a loop to copy
all values. The qu
On Fri, 2002-07-12 at 08:34, Alberto Manuel Brandão Simões wrote:
>
> Hi.
>
> Using PerlArray PMC, if I use
>
> new P0, .PerlArray
> set P1, P0
>
> P1 becomes a 'pointer' to the same array as P0. Now the question is, and
> if I want a new copy? If all PerlArray elements are
> integ
I have to say that I am extremely disappointed at the
paucity of internal documentation.
One of the goals of the p6 rewrite is to make the code
more accessible for maintainers who will come along later.
This cannot happen without good, substantial internal
documentation.
And I don't wanna hear
--- Dave Mitchell <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 11, 2002 at 01:18:51PM -0700, John Porter wrote:
> > Nicholas Clark wrote:
> > > I was thinking that the metric (x*x + y*y) would be fast to
> > > calculate, as that's all we need for ordering.
> >
> > Point is, it's rather *more* than w
On Thu, Jul 11, 2002 at 09:25:03PM -0400, Melvin Smith wrote:
> I also note that without explicitly telling the Array to size itself, you
> start with a NULL array which will core if you insert an item. Maybe
> someone can take over the Array work since Steve Fink has been
> busy elsewhere?
Hey,
On Fri, 2002-07-12 at 02:33, Sean O'Rourke wrote:
> What's currently "supported":
> - if/elsif/else (even "unless" and the feared "elsunless";)
When we talked about this last, I had been concerned about loops and
conditionals, but others had scoping concerns. Ok, perhaps there's no
way we can r
On Fri, 12 Jul 2002, John Porter wrote:
[...]
> And I don't wanna hear the same old b.s. "patches welcome".
> It is incumbent on the person who writes the code to include
> his own commentary. Of course, if someone else who *already*
> understands the code wants to remedy here and there, fine.
W
Hi all,
I've been lurking for a bit until I'm up to speed enough to help out. I'm glad to see
a glossary is forming of some of the terms newbies need, but there are some things I
think are missing.
First is that COW was discussed a few days (weeks?) ago, but doesn't appear to have
made it to
At 11:13 AM 7/12/2002 -0400, Mike Litherland wrote:
>I've been lurking for a bit until I'm up to speed enough to help out. I'm
>glad to see a glossary is forming of some of the terms newbies need, but
>there are some things I think are missing.
>
>First is that COW was discussed a few days (wee
At 01:37 AM 7/12/2002 -0700, John Porter wrote:
>I have to say that I am extremely disappointed at the
>paucity of internal documentation.
push @melvins_list_of_disappointments, $johns_disappointment;
>I know this is going to be extremely painful for some of you
>hackers... consider it a chance
At 12:01 PM -0400 7/12/02, Melvin Smith wrote:
>At 11:13 AM 7/12/2002 -0400, Mike Litherland wrote:
>>Next is that garbage collection should probably be listed under
>>it's acronym GC. Probably with a description of what it is and how
>>it works under Parrot.
>
>Did you check docs/ and docs/pdd
At 12:01 PM -0400 7/12/02, Melvin Smith wrote:
>Did you check docs/ and docs/pdds first? There may already be something
>there. The glossary is probably a good idea anyway.
I added some definitions to glossary. I think the changes'll be
picked up on parrotcode.org around 4PM EST by the autogener
Hi
I've sent these files to Dan, but still didn't any answer. Meanwhile,
somebody can have some more time than he too look into these files.
They are POD's documenting PMC's (Arrays, PerlArrays and PerlHashes).
If you think they are interesting, put them on the doc dir for parrot,
and I'll do s
Okay, anyone up for this? Should be fairly trivial--take the address
of an auto variable in runops, store it in the interpreter, take the
address of *another* auto variable in the GC, and walk the contiguous
chunk of memory between, looking for valid PMC and Buffer pointers.
Anyone?
--
I've seen several comments go across with valid concerns,
and a few that perplex me.
Guys, look at the facts. We have a very small number of
internals hackers here, and only one who actually gets
paid for it. Most of us have jobs and families, and we slip in this stuff
in little slices in hopes
Dan Sugalski writes:
>At 12:01 PM -0400 7/12/02, Melvin Smith wrote:
>>Did you check docs/ and docs/pdds first? There may already be something
>>there. The glossary is probably a good idea anyway.
>
>I added some definitions to glossary. I think the changes'll be
>picked up on parrotcode.org arou
The situation with set vs. set_keyed vs. set_keyed_integer is pretty foul
now. The last half of core.ops has a bunch of set() functions and,
corresponding to (most of) them, set_keyed_integer() functions with the
exact same arguments and bodies. From what I gather, the 3-argument set()
functions
At 10:27 AM -0700 7/12/02, Robert Spier wrote:
>Dan Sugalski writes:
>>At 12:01 PM -0400 7/12/02, Melvin Smith wrote:
>>>Did you check docs/ and docs/pdds first? There may already be something
>>>there. The glossary is probably a good idea anyway.
>>
>>I added some definitions to glossary. I think
>I've heard reports of rsync not working. I don't use it, so I dunno
>there. If someone's got the proper incantation, or follows the
>directions and it doesn't work (when you're *sure* you know what
>you're doing) I'll update it appropriately.
Yes, this seems broken at the moment. I've opene
>Correct, I don't maintain the site, but I believe Robert has said he would
>accept patches.
Yes, if people send me updates/diff/new content's, or just "replace
this paragraph with this", I'll do the merges.
-R
At 10:42 AM -0700 7/12/02, Sean O'Rourke wrote:
>The situation with set vs. set_keyed vs. set_keyed_integer is pretty foul
>now. The last half of core.ops has a bunch of set() functions and,
>corresponding to (most of) them, set_keyed_integer() functions with the
>exact same arguments and bodies.
Melvin &co,
Which IRC network, which channel?
Sorry for past, present, and future newbie questions. Doubly so for having
overlooked documentation. Docs are in excellent condition, considering.
Since I can't help but to pipe up, I should disclaim myself: Parrot is
extremely coo. The core team h
Aaron Sherman wrote:
> An example:
>
> $pid = fork() // -1;
> if $pid < 0 {
> # error ...
> } else unless $pid {
> # Parent
> } else if $pid > 0 {
> # Child
> } else {
> # Huh? Can't happen
> }
Of course, your indentation implies a differen
>Which IRC network, which channel?
I use irc.pobox.com, you can also try irc.rhizomatic.net
Channel is #parrot
>Sorry for past, present, and future newbie questions. Doubly so for having
As always, newbie questions are welcome, and I think the Parrot list
is usually nicely on-topic.
-Melv
At 11:33 PM -0700 7/11/02, Sean O'Rourke wrote:
>It's time for my weekly post to this old thread. The grammar has
>grown enough to deserve more than one file, and is starting to change
>in new directions. For example, it's now Turing-complete, if you have
>a Parrot engine and a bit of spare time
I just changed 'kc' to be an integer constant, because it was the
simpliest way to make the warnings go away.
If kc should be a string and k too, tell me.
Daniel Grunblatt.
On Thu, Jul 11, 2002 at 08:20:21PM -0700, John Porter wrote:
>
> Dave Mitchell wrote:
> > IIRC, all metrics of the form (x^n + y^n)^(1/n), n=1,2,...Inf
> > are strongly equivalent, ie they give rise to the *same* ordering.
> > (In the limit as n -> Inf, the metric is max(x,y).)
>
> I'm sorry, YD
> >Which IRC network, which channel?
>
> I use irc.pobox.com, you can also try irc.rhizomatic.net
> Channel is #parrot
Problem I have with irc (besides the fact that I don't, can't
and won't use it) is that all the good stuff that flows by
isn't getting captured and archived anywhere. I'm su
Melvin Smith wrote:
> Guys, look at the facts. We have a very small number of
> internals hackers here, and only one who actually gets
> paid for it. . . . We are not an army.
"I'm so busy building this tower single-handedly,
I don't have time to teach anyone else how to cut
stone or mix mortar
Melvin Smith wrote:
> What parts particularly bug you? Maybe we can address a few.
Well, basically, AFAICT, virtually none of the parrot code
is adequately documented. So, pick a random entry point. :-)
But this is why I'm not suggesting that someone drop what
they're doing and going in and do
I'll take a stab at it. Got a few questions, tho:
a) Can I assume the stack always extends into larger-addressed memory, or
must I handle both cases?
b) What's the largest alignment guaranteed for pointers? Byte-level?
c) Where should this code go, such that it can be replaced for the
OS/platfo
At 4:50 PM -0400 7/12/02, Mike Lambert wrote:
>I'll take a stab at it. Got a few questions, tho:
>
>a) Can I assume the stack always extends into larger-addressed memory, or
>must I handle both cases?
Both cases. If you want to add configure probing to determine
direction, go ahead.
>b) What's
> Melvin Smith wrote:
> > What parts particularly bug you? Maybe we can address a few.
>
> Well, basically, AFAICT, virtually none of the parrot code
> is adequately documented. So, pick a random entry point. :-)
First, you have to understand that what you are saying is quite
inflammatory, regar
[EMAIL PROTECTED] (John Porter) writes:
> Yeah, look at the so-called Parrot FAQ. Someone needs to
> get serious and make a real FAQ for parrot developers.
I'm sure noone would mind if you start one!
- ask
--
ask bjoern hansen, http://askbjoernhansen.com/ !try; do();
[EMAIL PROTECTED] (Robert Spier) writes:
> >I've heard reports of rsync not working. I don't use it, so I dunno
> >there. If someone's got the proper incantation, or follows the
> >directions and it doesn't work (when you're *sure* you know what
> >you're doing) I'll update it appropriately.
>
At 01:16 PM 7/12/2002 -0700, John Porter wrote:
>Melvin Smith wrote:
> > Guys, look at the facts. We have a very small number of
> > internals hackers here, and only one who actually gets
> > paid for it. . . . We are not an army.
>
>"I'm so busy building this tower single-handedly,
>I don't hav
> >a) Can I assume the stack always extends into larger-addressed memory, or
> >must I handle both cases?
>
> Both cases. If you want to add configure probing to determine
> direction, go ahead.
I'm currently doing it dynamically. Get it working, then someone can do
nice configure probing. :) Tur
37 matches
Mail list logo
