According to Leo Toetsch:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > It's been suggested to create a libparrotvm at some point, with
> > PBC support but no imcc/pir/ast(?); but given our target
> > languages, I don't see that it would get much usage...?
>
> No eval-like functionality. OTOH i
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> OK, no point in dividing that. It's been suggested to create a
> libparrotvm at some point, with PBC support but no imcc/pir/ast(?);
> but given our target languages, I don't see that it would get much
> usage...?
No eval-like functionality. OTOH it c
According to Leo Toetsch:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > On the one hand, IMCC doesn't really help you _run_ code, so I'm not
> > inclined to see it part of libparrot. On the other hand, I haven't
> > grokked the entire code base organization, so I could be Greatly
> > Missing Th
According to Ron Blaschke:
> Chip Salzenberg wrote:
> > How many variables need to be exported currently? I'd consider it an
> > API feature if there were no exported variables whatsoever ...
>
> Let's see...
> Parrot_base_vtables
> pio_stdio_layer
> op_jit
> yyin
>
> I guess that's it.
That's
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> According to Ron Blaschke:
>> - After I changed the linkage, some dynclasses failed, during access
>> of C. No surprise, as the array is only
>> C<#define PARROT_MAX_CLASSES 100>
>> long. After I changed it to 1000, the tests passed. Why gets no one
Chip Salzenberg wrote:
> According to Ron Blaschke:
>> The idea [of parrot01.dll] was mainly stolen from other projects,
>> guess it's some sort of convention on Windows. [...] Adding all
>> three parts, with dots, will work nicely, too, I guess.
> That'd be great. If you get pushback from some
At 04:44 PM 3/28/2005, Ron Blaschke wrote:
MrJoltCola wrote:
> At 04:08 PM 3/28/2005, Ron Blaschke wrote:
>> > On the one hand, IMCC doesn't really help you _run_ code, so I'm not
>> > inclined to see it part of libparrot. On the other hand, I haven't
>> > grokked the entire code base organization
According to Ron Blaschke:
> The idea [of parrot01.dll] was mainly stolen from other projects,
> guess it's some sort of convention on Windows. [...] Adding all
> three parts, with dots, will work nicely, too, I guess.
That'd be great. If you get pushback from something that matters,
like an im
MrJoltCola wrote:
> At 04:08 PM 3/28/2005, Ron Blaschke wrote:
>> > On the one hand, IMCC doesn't really help you _run_ code, so I'm not
>> > inclined to see it part of libparrot. On the other hand, I haven't
>> > grokked the entire code base organization, so I could be Greatly
>> > Missing The Po
At 04:08 PM 3/28/2005, Ron Blaschke wrote:
> On the one hand, IMCC doesn't really help you _run_ code, so I'm not
> inclined to see it part of libparrot. On the other hand, I haven't
> grokked the entire code base organization, so I could be Greatly
> Missing The Point.
> On the gripping hand, if
Chip Salzenberg wrote:
> According to Ron Blaschke:
>> - The parrot library should be named C and
>> C on Windows
> OK, but will Windows allow delimiter(s) on the DLL name? Without
> them, there's an ambiguity (is "parrot110.dll" 1.10 or 11.0?).
> Also, Parrot release numbers currently have thr
According to Ron Blaschke:
> - Parrot should be told during Configure to be built static
> or dynamic (shared); it should probably be dynamic on most systems
Yes.
> - The parrot library should be named C and
> C on Windows
OK, but will Windows allow delimiter(s) on the DLL name? Without
them,
Ron Blaschke <[EMAIL PROTECTED]> wrote:
> After
> Failed Test Stat Wstat Total Fail Failed List of Failed
> ---
> t\op\spawnw.t2 512 32 66.67% 2-3
Great.
[ ... the plan ]
> Comments are highly ap
I've been experimenting with dynamic linkage on Windows. As a teaser
to read on, here's how far I've got.
Before
Failed TestStat Wstat Total Fail Failed List of Failed
---
t\dynclass\foo.t 1 25
14 matches
Mail list logo
