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 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
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
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
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
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
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
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
>
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.
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
> 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
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
>
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
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]
=
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
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
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
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/
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
19 matches
Mail list logo
