[MSWin32] Helping The Paranoid Parrot on Windows

1 view
Skip to first unread message

Ron Blaschke

unread,
Mar 27, 2005, 11:18:22 AM3/27/05
to Leopold Toetsch, perl6-i...@perl.org
I've been experimenting with dynamic linkage on Windows. As a teaser
to read on, here's how far I've got.
Before
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t\dynclass\foo.t 1 256 1 1 100.00% 1
t\dynclass\gdbmhash.t 13 3328 13 13 100.00% 1-13
t\dynclass\pybuiltin.t 6 1536 6 6 100.00% 1-6
t\dynclass\pyclass.t 6 1536 6 6 100.00% 1-6
t\dynclass\pycomplex.t 1 256 1 1 100.00% 1
t\dynclass\pyfunc.t 4 1024 4 4 100.00% 1-4
t\dynclass\pyint.t 25 6400 25 25 100.00% 1-25
t\op\spawnw.t 2 512 3 2 66.67% 2-3
3 tests and 66 subtests skipped.
Failed 8/141 test scripts, 94.33% okay. 58/2263 subtests failed, 97.44% okay.

After
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t\op\spawnw.t 2 512 3 2 66.67% 2-3
3 tests and 65 subtests skipped.
Failed 1/139 test scripts, 99.28% okay. 2/2257 subtests failed, 99.91% okay.


Don't worry about spawn at the moment, it broke some week ago, and is
not related to the linkage problem.

There's quite a number of changes involved, here's my proposal of how
to change things. Choosing early on static or dynamic linkage, and
changing the library names, is not strictly necessary, but would
probably make things simpler, and Parrot feel more at home on
Windows, respectively.

- Parrot should be told during Configure to be built static
or dynamic (shared); it should probably be dynamic on most systems

- A static Parrot should not run the dynclasses tests

- The parrot library should be named C<parrot.lib> and
C<parrot${MAJOR}${MINOR}.dll> on Windows

- The dynamic parrot library C<parrot01.dll> should be in the same
directory as C<parrot.exe>, or otherwise it must be a)explicity loaded
or b)the directory added to the PATH environment.

- Paths and/or linkage instructions should be updated accordingly, eg
F<lib/Parrot/Test.pm>
(my $libparrot_root = $PConfig{blib_lib_libparrot_a}) =~ s/\$\(A\)//;
my $libparrot_dynamic = $libparrot_root.$PConfig{share_ext};

my $libparrot;

# use shared library version if available
if( -e $libparrot_dynamic ) {
$libparrot = '-Lblib/lib -lparrot';
} else {
$libparrot = $libparrot_root.$PConfig{a};
}

- There should be a macro PARROT_API, which hints the compiler how to
link things, on platforms that support it. Eg, on Windows it should
expand to
'__declspec(dllexport)' if a symbol should be exported (dynamic)
'__declspec(dllimport)' if a symbol should be imported (dynamic)
empty string (static)
PARROT_API must be added to each API symbol of the library.

- A similar macro must be present for each library, which means there
must be a different one for dynclasses (PARROT_DYNCLASSES_API), as the
symbols of libparrot must be imported, and the symbols of the
dynclasses exported.


I have some questions, too.

- After I changed the linkage, some dynclasses failed, during access
of C<Parrot_base_vtables[100]>. 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
else bitten by this? Somehow my fault? Shouldn't it be dynamically
resized?

- I'm not sure where IMCC belongs. I'd guess it goes into libparrot.
But F<imcc/main.c> goes into the parrot executable. Yet, this one
depends on parser symbols (line, yyparse, yyin, yydebug, yylex), which
probably should not be exported by libparrot. Any hints?


Comments are highly appreciated, especially from the Win32 folks.

Leo, if that's okay, I'll wait for your "GO" before preparing and
submitting any patches.

Frohe Ostern,
Ron


Leopold Toetsch

unread,
Mar 28, 2005, 4:52:05 AM3/28/05
to Ron Blaschke, perl6-i...@perl.org, ch...@pobox.com
Ron Blaschke <mailin...@rblasch.org> wrote:

> After
> Failed Test Stat Wstat Total Fail Failed List of Failed
> -------------------------------------------------------------------------------
> t\op\spawnw.t 2 512 3 2 66.67% 2-3

