On Fri, 17 Sep 2010 11:43:55 -0400, Andrew Whitworth
wrote:
> On Fri, Sep 17, 2010 at 11:18 AM, Peter Lobsinger wrote:
>> But more to the point, they are insufficient for handling aggregates.
>> If a PMC cointaining ATTR isn't a simple PMC*, but something more
>> complicated (like PMC**), the who
On Fri, Sep 17, 2010 at 3:55 PM, Nick Wellnhofer wrote:
> On 17/09/10 19:34, Peter Lobsinger wrote:
>>
>> I think we need both a deprecation notice and stub implementations of
>> these macros by 2.9. Being able to assign simply by using 'x = y' is
>> pretty much taken for granted, and we'll be bra
> However, NotFound suggested that some other discussion that was not
> included in the ticket came to an opposite conclusion: that we should
> rip this method out entirely and instead rely on some of the dynops in
> the io.ops set. I haven't been able, in a short search, to find any
Looks like I
On 17/09/10 23:14, Andrew Whitworth wrote:
Those macros, SET_PMC_REF and SET_STRING_REF work well for me. We need
to think carefully about how we want to add these things, however,
considering that our GC systems are (in theory anyway) selectable. If
every single one of these becomes an indirect
Those macros, SET_PMC_REF and SET_STRING_REF work well for me. We need
to think carefully about how we want to add these things, however,
considering that our GC systems are (in theory anyway) selectable. If
every single one of these becomes an indirect function call, we could
end up eating a lot o
On 17/09/10 19:34, Peter Lobsinger wrote:
I think we need both a deprecation notice and stub implementations of
these macros by 2.9. Being able to assign simply by using 'x = y' is
pretty much taken for granted, and we'll be braking that assumption.
Yes, we should start with a stub implementati
http://trac.parrot.org/parrot/ticket/264
The last comment from Allison in that ticket recommends we break up
the stdhandle method, which is not clearly named, into several
individual methods for each standard handle: input, output, and error.
However, NotFound suggested that some other discussion
On Fri, Sep 17, 2010 at 11:43 AM, Andrew Whitworth
wrote:
> On Fri, Sep 17, 2010 at 11:18 AM, Peter Lobsinger wrote:
>> But more to the point, they are insufficient for handling aggregates.
>> If a PMC cointaining ATTR isn't a simple PMC*, but something more
>> complicated (like PMC**), the whole
On Fri, Sep 17, 2010 at 11:18 AM, Peter Lobsinger wrote:
> But more to the point, they are insufficient for handling aggregates.
> If a PMC cointaining ATTR isn't a simple PMC*, but something more
> complicated (like PMC**), the whole thing falls appart. Clearly you
> can still have one PMC refere
On Fri, Sep 17, 2010 at 8:49 AM, kjstol wrote:
> On Fri, Sep 17, 2010 at 6:54 AM, Peter Lobsinger wrote:
>> pirc:
>> * incompatibilities with imcc (if any) likely need deprecations
>> * stalled, so these incompatibilities are unknown at the moment
>
> I could point out a number of differences i
On 17/09/2010 17:18, Peter Lobsinger wrote:
But more to the point, they are insufficient for handling aggregates.
If a PMC cointaining ATTR isn't a simple PMC*, but something more
complicated (like PMC**), the whole thing falls appart. Clearly you
can still have one PMC reference another by these
On Fri, Sep 17, 2010 at 8:12 AM, Andrew Whitworth wrote:
> On Fri, Sep 17, 2010 at 1:54 AM, Peter Lobsinger wrote:
>> GC:
>> * Generational:
>> * requires barriers to handle bookkeeping at reference creation
>> * existing object attribute access barriers are:
>> (a) unwieldy and th
On Fri, Sep 17, 2010 at 6:54 AM, Peter Lobsinger wrote:
> Hi,
>
> As noted this week on #ps, some of the goals we have for 3.0 require
> that some existing functionality be deprecated before they can be
> complete. The 2.9 supported release next month is the last chance to
> get these deprecations
On Fri, Sep 17, 2010 at 1:54 AM, Peter Lobsinger wrote:
> GC:
> * Generational:
> * requires barriers to handle bookkeeping at reference creation
> * existing object attribute access barriers are:
> (a) unwieldy and therefore not used consistently
> (b) insufficient to support
At 9/17/2010 04:08 AM, Moritz Lenz wrote:
>Just as a data point from a language writer: Rakudo defines its own Complex
>type, because it was easier to get the dispatch right that way. Only a few
>otherwise costly functions are privately re-dispatched to parrot's Complex PMC.
>
>So we Rakudo deve
Hello,
Am 17.09.2010 00:59, schrieb Paul C. Anagnostopoulos:
At 9/16/2010 05:32 PM, Andrew Whitworth wrote:
I'm not against creating ops like this, but I would suggest instead
creating them as dynops. In fact, I would be happy to see all the trig
and hyperbolic trig ops moved to dynops, if they
16 matches
Mail list logo
