From: "Will Coleda" <[EMAIL PROTECTED]>
Date: Thu, 7 Aug 2008 11:30:34 -0400
On Thu, Aug 7, 2008 at 11:26 AM, Bob Rogers
<[EMAIL PROTECTED]> wrote:
> I once suggested a "null register allocator" that would do this
> globally, but this is a better idea. The only use case I can t
Ron Blaschke wrote:
Jonathan Worthington wrote:
I've just been looking at the time op, and what it returns is
somewhat platform specific.
* On Win32, it's the number of seconds since January 1, 1601
If I remember correctly, some parts of Windows use 100ns ticks since
1601 to represent time.
# New Ticket Created by Will Coleda
# Please include the string: [perl #57728]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57728 >
Open a ticket for TODO item.
-- Forwarded message --
From: jerry gay <[E
On Thu, Aug 7, 2008 at 12:40 PM, Ron Blaschke <[EMAIL PROTECTED]> wrote:
> Jonathan Worthington wrote:
>>
>> Hi,
>>
>> I've just been looking at the time op, and what it returns is somewhat
>> platform specific.
>>
>> * On Win32, it's the number of seconds since January 1, 1601
>
> If I remember co
Jonathan Worthington wrote:
Hi,
I've just been looking at the time op, and what it returns is somewhat
platform specific.
* On Win32, it's the number of seconds since January 1, 1601
If I remember correctly, some parts of Windows use 100ns ticks since
1601 to represent time. Not sure if c
On Thursday 07 August 2008 05:16:40 Carl Mäsak wrote:
> r30087:
> $ ./perl6 -e 'subset A of Int where 1; my A $a = 1' # this works
> $ ./perl6 -e 'subset A of Int where 1; my A $a = 0' # this fails (as
> it should) but segfaults
> Type check failed
> [...]
> Segmentation fault
>
> I was not able t
On Thursday 07 August 2008 08:26:19 Bob Rogers wrote:
> I once suggested a "null register allocator" that would do this
> globally, but this is a better idea. The only use case I can think of
> is debugging, particularly of the register allocator, but that's still
> important.
In theory, that's
On Thu, Aug 7, 2008 at 12:51 PM, Jonathan Worthington
<[EMAIL PROTECTED]> wrote:
> jerry gay wrote:
>>
>> seems to me this is trying to test whether there's a defined value in
>> $!.
>
> Testing truth falls back to definedness, yes.
>
>> however, you've jumped straight into blaming parrot's Excepti
jerry gay wrote:
seems to me this is trying to test whether there's a defined value in
$!.
Testing truth falls back to definedness, yes.
however, you've jumped straight into blaming parrot's Exception
PMC, without considering the expected perl 6 behavior.
Well, I was more blaming the *chan
Allison Randal wrote:
The Exception PMC never had a get_bool vtable function implemented,
but it did previously inherit one from ResizablePMCArray. So, that
test was relying on an implementation artifact.
OK, then that was certainly a wart, agreed.
Under what circumstances should an exceptio
On Thu, Aug 7, 2008 at 3:26 AM, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Rakudo is currently failing t\spec\S12-class\attributes.t. This turns out
> not to be an issue with attributes, but rather exceptions. The test does:
>
> my $c = Counter.new();
> try {
> $c.x
> }
> ok($!, 'n
Jonathan Worthington wrote:
Hi,
Rakudo is currently failing t\spec\S12-class\attributes.t. This turns
out not to be an issue with attributes, but rather exceptions. The test
does:
my $c = Counter.new();
try {
$c.x
}
ok($!, 'no public accessor for private attribute');
And fails because th
From: "Andrew Whitworth" <[EMAIL PROTECTED]>
Date: Thu, 7 Aug 2008 11:36:16 -0400
On Thu, Aug 7, 2008 at 11:18 AM, Bob Rogers
<[EMAIL PROTECTED]> wrote:
> But there's a concat_p_p_p op, so "+" is ambiguous. In general, it
> seems best to use distinct tokens for distinct operatio
On Thu, Aug 7, 2008 at 11:26 AM, Bob Rogers
<[EMAIL PROTECTED]> wrote:
> From: "jerry gay" <[EMAIL PROTECTED]>
> Date: Thu, 7 Aug 2008 07:04:24 -0700
>
> . . .
>
> also, if i understand satisfy patrick's use case in pge,
>
> 3) add the ability to select the register allocator used, or dis
From: "jerry gay" <[EMAIL PROTECTED]>
Date: Thu, 7 Aug 2008 07:04:24 -0700
. . .
also, if i understand satisfy patrick's use case in pge,
3) add the ability to select the register allocator used, or disable
it, within a sub.
a programmer who knows what he's doing should hav
From: Andrew Whitworth via RT <[EMAIL PROTECTED]>
Date: Thu, Aug 7, 2008 at 12:11 AM
I like ".." and "~". I also like "+", if we can get IMCC to reliably
understand that when used on strings it performs concatenation
instead of some crazy addition.
But there's a concat_p_p_p op, so
On Thu, Aug 7, 2008 at 10:04 AM, jerry gay <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 7, 2008 at 5:44 AM, Jonathan Worthington <[EMAIL PROTECTED]>
> wrote:
>> Klaas-Jan Stol wrote:
>>>
>>> I think basically the question remans; is there any way we could do
>>> without the :unique_reg?
>>>
>> Yes:
>>
On Thu, Aug 7, 2008 at 5:44 AM, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> Klaas-Jan Stol wrote:
>>
>> I think basically the question remans; is there any way we could do
>> without the :unique_reg?
>>
> Yes:
>
> 1) Add the reference-taking op and register reference PMC to the Parrot
> core.
Spam
--
Reini Urban
On Thu, Aug 7, 2008 at 8:21 AM, NotFound <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 7, 2008 at 2:06 PM, Will Coleda <[EMAIL PROTECTED]> wrote:
>
>> make headerizer is trying to operate on files generated by make. Given
>> that it's supposed to be updating the header files based on the C
>> sources, t
Klaas-Jan Stol wrote:
I think basically the question remans; is there any way we could do
without the :unique_reg?
Yes:
1) Add the reference-taking op and register reference PMC to the Parrot
core.
2) Make IMCC specially aware of this op so that it never re-uses this
register.
Thanks,
On Thu, Aug 7, 2008 at 1:33 PM, Jonathan Worthington <[EMAIL PROTECTED]>wrote:
> Will Coleda wrote:
>
>> So, again, do we in parrot want to support the ability to dig into our
>> callers register set and pull out a particular register since we have
>> no way to say which register that is when we'r
Will Coleda wrote:
So, again, do we in parrot want to support the ability to dig into our
callers register set and pull out a particular register since we have
no way to say which register that is when we're using PIR? Even
unique_reg just says 'the register doesn't change', not "it's PMC
registe
On Thu, Aug 7, 2008 at 2:06 PM, Will Coleda <[EMAIL PROTECTED]> wrote:
> make headerizer is trying to operate on files generated by make. Given
> that it's supposed to be updating the header files based on the C
> sources, this seems vaguely reasonable, so I would suggest that the
> problem is act
On Thu, Aug 7, 2008 at 8:10 AM, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, Aug 7, 2008 at 12:45 PM, Will Coleda <[EMAIL PROTECTED]> wrote:
>>
>> On Wed, Aug 6, 2008 at 3:30 PM, Jonathan Worthington <[EMAIL PROTECTED]>
>> wrote:
>> > Will Coleda wrote:
>> >>
>> >> Can you describe a sit
On Thu, Aug 7, 2008 at 12:45 PM, Will Coleda <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 6, 2008 at 3:30 PM, Jonathan Worthington <[EMAIL PROTECTED]>
> wrote:
> > Will Coleda wrote:
> >>
> >> Can you describe a situation where this occurs that isn't a bug in the
> >> register allocator?
> >>
> >
> >
On Thu, Aug 7, 2008 at 7:53 AM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> For reference, here's what I got last night on Linux after a make
> realclean, svn up and perl Configure.pl.
>
>
>
> So I never got to 'make' per se; the problem is in
> tools/build/headerizer.pl's action.
>
make hea
Will Coleda wrote:
Being allowed to poke inside your caller's register set seems... evil?
It's the Parrot equivalent of the .Net CLR allowing you to take
references to stuff in caller's stack frames.
Can you provide a working PIR example that shows this functionality?
It was implemente
For reference, here's what I got last night on Linux after a make
realclean, svn up and perl Configure.pl.
$ make headerizer && make
/usr/local/bin/perl tools/build/headerizer.pl src/string.o
src/ops/core_ops.o src/ops/core_ops_switch.o src/atomic/gcc_x86.o
src/builtin.o src/byteorder.o src/charse
As expected, no harm done on 32-bit PPC OS X 10.4.
Since people are looking at patches for Darwin, let me remind you of
these open tickets:
http://rt.perl.org/rt3/Ticket/Display.html?id=49226
http://rt.perl.org/rt3/Ticket/Display.html?id=52212 (another Seneca patch)
http://rt.perl.org/rt3/Ticke
On Wed, Aug 6, 2008 at 3:30 PM, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> Will Coleda wrote:
>>
>> Can you describe a situation where this occurs that isn't a bug in the
>> register allocator?
>>
>
> Yes. IIRC, it was added when I was working on the .Net bytecode translator,
> and it needed
Hi,
I've just been looking at the time op, and what it returns is somewhat
platform specific.
* On Win32, it's the number of seconds since January 1, 1601
* In other codepaths, it appears to be the number of seconds since
January 1, 1970.
I'm thinking we should correct the Win32 version to
[this message was not sent to list, which it seems it should have; hence the
forward.]
-- Forwarded message --
From: Andrew Whitworth via RT <[EMAIL PROTECTED]>
Date: Thu, Aug 7, 2008 at 12:11 AM
Subject: [perl #57656] [PROPOSAL][PIR] change PIR sugar for concat into ".."
(or somet
Author: kjs
Date: Thu Aug 7 03:35:11 2008
New Revision: 30083
Modified:
trunk/docs/pdds/pdd19_pir.pod
Log:
[pdd19] add description for binary relational operators in =
section.
Modified: trunk/docs/pdds/pdd19_pir.pod
==
Hi,
Rakudo is currently failing t\spec\S12-class\attributes.t. This turns
out not to be an issue with attributes, but rather exceptions. The test
does:
my $c = Counter.new();
try {
$c.x
}
ok($!, 'no public accessor for private attribute');
And fails because the Exception PMC does not impl
# New Ticket Created by chromatic
# Please include the string: [perl #57700]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57700 >
Based on a comment from Seneca in IRC earlier tonight, I'd like to get
feedback from Mac O
I've stopped the crashes that appear related to this on my box with the
attached patch.
config/gen/platform/darwin/memalign.c has a few unsigned variables that were
being
implicitly handled as (32-bit) ints, those variables are actually used as (or
in the calculation of)
memory addresses. N
On Sat Aug 02 14:38:57 2008, tetragon wrote:
> Using a lightly modified config (RT#57532), I got parrot to build as a
> 64-bit Intel binary on OS X. One of a series of segfaults encountered
> appears to be triggered in Parrot_memalign in
> config/gen/platform/darwin/memalign.c (if gdb is to be bel
Author: infinoid
Date: Wed Aug 6 21:32:18 2008
New Revision: 30081
Modified:
trunk/docs/pdds/pdd13_bytecode.pod
Log:
[docs/pdds/pdd13] Add the ability to delete a segment from a PackfileDirectory,
per my discussion with jonathan++ on this subject.
Modified: trunk/docs/pdds/pdd13_bytecode.po
# New Ticket Created by Andrew Whitworth
# Please include the string: [perl #57690]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57690 >
"make headerizer" appears to be screwing up the build. When I run make
headerizer, i
On Wed, Aug 6, 2008 at 8:30 PM, Jonathan Worthington <[EMAIL PROTECTED]>wrote:
> Will Coleda wrote:
>
>> Can you describe a situation where this occurs that isn't a bug in the
>> register allocator?
>>
>>
> Yes. IIRC, it was added when I was working on the .Net bytecode translator,
> and it needed
# New Ticket Created by Andrew Whitworth
# Please include the string: [perl #57678]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57678 >
In src/stm/backend.c:wait_for_version() there are a few XXX FIXME items:
This algor
# New Ticket Created by Andrew Whitworth
# Please include the string: [perl #57676]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57676 >
In src/stm/backend.c:Parrot_STM_mark_pmc_handle(), there is the
following comment:
# New Ticket Created by Andrew Whitworth
# Please include the string: [perl #57680]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57680 >
in src/stm/backend.c:find_write_record() there are a few cleanup notes:
FIXME check
# New Ticket Created by François PERRAD
# Please include the string: [perl #57668]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57668 >
The patch contains a test case that exhibits the problem.
François.
Index: t/pmc/nam
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #57656]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57656 >
hi,
the "." has different meanings in PIR:
1. to separate object and method in a met
46 matches
Mail list logo
