On 4/24/07 6:31 PM, Nikolay Ananiev wrote:
> As we all know, parrot has been in development for 7 years now. That's a lot
> of time and many things have changed since then. From my point of view one of
> the biggest strengths of Parrot is that it's a target for many (and why not
> all?) dynamic lan
On 8/23/06 4:09 PM, Aaron Sherman wrote:
> here's the problem with that: llvm is a very light layer, but it's yet another
> layer. To put it between parrot and hardware would mean that parrot is JITing
> to LLVM byte-code, which is JITing to machine code. Not really ideal.
...unless LLVM does a mu
Has anyone looked at LLVM lately?
http://llvm.org/
It seems to be making a lot of progress lately with the support of Apple
(which is using LLVM for its own purposes in Mac OS X). Is there anything
there Parrot can steal? Would it make sense for Parrot to target LLVM
bytecode and let LLVM do fu
On 11/24/04 7:27 PM, Tim Bunce wrote:
> I predict a burst of wild creativity from authors enjoying the
> exploration of all the wonderful tools in the perl6 toolbox.
>
> Then, after a year or three of fun, sawn off limbs, and bloodied
> fingers (and after a few good books get published) most of us
On 11/24/04 3:42 PM, Felix Gallo wrote:
> Well, it's the first time *I've* seen it.
>
> http://otierney.net/images/perl6.gif
>
> I find it difficult to disagree, at the perl6 language level.
I don't :) Judging by the Perl 6 RFCs, I think that book cover would be
accurate if "the community" real
On Wed, 8 Sep 2004 15:46:17 +, Herbert Snorrason <[EMAIL PROTECTED]> wrote:
> I suggest we institute a "Rule One" for Dan. (And number two, too,
> while we're at it.) It'd be easier that way.
That rule already exists, but I think Dan still feels insecure about
it ;) The Larry Way(tm) is to in
On Thu, 26 Aug 2004 11:10:59 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:56 AM -0400 8/26/04, John Siracusa wrote:
> >Why make a stop in 32-bit land at all in that case? If the system supports
> >64-bit ints, why not use them for everything right up until you
On Wed, 25 Aug 2004 07:48:03 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> John Siracusa <[EMAIL PROTECTED]> wrote:
> > On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >> The big question is whether being clever and producing
On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The big question is whether being clever and producing the tightest
> type is worth the time to figure out what that type is, as well as
> the potentially uncertain output type.
Tangentially related: will promotion be su
On 3/24/04 1:58 PM, Brent 'Dax' Royal-Gordon wrote:
> And I do think URIs aren't a horrible idea, although it doesn't matter
> since you disagree. Ah well...
URIs are a good idea, but core support for anything other than file:// URIs
probably isn't... :) Anyway, if you use URIs, then you can be
On 3/4/04 5:09 PM, Dan Sugalski wrote:
> If the local system returns localtime, I can see adjusting to GMT or UTC, or
> whatever, as that ought to be a trivial transform.
Er, I'm not so sure about that. That means you'd have to be 100% sure that
you can determine the local timezone without any am
On 12/4/02 2:16 PM, Michael G Schwern wrote:
> On Wed, Dec 04, 2002 at 02:03:06PM -0500, Dan Sugalski wrote:
DOS isn't an intended compilation target, no.
>>> Not even djgpp?
>>
>> Hadn't planned on it. What advantage does it give over windows?
>
> It'll compile C programs on a 386/SX, 20M o
On 2/8/02 1:44 PM, Wizard wrote:
> Try this. It's might be too 1970's, though.
Also too carcinogenic ;)
-John
On 11/19/01 12:25 PM, Dan Sugalski wrote:
> Python's got a good shot at things, as it seems to be the 'dirty little
> secret' of the academic world--it's the practical language people admit to
> using when they're actually doing something.
Sounds familiar...
> I've reasonably good hope for Ruby,
On 10/27/01 10:34 PM, John Siracusa wrote:
> On 10/27/01 7:08 PM, Dan Sugalski wrote:
>> I think we're due out in reasonably good alpha/beta shape for the summer.
>
> Heh, the phrase "suitable vague" springs to mind... :)
s/e v/y v/; # oops :)
-John
On 10/27/01 7:08 PM, Dan Sugalski wrote:
> I think we're due out in reasonably good alpha/beta shape for the summer.
Heh, the phrase "suitable vague" springs to mind... :)
(which year is that again? ;)
-John
On 10/27/01 4:22 PM, Dan Sugalski wrote:
> At 06:27 AM 10/27/2001 -0700, Ask Bjoern Hansen wrote:
>> [EMAIL PROTECTED] (Dan Sugalski) writes:
>> I think Robert and I are planning to get mod_parrot to work as soon as
>> parrot has some kind of I/O. :-)
>
> Darned soon now.
>
> So I know for the f
On 10/23/01 8:16 AM, Paolo Molaro wrote:
> On 10/23/01 Simon Cozens wrote:
>> On Tue, Oct 23, 2001 at 12:16:04PM +0200, Paolo Molaro wrote:
>>> autoconf automake libtool
>>
>> MVS, MacOS, cross-compilation.
> [...]
> MacOS: I guess any type of Makefile based build system would not work on
> MacOS
On 9/19/01 11:51 AM, Randal L. Schwartz wrote:
> John> (HFS and HFS+ are indeed case-insensitive though)
>
> Which they *could* have fixed from the Unix side in the same way that
> MachTen did it..., and I wish they would. In MachTen, each
> case-folded collision on the HFS+ side is handled by a
On 9/19/01 10:35 AM, Randal L. Schwartz wrote:
> John> Someone will correct me if I'm wrong, but I don't think Darwin
> John> even installs on file systems that support anything less than
> John> 255 character file names (e.g. HFS).
>
> My HFS+ drive held Darwin for at least a little while, and t
On 9/18/01 7:26 PM, Randal L. Schwartz wrote:
> I'd suggest you "Darwin" there to be sure you're thinking about
> case-insensitive-32-char filenames
Someone will correct me if I'm wrong, but I don't think Darwin even installs
on file systems that support anything less than 255 character file name
On 9/9/01 11:47 AM, Dan Sugalski wrote:
>> http://www.allegedlyfunny.com/opcodes.html
>> I think DWIM might be a bit much, but HCF (Halt, Catch Fire) might be
>> fun :)
>
> Far too many of those are tempting... :)
Hey, if the PPC can have EIEIO, I see no reason Parrot can't sneak a few fun
ones
On 8/25/01 10:37 AM, Dan Sugalski wrote:
> I'm currently thinking of using .pasm as the extension for parrot assembly
> code, and .pbc for precompiled bytecode. [...] Can anyone think of anything
> better? They seem rather lame.
I think they're just fine, actually. I like them better than anythi
On 7/29/01 12:48 PM, Bryan C. Warnock wrote:
> Let's just arbitrarily assume that the
> major number of the version is equivalent to that version of the API.
> (In other words, Foo 1.05 gives us a promise that it uses the same API
> as 1.02 and 1.08. Foo 2.01 would use a different (however slight
On 4/11/01 4:38 PM, Dan Sugalski wrote:
> At 03:09 PM 4/11/2001 -0400, John Siracusa wrote:
>> On 4/11/01 10:55 AM, Dan Sugalski wrote:
>>> It does fix the link issues, though. perl6.so won't ever have an
>>> unqualified function in it--they'll all have either
On 4/11/01 10:55 AM, Dan Sugalski wrote:
> It does fix the link issues, though. perl6.so won't ever have an
> unqualified function in it--they'll all have either a Perl_ or _Perl_
> prefix on them, and all global data will have a PL_ prefix on it.
Remind me again why it's PL_ and not PERL_? It s
On 4/5/01 6:36 PM, Nathan Torkington wrote:
> Better late than never! Chip's provided the slides for last year's
> Topaz talk at TPC5.
Ah, the speed of the Internet age! ;)
(but you're right, so thanks :)
-John
27 matches
Mail list logo
