:
M S17-concurrency.pod
Log Message:
---
clarify why more/done distinction in winner works
more only makes sense on on channels, while done only works on promises, and
hence will happily autocoerce a channel to its 'done' promise.
2013)
Changed paths:
M S12-objects.pod
Log Message:
---
.WHY is specced now.
Matthew Walton wrote:
If a user of your API contrives to make it change while you're
running, that's their own foot they've just shot, because they can
look at the signature and know the semantics of the parameter
passing being used and know that if they change the value externally
On Fri, 19 Jun 2009, Martin D Kealey wrote:
To that end I would propose that:
- parameters should be read-only AND invariant by default, and
- that invariance should be enforced passing a deep immutable clone
(*5) in place of any object that isn't already immutable.
Sorry, typo: that
and know that if they change the value externally before
you return Bad Things Could Happen.
I agree that the caller is responsible for the constness of the value
he gives to a function. With this we get the best performance. I don't
understand why John thinks that an intermediate proxy is needed
before
you return Bad Things Could Happen.
I agree that the caller is responsible for the constness of the value
he gives to a function. With this we get the best performance. I don't
understand why John thinks that an intermediate proxy is needed. A very
shallow wrapper that ensures the readonlyness
that it is useful for plural containers. We don't want to
copy them! But for items, why do we not even _have_ pass by value? The
compiler must assume the worst and can't optimize as well.
'is copy' is pass-by-value... remember everything in Perl 6 is a
reference, of sorts. Pass-by-value
that it is useful for plural containers. We don't want to
copy them! But for items, why do we not even _have_ pass by value? The
compiler must assume the worst and can't optimize as well.
'is copy' is pass-by-value... remember everything in Perl 6 is a
reference, of sorts. Pass-by-value
? And if so, why does that preclude having the simple
pass-by-value method available also?
From the typical Perl 5 usage, I would think that pass-by-value should
be the default.
--John
Em Dom, 2009-06-14 às 15:53 -0500, John M. Dlugosz escreveu:
In Perl 6, the default parameter passing is to make a read-only alias
for the caller's lvalue. This means that the function may not change
the caller's variable, but must track changes to it made by other means.
What is the point?
meaning, not whether it is considered simple.
Since then, I see that it is useful for plural containers. We don't
want to copy them! But for items, why do we not even _have_ pass by
value? The compiler must assume the worst and can't optimize as well.
--John
On 2008-Dec-4, at 3:08 pm, Mark J. Reed wrote:
Using div instead of / should make it pretty clear that you're
disposing of the remainder.
I misremembered div vs. idiv, but how standard is it? I know div
commonly means int division, but not always. On the one hand, some
things you just
On Fri, Dec 5, 2008 at 9:10 AM, David Green [EMAIL PROTECTED] wrote:
I misremembered div vs. idiv, but how standard is it? I know div commonly
means int division, but not always.
True enough. In ANSI C, / already does integer division, but there's
also a div() function - the difference there
HaloO,
Mark J. Reed wrote:
Well, respelling it is OK, just not sure how. Python 3 uses // for
integer division, but we don't want to open up that can of worms
again..
We still haven't used '÷' which is Latin1. But if we use that it
should be as infix:÷:(Int, Int -- Rat) because this doesn't
HaloO,
David Green wrote:
On 2008-Dec-4, at 3:08 pm, Mark J. Reed wrote:
Using div instead of / should make it pretty clear that you're
disposing of the remainder.
I strongly agree to that. Actually you are disposing of the
fractional part.
I misremembered div vs. idiv, but how standard
with floor semantics as the default. This is now not the case
anymore. Why?
Isn't the special handling of integer division by infix:/ enough?
There the result becomes a Num only if needed such that it preserves
precision as long as possible. Question: does such a 'Num but Rat' type
dispatch
On 2008-Dec-4, at 9:42 am, TSa wrote:
I remember the state of affairs being that [div] returns an Int
Something more explicit like idiv was suggested for integral
division. Personally, I'm happy not to have anything special provided
for it, on the grounds that having to say, e.g.
On Thu, Dec 4, 2008 at 3:26 PM, David Green [EMAIL PROTECTED] wrote:
Something more explicit like idiv was suggested for integral division.
Personally, I'm happy not to have anything special provided for it, on the
grounds that having to say, e.g. floor($i/$j), forces you to be blatantly
, which is where I believe we should be aiming, I think I'd put
rw and read-only. I'm not entirely sure why. Maybe
psychologically, ro looks like it could be a word, whereas the
unpronounceable rw has to be an abbreviation? Or maybe it's just
because I see rw every day in ls output, but ro not so
.
But the problem with Java isn't just that it's too verbose to write;
it's that it's too verbose to read, too. Why shouldn't your editor
help with verbosity? The amount of typing shouldn't be a main concern
in language design, because your editor can mostly compensate for
that; there are other, better
On 2008 Sep 24, at 17:45, David Green wrote:
On 2008-Sep-23, at 5:27 pm, Michael G Schwern wrote:
David Green wrote:
Happily, brevity often aids clarity. The rest of the time, it
should be up to one's editor; any editor worth its salt ought to
easily auto-complete ro into readonly.
Eeep!
John M. Dlugosz wrote:
I'm not opposed to having it be ro, but wonder why he didn't call it that
in the first place, so there must be a reason.
Nobody's perfect?
My other thought is that since parameters are read-only by default it's not
thought you'd have to write it much so clarity wins out
On 2008-Sep-23, at 2:32 pm, Michael G Schwern wrote:
My other thought is that since parameters are read-only by default
it's not
thought you'd have to write it much so clarity wins out over
brevity, the flip
side of Huffamn encoding. But that doesn't work out so good for
normal
variable
David Green wrote:
On 2008-Sep-23, at 2:32 pm, Michael G Schwern wrote:
My other thought is that since parameters are read-only by default
it's not
thought you'd have to write it much so clarity wins out over brevity,
the flip
side of Huffamn encoding. But that doesn't work out so good for
Michael G Schwern schwern-at-pobox.com |Perl 6| wrote:
It should be possible to alias it in your own scope easily.
Every time someone replies to a Perl 6 language design nit with but you can
change the grammar *I* kill a kitten.
*meowmmmf*
That would not be a change in the
Michael G Schwern schwern-at-pobox.com |Perl 6| wrote:
John M. Dlugosz wrote:
I'm not opposed to having it be ro, but wonder why he didn't call it that
in the first place, so there must be a reason.
Nobody's perfect?
My other thought is that since parameters are read-only by default
On 2008 Aug 8, at 23:12, John M. Dlugosz wrote:
Brandon S. Allbery KF8NH allbery-at-ece.cmu.edu |Perl 6| wrote:
On 2008 Aug 8, at 23:06, John M. Dlugosz wrote:
Why is 3;3;3 a list of captures rather than a list of lists?
IIRC it has to do with providing enough information for slices
Why is 3;3;3 a list of captures rather than a list of lists?
--John
Brandon S. Allbery KF8NH allbery-at-ece.cmu.edu |Perl 6| wrote:
On 2008 Aug 8, at 23:06, John M. Dlugosz wrote:
Why is 3;3;3 a list of captures rather than a list of lists?
IIRC it has to do with providing enough information for slices and/or *
to work in multiple dimensions.
So how
Jonathan Lang wrote:
Close. I'm thinking added functionality for semicolon alternatives
rather than the replace the semicolon stunt that Semi::Semicolons
pulls. In particular, as long as there's no ambiguity between
prefix:? and postfix:?, I think that it would be quite useful for
postfix:?
On 5/15/07, Dave Whipp [EMAIL PROTECTED] wrote:
A slightly tangental thought: is the behavior of Cgiven with no block
defined? I.e. is
given $foo { when 1 {...} };
equivalent to
given $foo;
when 1 {...};
Doubtful.
However, I do think that it's useful to be able to treat the rest of
the
On Tue, May 15, 2007 at 11:59:35AM -0700, Dave Whipp wrote:
: Jonathan Lang wrote:
:
: Close. I'm thinking added functionality for semicolon alternatives
: rather than the replace the semicolon stunt that Semi::Semicolons
: pulls. In particular, as long as there's no ambiguity between
:
On Tue, May 15, 2007 at 01:14:44PM -0600, Luke Palmer wrote:
However, I do think that it's useful to be able to treat the rest of
the current scope as a block (usually with a parameter), for certain
kinds of closure-heavy code.
Maybe this is a case for one of Mr. Lang's custom semicolons with
Larry Wall wrote:
Dave Whipp wrote:
: A slightly tangental thought: is the behavior of Cgiven with no block
: defined? I.e. is
It would be illegal syntax currently.
As I understand it, the proposal is to say that if the parser finds a
';' where it was expecting to find a control block, it
Hi everyone,
I don't want to argue about the design of perl6[1], I just wonder: why
the semicolon is still needed in the end of lines in perl6?
I can think of different reasons (history, readability, easier parsing
of multiline statements, force people to write one-line functions to
avoid
I don't want to argue about the design of perl6[1], I just wonder: why
the semicolon is still needed in the end of lines in perl6?
JavaScript allows to omit semicolumn. In lecture at Yahoo's YUI
Theatre one of JS's gurus talked about how it is organized in
JavaScript parser.
If the line
JavaScript allows to omit semicolumn.
Sorry, s/lumn/lon/.
By the way, Perl also ignors semicolumn :-)
--
Andrew Shitov
__
[EMAIL PROTECTED] | http://www.shitov.ru
On Mon, May 14, 2007 at 07:05:01PM +0200, gabriele renzi wrote:
: Hi everyone,
:
: I don't want to argue about the design of perl6[1], I just wonder: why
: the semicolon is still needed in the end of lines in perl6?
:
: I can think of different reasons (history, readability, easier parsing
On 5/14/07, Andrew Shitov [EMAIL PROTECTED] wrote:
JavaScript allows to omit semicolumn.
Speaking of JavaScript, any experienced JavaScript programmer will
tell you that while semi-colons are in fact optional, you should
always treat them as mandatory, to avoid subtle errors creeping into
your
gabriele renzi wrote:
Hi everyone,
I don't want to argue about the design of perl6, I just wonder: why
the semicolon is still needed in the end of lines in perl6?
It isn't - sometimes. S03 identifies a number of ways that an
expression can be terminated: the semicolon (';'), a block-final
Aankhen wrote:
Speaking of JavaScript, any experienced JavaScript programmer will
tell you that while semi-colons are in fact optional, you should
always treat them as mandatory, to avoid subtle errors creeping into
your code.
We should also note that the idea of omitting ';' is not as
Jonathan Lang wrote:
^[3]: If this were included in the core, you might even reverse things
so that ';' is defined in terms of postfix:. or infix:{'=='},
depending on the context; in this case, postfix:? would be defined
in terms of postfix:., rather than postfix:;. In fact, the only
thing
On Mon, May 14, 2007 at 02:29:11PM -0700, Jonathan Lang wrote:
2. This brings up the possibility of custom-designed termination
operators.
cf. Semi::Semicolons. I think that being flexible enough that people can
write packages like that is one of Perl 6's greatest strengths.
Long may it
Andrew Shitov:
If the line of code is not ended with ';' the parser tries first
to assume [..]
Wouldn't that be unambigous?
foo = 23
bar = \
42
?
I think there would be no ambiguities and you only had to add additional
syntax for the rare cases instead of the common cases.
--
\ to join unterminated lines you just get more
ugliness than having semicolons. It's also, in many cases,
harder to edit - that's why a trailing comma in a list that
is surrounded by parens, or a trailing semicolon in a block
surrounded by braces, is easier to manage. The syntax of
the last element
John Macdonald schrieb:
It's also, in many cases,
harder to edit - that's why a trailing comma in a list that
is surrounded by parens, or a trailing semicolon in a block
surrounded by braces, is easier to manage.
Now that the list is surrounded by parens makes clear that it ends
On 5/14/07, Daniel Hulme [EMAIL PROTECTED] wrote:
On Mon, May 14, 2007 at 02:29:11PM -0700, Jonathan Lang wrote:
2. This brings up the possibility of custom-designed termination
operators.
cf. Semi::Semicolons.
Close. I'm thinking added functionality for semicolon alternatives
rather than
On Tue, May 15, 2007 at 02:02:06AM +0200, Thomas Wittek wrote:
John Macdonald schrieb:
It's also, in many cases,
harder to edit - that's why a trailing comma in a list that
is surrounded by parens, or a trailing semicolon in a block
surrounded by braces, is easier to manage.
Now
HaloO,
I wrote:
This depends on the partial order of parameter types of the
candidates. Note that this order is rooted at the actual argument
type.
I don't know if the following is obvious but I want to rant about it ;)
This partial order of the parameter types is in the case of a readonly
can the number of
steps be important? Consider one chain Foo -- Bar -- Baz and
one Blahh -- Baz. Why should the second be more specific? In
the end the type system has to decide if Foo or Blahh is more
specific with respect to Baz or if they are incomparable. This
depends on the partial order
While I agree with most of the changes made to the s[]... notation,
there's one oddity that I just spotted:
S05 says:
This is not a normal assigment, since the right side is
evaluated each time the substitution matches (much like the
pseudo-assignment to declarators can happen at strange
On Wed, Oct 11, 2006 at 05:55:45PM -0700, Jonathan Lang wrote:
: While I agree with most of the changes made to the s[]... notation,
: there's one oddity that I just spotted:
:
: S05 says:
: This is not a normal assigment, since the right side is
: evaluated each time the substitution matches
On Wed, Oct 11, 2006 at 06:29:00PM -0700, Larry Wall wrote:
: s:s:g[, (\w+): (.+) ,] = - $key, $val { $key = $val }.(@())
Hmm, that won't work, since @() is a single argument. It'd have to be one of:
s:s:g[, (\w+): (.+) ,] = - [$key, $val] { $key = $val }.(@())
s:s:g[, (\w+): (.+) ,]
In short, nearly every case where I'm looking to use a raw closure
can be handled almost as easily by prefacing it with Cdo (if the
block doesn't take parameters) or Cdo given (if it does). A bit
more wordy than I'd like, but acceptable; it still reads well.
Although I'd recommend pointing this
of the
rule would be:
rule parameter_list { parameter [ , parameter ]* }
Is there a strong reason (ambiguity) why every nonterminal needs to be
quoted (or could we at least have a form ( C rule:y {...} ) where
they are not)? I see this as increasingly important when rules are used
to process non
Audrey Tang wrote:
Hm, Perl 6 actually has two different ways of putting Capture to some
Code object... Following yesterday's P6AST draft I'll call them Call and
Apply respectively:
moose($obj: 1, 2); # this is Call
moose.($obj: 1, 2); # this is Apply
elk(named =
Dave Whipp wrote:
Also, I'm a bit confused By the idea that the invocant is obtained by a
scalar dereference, because I know that arrays and hashes can be
invocants, too. E.g. @a.pop. So, If I do:
my $args = \(@a:);
my $b = $$args; # @a as a scalar
my @c = @$args; # empty list
Reading about capture objects, I see that they represent an arglist, and
the the object to which you going to send those args. What is doesn't
capture is the method name (the verb) that's being called. This feels
like a slightly strange ommission.
Compare:
$message = Shape::draw.prebind(
Dave Whipp wrote:
Perhaps I'm not fully groking the abstraction of the capture-object, but
it seems to me that there should be a slot in it for the method. For
dispatch, all three things are needed (invocant, method, args); so if
you're going to put two of them in one object, then maybe the
On Mon, Mar 20, 2006 at 01:26:03PM +0100, TSa wrote:
: HaloO,
:
: S03 does explicitly disallow auto-reversed ranges.
: And I'm not sure if the upto operator has a downto
: cousin where ^-4 == (-1, -2, -3, -4) returns a list
: that is suitable for indexing an array from the back.
: Why is that so
HaloO,
S03 does explicitly disallow auto-reversed ranges.
And I'm not sure if the upto operator has a downto
cousin where ^-4 == (-1, -2, -3, -4) returns a list
that is suitable for indexing an array from the back.
Why is that so?
With negative ranges, negative array and list length
becomes
Foo::bar with empty @_
say $foo.data; # prints 23
For most of that, doesn't a private method suffice?
When it doesn't, I feel uneasy about:
class Foo {
submethod bar() { ... }
}
my $foo = Foo.new;
$foo.bar;
If that's externally sub-like, why does it look so much like
DC == Damian Conway [EMAIL PROTECTED] writes:
DC But factoring method implementations out into a subroutines is
DC also extremely annoying, because a subroutine doesn't provide the
DC internal conveniences that a method does. In particular, it
DC doesn't have an invocant and so you can't
the same basic principle relate to
classes and submethods. If marked as such, a submethod is required to
be implemented by a subclass, or class composition fails.
I think that could be a useful feature which would allow very safe
re-use along those lines.
Good point, which is why the is required
In his use.perl.org journal, Luke wrote:
To be fair, Damian responded to my query, but he didn't answer my
question. He gave more an example of how submethods are used, rather
than why they are used.
Subroutines are useful inside classes, for factoring class-specific
implementation details
this useful construct a submethod.
Hmm, thanks.
For most of that, doesn't a private method suffice?
When it doesn't, I feel uneasy about:
class Foo {
submethod bar() { ... }
}
my $foo = Foo.new;
$foo.bar;
If that's externally sub-like, why does it look so much like a method
+1;
}
}
Foo.new.process_data(0); # 1
class Bar is Foo { }
Bar.new.process_data(0); # dies[1]
What??? I didn't change anything yet! Why does it die? (This is the
first principle in the journal entry you quoted)
This is true, but I think that it is easily
I am currently failing to see the need for a distinction between $.
and $: . The only difference is in whether accessors are *generated*;
the attribute access itself is no different. If you want to refactor
and turn your auto-accessor into a custom one, you have to[1] go
replace $. with $:
On Mon, 2005-05-16 at 04:02 -0600, Luke Palmer wrote:
I am currently failing to see the need for a distinction between $.
and $: . The only difference is in whether accessors are *generated*;
Not at all! There are numerous differences as described in A12:
* The attribute gets a private
Pardon if this has already come up. I only found one prior reference in
my search.
There's a section in S5 about Matching against non-strings, but it
really only addresses matching against strings that are retrieved
dynamically from tied values.
Some operations in a rule operate on string
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 strict;
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 sure
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 NOT
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
include most of these, even in a trimmed down release, such
: : as an OS installer
: :
: : What most venders will ship.
:
: Which is basically why we are planning not to produce one of these.
: I think we should concentrate on 1 and 3.
:
: I know. In that case, I think venders are liable
. That's why we're going to distribute close to nothing
with Perl 6 in order to force vendors to install a decent module suite.
It's likely that CPAN will have a Bundle::EYEWTIBWATA. [1]
Well, it certainly makes sense to me to have perl itself as
minimal as possible, as long as there's an official
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
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.
Oh,
out of a user's home directory in a
production environment.
I know this isn't a new problem, but it is why I didn't use Net::FTP at
work until about a year ago. They just didn't install the bugger and I
didn't have control of the site image. The same goes for perl5.6 for
that matter, so I might
:
: What most venders will ship.
Which is basically why we are planning not to produce one of these.
I think we should concentrate on 1 and 3.
Larry
installer
:
: What most venders will ship.
Which is basically why we are planning not to produce one of these.
I think we should concentrate on 1 and 3.
I know. In that case, I think venders are liable to be lazy or peeved
and ship option 1 or worse, nothing. Is the answer really supposed
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 installed,
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,
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.
Security
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
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
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 pretty big
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 think
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 it.
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 file
, not Open a file, and then
apply these specifications to it.
I do admit there is merit to your abstraction system, but IMO, it
belongs in a library.
-- Rod Adams
First, why are they incompatible? Offer both, let TIMTOWTDI sort it
out.
Second, I would suggest that it NOT go in a library
these features available to open as arguements seems a much better
idea to me. It's Open a file with these specifications, not Open
a file, and then apply these specifications to it.
But why? Do you really open files and then perform an hour of work
before attempting to use them? I'll argue
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 before
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 line\n;
#
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
--- 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 hard
- 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 into
the core
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 magic and should
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 magic and should
1 - 100 of 245 matches
Mail list logo
