Re: RFC 334 (v1) I'm {STILL} trying to understand this...

[Dan Sugalski]

At 11:21 PM 10/12/00 -0400, John Porter wrote:
>Jarkko Hietaniemi wrote:
> > On Thu, Oct 12, 2000 at 10:55:52PM -0400, John Porter wrote:
> > >
> > > I don't think it's that big a deal.  Easy enough to wrap in a macro.
> >
> > I thought (hoped) that the plan was the avoid the cpp like the plague
> > and cancer it is.
>
>Well, yes, definitely; but we're just adding an argument to the front
>of the arg list.  Is that so bad?

Yes, it is.

Extra arguments cost. It's not free to pass them in by any means--you can 
see hits up to 10% in some extreme cases. If the arguments are used it's 
one thing, but if they're dummy (as they would be in those cases where the 
indirect routine you're calling *isn't* a perl one) then that cost can 
really add up.

CPP won't help us either, since we'll be calling these routines indirectly, 
via a function pointer in C. There's no way we can reasonably get CPP 
involved, even if we wanted to.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

[John Porter]

Jarkko Hietaniemi wrote:
> On Thu, Oct 12, 2000 at 10:55:52PM -0400, John Porter wrote:
> > 
> > I don't think it's that big a deal.  Easy enough to wrap in a macro.
> 
> I thought (hoped) that the plan was the avoid the cpp like the plague
> and cancer it is.  

Well, yes, definitely; but we're just adding an argument to the front
of the arg list.  Is that so bad?

-- 
John Porter

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

[Jarkko Hietaniemi]

