On 1 Oct 2002 at 18:47, [EMAIL PROTECTED] wrote:
> > > all text up to, but not including the string "union".
> >
> > rule getstuffbeforeunion { (.*?) union | (.*) }
> >
> > "a union" => "a "
> > "b" => "b"
>
> hmm... well, it works, but its not very efficient. It basically
> scans the whole st
On Mon, Sep 30, 2002 at 11:22:02PM -0400, Michael G Schwern wrote:
> Last year at JAOO I stumbled on this thing called Subject-Oriented
> Programming which looked interesting.
There are a bunch of "advanced" programming techniques like this that
all fit under the same umbrella:
* Subject Ori
On Tue, Oct 01, 2002 at 05:04:29PM -0700, Michael Lazzaro wrote:
> On Tuesday, October 1, 2002, at 02:49 PM, Michael Lazzaro wrote:
> >Which implies, I assume, that "interface" is not the default state of
> >a class method, e.g. we do need something like "method foo() is
> >interface { ... }" t
On Tue, Oct 01, 2002 at 04:01:26PM -0700, Michael Lazzaro wrote:
> >On Tue, Oct 01, 2002 at 03:43:22PM -0400, Trey Harris wrote:
> >>You want something like
> >>
> >> class Car is Vehicle renames(drive => accel)
> >>is MP3_Player renames(drive => mp3_drive);
>
> I *really* like this,
On Tue, Oct 01, 2002 at 02:49:49PM -0700, Michael Lazzaro wrote:
> >>My musing is that the behavior of a class in different contexts is
> >>itself an interface, in the sense of being a contract between a
> >>class/subclass and it's users
> >
> >Ah HA! Contract! Return values can be enforce via a
On Wed, Oct 02, 2002 at 10:39:17AM +0300, Markus Laire wrote:
> On 1 Oct 2002 at 18:47, [EMAIL PROTECTED] wrote:
>
> > > > all text up to, but not including the string "union".
> > >
> > > rule getstuffbeforeunion { (.*?) union | (.*) }
> > >
> > > "a union" => "a "
> > > "b" => "b"
> >
> > hmm
On Wednesday, October 2, 2002, at 03:11 AM, Andy Wardley wrote:
> There are a bunch of "advanced" programming techniques like this that
> all fit under the same umbrella:
>
> * Subject Oriented Programming (IBM)
> * Aspect Oriented Programming (Xerox Parc)
> * Composition Filters
> * Ada
On Wed, 2 Oct 2002, Erik Lechak wrote:
> I was wondering if you could take a look at it and tell me if it has any
> merrit, or if I should not waste my time on it and get back to the
> "getting started guide".
Have you had a chance to look at doxygen? It doesn't support Perl, but
Perl is on the
On Wed, Oct 02, 2002 at 03:46:33PM +0200, Leopold Toetsch wrote:
> Nicholas Clark wrote:
>
> >On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
> >>+if (buffer->bufstart && !(buffer->flags &
> >>+(BUFFER_COW_FLAG|BUFFER_external_FLAG))) {
> >>+free(buffe
> On 1 Oct 2002 at 18:47, [EMAIL PROTECTED] wrote:
>
> > > > all text up to, but not including the string "union".
How about (Perl6)
/(.*?) union {$pos -= length('union');}/
This gets everything up to and including the first instance of 'union',
then gets rid of the bit at the end that w
Sean O'Rourke wrote:
>Have you had a chance to look at doxygen? It doesn't support Perl, but
>Perl is on the todo list, and (at least a couple of years ago) its C++
>support was pretty impressive.
>
>http://www.stack.nl/~dimitri/doxygen/
>
>/s
>
>
>
I'm looking at it right now. Thanks for t
I hate to say this, but I'm still in favor of POD. It has all of the
functionality required
and is the official commenting style of parrot and perl. I personally find
POD distasteful,
but since it is the norm, then I think we should stick with it.
- Original Message -
From: "Erik Lechak"
On Wed, 2 Oct 2002, Erik Lechak wrote:
> I'm looking at it right now. Thanks for the link. This is the first
> time I have heard of doxygen.
I meant the pointer at least partly as a reminder that this is one wheel
we shouldn't have to reinvent. I think there are plenty of solutions out
there t
All~
I disagree.
I don't like Java that much (for many reasons), but I have nothing but
respect for the massive amount of documentation that is easily accessible as
a direct result of JavaDoc. I personnaly feel that it greatly helped java
achieve the success it has. If all of parrot's module w
> I disagree.
>
> I don't like Java that much (for many reasons), but I have nothing but
> respect for the massive amount of documentation that is easily accessible
as
> a direct result of JavaDoc. I personnaly feel that it greatly helped java
> achieve the success it has. If all of parrot's mod
On Thu, Oct 03, 2002 at 12:26:53AM -0400, Matt Fowles wrote:
> I don't like Java that much (for many reasons), but I have nothing but
> respect for the massive amount of documentation that is easily accessible as
> a direct result of JavaDoc. I personnaly feel that it greatly helped java
> achiev
Hi,
I'm using a Pentium 200 (well, Cyrix actually) with 32 MB of RAM, gcc
2.95.4, linux 2.2.17 and parrot out of CVS. Without swap, when I do
"make", compiling core_ops_cg.c fails due to lack of memory. Which is
unsurprising, as it is pretty big. It works if I use a 70 MB swap
partition.
Shou
On a related note, are there any good tools for static code analysis
around? The usual cross-reference stuff would be handy, but ideally
something that goes further.
Graphical would be good, interactive better (or at least cooler :).
Perhaps something like www.kartoo.com (needs flash) or
http://
As already posted I incorparated the allocator from
http://gee.cs.oswego.edu/dl/html/malloc.html
in parrot.
Some remarks:
- it's totally stable now, runs all tests (parrot and perl6)
- memory consumption is like CVS or much less ...
- ... if resources.c is unpatched (#17702)
- runs almost[1] eve
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17722]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17722 >
Some recent change in P6C did break examples/mandel.p6.
Please apply,
TIA,
leo
--
On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
> As already posted I incorparated the allocator from
> http://gee.cs.oswego.edu/dl/html/malloc.html
> in parrot.
>
> Some remarks:
> - it's totally stable now, runs all tests (parrot and perl6)
> - memory consumption is like CVS o
On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
> As already posted I incorparated the allocator from
> http://gee.cs.oswego.edu/dl/html/malloc.html
> in parrot.
Whatever source you are using cannot be the original Lea malloc, since it does
not do garbage collection. There are m
Jason Gloudon wrote:
> On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
> Whatever source you are using cannot be the original Lea malloc, since it does
> not do garbage collection.
* VERSION 2.7.2 Sat Aug 17 09:07:30 2002 Doug Lea (dl at gee)
There seems to be no need for
Nicholas Clark wrote:
> On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
>>+if (buffer->bufstart && !(buffer->flags &
>>+(BUFFER_COW_FLAG|BUFFER_external_FLAG))) {
>>+free(buffer->bufstart);
>>+}
> The article doesn't mention garbage collection at
Jason Gloudon wrote:
> There are many comments indicating that the GNU C
> library uses a derived version of Lea malloc.
$ pwd
/software/source/glibc-2.1.3/malloc
$ grep Lea$ malloc.c
This work is mainly derived from malloc-2.6.4 by Doug Lea
I don't have any later glibc sources handy to check.
David Chan:
# I'm using a Pentium 200 (well, Cyrix actually) with 32 MB of
# RAM, gcc 2.95.4, linux 2.2.17 and parrot out of CVS. Without
# swap, when I do "make", compiling core_ops_cg.c fails due to
# lack of memory. Which is unsurprising, as it is pretty big.
# It works if I use a 70 MB
On Wed, Oct 02, 2002 at 08:26:20AM -0700, Brent Dax wrote:
> David Chan:
> # I'm using a Pentium 200 (well, Cyrix actually) with 32 MB of
> # RAM, gcc 2.95.4, linux 2.2.17 and parrot out of CVS. Without
> # swap, when I do "make", compiling core_ops_cg.c fails due to
> # lack of memory. Which
Having decided that life.pasm was not going to get much
better (58 seconds for 5000 generations vs 118 for CVS),
I have been looking at other areas for improvements.
Arrays seem to be one such area, as the current CVS code
expands arrays by creating a new one and copying all the
data. I believe L
[EMAIL PROTECTED] (Peter Gibbs) writes:
> On my machine, CVS parrot completes the above in
> an elapsed time of 13 minutes; grey takes 14 seconds.
> Changing the iteration count to 25000 takes 1 second
> with grey versus 46 seconds for CVS.
That's great, but what impact does it have on access
Nicholas Clark wrote:
>
> Which in C terms scares me, as *how* can the allocator know for sure?
> Sure it can stack walk, and probe all the CPU registers for pointers to buffers,
> but there are defined C behaviours you can do (such as storing only a pointer
> somewhere into your buffer at fix
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17731]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17731 >
As adviced by Dan, this patch integrates the possibility of using a
Lea-like alloca
Peter Gibbs wrote:
> Simon Cozens wrote:
>>Put another loop in, which sets I1 to every array element in turn,
>>(maybe make this an inner loop which runs each time you extend) and
>>re-benchmark.
> 25000: CVS = 47 seconds, grey = 1 second
Please compare to intlist.
leo
I did post 3 major proposals for the next big changes in parrot
internals - but I'm lacking somehow final answers on these.
There seems to be a general consens to do these changes though.
So here is a summary of the next changes to parrot:
1) restructure class dependencies
(s. #17352, #173
After my posting "Status of my patches" a lot of patches went in -
thanks again to Tom. But now unapplied patches accumulate again e.g.
imcc, perl6 examples ...
So please ...
leo
At 2:01 PM +0200 10/2/02, Leopold Toetsch wrote:
>As already posted I incorparated the allocator from
>http://gee.cs.oswego.edu/dl/html/malloc.html
>in parrot.
>
>Some remarks:
>- it's totally stable now, runs all tests (parrot and perl6)
>- memory consumption is like CVS or much less ...
>- ...
At 12:15 PM +0100 10/2/02, Tim Bunce wrote:
>On a related note, are there any good tools for static code analysis
>around? The usual cross-reference stuff would be handy, but ideally
>something that goes further.
If someone wants to build some and there are things that parrot
doesn't provide th
At 5:27 PM +0200 10/2/02, Peter Gibbs wrote:
>On my machine, CVS parrot completes the above in
>an elapsed time of 13 minutes; grey takes 14 seconds.
Cool. Since this is a PMC class, I expect, and thus self-contained
(right? :) it ought to be fine to check it in as an alternate array.
If you co
Dan Sugalski wrote:
> At 2:01 PM +0200 10/2/02, Leopold Toetsch wrote:
>
>> As already posted I incorparated the allocator from
>> http://gee.cs.oswego.edu/dl/html/malloc.html
>> in parrot.
>>
>> Some remarks:
>> - it's totally stable now, runs all tests (parrot and perl6)
>> - memory consumpti
Peter Gibbs wrote:
> I have been looking at other areas for improvements.
> Arrays seem to be one such area, ...
Yep
> This is using a singly linked list of variable sized chunks,
> without a separate index array. Each chunk is created
> with a minimum size (4 entries at present), then doubl
Simon Cozens wrote:
> That's great, but what impact does it have on access to individual
> elements? If you're not careful, you may find that accessing stuff in
> the array gets quite seriously slower. Linked lists being O(n) access
> and all that...
I certainly hope that access gets slower, othe
Leopold Toetsch wrote:
> Peter Gibbs wrote:
> Did you look at indexed access, shift, unshift, splice ;-)
I have simply modified classes/array.pmc, which does not yet
implement shift or unshift; grey aims to provide alternative
implementations, rather than add new functionality. However,
since Dan
Hi,
I asked a while ago if a "getting started manual" was a good idea. But
I got caught up on another issue, the format. I spent a couple of days
throwing together this demo of a self documenting comment style that can
be used in perl and c without the compiler freaking out. It also works
42 matches
Mail list logo
