Here is the first version of my little languge, Cola (Java pun intended).
Its not fancy, has few warnings, but what can I say?
Please read the README and the examples before
playing with it, and please keep all criticism constructive. ;)
It has no fancy Configure script, but it builds and tests
There may be a very good reason for this that I haven't determined but
this keeps catching me - I don't really expect 'make clean' to be deleting
files that I have deliberately made:
--- Makefile.in~Mon Mar 18 07:06:35 2002
+++ Makefile.in Mon Mar 18 07:08:26 2002
-425,7 +425,6
--- packfile.c~ Mon Mar 18 07:02:08 2002
+++ packfile.c Mon Mar 18 07:03:04 2002
-126,7 +126,7
if (segment_size % sizeof(opcode_t)) {
fprintf(stderr,
PackFile_unpack: Illegal %s table segment size %ld (must be multiple
of %ld)!\n,
-debug,
On Mon, 18 Mar 2002, Jonathan Stowe wrote:
This is a little
problematic because in ut8.c and utf16.c we are doing rather unconstly
things to variables that we hade previously declared as const,
I should qualified this: but it's probably the
OS: Win2000
Compiler: MSVC 6
Build: parrot_2002-03-18_08.tar.gz
Result:
All tests successful, 20 subtests skipped.
Files=19, Tests=313, 146 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
With the SCO development kit compiler :
[pigment.dircon.net] $ perl ./Configure.pl
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
Steve Fink:
Ok, you asked for it. I just committed the regular expression
compiler.
That might not have been an amazingly intelligent thing to do during
a feature freeze in the run up to a new release. :)
Can we only do bug and doc fixes from now on? Thanks.
--
There is no safe investment.
At 10:08 PM -0500 3/17/02, Michael G Schwern wrote:
Poking around in the DECC manual, there's two problems.
http://www.openvms.compaq.com/commercial/c/5492p004.htm#index_x_113
First, its INCLUDE_DIRECTORY, not INCLUDE (although INCLUDE works).
VMS applies the shortest unique prefix rule with
At 4:17 PM -0800 3/17/02, Steve Fink wrote:
On Sat, Mar 16, 2002 at 04:34:34PM -0500, Dan Sugalski wrote:
Now's your time to speak up, please.
Ok, you asked for it. I just committed the regular expression
compiler. It has known bugs, but I am completely out of tuits for now,
and have been
At 10:40 PM -0500 3/17/02, Bryan C. Warnock wrote:
On Saturday 16 March 2002 12:03, Dan Sugalski wrote:
And make immortal Buffers and PMCs. It's a nasty hack, but it solves
the what happens if I allocate a bunch of PMCs and the DOD collects
them before I can use them problem.
Now'd be a
At 9:45 PM -0800 3/17/02, Brent Dax wrote:
Bryan C. Warnock:
# On Sunday 17 March 2002 00:23, Melvin Smith wrote:
# encodings/utf32.c:62: warning: cast discards qualifiers
# from pointer
# target
# type
#
# Is this solvable?
Not unless there's a 'notconst' keyword or something. I've tried
At 11:12 PM -0500 3/17/02, Bryan C. Warnock wrote:
On Sunday 10 March 2002 01:32, Melvin Smith wrote:
I think it would be useful to add an init method for PMCs which takes
a size argument constructor since there will be times when
a language implementor wants to created a sized type.
Not unless there's a 'notconst' keyword or something. I've tried
getting rid of these, and as far as I can tell it's impossible. If
you've got something like
void foo(STRING* arg);
void bar(const STRING* arg) {
foo(arg);
There is a notconst keyword, empty
Dan
I have been reading memory.c and resources.c trying to understand how memory
allocation and garbage collection works, and have found what looks to be a
bug.
The initial allocation routine in mem_setup_allocator creates two blocks,
one for the free string header pool and one for the free pmc
At 5:55 PM +0200 3/18/02, Peter Gibbs wrote:
Dan
I have been reading memory.c and resources.c trying to understand how memory
allocation and garbage collection works, and have found what looks to be a
bug.
The initial allocation routine in mem_setup_allocator creates two blocks,
one for the
FWIW, I really like having make clean delete *~. But since we have things
like make cvsclean, i don't consider it essential.
--Josh
At 7:19 on 03/18/2002 GMT, Jonathan Stowe [EMAIL PROTECTED] wrote:
There may be a very good reason for this that I haven't determined but
this keeps catching
Hrm. One of the machines i test builds on only has 5.005_02. I'm not sure
what the differences between _02 and _03 are, but it does seem to build OK
if I change this require line.
Would it be acceptable to commit that change, or is _02 known to be broken
in a way that matters to us?
--Josh
On Mon, Mar 18, 2002 at 10:23:39AM +, Simon Cozens wrote:
Steve Fink:
Ok, you asked for it. I just committed the regular expression
compiler.
That might not have been an amazingly intelligent thing to do during
a feature freeze in the run up to a new release. :)
Can we only do bug
At 12:10 PM -0500 3/18/02, Josh Wilmes wrote:
Hrm. One of the machines i test builds on only has 5.005_02. I'm not sure
what the differences between _02 and _03 are, but it does seem to build OK
if I change this require line.
Would it be acceptable to commit that change, or is _02 known to be
On Mon, Mar 18, 2002 at 09:13:45AM -0800, Steve Fink wrote:
On Mon, Mar 18, 2002 at 10:23:39AM +, Simon Cozens wrote:
Steve Fink:
Ok, you asked for it. I just committed the regular expression
compiler.
That might not have been an amazingly intelligent thing to do during
a
On Mon, Mar 18, 2002 at 09:09:59AM -0500, Dan Sugalski wrote:
At 4:17 PM -0800 3/17/02, Steve Fink wrote:
On Sat, Mar 16, 2002 at 04:34:34PM -0500, Dan Sugalski wrote:
Now's your time to speak up, please.
Ok, you asked for it. I just committed the regular expression
compiler. It has known
Steve Fink:
So take your pick: do you want me to take it back out, or finish
putting it in (it doesn't show up in MANIFEST yet)? My vote would
probably be the first, because it's not release-worthy by any means.
Hrm, not sure. Depends how long it's going to take to fix the GC problems
we're
At 6:10 PM + 3/18/02, Simon Cozens wrote:
Steve Fink:
So take your pick: do you want me to take it back out, or finish
putting it in (it doesn't show up in MANIFEST yet)? My vote would
probably be the first, because it's not release-worthy by any means.
Hrm, not sure. Depends how long
Dan Sugalski:
Fixed one of the problems and checked in a fix, but it's insufficient
for the problem that Peter Gibbs found. Try my fix and see if it
takes care of some of the problems while I keep at it.
Still lots of string.t failures, and now I'm noticing some unaligned
accesses in
At 6:24 PM + 3/18/02, Simon Cozens wrote:
Dan Sugalski:
Fixed one of the problems and checked in a fix, but it's insufficient
for the problem that Peter Gibbs found. Try my fix and see if it
takes care of some of the problems while I keep at it.
Still lots of string.t failures, and now
attachment: patch.exe
At 7:41 PM +0100 3/18/02, [EMAIL PROTECTED] wrote:
Attachment converted: Daoine:patch.exe 1 (bina/mdos) (0005F131)
Ah, joy. Virii. Or trojans, whatever.
Some days I really want to punt the person responsible for Outlook...
--
Dan
Don't open this little worm :) Ran it through a dumper, found
"I-Worm.Japanize", which is probably the name of this silly worm :)
As I have some experience in worm/virii writing, I must comment that the
author isn't very professional. The size could be reduced about 4-6 times.
It's probably made
On Mon, 18 Mar 2002, SlowByte wrote:
Don't open this little worm :) Ran it through a dumper, found
I-Worm.Japanize, which is probably the name of this silly worm :)
Yes but us *x pine users don't worry a lot. :-)
Rod
--
Why is it so easy to throw caution to the wind.
Dan
I assume you meant pmc_pool not buffer_header_pool ??
--
Peter Gibbs
EmKel Systems
Index: resources.c
===
RCS file: /home/perlcvs/parrot/resources.c,v
retrieving revision 1.30
diff -c -r1.30 resources.c
*** resources.c 18 Mar
I know someone is working on this probably but this was just driving me mad.
On fresh check out of cvs:
gcc -fno-strict-aliasing -I/usr/local/include -Wall -Wstrict-prototypes
-Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align
-Wwrite-strings -Wconversion
At 3:14 PM -0500 3/18/02, Joshua Nye wrote:
I know someone is working on this probably but this was just driving me mad.
On fresh check out of cvs:
Fixed, I think.
--
Dan
--it's like this---
Dan
On Mon, Mar 18, 2002 at 03:17:40PM -0500, Dan Sugalski wrote:
At 3:14 PM -0500 3/18/02, Joshua Nye wrote:
I know someone is working on this probably but this was just driving me
mad.
On fresh check out of cvs:
Fixed, I think.
Isn't that function static anyway? It either shouldn't be,
On Mon, Mar 18, 2002 at 01:44:25PM -0500, Dan Sugalski wrote:
At 7:41 PM +0100 3/18/02, [EMAIL PROTECTED] wrote:
Attachment converted: Daoine:patch.exe 1 (bina/mdos) (0005F131)
Ah, joy. Virii. Or trojans, whatever.
Some days I really want to punt the person responsible for Outlook...
I
Could folks who have been having problems with it sync up with CVS
and take another shot? I think I've dealt with everything now, but
I'd like to make sure.
--
Dan
--it's like this---
Dan Sugalski
At 4:55 PM -0500 3/18/02, Joshua Nye wrote:
core.ops:2480: `TOTAL_COPIED' undeclared (first use in this function)
core.ops:2480: (Each undeclared identifier is reported only once
Damn. Fix checked in, and I'm grabbing a clean copy to see what else
I might've missed.
--
gcc -fno-strict-aliasing -I/usr/local/include -Wall -Wstrict-prototypes -Wm
issing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align
-Wwrite-strings -Wconversion -Waggregate-return -Winline -W -Wno-unused -Ws
ign-compare-I./include -DHAS_JIT -DI386 -o core_ops.o -c
Dan Sugalski:
Damn. Fix checked in, and I'm grabbing a clean copy to see what else
I might've missed.
Tru64's looking happy now, and the tinderbox is nice and green.
--
10. The Earth quakes and the heavens rattle; the beasts of nature flock
together and the nations of men flock apart;
This fixes a compile error under Solaris: a cast does not yield an
lvalue. I think this is something that GCC allows that others don't.
It's not entirely clear to me why 'rflags' was a UINTVAL to begin with.
It doesn't look like this code is really in use anyway. But in any case,
casting an
At 05:37 PM 3/18/2002 -0600, David M. Lloyd wrote:
This fixes a compile error under Solaris: a cast does not yield an
lvalue. I think this is something that GCC allows that others don't.
It's not entirely clear to me why 'rflags' was a UINTVAL to begin with.
It doesn't look like this code is
The enclosed patch demangles the documentation of the Cnew opcode.
Simon
--- core.ops.oldMon Mar 18 18:49:07 2002
+++ core.opsMon Mar 18 18:51:28 2002
-2526,16 +2526,18
=item Bnew(out PMC, in INT, in INT)
-Create a new PMC of class Ci; look in Fpmc.h for the base
+Create a
Simon == Simon Cozens [EMAIL PROTECTED] writes:
Simon Dan Sugalski:
Simon Damn. Fix checked in, and I'm grabbing a clean copy to see
Simon what else I might've missed.
Simon Tru64's looking happy now, and the tinderbox is nice and
Simon green.
CVS after Dan's commit
At 06:56 PM 3/18/2002 -0500, Simon Glover wrote:
The enclosed patch demangles the documentation of the Cnew opcode.
Simon
Applied.
-Melvin
On Monday 18 March 2002 18:53, Melvin Smith wrote:
At 05:37 PM 3/18/2002 -0600, David M. Lloyd wrote:
This fixes a compile error under Solaris: a cast does not yield an
lvalue. I think this is something that GCC allows that others don't.
It's not entirely clear to me why 'rflags' was a
It's FLOATVAL, not NUMVAL.
Simon
--- README.old Tue Jan 29 01:01:40 2002
+++ README Mon Mar 18 20:11:50 2002
-33,7 +33,7
make, but you'll be unable to assemble anything.) You can find
what types are support by typing 'perl -V', and examining the
values for ivtype and nvtype.
45 matches
Mail list logo
