Gah. Not a good combination do heavy editing and insufficient
proofreading make.
* A. Pagaltzis <[EMAIL PROTECTED]> [2004-01-22 03:55]:
> Good point; however, this means
a
> different way to think of the vector ops than we had so far.
> Basically, we're moving from the realm of vector ops to that
* Piers Cawley <[EMAIL PROTECTED]> [2004-01-21 23:33]:
> And once you go to an image based IDE and have access to the
> bytecode of the code you're writing there's all *sorts* of
> interesting things you can do. And that's before one starts to
> imagine attaching the IDE/debugger to a running proce
* Larry Wall <[EMAIL PROTECTED]> [2004-01-21 20:35]:
> On Wed, Jan 21, 2004 at 03:21:01PM +0100, A. Pagaltzis wrote:
> > It seems to me that this is too big a semantic choice to make
> > merely by omission of a single (and quite dainty) character.
> > I'd rather express this by forcing a context on
- Original Message -
From: "Larry Wall" <[EMAIL PROTECTED]>
To: "Perl6" <[EMAIL PROTECTED]>
Sent: Wednesday, January 21, 2004 2:51 PM
Subject: [perl] Re: Comma Operator
> On Tue, Jan 20, 2004 at 08:12:28PM -0800, Jonathan Lang wrote:
> : Joe Gottman wrote:
> : >About a month ago, a
On Wed, Jan 21, 2004 at 01:14:46PM -0500, Dan Sugalski wrote:
> >... seems to indicate that even whole ops like add P,P,P are atomic.
>
> Yep. They have to be, because they need to guarantee the integrity of
> the pmc structures and the data hanging off them (which includes
> buffer and string s
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>4) list.c
> If you want to hack in on this, go ahead, though it looks like
> something that we'll ultimately need--its the guts of a sparse
> mixed-type array, which is useful and we may well need at some point.
Actually that was the reason, I implemented
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> So, lets do the classes as:
> *) Array - fixed-size, mixed-type array
> *) vPArray - variable-sized PMC array
> *) PArray - Fixed-size PMC array
> *) vSArray - variable-sized string array
> *) SArray - fixed-size string array
Actually I forgot one: We alr
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ No Guarantees WRT data access }
>>... seems to indicate that even whole ops like add P,P,P are atomic.
> Yep. They have to be, because they need to guarantee the integrity of
> the pmc structures and the data hanging off them (which includes
> buffer and
On Wed, Jan 21, 2004 at 04:01:43PM -0500, Austin Hastings wrote:
> Perhaps the right way to vectorize the arguments is to delimit them with
> vectorization markers?
>
> @a + >>$b<<
or @a + @$b even!
--
Justice is when you get what you deserve.
Law is when you get what you pay for.
*) Array - fixed-size, mixed-type array
*) vPArray - variable-sized PMC array
*) PArray - Fixed-size PMC array
*) vSArray - variable-sized string array
*) SArray - fixed-size string array
And so on, for N and I arrays. I'm not particularly attached to the
names. (Actually I think they suck, but th
Uri Guttman <[EMAIL PROTECTED]> writes:
>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
>
> LW> This would be relatively straightforward for syntax highlighters,
> LW> I think. But Perl 6 will throw other curves at highlighters that
> LW> will be much more difficult to solve, such as
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 21, 2004 2:33 PM
> To: Language List
> Subject: Re: Semantics of vector operations
>
>
> On Wed, Jan 21, 2004 at 03:21:01PM +0100, A. Pagaltzis wrote:
> : That said, I'm not sure how keen I am on
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> This would be relatively straightforward for syntax highlighters,
LW> I think. But Perl 6 will throw other curves at highlighters that
LW> will be much more difficult to solve, such as the fact that any
LW> C potentially changes the
On Tue, Jan 20, 2004 at 08:12:28PM -0800, Jonathan Lang wrote:
: Joe Gottman wrote:
: >About a month ago, a thread here suggested that we change the meaning
: > of the comma operator. Currently, in scalar context the expression
: > foo(), bar()
: > means "evaluate foo(), discard the result
Dan Sugalski writes:
> At 9:38 AM +0100 1/21/04, Leopold Toetsch wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> >> Okay, at this point we've a pile of different array classes
> >
> >> Before we go any further we need to figure out what we want.
> >
> >1) Unify setting/getting element count
On Wed, Jan 21, 2004 at 03:21:01PM +0100, A. Pagaltzis wrote:
: That said, I'm not sure how keen I am on the idea of "one-sided"
: vector operators. It seems to me that this is too big a
: semantic choice to make merely by omission of a single (and quite
: dainty) character. I'd rather express this
On Tue, Jan 20, 2004 at 11:06:13PM -0500, Austin Hastings wrote:
: If only from a syntax-highlighting point of view, this is a horrible
: proposal. Make it die.
This would be relatively straightforward for syntax highlighters,
I think. But Perl 6 will throw other curves at highlighters that
will
All~
So, lets do the classes as:
*) Array - fixed-size, mixed-type array
*) vPArray - variable-sized PMC array
*) PArray - Fixed-size PMC array
*) vSArray - variable-sized string array
*) SArray - fixed-size string array
I suggest using "Array" to mean fixed size and "Vector" to mean variable
si
At 10:25 AM +0100 1/21/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
One more question:
=head2 Guarantees
... doesn't have anything about user data integrity. So when 2 threads
access a PerlNum, they could get a mixture of the typically 2 involved
words.
Potentially, yeah, th
At 9:38 AM +0100 1/21/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Okay, at this point we've a pile of different array classes
Before we go any further we need to figure out what we want.
1) Unify setting/getting element count
- the elements() vtable is unused (not acce
Hi all,
I'm hoping this is just a simple linker option, but
I've been reading "ld" manuals for the past few
hours and I just don't get it. :)
I'm trying to make a dynamically loaded PMC that
subclasses another dynamically loaded PMC.
I made two files in parrot/dynclasses/ :
// file 1: pisequen
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Steve Fink <[EMAIL PROTECTED]> wrote:
>> It crashes on a memcpy inside compact_pool
> Some remarks what I could find out:
> - current COW copying of stacks is AFAIK borken - both "copies" of
> one COWed stack share the same Buffer header
I have now
Robert Spier wrote:
>24941: [PATCH] RE: More Buffer IO Bugs (was:
Strangeness when printing to file)
>
>
patch applied.
Arvindh
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
>This is a test for the buffer bug that
>was discussed on p6i a few days ago.
>
>It does not remove the test file it makes
>because I do not know a good way to do this.
You may use teardown() defined in t/src/io.t
The attached patch contains stripped down versions of your program
that I used to s
* Larry Wall <[EMAIL PROTECTED]> [2004-01-21 01:44]:
> Note that if we do take this approach, we'll have to require the
> space after = in
>
> @list = «a b c d e»;
This shouldn't be a problem. The whitespace rule changes I
believe should be avoided (Abigail does have a point there) is if
whit
My vote goes for the simplest that will still parse;
/*
=head1 foo
*/
After all, arent't we all using editors that can highlight the
scructure of our code to our satisfaction ? Surely even VIM et al can
stick in dividers or something to make them stand out if the coder
desires? I've already go
21/01/2004 02:12:09, Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> This is false. The mark phase will still need to run over the entire
> process, else it cannot detect all references into the pool.
>
If by reference, you mean address, then that is true.
If when a reference is taken, the addres
Leopold Toetsch writes:
> While trying to generate a small example that shows the memory
> corruption problem reported by Steve, I came along these issues:
>
> a) [1] is .Sub, [2] is turned off
>The subroutine prints main's $m - very likely wrong.
Well, Subs don't do anything with pads, so I
While trying to generate a small example that shows the memory
corruption problem reported by Steve, I came along these issues:
a) [1] is .Sub, [2] is turned off
The subroutine prints main's $m - very likely wrong.
Q: Should the Sub get a NULL scratch pad, or a new empty scratch pad stack?
b)
Dan Sugalski <[EMAIL PROTECTED]> wrote:
One more question:
>=head2 Guarantees
... doesn't have anything about user data integrity. So when 2 threads
access a PerlNum, they could get a mixture of the typically 2 involved
words.
But:
>=item All shared PMCs must have a threadsafe vtable
> The fi
Warning: spacey, tangential semi-argument ahead.
Larry Wall writes:
> On Tue, Jan 20, 2004 at 01:54:33AM -0700, Luke Palmer wrote:
> : A thought occurred to me. What should this return:
> :
> : [1,2,3] Â+Â [4,5,6]
> :
> : At first glance, one might say [5,7,9]. But is that really the best
PDD 7 "Conventions and Guidelines for Parrot Source Code" has a section
on "Code Comments" that has been followed for C code. I'm about to
change this.
The existing documentation headers will be replaced with pod headers
contained within C multi-line comment delimiters. I'm going to stick to
e
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I believe that parrot already has the concept of memory pools in it's
> memory management. The idea is that by allocating similarly sized objects
The problem is not in the fixed sized header pools, its with the
*memory* pool used e.g for string memor
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, at this point we've a pile of different array classes
> Before we go any further we need to figure out what we want.
1) Unify setting/getting element count
- the elements() vtable is unused (not accessible by opcode)
- we use get_integer()
34 matches
Mail list logo
