Cola compiler 0.0.1

[Melvin Smith]

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 ok on Linux x86
and Solaris 8 Sparc.

Tested with gcc, Flex and Bison and of course Perl5.

After Simon releases 0.0.4 I'll check this into parrot/languages

I wanted to get this out so people could play with it before I
did a redesign and rewrite.

-Melvin


cola-0.0.1.tar.gz
Description: Binary data

[PATCH] Fix last warnings in encodings stuff

[Jonathan Stowe]

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)ward ...

--- include/parrot/encoding.h~  Mon Mar 18 07:26:24 2002
+++ include/parrot/encoding.h   Mon Mar 18 07:27:10 2002
@@ -28,8 +28,8 @@
  Parrot_UInt(*characters) (const void *ptr, Parrot_UInt bytes);
  Parrot_UInt(*decode) (const void *ptr);
 void *(*encode) (void *ptr, Parrot_UInt c);
-void *(*skip_forward) (const void *ptr, Parrot_UInt n);
-void *(*skip_backward) (const void *ptr, Parrot_UInt n);
+const void *(*skip_forward) (const void *ptr, Parrot_UInt n);
+const void *(*skip_backward) (const void *ptr, Parrot_UInt n);
 };

 #define Parrot_Encoding struct parrot_encoding_t *
--- encodings/singlebyte.c~ Mon Mar 18 07:22:08 2002
+++ encodings/singlebyte.c  Mon Mar 18 07:24:34 2002
@@ -43,18 +43,18 @@
 return bptr + 1;
 }

-static void *
+static const void *
 singlebyte_skip_forward(const void *ptr, UINTVAL n)
 {
-byte_t *bptr = (byte_t *)ptr;
+const byte_t *bptr = (const byte_t *)ptr;

 return bptr + n;
 }

-static void *
+static const void *
 singlebyte_skip_backward(const void *ptr, UINTVAL n)
 {
-byte_t *bptr = (byte_t *)ptr;
+const byte_t *bptr = (const byte_t *)ptr;

 return bptr - n;
 }
--- encodings/utf16.c~  Mon Mar 18 07:22:08 2002
+++ encodings/utf16.c   Mon Mar 18 07:33:10 2002
@@ -81,10 +81,10 @@
 return u16ptr;
 }

