On Mon, 18 Mar 2002, Jim Cromie wrote:
> Rich Morin wrote:
>
> > At 11:24 PM -0500 3/6/02, Uri Guttman wrote:
> >
> >> qn would be just like qq but not allow any
> >> direct hash interpolations (%foo or %foo{bar}). you can always get those
> >> with $() if needed. this solves the common c
Rich Morin wrote:
> At 11:24 PM -0500 3/6/02, Uri Guttman wrote:
>
>> qn would be just like qq but not allow any
>> direct hash interpolations (%foo or %foo{bar}). you can always get those
>> with $() if needed. this solves the common case with a minimal of noise
>> and the uncommon case h
Charles Bunders writes:
: I came across Simon Cozens email
: (http:[EMAIL PROTECTED]/msg08641.html) again
: tonight and it got me thinking...
:
: In Perl 6 are modules compiled down to pbc (Perl byte code) going to also
: create metadata similar to what .NET has describing methods, use, etc.
We
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.
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'
At 06:56 PM 3/18/2002 -0500, Simon Glover wrote:
> The enclosed patch demangles the documentation of the C opcode.
>
> Simon
Applied.
-Melvin
> "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 aft
The enclosed patch demangles the documentation of the C opcode.
Simon
--- core.ops.oldMon Mar 18 18:49:07 2002
+++ core.opsMon Mar 18 18:51:28 2002
@@ -2526,16 +2526,18 @@
=item B(out PMC, in INT, in INT)
-Create a new PMC of class C; look in F for the base
+Create a new PMC of
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
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 l
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; volc
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 core_
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.
--
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
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 Outlo
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 shoul
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 S
At 10:08 PM +0200 3/18/02, Peter Gibbs wrote:
>
>Dan
>
>I assume you meant pmc_pool not buffer_header_pool ??
D'oh! Yes, you're right. Now life.pasm doesn't fail if you throw a
new P1, PerlInt in the end somewhere.
--
Dan
---
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 -Waggreg
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 2
Dan Sugalski:
# 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
#
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.
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 i
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
<>
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,
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 stac
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 h
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
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. I
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 dur
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
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 on
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
A
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 catchi
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
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
>>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
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.
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'v
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.
>>
>>
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 bee
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
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
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
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)
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 t
--- 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, se
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 @@
I probably did something like this before, ho hum. 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, but its
either that or remove the const qualifier from the first argument to
..*_skip_(for|back)
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
51 matches
Mail list logo
