Russ Allbery wrote:
> I've fiddled with this before and can do text to HTML; the rest is just a
> question of picking different backends and shouldn't be *too* hard. All
> the heuristics for parsing text are inherently fragile, but if you follow
> a standard text formatting style, it works reaso
"Bradley M. Kuhn" <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> However, I don't think we should dismiss it out of hand because people don't
> do a lot of systems programming C. some of the things we are going to build
> for C (if that's what we pick), are already there
On Thu, Dec 07, 2000 at 01:22:08PM +0100, Roland Giersig wrote:
> How about a two-step requirement?
>
> 1) Native compiler must support ANSI-C.
>
> 2) If 1) doesn't hold, gcc can be required, which fulfills ANSI-C.
strictly and really pedant point no it doesn't quite, as ANSI specifies
the comp
(whoops, correcting my own post!):
> sva->refcount=0;
> sva->refcount++; // these first 2 combined if we get the implemention right
> svb->refcount=0;
> svb->refcount++; // ditto
sva->refcount++;
> ...
> if (--sva->refcount == 0) ... // branch not taken
> if (--svb->refcount == 0) ... // branch
Buddha Buck <[EMAIL PROTECTED]> writes:
> At 03:54 PM 12-06-2000 -0500, Sam Tregar wrote:
> >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
> > >
On Thu, Dec 07, 2000 at 10:54:09AM +, Piers Cawley wrote:
> "Bradley M. Kuhn" <[EMAIL PROTECTED]> writes:
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > 2) GCC produces slow code on all platforms where there's an
> > >alternative.
> >
> > This is likely going to change with the releas
Dan Sugalski wrote:
> I object to targetting GCC specifically for two reasons,
> though, neither of them VMS related:
>
> 1) Targeting a single compiler, no matter whose it is, is a bad idea. We're
> writing in a *language*, not for a compiler. Targeting a specific compiler
> restricts us even m
> There's evidence in the
> literature that switching from reference counting to a more sophisticated
> GC scheme can also save us 5-10% in CPU overhead. (Though that's not a
> guarantee--LISPlike languages likely have different GC performance
> characteristics than perl does)
[warning: vague
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > Dave M wrote:
> >That was probably me. (Which means it was probsbly a daft proposal,
> >and everyone rightly ignored it ;-)
> >The basic idea was that all numeric SV types must provide methods
> >that extract their vlaue as an integer or float of a size
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> print $foo[0];
> is
>foo->get_string[UTF_8](ARRAY, 0);
> while
>print $foo
> is
>foo->get_string[UTF_8](SCALAR);
Just to clarify:
does the get_string method in an AV's vtable do an indexing lookup,
grab the relevant SV pointer, then call
On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > All the math is easy if the scalars are of known types. Addition and
> > multiplication are easy if only one of the scalars involved is of known
> > type. Math with both of unknown type
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > > All the math is easy if the scalars are of known types. Addition and
> > > multiplication are easy if only one of the scalars involved i
At 01:20 PM 12/7/00 +, David Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > print $foo[0];
> > is
> >foo->get_string[UTF_8](ARRAY, 0);
> > while
> >print $foo
> > is
> >foo->get_string[UTF_8](SCALAR);
>
>Just to clarify:
>
>does the get_string method in an AV's
On Thu, Dec 07, 2000 at 11:24:06AM -0500, Dan Sugalski wrote:
> I think I'd just as soon always call DESTROY in a predicable manner and not
> do *anything* perlish at GC time. If nothing else it means that we don't
> have to worry about having a valid perl context handy when the GC runs.
> (Sin
Dan Sugalski <[EMAIL PROTECTED]> writes:
> I think I'd just as soon always call DESTROY in a predicable manner
> and not do *anything* perlish at GC time. If nothing else it means
> that we don't have to worry about having a valid perl context handy
> when the GC runs. (Since threading the thing i
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 01:20 PM 12/7/00 +, David Mitchell wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > print $foo[0];
> > > is
> > >foo->get_string[UTF_8](ARRAY, 0);
> > > while
> > >print $foo
> > > is
> > >foo->get_string[UTF_8](SCALAR);
At 05:55 PM 12/7/00 +, Piers Cawley wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> > I think I'd just as soon always call DESTROY in a predicable manner
> > and not do *anything* perlish at GC time. If nothing else it means
> > that we don't have to worry about having a valid perl context
Piers Cawley wrote:
>
> > And, it will make the barrier for entry for new internals hacker
> > lower.
>
> Err. How do you get to that conclusion? The thing that really stops me
> mucking about with perl's internals is the fiendish complexity of said
> internals. Changing the programming language
On Thu, Dec 07, 2000 at 12:06:36PM +, Nicholas Clark wrote:
> > I think that that would be a 'courageous' decision.
>
> Making decisions now that make it hard to use anything other than 1 compiler
> are as wise as decisions that make it hard to use anything other than one
> implementation lan
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?
> nearly as fast,
Why have nearly as fast, when you can have as fast?
> and WAY WAY
On Wed, Dec 06, 2000 at 03:11:33PM -0500, Dan Sugalski wrote:
> >I'm in favour of the exact opposite: an AV is "just" an SV-alike vtable
> >with array methods instead of scalar methods and a pointer to some
> >storage, (probably an array of SVs) and likewise an HV. That would allow
> >(array->leng
On Thu, Dec 07, 2000 at 12:24:50PM +, David Mitchell wrote:
> In a Perl context, I find it hard to believe that reference counting takes
> up more than tiny fraction of total cycles.
On a vaguely related note, here's the flat profile from gprof run
cumulatively on the test suite. (I haven't
Nicholas Clark wrote:
>
> But fflush(NULL) is, and we still seem to run
> into that one on one current platform
Amazingly, there are still things in supposedly ANSI-conformant
implementations that are done wrong. free(0) is supposed to be
a safe no-op; but on certain compilers, we get a crash.
> often. What the *hell* is wrong with modulo?
It does sort of stand out, doesn't it...floating point divide?
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
At 02:01 PM 12/7/00 +, David Mitchell wrote:
>Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
> > > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > > All the math is easy if the scalars are of known types. Addition and
> > > > mul
At 11:17 AM 12/7/00 +, Piers Cawley wrote:
>Buddha Buck <[EMAIL PROTECTED]> writes:
> > It seems to me that there are three types of thingies[1] we are
> > concerned about, conceptually:
> >
> >
> > A) Thingies with no DESTROY considerations, which don't need refcounts.
> > B) Thingies with DE
On Wed, Dec 06, 2000 at 08:28:14PM -0500, Bradley M. Kuhn wrote:
> Whether or not it is slow is not my concern.
Speed isn't (necessarily) the problem, although I'd prefer it if Perl wasn't
slow. *Size* is the problem. On-the-fly evaluation requires a compiler and its
associated environment, and t
On Thu, Dec 07, 2000 at 02:33:53PM -0500, John Porter wrote:
> 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?
>
> I don't know. Sounds reasonable! :-)
>
> Aside from lam
On Thu, Dec 07, 2000 at 02:33:53PM -0500, John Porter wrote:
> I'd say, screw 'em if they don't have a C++ compiler.
No.
--
"The best index to a person's character is a) how he treats people who can't
do him any good and b) how he treats people who can't fight back."
-- Abigail Van Buren
On Thu, Dec 07, 2000 at 07:42:26PM +, Nicholas Clark wrote:
> What was Sapphire's implementation language? What were its lessons?
See http://www.perl.com/pub/2000/09/sapphire.html
--
Hildebrant's Principle:
If you don't know where you are going, any road will get you there.
Jarkko Hietaniemi wrote:
>
> You seem hell-bent to gain popularity and support, don't you.
Do I? "Hell-bent"?
When it comes right down to it, the likelihood that I personally
will contribute to the core is vanishingly small, regardless of
language. So, I guess you can defend your own choice o
On Thu, Dec 07, 2000 at 03:40:37PM -0500, John Porter wrote:
> When it comes right down to it, the likelihood that I personally
> will contribute to the core is vanishingly small, regardless of
> language.
Great. When it comes down to it, what are you doing here?
> I wonder: In what order will
Simon Cozens wrote:
>
> Great. When it comes down to it, what are you doing here?
Excellent question.
--
John Porter
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?
I don't know. Sounds reasonable! :-)
Aside from lame-o solutions like C-front and cross-compiling,
I'd say, screw 'em if they don't ha
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, Dec 07, 2000 at 02:33:53PM -0500, John Porter wrote:
> 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?
>
> I don't know. Sounds reasonable! :-)
What did Chip lear
Sam Tregar wrote:
>
> Which also brings up another point - choosing anything but C is likely to
> have a direct impact on our existing userbase. I have a suggestion - if a
> system compiled and ran Perl 5 then it should be able to compile and run
> Perl 6. No upgrades required.
The Backwards C
On Thu, Dec 07, 2000 at 10:23:55PM -0500, Bradley M. Kuhn wrote:
> > > > At 07:49 AM 12/6/00 -0800, Daniel Chetlin wrote:
> > > > >Simply deciding that `eval STRING' is "unimplemented" on these
> > > > >theoretical ports and binary compiles is the best idea I've heard yet,
> > > > >but we should r
Simon Cozens <[EMAIL PROTECTED]> wrote:
> It seems like everyone has their axes to grind on this one: Bradley thinks
> the world must be built in Java,
I don't believe that. There has been a misunderstanding, and I apologize if
I didn't communicate that effectively.
I don't really care *that*
John Porter <[EMAIL PROTECTED]> wrote:
> Almost. You're potentially taking away Perl6, which is vaporware.
> I wonder: In what order will the following exist on Handheld Device
> Foo:
>
> - C
> - C++
> - Java
> - Perl6
I know of at least one hand-held on the market (Po
On Thu, Dec 07, 2000 at 10:23:55PM -0500, Bradley M. Kuhn wrote:
> However, the JVM is a powerful environment for generalized bytecode and for
> allowing bytecode of different languages to communicate.
So's Microsoft vaporware ".NET platform". And the second version
of that bytecoded runtime wi
At 07:02 PM 12/7/00 +, Simon Cozens wrote:
>On Wed, Dec 06, 2000 at 03:11:33PM -0500, Dan Sugalski wrote:
> > >I'm in favour of the exact opposite: an AV is "just" an SV-alike vtable
> > >with array methods instead of scalar methods and a pointer to some
> > >storage, (probably an array of SVs
I would like to do this, but I think its a bigger job than you imagine, and...
"I tend towards insanity from time to time. Good thing its only perl." (you can
quote me)
(It comes from stresses developing sysadm apps around the single largest depository of
human wealth. They actually smoth
> On Wed, 6 Dec 2000, Bradley M. Kuhn wrote:
>
> > And, it will make the barrier for entry for new internals hacker lower.
Sam Tregar <[EMAIL PROTECTED]> wrote:
> Really? Do you honestly believe there are more Java programmers than C
> programmers? Particularily in the Perl development commu
> > > At 07:49 AM 12/6/00 -0800, Daniel Chetlin wrote:
> > > >Simply deciding that `eval STRING' is "unimplemented" on these
> > > >theoretical ports and binary compiles is the best idea I've heard yet,
> > > >but we should remember that `require' is built on `eval STRING'.
> On Wed, Dec 06, 2000
At 10:46 PM 12/7/00 -0500, Bradley M. Kuhn wrote:
>John Porter <[EMAIL PROTECTED]> wrote:
>
> > Almost. You're potentially taking away Perl6, which is vaporware.
> > I wonder: In what order will the following exist on Handheld Device
> > Foo:
> >
> > - C
> > - C++
> > - Java
> >
At 06:01 PM 12/7/00 +, Piers Cawley wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> > At 01:20 PM 12/7/00 +, David Mitchell wrote:
> > >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > >
> > > > print $foo[0];
> > > > is
> > > >foo->get_string[UTF_8](ARRAY, 0);
> > > > while
> > > >
47 matches
Mail list logo
