Jarkko Hietaniemi wrote:
Umm, one way or another I suspect UTF-8 will be in there.
I suspect so too but very grudgingly. As Dan said dealing with
variable length data is a major pain. UTF-8 is certainly a much
better designed VLD than most but it's still a pain.
I guess that's why
On Fri, Feb 09, 2001 at 10:28:49AM -0200, Branden wrote:
In http://www.w3.org/TR/NOTE-OSD.html#B they describe platform/cpu standard
names, and we'll definetly need those for checking target architecture. Can
we standardize upon those, or there's something missing? There's an issue
I take it
I wrote:
David L. Nicol wrote:
sub DirectBubbleSort() {
my ($i,$t) = (-1,0);
while (++$i = $#$__) {
$$__[$i] $$__[1+$i] and $t++ and @$__[$i,1+$i] = @$__[1+$i,$i];
};
$t and @$__ = DirectBubbleSort;
}
@SomeList = DirectBubbleSort; # instead of
Nicholas Clark wrote:
I take it "Lunix" is Linux.
BSDi isn't FreeBSD, NetBSD or OpenBSD
Nothing they list seems to be VMS
Pace are still developing variants of Acorn's RISC OS to run set top boxes
As I understood it there were about 39 variants of Unix ever, and they
seem
to have 12 listed.
Does everyone already know about www.kx.com ?
--
May the best description of competition prevail.
(via, but not speaking for Deutsche Bank)
At 09:36 AM 2/9/2001 -0500, Joshua N Pritikin wrote:
Does everyone already know about www.kx.com ?
What about it? Looks like yet another semi-specialized relational database
company. (With a far too clever website)
Dan
On Fri, Feb 09, 2001 at 10:16:22AM -0500, [EMAIL PROTECTED] wrote:
At 09:36 AM 2/9/2001 -0500, Joshua N Pritikin wrote:
Does everyone already know about www.kx.com ?
What about it? Looks like yet another semi-specialized relational database
company. (With a far too clever website)
Am i
Joshua N Pritikin wrote:
On Fri, Feb 09, 2001 at 10:16:22AM -0500, [EMAIL PROTECTED] wrote:
At 09:36 AM 2/9/2001 -0500, Joshua N Pritikin wrote:
Does everyone already know about www.kx.com ?
What about it? Looks like yet another semi-specialized relational
database
company. (With a far
On Fri, Feb 09, 2001 at 10:28:49AM -0200, Branden wrote:
Other important issue I don't know yet: Is there an Archive::Zip module for
Perl? How cross-platform is it? Can we bundle it with Perl (licensing
issues)? Is it stable? Will it give us the support we need (access to
individual files in
Self-referencing definitions - it's a bit like time travel.
This was originally submitted back in December, but I never saw it show up,
and didn't see it in the archives, so I'm going to throw it to the meta
list for hacking before there are a slew of PDDs floating around.
(I'm withholding the
Joshua N Pritikin wrote:
On Fri, Feb 09, 2001 at 01:51:02PM -0200, [EMAIL PROTECTED] wrote:
Well, I found Kdb nothing awesome... The K language I thought it's a
somewhat interesting, specially the part on "bulk operators", which I
think
is the same that is intended to do with Perl 6 arrays
On Fri, Feb 09, 2001 at 01:51:02PM -0200, [EMAIL PROTECTED] wrote:
Joshua N Pritikin wrote:
Does everyone already know about www.kx.com ?
Well, I found Kdb nothing awesome... The K language I thought it's a
somewhat interesting, specially the part on "bulk operators", which I think
is the
At 10:49 AM 2/9/2001 -0500, Joshua N Pritikin wrote:
On Fri, Feb 09, 2001 at 10:16:22AM -0500, [EMAIL PROTECTED] wrote:
At 09:36 AM 2/9/2001 -0500, Joshua N Pritikin wrote:
Does everyone already know about www.kx.com ?
What about it? Looks like yet another semi-specialized relational
On Fri, Feb 09, 2001 at 02:13:46PM -0200, [EMAIL PROTECTED] wrote:
Joshua N Pritikin wrote:
Well yah! Perl6 array indeed. It also reminds me of PDL. i like the
data model. It looks like FAME done right.
Are you suggesting we borrow some features of it? Take some inspiration on
it to
This is the alpha version of the PDD about archives. I actually didn't have
the time to format it as a POD, and probably won't have the time to do it
until Monday, I don't even think I'll have time to check the lists on the
weekend. Nevertheless, I'm sending it on mail-message format for your
Joshua N Pritikin wrote:
On Fri, Feb 09, 2001 at 02:13:46PM -0200, [EMAIL PROTECTED] wrote:
Could you be more specific about your intents about that language? Do
you
have more information about it (some interesting syntax, or some scripts
that could inspire new features or interesting
Dan Sugalski wrote:
At 12:06 PM 2/9/2001 -0500, Ken Fox wrote:
2. Work proportional to live data, not total data. This is hard to
believe for a C programmer, but good garbage collectors don't have
to "free" every allocation -- they just have to preserve the live,
or
On Fri, Feb 09, 2001 at 01:19:36PM -0500, Dan Sugalski wrote:
The less memory you chew through the faster your code will probably be (or
at least you'll have less overhead). Reuse is generally faster and less
resource-intensive than recycling. What's true for tin cans is true for memory.
David L. Nicol wrote:
We're having a blizzard in Kansas City. After breakfasting, changing
the litter box, and hiking to work through the snow, I am finally
looking at Conway's RFC 271. Guess which one of the earlier
activites it reminds me of.
I'm in really doubt... Breakfasting? ;-)
On Fri, Feb 09, 2001 at 12:06:12PM -0500, Ken Fox wrote:
2. Work proportional to live data, not total data. This is hard to
believe for a C programmer, but good garbage collectors don't have
to "free" every allocation -- they just have to preserve the live,
or reachable, data.
Johan Vromans wrote:
Would the POST be executed if the open fails? Why? Why not?
sub readit {
POST {
close F;
}
open F, " $f" or die;
scalar(F)
}
Yes, because the flow of control passed it before the
On Fri, Feb 09, 2001 at 06:46:26PM -0200, Branden wrote:
Jarkko Hietaniemi wrote:
Whatever we do I would much prefer being package format agnostic
instead of tying ourselves too tightly with some single format.
Any ideas on how to do that? Without breaking requirements?
There isn't a
[EMAIL PROTECTED] wrote:
So, it's more a data preserver than a garbage collector ;-)
Abigail
I find it odd that perl mallocs each string individually, for instance;
I had thought that it would only malloc massive pieces and do its own
allocation and freeing of it. Its laziness, of
I had the time to do a research in Internet about rpm/jar. The correct URLs
are:
* http://www.rpm.org
* http://java.sun.com/products/jdk/1.1/docs/guide/jar/
I found great utilitaries in http://www.rpm.org/software.html, we could
probably steal some of them for `par'. I found out that most of
Jarkko Hietaniemi wrote:
(for those of you who didn't get the reference)
Well, I certainly heard the reference before even hearing of Perl or Tom...
I only ever saw it with his name on it.
So if he didn't coin it, then I think he "appropriated" it...
--
John Porter
Branden wrote:
Ken Fox wrote:
Some researchers have estimated that 90% or
more of all allocated data dies (becomes unreachable) before the
next collection. A ref count system has to work on every object,
but smarter collectors only work on 10% of the objects.
Does this 90/10 ratio
Jarkko Hietaniemi wrote:
There isn't a software problem another abstraction layer can't fix...
"...except the problem of too many layers of abstraction". tchrist
(for those of you who didn't get the reference)
--
John Porter
At 11:32 AM 2/9/2001 -0200, Branden wrote:
Nicholas Clark wrote:
that I really don't know: in the same platform, different compilers
generate
incompatible binaries? Because if this happens (and will still happen
on
Perl 6) the platform identification should be os/cpu/compiler. Perhaps
At 09:42 AM 2/9/2001 +, Michael G Schwern wrote:
On Thu, Feb 08, 2001 at 01:40:52PM -0500, Dan Sugalski wrote:
Seperated documentation is no documentation.
At some point things are going to get split out, unless you wedge the docs
into the actual program itself. (You were, after all,
On Fri, Feb 09, 2001 at 09:22:13PM +, Nicholas Clark wrote:
On Fri, Feb 09, 2001 at 02:53:43PM -0600, Jarkko Hietaniemi wrote:
On Fri, Feb 09, 2001 at 06:46:26PM -0200, Branden wrote:
problems (like `oh! I don't have bzip2 and the developper only supplied a
bzip2 version of the
At 06:30 PM 2/9/2001 +, Nicholas Clark wrote:
On Fri, Feb 09, 2001 at 01:19:36PM -0500, Dan Sugalski wrote:
The less memory you chew through the faster your code will probably be (or
at least you'll have less overhead). Reuse is generally faster and less
resource-intensive than
On Fri, Feb 09, 2001 at 09:22:13PM +, Nicholas Clark wrote:
Code to do unzip (yes, even including the whole of zlib just like gcc,
xfree86 and several other things I can't remember offhand that irritate
me as I have libz.so) is small enough to go in the perl core if needed.
Even after
At 07:06 PM 2/9/2001 +, Simon Cozens wrote:
Perl's internals are notoriously grubby; it's been understood for years
that
the language's implementation needs to be rewritten from scratch, but an
attempt in 1999 failed and another seems presently stalled.
If that other is Perl 6, I
At 04:53 PM 2/9/2001 -0500, Ken Fox wrote:
Dan Sugalski wrote:
At 04:09 PM 2/9/2001 -0200, Branden wrote:
If I change the way some objects are used so
that I tend to create other objects instead of reusing the old ones, I'm
actually not degrading GC performance, since its work is
"David L. Nicol" wrote:
# with POST
sub find_first_line_matching_array($\@){
open F, shift or die "could not open: $!";
POST{close F};
while(F){
foreach $w (@{$_[0]}){
On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
That may work for C, but not for Perl.
sub test {
my($foo, $bar, %baz);
...
return \%baz;
}
You may notice that only PART of the locally malloced memory, gets
freed. the memory of %baz
On Fri, Feb 09, 2001 at 06:17:19PM -0500, Eric S. Raymond wrote:
The obvious and cutting rejoinder for me to make would be:
"Hey. If I believed this, I'd still be writing Perl."
Don't look now, but your bias is showing. :)
What *is* going on over there, anyway? It is unfortunately
37 matches
Mail list logo
