On Tue, 10 Oct 2000, Tim Bunce wrote:
> > A very complete UML tool in Java is ArgoUML:
> >
> > http://argouml.tigris.org/
>
> Umm, it might be interesting for someone to add a Perl code generator
> for it...
I've played with the idea of adding Perl code-generation to my design
tools (Visio200
On Wed, 22 Nov 2000, Dan Sugalski wrote:
> Probably the easiest thing is to implement some sort of file-tied scalar or
> something that can provide bytes to the regex engine until it stops asking
> for them. Some magic or other, though, will get us what we need.
That might be the easiest thing f
On Tue, 21 Nov 2000, David Grove wrote:
> If we were simply feeding it perl with a single syntax, we could get away
> with a "one call" scheme. But since we're dealing with almost certainly
> mutually exclusive syntax and semantics, it probably needs more
> information.
Perhaps the "one call" ca
On Fri, 24 Nov 2000, Nicholas Clark wrote:
> I think Dan was suggesting that the (user side) regex doesn't change at all
> (so that's no new syntax there)
> It's just that the innards of perl gains a tied scalar that doesn't actually
> read in and buffer the file immediately, but defers it as lon
On Wed, 22 Nov 2000, Nicholas Clark wrote:
> Are we hoping that we can mmap() most scripts, so read isn't hugely a
> problem? And slrp the rest in one? [doesn't feel good]
> Are we going to have "lazy scalars" which collude with the regexp engine
> so that if the regexp engine hits the cu
On Sat, 2 Dec 2000, Nathan Torkington wrote:
> * it's difficult for the design to happen through the questions
Is that really true? Have we tried? As far as I can tell we've got a
lot of well-intentioned people that for whatever reason are spending very
little time making Perl 6 happen.
Let
On Tue, 5 Dec 2000, Alan Burlison wrote:
> How about writing the documents in XML and having a 'perl specification'
> DTD?
> ...
> Death to POD!
Can we *please* not re-fight this war? I know you remember the last
couple incarnations of XML VS POD. Just replay them in your mind and
enjoy the sh
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> >my $new_dog;
> >{
> > my $dog = new Dog;
> > $new_dog = \$dog;
> >}
>
> That would hoist the Dog reference into an outer level of scope--in this
> case the one containing $new_dog. Or so my thinking goes at the moment,
> though th
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> Non-refcounting GC schemes are more expensive when they collect, but less
> expensive otherwise, and it apparently is a win for the non-refcount
> schemes.
Which is why GC is intimately tied to DESTROY consideration in terms of
Perl. If we intend to hon
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> Sure, but only objects. (or, to be really paranoid, things referred to)
> Nothing else needs refcounting. All the refcounting code can be isolated in
> the reference creation and deletion code, and we don't have to pay it
> otherwise.
Good point. I hadn
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> What I'm thinking is that we'll have a scoped destruct stack that gets
> pointers to variables that explicitly need destruction, and as we exit
> levels of scope we call the destructors of those variables that need it.
> (They can still be GC'd later to p
On Wed, 6 Dec 2000, Bradley M. Kuhn wrote:
> And, it will make the barrier for entry for new internals hacker lower.
Really? Do you honestly believe there are more Java programmers than C
programmers? Particularily in the Perl development community!
> I would note that if we write in Java, we
On Thu, 7 Dec 2000, Simon Cozens wrote:
> On Thu, Dec 07, 2000 at 11:22:35AM -0500, John Porter wrote:
> > [C++]
>
> > It's nearly as portable,
>
> Uhm. Is this actually true? C runs pretty much anywhere.
>
> Are there any non-fragile implementations of C++ yet?
Which also brings up another poin
On Thu, 7 Dec 2000, Bradley M. Kuhn wrote:
> Now, I would agree that there are more C hackers about. However, many
> people are graduating college with computer science degrees having worked
> mostly in Java and very little in C. In 6 years or so, we may find that
> there are more Java hackers
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 th
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 w
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, b
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 so
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 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 s
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
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
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 Mon, 12 Feb 2001, Dan Sugalski wrote:
> Perl needs some level of tracking for objects with finalization attached to
> them. Full refcounting isn't required, however.
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
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
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.
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 e
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 "
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
t
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"...
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 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,
appar
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
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, 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 wi
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 t
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 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 pas
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 o
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 t
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 agr
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 t
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 fak
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
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 sing
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 i
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)
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();
>
> 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 Wed, 20 Jul 2005, Michael G Schwern wrote:
> Also, it eliminates one of the valuable parts of CPAN testers: testing in the
> wild. If you create an artificially clean environment (the clean image),
> then install all the latest versions of dependent modules into it and then
> run the tests you
Hello all. I've got a test I want to write, but I don't know to write
it (easily). I've got a test script, call it foo.t which uses
Test::More and runs under Test::Harness. Now I want to make a new
test script tweek-then-foo.t which tweeks the system and then ensures
that foo.t still passes. Ho
On Tue, 12 Apr 2005, Paul Johnson wrote:
> I would do it in the same way as if this had nothing to do with tests.
> That is, abstract away the common code into a module, which can also
> live under t/
That would be a lot of work in this case. I found an easier
solution. In tweek-then-foo.t:
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 p
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
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 miss
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
>
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
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.
Soun
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
incompa
Here's a patch to re-fix comparisions in the Scheme compiler. The
patch:
- Makes (<),(>),(<=),(>=) and (=) behave correctly on more than two
args.
- Adds tests to affirm this and fixes tests that were incorrect.
Sidenote: I don't think it's going to be possible to do static type
inf
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 probabl
On Thu, 25 Oct 2001, Dan Sugalski wrote:
> The only bits of the interpreter that much care about the
> string data are the regex engine parts, and those only operate on
> fixed-sized data.
Care to elaborate? I thought the mandate from Larry was to have regexes
compile down to a stream of string
On Fri, 26 Oct 2001, Dan Sugalski wrote:
> Okay, here are the conventions.
Great. Anyone want to offer up some examples or should I just wait for
Jako support to see this in action?
-sam
On Sun, 28 Oct 2001, Simon Cozens wrote:
> You are all encouraged to write implementations of the vtable functions
> in scalarclass.c
Cool. So, what needs to get done first? By that I mean, what is standing
in the way of our creating tests for scalar PMCs? Maybe I'm anal
retentive, but I don'
On Mon, 5 Nov 2001, Simon Cozens wrote:
> On Sun, Nov 04, 2001 at 06:22:59PM -0300, Daniel Grunblatt wrote:
> > Do you want me to give you an account in my linux machine where I have
> > install gcc 3.0.2 so that you see it?
>
> How much effort do we want to put into something that shows a speedu
On Fri, 26 Oct 2001, Brent Dax wrote:
> What if I want my compiler to be lazy? Do you have the right to punish
> me for my laziness by making me add constant folding to my optimizer (or
> perhaps making me *write* an optimizer just to do constant folding)?
Actually, a really lazy compiler will
On Thu, 8 Nov 2001, Dan Sugalski wrote:
> Gack. Looks like a mis-placed optimization in perl 5. The list of a foreach
> is *supposed* to flatten at loop start and be static. Apparently not. :)
>
> Care to file the perl 5 bug report, or shall I?
It's not a bug. Check out the "Foreach Loops" sect
On Thu, 8 Nov 2001, Brent Dax wrote:
> That doesn't support your argument. The point is that in the statement:
>
> foreach(@array) {
> ...
> }
>
> @array should only be evaluated once, at the beginning of the loop. In
> effect (using := here, but otherwise Perl 5 code)
On Thu, 8 Nov 2001, Dan Sugalski wrote:
> Yes, it is a bug. There's an array in list context--it's supposed to be
> flattened before the foreach loop gets evaluated. (And if there are
> multiple arrays in the list it works as you'd expect)
Sorry, I quoted the wrong section. It really isn't a bu
On Sat, 1 Dec 2001, Dan Sugalski wrote:
> At 01:20 PM 12/1/2001 -0500, Jeff G wrote:
> >I'll probably pull out perl5's snprintf function and
> >add it to the vtables.
>
> Unfortunately I'll say the dreaded "L" word here...
>
> Licensing.
Wow, are we still running this project without a license?
On Sun, 2 Dec 2001, Michael L Maraist wrote:
> On Sunday 02 December 2001 02:47 pm, Brent Dax wrote:
> > Quick comment: I've been thinking about constructing an 'OpaqueHandle'
> > PMC type. All the programmer is supposed to know about it is that it
> > points to Something (usually a C struct, bu
On Sun, 9 Dec 2001, David Jacobs wrote:
> +for (i = 1; size > i; i <<= 1);
Infinite loop if size == MAXINT, eh? "So don't do that." Ok.
-sam
On Sat, 29 Dec 2001, Boris Tschirschwitz wrote:
> I suggest
> opcode_t* code_start
So what does this declare:
opcode_t* code_start, code_end;
If you said two pointers to opcode_t then you just got fooled by your
notation! If you want to move the '*' then it has to go to the RHS since
On Mon, 31 Dec 2001, Clark C . Evans wrote:
> Hello. I was wondering if Parrot is going to support
> Generators. A generator is a function that returns
> multiple times, and I believe, was first made available
> in the language ICON. Now, ICON may have taken it a
> bit too far (everything is
On Thu, 17 Aug 2000, Nick Ing-Simmons wrote:
> Simon Cozens <[EMAIL PROTECTED]> writes:
> >Wow. I'm sold. Can this be how we should be doing XS in Perl 6?
> So we now run equivalent of xsubpp and cc every time script is run?
No. The documentation states that the compilation is done only when the
On Fri, 18 Aug 2000, Graham Barr wrote:
> > No. The documentation states that the compilation is done only when the
> > source file is out of date with the companion object file. As I
> > understand it, Inline has some kind of limited automatic make ability.
>
> So it is a security issue then a
On 20 Aug 2000, Chaim Frenkel wrote:
> SWM> Does Perl6 support Symmetric MultiProcessing (SMP)?
Perl5 does - see 'fork'. I'm guessing that Perl6 will have at
least that much support.
> SWM> This is a *huge* issue. It affects everything else that we do with
> SWM> threads.
Most operating syst
On 23 Aug 2000, Perl6 RFC Librarian wrote:
> Since versioning is a meta-implementation issue, all that is required
> is that fearless leader has to agree this is a good idea.
Very funny. I suppose you don't mind if he changes his mind someday?
I'm starting to think that you have too much time
On Tue, 29 Aug 2000, David L. Nicol wrote:
> Well then. It is impossible to rearchitect it to make it shared
> text? Perhaps the first instance of perl sets up some vast shared
> memory segments and a way for the newcomers to link in to it and look
> at the modules that have been loaded, somewh
On Tue, 29 Aug 2000, Nick Ing-Simmons wrote:
> David L . Nicol <[EMAIL PROTECTED]> writes:
> >
> >does sysV shm not support the equivalent security as the file system?
>
> mmap() has the file system.
I wasn't aware that mmap() was part of SysV shared memory. My
mistake? It's not on the SysV IP
On Tue, 29 Aug 2000, David L. Nicol wrote:
> does sysV shm not support the equivalent security as the file system?
Well, no, I don't think it does. It supports permissions on individual
segments but it doesn't support anything like directory perimssions. It
might be enough, and it might not be
On Thu, 31 Aug 2000, David L. Nicol wrote:
> Perl looks, and AFAIK has always looked, like "C plus lune noise" to
> many people.
I think Perl looks like "C plus moon noise" to former C programmers. I
imagine some people see it and think "Csh plus Awk noise". Perl is a lot
more than C-with-scal
On Thu, 31 Aug 2000, David L. Nicol wrote:
> We're talking about making a faster Perl. C's syntax requires enough
> clarity to compile to something quick. it is a very short hop from
> my dog $spot;
> to
> dog spot;
What about the second version would result in faster execution? D
On 14 Sep 2000, Chaim Frenkel wrote:
> (Someone remind me, What is the point of -T if not running setuid?)
All you need to get root is an unprivilaged shell on anything but a
fully patched machine. A dumb Perl CGI running without -T is all you need
to get a shell.
Besides, I bet most online st
On 20 Sep 2000, Perl6 RFC Librarian wrote:
> The absence of a C concept and keyword in Perl makes it more
> difficult to interface with relational databases and other medium which
> utilize C. Modules such as C must map C to C,
> which is an imperfect match.
Does it really make it more difficult
On Tue, 19 Sep 2000, Glenn Linderman wrote:
> > I agree that undef and NULL have different semantics. However, this is
> > clearly SQL's fault and not Perl's. We shouldn't repeat their mistake
> > just because we occasionally have to interface with their system.
>
> They are different. Neithe
On Mon, 18 Sep 2000, Michael G Schwern wrote:
> On Mon, Sep 18, 2000 at 12:32:08PM -0400, Sam Tregar wrote:
>
> If I grok'd the bastards, I'd write the explaination myself.
If you grok'd the bastards I bet you'd realize how useless such an
explanation would be. Th
On Tue, 19 Sep 2000, Dave Storrs wrote:
> "Unpack takes binary data in some particular format and
> disassembles it, assigning various pieces of it to variables according to
> formatting that you supply. Pack does the opposite, using your supplied
> formatting to crunch Perl scalar variabl
On 19 Sep 2000, Perl6 RFC Librarian wrote:
> Distinguish packed binary data from printable strings
What defines a "printable" string? What if I'm working in an environment
that can "print" bytes that yours can't? Specifically I'm wondering how
this proposal handles Unicode.
-sam
On Mon, 18 Sep 2000, Michael G Schwern wrote:
> Perhaps someone could attempt to write an explaination of pack and
> unpack in completely Perl terms. No bits, no ints, no nybbles, no
> IEEE floating point arithmetic, no prior knowledge of C necessary.
> Those are not Perl. Scalars, arrays, hash
96 matches
Mail list logo
