Steve Fink <[EMAIL PROTECTED]> wrote:
> I did a cvs update, and it looks like imcc doesn't properly return
> integers anymore from nonprototyped routines.
I don't even know if this is allowed. But anyway, if the call is non
prototyped, native types should go into P3. So you have the overhead of
P
Michal Wallace <[EMAIL PROTECTED]> wrote:
> 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.
Its a l
Running parrot built with --gc=libc works fine, all tests pass *except*
t/pmc/pmc_62 when --gc-debug is set.
I could track this down until here:
classes/default.c:
static void
check_set_std_props(Parrot_Interp interp, PMC *pmc, STRING *key, PMC *value)
{
if (!string_compare(interp, key, str
On Thu, 22 Jan 2004, Leopold Toetsch wrote:
> Michal Wallace <[EMAIL PROTECTED]> wrote:
>
> > I'm trying to make a dynamically loaded PMC that
> > subclasses another dynamically loaded PMC.
>
> Its a linker problem, but not too simple. Your analysis is correct:
> pistring needs the symbol Parrot_P
Arvindh Rajesh Tamilmani <[EMAIL PROTECTED]> wrote:
> name="biotests.patch"
Something is wrong with these tests: patching t/src/io.t and PASM code.
Even if that works, PASM tests shouldn't be in t/src but in t/pmc/io.t.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> *) Array - fixed-size, mixed-type array
> Personally I'd leave Array as it is, since it does one of the things
> that we need it to do.
Array isn't really mixed-typed. It has methods to store or retrieve
non-PMC types, but they are converted internally t
On Thu, Jan 22, 2004 at 07:56:51AM -0500, Michal Wallace wrote:
>
> > I did something like this:
> >
> > $ make -C dynclasses
> > $ cp dynclasses/pisequence.so blib/lib/libpisequence.so
>
> Aha! I was trying to figure out how to do -lpisequence.
> It didn't occur to me to just RENAME it. :)
Perh
# New Ticket Created by "Tamilmani, Arvindh Rajesh (Cognizant)"
# Please include the string: [perl #25232]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=25232 >
The attached patch
a) fixes bugs in reading a larger chunk w
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #25233]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=25233 >
I'm finding parrot's killing its memory pools somewhere and dying
when it goes to compa
>Even if that works, PASM tests shouldn't be in t/src but in t/pmc/io.t.
Sorry, I didn't know that.
The attached patch is for t/pmc/io.t
>leo
Thanks,
Arvindh
biotests2.patch
Description: biotests2.patch
This e-mail and any files transmitted with it are for the sole use of the intended
recipie
On Thu, Jan 22, 2004 at 03:53:04AM +0100, A. Pagaltzis wrote:
: Good point; however, this means 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 of vectorized operands.
:
: In light of this, I think Austin's proposal of m
On Thu, Jan 22, 2004 at 03:57:26AM +0100, A. Pagaltzis wrote:
: * 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
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 22, 2004 12:50 PM
> To: Language List
> Subject: Re: Semantics of vector operations
>
>
> On Thu, Jan 22, 2004 at 03:57:26AM +0100, A. Pagaltzis wrote:
> : * Piers Cawley <[EMAIL PROTECTED]> [2004-
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 22, 2004 12:39 PM
> To: Language List
> Subject: Re: Semantics of vector operations
>
>
> On Thu, Jan 22, 2004 at 03:53:04AM +0100, A. Pagaltzis wrote:
> : Good point; however, this means different
> -Original Message-
> From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 22, 2004 1:16 PM
> To: Austin Hastings
> Cc: Larry Wall; Language List
> Subject: Re: Semantics of vector operations (Damian)
>
>
> On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hasting
On Wed, Jan 21, 2004 at 08:51:33PM -0500, Joe Gottman wrote:
: Great, so
: $x = foo(), bar();
: means the same thing as
: $x = ( foo(), bar() );
No, we haven't changed the relative precedence of assignment and comma.
I've been tempted to, but I always come back to liking the parens
for vis
On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote:
> In reverse order:
>
> > %languageometer.values ?+= rand;
>
> This is the same as
>
> all( %languageometer.values ) += rand;
>
> right?
It's the same as
$r = rand;
$_ += $r for %languageometer.values
On Thu, Jan 22, 2004 at 01:10:25PM -0500, Austin Hastings wrote:
: > -Original Message-
: > From: Larry Wall [mailto:[EMAIL PROTECTED]
: > I think some people will want to think of it one way, while others
: > will want to think of it the other way. If that's the case, the
: > proper place
Jonathan Scott Duff writes:
> On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote:
> > In reverse order:
> >
> > > %languageometer.values Â+= rand;
> >
> > This is the same as
> >
> > all( %languageometer.values ) += rand;
> >
> > right?
Well, yes. It's also the same as e
* Larry Wall <[EMAIL PROTECTED]> [2004-01-22 18:40]:
> You might argue that we should force people to think of it one
> way or the other.
I wouldn't, because if I did I'd should've been talking to Guido
rather than you in the first place. :-)
And because I'm talking to you, I'll wonder whether ma
Austin Hastings writes:
> How do you handle operator precedence/associativity?
>
> That is,
>
>$a + $b + $c
>
> If you're going to vectorize, and combine, then you'll want to group. I
> think making the vectorizer a grouper as well kills two birds with one
> stone.
>
> $a + >>$b + $c<<
>
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 22, 2004 3:52 PM
> To: Austin Hastings; Larry Wall; Language List
> Subject: Re: Semantics of vector operations (Damian)
>
>
> Jonathan Scott Duff writes:
> > On Thu, Jan 22, 2004 at 01:10:23PM
Austin Hastings writes:
> > Sortof. I think Larry was implying that rand returned an infinite list
> > of random numbers in list context. If not, then what he said was wrong,
> > because it would be sick to say that:
> >
> > (1,2,3,4,5) Â+Â foo()
> >
> > Calls foo() 5 times.
>
> Why would
Luke Palmer writes:
> > (1,2,3,4,5) +Â foo() # Maybe the same as above? What does
> > infix:+(@list,$scalar) do?
>
> Well, what does a list return in scalar context? In the presence of the
> C comma, it returns 5 for the last thing evaluated. In its absence, it
> returns 5 for the lengt
On Thu, Jan 22, 2004 at 01:28:42PM -0500, Austin Hastings wrote:
> > From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
> > On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote:
> > > In reverse order:
> > >
> > > > %languageometer.values ?+= rand;
> > >
> > > This is the same as
>
On Thu, Jan 22, 2004 at 11:25:41AM -0800, Larry Wall wrote:
> On Thu, Jan 22, 2004 at 01:10:25PM -0500, Austin Hastings wrote:
> : > -Original Message-
> : > From: Larry Wall [mailto:[EMAIL PROTECTED]
> : > I think some people will want to think of it one way, while others
> : > will want t
On Thu, Jan 22, 2004 at 02:28:09PM -0700, Luke Palmer wrote:
: Well, for being called "vector operators", they're ending up pretty
: useless as far as working with mathematical vectors.
Which is why I suggested calling them distributors or some such.
: As a
: mathematician, I'd want:
:
: @ve
On Thu, Jan 22, 2004 at 01:34:33PM -0600, Jonathan Scott Duff wrote:
: On Thu, Jan 22, 2004 at 11:25:41AM -0800, Larry Wall wrote:
: > Me? I handle it by making it an adverb on the base operator. :-)
:
: Does that mean it should get the colon? :)
Only if all adverbs in English end in -ly.
Of
- Original Message -
From: "Luke Palmer" <[EMAIL PROTECTED]>
To: "Austin Hastings" <[EMAIL PROTECTED]>
Cc: "Larry Wall" <[EMAIL PROTECTED]>; "Language List" <[EMAIL PROTECTED]>
Sent: Thursday, January 22, 2004 4:28 PM
Subject: [perl] Re: Semantics of vector operations
> Austin Hastings
On Thu, Jan 22, 2004 at 08:08:13PM -0500, Joe Gottman wrote:
:I just realized a potential flaw here. Consider the code
: $a >>= 1;
:
:Will this right-shift the value of $a one bit and assign the result to $a
: (the current meaning)? Or will it assign the value 1 to each element i
Luke Palmer <[EMAIL PROTECTED]> writes:
> @A »+« @B # One-at-a-time
> @A «+» @B # Outer product
>
> Or something. Hmm, then both:
>
> @A »+ $b
> @A «+ $b
There is a page you may find inspiring:
http://www.ritsumei.ac.jp/~akitaoka/index-e.html
Sorry, I could n
Larry Wall writes:
> On Thu, Jan 22, 2004 at 08:08:13PM -0500, Joe Gottman wrote:
> :I just realized a potential flaw here. Consider the code
> : $a >>= 1;
> :
> :Will this right-shift the value of $a one bit and assign the result to $a
> : (the current meaning)? Or will it assig
At 12:15 AM +0100 1/22/04, Leopold Toetsch wrote:
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
[Note to everyone -- I'm digging through my mail so be prepared for a
potential set of responses to things that're already answered...]
At 6:37 PM -0500 1/19/04, Gordon Henriksen wrote:
Dan Sugalski wrote:
For a copying collector to work, all the mutators must be blocked,
and arguably all reade
At 2:15 PM -0500 1/21/04, Matt Fowles wrote:
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
At 10:28 AM +0100 1/22/04, Leopold Toetsch wrote:
Steve Fink <[EMAIL PROTECTED]> wrote:
I did a cvs update, and it looks like imcc doesn't properly return
integers anymore from nonprototyped routines.
I don't even know if this is allowed. But anyway, if the call is non
prototyped, native types s
At 10:42 AM +0100 1/21/04, Michael Scott wrote:
Perhaps the most controversial feature of all this is that I'm using
rows of 80 '#'s as visual delimiters to distinguish documentation
sections from code.
Please don't. If you really, really must, chop it down to 60 or so
characters. 80 may wrap in
At 4:59 PM -0800 1/19/04, Dave Whipp wrote:
"Dan Sugalski" <[EMAIL PROTECTED]> wrote:
=head2 Guarantees
Maybe this isn't strictly a threading thing, but are we going to make any
guarantees about event orderings? For example, will we guarantee that a
sequence of events send from one thread to anoth
At 2:06 PM +0100 1/19/04, Michael Scott wrote:
Some files have CVS version $Id strings, some don't.
While tidying up the documentation I'm visiting every file. I can either:
1) add them when missing
2) remove them when present
3) do nothing
I was inclined to (1) until I reflected that it did pres
At 2:52 PM +0100 1/17/04, Elizabeth Mattijsen wrote:
Don't know why you thgink it would be fetched 3 times, but as using
tied variables in Perl 5, a fetch is done _everytime_ the value of
the tied variable is needed.
You misunderstand. I'm talking about fetching the PMC for the
variable *out of
At 3:25 PM -0800 1/20/04, Robert Spier wrote:
(FYI, for the future, I may not ack all the changes, although it
depends how many there are.)
Is there any way to get RT to close tickets (or change their status)
entirely via e-mail? That'd make this a lot easier if we could throw
a:
RT-Status: Clos
At 12:10 PM +0100 1/22/04, Leopold Toetsch wrote:
I have converted that one now into a static constant string, but
this isn't a solution.
We have discussed already a few times, what to do with such constant
strings, e.g. declare them static with some macro tricks or use a
string hash. We need a
At 8:37 AM -0500 1/19/04, Benjamin K. Stuhl wrote:
Luke Palmer wrote:
Benjamin K. Stuhl writes:
Other than the special case of :readonly, can you give me an example
of when you'd need to, rather than simply writing a PMC class that
inherits from some base? I'm having trouble thinking of an exampl
Last chance to get in comments on the first half of the proposal. If
it looks adequate, I'll put together the technical details
(functions, protocols, structures, and whatnot) and send that off for
abuse^Wdiscussion. After that we'll finalize it, PDD the thing, and
get the implementation in and
Yep. I bounced Sam's comment around in my head for a while until I saw
that I was only putting them in for my own current convenience - makes
it easier to see what I'm doing as I'm doing it - so they won't be
there. Minimal is best. And anyway who wants to be "SO 20th century".
Mike
On 22 Jan
Duh. Rereading that I can see I got my numbers in a twist. I've been
adding them where missing.
On 22 Jan 2004, at 19:39, Dan Sugalski wrote:
At 2:06 PM +0100 1/19/04, Michael Scott wrote:
Some files have CVS version $Id strings, some don't.
While tidying up the documentation I'm visiting every
On Thu, 2004-01-15 at 09:16, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > If that's living in an managedstruct, then accessing the struct
> > elements should be as simple as:
>
> > set I0, P20['bar']
> > set S1, P20['plugh']
> > set P20['baz'], 15
>
> That's
> Is there any way to get RT to close tickets (or change their status)
> entirely via e-mail? That'd make this a lot easier if we could throw
> a:
> RT-Status: Closed
> or something like it in the reply to a bug report that notes the bug
> has been fixed.
I could implement this, but there are a
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The only tricky bit comes in with the examination of the root set of
> other threads--accessing the hardware register contents of another
> running thread may be... interesting. (Which, I suppose, argues for
> some sort of volatile marking of the temp vari
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I'm finding parrot's killing its memory pools somewhere and dying
> when it goes to compact memory during a GC sweep.
Yep. See also "Memory corruption" by Steve Fink and my f'ups.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:28 AM +0100 1/22/04, Leopold Toetsch wrote:
>>And mainly the return convention are still broken.
> I thought those were fixed.
Not yet.
> ... There's no difference between calling and
> return conventions
To be done.
leo
Dan Sugalski wrote:
Last chance to get in comments on the first half of the proposal. If
it looks adequate, I'll put together the technical details (functions,
protocols, structures, and whatnot) and send that off for
abuse^Wdiscussion. After that we'll finalize it, PDD the thing, and
get the
I'm also concerned by those timings that leo posted.
0.0001 vs 0.0005 ms on a set- that magnitude of locking overhead
seems pretty crazy to me.
It seemed like a few people have said that the JVM style of locking
can reduce this, so it seems to me that it merits some serious
consideration, even
My most recent "get tcl working again" error was in fact, the result of
a bad jump, as Leo suggested. Of course, that jump was never made
before, and in trying to track down why I was hitting an error
condition I hadn't before, I realized that I had a few
non-calling-convention subs near where
Robert~
You can close the following tickets
24848
24840
22281
21988
Matt
The subject says it all.
As parrot is designed to be targetted by many langauges,
how will it handle 'eval' opcodes for those different languages?
Shell out to a seperate process?
Nigel.
On Fri, 23 Jan 2004 [EMAIL PROTECTED] wrote:
> The subject says it all.
>
> As parrot is designed to be targetted by many langauges,
> how will it handle 'eval' opcodes for those different languages?
>
> Shell out to a seperate process?
You could do that, or you can provide a C-based
compiler as
Dan Sugalski wrote:
[sniping to reduce verbiage]
The issue is that the PMC's original vtable assumes (and should, IMHO
be _able_ to assume) that it has total control over the PMC's data,
Well... I think I'll disagree here. The *class* vtable can assume this.
However that doesn't mean that any r
58 matches
Mail list logo
