So, given the below, looks like we've got everything sewn up and the
long-awaited day of the STM merge is upon us.
Charles, care to do the honors?
On Tue, Aug 15, 2006 at 06:31:38PM -0400, Charles Reiss wrote:
> On 8/15/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> >On Sat, Aug 12, 2006 at 08:
On 8/15/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
On Sat, Aug 12, 2006 at 08:14:52PM -0400, Charles Reiss wrote:
> I wrote:
[snip]
> >It also does not allow .pmc files to overide the default idea of
> >whether a vtable method is read-only.
>
> This remains unresolved though I'm not certain
On Sat, Aug 12, 2006 at 08:14:52PM -0400, Charles Reiss wrote:
> I wrote:
> >The read-only variant generation currently does not handle NCI methods
> >at all. There are number of implementation options; the best I can
> >think of is to override findmethod (in the read-only type) to check
> >for a p
On Fri, Aug 11, 2006 at 04:38:59PM -0400, Charles Reiss wrote:
> On 8/10/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > /* XXX is it okay to combine flatten/slurpy into one flag? */
> >
> > The answer is "No": "flat" is an output flag, "slurpy_array" is an input
> > flag, and there's no
I wrote:
[snip]
I suppose trying to make '@' mean something different for signatures and for
calls from C (as I have done) is a Bad Idea as long as the same code is used
to parse the signatures in both cases. The easy solution is to choose
a character
other than '@' for one of the directions thou
On 8/10/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
More on the STM branch:
ANSWERS, FOR A CHANGE
* A comment asks:
/* XXX is it okay to combine flatten/slurpy into one flag? */
The answer is "No": "flat" is an output flag, "slurpy_array" is an input
flag, and there's no guara
More on the STM branch:
ANSWERS, FOR A CHANGE
* A comment asks:
/* XXX is it okay to combine flatten/slurpy into one flag? */
The answer is "No": "flat" is an output flag, "slurpy_array" is an input
flag, and there's no guarantee that the input and output flags won't
conflict wi