-static void *
+static const void *
 utf16_skip_forward(const void *ptr, UINTVAL n)
 {
-utf16_t *u16ptr = (utf16_t *)ptr;
+const utf16_t *u16ptr = (const utf16_t *)ptr;

 while (n-- > 0) {
 if (UNICODE_IS_HIGH_SURROGATE(*u16ptr)) {
@@ -106,10 +106,10 @@
 return u16ptr;
 }

-static void *
+static const void *
 utf16_skip_backward(const void *ptr, UINTVAL n)
 {
-utf16_t *u16ptr = (utf16_t *)ptr;
+const utf16_t *u16ptr = (const utf16_t *)ptr;

 while (n-- > 0) {
 u16ptr--;
--- encodings/utf32.c~  Mon Mar 18 07:22:08 2002
+++ encodings/utf32.c   Mon Mar 18 07:34:07 2002
@@ -48,18 +48,18 @@
 return u32ptr + 1;
 }

-static void *
+static const void *
 utf32_skip_forward(const void *ptr, UINTVAL n)
 {
-utf32_t *u32ptr = (utf32_t *)ptr;
+const utf32_t *u32ptr = (const utf32_t *)ptr;

 return u32ptr + n;
 }

-static void *
+static const void *
 utf32_skip_backward(const void *ptr, UINTVAL n)
 {
-utf32_t *u32ptr = (utf32_t *)ptr;
+const utf32_t *u32ptr = (const utf32_t *)ptr;

 return u32ptr - n;
 }
--- encodings/utf8.c~   Mon Mar 18 07:22:08 2002
+++ encodings/utf8.cMon Mar 18 07:31:34 2002
@@ -107,10 +107,10 @@
 return u8ptr + len;
 }

-static void *
+static const void *
 utf8_skip_forward(const void *ptr, UINTVAL n)
 {
-utf8_t *u8ptr = (utf8_t *)ptr;
+const utf8_t *u8ptr = (const utf8_t *)ptr;

 while (n-- > 0) {
 u8ptr += UTF8SKIP(u8ptr);
@@ -119,10 +119,10 @@
 return u8ptr;
 }

-static void *
+static const void *
 utf8_skip_backward(const void *ptr, UINTVAL n)
 {
-utf8_t *u8ptr = (utf8_t *)ptr;
+const utf8_t *u8ptr = (const utf8_t *)ptr;

 while (n-- > 0) {
 u8ptr--;
--- string.c~   Mon Mar 18 07:40:41 2002
+++ string.cMon Mar 18 07:47:16 2002
@@ -172,8 +172,8 @@
 STRING *dest;
 CHARTYPE_TRANSCODER transcoder1 = (CHARTYPE_TRANSCODER)NULLfunc;
 CHARTYPE_TRANSCODER transcoder2 = (CHARTYPE_TRANSCODER)NULLfunc;
-char *srcstart;
-char *srcend;
+const char *srcstart;
+const char *srcend;
 char *deststart;
 char *destend;

@@ -365,11 +365,11 @@
 true_length = (UINTVAL)(src->strlen - true_offset);
 }

-substart_off = (char *)src->encoding->skip_forward(src->bufstart,
+substart_off = (const char *)src->encoding->skip_forward(src->bufstart,
true_offset) -
 (char *)src->bufstart;
 subend_off =
-(char *)src->encoding->skip_forward((char *)src->bufstart +
+(const char *)src->encoding->skip_forward((char *)src->bufstart +
 substart_off,
 true_length) -
 (char *)src->bufstart;
@@ -400,8 +400,8 @@
 STRING *
 string_chopn(STRING *s, INTVAL n)
 {
-char *bufstart = s->bufstart;
-char *bufend = bufstart + s->bufused;
+const char *bufstart = s->bufstart;
+const char *bufend = bufstart + s->bufused;
 UINTVAL true_n;

 true_n = (UINTVAL)n;
@@ -427,10 +427,10 @@
 string_compare(struct Parrot_Interp *interpreter, const STRING *s1,
const STRING *s2)
 {
-char *s1start;
-char *s1end;
-char *s2start;
-char *s2end;
+const char *s1start;
+const char *s1end;
+const char *s2start;
+const char *s2end;
 INTVAL cmp = 0;

 

[PATCH] Makefile.in 'make clean' should preserve backups

[Jonathan Stowe]

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 @@
$(RM_F) examples/assembly/mops$(O) examples/assembly/mops.pbc
$(RM_F) examples/mops/mops$(O) examples/mops/mops${exe}
$(RM_RF) blib
-   $(RM_F) *~
cd docs && $(MAKE) clean && cd ..
cd classes && $(MAKE) clean && cd ..
cd languages && $(MAKE) clean && cd ..
@@ -434,6 +433,7 @@
$(RM_F) t/op/*.pasm t/op/*.pbc t/op/*.out

 realclean: clean
+   $(RM_F) *~
$(RM_F) $(STICKY_FILES)

 distclean:



/J\
-- 
Jonathan Stowe  |
  |  This space for rent
|

[PATCH] Warning in packfile.c

[Jonathan Stowe]

--- 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, segment_size, sizeof(opcode_t));
+debug, segment_size, (long)sizeof(opcode_t));
 return 0;
 }
 return 1;

/J\
-- 
Jonathan Stowe  |
  |  This space for rent
|

Re: [PATCH] Fix last warnings in encodings stuff

[Jonathan Stowe]

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 compilers place to be
deciding whether its a bad thing and it doesn't seem to think so :)"

/J\
-- 
Jonathan Stowe  |
  |  This space for rent
|

Win2000 MSVC version 6 OK

[Joe Yates]

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)

[Not OK] SCO_SV pigment 3.2 5.0.5 i386

[Jonathan Stowe]

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 to make sure you have a complete Parrot kit...

Okay, we found everything.  Next you'll need to answer
a few questions about your system.  Defaults are in square
brackets, and you can hit enter to accept them.  If you
don't want the default, type a new value in.  If that new
value starts with a '+', it will be concatenated to the
default value.

What C compiler do you want to use? [cc]
How about your linker? [ld]
What flags would you like passed to your C compiler? [-U M_XENIX -D
PERL_SCO -D
PERL_SCO5 -w0 -belf]
What flags would you like passed to your linker? [ -L/usr/local/lib]
Which libraries would you like your C compiler to include? [-lintl
-lsocket -lns
l -lndbm -ldbm -lld -lm -lc -lcrypt -lPW -lx]
How big would you like integers to be? [long]
And your floats? [double]
What is your native opcode type? [long]

Now I have to find out what opcode files you would like to compile into
your
Parrot.

The following opcode files are available:
core.ops io.ops obscure.ops rx.ops

WARNING: Bad Things may happen if the first file on the list isn't
core.ops.

WARNING: These file names will not be checked for spelling, and typing
them
 wrong will force you to run Configure again.

WARNING: I worry way too much about Configure users.

Which opcode files would you like? [core.ops io.ops rx.ops]

Determining if your C compiler is actually gcc (this could take a while):

Odd number of elements in hash assignment at ./Configure.pl line 360,
 ch
unk 9.
Use of uninitialized value at ./Configure.pl line 360,  chunk 9.

The test program didn't give the expected result - assuming your compiler
is
not gcc.


Probing Perl 5's configuration to determine which headers you have (this
could
take a while on slow machines)...

Determining C data type sizes by compiling and running a small C program
(this
could take a while):

  Building ./test.c   from test_c.in...
Odd number of elements in hash assignment at ./Configure.pl line 505.
Use of uninitialized value at ./Configure.pl line 505.
Use of uninitialized value at ./Configure.pl line 513.
Use of uninitialized value at ./Configure.pl line 513.
Use of uninitialized value at ./Configure.pl line 542.
Use of uninitialized value at ./Configure.pl line 545.
Use of uninitialized value at ./Configure.pl line 545.
Configure.pl:  Unable to find a suitable packtype for intvalsize.


I'll take a poke at it - this should be considered FYI rather than
something that should stop 0.04 ;-}

/J\
-- 
Jonathan Stowe  |
  |  This space for rent
|

Re: Anyone using the current regex ops?

[Simon Cozens]

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. To love at all is to be vulnerable. ... 
The only place outside Heaven where you can be perfectly safe from all the
dangers and pertubations of love is Hell."
 -CS Lewis "The Four Loves"

Re: [PATCH Configure.pl] (still broken) Re: OpenVMS can't getpast configure

[Dan Sugalski]

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 commands and 
switches. I think /inc would work too, but that's probably a bit too 
short for comfort.

>Second, there seems to be some confusing rules about mixing VMS and
>Unix style paths.  It seems that the style used in INCLUDE_DIRECTORY
>has to match the style used in the #include. 
>
>so this works:
>
> CC/DECC /INCLUDE=("./include") testparrotsizes.c
>
>but you might want to get independent confirmation from the vmsperl
>folks about that.

That's new. Older versions of the Dec C compiler didn't do that--the 
bit before the / was considered either a logical name or ignored. So 
you'd need a PARROT: logical to make it work. If the ./include scheme 
is OK, we'll go with that and require folks to have reasonably modern 
versions of Dec C. Given our rollout schedule, I don't consider that 
excessive.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Anyone using the current regex ops?

[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 tuits for now,
>and have been since about the time I announced this thing's existence.
>:-(

Fair enough--that's what I wanted to know.

>I do wonder what you'd replace the rx opcodes with. I don't see any
>use for some of the existing opcodes (regex flag setting, zwa_atend,
>etc.), but doing things like maintaining the backtracking stack using
>generic opcodes sounds very slow to me.

Maybe. I don't think so, though, and if some specialized constructs 
are needed, I think they need to be brought outside the context of 
the regex engine.

>The last benchmarking I did on the regex engine (with a single regex,
>admittedly) put it at somewhat better than half the speed of perl5's
>engine, which isn't too bad. Do you have newer (worse) numbers?

Half the speed is pretty abominable. However, code using the regex 
opcodes to match /fo+ba?r/ runs at the same speed or slower than code 
using plain positional ords, and the positional ord code sees 
significant gains when using the JIT. Neither version came within 
half the speed of perl, though. Both were slower than that.

>My compiler would be relatively easy to retarget to general opcodes or
>another set of regex opcodes, but I am very skeptical that regexen can
>be sufficiently fast without some tailored opcodes and a regex state
>PMC.

Possibly. Regardless, at the moment I'm thinking that the current 
shot at regexes is, while good, insufficiently compelling over the 
plain opcodes we have now.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: I'm about to do something really evil

[Dan Sugalski]

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 good time to object if you've a better option. :)
>
>Immortal sounds a little scary.  What are you *really* doing?

Trying to solve the "How can I allocate things without the GC yanking 
them out from under me" problem. Incorrectly, I might add. (The 
solution, not the yanking)
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

RE: Solaris8 32bit GCC3.0.3 on 64bit Ultra10 OK but...

[Dan Sugalski]

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
>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);
>   }
>
>it warns--but it does the same if you do:
>
>   foo((STRING*)arg);
>
>I'd suggest that this be deactivated--I can't see any good coming from
>it.

Actually I'd go with plan B: We don't do that. If we're telling the 
compiler that a parameter to one of our functions is constant, we 
shouldn't then go and change it, even indirectly. Lying to the 
compiler is a Bad Thing--it messes up optimizations. (And if the 
compiler trusts the const-ness of things, potentially fatally)

Either parameters are const and we don't change them, or they're not 
declared const.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: pmc_init

[Dan Sugalski]

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.
>>
>>  Right now init takes no arguments.
>>
>>  It will definitely be important for C style languages where most things
>>  are structs, classes or static arrays.
>>
>>  I personally think that it should take this argument by
>>  default rather than being overloaded (all in interest of less bloat, I'd
>>  rather just modify the existing init).
>>
>>  Any objections?
>
>On a side note, did anyone read the "Is Java's 'new' harmful?" article in
>DDJ?

Just finished it. Odd little article--I'm not sure I see the 
problems, and the author seemed kind of confused. (Like at the 
beginning he says that there aren't any languages that separate 
allocation and initialization, then later complains about the 
problems you get when smalltalk does exactly that) I couldn't tell 
whether the problems were considered inherent in new, or just due to 
a screwup with Java's particular style of it.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

RE: Solaris8 32bit GCC3.0.3 on 64bit Ultra10 OK but...

[Melvin Smith]

>>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 string. ;)

const says, "if you so choose you may stick this into
a protected segment or ROM". If it was ROM on an
embedded, you might not even crash, but simply fail
to modify the variable.

-Melvin

GC discarding free pmc pool?

[Peter Gibbs]

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 header pool.
However, Parrot_go_collect copies only the free string header pool to the
newly allocated block (followed by the compacted strings), then proceeds to
free the entire memory pool - what happens to the free pmc header pool??

I have done a simple test by adding a " new P1, PerlInt" to life.pasm in the
middle of the stats output lines, and on my linux x86 system this gives a
segfault, which seems to confirm that something has gone awry somewhere.

--
Peter Gibbs
EmKel Systems

Re: GC discarding free pmc pool?

[Dan Sugalski]

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 free string header pool and one for the free pmc header pool.
>However, Parrot_go_collect copies only the free string header pool to the
>newly allocated block (followed by the compacted strings), then proceeds to
>free the entire memory pool - what happens to the free pmc header pool??

D'oh! thanks for the catch. I'll go fix.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: [PATCH] Makefile.in 'make clean' should preserve backups

[Josh Wilmes]

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 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 @@
>   $(RM_F) examples/assembly/mops$(O) examples/assembly/mops.pbc
>   $(RM_F) examples/mops/mops$(O) examples/mops/mops${exe}
>   $(RM_RF) blib
> - $(RM_F) *~
>   cd docs && $(MAKE) clean && cd ..
>   cd classes && $(MAKE) clean && cd ..
>   cd languages && $(MAKE) clean && cd ..
> @@ -434,6 +433,7 @@
>   $(RM_F) t/op/*.pasm t/op/*.pbc t/op/*.out
> 
>  realclean: clean
> + $(RM_F) *~
>   $(RM_F) $(STICKY_FILES)
> 
>  distclean:
> 
> 
> 
> /J\
> -- 
> Jonathan Stowe  |
>   |  This space for rent
> |

Re: [PATCH] 5.005_03 (was Re: New assembler ready for tasting)

[Josh Wilmes]

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

At 11:11 on 03/16/2002 EST, Josh Wilmes <[EMAIL PROTECTED]> wrote:

> applied.
> 
> At 16:01 on 03/16/2002 GMT, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> 
> > On Fri, Mar 15, 2002 at 06:10:11PM -0500, Simon Glover wrote:
> > >  With a proper fresh checkout, everything builds OK here, but I've run
> > >  into another problem:  Parrot::Assembler:Utils uses Text::Balanced, but
> > >  that's not a core module in 5.6.x and earlier. Weren't we trying to
> > >  stay compatible with Perl's back to 5.5.3 ?
> > 
> > Can I suggest the appended, which stops silly people (such as me) running
> > Configure with /usr/local/bin/perl (which is 5.004_05) and not
> > realising their mistake until the pmc subdirectory, where the first qr//
> > is encountered.
> > 
> > Syntax error messages don't tell you what you did wrong. This does:
> > 
> > /usr/local/bin/perl Configure.pl
> > Perl 5.00503 required--this is only version 5.00405, stopped at Configure.p
l 
> line 10.
> > 
> > 
> > Nicholas Clark
> > -- 
> > Even better than the real thing:http://nms-cgi.sourceforge.net/
> > 
> > --- Configure.pl.orig   Tue Mar  5 22:33:47 2002
> > +++ Configure.plSat Mar 16 11:43:43 2002
> > @@ -7,6 +7,8 @@
> >  # Author: Brent Dax
> >  #
> >  
> > +require 5.005_03;
> > +
> >  use strict;
> >  use lib 'lib';
> >  
> 

Re: Anyone using the current regex ops?

[Steve Fink]

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 and doc fixes from now on? Thanks.

Sorry. I didn't think of the languages/ subdirectory as part of the
release, but I suppose it's part of the tarball.

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.

Re: [PATCH] 5.005_03 (was Re: New assembler ready for tasting)

[Dan Sugalski]

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 broken
>in a way that matters to us?

_03 was just a bugfix from _02, IIRC. I don't see a problem with 
changing the require line.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Anyone using the current regex ops?

[Steve Fink]

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 feature freeze in the run up to a new release. :)
> > 
> > Can we only do bug and doc fixes from now on? Thanks.
> 
> Sorry. I didn't think of the languages/ subdirectory as part of the
> release, but I suppose it's part of the tarball.
> 
> 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.

Never mind. I removed it all. Sorry about that.

(The directories, of course, are still there. But then, I added those
a few weeks ago anyway. They'll go away with update -P.)

Re: Anyone using the current regex ops?

[Steve Fink]

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 bugs, but I am completely out of tuits for now,
> >and have been since about the time I announced this thing's existence.
> >:-(
> 
> Fair enough--that's what I wanted to know.

I'm not really enough of a user to merit keeping it in for my sake.
Anyone else?

> >I do wonder what you'd replace the rx opcodes with. I don't see any
> >use for some of the existing opcodes (regex flag setting, zwa_atend,
> >etc.), but doing things like maintaining the backtracking stack using
> >generic opcodes sounds very slow to me.
> 
> Maybe. I don't think so, though, and if some specialized constructs 
> are needed, I think they need to be brought outside the context of 
> the regex engine.

I can certainly agree with this. I don't think there's anything that's
inherently specific to regular expressions, although there may be some
opcodes that would never really end up being used by anything else.
(Though regular expression code now kind of includes parsing code, so
that's a lot.)

> >The last benchmarking I did on the regex engine (with a single regex,
> >admittedly) put it at somewhat better than half the speed of perl5's
> >engine, which isn't too bad. Do you have newer (worse) numbers?
> 
> Half the speed is pretty abominable. However, code using the regex 
> opcodes to match /fo+ba?r/ runs at the same speed or slower than code 
> using plain positional ords, and the positional ord code sees 
> significant gains when using the JIT. Neither version came within 
> half the speed of perl, though. Both were slower than that.

Probably because you didn't cheat. :-) I was benchmarking my code
against Brent's and winning, so I wrote to him for help, and disabling
a forced canonicalization to UTF-32 reversed the situation. And that's
probably a fairer comparison to perl5.

> >My compiler would be relatively easy to retarget to general opcodes or
> >another set of regex opcodes, but I am very skeptical that regexen can
> >be sufficiently fast without some tailored opcodes and a regex state
> >PMC.
> 
> Possibly. Regardless, at the moment I'm thinking that the current 
> shot at regexes is, while good, insufficiently compelling over the 
> plain opcodes we have now.
> -- 

So what's the best way of ensuring that we can easily compare the
speeds of the two? We could move the rx .ops files and supporting .c
and .h files into somewhere in languages/regex, though right now it's
kind of a pain to have .ops files outside of the root directory.

Re: Anyone using the current regex ops?

[Simon Cozens]

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 seeing on Alpha. Dan, how're you getting on with those?

Simon

-- 
 heh, yeah, but Aretha could be reading out /etc/services and
kick just so much ass :)

Re: Anyone using the current regex ops?

[Dan Sugalski]

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 it's going to take to fix the GC problems
>we're seeing on Alpha. Dan, how're you getting on with those?

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.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Anyone using the current regex ops?

[Simon Cozens]

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 stacks.t and perlstring.t.

t/op/hacks.t  1   256 11 100.00%  1
t/op/rx.t??   ??   %  ??
t/op/stacks.t 2   512152  13.33%  2 13
t/op/string.t22  563264   22  34.38%  6 17-20 22-24 27-29 31-33 35-
  37 39-41 62-63
t/op/trans.t  2   512182  11.11%  13 18
t/pmc/perlstring.t4  1024 84  50.00%  1-3 8
t/pmc/pmc.t   5  1280565   8.93%  32 34 44-45 48

-- 
"If that makes any sense to you, you have a big problem."
-- C. Durance, Computer Science 234

Re: Anyone using the current regex ops?

[Dan Sugalski]

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 I'm noticing some unaligned
>accesses in stacks.t and perlstring.t.

I made it worse. Grand... :(
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Important

[daniel . ritz]

<>

Re: Important

[Dan Sugalski]

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

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Important

[SlowByte]

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 in Delphi, and you don't writes serious code in that. It
uses some tricks for e-mail addr. extracting and sending, but nothing
special.

*grin*

-Jaen

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 18, 2002 8:41 PM
Subject: Important


>
>

Re: Important

[raanders]

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.
Shouldn't it be heavier and shaped like an anvil?

   Jon Anderson

RE: Anyone using the current regex ops?

[Brent Dax]

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
# tuits for now,
# >and have been since about the time I announced this thing's
# existence.
# >:-(
#
# Fair enough--that's what I wanted to know.
#
# >I do wonder what you'd replace the rx opcodes with. I don't see any
# >use for some of the existing opcodes (regex flag setting, zwa_atend,
# >etc.), but doing things like maintaining the backtracking stack using
# >generic opcodes sounds very slow to me.
#
# Maybe. I don't think so, though, and if some specialized constructs
# are needed, I think they need to be brought outside the context of
# the regex engine.
#
# >The last benchmarking I did on the regex engine (with a single regex,
# >admittedly) put it at somewhat better than half the speed of perl5's
# >engine, which isn't too bad. Do you have newer (worse) numbers?
#
# Half the speed is pretty abominable. However, code using the regex
# opcodes to match /fo+ba?r/ runs at the same speed or slower than code
# using plain positional ords, and the positional ord code sees
# significant gains when using the JIT. Neither version came within
# half the speed of perl, though. Both were slower than that.

On the other hand, we never did test it with stack operations, probably
because most realistic test cases that need them use character classes.

Also, I'm fairly certain that by using a vtable, I can put in some evil
speed hacks.  (For example, "OK, this string is Unicode.  We'll use the
Unicode vtable, which'll transcode to utf32 and reach inside the
string's guts for speed.")

# >My compiler would be relatively easy to retarget to general
# opcodes or
# >another set of regex opcodes, but I am very skeptical that
# regexen can
# >be sufficiently fast without some tailored opcodes and a regex state
# >PMC.
#
# Possibly. Regardless, at the moment I'm thinking that the current
# shot at regexes is, while good, insufficiently compelling over the
# plain opcodes we have now.

There are probably some significant idiotic moves in terms of speed in
that code.  If anybody can give me C profiling data I'd much appreciate
it--free tools for that don't appear to exist on Windows.

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

#define private public
--Spotted in a C++ program just before a #include

Re: Anyone using the current regex ops?

[Peter Gibbs]

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 2002 16:42:06 -  1.30
--- resources.c 18 Mar 2002 19:21:21 -
***
*** 702,711 

/* Collect the PMC header pool */
memcpy(cur_spot,
!interpreter->arena_base->buffer_header_pool->pool_buffer.bufstart,
!interpreter->arena_base->buffer_header_pool->pool_buffer.buflen);
!   interpreter->arena_base->buffer_header_pool->pool_buffer.bufstart =
cur_spot
;
!   cur_size =
interpreter->arena_base->buffer_header_pool->pool_buffer.buflen;
if (cur_size & 0x0f) {
  cur_size &= ~0x0f;
  cur_size += 16;
--- 702,711 

/* Collect the PMC header pool */
memcpy(cur_spot,
!interpreter->arena_base->pmc_pool->pool_buffer.bufstart,
!interpreter->arena_base->pmc_pool->pool_buffer.buflen);
!   interpreter->arena_base->pmc_pool->pool_buffer.bufstart = cur_spot;
!   cur_size = interpreter->arena_base->pmc_pool->pool_buffer.buflen;
if (cur_size & 0x0f) {
  cur_size &= ~0x0f;
  cur_size += 16;

[patch] mismatched prototype

[Joshua Nye]

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 -Waggregate-return -Winline -W -Wno-unused -Wsign-compare 
   -I./include  -DHAS_JIT -DI386 -o resources.o -c resources.c
resources.c:336: conflicting types for `mark_used'
include/parrot/resources.h:29: previous declaration of `mark_used'
make: *** [resources.o] Error 1


diff -u -r1.23 resources.h
--- include/parrot/resources.h  16 Mar 2002 17:38:53 -  1.23
+++ include/parrot/resources.h  18 Mar 2002 20:12:08 -
@@ -26,7 +26,7 @@
 void *new_bigint_header(struct Parrot_Interp *);
 void free_bigint(void);
 
-PMC *mark_used(struct Parrot_Interp *, PMC *, PMC *);
+PMC *mark_used(PMC *, PMC *);
 
 void Parrot_block_DOD(struct Parrot_Interp *);
 void Parrot_block_GC(struct Parrot_Interp *);

Re: Anyone using the current regex ops?

[Dan Sugalski]

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

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: [patch] mismatched prototype

[Dan Sugalski]

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 Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: [patch] mismatched prototype

[Steve Fink]

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, or there
shouldn't be a prototype in the .h file.

Re: Important

[Nicholas Clark]

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 wrote the spec for the solution ages ago, but no-one yet seems to have
implemented it:

http://www.ccl4.org/~nick/ahfw

(so long ago that it was still called "New Technogy")

Nicholas Clark
-- 
Even better than the real thing:http://nms-cgi.sourceforge.net/

I think GC's fixed now

[Dan Sugalski]

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  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: I think GC's fixed now

[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.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: I think GC's fixed now

[Joshua Nye]

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_ops.c
core.ops: In function `Parrot_interpinfo_i_i':
core.ops:2480: `TOTAL_COPIED' undeclared (first use in this function)
core.ops:2480: (Each undeclared identifier is reported only once
core.ops:2480: for each function it appears in.)
core.ops: In function `Parrot_interpinfo_i_ic':
core.ops:2480: `TOTAL_COPIED' undeclared (first use in this function)
make: *** [core_ops.o] Error 1

- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 18, 2002 4:47 PM
Subject: I think GC's fixed now


> 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  even samurai
> [EMAIL PROTECTED] have teddy bears and even
>teddy bears get drunk
>

Re: I think GC's fixed now

[Simon Cozens]

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; volcanoes usher up heat
while elsewhere water becomes ice and melts; and then on other days it
just rains. - Prin. Dis.

[PATCH] Fix compile problem under Solaris

[David M. Lloyd]

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 lvalue is probably not a good idea here.

Index: io_unix.c
===
RCS file: /home/perlcvs/parrot/io/io_unix.c,v
retrieving revision 1.15
diff -u -r1.15 io_unix.c
--- io_unix.c   17 Mar 2002 05:07:31 -  1.15
+++ io_unix.c   18 Mar 2002 23:35:02 -
@@ -193,7 +193,7 @@
 ParrotIO *io;
 UINTVAL oflags, mode;
 #ifdef HAS_HEADER_FCNTL
-UINTVAL rflags;
+INTVAL rflags;
 #endif
 mode = 0;

@@ -203,7 +203,7 @@
 /* FIXME - Check file handle flags, validity */
 #ifdef HAS_HEADER_FCNTL
 /* Get descriptor flags */
-if (((INTVAL)rflags = fcntl(fd, F_GETFL, 0)) >= 0) {
+if ((rflags = fcntl(fd, F_GETFL, 0)) >= 0) {
 /*int accmode = rflags & O_ACCMODE; */
 /* Check other flags (APPEND, ASYNC, etc) */
 }


- D

<[EMAIL PROTECTED]>

Re: [PATCH] Fix compile problem under Solaris

[Melvin Smith]

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 really in use anyway.  But in any case,
>casting an lvalue is probably not a good idea here.

Thats a typo on my part. The cast was meant to be outside
the assignment.

The reason it was UINTVAL is just a matter of taste for
flag values, however one is as good as another here.

Applied.

-Melvin

[PATCH] Core.ops documentation fix-up

[Simon Glover]

 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 class $2; look in F for the base
 vtable types. The assembler allows you to specify PMCs by type
 name as well as by integer - you should do this for compatibility,
 to avoid problems if the base types get reassigned. For example:

+new P0, PerlScalar
+
 Optionally a size may be passed to the constructor which may or
-may not be used by the particular class.
+may not be used by the particular class. For example:

-new P0, PerlScalar
 new P0, PerlStruct, 64
+
 =cut

 op new(out PMC, in INT) {

Re: I think GC's fixed now

[Chris Ball]

> "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 compiles and tests fine under Alpha / Linux
2.4.16 / egcs-2.91.66 / libc-2.1.3 / perl 5.6.0:

All tests successful, 20 subtests skipped.

Standard useless compile warnings on different widths due to prototypes.

Congrats to Dan on the fix,
  
- Chris.

(I posted a day or two ago saying that Alpha died, when it was already
known to die, and I did so from a mail address that isn't the one I
subscribe from.  Please ignore that mail when it's moderated through.)
-- 
$a="printf.net"; Chris Ball | chris@void.$a | www.$a | finger: chris@$a
 "In the beginning there was nothing, which exploded."

Re: [PATCH] Core.ops documentation fix-up

[Melvin Smith]

At 06:56 PM 3/18/2002 -0500, Simon Glover wrote:

>  The enclosed patch demangles the documentation of the C opcode.
>
>  Simon

Applied.

-Melvin

Re: [PATCH] Fix compile problem under Solaris

[Bryan C. Warnock]

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 UINTVAL to begin with.
> >It doesn't look like this code is really in use anyway.  But in any case,
> >casting an lvalue is probably not a good idea here.
> 
> Thats a typo on my part. The cast was meant to be outside
> the assignment.
> 
> The reason it was UINTVAL is just a matter of taste for
> flag values, however one is as good as another here.

and both will be going away.

(I hope that 0.0.4 and my schedule sync up the way I need it to.)-:

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

[PATCH] Trivial README fix

[Simon Glover]

 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.  Parrot should work with INTVALs
-and NUMVALs up to those types.
+and FLOATVALs up to those types.

 For most of the platforms that we are supporting initially,
 Parrot should build out of the box.  We do not have,

Re: Metadata

[Larry Wall]

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 have to do that if we want to run well on top of .NET.

: I don't think it would be that dificult to do and you could do some interesting
: things with the development environments on the various platforms with it as
: well.
: 
: Just curious if you plan on keeping with the POD documentation in the source or
: had some magic mojo you would be throwing in either with the pbc or files that
: go with it?

Hasn't been designed yet.  POD streams will certainly have to be
accessible, but so will various kinds of metadata derived from Perl
declarations.  So it's unlikely to be an either/or thing.

Larry

Re: rethinking printf

[Jim Cromie]

  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 has a simple out of using $(). no need for wacko
>> ways to put in \n. it is double quotish in all ways but one and mainly
>> to be used for printf format strings.
>
>
> I also like this because it allows a typical format string to be 
> converted
> merely by adding a two-character prefix:
>
> printf("The value is %7.2f\n", $foo);
> ---
> printf(qn"The value is %7.2f\n", $foo);
>
> -r

if qf() is defensible, it should pass some generality tests;

1. make it 'replace' printf
print qf'%s %d', $somestring, $someint;

2. make it 'replace' sprintf.
$res = qf('%s %d %d', $somestr, $anint)

3. detect the silent error above - insufficient args.
this quote-like operator is now a list-op, and a smart one.

4. make it know whether %s means hash interpolation or printf-format-spec

a. ive seen perl5 warn about escaping @ when printing undefined / undeclared
@array (cant seem to replicate now :-/ )

b. the universe of printf format specs is pretty small, it really only 
interferes
with (the expansion of: @{[ each %s ]} ) a few single letter hashes %s, 
%d, etc..

c. item b implies a run-time check to see that no %s, %d, are hidden by 
a format-spec
interpretation, but that is excessive; a comment in `perldoc -f printf` 
would address
that rather fully.

Re: rethinking printf

[Luke Palmer]

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 case with a minimal of noise
> >> and the uncommon case has a simple out of using $(). no need for wacko
> >> ways to put in \n. it is double quotish in all ways but one and mainly
> >> to be used for printf format strings.
> >
> >
> > I also like this because it allows a typical format string to be 
> > converted
> > merely by adding a two-character prefix:
> >
> > printf("The value is %7.2f\n", $foo);
> > ---
> > printf(qn"The value is %7.2f\n", $foo);
> >
> > -r
> 
> if qf() is defensible, it should pass some generality tests;
> 
> 1. make it 'replace' printf
> print qf'%s %d', $somestring, $someint;
> 
> 2. make it 'replace' sprintf.
> $res = qf('%s %d %d', $somestr, $anint)
> 
> 3. detect the silent error above - insufficient args.
> this quote-like operator is now a list-op, and a smart one.
> 
> 4. make it know whether %s means hash interpolation or printf-format-spec
> 
> a. ive seen perl5 warn about escaping @ when printing undefined / undeclared
> @array (cant seem to replicate now :-/ )
> 
> b. the universe of printf format specs is pretty small, it really only 
> interferes
> with (the expansion of: @{[ each %s ]} ) a few single letter hashes %s, 
> %d, etc..
> 
> c. item b implies a run-time check to see that no %s, %d, are hidden by 
> a format-spec
> interpretation, but that is excessive; a comment in `perldoc -f printf` 
> would address
> that rather fully.

I'm thinking, an operator really isn't needed is it? Hows about we extend 
printf to support double quote-like escape sequences. So:
 (s)printf 'Hello $foo,\n how %s you?', 'am';
Would print:
Hello $foo,
how am you?

In other words, we change printf, not the quotes.