Great.

[ ... the plan ]

> Comments are highly appreciated, especially from the Win32 folks.

Yes.

> Leo, if that's okay, I'll wait for your "GO" before preparing and
> submitting any patches.

Seems to work and do the right thing, but my knowledge of Win32 and
other architectures is rather limited. I'll leave it to Chip.

> Frohe Ostern,
> Ron

Same to you,
leo

Chip Salzenberg

unread,
Mar 28, 2005, 11:02:46 AM3/28/05
to Ron Blaschke, Leopold Toetsch, perl6-i...@perl.org
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<parrot.lib> and
> C<parrot${MAJOR}${MINOR}.dll> 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 three parts. Closer to
release you could change the Win32 DLL name to be based only on the
top two, since changes in the third number will not involve any issues
of binary compatibility[*], but at least during early development it
would be a Good Idea to include all three.

> - The dynamic parrot library C<parrot01.dll> should be in the same
> directory as C<parrot.exe>, or otherwise it must be a)explicity loaded
> or b)the directory added to the PATH environment.

OK. I haven't done much Windows software work since Win98; what's the
standard way of making a command (e.g. "parrot") available from [a]
the Win32 command line and [b] the Win32 spawn interface? The old
hack of adding PATH statements to autoexec.bat doesn't work any more.
Or so I'm told. :-)

> - Paths and/or linkage instructions should be updated accordingly, eg
> F<lib/Parrot/Test.pm>
> (my $libparrot_root = $PConfig{blib_lib_libparrot_a}) =~ s/\$\(A\)//;
> my $libparrot_dynamic = $libparrot_root.$PConfig{share_ext};
>
> my $libparrot;
>
> # use shared library version if available
> if( -e $libparrot_dynamic ) {
> $libparrot = '-Lblib/lib -lparrot';
> } else {
> $libparrot = $libparrot_root.$PConfig{a};
> }

I think I see where you're going with this, but why test for existence
of the dll?? If a given Parrot instance included a libparrot.dll at
build time, then assume it's there; otherwise, assume it's not. The
only way these assumptions could be wrong is (1) we have a bug or (2)
the filesystem being modified in unsupported ways. I'm not interested
in papering over either of those cases.

> - There should be a macro PARROT_API, which hints the compiler how to
> link things, on platforms that support it. Eg, on Windows it should
> expand to
> '__declspec(dllexport)' if a symbol should be exported (dynamic)
> '__declspec(dllimport)' if a symbol should be imported (dynamic)
> empty string (static)
> PARROT_API must be added to each API symbol of the library.

By "added" you mean in the .h, or the .c, or both? And if both, will
the same macro with the same definition work for both places?

> - A similar macro must be present for each library, which means there
> must be a different one for dynclasses (PARROT_DYNCLASSES_API), as the
> symbols of libparrot must be imported, and the symbols of the
> dynclasses exported.

Looking at this from the point of view of a third-party PMC author,
might "PARROT_EXPORT" be closer to the relevant idea? From the
interface design perspective, does it matter whether I'm writing a
"DYNCLASS" or something else?

But then there are the fourth-party authors who want to #include the
headers that came with the third-party PMC, because they're using its
library bits or extending it. The system should support them, too,
and without inventing a new namespace ("DYNCLASSES" et al).

> - After I changed the linkage, some dynclasses failed, during access
> of C<Parrot_base_vtables[100]>. 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
> else bitten by this? Somehow my fault? Shouldn't it be dynamically
> resized?

Absolutely. I don't want to speak for Leo, but: "Patches welcome."

> - I'm not sure where IMCC belongs. I'd guess it goes into libparrot.
> But F<imcc/main.c> goes into the parrot executable. Yet, this one
> depends on parser symbols (line, yyparse, yyin, yydebug, yylex), which
> probably should not be exported by libparrot. Any hints?

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 you'd like to experiment with putting IMCC
into libparrot, bison's "-p prefix" option seems relevant: "Rename the
external symbols used in the parser so that they start with prefix
instead of yy." Maybe "-p Parrot_imcc_"?

