On Fri, Aug 13, 2004 at 10:53:02AM +0100, Nicholas Clark wrote:
> On Wed, Aug 11, 2004 at 03:25:20PM -0700, David Storrs wrote:
> > On Sat, Aug 07, 2004 at 03:55:21PM +0100, Nicholas Clark wrote:
>
> > > However, Acme::Intraweb hasn't been updated for a while, whereas CPANPLUS
> > > has, so I'm n
On Wed, Aug 11, 2004 at 03:25:20PM -0700, David Storrs wrote:
> On Sat, Aug 07, 2004 at 03:55:21PM +0100, Nicholas Clark wrote:
> > However, Acme::Intraweb hasn't been updated for a while, whereas CPANPLUS
> > has, so I'm not sure if it still works. Both are by Jos Boumans.
>
> Urrmmm...ok, I'm s
On Sat, Aug 07, 2004 at 03:55:21PM +0100, Nicholas Clark wrote:
> On Sat, Jul 24, 2004 at 02:50:18PM -0700, David Storrs wrote:
> > #!/usr/bin/perl6
>
> #!/usr/bin/perl
I stated perl6 explicitly to be, well, explicit.
> > #use warnings; # Note that I am NOT explicitly using these
> > #use s
On Sat, Jul 24, 2004 at 02:50:18PM -0700, David Storrs wrote:
> Definitely. On the other hand...I find myself wondering if we could
> offer a pragma so that people can have the option if they want it.
> For example:
>
>
> #!/usr/bin/perl6
#!/usr/bin/perl
> #use warnings; # Note that I am N
On Sun, Jul 18, 2004 at 08:20:25PM -0700, David Storrs wrote:
> Race condition: what if something deletes the file between the moment
> that perl closes the file and the moment that it re-opens it? Is
> there a cross-platform way to do an atomic reopen?
No.
To the best of my knowledge there isn'
Luke Palmer wrote:
It's likely that CPAN will have a Bundle::EYEWTIBWATA. [1]
[1] Everything You Ever Wanted To Install But Were Afraid To Ask
EYEWTIBWATL eye-witty-bwattle
.. But Were Always Too Lazy
On Sat, 24 Jul 2004, Brent 'Dax' Royal-Gordon wrote:
> Hmm...maybe this could be done for Perl 5...
I guess it could be relatively easily done by means of the [EMAIL PROTECTED]
feature present in recent perls...
Michele
--
> A mathematically-inclined glove-fetishist [...]
What a wonderful intr
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> writes:
>> hopefully without dependencies on external non-Perl things like gcc).
>
> Don't think it'll be possible for modules that have C components,
I'm really hoping Perl6 will be sufficiently powerful that C
components won't be needed or wanted.
>
Larry Wall wrote:
Sounds like you're confusing #3 with #4.
Larry
Could be. Does 3 mean at install time, you down load the latest of the
'supported' packages from the CPAN alike or is it more like versioned
snapshots? (Possibly yet to be decided?) It's the idea of a standard
library being open
On 7/23/04, Luke Palmer wrote:
Not necessarily. Glop, on which I'm doing a presentation at OSCON
(have to plug it sometime ;-),
"Game Language on Perl, you say? Goodness, what's that??"
Sorry. Got tired of English.
=)
There's a lot of stuff like that. Way too much to include in a
distribution.
On Sun, Jul 25, 2004 at 11:41:14PM -0500, Dan Hursh wrote:
: Larry Wall wrote:
:
: >On Sun, Jul 25, 2004 at 01:32:29AM -0500, Dan Hursh wrote:
: >: >2. Really core. This is the sort of "standard library". Just the most
: >: >essential bits that are required for general Perl usability. You'd
: >: >
Larry Wall wrote:
On Sun, Jul 25, 2004 at 01:32:29AM -0500, Dan Hursh wrote:
: >2. Really core. This is the sort of "standard library". Just the most
: >essential bits that are required for general Perl usability. You'd
: >probably include most of these, even in a "trimmed down" release, such
: >as
On Sun, Jul 25, 2004 at 01:32:29AM -0500, Dan Hursh wrote:
: >2. Really core. This is the sort of "standard library". Just the most
: >essential bits that are required for general Perl usability. You'd
: >probably include most of these, even in a "trimmed down" release, such
: >as an OS installer
:
Aaron Sherman wrote:
Do any C++ programmers consider the STL to be anything other than "in
core" even though it's not part of the compiler, and with at least GCC,
it's distributed as a separate component?
Do any C programmers consider strlen or sprintf to be outside of the
core? It's part of the AN
On Sat, Jul 24, 2004 at 04:51:52PM -0700, Brent 'Dax' Royal-Gordon wrote:
: This would require 'cpan' to parse the script with a modified grammar
: that noted all the 'use's (and 'require's, I guess), then install each
: module. Or something like that.
:
: Hmm...maybe this could be done for Per
David Storrs wrote:
#!/usr/bin/perl6
#use warnings; # Note that I am NOT explicitly using these
#use strict;
{ no 'warnings'; no 'strict'; # These must be explicitly turned off...
no installation_security; # or this would throw warning & error
use SomeModule; #
use OtherMod
On Sat, Jul 24, 2004 at 02:23:10PM -0700, Brent 'Dax' Royal-Gordon wrote:
> Jonadab the Unsightly One wrote:
>
> >Oh, and here's me resisting the urge to suggest that use ought to
> >automatically install from the CPAN anything that isn't present, as a
> >core behavior right out of the box.
>
> S
Jonadab the Unsightly One wrote:
Surely, at bare minimum, there must be something included in core to
allow things that are not in core to be easily installed, the
equivalent of what CPAN.pm is for Perl5 (hopefully even better, and
I believe that's the current plan--the core will include CPAN, LWP,
JOSEPH RYAN <[EMAIL PROTECTED]> writes:
> Well, that's what all of the ruckus is about. There is a strong
> leaning towards including *no* builtin modules with the core.
Surely, at bare minimum, there must be something included in core to
allow things that are not in core to be easily installe
I define "outside the core" as "anything that isn't
packaged with Perl itself". Things you'd define as
"part of the language." I/O stuff, threading stuff,
standard types, builtin functions, etc. And yeah,
most of that stuff will be written natively in C,
PIR, or be part of parrot itself.
I thi
On Thu, 2004-07-22 at 19:21, JOSEPH RYAN wrote:
> Well, that's what all of the ruckus is about.
> There is a strong leaning towards including *no*
> builtin modules with the core. So, that leaves only
> the builtin functions and classes as "the core", and
> so what is "in core" becomes a prett
David Green writes:
> >So making it "go in the core" may just mean that it's
> >on the list of recommended modules to install.
>
> Does that mean having to "use Some::Module" to use it?
Not necessarily. Glop, on which I'm doing a presentation at OSCON (have
to plug it sometime ;-), makes use of
Luke Palmer <[EMAIL PROTECTED]> wrote on July 22, 2004:
Even more philosophical is "what is core?"
I believe the standard definition is "Anything I want to use goes in
the core; anything everyone else wants goes wherever there's room
left over." ...
So making it "go in the core" may just mean th
- Original Message -
From: Dan Hursh <[EMAIL PROTECTED]>
Date: Thursday, July 22, 2004 3:07 pm
Subject: Re: Why do users need FileHandles?
> Luke Palmer wrote:
>
> > JOSEPH RYAN writes:
> >
> >>- Original Message -
> >>From: David S
Luke Palmer wrote:
JOSEPH RYAN writes:
- Original Message -
From: David Storrs <[EMAIL PROTECTED]>
Date: Monday, July 19, 2004 5:04 pm
Subject: Re: Why do users need FileHandles?
Second, I would suggest that it NOT go in a library...this is
reasonably serious under-the-hood mag
- Original Message -
From: Luke Palmer <[EMAIL PROTECTED]>
Date: Thursday, July 22, 2004 2:48 pm
Subject: Re: Why do users need FileHandles?
>> JOSEPH RYAN writes:
> >
> > How would integrating this in the core make it more efficient? Core
> > or not, I&#
JOSEPH RYAN writes:
> - Original Message -
> From: David Storrs <[EMAIL PROTECTED]>
> Date: Monday, July 19, 2004 5:04 pm
> Subject: Re: Why do users need FileHandles?
>
> > Second, I would suggest that it NOT go in a library...this is
> > reasonably
- Original Message -
From: David Storrs <[EMAIL PROTECTED]>
Date: Monday, July 19, 2004 5:04 pm
Subject: Re: Why do users need FileHandles?
> Second, I would suggest that it NOT go in a library...this is
> reasonably serious under-the-hood magic and should be integrated int
--- chromatic <[EMAIL PROTECTED]> wrote:
> On Mon, 2004-07-19 at 14:04, David Storrs wrote:
>
> > Second, I would suggest that it NOT go in a library...this is
> > reasonably serious under-the-hood magic and should be integrated
> into
> > the core for efficiency.
>
> You must have amazingly fast
On Mon, 2004-07-19 at 14:04, David Storrs wrote:
> Second, I would suggest that it NOT go in a library...this is
> reasonably serious under-the-hood magic and should be integrated into
> the core for efficiency.
You must have amazingly fast hard drives.
-- c
"David Storrs" <[EMAIL PROTECTED]> wrote
># Print file, inefficiently
> print $default.readline for 1..$default.lines;
print it efficiently:
print $default;
> # Append a line
> $rw .= "an additional line\n";
$rw ~= "\n" unless $rw.chars[-1] eq "\n";
$rw ~= "an additional l
"David Storrs" <[EMAIL PROTECTED]> wrote (apparently may days ago):
> Race condition: what if something deletes the file between the moment
> that perl closes the file and the moment that it re-opens it? Is
> there a cross-platform way to do an atomic reopen?
I'm not sure if you need to close it
On Tue, 20 Jul 2004 07.25, Austin Hastings wrote:
> --- Rod Adams <[EMAIL PROTECTED]> wrote:
> > If I cannot open a file for writing (permissions, out of space,
> > write locked, etc), I want to know the instant I attempt to open it
> > as such, _not_ when I later attempt to write to it. Having al
On Mon, Jul 19, 2004 at 03:37:12PM -0500, Rod Adams wrote:
> I think part of the "mental jam" (at least with me), is that the
> read/write, exclusive, etc, are very critical to the act of opening the
> file, not only an after the fact restriction on what I can do later. If
> I cannot open a fil
On Sun, Jul 18, 2004 at 08:39:09PM -0500, Rod Adams wrote:
> Case 1:
> So I wanted to do a read/write scan, so I create my TextFile, start
> reading in data, so the file is opened for reading. Then, I come to the
> part where I want to update something, so I do a write command. Suddenly
> the f
On Sun, Jul 18, 2004 at 05:36:58PM -0700, Dave Whipp wrote:
> truncate Vs append would be infered from usage (assign => truncate). One
> might be able to infer read Vs write in a similar way -- open the file based
> on the first access; re-open it (behind the scenes) if we write it after
> reading
On Sun, 18 Jul 2004, Andrew Shitov wrote:
> DW> my $text is TextFile("/tmp/bar");
> DW> $text = "hello"; # writes, truncates
> DW> $text ~= ", world\n"; # appends
>
> DW> $text.print "again\n"; # for old-times sake
>
> Anyhow we still need $text.flush() or $text.close() methods.
On Mon, Jul 19, 2004 at 07:40:01PM -0500, Rod Adams wrote:
: TMTOWTDI can apply here, I believe. You give me my way, I'll give you
: yours. Leave me open with all my parameters, and you can have your list
: of file abstraction classes. I could see having those classes part of
: core, if there's
Austin Hastings wrote:
--- Rod Adams <[EMAIL PROTECTED]> wrote:
I think part of the "mental jam" (at least with me), is that the
read/write, exclusive, etc, are very critical to the act of opening
the file, not only an after the fact restriction on what I can do
later.
But why? I'd argue
--- Rod Adams <[EMAIL PROTECTED]> wrote:
> Dave Whipp wrote:
>
> >
> > Your case 2 is easy: "my Str $passwds is File("/etc/passwd") is
> > const". With that, we might even catch your error at compile
> > time.
> >
> >>/file/open/ and we're back where we started.
> >
> > Except that we've lost a l
Dave Whipp wrote:
Under the hood, I don't really care, as long as it works (and is
sufficiently efficient). There are obvious implementations that might be a
bit inefficient on the first iteration (e.g. close and reopen). Quite
frankly, the number of times I open unstructured files in rd/wr mode in
"Rod Adams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Case 1:
> So I wanted to do a read/write scan, so I create my TextFile, start
> reading in data, so the file is opened for reading. Then, I come to the
> part where I want to update something, so I do a write command. Suddenl
Dave Whipp wrote:
"Rod Adams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Uhm, my impression was that most of the "huffmanization" discussion was
centered around declaring a file handle to be read only, write only,
read-write, exclusive, etc. Masking the file handle with what bas
"Rod Adams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Uhm, my impression was that most of the "huffmanization" discussion was
> centered around declaring a file handle to be read only, write only,
> read-write, exclusive, etc. Masking the file handle with what basically
> amount
Dave Whipp wrote:
I was thinking about the discussions about the "open" function, and of the
capabilities of "string"s.
Given that we'll have things like $str.bytes, etc. It doesn't seem a stretch
to suggest that we could also have $str.lines. Once we have that, and also a
level of pervasive lazine
"Andrew Shitov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> DW> my $text is TextFile("/tmp/bar");
> DW> $text = "hello"; # writes, truncates
> DW> $text ~= ", world\n"; # appends
>
> DW> $text.print "again\n"; # for old-times sake
>
> Anyhow we still need $text.flush() or
DW> my $text is TextFile("/tmp/bar");
DW> $text = "hello"; # writes, truncates
DW> $text ~= ", world\n"; # appends
DW> $text.print "again\n"; # for old-times sake
Anyhow we still need $text.flush() or $text.close() methods.
--
_
I was thinking about the discussions about the "open" function, and of the
capabilities of "string"s.
Given that we'll have things like $str.bytes, etc. It doesn't seem a stretch
to suggest that we could also have $str.lines. Once we have that, and also a
level of pervasive laziness (lazy evaluati
48 matches
Mail list logo
