When you try to invoke a sub that doesn't exist, Parrot currently gives the
unhelpful error message "Null PMC access in invoke()". Sometimes you can
figure out what's wrong given the backtrace. Often you can't.
It would be nice instead to get a more specific error message indicating that
you
On Thursday 01 May 2008 15:51:17 James Keenan via RT wrote:
> *Is* the script worth keeping? If someone can describe how it is
> useful, then I will take a crack at perl-izing it.
I believe that you give it the name of an opcode, and it tells you which
src/ops/*.ops file contains it and any doc
On Thu May 01 11:20:22 2008, coke wrote:
> We shouldn't rely on having python available to developers. If this
> script is worth keeping, it should be converted to perl.
>
*Is* the script worth keeping? If someone can describe how it is
useful, then I will take a crack at perl-izing it.
kid51
Coke,
This has been come up a couple of times either on list or on #parrot.
And the same question has been raised about config/auto/m4.pm.
Other things being equal, I'm in favor of this. Hey! Two fewer config
steps to have to maintain or test!
But then I grepped for the string 'python' (upper
chromatic wrote:
From the wiki at
http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks :
* Deprecate "rethrow".
The replacement seems to be that an exception handler declines to handle an
exception. This is the default behavior; an exception handler explicitly
notifies the sched
On Thursday 01 May 2008 13:07:10 Alberto Simões wrote:
> Doing an otool -l (and some greps) to check libraries from the parrot
> binary, I got:
>
> name /usr/lib/dyld (offset 12)
> name /Users/ambs/Projects/parrot/blib/lib/libparrot.dylib
> (offset 24)
> name /usr/lib
Hi
Doing an otool -l (and some greps) to check libraries from the parrot
binary, I got:
name /usr/lib/dyld (offset 12)
name /Users/ambs/Projects/parrot/blib/lib/libparrot.dylib
(offset 24)
name /usr/lib/libSystem.B.dylib (offset 24)
name /opt/local/lib/lib
chromatic wrote:
I vote for fixing the buggy test (no pcre, no reason to run the tests) but not
working around standard dynamic library loading.
It is not that easy (I think). Also, I do not know much about these
things, so let me try explain some more details.
1) the configure step finds
hi,
it seems that there is overlap in the strings pdd (28) and the strings
implementation document in docs/strings.pod.
I'm not sure if this is a good idea; I think these should be merged.
If so, I'll open a ticket to do so (but wanted to check first)
kjs
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #53606]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53606 >
S05 has changed the meaning of colons following assertions,
such that
<.foo:
On Thu, May 01, 2008 at 12:19:06PM -0700, chromatic wrote:
> I'm not sure. Why add special logic to Parrot to find poorly-installed
> libraries? If you install a dynamic library outside of your normal system
> library paths, no other program will find it. If you want other things to
> find it
On Thursday 01 May 2008 12:07:47 Alberto Simões wrote:
> There was a test (test three from t/examples/library.t) that was failing
> and failing under MacOS X. That test relies on libpcre that is not
> available by default on MacOS X.
It seems to me that the test should skip itself if dynamic load
Hi, Folks
I am kind of 'out' from Parrot for a long time, and probably there is
something that I am missing.
There was a test (test three from t/examples/library.t) that was failing
and failing under MacOS X. That test relies on libpcre that is not
available by default on MacOS X.
If you u
# New Ticket Created by Will Coleda
# Please include the string: [perl #53602]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53602 >
We shouldn't rely on having python available to developers. If this
script is worth keepi
# New Ticket Created by Will Coleda
# Please include the string: [perl #53600]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53600 >
the only place that the config setting "has_python" is referenced in
the distro is in con
Off-and-on over the past year there have been sporadic conversations
about starting a foundation for Parrot separate from the Perl
Foundation. With 1.0 approaching, it's making more and more sense.
Parrot will be better able to approach the Python, Ruby, PHP, Lua, etc
communities if we're hoste
16 matches
Mail list logo
