On Mon, 31 Dec 2001, Clark C . Evans wrote:
> Hello. I was wondering if Parrot is going to support
> Generators. A generator is a function that returns
> multiple times, and I believe, was first made available
> in the language ICON. Now, ICON may have taken it a
> bit too far (everything is
On Sat, 29 Dec 2001, Boris Tschirschwitz wrote:
> I suggest
> opcode_t* code_start
So what does this declare:
opcode_t* code_start, code_end;
If you said two pointers to opcode_t then you just got fooled by your
notation! If you want to move the '*' then it has to go to the RHS since
On Sun, 9 Dec 2001, David Jacobs wrote:
> +for (i = 1; size > i; i <<= 1);
Infinite loop if size == MAXINT, eh? "So don't do that." Ok.
-sam
On Sun, 2 Dec 2001, Michael L Maraist wrote:
> On Sunday 02 December 2001 02:47 pm, Brent Dax wrote:
> > Quick comment: I've been thinking about constructing an 'OpaqueHandle'
> > PMC type. All the programmer is supposed to know about it is that it
> > points to Something (usually a C struct, bu
On Sat, 1 Dec 2001, Dan Sugalski wrote:
> At 01:20 PM 12/1/2001 -0500, Jeff G wrote:
> >I'll probably pull out perl5's snprintf function and
> >add it to the vtables.
>
> Unfortunately I'll say the dreaded "L" word here...
>
> Licensing.
Wow, are we still running this project without a license?
On Thu, 8 Nov 2001, Dan Sugalski wrote:
> Yes, it is a bug. There's an array in list context--it's supposed to be
> flattened before the foreach loop gets evaluated. (And if there are
> multiple arrays in the list it works as you'd expect)
Sorry, I quoted the wrong section. It really isn't a bu
On Thu, 8 Nov 2001, Brent Dax wrote:
> That doesn't support your argument. The point is that in the statement:
>
> foreach(@array) {
> ...
> }
>
> @array should only be evaluated once, at the beginning of the loop. In
> effect (using := here, but otherwise Perl 5 code)
On Thu, 8 Nov 2001, Dan Sugalski wrote:
> Gack. Looks like a mis-placed optimization in perl 5. The list of a foreach
> is *supposed* to flatten at loop start and be static. Apparently not. :)
>
> Care to file the perl 5 bug report, or shall I?
It's not a bug. Check out the "Foreach Loops" sect
On Sun, 28 Oct 2001, Simon Cozens wrote:
> You are all encouraged to write implementations of the vtable functions
> in scalarclass.c
Cool. So, what needs to get done first? By that I mean, what is standing
in the way of our creating tests for scalar PMCs? Maybe I'm anal
retentive, but I don'
On Fri, 26 Oct 2001, Dan Sugalski wrote:
> Okay, here are the conventions.
Great. Anyone want to offer up some examples or should I just wait for
Jako support to see this in action?
-sam
On Fri, 26 Oct 2001, Brent Dax wrote:
> What if I want my compiler to be lazy? Do you have the right to punish
> me for my laziness by making me add constant folding to my optimizer (or
> perhaps making me *write* an optimizer just to do constant folding)?
Actually, a really lazy compiler will
On Thu, 25 Oct 2001, Dan Sugalski wrote:
> The only bits of the interpreter that much care about the
> string data are the regex engine parts, and those only operate on
> fixed-sized data.
Care to elaborate? I thought the mandate from Larry was to have regexes
compile down to a stream of string
On Tue, 23 Oct 2001, Dan Sugalski wrote:
> At 12:05 PM 10/23/2001 -0400, Sam Tregar wrote:
> >PS: CVS! CVS! CVS CVS CVS!
>
> Someone send me the files needed for Scheme and I'll check 'em in.
I'll leave that to Jeff since it's his baby. You'll probabl
Here's a patch to re-fix comparisions in the Scheme compiler. The
patch:
- Makes (<),(>),(<=),(>=) and (=) behave correctly on more than two
args.
- Adds tests to affirm this and fixes tests that were incorrect.
Sidenote: I don't think it's going to be possible to do static type
inf
Fresh checkout won't compile on Redhat Linux 7.1:
string.c: In function `string_compare':
string.c:161: warning: passing arg 1 of pointer to function from
incompatible pointer type
string.c:161: too few arguments to function
string.c:164: warning: passing arg 1 of pointer to function from
incompa
On 20 Oct 2001, Gregor N. Purdy wrote:
> I want to libify everything to the point where Perl wrappers around
> the libs allow you to pass the .pasm stuff as a string and get back
> a packfile that you can pass on to the interpreter, without firing
> off separate processes and writing files.
Soun
Here's a patch to fix logical ops in the Parrot Scheme compiler. The
patch:
- Implements (min) and (max) which had stubs and some =pod'd out code
which I couldn't understand.
- Fixes (=), (<), (>), (<=) and (>=) to work with more than 2 operands.
Added tests where they were miss
Why is "make test" so durn slow? Our tools run individually seem pretty
snappy on my low-end box (P200/64MB) but running "make test" is like
watching paint dry. I'm seeing something like 1 test per second!
Please feel free to point me to TFM if this question is answered there.
-sam
On Fri, 19 Oct 2001, Jeff wrote:
> For a -very- primitive Scheme -> Parrot compiler, see
>
> http://216.254.0.2/~jgoff/Files/scheme.tar.gz
Woo hoo!
> Test files (using the provided version of Test::More) are in the t/
> directory, and can be run by typing 'make test' at the command line. The
>
On Thu, 11 Oct 2001, Dan Sugalski wrote:
> Did we put a patch into parrot that lets you fetch the current PC and store
> it in an integer register? I seem to recall someone did, but I can't find it.
That's the '@' thing I was talking about making a doc patch for. I then
realized that I didn't u
On Sat, 6 Oct 2001, Gregor N. Purdy wrote:
> After the bytecode is loaded, but before it is executed, put it through
> a stage of processing that requires about as much information as a
> disassembler would (which is why my op_info stuff from one of my previous
> patches is required).
>
> This pr
Am I correct that '@' in the assembly syntax is undocumented? The only
place I could find it was in source comments in Parrot::Assembler. I had
to search for @ to find it. Believe me, the last thing you want to search
for in a Perl module is @.
I think a patch to docs/parrot_assembly.pod would
On Sun, 30 Sep 2001, Nick Ing-Simmons wrote:
> The main problem with perl5 and threads is that threads are an afterthought.
Which, of course, also goes for "UNIX and threads" and "C and threads".
It's good for us to be thinking about as early as possible but it's no
garauntee that there won't be
On Thu, 20 Sep 2001, Dan Sugalski wrote:
> FWIW, my 600MHz Alpha clocks in at around 23M ops/sec. Nyah! ;-P
My PIII 700Mhz gets 23M. Well, ok, to get above 21M I had to make a
slight alteration (below). Damn Alphas and their "superior technology".
-sam
RCS file: /home/perlcvs/parrot/interpre
On Tue, 18 Sep 2001, Damien Neil wrote:
> Proposed: Parrot should never crash due to malformed bytecode. When
> choosing between execution speed and bytecode safety, safety should
> always win.
I don't see this as a safety issue. There's nothing unsafe about
crashing. It's just not as pretty
On Sat, 15 Sep 2001, Philip Kendall wrote:
> My personal view would be that the gains due to portable bytecode would
> be outweighed by the amount of cruft we'd have to put into the
> interpreter to get them. As Nicholas Clark and someone else who's name
> I've forgotten[1] mentioned, there are p
> Patches should be sent to the perl6-internals mailing list, where I'll take a
> look at them and apply them to the CVS tree.
Ooo, ooo - me first. Since you turned on -Wall in the Makefile I thought
it would be nice if it compiled without warnings. Below is a patch that
does that on my system
On Mon, 3 Sep 2001, Brent Dax wrote:
> Now is where the temp() stuff I was talking about earlier comes in.
>
> sub foo {
> my($bar);
> foo();
> }
>
> is basically equivalent to
>
> sub foo {
> temp($MY::bar);
> foo();
>
On Mon, 3 Sep 2001, Dan Sugalski wrote:
> I'm not entirely sure how much this'll be used, but I really, *really* want
> to be able to call any sub that qualifies as an op rather than as a sub.
What would a sub have to do (be?) to qualify?
> >I don't understand this restriction. Won't it make i
On Mon, 3 Sep 2001, Dan Sugalski wrote:
> >avoid using a "call" opcode all over the place, right?
>
> No, more a "try and leave the bytecode sections read-only" hack.
>
> Imagine, if you will, building LWP and bytecode compiling it. It uses
> private opcodes 1024-1160. Then you later build, say,
On Mon, 3 Sep 2001, Dan Sugalski wrote:
> Basically chunks of perl code can define opcodes on the fly--they might be
> perl subs that meet the proper critera, or opcode functions defined by C
> code with magic stuck in the parser, or wacky optimizer extensions or
> whatever. There won't be a sing
On Mon, 3 Sep 2001, Nathan Torkington wrote:
> > Ok, so one example of a PMC is a Perl string...
>
> If you grok vtables, think of a PMC as the thing a vtable hangs off.
>
> Another way to think of it is that a PMC is an object. To the outside
> (the interpreter that is manipulating data values)
On Sun, 2 Sep 2001, Simon Cozens wrote:
> For instance, the Parrot VM will have a register architecture, rather
> than a stack architecture.
s/rather than/as well as/; # we've got a stack of register frames, right?
> There will be global and private opcode tables; that is to say, an area
> of
On Sun, 2 Sep 2001, Brent Dax wrote:
> Okay, I forgot to account for the fact that we'd have to increment the
> refcount for every inner scope a my() variable is referred to in.
> That's not terribly hard, is it?
I have no idea what you're talking about here. You asked if it was
possible to fak
On Sun, 2 Sep 2001, Brent Dax wrote:
> but in that case the inner my($x) could be translated to
> temp($MY::x)--the behavior is basically the same. (Actually, if pads
> are replaced with stashes, is there any situation where my($x) can't be
> translated to temp($MY::x)? Hmmm...)
Closures, for
On Thu, 30 Aug 2001, Simon Cozens wrote:
> I could spend a lot of time justifying it to you here and now, or I
> could spend the same time writing a detailed specification of the
> interpreter interface. I think, to be honest, it might be more
> productive for me to take the second option.
I agr
On Thu, 30 Aug 2001, Simon Cozens wrote:
> That's not entirely relevant any more. Parrot has a semi-autonomous
> existence as a generic bytecode interpreter. We may be a long way
> from having a language spec, but we're pretty damned close to having
> a spec for the interpreter.
I look forward t
On Thu, 30 Aug 2001, Uri Guttman wrote:
> we have very strong internal specs already that will support most
> anything larry throws at us. stuff such as the op code loop, async
> (file) i/o, events, etc, are all known to be needed so we can code them
> now that the design is firming up. we have t
On Wed, 29 Aug 2001, Simon Cozens wrote:
> It's almost time to start coding, people, almost.
Not to be an ass, but is it? It seems like we're still a long way from
having a language spec.
-sam
On Sat, 25 Aug 2001, Nathan Torkington wrote:
> I'd like to keep the code on Sourceforge from the get-go. I don't
> have much experience with Sourceforge, though, and would like to talk
> to someone who has. Which bits work well? Which bits aren't worth
> the effort? Any tips or tricks to pas
On Mon, 6 Aug 2001, Dan Sugalski wrote:
> No, he's right. Not dirtying cache lines is pretty much always faster than
> dirtying them, and not twiddling with memory's faster than twiddling. And
> unfortunately we can't really do fully platform-dependent code, since it'll
> be the actual bytecode t
On Mon, 6 Aug 2001, Hong Zhang wrote:
> It is not just for performance, the stack size and cache
> locationality are also big issues.
Cache sizes and timings vary from machine to machine. Maybe we should
make it configurable at compile-time? If we do that then there's no
reason to try to guess
On Mon, 30 Jul 2001, Dan Sugalski wrote:
> When you actually use a module, the simple name (like IO) will be
> internally expanded out to the three value thing. So if you have two
> modules that each use a different version of the same module, they won't
> interact because each will be dealing wi
On Fri, 8 Jun 2001, Jarkko Hietaniemi wrote:
> An interesting article in the July DDJ) in the Algorithm Alley:
> "Fast and Small Resizable Arrays", presents a datastructure that
> promises just what the subject says.
The first thing I thought of after reading the article was "use less
memory"...
On Fri, 16 Feb 2001, Simon Cozens wrote:
> On Fri, Feb 16, 2001 at 08:52:03PM +, Nicholas Clark wrote:
> > macro languages and symbolic debuggers don't mix well.
>
> Generated output would be Real Life C. I'm thinking something along the lines
> of
> perl vtable.pl < vtable.spec > vtable.
On Sat, 10 Feb 2001, Buddha M Buck wrote:
> I think what he's thinking (in C terms) would be more like the following:
Right. It already has a technical name - copy-on-write. I should have
made it more clear that I recognized the intended mechanism. I was trying
to demonstrate that Perl-level
On Sat, 10 Feb 2001, Branden wrote:
> Suppose I have a string stored in $foo, say, "abcbca", and then I do:
>
> $bar = $foo;
> $foo .= "xyzyzx";
>
> I see two ways of doing this: one is allowing a string value to be shared by
> two or more variables, and the other one not.
Why would you
On Wed, 3 Jan 2001, Dan Sugalski wrote:
> I think one of the things we might want to do is figure out what people use
> signals for and see if we can abstract out some of that functionality
> without actually exposing signals. (From an internals standpoint, at least)
Well, one thing people use s
On Thu, 7 Dec 2000, Bradley M. Kuhn wrote:
> Now, I would agree that there are more C hackers about. However, many
> people are graduating college with computer science degrees having worked
> mostly in Java and very little in C. In 6 years or so, we may find that
> there are more Java hackers
On Thu, 7 Dec 2000, Simon Cozens wrote:
> On Thu, Dec 07, 2000 at 11:22:35AM -0500, John Porter wrote:
> > [C++]
>
> > It's nearly as portable,
>
> Uhm. Is this actually true? C runs pretty much anywhere.
>
> Are there any non-fragile implementations of C++ yet?
Which also brings up another poin
On Wed, 6 Dec 2000, Bradley M. Kuhn wrote:
> And, it will make the barrier for entry for new internals hacker lower.
Really? Do you honestly believe there are more Java programmers than C
programmers? Particularily in the Perl development community!
> I would note that if we write in Java, we
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> Sure, but only objects. (or, to be really paranoid, things referred to)
> Nothing else needs refcounting. All the refcounting code can be isolated in
> the reference creation and deletion code, and we don't have to pay it
> otherwise.
Good point. I hadn
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> Non-refcounting GC schemes are more expensive when they collect, but less
> expensive otherwise, and it apparently is a win for the non-refcount
> schemes.
Which is why GC is intimately tied to DESTROY consideration in terms of
Perl. If we intend to hon
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> >my $new_dog;
> >{
> > my $dog = new Dog;
> > $new_dog = \$dog;
> >}
>
> That would hoist the Dog reference into an outer level of scope--in this
> case the one containing $new_dog. Or so my thinking goes at the moment,
> though th
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> What I'm thinking is that we'll have a scoped destruct stack that gets
> pointers to variables that explicitly need destruction, and as we exit
> levels of scope we call the destructors of those variables that need it.
> (They can still be GC'd later to p
On Tue, 5 Dec 2000, Alan Burlison wrote:
> How about writing the documents in XML and having a 'perl specification'
> DTD?
> ...
> Death to POD!
Can we *please* not re-fight this war? I know you remember the last
couple incarnations of XML VS POD. Just replay them in your mind and
enjoy the sh
On Sat, 2 Dec 2000, Nathan Torkington wrote:
> * it's difficult for the design to happen through the questions
Is that really true? Have we tried? As far as I can tell we've got a
lot of well-intentioned people that for whatever reason are spending very
little time making Perl 6 happen.
Let
On Tue, 10 Oct 2000, Tim Bunce wrote:
> > A very complete UML tool in Java is ArgoUML:
> >
> > http://argouml.tigris.org/
>
> Umm, it might be interesting for someone to add a Perl code generator
> for it...
I've played with the idea of adding Perl code-generation to my design
tools (Visio200
On 14 Sep 2000, Chaim Frenkel wrote:
> (Someone remind me, What is the point of -T if not running setuid?)
All you need to get root is an unprivilaged shell on anything but a
fully patched machine. A dumb Perl CGI running without -T is all you need
to get a shell.
Besides, I bet most online st
On Tue, 29 Aug 2000, Nick Ing-Simmons wrote:
> David L . Nicol <[EMAIL PROTECTED]> writes:
> >
> >does sysV shm not support the equivalent security as the file system?
>
> mmap() has the file system.
I wasn't aware that mmap() was part of SysV shared memory. My
mistake? It's not on the SysV IP
On Tue, 29 Aug 2000, David L. Nicol wrote:
> does sysV shm not support the equivalent security as the file system?
Well, no, I don't think it does. It supports permissions on individual
segments but it doesn't support anything like directory perimssions. It
might be enough, and it might not be
On Tue, 29 Aug 2000, David L. Nicol wrote:
> Well then. It is impossible to rearchitect it to make it shared
> text? Perhaps the first instance of perl sets up some vast shared
> memory segments and a way for the newcomers to link in to it and look
> at the modules that have been loaded, somewh
On 20 Aug 2000, Chaim Frenkel wrote:
> SWM> Does Perl6 support Symmetric MultiProcessing (SMP)?
Perl5 does - see 'fork'. I'm guessing that Perl6 will have at
least that much support.
> SWM> This is a *huge* issue. It affects everything else that we do with
> SWM> threads.
Most operating syst
On Fri, 18 Aug 2000, Graham Barr wrote:
> > No. The documentation states that the compilation is done only when the
> > source file is out of date with the companion object file. As I
> > understand it, Inline has some kind of limited automatic make ability.
>
> So it is a security issue then a
On Thu, 17 Aug 2000, Nick Ing-Simmons wrote:
> Simon Cozens <[EMAIL PROTECTED]> writes:
> >Wow. I'm sold. Can this be how we should be doing XS in Perl 6?
> So we now run equivalent of xsubpp and cc every time script is run?
No. The documentation states that the compilation is done only when the
On 4 Aug 2000, Perl6 RFC Librarian wrote:
> This proposal introduces a new keyword to perl, "co", as a complement
> to "sub". A subroutine is defined thusly:
>
> co foo { ... }
>
> Coroutines can also be closures:
>
> my $x = co { ... }
Does this really require a new keyword? Why not do
On Tue, 1 Aug 2000, John Tobey wrote:
> The people here are rightly skeptical about the effectiveness of using
> the 5.6 code base as a starting point for v6, but I have a pretty
> clear vision of how to do it, and I am committed to giving it a try,
> even if no one else will. In fact, I'll give
On Tue, 1 Aug 2000, John Tobey wrote:
> I'm thinking of a rewrite in the sense that (by my impression) BSD was
> a rewrite of Unix. Refactoring, shifting stuff around until it's easy
> to get a handle on things, and replace it all a little at a time. So,
> yes, these problems can be solved IMHO
On Tue, 1 Aug 2000, John Tobey wrote:
> Umm, well, not necessarily. Not if what I'm doing becomes what we're
> doing.
Do tell! What have you been doing?
> See http://joel.editthispage.com/stories/storyReader$47 on the
> evils of total rewrites.
This article has been haunting me. My boss lo
On Tue, 1 Aug 2000, Simon Cozens wrote:
> Counter-counterproposition: Look at the way Sapphire does it. I'm really
> proud of that. It's automagically switchable from inlines to ordinary
> functions to macros. You can choose which wins, and it's neat to debug.
Counter-counter-... Sure I'll take
On Tue, 1 Aug 2000, John Tobey wrote:
> I propose that all internal and external functions be implemented in
> header files and declared inline. The external runtime API will be
> generated by compiling non-inline wrappers.
>
> This will make possible an interesting performance optimization wit
71 matches
Mail list logo
