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
>
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 thr
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 fo
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
'.' t
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
--- 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. dlop
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
an
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 miss
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]
=
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 array
On Fri, 19 Oct 2001, Jeff wrote:
> For a -very- primitive Scheme -> Parrot compiler, see
>
> http://216.254.0.2/~jgoff/Files/scheme.tar.gz
Woo hoo!
> Test files (using the provided version of Test::More) are in the t/
> directory, and can be run by typing 'make test' at the command line. The
>
> 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.
> An
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.
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
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 CVS,
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.
Soun
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 appr
19 matches
Mail list logo