[*] Is there already a version number policy sketched out?
--
Chip Salzenberg - a.k.a. - <ch...@pobox.com>
Open Source is not an excuse to write fun code
then leave the actual work to others.

MrJoltCola

unread,
Mar 28, 2005, 4:28:37 PM3/28/05
to Ron Blaschke, Chip Salzenberg, Leopold Toetsch, perl6-i...@perl.org
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 you'd like to experiment with putting IMCC
> > into libparrot, bison's "-p prefix" option seems relevant: "Rename the
> > external symbols used in the parser so that they start with prefix
> > instead of yy." Maybe "-p Parrot_imcc_"?
>
>I have left things as-is while getting linkage correctly. That is,
>most of IMCC is currently part of libparrot (only F<main.c> is not).
>In the beginning, I thought IMCC is part of the parrot executable, but
>reality left me puzzled, so I thought I'll leave the decision to you.

IMCC is integral for Parrot in order to eval/compile new PASM and PIR at
runtime. If you ONLY want to support precompiled bytecodes you
can get by without it but for quite some time now IMCC _is_ the
Parrot front end.

It might make sense to provide separate libparrotvm without dynamic eval
capability so you can leave out the actual compiler and register allocator
and have it loaded on demand (libparrotimcc or some such).
This would help save memory in the default case.

-Melvin


Ron Blaschke

unread,
Mar 28, 2005, 4:44:35 PM3/28/05
to MrJoltCola, Chip Salzenberg, Leopold Toetsch, perl6-i...@perl.org
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 Point.
>>I have left things as-is while getting linkage correctly. That is,
>>most of IMCC is currently part of libparrot (only F<main.c> is not).
>>In the beginning, I thought IMCC is part of the parrot executable, but
>>reality left me puzzled, so I thought I'll leave the decision to you.

> IMCC is integral for Parrot in order to eval/compile new PASM and PIR at
> runtime. If you ONLY want to support precompiled bytecodes you
> can get by without it but for quite some time now IMCC _is_ the
> Parrot front end.

> It might make sense to provide separate libparrotvm without dynamic eval
> capability so you can leave out the actual compiler and register allocator
> and have it loaded on demand (libparrotimcc or some such).
> This would help save memory in the default case.

So, I guess the yacc stuff - yylex, yyparse, yyin and such - should be
hidden somewhere inside IMCC, behind an interface, which would then be
part of libparrot interface?

Ron

Ron Blaschke

unread,
Mar 28, 2005, 4:08:10 PM3/28/05
to Chip Salzenberg, Leopold Toetsch, perl6-i...@perl.org
Chip Salzenberg wrote:
> According to Ron Blaschke:

>> - The parrot library should be named C<parrot.lib> and


>> C<parrot${MAJOR}${MINOR}.dll> 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 three parts. Closer to
> release you could change the Win32 DLL name to be based only on the
> top two, since changes in the third number will not involve any issues
> of binary compatibility[*], but at least during early development it
> would be a Good Idea to include all three.

The idea was mainly stolen from other projects, guess it's some sort
of convention on Windows. Eg, Microsoft Visual C++ 7.1 distributes
its C Runtime as F<msvcrt71.dll>. The ICU data library 3.0 is named
F<icudt30.dll>, Perl 5.8.6 called F<perl58.dll>. Adding all three
parts, with dots, will work nicely, too, I guess.


>> - The dynamic parrot library C<parrot01.dll> should be in the same
>> directory as C<parrot.exe>, or otherwise it must be a)explicity loaded
>> or b)the directory added to the PATH environment.

> OK. I haven't done much Windows software work since Win98; what's the
> standard way of making a command (e.g. "parrot") available from [a]
> the Win32 command line and [b] the Win32 spawn interface? The old
> hack of adding PATH statements to autoexec.bat doesn't work any more.
> Or so I'm told. :-)

Not sure I get your question right, but libraries are mostly located
in the same directory as the executable, which is called "private DLL"
or "side-by-side installation." The reason for this is that Windows
favours this location, it is the first place Windows looks for the
library (even before the system directory).

>> - Paths and/or linkage instructions should be updated accordingly, eg
>> F<lib/Parrot/Test.pm>

[snip]


