Michael Lazzaro:
# Brent Dax wrote:
# >
# > I was writing up some docs (in a perldoc-like style--we can always
# > change the form later, but the content is important), and started
# > working on documenting references. I ended up with this bit:
#
# I imagine (if there are no objections) that
Brent Dax wrote:
>
> I was writing up some docs (in a perldoc-like style--we can always
> change the form later, but the content is important), and started
> working on documenting references. I ended up with this bit:
I imagine (if there are no objections) that the general perldoc writing
style
I was writing up some docs (in a perldoc-like style--we can always
change the form later, but the content is important), and started
working on documenting references. I ended up with this bit:
*** BEGIN DOCS ***
=head3 Autovivification
Actually, one of the features of the extra-sigil mentioned
> Then if they read through the initial stuff and _still_ like Perl :-)
> they'll go out and buy a book or two on the subject, which they will
> study. Once they get familiar with the language, they'll go buy
> another few more specialized books, according to their interest.
I wouldn't bank too m
> -- whereas Perl has
> gotten a *bad* reputation from outsiders, who say the language is
> completely incomprehensible.
To clarify: Perl5 has gotten quite a bit of flak for being opaque,
write-only-read-never, whatever they want to call it. I am not
_agreeing_ with these statements, nor should
"Joseph F. Ryan" wrote:
> I think the biggest concern should be converts from perl 5. Most people
> will
Should we be focus on converting perl5 people, or converting people
completely new to Perl? My hope is that perl5 folks won't need much
convincing -- perhaps a tutorial/summary of changes --
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Sat, 09 Nov 2002 19:20:58 -0500
> From: "Joseph F. Ryan" <[EMAIL PROTECTED]>
> X-Accept-Language: en-us, en
> Cc: [EMAIL PROTECTED]
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> Michael Lazzaro wrote:
>
> >"Joseph
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Sat, 09 Nov 2002 14:43:42 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
> We can make some guesses based on our own experiences, and they might be
> close, except that I think we are a profoundly self-selected group.
> There may b
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Sat, 9 Nov 2002 22:24:20 +
> From: Andrew Wilson <[EMAIL PROTECTED]>
>
> > - Operators
> > - Precedence
> > - Superpositional
>
> These are now called Junks (From Junctions)
Iie, these are now called "Junction
[EMAIL PROTECTED] wrote:
Joseph F. Ryan writes:
Siction 0 :
General concepts . ( this is usually the most difficult part of a rich
language ( and perl5 / perl6 )
compile-phase / run-phase / more ???
...many more... all things that we will be back-referencing all the
time. may be this is ju
Hi, Michael,
I personally like perldoc.com documentation .
I think that for now we do not need a comrehensive reference.
we just need a series of more or less connected and ( not to be afraid
if ) overlapping esseis on particular topic with many code examples
which may be after collected ( in
Michael Lazzaro wrote:
"Joseph F. Ryan" wrote:
Angel Faus wrote:
I think that the best way would be to create an schema of a language manual,
and fill the documents as we proceed reviewing the Apocalypses.
Agreed -- we should certainly figure out the overall structure first,
befo
Joseph F. Ryan writes:
Siction 0 :
General concepts . ( this is usually the most difficult part of a rich
language ( and perl5 / perl6 )
compile-phase / run-phase / more ???
many more... all things that we will be back-referencing all the
time. may be this is just good glossary.
(It se
"Joseph F. Ryan" wrote:
> Angel Faus wrote:
> >I think that the best way would be to create an schema of a language manual,
> >and fill the documents as we proceed reviewing the Apocalypses.
Agreed -- we should certainly figure out the overall structure first,
before doing much else. I think tha
On Sat, 09 Nov 2002 13:21:06
Michael Lazzaro wrote:
>Markus Laire wrote:
>> On 9 Nov 2002 at 18:56, Andrew Wilson wrote:
>> > I will be happy to be proved wrong about this but I have a feeling that
>> > too much attention to detail will get us bogged down.
>>
>> I also think that we shouldn't
On Sat, Nov 09, 2002 at 04:49:42PM -0500, Joseph F. Ryan wrote:
> Angel Faus wrote:
>> I think that the best way would be to create an schema of a language
>> manual,
>> and fill the documents as we proceed reviewing the Apocalypses.
>>
>> Something like this:
>>
>> Section 1 - Language Referenc
Angel Faus wrote:
Should start small. No tutorials until docs & tests are done. No
working on A3 until A2 behaviors are *locked*, to whatever extent that
proves possible.
Comments?
I think that the best way would be to create an schema of a language manual,
and fill the documents as we
Carlos Ramirez wrote:
> I like Rex's all-in-one reference guide
> http://www.rexswain.com/perl5.html
>
> And perldoc.com for a more comprehensive reference resource ;)~
It's true, I use perldoc all the time. :-) Beats trying to "less"
through the man pages by a wide shot. Let me ask you, Carl
Markus Laire wrote:
> On 9 Nov 2002 at 18:56, Andrew Wilson wrote:
> > I will be happy to be proved wrong about this but I have a feeling that
> > too much attention to detail will get us bogged down.
>
> I also think that we shouldn't try to provide too exact and final
> documentation at once. Ju
Richard Nuttall wrote:
>
> Michael Lazzaro wrote:
>
> >Here's some notes based on the first bits of feedback -- something to
> >throw rocks at, as it were.
> >
> >
> >"The overall project goal is to produce documentation that will:"
> >
> >(1) define precise semantics for the Perl6 language; disc
On 9 Nov 2002 at 18:56, Andrew Wilson wrote:
> Starting small sounds like a good idea. I'm not so sure about trying to
> "lock things down" before moving on. I don't think that will be
> possible in any meaningful way. The problem with trying to lock things
> down is that the design team are re
On Fri, Nov 08, 2002 at 06:50:03PM -0800, Michael Lazzaro wrote:
> Conversations on this mailing list are going to look a lot like
> perl6-language, except more aggressively focused on one narrow area at a
> time. Starting from data types & behaviors, moving on to operators,
> then blocks, conditi
Michael Lazzaro writes:
> This message is to open the perl6-documentation list. First things
> first, can we get a quick roll call of who is interested in this
> effort, at least in abstract principle? No point in having
> discussions unless/until there is a critical mass here.
>
> If you wish t
Michael Lazzaro wrote:
Here's some notes based on the first bits of feedback -- something to
throw rocks at, as it were.
"The overall project goal is to produce documentation that will:"
(1) define precise semantics for the Perl6 language; discover and
document ambiguous possible behaviors and
>
> Should start small. No tutorials until docs & tests are done. No
> working on A3 until A2 behaviors are *locked*, to whatever extent that
> proves possible.
>
> Comments?
>
I think that the best way would be to create an schema of a language manual,
and fill the documents as we proceed revi
Nicholas Clark wrote:
On Sat, Nov 09, 2002 at 11:09:39AM -, [EMAIL PROTECTED] wrote:
-interpreter->ctx.int_reg_base->prev = NULL;
It's not likely to be a portability problem, as I seem to remember that the C
FAQ is only able to mention one very obscure platform where NULL was not
On Sat, Nov 09, 2002 at 11:09:39AM -, [EMAIL PROTECTED] wrote:
> -/* Initialize the integer register chunk */
> -interpreter->ctx.int_reg_base->used = 0;
> +/* Initialize the register chunks */
>interpreter->ctx.int_reg_base->free = FRAMES_PER_INT_REG_CHUNK;
> -
Dan Sugalski wrote:
At 8:58 PM +0100 11/6/02, Leopold Toetsch wrote:
If we want this, then lets have Parrot_{re,}allocate{,zeroed}.
The allocate_string variants are ok with unzeroed mem already.
Which was my thought here. Things that care can ask for zeroed memory,
which they may get anywa
After removing IntQueue this is the state of memory leaks[1] (i386/linux):
Failed Test Status Wstat Total Fail Failed List of failed
---
t/op/hacks.t 21 50,00% 1
t/op/rx.t23
I think tutorials and code samples are a good start, especially to get
started. In addition a reference manual (list) of builtins for quick
lookups like perfunc would be helpful too.
I like Rex's all-in-one reference guide
http://www.rexswain.com/perl5.html
And perldoc.com for a more comprehens
Better late then never...count me in.
Michael Lazzaro wrote:
This message is to open the perl6-documentation list. First things
first, can we get a quick roll call of who is interested in this effort,
at least in abstract principle? No point in having discussions
unless/until there is a cri
Leopold Toetsch wrote:
If no one hollers, I'll remove the IntQueue class.
- only used in some tests AFAIK
- functionality may be written in terms of intlist push/pop
- has a weird syntax for queue/dequeue
- is broken WRT memory management and clone
IntQueue is history.
Please run 'make realcl
32 matches
Mail list logo
