Gordon Henriksen wrote:
>
> Benjamin Goldberg wrote:
>
> > Gordon Henriksen wrote:
[snip]
> > > [3] Unshift hack #1: Where commit appears in the above, exit the
> > > grammar, trim the beginning of the string, and re-enter. (But that
> > > forces the grammar author to discard the regex state, whe
Benjamin Goldberg wrote:
> Gordon Henriksen wrote:
>
> > Having a lazily slurped file string simply delays disaster, and
> > opens the door for Very Big Mistakes. Such strings would have to be
> > treated very delicately, or the program would behave very
> > inefficiently or crash.
>
> Although
Gordon Henriksen wrote:
>
> Now, I don't really have much of an opinion on compound strings in
> general. I do want to address one particular argument, though—the lazily
> slurped file string.
>
> On Thursday, August 21, 2003, at 07:22 , Benjamin Goldberg wrote:
>
> > A foolish question: can you
Dan Sugalski wrote:
>
> At 12:07 AM -0400 8/19/03, Benjamin Goldberg wrote:
> >There are a number of shortcomings in the API, which I'd like to address
> >here, and propose improvments for.
>
> You're conflating language level strings with low-level strings. Don't.
>
> STRINGs, the parrot stru
At 10:01 AM +0200 8/22/03, Leopold Toetsch wrote:
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
I have problems imaginating such kind of STRINGs.
You lack sufficient imagination -- Larry's suggested that Perl6 strings
may consist of a list of chunks. I can easily imagine
At 12:57 PM +0200 8/21/03, Peter Gibbs wrote:
If the string API is to be revised, I would like to suggest that
consideration be given to having a single string vtable, merging
the current encoding and chartype structures into a single one.
I think this has been addressed, but in case it hasn't... w
At 12:07 AM -0400 8/19/03, Benjamin Goldberg wrote:
There are a number of shortcomings in the API, which I'd like to address
here, and propose improvments for.
You're conflating language level strings with low-level strings. Don't.
STRINGs, the parrot structure and what S registers point to, are
Now, I don't really have much of an opinion on compound strings in
general. I do want to address one particular argument, though—the lazily
slurped file string.
On Thursday, August 21, 2003, at 07:22 , Benjamin Goldberg wrote:
A foolish question: can you imagine strings which are lazily read fr
On Thu, Aug 21, 2003 at 06:37:52PM -0400, Benjamin Goldberg wrote:
>
>
> Nicholas Clark wrote:
> > Particularly when the regexp engine is written assuming O(1) random
> > access.
>
> It doesn't *need* to assume O(1) random access; after all, it's never
> accessing *randomly*, it's always access
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> I have problems imaginating such kind of STRINGs.
> You lack sufficient imagination -- Larry's suggested that Perl6 strings
> may consist of a list of chunks. I can easily imagine each of those
> "chunks" being full-fledged
Leopold Toetsch wrote:
>
> Benjamin Goldberg wrote:
>
> >
> > Leopold Toetsch wrote:
> > Not having an INTERP argument severely limits us, even in other ways.
>
> The INTERP argument is fine. The user defined encoding is/was my
> problem.
As in, you think we shouldn't have any, at all?
> > Sim
Nicholas Clark wrote:
>
> On Wed, Aug 20, 2003 at 07:19:42PM -0400, Benjamin Goldberg wrote:
>
> > Leopold Toetsch wrote:
>
> > > But these could be converted to utf32 as soon as they are seen.
> >
> > For a long string, that could be quite a bit of bloat.
>
> Jarkko's view is that the combin
On Thu, 21 Aug 2003, Elizabeth Mattijsen wrote:
> At 14:15 +0100 8/21/03, Nicholas Clark wrote:
> >On Wed, Aug 20, 2003 at 07:19:42PM -0400, Benjamin Goldberg wrote:
> > > Leopold Toetsch wrote:
> > > > But these could be converted to utf32 as soon as they are seen.
> > > For a long string, tha
At 14:15 +0100 8/21/03, Nicholas Clark wrote:
On Wed, Aug 20, 2003 at 07:19:42PM -0400, Benjamin Goldberg wrote:
> Leopold Toetsch wrote:
> > But these could be converted to utf32 as soon as they are seen.
> For a long string, that could be quite a bit of bloat.
Jarkko's view is that the combine
On Wed, Aug 20, 2003 at 07:19:42PM -0400, Benjamin Goldberg wrote:
> Leopold Toetsch wrote:
> > But these could be converted to utf32 as soon as they are seen.
>
> For a long string, that could be quite a bit of bloat.
Jarkko's view is that the combined hit of the size of the extra code to skip
In message <[EMAIL PROTECTED]>
Peter Gibbs <[EMAIL PROTECTED]> wrote:
> I do not believe that the two existing parameters are orthogonal,
> so the number of charset (or whatever) entities would be less than
> the cross product. e.g. the existing 2 chartypes x 4 encodings
> would really onl
If the string API is to be revised, I would like to suggest that
consideration be given to having a single string vtable, merging
the current encoding and chartype structures into a single one.
This removes one pointer from each string header, and allows
a single parameter to be used instead of tw
Benjamin Goldberg wrote:
Leopold Toetsch wrote:
Not having an INTERP argument severely limits us, even in other ways.
The INTERP argument is fine. The user defined encoding is/was my problem.
Similarly, that would eliminate the chance of a STRING* which is
actually a lazily concatenated list of
Leopold Toetsch wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > Leopold Toetsch wrote:
> >>
> >> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> >> > There are a number of shortcomings in the API, which I'd like to
> >> > address here, and propose improvments for.
> >>
> >> > To allow
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>
>> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>> > There are a number of shortcomings in the API, which I'd like to
>> > address here, and propose improvments for.
>>
>> > To allow user-defined encodings, and user-defined tr
Tim Bunce wrote:
>
> On Tue, Aug 19, 2003 at 12:07:22AM -0400, Benjamin Goldberg wrote:
> > There are a number of shortcomings in the API, which I'd like to
> > address here, and propose improvments for.
>
> Just to be sure people are keeping it in mind, I'll repost this from
> Larry:
>
> On W
Leopold Toetsch wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > There are a number of shortcomings in the API, which I'd like to
> > address here, and propose improvments for.
>
> > To allow user-defined encodings, and user-defined transcoding,
> > (written in parrot) the first parame
Luke Palmer wrote:
>
> Benjamin Goldberg writes:
[snip]
> >9/ New ops which provide access to the string iterator API.
>
> Yes. What is going to be used to store an iterator. An I reg, a P reg?
> If it's a PMC, would it be possible to just implement the iterator
> itself as a PMC, and use t
On Tue, Aug 19, 2003 at 12:07:22AM -0400, Benjamin Goldberg wrote:
> There are a number of shortcomings in the API, which I'd like to address
> here, and propose improvments for.
Just to be sure people are keeping it in mind, I'll repost this from Larry:
On Wed, Jan 30, 2002 at 10:47:36AM -0800,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> There are a number of shortcomings in the API, which I'd like to address
> here, and propose improvments for.
> To allow user-defined encodings, and user-defined transcoding, (written
> in parrot) the first parameter of all of the function pointers in
Benjamin Goldberg writes:
> I *really* *really* want string iterators. The current API for
> iterating through the characters of a string is, IMHO, vastly
> insufficient.
Not only because it's inconvenient, but it's also essential for doing
pattern matching efficiently on some multibyte encodings
On Thu, 16 May 2002, Nicholas Clark wrote:
> It's not nice. It's enough to drive people loopy, just looking at the output
> of the preprocessor, where one source line has expanded to a 10 line wrapped
> monstrosity so right in parenthesis that it couldn't be written with a dozen
> Lisp fridge mag
Melvin Smith wrote:
> At 10:30 PM 4/8/2002 -0700, Robert Spier wrote:
>>> Keep track of global (or interpreter local) scope with a macro
>>> upon entry.
>> I shudder every time someone says "macro" on p6i.
>> perl5 has several thousand macros defined. (grep for ^#define) (over
> Are you counting
# Keep in mind there is the primitive STRING type which is the S* registers,
# and then there is the PMC (PerlString) which uses vtables.
I am refering to the parrots internal strings e.g. S*
the vtable I am refering to is the 'encoding' vtable of functions in
the string struct (*STRING).encodi
At 01:48 AM 4/9/2002 -0400, Michel J Lambert wrote:
> > the malloc()/free() situation which is one of the primary reasons we
> > use garbage collection in the first place, so why reinvent the same
> > situation with different syntax?
>
>Generally, malloc/free are used in more complex situations th
> I agree we need an overall architectural solution. Setting and clearing
> bits manually is error-prone but fast, as you said. Its identical to
> the malloc()/free() situation which is one of the primary reasons we
> use garbage collection in the first place, so why reinvent the same
> situation
At 10:30 PM 4/8/2002 -0700, Robert Spier wrote:
>>Keep track of global (or interpreter local) scope with a macro
>>upon entry.
>
>I shudder every time someone says "macro" on p6i.
>
>perl5 has several thousand macros defined. (grep for ^#define) (over 8000
>if you include all the embedding macr
> Keep track of global (or interpreter local) scope with a macro
> upon entry.
I shudder every time someone says "macro" on p6i.
perl5 has several thousand macros defined. (grep for ^#define) (over
8000 if you include all the embedding macros. it's down to ~4000 if you
cut out embedding, co
At 11:40 PM 4/8/2002 -0400, Michel J Lambert wrote:
> > 2) I'm thinking of an internal stack not visible to user code that we use
> > for temporary PMCs and Buffers and a simple macro for entry and
> > exit of GC sensitive routines. I think I might have mentioned this.
>
>What defines a
On Mon, Apr 08, 2002 at 11:40:28PM -0400, Michel J Lambert wrote:
> However, if we can't find all the places we do buffer manipulation to mark
> them immortal, how are we going to properly identify all the GC-sensitive
> functions?
Ack! Sorry for being anal, but I finally decided the 'immortal' n
> >This message does remind me of how empty the TODO list is. Surely we
> >can think of many more things to be done?
>
> Speaking of..
>
> 1) Bugfix release please, we banged quite a few stack and GC bugs out.
> Don't we get any dessert?
Peter has already stated he'd like his parrot_realloca
At 06:10 PM 4/8/2002 -0700, Steve Fink wrote:
>On Mon, Apr 08, 2002 at 07:01:44PM -0400, Melvin Smith wrote:
> > At 05:49 PM 4/8/2002 -0400, Roman Hunt wrote:
> > >find the definition for the string_vtable it is not in
> >
> > Try classes/perlstring.pmc
> >
> > Keep in mind there is the pr
On Mon, Apr 08, 2002 at 07:01:44PM -0400, Melvin Smith wrote:
> At 05:49 PM 4/8/2002 -0400, Roman Hunt wrote:
> >find the definition for the string_vtable it is not in
>
> Try classes/perlstring.pmc
>
> Keep in mind there is the primitive STRING type which is the S* registers,
> and then
At 05:49 PM 4/8/2002 -0400, Roman Hunt wrote:
>hello:
> and importance, but I feel up to the task. (Read: "Please, be
> patient with the newbie"). I have begun work on
The more the merrier, its been too quiet this last week.
> find the definition for the string_vtable i
(As previously remarked, I'm trying to catch up from a few days offline,
so excuse me if this is OOD.)
On Tue, 11 Sep 2001, Ken Fox wrote:
> The interpreter knows the internals of the stack structure and is
> responsible for managing it. To change the stack implementation, we'll
> have to caref
On Thu, Sep 13, 2001 at 05:59:13PM +0100, Tom Hughes wrote:
> Especially since all function names starting with str are strictly
> speaking reserved to ANSI/ISO for future expansion of the string.h
> facilities ;-)
Oh blow. If you're worried about namespace pollution, you're definitely
blaming th
In message <[EMAIL PROTECTED]>
Benjamin Stuhl <[EMAIL PROTECTED]> wrote:
> Thus wrote the illustrious Simon Cozens:
> [severely trimmed]
> > STRING* string_make(void *buffer, IV buflen, IV
> > encoding, IV flags, IV type)
> > STRING* string_copy(STRING* s)
> > void string_de
On Tue, Sep 11, 2001 at 09:08:18AM +0100, Simon Cozens wrote:
> > The use of an encoding enum seems a little weird, but once
> > you explain why it will probably make sense. Right now the
> > only thing it seems good for is the transcoding system --
> > everything else is slower and vtables are mo
At 01:35 PM 9/11/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > If you're speaking of multiple buffers for a string or something like that,
> > you're looking at too low a level. That's something that should go in the
> > variables, not in the string bits. (We do *not* want all string ops slo
Dan Sugalski wrote:
> If you're speaking of multiple buffers for a string or something like that,
> you're looking at too low a level. That's something that should go in the
> variables, not in the string bits. (We do *not* want all string ops slow to
> support flexibility of this sort. Only the b
At 12:15 PM 9/11/2001 -0400, Ken Fox wrote:
>Simon Cozens wrote:
> > On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote:
> > > Have you guys seen Topaz?
> >
> > I may have heard of it, yes.
>
>That's it? You're rejecting all of that work without
>learning anything from it? Building strings on
On Tue, Sep 11, 2001 at 12:15:37PM -0400, Ken Fox wrote:
> Simon Cozens wrote:
> > On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote:
> > > Have you guys seen Topaz?
> >
> > I may have heard of it, yes.
>
> That's it? You're rejecting all of that work without
> learning anything from it?
Simon Cozens wrote:
> On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote:
> > Have you guys seen Topaz?
>
> I may have heard of it, yes.
That's it? You're rejecting all of that work without
learning anything from it? Building strings on buffers
looked like a really good idea.
In general I
On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote:
> Have you guys seen Topaz?
I may have heard of it, yes.
> The other major suggestion I have is to avoid "void *"
> interfaces.
I'm using void * to avoid char *. :)
> Do we really need a string_make() that takes
> the encoding enum?
Simon Cozens wrote:
> =head1 The Parrot String API
Have you guys seen Topaz? One of many things I think Chip
did right was to build strings from a low-level buffer
concept. This moves memory management (and possibly raw-io)
out of the string class and into the buffer class.
The other major sugge
At 12:46 PM 9/10/2001 -0400, Jason Gloudon wrote:
>Will the buffers associated with a string be managed by Parrot's memory
>management, and be visible to the garbage collector ? Or will these buffers be
>allocated from their own pool of memory not subject to garbage collection.
They'll be GC'd.
Will the buffers associated with a string be managed by Parrot's memory
management, and be visible to the garbage collector ? Or will these buffers be
allocated from their own pool of memory not subject to garbage collection.
--
Jason
[EMAIL PROTECTED] (Simon Cozens) writes:
> =head2 C
>
> This field is, as its name suggests, unused; however, it can be used to
> hold a pointer to the correct vtable for foreign strings.
Wouldn't it be better to put a vtable * directly inside struct
parrot_string instead of the 'encoding' enum
At 12:53 PM 9/10/2001 +0100, Nicholas Clark wrote:
>On Sun, Sep 09, 2001 at 10:16:27PM +0100, Simon Cozens wrote:
> > =head1 Elements of the C structure
> >
> > Those implementing the C API will obviously need to know about
> > how the C structure works. You can find the definition of this
> > str
--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 10, 2001 at 04:48:35AM -0700, Benjamin Stuhl
> wrote:
> > *cough* Namespace pollution *cough*
> > These should proably all be prefixed...
>
> You're going to have a canary when you see the rest of
> the code... :)
I know. I've looked at t
On Mon, Sep 10, 2001 at 12:53:51PM +0100, Nicholas Clark wrote:
> > void *bufstart;
>
> A split buffer would allow an offset at the front, by effectively treating
> the STRING as '' . 'Pathologically Eclectic Rubbish Lister'
Who says we don't support split buffers? void* bufstart can be an
On Mon, Sep 10, 2001 at 04:48:35AM -0700, Benjamin Stuhl wrote:
> *cough* Namespace pollution *cough*
> These should proably all be prefixed...
You're going to have a canary when you see the rest of the code... :)
Seriously, I see the string subsystem as being self-sufficient; it can be
detached
Thus wrote the illustrious Simon Cozens:
[severely trimmed]
> STRING* string_make(void *buffer, IV buflen, IV
> encoding, IV flags, IV type)
> STRING* string_copy(STRING* s)
> void string_destroy(STRING *s)
*cough* Namespace pollution *cough*
These should proably all be prefixed...
58 matches
Mail list logo
