All --
I've been tinkering with loading oplibs via dlopen(). This patch
works on one of my test machines, although I'd expect your mileage
to vary somewhat.
You may have to play with your LD_LIBRARY_PATH environment variable
to get the libcore_ops.so file findable by dlopen(). I had to add
'.'
The stacktest patch will fail on the current CVS source, due to a bug in
push_generic_entry.
--
Jason
Index: t/op/stacks.t
===
RCS file: /home/perlcvs/parrot/t/op/stacks.t,v
retrieving revision 1.3
diff -u -r1.3 stacks.t
---
On Sat, Oct 20, 2001 at 11:44:40AM -0400, Jason Gloudon wrote:
The stacktest patch will fail on the current CVS source, due to a bug in
push_generic_entry.
The 1-line patch to fix this was also included.
--
Jason
On Sat, 20 Oct 2001, Gregor N. Purdy wrote:
Comments? Suggestions? Critiques?
This is nifty. Couple'a things:
*) It points out a huge weakness in the build system. We need something
better to generate shared libraries
*) We definitely need to abstract out the shared library loading
code.
Dan --
Comments? Suggestions? Critiques?
This is nifty. Couple'a things:
Thanks. I really want to get enough of a solution together that we can
move the temporary during-development-only ops into a separate oplib
(call it 'devel.ops'). This then becomes proof of the overall approach
and
All --
Based on the recent exchange between Dan and I, I've revised the
dynamic oplib loading patch. Now, there is a op_lib_init()
function that gets called. It returns a pointer to an op_lib_t,
which contains the name of the oplib, the number of ops, and
pointers to the op_info and op_func
On Wed, Oct 17, 2001 at 12:45:49PM +0100, Simon Cozens wrote:
On Tue, Oct 16, 2001 at 03:43:57PM -0400, Gregor N. Purdy wrote:
I just fixed the dependancy. Hopefully, this problem goes away now.
Nope.
Fixed it up, and also fixed some problems with the clean target.
Any volunteers
Why is make test so durn slow? Our tools run individually seem pretty
snappy on my low-end box (P200/64MB) but running make test is like
watching paint dry. I'm seeing something like 1 test per second!
Please feel free to point me to TFM if this question is answered there.
-sam
Sam --
Why is make test so durn slow? Our tools run individually seem pretty
snappy on my low-end box (P200/64MB) but running make test is like
watching paint dry. I'm seeing something like 1 test per second!
I think its because each test involves:
1. Write out a .pasm file
2. Run
On Thu, 2001-10-11 at 12:24, Dan Sugalski wrote:
No, we don't have to do it in C. We can do it in perl, we just can't
require perl for the initial build. The steps would be:
1) Build minimal perl 6 with default parameters using platform build tool
2) Run configure with minimal perl 6
3)
Here's a patch to fix logical ops in the Parrot Scheme compiler. The
patch:
- Implements (min) and (max) which had stubs and some =pod'd out code
which I couldn't understand.
- Fixes (=), (), (), (=) and (=) to work with more than 2 operands.
Added tests where they were missing
On 20 Oct 2001, Gregor N. Purdy wrote:
I want to libify everything to the point where Perl wrappers around
the libs allow you to pass the .pasm stuff as a string and get back
a packfile that you can pass on to the interpreter, without firing
off separate processes and writing files.
Sounds
On Thu, 2001-10-11 at 15:06, Josh Wilmes wrote:
It seems to me that we should look at cons before writing Yet Another Perl
Build System. (i haven't used it myself, so I don;'t know if it's good
or not). For reference: http://www.dsmit.com/cons/
I like Cons, but I don't think it's
Judging by the patches, this was a much earlier version than I intended to
post. In the current version, min and max are now implemented, and test files
evaluate two-operand and three-operand versions. The (=) operands work now
with more than two operands, and I've added tests for these with
All --
Judging by the patches, this was a much earlier version than I intended to
post. In the current version, min and max are now implemented, and test files
evaluate two-operand and three-operand versions. The (=) operands work now
with more than two operands, and I've added tests for
Thanks for your confidence. Since one of the goals for Parrot seemed to be the
ability to target multiple languages to a single backend, I figured that we had to
have at least two languages to work with. That, and Scheme seemed to be a fairly
simple language to parse.
My code is currently in
On Sat, Oct 20, 2001 at 08:11:27PM +0200, raptor wrote:
will it be possible to do this inside Perl program :
use parrot;
...parrot code...
no parrot;
Bad idea of the day -- Inline::Parrot!
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality
hi,
will it be possible to do this inside Perl program :
use parrot;
...parrot code...
no parrot;
OR
sub mysub is parrot {
parrot code ...
}
=
iVAN
[EMAIL PROTECTED]
=
18 matches
Mail list logo
