On Tue, 16 Jul 2002, John Porter wrote:
>
> > But what about setting size on multdimensional PMC's
> > would it also be:
> > set P0,5,5,5
> > assembler.pl would try to call
> > set_p_ic_ic_ic
> > This will break things when having N dimensions..
>
> I don't see how it could possible b
Hi
Some of you (Dan) knows that I'm working on a project to generate Parrot
code from a specification programming language.
On these language, data-structures are very similar with mathematical
constructs. I will need a finite mapping (or finite function) which maps
objects (any type) to object
Melvin Smith wrote:
> Hmm, looking at the source directory, I'm starting to think
> maybe that isn't so good, it is pretty busy already.
>
> We have one vote for a /dev directory.
Actually, I think Dan did -- or at least was going to do --
something about this last night. Part of it was to sho
I noticed this morning that my parrot_coverage cron job was broken, so the
stats at http://www.hitchhiker.org/parrot_coverage/ weren't updating properly.
They should be correct now.
--Josh
--
Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
The following patch brings the MANIFEST file up-to-date with recent
additions. I haven't committed this in case some other reorganization
(e.g. moving stuff to a src/ or dev/ or doc/ directory) is underway.
There are also a few minor shuffles as I've re-sorted the MANIFEST.
Andy Dougherty
On Wed, Jul 17, 2002 at 12:32:43AM -0400, Mark J. Reed wrote:
> On Tue, Jul 16, 2002 at 05:42:18PM -0400, Michael G Schwern wrote:
> > I don't know how Java and Python handle Unicode.
> Java has always been 100% Unicode from the ground up; it's in the spec.
> The fundamental char type is a 16-bit
At 4:17 PM +0100 7/17/02, Nicholas Clark wrote:
>On Wed, Jul 17, 2002 at 12:32:43AM -0400, Mark J. Reed wrote:
>> On Tue, Jul 16, 2002 at 05:42:18PM -0400, Michael G Schwern wrote:
>> > I don't know how Java and Python handle Unicode.
>> Java has always been 100% Unicode from the ground up; it'
On Wed, Jul 17, 2002 at 04:17:15PM +0100, Nicholas Clark wrote:
> My understanding was that Unicode has now escaped the base plane (or whatever
> it's called) and now has started using code points >65536. How does Java
> cope with this?
This is getting a little off-topic, I think. But here's a br
On Wed, Jul 17, 2002 at 12:13:47PM -0400, Dan Sugalski wrote:
> I thought Java used UTF-16. It's a variable-width encoding, so it
> should be fine. (Though I bet a lot of folks will be rather surprised
> when it happens...)
UTF-16 isn't technically a variable-width encoding, since
surrogate code
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:30 AM -0400 7/16/02, Karl Glazebrook wrote:
> >I still feel this adds yet another layer of inconsistency and
> >confusion. I can't look at a piece of code and know what it does,
> >without referring up N lines to the top of the scripts.
> >
> >
At 12:34 PM -0400 7/17/02, Mark J. Reed wrote:
>On Wed, Jul 17, 2002 at 12:13:47PM -0400, Dan Sugalski wrote:
>> I thought Java used UTF-16. It's a variable-width encoding, so it
>> should be fine. (Though I bet a lot of folks will be rather surprised
>> when it happens...)
>UTF-16 isn't techni
On Wed, 17 Jul 2002, Andy Dougherty wrote:
> The following patch brings the MANIFEST file up-to-date with recent
> additions. I haven't committed this in case some other reorganization
> (e.g. moving stuff to a src/ or dev/ or doc/ directory) is underway.
>
> There are also a few minor shuffles
I'm happy to see new documentation, including the .dev files, appearing
in parrot. However, I do have a small concern that we not set ourselves
in a position of maintaining multiple copies of the same information.
To be specific, I looked at byteorder.dev and noted a listing of all the
functions
Yes, after looking at this, I agree with Andy (and don't worry I don't think
you're picking on it,
I picked a small file so we could play with it until we found what we liked)
that it is a maintenence
headache to duplicate all of the functions.
However, I do think it is nice to be able to look at
We have one vote for docs/dev.
Daniel Grunblatt.
On Wed, 17 Jul 2002, Melvin Smith wrote:
> At 06:14 PM 7/16/2002 -0700, John Porter wrote:
>
> >Melvin Smith wrote:
> > > I put it temporarily in the root dir, which I know is wrong.
> > > Where should .dev files go, anyway?
> >
> >Actually, I t
# New Ticket Created by Mike Lambert
# Please include the string: [perl #15006]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=15006 >
This is a rather major refactoring of the GC code which I believe makes
the code muc
Tanton Gibbs wrote:
> . . . That saves a person digging through
> the .c file to find what they are looking for.
> Perhaps we could automatically update the .dev
> file with the POD found in the .c file?
As someone else has already said, a better place
for the .dev information might be inside t
There should be no Makefile.in's left in the source--they've been tossed
in favor of config/gen/makefiles.
Andy Dougherty:
# --- parrot-cvs/MANIFEST Sat Jul 13 13:04:15 2002
# +++ parrot-andy/MANIFEST Wed Jul 17 11:46:50 2002
# @@ -12,16 +12,15 @@
# VERSION
# assemble.pl
# byteorder
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [perl #15009]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=15009 >
This file is intended to be languages/perl6/t/compiler/5.t. It tests
perl6-style
On Wed, 17 Jul 2002, Brent Dax wrote:
> There should be no Makefile.in's left in the source--they've been tossed
> in favor of config/gen/makefiles.
Fair enough. I just took what cvs handed me. It was a fresh checkout as
of yesterday, updated this morning. Whoever removes those files from the
That's a good point. Perhaps the .dev file are superfluous.
If that is the case then all we need to do is change the .c file
header to contain the POD comments and then
intersperse POD in the code as Andy did. Then
we can eliminate the .dev files and replace them with
a utility that will allow v
John Porter:
# Tanton Gibbs wrote:
# > . . . That saves a person digging through
# > the .c file to find what they are looking for.
# > Perhaps we could automatically update the .dev
# > file with the POD found in the .c file?
#
# As someone else has already said, a better place
# for the .dev in
Applied.
Daniel Grunblatt.
On Wed, 17 Jul 2002, Sean O'Rourke wrote:
> # New Ticket Created by "Sean O'Rourke"
> # Please include the string: [perl #15009]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=15009 >
>
>
Brent Dax wrote:
> Do you really want to see a ten-page discussion of hashing
> algorithms and why the current one was chosen in the middle
> of classes/perlhash.pmc?
I guess that wouldn't bother me as much as it might bother
some other people.
> *That's* the sort of thing the .dev files are f
On Wed, 17 Jul 2002, John Porter wrote:
> As someone else has already said, a better place
> for the .dev information might be inside the .c
> file itself.
> I for one find the separation unnatural,
> uncustomary, and de-sync-prone.
> Frankly I just don't see what it buys us.
Obviously, in princ
Andy Dougherty wrote:
> I think the purpose of the .dev files, as laid out in
> docs/pdds/pdd07_codinstd.pod, is a reasonable one.
> Here's an edited excerpt: . . .
(Thanks, Andy.)
Well, given that definition of the purpose, I must
persist in my opinion that the proper place for that
kind of d
Austin Hastings:
# --- Dan Sugalski <[EMAIL PROTECTED]> wrote:
# > At 8:30 AM -0400 7/16/02, Karl Glazebrook wrote:
# > >I still feel this adds yet another layer of inconsistency and
# > >confusion. I can't look at a piece of code and know what it does,
# > >without referring up N lines to the to
I'm putting together my presentations for TPC (one of the reasons
I've been missing the past few days). There's going to be a good
round of acknowledgements in the State of the Parrot talk. If you've
contributed and *don't* want to be recognized, this would be the time
to speak up.
--
At 04:50 PM 7/17/2002 -0400, Dan Sugalski wrote:
>I'm putting together my presentations for TPC (one of the reasons I've
>been missing the past few days). There's going to be a good round of
>acknowledgements in the State of the Parrot talk. If you've contributed
>and *don't* want to be recogni
On Wed, Jul 17, 2002 at 03:56:39PM -0400, Andy Dougherty wrote:
> In practice, what we need is a supporting culture and infrastructure to
> make it most likely that useful documentation will get written and be
> in a place you can find it.
> Obviously, in practice, judgment will be needed for any
># New Ticket Created by Mike Lambert
># Please include the string: [perl #15006]
># in the subject line of all future correspondence about this issue.
># http://bugs6.perl.org/rt2/Ticket/Display.html?id=15006 >
Tickets from RT don't have an address in the To: line
and so my mailfilter is fil
In message <[EMAIL PROTECTED]>
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> On Wed, 17 Jul 2002, Brent Dax wrote:
>
> > There should be no Makefile.in's left in the source--they've been tossed
> > in favor of config/gen/makefiles.
>
> Fair enough. I just took what cvs handed me. It w
very recently I wrote:
> ... fine. Whatever.
People, if I'm coming across with a nasty or petulant tone,
I sincerely apologize. It's really not what I was going for.
jdp
__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://aut
On Wed, Jul 17, 2002 at 01:42:17PM -0700, John Porter wrote:
>
> Andy Dougherty wrote:
> > I think the purpose of the .dev files, as laid out in
> > docs/pdds/pdd07_codinstd.pod, is a reasonable one.
> > Here's an edited excerpt: . . .
>
> (Thanks, Andy.)
>
> Well, given that definition of the
On Wed, Jul 17, 2002 at 10:38:47PM +0100, Dave Mitchell wrote:
> One of the reasons I used numerical accuracy as an example was because
> in Perl 5, Nick's mini-essay on his stirling work *is* buried somewhere
> in the middle of the 10,000 line sv.c, and thus probably hasn't been seen
> by most pe
On Mon, Jan 21, 2002 at 12:21:41PM +, Simon Glover wrote:
>
> Please, people, if you create new files, remember to add them to the
> MANIFEST.
Is CVS flexible enough to let us run a manifest check on each commit
and generate warnings that get sent somewhere useful if it fails?
I seem to re
On Wed, Jul 17, 2002 at 11:13:58PM +0100, Nicholas Clark wrote:
> On Wed, Jul 17, 2002 at 10:38:47PM +0100, Dave Mitchell wrote:
> > One of the reasons I used numerical accuracy as an example was because
> > in Perl 5, Nick's mini-essay on his stirling work *is* buried somewhere
> > in the middle
For what it's worth, I agree. I think that when your documentation is
tied to the structure of your source files, it only makes sense to put it
IN the source files.
I don't think you can do literate programming half-way. While I don't
think literate programming is the right thing to do to p
As the message says. Code freeze tonight at midnight EDT (GMT-0400).
I'll be tagging with PRE_REL_0.0.7 then.
Features to be included:
Perl 6 grammar
Partial perl6 compiler
Pure-perl assembler
Heavily patched and upgraded intermediate language
Massive patching in general, cleaned-up PMCs.
FORTH
Melvin (and the rest of you... :)
Are subroutine PMCs at a point where we can use them? If not, that's
fine, but if so, they can go on the list 'o things. (And we can add
global variables, if they didn't make it in the 0.0.6 release notes)
--
Dan
-
Applied, thanks..
At 09:16 PM 7/17/2002 -0400, Dan Sugalski wrote:
>Melvin (and the rest of you... :)
>
>Are subroutine PMCs at a point where we can use them? If not, that's fine,
>but if so, they can go on the list 'o things. (And we can add global
>variables, if they didn't make it in the 0.0.6 release notes)
Jeff wrote:
>
> As the message says. Code freeze tonight at midnight EDT (GMT-0400).
> I'll be tagging with PRE_REL_0.0.7 then.
Code slush at 2200, code freeze at 0030. Tag was actually named
PRE_REL_007.
> Features to be included:
>
> Perl 6 grammar
> Partial perl6 compiler
> Pure-perl assemb
43 matches
Mail list logo
