Re: licensing issues

2001-01-07 Thread Bradley M. Kuhn
it. As far as I can tell, this is FUD. Can you produce statements from these lawyers? Every lawyer I have ever met things it is legally sound, including those lawyers who are trying to find ways to violate it! -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

public domain? (was Re: standard representations)

2001-01-05 Thread Bradley M. Kuhn
> At 12:29 AM 1/5/01 -0500, Bradley M. Kuhn wrote: > >Dan Sugalski <[EMAIL PROTECTED]> wrote: > > > > > I'm beginning to loathe software licenses in a *big* way, and I'm a half > > > step away from saying to hell with it all and going fully publi

licensing issues (was Re: standard representations)

2001-01-05 Thread Bradley M. Kuhn
> On Fri, 5 Jan 2001, Bradley M. Kuhn wrote: > > > I personally think that the relying on LGPL'ed code is completely > > reasonable. Some will disagree, so we need to come to a consensus on this > > as a community. Andy Dougherty <[EMAIL PROTECTED]> wrote:

Re: standard representations

2001-01-04 Thread Bradley M. Kuhn
> Liceses. Bletch. Don't blame the licenses, blame the copyright law that makes them an unfortunate necessity in many cases. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: standard representations

2001-01-04 Thread Bradley M. Kuhn
ensus on this as a community. Also, note that as long as our license is compatible with the LGPL (and most licenses are). There are no licensing problems for us, but we might be creating hassles for those who redistribute proprietary software versions of perl. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: Supporting architectures without native C support (was Re: Meta-design)

2000-12-11 Thread Bradley M. Kuhn
d to do", from a programming point a view, given that the Turing indicated that it can be done by a program in polynomial time. There is not a definitive way to "prove" coming up with that polynomial time algorithm is hard. ;) -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: Perl6 on handhelds (was Re: Meta-design)

2000-12-09 Thread Bradley M. Kuhn
likely. Given that my "write it all in Java" proposal was shot down with very good arguments, I wouldn't ask for these sorts of parts to be anything but in C, and eccentric. ;) Internals of scalars: C API to scalars: language independent -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: Supporting architectures without native C support (was Re: Meta-design)

2000-12-09 Thread Bradley M. Kuhn
ou chapters of my Master's Thesis that I am finishing up this month, that is making the detailed arguments as to why it is a hard problem. I believe the difficult that we've had porting perl5 to the JVM is a bug in perl5's design. I am trying to encourage people to fix that bug in perl6. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: Supporting architectures without native C support (was Re: Meta-design)

2000-12-09 Thread Bradley M. Kuhn
design doesn't have to center around the langauge we choose to implement that design, though. We've got C for the implementation and that's fine. But, why design it so C is the only choice for a language? -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Perl6 on handhelds (was Re: Meta-design)

2000-12-07 Thread Bradley M. Kuhn
t least one hand-held on the market (PocketLinux) that is basically Java-based. (My understanding is that they run enough of Linux to make the JVM work. ;) As mentioned elsewhere in the thread, Motorola has a JVM-based device coming out, too. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Let's not be C-specific even if we use C (was Re: Meta-design)

2000-12-07 Thread Bradley M. Kuhn
choice other than to treat the JVM like "just another processor". But the JVM isn't just a processor, it's also an object model. If a port isn't aware of that object model, then the usefulness of the JVM port is greatly reduced. I'd be happy to talk more about this with you off-list if you are interested. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Supporting architectures without native C support (was Re: Meta-design)

2000-12-07 Thread Bradley M. Kuhn
ember that `require' is built on `eval STRING'. > On Wed, Dec 06, 2000 at 08:30:06PM -0500, Bradley M. Kuhn wrote: > > I see no reason to ghettoize powerful non-C-based systems just because we Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote: > Powerful? Java? Excuse me,

Perl6 compatibility with non-C enviornments (was Re: Perl6 in Java? (was Re: Meta-design))

