On Tue, 23 Oct 2001, Dan Sugalski wrote:
At 12:05 PM 10/23/2001 -0400, Sam Tregar wrote:
PS: CVS! CVS! CVS CVS CVS!
Someone send me the files needed for Scheme and I'll check 'em in.
I'll leave that to Jeff since it's his baby. You'll probably also want to
give him CVS commit privs
Fresh checkout won't compile on Redhat Linux 7.1:
string.c: In function `string_compare':
string.c:161: warning: passing arg 1 of pointer to function from
incompatible pointer type
string.c:161: too few arguments to function
string.c:164: warning: passing arg 1 of pointer to function from
Fresh checkout won't compile on Redhat Linux 7.1:
string.c: In function `string_compare':
string.c:161: warning: passing arg 1 of pointer to function from
incompatible pointer type
string.c:161: too few arguments to function
string.c:164: warning: passing arg 1 of pointer to function from
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
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 missing
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.
Sounds
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 missing
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
test
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.
Sounds
On Thu, 11 Oct 2001, Dan Sugalski wrote:
Did we put a patch into parrot that lets you fetch the current PC and store
it in an integer register? I seem to recall someone did, but I can't find it.
That's the '@' thing I was talking about making a doc patch for. I then
realized that I didn't
On Sat, 6 Oct 2001, Gregor N. Purdy wrote:
After the bytecode is loaded, but before it is executed, put it through
a stage of processing that requires about as much information as a
disassembler would (which is why my op_info stuff from one of my previous
patches is required).
This process
Am I correct that '@' in the assembly syntax is undocumented? The only
place I could find it was in source comments in Parrot::Assembler. I had
to search for @ to find it. Believe me, the last thing you want to search
for in a Perl module is @.
I think a patch to docs/parrot_assembly.pod
Can I get a .car and a .cdr please? In my limited mind key and value
are specific to hashes and their wimpy brother associative lists.
-sam
Can I get a what what?
On Thu, 4 Oct 2001, Damian Conway wrote:
A false economy. We should encourage Larry as often as we can.
After all, is it any wonder that it's so long between Apocalypses when
every time he releases one, he gets nothing but negative feedback?
Hm, that never occured to me. In that case, let
On Sun, 30 Sep 2001, Steffen Beyer wrote:
Therefore Bit::Vector objects are just a blessed scalar containing
a number (actually the pointer returned by malloc) as far as Perl
is concerned.
Because changing this number would be extremely dangerous, I
write-protect the blessed scalar.
I've
On Sun, 30 Sep 2001, Nick Ing-Simmons wrote:
The main problem with perl5 and threads is that threads are an afterthought.
Which, of course, also goes for UNIX and threads and C and threads.
It's good for us to be thinking about as early as possible but it's no
garauntee that there won't be big
On Mon, 24 Sep 2001 [EMAIL PROTECTED] wrote:
I've found that HTML::Template keeps the \n(newline, if that
character screws up your mail reader) in it's template parsing.
Yup, that's by design. Think about it for a moment and you'll realize
that's the only sane option. HTML::Template is
On Mon, 24 Sep 2001 [EMAIL PROTECTED] wrote:
Current behavior would still screw up a pre block, unless you wrote
your .tmpl files without newlines for TMPL_LOOP and other control
directives.
I've used TMPL_LOOPs to write pre blocks with no problems. You just
have to be aware of where your
On Mon, 24 Sep 2001, Philip Coombes wrote:
I have a sort of similar (but subtly different!) issue to raise. When I'm
building up long lines of HTML (or WML, I use it for both) using TMPL_IFs and
TMPL_LOOPs I'd very much like to have the option to string it all together
without any newlines
On Mon, 24 Sep 2001, Philip Coombes wrote:
Nope, the complexity doesn't worry me. Just the inate redundancy of parsing
all the TMPL_SECTION bits in one place and all the other TMPL bits in another
when all the while the Template module already knows exactly which newlines
are genuine and
On Tue, 18 Sep 2001, Damien Neil wrote:
Proposed: Parrot should never crash due to malformed bytecode. When
choosing between execution speed and bytecode safety, safety should
always win.
I don't see this as a safety issue. There's nothing unsafe about
crashing. It's just not as pretty as
On Mon, 17 Sep 2001, Command Prompt, Inc. wrote:
Is this truly the case, or is there a way for PostgreSQL to remember the
connection identifier so that the next time a PHP connection is made with
the same identifier a transaction can be completed?
Anything is possible - you could write a
On Sat, 15 Sep 2001, Philip Kendall wrote:
My personal view would be that the gains due to portable bytecode would
be outweighed by the amount of cruft we'd have to put into the
interpreter to get them. As Nicholas Clark and someone else who's name
I've forgotten[1] mentioned, there are
On Sat, 15 Sep 2001, Philip Kendall wrote:
My personal view would be that the gains due to portable bytecode would
be outweighed by the amount of cruft we'd have to put into the
interpreter to get them. As Nicholas Clark and someone else who's name
I've forgotten[1] mentioned, there are
Patches should be sent to the perl6-internals mailing list, where I'll take a
look at them and apply them to the CVS tree.
Ooo, ooo - me first. Since you turned on -Wall in the Makefile I thought
it would be nice if it compiled without warnings. Below is a patch that
does that on my system.
Patches should be sent to the perl6-internals mailing list, where I'll take a
look at them and apply them to the CVS tree.
Ooo, ooo - me first. Since you turned on -Wall in the Makefile I thought
it would be nice if it compiled without warnings. Below is a patch that
does that on my system.
On Sun, 2 Sep 2001, Simon Cozens wrote:
For instance, the Parrot VM will have a register architecture, rather
than a stack architecture.
s/rather than/as well as/; # we've got a stack of register frames, right?
There will be global and private opcode tables; that is to say, an area
of the
On Mon, 3 Sep 2001, Nathan Torkington wrote:
Ok, so one example of a PMC is a Perl string...
If you grok vtables, think of a PMC as the thing a vtable hangs off.
Another way to think of it is that a PMC is an object. To the outside
(the interpreter that is manipulating data values) its
On Mon, 3 Sep 2001, Dan Sugalski wrote:
Basically chunks of perl code can define opcodes on the fly--they might be
perl subs that meet the proper critera, or opcode functions defined by C
code with magic stuck in the parser, or wacky optimizer extensions or
whatever. There won't be a single
On Mon, 3 Sep 2001, Dan Sugalski wrote:
avoid using a call opcode all over the place, right?
No, more a try and leave the bytecode sections read-only hack.
Imagine, if you will, building LWP and bytecode compiling it. It uses
private opcodes 1024-1160. Then you later build, say,
On Mon, 3 Sep 2001, Dan Sugalski wrote:
I'm not entirely sure how much this'll be used, but I really, *really* want
to be able to call any sub that qualifies as an op rather than as a sub.
What would a sub have to do (be?) to qualify?
I don't understand this restriction. Won't it make
On Mon, 3 Sep 2001, Brent Dax wrote:
Now is where the temp() stuff I was talking about earlier comes in.
sub foo {
my($bar);
foo();
}
is basically equivalent to
sub foo {
temp($MY::bar);
foo();
}
Oh,
On Sun, 2 Sep 2001, Simon Cozens wrote:
For instance, the Parrot VM will have a register architecture, rather
than a stack architecture.
s/rather than/as well as/; # we've got a stack of register frames, right?
There will be global and private opcode tables; that is to say, an area
of the
On Mon, 3 Sep 2001, Dan Sugalski wrote:
Basically chunks of perl code can define opcodes on the fly--they might be
perl subs that meet the proper critera, or opcode functions defined by C
code with magic stuck in the parser, or wacky optimizer extensions or
whatever. There won't be a single
On Mon, 3 Sep 2001, Dan Sugalski wrote:
avoid using a call opcode all over the place, right?
No, more a try and leave the bytecode sections read-only hack.
Imagine, if you will, building LWP and bytecode compiling it. It uses
private opcodes 1024-1160. Then you later build, say,
On Mon, 3 Sep 2001, Dan Sugalski wrote:
I'm not entirely sure how much this'll be used, but I really, *really* want
to be able to call any sub that qualifies as an op rather than as a sub.
What would a sub have to do (be?) to qualify?
I don't understand this restriction. Won't it make
On Mon, 3 Sep 2001, Nathan Torkington wrote:
Ok, so one example of a PMC is a Perl string...
If you grok vtables, think of a PMC as the thing a vtable hangs off.
Another way to think of it is that a PMC is an object. To the outside
(the interpreter that is manipulating data values) its
On Mon, 3 Sep 2001, Brent Dax wrote:
Now is where the temp() stuff I was talking about earlier comes in.
sub foo {
my($bar);
foo();
}
is basically equivalent to
sub foo {
temp($MY::bar);
foo();
}
Oh,
On Sun, 2 Sep 2001, Brent Dax wrote:
but in that case the inner my($x) could be translated to
temp($MY::x)--the behavior is basically the same. (Actually, if pads
are replaced with stashes, is there any situation where my($x) can't be
translated to temp($MY::x)? Hmmm...)
Closures, for
On Sun, 2 Sep 2001, Brent Dax wrote:
but in that case the inner my($x) could be translated to
temp($MY::x)--the behavior is basically the same. (Actually, if pads
are replaced with stashes, is there any situation where my($x) can't be
translated to temp($MY::x)? Hmmm...)
Closures, for
On Sun, 2 Sep 2001, Brent Dax wrote:
Okay, I forgot to account for the fact that we'd have to increment the
refcount for every inner scope a my() variable is referred to in.
That's not terribly hard, is it?
I have no idea what you're talking about here. You asked if it was
possible to fake
On Wed, 29 Aug 2001, Simon Cozens wrote:
It's almost time to start coding, people, almost.
Not to be an ass, but is it? It seems like we're still a long way from
having a language spec.
-sam
On Thu, 30 Aug 2001, Simon Cozens wrote:
That's not entirely relevant any more. Parrot has a semi-autonomous
existence as a generic bytecode interpreter. We may be a long way
from having a language spec, but we're pretty damned close to having
a spec for the interpreter.
I look forward to
On Thu, 30 Aug 2001, Simon Cozens wrote:
That's not entirely relevant any more. Parrot has a semi-autonomous
existence as a generic bytecode interpreter. We may be a long way
from having a language spec, but we're pretty damned close to having
a spec for the interpreter.
I look forward to
On Thu, 30 Aug 2001, Simon Cozens wrote:
I could spend a lot of time justifying it to you here and now, or I
could spend the same time writing a detailed specification of the
interpreter interface. I think, to be honest, it might be more
productive for me to take the second option.
I agree
On Wed, 29 Aug 2001, Simon Cozens wrote:
It's almost time to start coding, people, almost.
Not to be an ass, but is it? It seems like we're still a long way from
having a language spec.
-sam
On Thu, 30 Aug 2001, Uri Guttman wrote:
we have very strong internal specs already that will support most
anything larry throws at us. stuff such as the op code loop, async
(file) i/o, events, etc, are all known to be needed so we can code them
now that the design is firming up. we have the
On Wed, 29 Aug 2001, Jeremy Howard wrote:
The answer used in .NET is to have a dispose() method (which is not a
special name--just an informal standard) that the class user calls manually
to clean up resources. It's not an ideal solution but there doesn't seem to
be many other practical
On Sun, 26 Aug 2001, Peter Eisentraut wrote:
Many of these advantages can easily interpreted as disadvantages. For
example:
Have you ever considered a career in marketting?
= In MySQL you have to repair your tables manually if corruption occurs.
PostgreSQL is coded so that corruption
On Sat, 25 Aug 2001, Nathan Torkington wrote:
I'd like to keep the code on Sourceforge from the get-go. I don't
have much experience with Sourceforge, though, and would like to talk
to someone who has. Which bits work well? Which bits aren't worth
the effort? Any tips or tricks to pass
On Sun, 19 Aug 2001, David Wheeler wrote:
I'm looking for a couple of solid books to help me broaden my knowledge of
database design so that I can improve my designs. So what do you like?
What stuff have you read and would recommend? I'm most interested in
fundamentals of both standard
On Mon, 6 Aug 2001, Dan Sugalski wrote:
No, he's right. Not dirtying cache lines is pretty much always faster than
dirtying them, and not twiddling with memory's faster than twiddling. And
unfortunately we can't really do fully platform-dependent code, since it'll
be the actual bytecode
On Mon, 6 Aug 2001, Dan Sugalski wrote:
No, he's right. Not dirtying cache lines is pretty much always faster than
dirtying them, and not twiddling with memory's faster than twiddling. And
unfortunately we can't really do fully platform-dependent code, since it'll
be the actual bytecode
On Mon, 6 Aug 2001, Hong Zhang wrote:
It is not just for performance, the stack size and cache
locationality are also big issues.
Cache sizes and timings vary from machine to machine. Maybe we should
make it configurable at compile-time? If we do that then there's no
reason to try to guess
On Mon, 6 Aug 2001, Hong Zhang wrote:
It is not just for performance, the stack size and cache
locationality are also big issues.
Cache sizes and timings vary from machine to machine. Maybe we should
make it configurable at compile-time? If we do that then there's no
reason to try to guess
On Fri, 3 Aug 2001, Evan Zane Macosko wrote:
I've got a large two dimensional matrix of float values--about 6000 rows
and 1000 columns (the size will vary, but will always be two
dimensional)--and I need to pass it from Perl to C to do some hefty
mathematical computations. I can't seem to
On Mon, 30 Jul 2001, Dan Sugalski wrote:
When you actually use a module, the simple name (like IO) will be
internally expanded out to the three value thing. So if you have two
modules that each use a different version of the same module, they won't
interact because each will be dealing with
On Tue, 24 Jul 2001, Brian Ingerson wrote:
+ Added support for ILSMs who don't want to invoke a build
Thanks! I'll give this a try in my next Inline::Guile release.
-sam
On Mon, 9 Jul 2001, ivan wrote:
http://www.ora.com/news/vhll_1299.html
Fascinating article, but his point about XML source code struck my funny
bone. I've certainly heard the argument before - most recently in Dr.
Dobbs Software Development insert.
I've got just one question: if this is such
On Mon, 9 Jul 2001, Adam Turoff wrote:
Don't laugh. It's here now. It's called XSLT. :-)
Um, that's not what the article was talking about The proposal is to use
an XML syntax to program in existing VHLL languages, including Perl.
This would supposedly allow programmers to embed drawings
On Mon, 9 Jul 2001, Adam Turoff wrote:
Who said programming Perl in XML was a good idea?
Did you read the article I was responding to? I suggest you do.
Strangely, many people seem to believe XML is ideally suited to every
computing task known to man. This includes programming in Perl,
On Mon, 9 Jul 2001, Dan Brian wrote:
program XSLT in XML? What does that mean?
It means roughly what program Perl in ASCII means.
Have you used XSLT? Do you understand what it is and what it does? It
makes quite a bit of sense for those performing regular conversions
from a single data
On Mon, 9 Jul 2001, Adam Turoff wrote:
Who said programming Perl in XML was a good idea?
Did you read the article I was responding to? I suggest you do.
Strangely, many people seem to believe XML is ideally suited to every
computing task known to man. This includes programming in Perl,
On Mon, 9 Jul 2001, ivan wrote:
http://www.ora.com/news/vhll_1299.html
Fascinating article, but his point about XML source code struck my funny
bone. I've certainly heard the argument before - most recently in Dr.
Dobbs Software Development insert.
I've got just one question: if this is such
On Mon, 9 Jul 2001, Dan Brian wrote:
program XSLT in XML? What does that mean?
It means roughly what program Perl in ASCII means.
Have you used XSLT? Do you understand what it is and what it does? It
makes quite a bit of sense for those performing regular conversions
from a single data
On Mon, 9 Jul 2001, Adam Turoff wrote:
Don't laugh. It's here now. It's called XSLT. :-)
Um, that's not what the article was talking about The proposal is to use
an XML syntax to program in existing VHLL languages, including Perl.
This would supposedly allow programmers to embed drawings
On Tue, 3 Jul 2001, Neil Watkiss wrote:
Should that be the default? Should the current directory (the actual source
directory, not the build area) be added to the INC by default? Something like
this:
Definitely. C programmers will naturally expect the current directory to
be search for
On Tue, 3 Jul 2001, Philip Molter wrote:
What causes this and how can I fix it?
Have you tried a VACUUM ANALYZE? For some reason Postgres isn't able to
use its indexes fully unless you VACUUM ANALYZE often.
I consider this a bug but I gather the developers are OK with it.
-sam
On Sat, 30 Jun 2001, Brian Ingerson wrote:
void
add4 (...)
PPCODE:
{
SV* sum = sv_newmortal();
sv_setiv(sum, (IV)((int)SvIV(ST(0)) + (int)SvIV(ST(1;
ST(0) = sum;
XSRETURN(1);
}
That can get a little better (10% or
+
+Sam Tregar [EMAIL PROTECTED]
+
+=back
+
+=cut --
+
=head2 Multiple Return Values
=over 4
On Sun, 10 Jun 2001, Me wrote:
Yes. But if the syntax for arrays and db data are to
be simultaneously the same and as ideal as possible,
then either the core array syntax needs to be relatively
ideal for relational db data, or one needs to redefine
the array syntax to match a created db
On Sun, 10 Jun 2001, Me wrote:
Agreed. So long as you are talking about Perl 5's arrays.
I disagree, if you are talking about 2 dimensional structures.
You appear to have some fundamental misunderstanding about Perl 5. Perl 5
does indeed support multidimentional arrays:
my @matrix = ( [
On Sun, 10 Jun 2001, Me wrote:
Yes. But if the syntax for arrays and db data are to
be simultaneously the same and as ideal as possible,
then either the core array syntax needs to be relatively
ideal for relational db data, or one needs to redefine
the array syntax to match a created db
On Sun, 10 Jun 2001, Me wrote:
Agreed. So long as you are talking about Perl 5's arrays.
I disagree, if you are talking about 2 dimensional structures.
You appear to have some fundamental misunderstanding about Perl 5. Perl 5
does indeed support multidimentional arrays:
my @matrix = ( [
On Fri, 8 Jun 2001, Jarkko Hietaniemi wrote:
An interesting article in the July DDJ) in the Algorithm Alley:
Fast and Small Resizable Arrays, presents a datastructure that
promises just what the subject says.
The first thing I thought of after reading the article was use less
memory... I
On Thu, 10 May 2001, David Grove wrote:
The changes are beautiful. It's calling it Perl and relying on subliminal
pursuasion to ask users to consider it the same that bothers me. That's a
very Microsoftish tactic.
No, it's Perl 6. If you want Perl 5 or even Perl 4 you know where
to find it.
On Thu, 10 May 2001, David Grove wrote:
The changes are beautiful. It's calling it Perl and relying on subliminal
pursuasion to ask users to consider it the same that bothers me. That's a
very Microsoftish tactic.
No, it's Perl 6. If you want Perl 5 or even Perl 4 you know where
to find it.
On Wed, 21 Feb 2001 [EMAIL PROTECTED] wrote:
On Wed, Feb 21, 2001 at 05:32:50PM -0500, Sam Tregar wrote:
Examples? I know you're not talking about C or C++. I'm pretty sure
you're not talking about Java - exception-handling renders the term "fatal
error" almost meaningle
On Wed, 21 Feb 2001, Bart Lateur wrote:
Actually, it's pretty common. Only, most languages are not as forgiving
as perl, and what is merely a warning in Perl, is a fatal error in those
languages. Trying to read the value of an uninitialized variable, for
example, that's commonly a fatal
On Wed, 21 Feb 2001 [EMAIL PROTECTED] wrote:
On Wed, Feb 21, 2001 at 05:32:50PM -0500, Sam Tregar wrote:
Examples? I know you're not talking about C or C++. I'm pretty sure
you're not talking about Java - exception-handling renders the term "fatal
error" almost meaningle
On Wed, 21 Feb 2001, Bart Lateur wrote:
Actually, it's pretty common. Only, most languages are not as forgiving
as perl, and what is merely a warning in Perl, is a fatal error in those
languages. Trying to read the value of an uninitialized variable, for
example, that's commonly a fatal
On Fri, 16 Feb 2001, Simon Cozens wrote:
On Fri, Feb 16, 2001 at 08:52:03PM +, Nicholas Clark wrote:
macro languages and symbolic debuggers don't mix well.
Generated output would be Real Life C. I'm thinking something along the lines
of
perl vtable.pl vtable.spec vtable.c
which
On Fri, 16 Feb 2001, Simon Cozens wrote:
On Fri, Feb 16, 2001 at 08:52:03PM +, Nicholas Clark wrote:
macro languages and symbolic debuggers don't mix well.
Generated output would be Real Life C. I'm thinking something along the lines
of
perl vtable.pl vtable.spec vtable.c
which
On Mon, 12 Feb 2001, Dan Sugalski wrote:
I think I've heard you state that before. Can you be more specific? What
alternate system do you have in mind? Is this just wishful thinking?
This isn't just wishful thinking, no.
You picked the easy one. Maybe you can get back to the other two
On Mon, 12 Feb 2001, Dan Sugalski wrote:
I think I've heard you state that before. Can you be more specific? What
alternate system do you have in mind? Is this just wishful thinking?
This isn't just wishful thinking, no.
You picked the easy one. Maybe you can get back to the other two
On Sun, 11 Feb 2001, Jan Dubois wrote:
However, I couldn't solve the problem of "deterministic destruction
behavior": Currently Perl will call DESTROY on any object as soon as the
last reference to it goes out of scope. This becomes important if the
object own scarce external resources
On Sat, 10 Feb 2001, Branden wrote:
Suppose I have a string stored in $foo, say, "abcbca", and then I do:
$bar = $foo;
$foo .= "xyzyzx";
I see two ways of doing this: one is allowing a string value to be shared by
two or more variables, and the other one not.
Why would you want
On Sat, 10 Feb 2001, Buddha M Buck wrote:
I think what he's thinking (in C terms) would be more like the following:
Right. It already has a technical name - copy-on-write. I should have
made it more clear that I recognized the intended mechanism. I was trying
to demonstrate that Perl-level
Hey guys - I've got an idea for a new feature I'd like to add to wget.
I'd like a way to specify a program to be run that can filter the URLs
just before they are fetched. I'd like this so that I could use wget to
do recursive retrievals against Google's web cache. This would be useful
for
On Wed, 3 Jan 2001, Dan Sugalski wrote:
I think one of the things we might want to do is figure out what people use
signals for and see if we can abstract out some of that functionality
without actually exposing signals. (From an internals standpoint, at least)
Well, one thing people use
On Wed, 3 Jan 2001, Dan Sugalski wrote:
I think one of the things we might want to do is figure out what people use
signals for and see if we can abstract out some of that functionality
without actually exposing signals. (From an internals standpoint, at least)
Well, one thing people use
On Sat, 30 Dec 2000, Johan Vromans wrote:
Have you considered CGI::Application::MailURL instead of MailPage? If
I understand correctly, it does not necessarily send a page, but it
sends a URL, either as a link, as HTML, or as text.
I think MailPage is more accurate - the module requires the
Let me try this again (again, again):
NAME: CGI::Application::MailPage
DESCRIPTION: CGI::Application that allows users to send a page to friends.
DSLI: bmpO
USER: SAMTREGAR
CHAPTER: 15
It's a CGI::Application module that allows people to mail HTML pages to
their friends. I'd like to call
On Mon, 18 Dec 2000, Eric Cholet wrote:
ANNOUNCEMENT: NEW VERSION: HTML::Template 2.1
Does it support ELSIF yet?
Nope, but you can build your own now with the new filter option. I expect
someone to post up an "ELSIF" = "ELSE IF" filter to the HTML::Template
mailinglist any time now.
-sam
On Mon, 18 Dec 2000, David Grove wrote:
For the full language spec, I don't think it's attainable, and honestly
don't see the reason for it within the context of Perl.
I've got a simple reason for it - I think it's going to be part of the
Perl6 spec. Do I have any proof? Nope. We'll know
On Sun, 17 Dec 2000, Andy Dougherty wrote:
Now matter how we slice it, it's going to be very hard for the first
person to twist perl6 to parse something that is both complex and very
different from Perl6. And I'm unconvinced that this difficulty ought to
hold up the entire process. It
On Sun, 17 Dec 2000, David Grove wrote:
That sounds too complex for what seems like a more simple solution. When
you say "turn simple 'languages' into perl", that's what Dan's told me is
my source filter. Actually, it's a bit more than a source filter. The goal
would be to turn the creole
On Sun, 17 Dec 2000, Dan Sugalski wrote:
For my part, at least, I've been thinking of something either LISP-ish
or very simple parameter setting/checking (like stuff in, say, your
average .rc file with a little control flow thrown in) when it's
brought up. Occasionally things FORTHish, but
On Sun, 17 Dec 2000, David Grove wrote:
Ok, my C's rather rusty, but are we interested in parsing that?
Yes. I've heard people talk about a C frontend. Will it ever see the
light? I don't know. Does it matter? I don't think so.
Is Perl going to provide API to access pointers through
On Fri, 15 Dec 2000, Jarkko Hietaniemi wrote:
Limbo, the systems programming language of Inferno, nee Plan 9, nee UNIX.
http://www.vitavuova.com/inferno/papers/limbo.html
What are your thoughts about Limbo? I did some Limbo programming a couple
of years back. I can't say I came out of the
601 - 700 of 778 matches
Mail list logo