On Thu, Oct 12, 2000 at 10:55:52PM -0400, John Porter wrote:
> Dan Sugalski wrote:
> > 
> > Well, damn. And I mean that sincerely. :(
> 
> I don't think it's that big a deal.  Easy enough to wrap in a macro.

I thought (hoped) that the plan was the avoid the cpp like the plague
and cancer it is.  The massive overdose of cpp magic is one of the
main reasons why understanding/debugging/developing Perl 5 core is
so much fun.

This example is slightly off because most of the "fun" is courtesy
gcc, not perl, but I think it illustrates the point quite nicely.

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-08/msg01810.html

> -- 
> John Porter

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

[John Porter]

Dan Sugalski wrote:
> 
> Well, damn. And I mean that sincerely. :(

I don't think it's that big a deal.  Easy enough to wrap in a macro.

-- 
John Porter

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

[Dan Sugalski]

At 12:07 AM 10/13/00 +0100, Simon Cozens wrote:
>On Thu, Oct 12, 2000 at 03:24:23PM -0700, Russ Allbery wrote:
> > Can't.  ISO C requires that all variadic functions take at least one named
> > parameter.  The best you can do is something like (void *, ...).

Well, damn. And I mean that sincerely. :(

>Argh. Can't we just use a stack? I like stacks. Stacks make sense.

Stacks cost time and programmer effort. Parameters are generally passed in 
registers, (how many depends on your architecture, but sane ones have a 
bunch) while stacks require smacking data into memory somewhere and messing 
with the stack pointer. Even if you have a macro to push, it means doing this:

   PUSH(i);
   PUSH(j);
   PUSH(k);
   call_foo();

instead of:

   call_foo(i, j, k);

Stacks are OK for internal work (though I'd prefer a register file, if even 
a virtual one) but for externally exposed stuff we're better off taking 
parameters if we can.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

[Simon Cozens]

On Thu, Oct 12, 2000 at 03:24:23PM -0700, Russ Allbery wrote:
> Can't.  ISO C requires that all variadic functions take at least one named
> parameter.  The best you can do is something like (void *, ...).

Argh. Can't we just use a stack? I like stacks. Stacks make sense.

-- 
..you could spend *all day* customizing the title bar.  Believe me.  I
speak from experience."
(By Matt Welsh)

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

[Russ Allbery]

Dan Sugalski <[EMAIL PROTECTED]> writes:

> C's vararg handling sucks in many sublime and profound ways. It does,
> though, work. If we declare in advance that all C-visible perl functions
> have an official parameter list of (...), then we can make it work. The
> calling program would just fetch function pointers from us somehow, and
> do the call in.

Can't.  ISO C requires that all variadic functions take at least one named
parameter.  The best you can do is something like (void *, ...).

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 334 (v1) Ahhhh.. i get it

[Dave Storrs]

Heh.  In my youth, we said "Thanks a million."  I see that inflation has
now turned that into "Thanks a million and twenty four thousand."  :>


On 12 Oct 2000, John van V wrote:
> 
> $thanks -> (1000K)

Re: A tentative list of vtable functions

[ye, wei]

Hildo Biersma wrote:

> Fisher Mark wrote:
> >
> > > One C++ problem I just found out is memory management.  It seems
> > > that it's impossible to 'new' an object from an specified memory block.
> > > So it's impossible to put free'd objects in memory pool and re-allocate
> > > them next time.
> >
> > It can't be done by the default new operator, but you can do it with an
> > overloaded new operator.  An overloaded operator new can do whatever you
> > need it to do -- I've got 9-year old code that does arena allocation and
> > reference counting by overloading new.
>
> It can be done using 'placement new', for which you do not have to
> override any operator.  See Stroustrup 3rd edition, 10.4.11, 'Placement
> of objects".

I finally read some books and understand how to do that in C++! Thanks you
guys very much!

Also, I found a GREAT garbage collector for C and C++, which is written by
Hans Boehm,
and would like introduce to you guys.

It's using mark-sweep algorithm to maintan memory, although Perl's gc is
count-reference.
But I think it's still very helpful for memory debugging, or other projects.

It's so smart that it can maintan active memory automatically by scanning
process's heap
and static memory, instead of asking you pass your global varible pointers.

Here is an example, it only uses fixed allocated memory block instead of using
up all your memory!
[yw@yw gc]$ more mytest.c
#include "gc.h"
main() {
 int i=0;
 while(++i) {
   void *p = GC_malloc(1000);
   if(i%15000==0) printf("%x\n", p);
 }
}
[yw@yw gc]$


Here is its URLs:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html

>
>
> Cheers,
>   Hildo

--

Sincerely,

Ye, Wei

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

[Dan Sugalski]

At 08:57 PM 10/12/00 +0100, Simon Cozens wrote:
>On Thu, Oct 12, 2000 at 03:43:07PM -0400, Dan Sugalski wrote:
> > Doing this also means someone writing an app with an embedded perl
> > interpreter can call into perl code the same way as they call into any C
> > library.
>
>Of course, the problem comes that we can't have anonymous functions in C.

Sure we do. You can get a pointer to a function, and then call that 
function through the pointer. (Though argument handling's rather dodgy)

>That is, if we want to call Perl sub "foo", we'll really need to call
>something like
>
> call_perl("foo", ..args... );
>
>whereas we'd much rather do this:
>
> foo(..args..)
>
>(Especially since C's handling of varargs is, well, unpleasant.)

C's vararg handling sucks in many sublime and profound ways. It does, 
though, work. If we declare in advance that all C-visible perl functions 
have an official parameter list of (...), then we can make it work. The 
calling program would just fetch function pointers from us somehow, and do 
the call in.

Granted this will be a pain on our side (since I expect the C vararg stuff 
is very different from platform to platform, even more so (and more 
annoyingly) than plain function call stuff) but it is doable.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

[Simon Cozens]

On Thu, Oct 12, 2000 at 03:43:07PM -0400, Dan Sugalski wrote:
> Doing this also means someone writing an app with an embedded perl 
> interpreter can call into perl code the same way as they call into any C 
> library.

Of course, the problem comes that we can't have anonymous functions in C.
That is, if we want to call Perl sub "foo", we'll really need to call
something like

call_perl("foo", ..args... );

whereas we'd much rather do this:

foo(..args..)

(Especially since C's handling of varargs is, well, unpleasant.)

In short, C needs currying. :)

-- 
"Don't worry about people stealing your ideas.   If your ideas are any good, 
you'll have to ram them down people's throats."
 -- Howard Aiken

Re: RFC 334 (v1) Ahhhh.. i get it

[John van V]

$thanks -> (1000K)

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

[Dan Sugalski]

At 07:48 PM 10/12/00 +, John van V wrote:


>  * It also means we can write bits of perl in Perl, and similarly not 
> have
>to care about this fact.
>
>Granted, some developers are thick as a brick...
>If you are writing perl in Perl, then, presumably, you would know this.

But perl won't be written in Perl. It'll be written in C, most likely. 
It'll be written in a modular and overridable way, though. And that means 
that if we want to override things with perl code, that perl code needs to 
be callable the same way that any C function is.

Doing this also means someone writing an app with an embedded perl 
interpreter can call into perl code the same way as they call into any C 
library.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 334 (v1) Perl should allow specially attributed subs to be called as C functions

[Dan Sugalski]

At 06:30 PM 10/10/00 -0400, John Porter wrote:
>Dan Sugalski wrote:
> >
> > Perl functions that are called from outside will have to have some sort of
> > interpreter attached to 'em. I can see either a default interpreter, or 
> the
> > one they were compiled into being valid as a choice.
> >
> > If there's no hit, I'd love to have all perl functions callable from
> > outside. I'm not sure that'll be the case, though I'm all for it...
>
>As you say, it's a matter of providing context.  For some categories
>of functions, the only context necessary will be an interpreter handle.
>For other, presumably lower-level, functions, other gobs of context
>will be needed.  If it will be possible to encapsulate that other
>context stuff into a ball, then presumably a handle to that ball
>can be handed to the calling program, for use in future calls.
>But that may be a big "if"...

It may be a huge and insurmountable "if". It may even require the caller to 
do some sort of semi-global setup or something. (PERL_SET_CONTEXT, say) It 
may turn out that the context required to function will make this proposal 
infeasable, though I hope not. (Might be tricky when using it with multiple 
active interpreters, but I bet we can do it in the single-interpreter case 
at least)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

[John van V]

 * It also means we can write bits of perl in Perl, and similarly not have
   to care about this fact.

Granted, some developers are thick as a brick...
If you are writing perl in Perl, then, presumably, you would know this.

Excatly where is the added value, or is it purely for entertainment purposes ?? ;)

Re: RFC 334 (v1) I'm really trying to understand this...

[Simon Cozens]

On Thu, Oct 12, 2000 at 07:10:30PM -, John van V wrote:
> If you get the chance, I would really grateful if you could translate the
> abstract into lay terms, just confused by the concept of "low level perl"
>   
* We want to call Perl routines as if they were C routines.
* This means applications which embed Perl don't have to care whether 
  the various routines they're about to call are C or Perl.
* It also means we can write bits of perl in Perl, and similarly not have
  to care about this fact.

-- 
It is now pitch dark.  If you proceed, you will likely fall into a pit.

Re: RFC 334 (v1) I'm really trying to understand this...

[John van V]

If you get the chance, I would really grateful if you could translate the abstract 
into lay terms, just confused by the concept of "low level perl"   


Why??, perl is my only (byte) compiled language...
...I'm an admin.

TIA ;)