2000-12-07 Thread Bradley M. Kuhn
> On Wed, 6 Dec 2000, Bradley M. Kuhn wrote: > > > And, it will make the barrier for entry for new internals hacker lower. Sam Tregar <[EMAIL PROTECTED]> wrote: > Really? Do you honestly believe there are more Java programmers than C > programmers? Particularily

Re: Meta-design

2000-12-06 Thread Bradley M. Kuhn
`eval STRING'. I see no reason to ghettoize powerful non-C-based systems just because we write the canonical perl6 implementation in Perl. Soon, there will likely be JVM systems that can run eval($string) quickly enough, but not if it is written in C (as there is no C->JVM compiler).

Re: Meta-design

2000-12-06 Thread Bradley M. Kuhn
#x27;t have a native C compiler (i.e., the JVM). I think that's the first and foremost concern with eval($string) (and hence, the parser). Slow things can usually be made faster, but "can't get there from here" is often hard to solve. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

this was only an academic example (was Re: Meta-design)

2000-12-06 Thread Bradley M. Kuhn
Sorry. I didn't mean those should be methods Scalars have! I was just trying to show the kind of documentation I'd like to see. I wasn't trying to produce said documentation. :) -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

documenting interfaces (was Re: Meta-design)

2000-12-06 Thread Bradley M. Kuhn
ace should be documented outside of the implementation. I was just concerned because much of the internals has been C-specific thus far. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Perl6 in Java? (was Re: Meta-design)

2000-12-06 Thread Bradley M. Kuhn
going to change with the release of GCC 3.0, based on current benchmarks of test releases of GCC 3.0. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: Meta-design

2000-12-05 Thread Bradley M. Kuhn
ith both the performance and ease of use. The argument is: "Computers do a better job at memory allocation than humans do by hand, so let the computer do it!" I think we should give this idea some serious consideration. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: Proposal for groups

2000-12-04 Thread Bradley M. Kuhn
Some people who aren't on the design team may want to follow the progress, but aren't particularly interested in the public list. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: Perl's parser and lexer will likely be in Perl (was Re: RFC 334 (v1) I'm {STILL} trying to understand this...)

2000-10-17 Thread Bradley M. Kuhn
some toke.re). Larry brought this up in his talk. Of course, I believe that Larry was sleep-deprived at the time, too. ;) > It was late though. Might have been sleep deprevation talking. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Larry's ALS talk

2000-10-16 Thread Bradley M. Kuhn
[dragged this thread to [EMAIL PROTECTED], where it is probably better discussed. Please honor Reply-To:] Leon Brocard wrote: > Bradley M. Kuhn sent the following bits through the ether: > > > It should be noted that in Larry's speech on Friday, he said that he wanted >

Perl's parser and lexer will likely be in Perl (was Re: RFC 334 (v1) I'm {STILL} trying to understand this...)

2000-10-15 Thread Bradley M. Kuhn
set of Perl. :) (I was the only one who clapped, which either means: (a) this is not a popular idea (b) there weren't many Perl6 hackers in the crowd (c) I am extremely over-exited about the prospect of writing the lexer and parser in Perl. :) -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: Perl Implementation Language

2000-09-19 Thread Bradley M. Kuhn
subset of Perl that buys you a full Perl parser. So, I'd like to see the parser written in a simple subset of Perl or some other small language that can be bootstrapped fast. And, if we pick a simple subset of Perl, translating to efficient C probably shouldn't be too hard. Does this argument make sense? Comments welcome. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

other parts of the guts playing with raw access (was Re: A tentative list of vtable functions)

2000-09-02 Thread Bradley M. Kuhn
M port to support what they are doing out of the box. My concern is just that _other parts of the core_ treat these vtable interfaces as a firewall, and do not "reach in" past them. If we find out they have to "reach in" later for performance, I see no problem with that. I just don't want the design to depend on "reaching in". -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: A tentative list of vtable functions

2000-08-31 Thread Bradley M. Kuhn
that the more of the perl core that relies on specific representations of data, the more complexity there is in porting to other architectures. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: A tentative list of vtable functions

2000-08-31 Thread Bradley M. Kuhn
> arrays and hashes and wedge them in too. Why not make the scalar, array, and hash vtables each be separate RFCs? Or, am I over-engineering the problem? -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: Removing stuff to shareable thingies

2000-08-30 Thread Bradley M. Kuhn
Dan Sugalski wrote: > At 04:25 AM 8/30/00 -0400, Bradley M. Kuhn wrote: > > > 2) Having a mechanism to automagically load in chunks of executable code > > > only when needed would be nice > > > >I would take this one a bit further: > > > > 2a) It s

Re: Removing stuff to shareable thingies

2000-08-30 Thread Bradley M. Kuhn
y have gone beyond a subset of Perl they sought to stay within. This is primarily for compiling Perl to be run on embedded devices. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

how small is small? (was Re: RFC 146 (v1) Remove socket functions from core)

2000-08-30 Thread Bradley M. Kuhn
epped out of the subset (see my other post on another thread for more stuff about that). My hope is that the perl6 (note case) will be able to provide me the hooks I'd need to do that. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: Optional Separate Programs for Interpreter Passes

2000-08-30 Thread Bradley M. Kuhn
27;t care much myself *how* it is done here, but something non-hokey would be good. ;) -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: RFC 146 (v1) Remove socket functions from core

2000-08-24 Thread Bradley M. Kuhn
on happen automagically in the parser? (My gut says "here there be dragons", but they don't seem like dragons that are unslayable.) -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

How to facilitate ports to other bytecode architectures (was Re: .NET IL)

2000-08-24 Thread Bradley M. Kuhn
For Perl5, I am currently using Kawa as the Java IR and what B:: provides (for lack of something better) as the Perl IR. This is why I want such a clearly defined API for the IR and for any internal data structures used by the IR---I'd like to write a backend that morphs the Perl IR into the "Java IR" to generate JVM bytecode. Dan, does that fit with your thinking? -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: RFC 131 (v1) Internal String Storage to be Opaque

2000-08-18 Thread Bradley M. Kuhn
> Internal String Storage to be Opaque > Number: 131 > =item Why a single internal encoding? FWIW, I would like to throw my support behind this proposal. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: .NET IL

2000-08-17 Thread Bradley M. Kuhn
nguage". As the JVM porter, I'd like my life easy, but I don't expect perl6 to hand me a JVM implementation---I just want to right components and interfaces so it is not as hard as a job as it is for perl5. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: Program lifecycle

2000-08-10 Thread Bradley M. Kuhn
ed the execution engine very far from the IR. Whether or not we want to have an execution engine (which I tend to call a VM :) that works directly on the IR or one that always goes through bytecode, or both, I think we must keep a high wall of abstraction between the IR and the VM. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: RFC 35 / Re: perl6-internals-gc sublist

2000-08-07 Thread Bradley M. Kuhn
lity version that maintains both. I agree with that. I believe we sould push as much as we can into the vtbl. This will make reimplmentation of Perl guts in say, Java, much easier. :) -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Re: ffcall GPL -> LGPL

2000-08-04 Thread Bradley M. Kuhn
ly, I have yet to find out how the process works to create new top-level working groups. Of course, it could be that no one has gotten time to figure out that procedure. That's understandable. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

Where to get RFCs?

2000-08-02 Thread Bradley M. Kuhn
#x27;t see them. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature

opcodes (was Re: Stuff in core (was Re: date interface, on language (wasRe: perl6 requirements, on bootstrap)))

2000-08-02 Thread Bradley M. Kuhn
ely coupled, you cannot work with one without the other. I don't have any clear ideas yet on how they might be separated yet, but I might have an RFC on that forthcoming in the months to come. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature