At 01:10 PM 1/2/2002 -0800, Steve Fink wrote:
Small cleanup patch:
Applied, thanks.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED]
At 01:58 PM 1/2/2002 -0600, David M. Lloyd wrote:
Silences this warning.
Applied, thanks.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED]
At 11:10 PM 1/3/2002 -0500, Bryan C. Warnock wrote:
The other obvious answer is that we don't, because it's just to difficult,
if not impossible, to do, and do well. So is it worth the effort to pursue?
FWIW, I've heard of at least one product out there that does this, though
at the machine
At 07:42 PM 1/2/2002 +, Tom Hughes wrote:
In message 20020102054642$[EMAIL PROTECTED]
David Lisa Jacobs [EMAIL PROTECTED] wrote:
Here is a short list of TODOs that I came up with for STRINGs. First, do
these look good to people? And second, what is the preferred method for
Wow, thanks for that excellent anaylsis of the problem. On the point
about the data and OS calls: You could potentially get around that by
also converting the system-call machine code into byte-code as well, in
which case your program may end up emulating some of the OS (which may
fiddle with
At 07:38 AM 1/2/2002 +, Jonathan Stowe wrote:
This quietens a warning in the Tokenizer test:
Applied, thanks.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL
At 08:20 PM 1/1/2002 -0500, Kevin Falcone wrote:
In an attempt to just keep knocking off warnings..
Applied, thanks.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL
At 04:47 PM 1/4/2002 +, Simon Glover wrote:
The enclosed patch brings the list of documentation in parrot.pod
up to date.
Applied, thanks.
Dan
--it's like this---
Dan Sugalski
C:\home\parrotperl configure.pl --defaults
Parrot Version 0.0.3 Configure
Copyright (C) 2001-2002 Yet Another Society
Since you're running this script, you obviously have
Perl 5--I'll be pulling some defaults from its configuration.
Checking the MANIFEST to make sure you have a complete Parrot
At 06:06 PM 1/4/2002 +0100, Sebastian Bergmann wrote:
test_gnuc.c
LINK : fatal error LNK1149: Output filename identical to input filename
C:\home\parrot\test_siz.exe identical
C compiler died! at configure.pl line 696.
Gah. Visual studio, right?
Dan
Dan Sugalski wrote:
Gah. Visual studio, right?
Right.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
At 06:29 PM 1/4/2002 +0100, Sebastian Bergmann wrote:
Dan Sugalski wrote:
Gah. Visual studio, right?
Right.
Okay, the problem is in the compiletestc in Configure.pl. Unfortunately I'm
not sure what's proper for this. If you could, take a look at hints/vms.pl
for how to override the
Dan Sugalski wrote:
not sure what's proper for this. If you could, take a look at
hints/vms.pl for how to override the default compiletestc sub and add
an override to hints/mswin32.pl? Or pass on the compile and link
command lines that're appropriate here and I'll wedge it in myself as
Okay, the problem is in the compiletestc in Configure.pl. Unfortunately
I'm
not sure what's proper for this. If you could, take a look at hints/vms.pl
for how to override the default compiletestc sub and add an override to
hints/mswin32.pl? Or pass on the compile and link command lines
On Fri, 4 Jan 2002, Jason Diamond wrote:
Okay, the problem is in the compiletestc in Configure.pl. Unfortunately
I'm
not sure what's proper for this. If you could, take a look at hints/vms.pl
for how to override the default compiletestc sub and add an override to
hints/mswin32.pl? Or
At 12:25 PM 1/4/2002 -0600, David M. Lloyd wrote:
I don't know if this is related, but about an hour or two ago someone
committed something that caused 'make' to not include 'CFLAGS' in the
link phase, which causes 64-bit Solaris to not build properly. Should I
be setting an additional thingy in
At 10:19 AM 1/4/2002 -0800, Jason Diamond wrote:
The attached patch builds for me on Win32. After applying it,
re-Configure.pl and make to see if I screwed up the Unix builds.
Works on Cygwin. Applied, thanks.
Dan
At 12:25 PM 1/4/2002 -0600, David M. Lloyd wrote:
I don't know if this is related, but about an hour or two ago someone
committed something that caused 'make' to not include 'CFLAGS' in the
link phase, which causes 64-bit Solaris to not build properly. Should I
be setting an additional thingy in
Okay, I just added a separate link options question and associated makefile
twiddlings to configure.pl. Any link-specific options you need can now go
there, or get jammed into $c{ldflags} if you need platform-specific bits.
Dan
This makes PerlUndef somewhat functional by adding logical,
arithmetic, and repeat methods.
Index: global_setup.c
===
RCS file: /home/perlcvs/parrot/global_setup.c,v
retrieving revision 1.12
diff -u -r1.12 global_setup.c
---
On Fri, Jan 04, 2002 at 02:57:29PM -0500, Jason Gloudon wrote:
This makes PerlUndef somewhat functional by adding logical,
arithmetic, and repeat methods.
Cool, thanks.
STRING* get_string () {
- return NULL;
+ return string_make(INTERP,NULL,0,NULL,0,NULL);
}
I did this
At 08:06 PM 1/4/2002 +, Simon Cozens wrote:
On Fri, Jan 04, 2002 at 02:57:29PM -0500, Jason Gloudon wrote:
This makes PerlUndef somewhat functional by adding logical,
arithmetic, and repeat methods.
Cool, thanks.
Want to apply the bits you want, then? Or shall I commit the whole thing?
On Fri, Jan 04, 2002 at 03:14:05PM -0500, Dan Sugalski wrote:
Adding undef to undef? Why bother? :)
Who needs to initialize variables anyway? :)
We need to add in some warning code, I think. I'll stub out an interface.
Exceptions of some kind would be nice too :)
--
Jason
Okay, I just added a separate link options question and associated
makefile
twiddlings to configure.pl. Any link-specific options you need can now go
there, or get jammed into $c{ldflags} if you need platform-specific bits.
Having the $c{ldflags} appear in compiletestc is showing warnings on
At 01:33 PM 1/4/2002 -0800, Jason Diamond wrote:
Okay, I just added a separate link options question and associated
makefile
twiddlings to configure.pl. Any link-specific options you need can now go
there, or get jammed into $c{ldflags} if you need platform-specific bits.
Having the
GCC plays the role of both compiler and linker. (Well, it compiles and
invokes ld under the hood, but it's all in one step) It can definitely
handle linker flags.
CL.exe does this, too. I just found out that you can specify link options if
you include them after a /link option at the end of
At 02:04 PM 1/4/2002 -0800, Jason Diamond wrote:
If it works for GCC to have link options appear after the filename (I'd try
it but I don't have cygwin installed here at work) then the attached patch
might work without having to override anything. (It works for me.)
Works here. In, and thanks.
Dan, back in Novemeber you mentioned talking with Eric Raymond about CML2 in
the context of the configuration and build issues surrounding Parrot. What
ever became of that?
I've also been hearing the occassional peep about a soon to materialize make
replacement. And mutterings related to
On Friday 04 January 2002 11:20 am, Dan Sugalski wrote:
At 11:10 PM 1/3/2002 -0500, Bryan C. Warnock wrote:
The other obvious answer is that we don't, because it's just to
difficult, if not impossible, to do, and do well. So is it worth the
effort to pursue?
FWIW, I've heard of at least
At 06:45 PM 1/4/2002 -0500, Bryan C. Warnock wrote:
On Friday 04 January 2002 11:20 am, Dan Sugalski wrote:
At 11:10 PM 1/3/2002 -0500, Bryan C. Warnock wrote:
The other obvious answer is that we don't, because it's just to
difficult, if not impossible, to do, and do well. So is it worth
Gregor,
You've got a disaster waiting to happen when sizeof(pointer) !=
sizeof(opcode). (64 bit/32 bit mix would be valid.)
interpreter.c, line 204:
static void **
prederef(void ** pc_prederef, struct Parrot_Interp * interpreter)
{
size_t offset =
At 09:50 PM 1/4/2002 -0500, Bryan C. Warnock wrote:
Index: interpreter.c
Applied, thanks.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED]
On Mon, Dec 31, 2001 at 10:57:54PM -0500, Bryan C. Warnock wrote:
...there's *two* of them!
My very first ever attempt at obfuscated code circa 1997.
#!/usr/lib/perl -w
use strict;
eval unpack('u*', 'JOKE');
M;7D@0'-IF5S(#T@7H;6%N('-Q=6%D('!L871O;VX@=5A;2!C;VUP86YY
I'm getting warnings on this bit of core.ops when compiling with 64-bit
ints:
op write(i|ic, i|ic) {
INTVAL * i = ($2); /* */
write($1, i, sizeof(INTVAL));
goto NEXT();
}
I'm getting a warning that stems from the fact that sizeof(INTVAL) = 8 and
sizeof(opcode_t) = 4, so the pointer
On Friday 04 January 2002 10:43 pm, David M. Lloyd wrote:
So that you can use constants that are up to sizeof(opcode_t) bytes, but
after that you're on your own. That raises a question, though: Do we
want to move integer constants into the constant table?
We're guaranteeing 32 bits of
On Fri, 4 Jan 2002, Bryan C. Warnock wrote:
On Friday 04 January 2002 10:43 pm, David M. Lloyd wrote:
So that you can use constants that are up to sizeof(opcode_t) bytes, but
after that you're on your own. That raises a question, though: Do we
want to move integer constants into the
Sample:
new P0,PerlHash
set P0,-6,foo # Store the value -6 in key 'foo' of the hash P0
set I0,P0,foo # Recover the value at foo
No work has yet been done on hash collision, and behavior for undefined
hash keys is not yet
decided upon.
--
Jeff [EMAIL PROTECTED]
Michael G Schwern:
# On Mon, Dec 31, 2001 at 10:57:54PM -0500, Bryan C. Warnock wrote:
# ...there's *two* of them!
#
# My very first ever attempt at obfuscated code circa 1997.
ROFL. Schwern, only you are weird enough to have written that... ;^)
--Brent Dax
[EMAIL PROTECTED]
Configure
Parrot Version 0.0.3 Configure
Copyright (C) 2001-2002 Yet Another Society
Since you're running this script, you obviously have
Perl 5--I'll be pulling some defaults from its configuration.
Checking the MANIFEST to make sure you have a complete Parrot kit...
No such file: classes/perlhash.pmc
Jeff G:
# new P0,PerlHash
# set P0,-6,foo # Store the value -6 in key 'foo' of the hash P0
# set I0,P0,foo # Recover the value at foo
How do you do these?
P1=P0{foo}
P0{foo}=P1
I think you're going to need retrieve and store ops:
retrieve P1, P0, foo
store P0,
Bryan --
Thanks for the message.
You've got a disaster waiting to happen when sizeof(pointer) !=
sizeof(opcode). (64 bit/32 bit mix would be valid.)
My intent in allocating a second memory block as an array of (void *) was
to make sure that I handled this case, even though it does not
At 08:26 PM 1/4/2002 -0800, Brent Dax wrote:
Jeff G:
# new P0,PerlHash
# set P0,-6,foo # Store the value -6 in key 'foo' of the hash P0
# set I0,P0,foo # Recover the value at foo
How do you do these?
P1=P0{foo}
P0{foo}=P1
set P1, P0, [foo]
set P0, [foo], P1
is what I'm
At 09:59 PM 1/4/2002 -0600, David M. Lloyd wrote:
That's what I thought I remembered; in that case, here's a patch:
Applied, thanks.
Dan
--it's like this---
Dan Sugalski even
On Friday 04 January 2002 11:38 pm, Gregor N. Purdy wrote:
You point out a place where I'm trying to resynch pc (which points into
real bytecode) with pc_prederef (which points into the array of void *s):
interpreter.c, line 204:
static void **
I'm fiddling with a compiler called tcc (i'll add it to tinderbox
shortly). It was complaining that struct _vtable was not completely
defined while building one of the test programs in Configure.pl. It was
right- at that point we generate an empty version of vtable.h, so this
struct isn't
I've added two more entries to the tinderbox. Both are on linux. Both
are not successfully building at the moment.
lcc: http://www.cs.princeton.edu/software/lcc/
lcc has been discussed before on this list- it's a fairly picky ANSI C
compiler.
tcc:
Index: classes/.cvsignore
===
RCS file: /home/perlcvs/parrot/classes/.cvsignore,v
retrieving revision 1.2
diff -u -r1.2 .cvsignore
--- classes/.cvsignore 11 Dec 2001 12:03:23 - 1.2
+++ classes/.cvsignore 5 Jan 2002
the pmc.t test 48 through 52 all fail. I've reported this two days ago
as well, seems like it hasn't been fixed yet.
nmake test also recompiles test_parrot.exe, so it's compiled once at
nmake and again at nmake test.
Ilya Sterin
48 matches
Mail list logo