On Apr 14, 2004, at 10:20 PM, Jarkko Hietaniemi wrote:
Finding stuff relative to the executable/DLL would be coolest scheme,
but that is admittedly somewhat tricky to get working cross-platform.
Excellent idea. Pretty much every single resource in Cocoa applications
and frameworks on Mac OS X is
Hi there,
I'm seeing method name truncation when trying to run code of the form:
.local pmc app
.local int app_type
find_type app_type, 'SDL::App'
app = new app_type, app_args
.local pmc main_screen
main_screen = app.'surface'()
surface() calls _new() on another object
> Just came across an interesting quirk with the current usage of
> ICU--if you do it, you can't run parrot unless your current directory
> is the base parrot directory. Trying it from elsewhere throws a
> "string_set_data_directory: ICU data files not found" error.
>
> Symlinking parrot's blib
On Apr 14, 2004, at 7:49 AM, Dan Sugalski wrote:
Just came across an interesting quirk with the current usage of
ICU--if you do it, you can't run parrot unless your current directory
is the base parrot directory. Trying it from elsewhere throws a
"string_set_data_directory: ICU data files not f
All of the easy differences are listed in dynclasses/README.
The hard difference, Leo summed up - we need a way to deal with dynamic
pmcs that depend on each other. If I had a bunch of unrelated pmc's
(like the Foo example), I'd be done already.
For simple dependencies, you could just force the
At 7:42 AM +0100 4/13/04, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
At 6:53 PM +0100 4/8/04, Mark Sparshatt wrote:
I've got a couple of questions about Atrributes in Parrot.
PDD15 says that both classes and objects have a list of attributes and
it is possible to add or remov
Seems we've some issues with static vs dynamic pmcs. Could someone
take a few minutes (nudge, nudge, Will :) and list out the issues?
I'd like to have the build process for static and dynamic PMCs be
identical which we're not at yet, so this'd seem to be a good time to
do what we have to to mak
On Tue, 2004-04-13 at 18:23, Leopold Toetsch wrote:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > For example, in Perl5/Ponie:
>
> > @names=;
> > print "Phone Book: ", sort(@names), "\n";
>
> > In this example, I don't see why I would care that NAMES might be a
> > pseudo-handle
At 1:39 PM +0200 4/14/04, Michael Scott wrote:
On 13 Apr 2004, at 23:43, Dan Sugalski wrote:
I've been assuming it's a left-side wins, as you're tacking onto an
existing string, so you'd get English in all cases. Alternately you
could get an exception. The end result of a mixed-language
operati
On Wed, Apr 14, 2004 at 01:39:17PM +0200, Michael Scott wrote:
:
: On 13 Apr 2004, at 23:43, Dan Sugalski wrote:
:
: >I've been assuming it's a left-side wins, as you're tacking onto an
: >existing string, so you'd get English in all cases. Alternately you
: >could get an exception. The end res
Adam Thomason <[EMAIL PROTECTED]> wrote:
> A handful of // comments are lingering around the tree. Patch fixes
> them to use /* ... */.
Thanks, applied.
leo
Walter G <[EMAIL PROTECTED]> wrote:
> t/pmc/object-meths..dubious
> Test returned status 1 (wstat 256, 0x100)
> Scalar found where operator expected at (eval 157)
> line 1, near "'int' $__val"
> (Missing operator before $__val?)
> DIED. FAILED test 17
Strange. This is AFAIK
On 13 Apr 2004, at 23:43, Dan Sugalski wrote:
I've been assuming it's a left-side wins, as you're tacking onto an
existing string, so you'd get English in all cases. Alternately you
could get an exception. The end result of a mixed-language operation
could certainly be the Dunno language or the
Just came across an interesting quirk with the current usage of
ICU--if you do it, you can't run parrot unless your current directory
is the base parrot directory. Trying it from elsewhere throws a
"string_set_data_directory: ICU data files not found" error.
Symlinking parrot's blib/ dir into t
Tim Bunce wrote:
> On Sat, Apr 10, 2004 at 01:49:37PM +0300, Jarkko Hietaniemi wrote:
>
>>>(We've learnt the hard way with Perl5 modules names that more words are good.
>>
>>And more words that mean something... "Data" ranks right up there as the
>>worst possible names for anything.
>
>
> (Nah,
On Saturday 10 April 2004 12:42, Tim Bunce wrote:
> Perhaps Data::DeepReplacePMC
What do you think about:
PMC::DeepReplace (Data::Replace)
PMC::Printable (Data::Escape)
PMC::Sort (Data::Sort)
PMC::Dumper (Data::Dumper)
> (We've learnt the hard way with Perl5 modules names that more words are
> go
16 matches
Mail list logo
