I was attempting to build parrot (0.7.1 release), but got a failure in
the docs directory because "perldoc" was not in my path. Looking at the
Makefile I see that it sets "PERLDOC := /perldoc", but
uses "perldoc" in a rule. I think this is due to:
parrot-0.7.1/config/gen/makefiles/docs.in:37
Andy Lester wrote:
Modified since when?
It'd have to be against the last update from svn of the file itself.
I'm not sure I like the idea of relying on a given VCS. I know Parrot's
hosted in Subversion, but what about the Git folks?
Perhaps a better approach is to squirrel away an MD5 of
Will Coleda wrote:
Right, the hard bit here was that I needed to specify something other
than "file". Just agreeing that we need something other than just
"file/line".
I'd have thought the onus is the other way: justify the use of
"file/line" as the primitive concept.
We're going to have
Dan Sugalski wrote:
All security is done on a per-interpreter basis. (really on a per-thread
basis, but since we're one-thread per interpreter it's essentially the
same thing)
...
* Number of open files
* IO operations/sec
* IO operations total
...
Can an "application" get more resources
Matt Diephouse wrote:
There's no real point in having a plan if you don't follow it,
That sounds a bit naive. The benefit of a plan is primarily in the act
of making it (it forces you to think about what you want to do). The
secondary benefit comes when you track how actual progress deviates from
Leopold Toetsch wrote:
1) rename vtable->data to vtable->class
All current usage of the 'void *data' vtable element is as the object's
class. So it should read "PMC *class".
Its a minor thing, but I would try to avoid using identifiers that are
keywords in C++: especially in header files. The fact
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Rather not. Python is AFAIK not as portable as Perl. But there is a Perl
> based make somewhere, the named just escaped my mind.
We use Makepp (http://makepp.sourceforge.net/) here. Written in Perl, its
particular stre
"Dan Sugalski" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> >Why not take a page from C++ and call "previous" and "next" C and
> >C, and then C to get what it points to.
>
> Because ++ and -- affect the value not the container. (There are days
> when I think "C++ does it like..." i
"Dan Sugalski" <[EMAIL PROTECTED]> wrote:
> The terminology there's a bit strained, and I think it's in large
> part responsible for most of the rest of the confusion.
>
> They're probably better called Named and Anonymous events, though
> that's a bit dodgy in some ways too. Maybe specific and gen
"Dan Sugalski" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Reasonable enough, though there's something to be said for a
> completely meaningless (to most people) epoch so folks stop treating
> the number as a number with meaning and instead treat it as a black
> box thing they can
"Dan Sugalski" <[EMAIL PROTECTED]> wrote:
> =head2 Guarantees
Maybe this isn't strictly a threading thing, but are we going to make any
guarantees about event orderings? For example, will we guarantee that a
sequence of events send from one thread to another will always be received
in the order th
"Dan Sugalski" <[EMAIL PROTECTED]> wrote
> Right now, the only true difference between a sub call and a return, at
> least at the assembly level, is that we don't pass back a return
> continuation when we're returning
If one is coding a co-routine/iterator, then perhaps even this difference
might
"Brent Dax" <[EMAIL PROTECTED]> wrote:
> # > The result would mean that something like:
> # > pmc->vtable->add
> #
> # > Might become:
> # > pmc->vtable->math->add
> #
> # Seems too expensive to me for the normal math stuff.
>
> Perhaps, although one dereference doesn't seem to painful to me.
Is t
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> What we'd like is a way (and there've been a couple proposed) to make it
> so that the sweep at the end of scope can *quickly* determine that all
> objects needing timely destruction are still alive/reachabe/in-scope,
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote > What about the following (also
considering, that we might not like one
> A dynamic PMC library has one init function returning a dyn_pmc_info
> structure:
In the past, I've found the "init-fn returns struct" model can become a
burden when, in a few yea
"Andy Dougherty" <[EMAIL PROTECTED]> wrote:
> The problem is that with a clean build tree, there are no *.o files
> down in languages/imcc/ at the point when that target is reached.
> Hence make doesn't have anything to expand *.o as, and quite reasonably
> complains. If, however, there is even a
"Matt Fowles" <[EMAIL PROTECTED]>
> Were this C++ I would say that we could write a single general purpose
> stack and use template meta-programming to avoid the overhead. Is there
> a similar solution available in C?
>
> My instincts tell me that this solution will be dirty to the tune of
> massi
"Piers Cawley" <[EMAIL PROTECTED]> wrote
> Threads and Progress Monitors
> Dave Whipp had some more thread questions, and wondered what would be
a
> good Perl 6ish way of implementing a threaded progress monitor. Whilst
> the discussion of all this was in
Dan Sugalski wrote:
Okay, here's another shot at the semantics for objects. If folks,
especially non-perl folks, would look this over and chime in, I'd much
appreciate it.
The thing that I noticed was the lack of semantics for creation and
destruction. Will there be well defined creation semanti
"Nicholas Clark" <[EMAIL PROTECTED]> wrote
> On Thu, Nov 14, 2002 at 08:53:02PM -0800, chromatic wrote:
> > Brent Dax had a nice suggestion for Perl 6 test organization. I like it
> > tremendously.
> >
> > I repost it here to solicit comments -- to make this work, I'll need to
change
>
> Did anyon
20 matches
Mail list logo