>> # use shared library version if available
>> if( -e $libparrot_dynamic ) {
>> $libparrot = '-Lblib/lib -lparrot';
>> } else {
>> $libparrot = $libparrot_root.$PConfig{a};
>> }

> I think I see where you're going with this, but why test for existence
> of the dll?? If a given Parrot instance included a libparrot.dll at
> build time, then assume it's there; otherwise, assume it's not. The
> only way these assumptions could be wrong is (1) we have a bug or (2)
> the filesystem being modified in unsupported ways. I'm not interested
> in papering over either of those cases.

Sorry, I should have been more explicit on this. Above code is taken
from the current Parrot::Test, and I think we both agree that it's not
the best way to do things. This, and the dynclasses tests, were the
reason I proposed the dynamic/static decision on Configure time. I've
stumbled over above code as I needed to get linkage of F<t/src/*.t>
tests right, for which C<$libparrot = 'blib/lib/libparrot.lib'> was
necessary.

>> - There should be a macro PARROT_API, which hints the compiler how to
>> link things, on platforms that support it. Eg, on Windows it should
>> expand to
>> '__declspec(dllexport)' if a symbol should be exported (dynamic)
>> '__declspec(dllimport)' if a symbol should be imported (dynamic)
>> empty string (static)
>> PARROT_API must be added to each API symbol of the library.

> By "added" you mean in the .h, or the .c, or both? And if both, will
> the same macro with the same definition work for both places?

Sorry again. Guess I've been pondering these issues too long, and
think way too much in Win32 terms.

A "common" Windows idiom is to add the following to the header.
#if defined(PARROT_EXPORTS)
#define PARROT_API __declspec(dllexport)
#else
#define PARROT_API __declspec(dllimport)
#endif

Symbols that should be exported get tagged on declaration.
PARROT_API void f();
PARROT_API int i;

Then, C<PARROT_EXPORTS> is defined during compilation of the library,
which yields C<__declspec(dllexport)>, and not defined during usage of
the library, yielding C<__declspec(dllimport)>.

As there are several headers for parrot, I'd guess we'd have a
F<include/parrot/api.h> which defines above, and used as necessary.

There would be another way to get functions exported, namely by
providing an C<EXPORTS> section in a separate module definition file,
which would contain a list of all functions to be exported. The
module definition file would be another argument to the linker. This
would not work with the current implementation, as data is accessed as
well, eg C<Parrot_base_vtables>, where C<__declspec> is the only way
to get hold of.


>> - A similar macro must be present for each library, which means there
>> must be a different one for dynclasses (PARROT_DYNCLASSES_API), as the
>> symbols of libparrot must be imported, and the symbols of the
>> dynclasses exported.

> Looking at this from the point of view of a third-party PMC author,
> might "PARROT_EXPORT" be closer to the relevant idea? From the
> interface design perspective, does it matter whether I'm writing a
> "DYNCLASS" or something else?

It's a matter of what is inside or outside of a library, I guess. For
a dynclass, parrot is on the outside, that's why I thought of a
different macro. That is, when compiling a dynclass, parrot's symbols
must be imported, and that of the dynclass exported. Am I making any
sense, or am I getting all confused here?

>> - After I changed the linkage, some dynclasses failed, during access
>> of C<Parrot_base_vtables[100]>. 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
>> else bitten by this? Somehow my fault? Shouldn't it be dynamically
>> resized?
> Absolutely. I don't want to speak for Leo, but: "Patches welcome."

Hope someone else, who's deeper in the core, can tackle this one.


>> - I'm not sure where IMCC belongs. I'd guess it goes into libparrot.
>> But F<imcc/main.c> goes into the parrot executable. Yet, this one
>> depends on parser symbols (line, yyparse, yyin, yydebug, yylex), which
>> probably should not be exported by libparrot. Any hints?

> 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 you'd like to experiment with putting IMCC
> into libparrot, bison's "-p prefix" option seems relevant: "Rename the
> external symbols used in the parser so that they start with prefix
> instead of yy." Maybe "-p Parrot_imcc_"?

I have left things as-is while getting linkage correctly. That is,


most of IMCC is currently part of libparrot (only F<main.c> is not).
In the beginning, I thought IMCC is part of the parrot executable, but
reality left me puzzled, so I thought I'll leave the decision to you.

;-)

Ron


MrJoltCola

unread,
Mar 28, 2005, 5:11:54 PM3/28/05
to Ron Blaschke, Chip Salzenberg, Leopold Toetsch, perl6-i...@perl.org

Yes, I think so. Of course I always wanted to write a pure parrot form of the
whole IMCC compiler, but nowadays Parrot is so reliant on C that it seems
a pointless exercise to go "Pure Parrot" until the whole community gets
on-board.

-Melvin

Chip Salzenberg

unread,
Mar 28, 2005, 5:07:55 PM3/28/05
to Ron Blaschke, Leopold Toetsch, perl6-i...@perl.org
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 important Windows tool (e.g. InstallShield), you can revert to
parrot09.dll just before 1.0 and parrot10.dll for 1.0. But I'd be
surprised if it were necessary -- the two-digit naming convention
smells like something invented for 8.3 filenames and never revisited.

> > OK. I haven't done much Windows software work since Win98; what's the
> > standard way of making a command (e.g. "parrot") available from [a]
> > the Win32 command line and [b] the Win32 spawn interface?
>

> Not sure I get your question right, but libraries are mostly located

> in the same directory as the executable [...]

No, sorry; I was changing the subject slightly. When the user types
"parrot" in his Windows command prompt window, how did the Parrot
installer make sure that Windows knows where to find parrot.exe?

[explanation of "__declspec(dll{im,ex}port)"]

> There would be another way to get functions exported, namely by
> providing an C<EXPORTS> section in a separate module definition
> file, which would contain a list of all functions to be exported.

> [...] This would not work with the current implementation, as data


> is accessed as well, eg C<Parrot_base_vtables>, where C<__declspec>
> is the only way to get hold of.

Darn. Last I heard, we have to make an exports file *anyway* to
support AIX. If that same same exports file could support creation of
both Win32 and AIX libraries, we'd be saved from the trouble of the
PARROT_API macro, and I'd be a happy camper.

How many variables need to be exported currently? I'd consider it an
API feature if there were no exported variables whatsoever, and all
the current public data were made available through a public function
API.

> It's a matter of what is inside or outside of a library, I guess. For
> a dynclass, parrot is on the outside, that's why I thought of a
> different macro. That is, when compiling a dynclass, parrot's symbols
> must be imported, and that of the dynclass exported. Am I making any
> sense, or am I getting all confused here?

You're making sense, but perhaps I didn't. Let me stop giving you a
solution and give you a requirement instead, and let you come up with
the solution.

I'm (mildly) concerned about macro namespace issues and portability
encapsulation WRT the API macros. (Macro name conflicts really bite.)

* It would be good if the author of a random DLL could be absolutely
sure that the FOO_API macro name he chooses is globally (and I mean
*globally*) unique; perhaps this is a problem that lay outside the
realm of what you're currently trying to solve, but perhaps not.

* It would also be good if the details of the "export me" and "import
me" macro _expansions_ were not something that the DLL author had to
know or worry about. Ideally, I'd like to see the definition of the
FOO_API macro be handled by the equivalent of Module::Starter or
h2xs, and all the author has to do is make sure he picks a good name
for it.

Again, I'm only mildly concerned about these issues. I'm only
spelling them out in detail in an attempt at clarity.

Ron Blaschke

unread,
Mar 29, 2005, 4:17:14 AM3/29/05
to Chip Salzenberg, Leopold Toetsch, perl6-i...@perl.org
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 something that matters,
> like an important Windows tool (e.g. InstallShield), you can revert to
> parrot09.dll just before 1.0 and parrot10.dll for 1.0. But I'd be
> surprised if it were necessary -- the two-digit naming convention
> smells like something invented for 8.3 filenames and never revisited.

Yeah, people are probably scared that Microsoft drops long file name
support. ;-)


>> > OK. I haven't done much Windows software work since Win98; what's the
>> > standard way of making a command (e.g. "parrot") available from [a]
>> > the Win32 command line and [b] the Win32 spawn interface?
>>
>> Not sure I get your question right, but libraries are mostly located
>> in the same directory as the executable [...]

> No, sorry; I was changing the subject slightly. When the user types
> "parrot" in his Windows command prompt window, how did the Parrot
> installer make sure that Windows knows where to find parrot.exe?

Just by adding the F<bin> directory to the PATH environment variable,
usually the system wide one.

>> There would be another way to get functions exported, namely by
>> providing an C<EXPORTS> section in a separate module definition
>> file, which would contain a list of all functions to be exported.
>> [...] This would not work with the current implementation, as data
>> is accessed as well, eg C<Parrot_base_vtables>, where C<__declspec>
>> is the only way to get hold of.

> How many variables need to be exported currently? I'd consider it an


> API feature if there were no exported variables whatsoever, and all
> the current public data were made available through a public function
> API.

Let's see...
Parrot_base_vtables
pio_stdio_layer
op_jit
yyin

I guess that's it.


>> It's a matter of what is inside or outside of a library, I guess. For
>> a dynclass, parrot is on the outside, that's why I thought of a
>> different macro. That is, when compiling a dynclass, parrot's symbols
>> must be imported, and that of the dynclass exported. Am I making any
>> sense, or am I getting all confused here?

> You're making sense, but perhaps I didn't. Let me stop giving you a
> solution and give you a requirement instead, and let you come up with
> the solution.

> I'm (mildly) concerned about macro namespace issues and portability
> encapsulation WRT the API macros. (Macro name conflicts really bite.)

[good points snipped]

> Again, I'm only mildly concerned about these issues. I'm only
> spelling them out in detail in an attempt at clarity.

I see where you are going. I've never given this too much thought
until now. Good that you are wearing the hat, not me. ;-)

Ron


Leopold Toetsch

unread,
Mar 29, 2005, 2:49:25 AM3/29/05
to Chip Salzenberg, perl6-i...@perl.org
Chip Salzenberg <ch...@pobox.com> wrote:
> According to Ron Blaschke:

>> - After I changed the linkage, some dynclasses failed, during access


>> of C<Parrot_base_vtables[100]>. 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
>> else bitten by this? Somehow my fault? Shouldn't it be dynamically
>> resized?

> Absolutely. I don't want to speak for Leo, but: "Patches welcome."

include/parrot/pmc.h:#define PARROT_MAX_CLASSES 100

include/parrot/pmc.h:VAR_SCOPE VTABLE **Parrot_base_vtables; \
/*[PARROT_MAX_CLASSES];*/

