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.
Ron Blaschke <mailing-li...@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.
> - 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. - <c...@pobox.com> Open Source is not an excuse to write fun code then leave the actual work to others.
> > 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.
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?
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. ;-)
>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?
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.
> 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. -- Chip Salzenberg - a.k.a. - <c...@pobox.com> Open Source is not an excuse to write fun code then leave the actual work to others.
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.
>> 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. ;-)
Chip Salzenberg <c...@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."
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.
> 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 ...
That's doable then. Excellent. -- Chip Salzenberg - a.k.a. - <c...@pobox.com> Open Source is not an excuse to write fun code then leave the actual work to others.
> Chip Salzenberg <c...@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...? -- Chip Salzenberg - a.k.a. - <c...@pobox.com> Open Source is not an excuse to write fun code then leave the actual work to others.
Chip Salzenberg <c...@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.
> Chip Salzenberg <c...@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. -- Chip Salzenberg - a.k.a. - <c...@pobox.com> Open Source is not an excuse to write fun code then leave the actual work to others.
|
