Re: Adding new function signatures to parrot's NCI call list

2002-11-27 Thread James Mastros
On 11/25/2002 9:02 PM, Dan Sugalski wrote:

Pretty straightforward. Edit call_types.txt. First parameter's the 
return type, the rest are the parameter types. Use "p" for any generic 
"i've stuffed a struct pointer into a PMC" type. Do please only add in 
signatures for functions you're actually going to call (or are adding if 
you're adding in a full library) as we'd rather not have nci.o get *too* 
big...
Could you setup build_nativecall.pl to ignore #-style comments, and 
document this at the top of call_types.txt, along with what it's for? 
(If you can't, at least rename the thing nci_types.txt, so it's mildly 
clear what it's for.)

Not that I mean to complaign -- this looks very cool indeed.  (Actualy 
messing with parrot for real again is on my todo project list, after a 
couple of other things that I'll probably never really complete.  For 
now, I'm just reading along and occasionaly kabitzing.)

	-=- James Mastros



Re: Adding new function signatures to parrot's NCI call list

2002-11-27 Thread James Mastros
On 11/27/2002 3:09 AM, Dan Sugalski wrote:


At 1:02 AM -0500 11/27/02, James Mastros wrote:


On 11/25/2002 9:02 PM, Dan Sugalski wrote:


Pretty straightforward. Edit call_types.txt. First parameter's the 
return type, the rest are the parameter types. Use "p" for any 
generic "i've stuffed a struct pointer into a PMC" type. Do please 
only add in signatures for functions you're actually going to call 
(or are adding if you're adding in a full library) as we'd rather 
not have nci.o get *too* big...

Could you setup build_nativecall.pl to ignore #-style comments, and 
document this at the top of call_types.txt, along with what it's for? 
(If you can't, at least rename the thing nci_types.txt, so it's 
mildly clear what it's for.)


I'll go look--it should already do this, and I thought I committed 
those changes, but they might not've gone in.

You did, my bad, sorry.  (Though a note about what these types we're 
specifiying are for would be useful.)

   -=- James Mastros



This week's summary

2002-11-27 Thread Piers Cawley
The Perl 6 Summary for the week ending 20021124
And some rough beast, its hour come 'round at last slouches toward...

And then the scansion goes to pot and I can't make a joke fit. Shame.

Anyhoo, it's time for another episode of the continuing saga of Perl 6
development. When I say 'saga' I don't mean a long, long poem of
alliterative lines, but a bright, breezy and brisk tale of the bods in
the lists. Well, one week mayb, when we've been quiet...

We start, as usual with the internals list.

  C#/Parrot Status
Rhys Weatherley, who has been absent from the internals list lo these
many days popped up again to ask about:

*   Object/class support

*   Fixed-size integers and/or conversion opcodes

*   Embedding of binary extension sections

He noted that "Not Done Yet" was an acceptable answer. Which is good,
because, as Leopold Tötsch pointed out, none of them were done yet. Leo
also reckoned that a start would be to implement fixed size integers and
conversion ops, and asked for details of what was wanted. Iacob Alin
wondered if the various types would be PMCs (answer: Only those types
which don't easily map to native types.) Florian Weimer wondered about
trapping integer arithmetic. Dan says these will be handled using
Parrots standard exception handling mechanism (which doesn't actually
exist yet, but signs in the wind suggest we might be getting a Halt and
Catch Fire op to raise an exception).

http://makeashorterlink.com/?P3F621592

  Parrot 0.0.9 status
According to Steve Fink: "The basic status is that lots of people, many
of them coincidentally named Leopold Tötsch, have been fixing zillions
of things and implementing a number of new features. Nearly everything
needed for 0.0.9 has happened, and a lot else besides."

See his post for details of what's still to be done.

One of the most important items was that the tinderbox (a fleet of
machines that constantly make, test and remake the latest parrot builds)
was a beautiful shade of orange and red, which led to discussion of what
was going on (since most people's home boxen seem to be making and
testing okay...) Various remedies and patches were tried, but I believe
the tinderbox is still mostly the wrong colour.

http://makeashorterlink.com/?I50722592

http://makeashorterlink.com/?W21751592

  Unified core.jit
Leopold Tötsch posted an RFC in which he proposed writing a universal
core.jit which provides the basic JIT framework and which delegates the
generation of native ops to processor specific implementations. Daniel
Grunblatt liked the basic idea, but thought there might be a case for
creating cisc.jit and risc.jit to avoid piles of "#ifdef"s. Daniel, Leo
and Nicholas Clark then spent a few posts thrashing out issues to do
with parameter naming and other more or less arcane things.

http://makeashorterlink.com/?U12722592

  Native Function calls
Dan announced that he'd redone the native function call interface and
had added a new op, "bnc", which stands for `build native call'. His
post has the details of how it all works (and how to use it). Well,
that's what he said at first, but apparently it's not true. What he's
actually done is altered the "dlfunc" opcode to behave like "bnc" he
described. (It's a shame you can't hit "s/bnc/dlfunc/" in your mailer
and have the world alter every single copy of the mail you just sent. It
would have been useful for some of my previous summaries.)

Brent Dax wondered if this was going to be the new XS or if there was
more coming. Answer: Sort of.

Leo Tötsch didn't like nci.c's string functions, and wondered too about
places where you'd need to pass a pointer to the parrot interpreter. Dan
doesn't like the string functions either, noting that the code is "evil,
crufty [and] embarrassing", but that it is at least "well encapsulated,
so it can be ripped out, shot, and replaced with something elegant and
fast at some point in the future." As for parrot interpreter pointers,
Dan reckons that any code that needs to go so far should install real
extension sub PMCs.

Gopal V worried about the type safety (it's an obsession of his
apparently) or rather the complete lack of it, in this interface. Dan,
in a quote of the week post said yup, of course it's totally type unsafe
and he liked it that way, before confessing that he was getting that
`XML feeling. (You know the one--"It seemed like a good idea until I
thought about it")' and started backpedalling. Gopal V made a few
suggestions, and that's about where we left it.

http://makeashorterlink.com/?Z23715592

http://makeashorterlink.com/?P54723592 -- the correction

  Leopold Tötsch, still the patch monster
Leo's contributions this week include:

*   Patches to the JIT which give 

Re: [perl #18637] PDD06: Incomplete sentence at end of section

2002-11-27 Thread Dan Sugalski
At 2:07 AM + 11/24/02, kj Woolley (via RT) wrote:

   One that leaves me hanging is source line 185 of PDD06 --
"String and integer constants don't need to be put in a separate" and
the sentence cuts there.  Do you have any insight as to what the end of
that sentence should be?  I'm guessing "namespace", but it seems to me
like there might be more missing.


D'oh! Fixed.
--
Dan

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



interesting idea...

2002-11-27 Thread Bryan Hundven
On Wed, 27 Nov 2002, Bryan Hundven wrote:

Bryan,

you should suggest it on the perl6-internals mailinglist where
parrot development is happening. :-)

 -ask

> I don't know if anyone at parrotcode has thought of this idea, or
> implemented it as a test (or joke)...
>
> But what if you made an architecture independent layer for 
operating
> systems, kind of like mach, but more minimalistic.
>
> This way if your an operating system designer, you don't have to 
learn
> cpu specific assembly, you can just learn parrot assembly.
>
> Granted, it probably wouldn't be fast, but it would be kinda cool!
>
> Just an idea,
>
> Bryan Hundven
>
> __
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>

-- 
ask bjoern hansen, http://askbjoernhansen.com/  !try;
develooper llc,http://www.develooper.com/   do();

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com