C<PARROT_MAX_CLASSES> defines the initial allocation size,
C<Parrot_base_vtables> should grow on demand. Maybe there's a bug in the
resizing code.

> 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.

Inside imcc/main.c is Parrot's main() entry. As soon as you load a
sourcecode file with C<load_bytecode>, the assemblers inside imcc are
needed to translate the source to PBC.

leo

Chip Salzenberg

unread,
Mar 29, 2005, 7:53:05 AM3/29/05
to Ron Blaschke, Leopold Toetsch, perl6-i...@perl.org
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 doable then. Excellent.

Chip Salzenberg

unread,
Mar 29, 2005, 7:57:04 AM3/29/05
to Leopold Toetsch, perl6-i...@perl.org
According to Leo Toetsch:

> Chip Salzenberg <ch...@pobox.com> 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.
>
> Inside imcc/main.c is Parrot's main() entry. As soon as you load a
> sourcecode file with C<load_bytecode>, the assemblers inside imcc are
> needed to translate the source to PBC.

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...?

Leopold Toetsch

unread,
Mar 29, 2005, 10:29:55 AM3/29/05
to Chip Salzenberg, perl6-i...@perl.org
Chip Salzenberg <ch...@pobox.com> 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 could be useful in secure
environments: just run the PBC that is there, nothing else.

leo

Chip Salzenberg

unread,
Mar 29, 2005, 10:37:28 AM3/29/05
to Leopold Toetsch, perl6-i...@perl.org
According to Leo Toetsch:
> Chip Salzenberg <ch...@pobox.com> 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 it could be useful in secure
> environments: just run the PBC that is there, nothing else.

Mm, but I'd think that true secure environments will need stronger
controls than just "no evals". Let's not spend any work on
libparrotvm just yet.

Reply all
Reply to author
Forward
0 new messages