Re: Is Parrot 1.0 too late?
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 languages and as I know there's no other VM like it. Well...
> since now.
>
> Check this article: http://blogs.zdnet.com/microsoft/?p=404 Microsoft
> announces a dynamic layer for CLR, so they will be able to support dynamic
> languages on their VM. And JVM 1.6 already has this, plus it's opensource and
> has support for the mainstream platforms.
>
> So, is one of parrot's biggest strengths gone? Are we too late?
> Why would the developers use Parrot instead of JVM/CLR/Mono?
I think the role Parrot aims to fill is remains unfilled, although it is
being approached from both sides. Check out this LLVM presentation, for
example:
http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.html
Look towards the ends of the slides:
http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.pdf
An excerpt:
Call for help!
OSS community needs to unite work on various scripting languages
Common module to represent/type infer an arbitrary dynamic language
Who will provide this? pypy? parrot? llvm itself someday ("hlvm")?
HLVM is actually in progress:
http://hlvm.org/
Judging by how fast LLVM has progressed since Apple's been backing it
(almost two years now) LLVM/HLVM may be something to watch (or work with...)
-John
Re: LLVM and HLVM
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 much better job of native code generation than the existing Parrot code, that is. Optimization seems to be LLVM's "thing." -John
LLVM and HLVM
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 further optimization and native code generation? There's also the predictably named HLVM: http://hlvm.org/ which looks vaguely Parrot-ish. Check out the comparison chart: http://hlvm.org/docs/FAQ.html Anyway, I'm just thinking out loud, here. Sorry if it's all old news to the Parrot dev gurus. -John
Re: [off topic] an amusing side note
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 will > converge towards a common subset of accepted good practice. ...much like what happened with Perl 5...although the last phase has been hampered somewhat but the utility of some of those early, crazy efforts :) -John
Re: [off topic] an amusing side note
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" really did design Perl 6 in the absence of Larry. Fortunately, that's not the case. I think Perl 6 is a lot cleaner than Perl 5 in addition to being much more powerful. -John
Re: No Autoconf, dammit!
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 include the decision in the middle of a mind-numbing, globe trotting spew of information. That way, there are plenty of jucier tidbits to distract people. He also usually gives a one or two sentence reason, which might help here too. An example: "No Autoconf because Autoconf assumes the existence of more things than Parrot can. Parrot has to build anywhere that has C89 support, but Autoconf requires sh, among other things." I don't even know if that's accurate, but in lieu of Larry's "Where's Waldo Hidden Decree" technique, I think there needs to be something more than "because I said so" to keep the natives from becoming restless :) -John
Re: Numeric semantics for base pmcs
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 promote to > >BigNum? Is it a memory bandwidth issue or something? > > If you've built parrot to use 64 bit ints, it will. Hm, but does that also mean that it'll expect "all" ints to be 64 bit? I'm thinking of "hybrid" situations like Mac OS X on a G5, where the OS and all system libs are still 32-bit, but the CPU can handle 64-bit integers. > We still have to generally address the whole 64 bit integer question. > I've been avoiding it, but I'm not sure that's ultimately feasable. Obviously someone needs to buy you a G5 in order to adequately motivate you... ;) -John
Re: Numeric semantics for base pmcs
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 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 suitably delayed on systems with > > support for 64-bit ints? More generally, what is the state-of/plan-for > > "64-bit support" (whatever that may mean) in Parrot? > > I thought about that during BigInt hacking. It could be a nice > optimization if we go: > > Int -> Int64 -> BigInt > > on 32-bit systems that have 64-bit integer support. OTOH it makes type > promotion a bit more complicated and dependent on configuration > settings. 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 promote to BigNum? Is it a memory bandwidth issue or something? Either way, it'll definitely be a boon to fast integer math if 64-bit ints are used to stave off promotion to BigNum when possible. This may be especially true for languages like Perl 6 which (AFAIK) doesn't have an "int64" native type specifier. So either Perl 6's "int" type is 64-bit where possible, or is a 32-to-64-auto-promoting type. -John
Re: Numeric semantics for base pmcs
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 suitably delayed on systems with support for 64-bit ints? More generally, what is the state-of/plan-for "64-bit support" (whatever that may mean) in Parrot? -John
Re: Load paths
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 like every badly behaved OS vendor and start making up your own crazy URI schemes: filehandle://, pmc://, sharedmem:// (Okay, maybe it's not such a good idea after all... :) -John
Re: Dates and Times
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 ambiguity. That has not proven to be the case if the DateTime.pm project is any indication... -John
Re: DOS filename collisions
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 of disk, 4megs of RAM and some > form of DOS. > > Dunno if hardware that old is inside Parrot's scope. Gah, it's like AutoLoader all over again! Please, let's just forget about building on systems that only support 8.3 or else we'll never be rid of them! :) -John
Re: Parrot Trooper
On 2/8/02 1:44 PM, Wizard wrote: > Try this. It's might be too 1970's, though. Also too carcinogenic ;) -John
Re: What happened at little languages?
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, too, but nobody seemed to have heard of > it. That's hopefully changed. (I made a point of mentioning it, as it is a > really nice language and one of our targets) > >> Or is this just the academic distaste for Perl syntax showing through? > > Sort of. How "academics" can dislike Perl's syntax aesthetics and yet like Smalltalk's is beyond me. -John
Re: Schedule of things to come
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
Re: Schedule of things to come
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
Re: Schedule of things to come
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 first-stage rollout, does Apache's module system support > Apache managing filehandles and modules calling apache's I/O routines, or > does it just do weird magic with I/O on normal filehandles? Which apache module system would this be, 1.3 or 2.0? What do the relative "schedules" (heh? :) of Parrot/Perl 6 and apache 2.0 look like? It'd be nice not to end up with one or the other being out of step (e.g. mod_perl6/parrot for apache 1.3 arriving long after apache 2.0 is the established standard) -John
Re: Revamping the build system
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. They can use a separate build setup with project files for the > metrowerks compiler or whatever the compiler is going to be there. As one of the few rabid Mac users on this list, let me just say that I personally have no problem with classic Mac OS support being totally dropped from Parrot if it'll get stuff out the door sooner :) Classic Mac OS is (somewhat sadly) a dead OS at this point. By the time Parrot is "done", Apple will probably be shipping hardware that won't even *boot* classic Mac OS outside of a virtual machine in OS X. (Also, I'd be much happier if those resources could be redirected to making sure Perl 6, apache, mod_perl, etc. all builds as easily on OS X as they do on, say, Solaris...but now I'm just whining ;) (Apache::Request-less on OS X, 7 months and counting...) -John
Re: The core platforms list
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 adding \0 bytes > until the names are distinct. The finder has a bit of a mess renaming > them, but at least you can see them as separate files. And no > collisions from the Unix side! > > So, foo, Foo, and FOO would be stored as "foo" "Foo\0" and "FOO\0\0", > effectively. Ick. > Is there anybody I can write at Apple to beg for this? If you're going to beg, beg for an actual case-sensitive file system, not an evil hack on top of HFS+ (the hard link hacking is bad enough ;) Check lists.apple.com for the relevant mailing list archive(s) to see how this debate has gone so far. On 9/19/01 11:49 AM, Robin Houston wrote: > Dan Sugalski wrote: >> I'd love to have Darwin there, [...] >> >> If someone is willing to pitch in the time and effort, I'd be thrilled >> to add it to the list. > > I'm willing. My hero! :) -John
Re: The core platforms list
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 that's only > 32-character, case-insensitive names. Unless the Finder is hiding > something from me. HFS+ supports 255 character file names. Yes, the (classic Mac OS) Finder is hiding something from you, as are the rest of the classic Mac OS file access APIs, which are limited to 32 characters and weren't updated when HFS+ was introduced with Mac OS 8.1(?). In Darwin and OS X on HFS+, feel free to: touch thisfilenameismuchlongerthanthirtytwocharactersanditworks (HFS and HFS+ are indeed case-insensitive though) -John
Re: The core platforms list
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 names (e.g. HFS). I'll probably try building Parrot on Darwin (well, OS X) from time to time, but I don't have the skills (or time) to do much more than notice whether it's broken or not, heh. I hope someone does pick up the Darwin torch, though. I don't want a repeat of the Apache/Perl 5 situation on Darwin (I *still* can't get mod_perl running correctly) -John
Re: Math functions? (Particularly transcendental ones)
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 in... :) -John
Re: Something to hash out
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 anything proposed so far. As for 8.3, come on, the madness has to end some time ;) -John
Re: Modules, Versioning, and Beyond
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) API > from 1.99 and 3.10. The major/minor version scheme is nice. I've seen it used elsewhere, but I often wonder what happens when I hit 1.99 and the API still isn't changing in an incompatible way. (Hey, it could happen...good planning! :) > An alternate way of representing this is through a directory hierarchy, > vaguely reminiscent of one Perl uses currently. We can abstract both > the API major version and the minor revision number to two layers of > directories. So now Foo.pm above could be found as: > > perllib/Foo.pm@ -> 1/02/Foo.pm > perllib/1/Foo.pm@ -> 02/Foo.pm > perllib/1/02/Foo.pm Mac OS X (nee NeXT) Framework bundles spring to mind at this point. They allow for multiple simultaneous versions (using major/minor version compatibility rules like those described earlier) and even multiple architectures, all within a single structured directory. More information can be found here: http://developer.apple.com/techpubs/macosx/CoreFoundation/BundleServices/Bun dle_Services/ or in the relevant section of the System Overview document: http://developer.apple.com/techpubs/macosx/SystemOverview/SystemOverview/Sys temOverview.pdf It may not be 100% applicable to Perl, but there are some good ideas in there (many echoed in Brian's post). -John
Re: Perl_foo() vs foo() etc
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 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_? > > Well, Perl_ and PERL_ won't work, since that's relying on case-sensitivity > in the various linkers, which is a Bad Thing. D'oh! Hadn't thought of that... > Having Perl_ and PL_ to separate code and data is in there mainly to make > separating things programmatically easier. We could, I suppose, make > everything Perl_ and have a config file somewhere with the type > (data/code/whatever) indicated. Well, that does sound a bit harder. Maybe I'm crazy, but I just keep seeing that "PL" product/technology/language/dessert-topping/floor-wax coming along and messing things up. And its kind of like domain names: how many two-letter combinations aren't already taken? > That's probably the best thing--since we're exporting only a reasonably few > things, and only explicitly, it ought to be OK. Cool beans :) ;) -John
Re: Perl_foo() vs foo() etc
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 seems to me that PL_ has *got* to be used somewhere in the wide world of code. (Isn't it a country code?) Maybe I'm being too paranoid, but Perl has basically staked out the letters "p e r l", whereas "PL" is probably still up for grabs. The last thing we need is some whizzy new product exploding into the "PL" moniker in 2003 and creating weird new embedding problems. PERL_ also matches up nicely with _Perl_ and Perl_, of course. What are two characters worth? ;) -John
Re: Chip's topaz slides
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
