Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:12 PM -0700 6/11/04, Matt Fowles (via RT) wrote:
This patch adds the above Fixed*Array classes. They are basic tests for
all of them included too, although more tests never hurts...
With MANIFEST patch even! Woohoo!
Applied, thanks.
1) Is there
At 12:53 PM -0500 6/13/04, Matt Fowles wrote:
Nicholas~
I will try to answer what I can, based on my current experience
making those array PMCs.
Nicholas Clark wrote:
a data pointer
which I can use. I am always responsible for freeing anything there(?)
and to do this I need to
At 11:57 AM +0200 6/14/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:12 PM -0700 6/11/04, Matt Fowles (via RT) wrote:
This patch adds the above Fixed*Array classes. They are basic tests for
all of them included too, although more tests never hurts...
With MANIFEST
At 11:01 AM +0100 6/13/04, Nicholas Clark wrote:
I'm trying to work out how to make PMCs. I'm not finding much documentation,
and I'm not sure what I'm missing. Particularly I'm trying to work out where
I'm allowed to store data, and what flags I might have to set
I'll write up something more
On Mon, Jun 14, 2004 at 08:53:10AM -0400, Dan Sugalski wrote:
At 12:53 PM -0500 6/13/04, Matt Fowles wrote:
Nicholas~
I will try to answer what I can, based on my current experience
making those array PMCs.
Nicholas Clark wrote:
a data pointer
which I can use. I am always
At 2:33 PM +0100 6/14/04, Nicholas Clark wrote:
On Mon, Jun 14, 2004 at 08:53:10AM -0400, Dan Sugalski wrote:
At 12:53 PM -0500 6/13/04, Matt Fowles wrote:
Nicholas~
I will try to answer what I can, based on my current experience
making those array PMCs.
Nicholas Clark wrote:
a data
At 12:42 AM -0700 6/13/04, Matt Fowles (via RT) wrote:
This patch adds Resizable*Array pmcs as the counterparts to Fixed*Array
pmcs. It does so by inheriting from them, so the Fixed ones are changed
too.
Applied, thanks.
--
Dan
Dan Sugalski wrote:
At 11:57 AM +0200 6/14/04, Leopold Toetsch wrote:
1) Is there any good reason to start now malloc(3) based array classes?
This leads to code duplication for all the utility vtable entries (like
Csplice). Fsrc/list.c can deal with all types already.
list.c's pretty inefficient
At 4:56 PM +0200 6/14/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 11:57 AM +0200 6/14/04, Leopold Toetsch wrote:
1) Is there any good reason to start now malloc(3) based array classes?
This leads to code duplication for all the utility vtable entries (like
Csplice). Fsrc/list.c can deal with
At 5:04 AM -0700 6/13/04, Bernhard Schmalhofer (via RT) wrote:
I have been looking into languages/Makefile and tried to update and beautify
it.
Cool. Applied, thanks.
--
Dan
--it's like this---
Dan Sugalski
Dan Sugalski [EMAIL PROTECTED] wrote:
At 12:42 AM -0700 6/13/04, Matt Fowles (via RT) wrote:
This patch adds Resizable*Array pmcs as the counterparts to Fixed*Array
pmcs. It does so by inheriting from them, so the Fixed ones are changed
too.
Applied, thanks.
- duplicates existing PMCs
For some reason I haven't been able to figure out, perl5.00503 can't seem
to handle the TODO test in t/pmc/object-meths.t. Here's the result of
perl5.005 t/harness t/pmc/object-meths.t
t/pmc/object-meths..FAILED test 19
Failed 1/21 tests, 95.24% okay
Failed Test Status Wstat Total
At 5:50 PM +0200 6/14/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 12:42 AM -0700 6/13/04, Matt Fowles (via RT) wrote:
This patch adds Resizable*Array pmcs as the counterparts to Fixed*Array
pmcs. It does so by inheriting from them, so the Fixed ones are changed
too.
Since we're going to need these, and I'm in a documenting and
defining mood (yes, I am making a final decision on strings today.
Whee!) I figure we need to tackle them.
First, slices. Perl's got 'em, Python has them, Ruby, interestingly,
doesn't. (Sort of) A slice is a subset of elements in an
Once we decide how to *get* these things (see the previous e-mail) we
need to decide how they should work. We can fiddle around, but
honestly the scheme:
1) They act as arrays--if you want the 18th element in the iterator,
access it directly
2) They have 'next', 'previous', 'first', 'last',
Dan~
Just a few questions.
Dan Sugalski wrote:
2) They have 'next', 'previous', 'first', 'last', and 'reset' methods
to get the next, previous, first, or last element in the iterator, or
to reset the iterator to the beginning. Next, last, and reset change
the internal current element pointer,
At 1:15 PM -0500 6/14/04, Matt Fowles wrote:
Dan~
Just a few questions.
Dan Sugalski wrote:
2) They have 'next', 'previous', 'first', 'last', and 'reset'
methods to get the next, previous, first, or last element in the
iterator, or to reset the iterator to the beginning. Next, last,
and reset
Dan Sugalski writes:
Once we decide how to *get* these things (see the previous e-mail) we
need to decide how they should work. We can fiddle around, but
honestly the scheme:
1) They act as arrays--if you want the 18th element in the iterator,
access it directly
2) They have 'next',
Dan Sugalski writes:
The slice vtable entry should take as its parameter a slice pmc. This
should be an array of typed from/to values, so we can do something
like:
@foo[0..2,4..8,12..];
with three entries in the slice array--one with a from/to of 0/2, one
with 4/8, and one with
At 1:08 PM -0600 6/14/04, Luke Palmer wrote:
Dan Sugalski writes:
Once we decide how to *get* these things (see the previous e-mail) we
need to decide how they should work. We can fiddle around, but
honestly the scheme:
1) They act as arrays--if you want the 18th element in the iterator,
At 1:21 PM -0600 6/14/04, Luke Palmer wrote:
Dan Sugalski writes:
The slice vtable entry should take as its parameter a slice pmc. This
should be an array of typed from/to values, so we can do something
like:
@foo[0..2,4..8,12..];
with three entries in the slice array--one with a from/to
At 8:15 PM +0100 6/14/04, Alex Gough wrote:
[Sat, Jun 12, 2004 at 11:39:27AM +0200: [EMAIL PROTECTED]
| Time for these as well. There's a partial implementation of them in
| types/bignum.c. I think it's time to move that to src/ (and the
| header file to .h) and get it integrated into
At 3:40 PM -0400 6/14/04, Dan Sugalski wrote:
At 8:15 PM +0100 6/14/04, Alex Gough wrote:
[Sat, Jun 12, 2004 at 11:39:27AM +0200: [EMAIL PROTECTED]
| Time for these as well. There's a partial implementation of them in
| types/bignum.c. I think it's time to move that to src/ (and the
|
Did we ever come to some consensus of what a character (that is a
sequence of code points which makes up a single atomic thing in a
language) should be called? I seem to remember grapheme being
not-quite-correct, but I can't dig up the better answer. (And yes,
the string doc is being finished.
The official, 1.0, final version, modulo a more correct name for
'grapheme', or spelling/grammar errors.
Do please note that whatever objection you may have to this has at
least three people who disagree differently, and one or more (who
aren't me) who agree with what you disagree with. Also
[Sat, Jun 12, 2004 at 11:39:27AM +0200: [EMAIL PROTECTED]
| Time for these as well. There's a partial implementation of them in
| types/bignum.c. I think it's time to move that to src/ (and the
| header file to .h) and get it integrated into parrot.
I'm not really sure if
On Mon, Jun 14, 2004 at 12:00:42PM -0400, Andy Dougherty wrote:
For some reason I haven't been able to figure out, perl5.00503 can't seem
to handle the TODO test in t/pmc/object-meths.t. Here's the result of
5.5.3's Test::Harness doesn't know how to handle that style of TODO.
You'll have to
At 4:39 PM -0400 6/14/04, Michael G Schwern wrote:
On Mon, Jun 14, 2004 at 12:00:42PM -0400, Andy Dougherty wrote:
For some reason I haven't been able to figure out, perl5.00503 can't seem
to handle the TODO test in t/pmc/object-meths.t. Here's the result of
5.5.3's Test::Harness doesn't know
On Mon, 2004-06-14 at 14:26, Dan Sugalski wrote:
5.5.3's Test::Harness doesn't know how to handle that style of TODO.
You'll have to make a dependency on T::H 2.x if you want to use TODO.
Is there another style of TODO that could be used here that would be
compatible with 5.005_03?
None
Has anyone run into immediate core dumps on Fedora Core 1? When I run
'make' the interpreter successfully compiles, but dumps core when it
tries to compile parrotlib.imc.
: blib/lib/libparrot.a
c++ -o parrot -Wl,-E -g imcc/main.o blib/lib/libparrot.a
blib/lib/libicuuc.a blib/lib/libicudata.a
Since I know this is going to come up, I figure I should pre-empt it
and be done with it. (Though I should've put this in the string
document. Ah, well. Hopefully timing isn't everything, or I am *so*
in trouble...)
Why aren't we converting to Unicode on the edge? Since, after all,
any Sane
Dan Sugalski writes:
At 1:21 PM -0600 6/14/04, Luke Palmer wrote:
Dan Sugalski writes:
The slice vtable entry should take as its parameter a slice pmc. This
should be an array of typed from/to values, so we can do something
like:
@foo[0..2,4..8,12..];
with three entries in the
Dan Sugalski writes:
At 1:08 PM -0600 6/14/04, Luke Palmer wrote:
Dan Sugalski writes:
Once we decide how to *get* these things (see the previous e-mail) we
need to decide how they should work. We can fiddle around, but
honestly the scheme:
1) They act as arrays--if you want the 18th
Sorry to reply to this, but I feel that this is a request for
clarifications, not for a change. :^)
Dan Sugalski wrote:
Synthesized code points
===
...
becomes two integers, 0x0041 and 0x82A9. (Though it could
represent them as 16-bit integers, since no character
34 matches
Mail list logo
