Re: Regular and Context-Free languages
On Fri, Aug 09, 2002 at 09:50:00PM -0400, Mark J. Reed wrote: > On Fri, Aug 09, 2002 at 05:23:58PM -0700, Steve Fink wrote: > > On Thu, Aug 08, 2002 at 12:05:00AM -0400, Mark J. Reed wrote: > > > Finite state machines can match regular expressions whose only operations > > > are closure (*), alternation (|), and grouping. Some of the other things > > > > Don't forget optional subexpressions (?). Not sure what the official > > name is. > > Don't need 'em. a? === (a|) (a or nothing). Duh. Right. > > They can also handle negation, but nobody ever seems to put that into > > the regex syntax. Probably because the exact semantics get fuzzy when > > you're not anchored at the beginning and end, and any particular > > semantics you might pick are deceptive and/or useless. > > Hm. Not sure about negation. Take a DFA representing a regular expression. Make all nonaccepting states accepting, and all accepting states nonaccepting. Which is really silly if you're not anchoring the expression at both ends: the negation of the pattern "hello", when given the input string "hello", will successfully match "h". Or if you let it run off the end of the input string and keep the last encountered accepting state, as is often done to get the longest match, it will match "hell". > > > (Historically, the grep program has used an NFA, while egrep has > > > used a DFA.) > > > > That sounds backwards. > > It's not. It was the example our prof used, and it's also that way > in table 4-1 of _Mastering_Regular_Expressions_. Hmm, you're right. But my version of egrep has backreferences. I'm confused. > > You should probably also mention somewhere that once you break free of > > the bounds of regularity, it's much easier to implement many features > > and irregular constructs with an NFA rather than a DFA. Like capturing > > parentheses, alternation that prefers the choice the expression gives > > first, etc. > > True. Although with a DFA there's not much reason to add preferential > alternation since it matches just as fast no matter which alternate > matches. Right, but it matters when you're also returning where in the string the pattern matched. (That's why I said "features" in addition to "irregular constructs", because order of alternation has nothing to do with the binary decision of whether to match.) And, of course, when you're doing sick perlish things like embedded code segments...
Re: Regular and Context-Free languages
On Fri, Aug 09, 2002 at 05:23:58PM -0700, Steve Fink wrote: > Wow. Since you went to the trouble of writing all this up, it really > ought to go in a FAQ somewhere. It probably already is in a FAQ somewhere; I just don't know where. :) > On Thu, Aug 08, 2002 at 12:05:00AM -0400, Mark J. Reed wrote: > > Finite state machines can match regular expressions whose only operations > > are closure (*), alternation (|), and grouping. Some of the other things > > Don't forget optional subexpressions (?). Not sure what the official > name is. Don't need 'em. a? === (a|) (a or nothing). > They can also handle negation, but nobody ever seems to put that into > the regex syntax. Probably because the exact semantics get fuzzy when > you're not anchored at the beginning and end, and any particular > semantics you might pick are deceptive and/or useless. Hm. Not sure about negation. > And if you implement the NFA the way you're implying (as a traditional > NFA), you'll always get the same answer to whether or not the > expression matches, but assuming the answer is yes the NFA and DFA > might match different parts of the string. Which doesn't contradict > anything you're saying, but it's good to be aware that the theoretical > purpose for these things (deciding whether a given string matches an > expression or not) is not the same as the common practical purpose > (finding the exact substring within a given string that matches the > expression). True. > > (Historically, the grep program has used an NFA, while egrep has > > used a DFA.) > > That sounds backwards. It's not. It was the example our prof used, and it's also that way in table 4-1 of _Mastering_Regular_Expressions_. > You should probably also mention somewhere that once you break free of > the bounds of regularity, it's much easier to implement many features > and irregular constructs with an NFA rather than a DFA. Like capturing > parentheses, alternation that prefers the choice the expression gives > first, etc. True. Although with a DFA there's not much reason to add preferential alternation since it matches just as fast no matter which alternate matches. > Anyone happen to know where pushdown automata fit in this list? Can > they handle context-sensitive, just context-free, or some other > subset? The set of languages recognizable by pushdown automata (PDAs) is exactly the set of context-free languages. To recognize a context-sensitive language I think you need a Turing machine. I'm not aware of anything intermediate in power between a PDA and a TM. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- "Help, Mr. Wizard!" -- Tennessee Tuxedo
Re: 'while <> {' in Perl 6
On Fri, 9 Aug 2002, Adam Lopresto wrote:
: I was wondering whether the Perl 'while (<>){' idiom will continue to be
: supported in Perl 6? I seem to recall people posting example code the list
: using it (although I can't dig any up), but it seems to me that if Perl 6's
: lazy list implementation is sufficiently smart, it could just be replaced with
: 'for <> {'. The only issues I can see are people using <> inside the loop, and
: maybe something about the scope of $_. (Does a topicalized $_ change the value
: of $_ outside of the loop?)
Of the two constructs, I lean toward only making C topicalize.
Possibly you can force an explicit topicalization on a C
like this:
while something() -> $_ { ... }
(Had an interesting typo there. I put => insteaqd of ->. I wonder
how much trouble that sort of thing is gonna cause. Maybe pairs
can be disallowed or warned about where a pointy sub might be
expected.)
Larry
Re: Regular and Context-Free languages
Wow. Since you went to the trouble of writing all this up, it really ought to go in a FAQ somewhere. On Thu, Aug 08, 2002 at 12:05:00AM -0400, Mark J. Reed wrote: > Finite state machines can match regular expressions whose only operations > are closure (*), alternation (|), and grouping. Some of the other things Don't forget optional subexpressions (?). Not sure what the official name is. They can also handle negation, but nobody ever seems to put that into the regex syntax. Probably because the exact semantics get fuzzy when you're not anchored at the beginning and end, and any particular semantics you might pick are deceptive and/or useless. > You can turn an nondeterministic FA into a deterministic one (a DFA) > by a fairly straightforward algorithm. Basically, each state in the > DFA corresponds to a set of all the possible states the NFA *could* > be in at a given point in a string. So the number of states in > a DFA built from an NFA can be huge; but the machine never has to > backtrack and try again because it knows exactly which transition > to make at each step. So in general, NFAs take less memory but > run slower, while DFAs run faster but take more memory. And if you implement the NFA the way you're implying (as a traditional NFA), you'll always get the same answer to whether or not the expression matches, but assuming the answer is yes the NFA and DFA might match different parts of the string. Which doesn't contradict anything you're saying, but it's good to be aware that the theoretical purpose for these things (deciding whether a given string matches an expression or not) is not the same as the common practical purpose (finding the exact substring within a given string that matches the expression). > (Historically, the grep program has used an NFA, while egrep has > used a DFA.) That sounds backwards. You should probably also mention somewhere that once you break free of the bounds of regularity, it's much easier to implement many features and irregular constructs with an NFA rather than a DFA. Like capturing parentheses, alternation that prefers the choice the expression gives first, etc. > A step up from regular languages are context-free languages, which can > count. C-F languages can be recognized by a variety of different > mechanisms, but not by FSMs. Anyone happen to know where pushdown automata fit in this list? Can they handle context-sensitive, just context-free, or some other subset?
[PATCH] Re: [perl #16024] gt.t has 2 busy CPU loops on 5.005_03
On Tue, Aug 06, 2002 at 10:38:46PM -, Simon Glover wrote:
>
> On Tue, 6 Aug 2002, Nicholas Clark wrote:
>
> > On Tue, Aug 06, 2002 at 10:17:48PM +, Nicholas Clark wrote:
> >
> >
> > chopn S1, 1 # Check that the contents of S1 are no longer constant
> >
> > I spot a trend here.
> >
>
> Yep, it looks like it's the trailing comments that are the problem; the
> code that strips these out was recently patched to fix a different bug
> -- check out change 82 to assemble.pl
>
> Unfortunately, I have no idea why the current code breaks on 5.005_03,
> or what to do about it :-(
The problem seems to be that capture with multiple levels of parenthesis
(even though they are non-capturing) is getting the 5.005_03 regexp engine
stuck, presumably due to the nested quantifiers (the * in $str_re and the
* outside)
Re-writing it as a match makes it take finite time on 5.005_03 (as appended)
I notice 2 things
1: $str_re is being defined several places as my - is there any reason why it
and the other building block regexps aren't defined once at the top of the
file
2: $str_re is always interpolated. In 5.x series qr// interpolation is done
by stringifying the rexexp, string interpolation and then recompiling,
isn't it? In which case it would be faster to define the building block
regexps as strings, surely?
Also, the assembler is slow, and I wonder if attacking other regexps in this
way would generate a speedup. YAPC::Europe have accepted my talk about making
perl scripts faster, and although I was planning on using the things I did to
Encode's compile for 5.8, it might be easier to attack assembler.pl and
document things that work as speedups as I go along.
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
--- ../../src/parrot/assemble.plTue Aug 6 20:54:48 2002
+++ assemble.pl Thu Aug 8 15:47:03 2002
@@ -435,7 +435,18 @@ sub _annotate_contents {
$self->{pc}++;
return if $line=~/^\s*$/ or $line=~/^\s*#/; # Filter out the comments and blank
lines
- $line=~s/^((?:[^'"]+|$str_re)*)#.*$/$1/; # Remove trailing comments
+
+ # Doing it this way chews infinite CPU on 5.005_03. I suspect 5.6.1
+ # introduces some cunning optimisation in the regexp engine to avoid
+ # backtracking through the brackets with the multiple levels of *s
+ #
+ # $line=~s/^((?:[^'"]+|$str_re)*)#.*$/$1/; # Remove trailing comments
+ #
+ # This is 5.005_03 friendly:
+ if ($line=~ /^(?:[^'"]+|$str_re)#/g) {
+# pos will point to the character after the #
+substr ($line, (pos $line) - 1) = '';
+ }
$line=~s/(^\s+|\s+$)//g; # Remove leading and trailing whitespace
#
# Accumulate lines that only have labels until an instruction is found.
Re: Constant & opcode swap ops
On Fri, Aug 09, 2002 at 04:10:50PM -0400, Dan Sugalski wrote: > Okay, one of the first things we need to do to support multiple > segment bytecode is to be able to swap in constant tables. (Since we > access constants by offset from the table, and we don't want to go > fix up the offsets every time we load in bytecode--ick. Slow) > > So... > > setconstant ix > > Takes the address *at* (not of) offset X and sticks it in the > interpreter structure as the address of the current constant table I wonder if the recent things you've been thinking about should be combined. Namely: make a PMC wrapper for the interpreter. Then do constant table manipulation through method invocations on the interpreter PMC. Or if not methods, then whatever mechanism you end up with for doing L-U decompositions for Josef H.'s matrix PMCs. While we're at it, we could nuke interp_info and do that through keyed access to the interpreter PMC.
Constant & opcode swap ops
Okay, one of the first things we need to do to support multiple segment bytecode is to be able to swap in constant tables. (Since we access constants by offset from the table, and we don't want to go fix up the offsets every time we load in bytecode--ick. Slow) So... setconstant ix Takes the address *at* (not of) offset X and sticks it in the interpreter structure as the address of the current constant table pushconstanttable Push the current constant table pointer onto the system stack popconstanttable Pop the constant table pointer from the system stack This has an implication for bytecode generation--it means that at least one pointer-sized word at the end of the bytecode will get altered at load time. This is OK--we can use it as the bytecode fixup section. (I expect we'll find other things we need to use as fixups along the way) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: status on matrix patch?
At 11:46 AM -0700 8/9/02, Sean O'Rourke wrote: >On Fri, 9 Aug 2002, Dan Sugalski wrote: >> 1) Bind the ops to the PMC implementation and just peek under the hood >> 2) Make method calls and have the PMCs do what they need to. >> >> #1 requires a way to load up PMC classes along with supporting opcode >> libs and parrot bytecode libs, which is infrastructure we've not got >> defined yet. >> >> #2 is slow. Yech. > >Since find_method results can be cached, the only slowdown would be from >fiddling with parameter passing (and maybe one extra level of function >call for invoke), and from looking up the method the first time. True, and odds are that time would be swamped by the time to actually perform the operations. Still, it's as good an excuse as any to get me motivated to get the stuff this needs defined... :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: status on matrix patch?
On Fri, 9 Aug 2002, Dan Sugalski wrote: > 1) Bind the ops to the PMC implementation and just peek under the hood > 2) Make method calls and have the PMCs do what they need to. > > #1 requires a way to load up PMC classes along with supporting opcode > libs and parrot bytecode libs, which is infrastructure we've not got > defined yet. > > #2 is slow. Yech. Since find_method results can be cached, the only slowdown would be from fiddling with parameter passing (and maybe one extra level of function call for invoke), and from looking up the method the first time. /s
Re: 'while <> {' in Perl 6
On Sat, Aug 10, 2002 at 02:23:07AM +0800, Christian Renz wrote:
> Actually, I once found myself wondering why while doesn't set $_ all
> the time anyway... It would be nice to do things like
Because the logic of the while construct doesn't require any
connection between the condition and the topic of the body.
In something like this, for instance:
while (!$file.eof)
{
my $line = $file.read();
...
}
Does it really make sense to have $_ set to the return value of
the eof call?
>while ($iterator->each()) { ... }
>while (query->nextResult()) { ... }
These examples seem to me to make more sense as for loops anyway.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
--
Absence in love is like water upon fire; a little quickens, but much
extinguishes it.
-- Hannah More
Re: status on matrix patch?
At 4:49 PM +0200 8/9/02, Josef Hook wrote: > > > If putting all the code into matrix.pmc is going to be a problem > >I see another problem coming up which i dont have the exact solution to. >How are we going to fit operations like >det() ludcmp() inverse() solve() transp() and others into vtable. >By that i dont mean that they should exist in vtable, but that >they must be placed in functions in the existing vtable. > >(Q) What vtable function should we call to get determiant? >(A) get_integer() is quite nice. Calling set I0,P0 and get determinant >value.. >(Q) What vtable function .. to get inverse? >(A) Now this one is really tricky. As i see it there isnt any suitable > vtable function for this. How are we going to solve > this? > >I believe we need a generall interface for accesess on "custom" >pmc function. Functions should also be accessable to ops... I think for these you have two choices: 1) Bind the ops to the PMC implementation and just peek under the hood 2) Make method calls and have the PMCs do what they need to. #1 requires a way to load up PMC classes along with supporting opcode libs and parrot bytecode libs, which is infrastructure we've not got defined yet. #2 is slow. Yech. So, then, we need #1. Which needs some infrastructure, as well as the capability to have multiple bytecode segments and sub loading in the bytecode. So I think it's time to start defining more stuff. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 'while <> {' in Perl 6
>I was wondering whether the Perl 'while (<>){' idiom will continue to
>be supported in Perl 6?
Actually, I once found myself wondering why while doesn't set $_ all
the time anyway... It would be nice to do things like
while ($iterator->each()) { ... }
while (query->nextResult()) { ... }
Setting $_ would be just what I would expect perl to do, only that it
doesn't do it.
Greetings,
Christian
--
[EMAIL PROTECTED] - http://www.web42.com/crenz/ - http://www.web42.com/
"Thirty was so strange for me. I've really had to come to terms with
the fact that I am now a walking and talking adult." -- C.S. Lewis
Re: 'while <> {' in Perl 6
In a message dated Fri, 9 Aug 2002, Adam Lopresto writes:
> I was wondering whether the Perl 'while (<>){' idiom will continue to be
> supported in Perl 6? I seem to recall people posting example code the list
> using it (although I can't dig any up), but it seems to me that if Perl 6's
> lazy list implementation is sufficiently smart, it could just be replaced with
> 'for <> {'. The only issues I can see are people using <> inside the loop, and
> maybe something about the scope of $_. (Does a topicalized $_ change the value
> of $_ outside of the loop?)
>
for <> { ... }
will be the new idiom, and it will be completely regular: a lazy iteration
of a list, with implicit topicalization to $_.
while <> {...}
Might be supported as a special case, I haven't heard either way. But by
switching while to for, no special syntactic sugar is necessary, unlike in
previous Perls.
I don't see why one couldn't use <> inside the for look. Either it's the
same iterator inside and out (iterators associated with filehandles), in
which case it'll do the right thing, or it's a different iterator
(iterators scoped by block), in which case the inside lazy iterator will
be monkeying with stuff that the outside lazy iterator has never, and will
never, see.
I don't know which it is, but either way, it seems like it would work fine
in the case of a filehandle read (provided that iterators can look ahead
and put stuff back on the buffer, which I understand they will be able
to).
Trey
Re: questions about pdd03_calling_conventions.pod
At 8:55 AM -0600 8/9/02, Jonathan Sillito wrote: >On Tue, 2002-08-06 at 20:11, Sean O'Rourke wrote: >> On Tue, 6 Aug 2002, Dan Sugalski wrote: >> >> > At 12:57 PM -0600 8/6/02, Jonathan Sillito wrote: >> > >Can a prototyped sub take a variable number of parameters (ie can it >> > >have 'rest' params?). If so, should there be some way for the caller to >> > >specify how many params are being passed in pmc registers? >> > >> > A prototyped sub can take a variable number of params, and there >> > should be a counter somewhere. I thought that was specified, but >> > apparently not. I'll fix that. >> >> I'm guessing this would be: >> >> I1 The number of items pushed onto the stack. > >Though I think what is missing is the number of PMC's passed in >registers. Yep. I added that to PDD03. Should be in the repository now. > > > >The pdd mentions callcc, but the callcc op seems to be going away >> > >(replaced with invoke on a continuation pmc) ... is that the plan? >> > >> > Callcc needs to stay--its removal is an oversight. >> >> Does it? We can do the same thing (and other, more devious ones) with >> existing ops. From my understanding of pdd03, the exact implementation >> would be this: >> >> # P0 contains a function object >> new P1, .Continuation >> set_addr I4, L1 >> set P1, I4 >> # Setup rest of args >> invoke >> L1: > >I like it. What do you think Dan? Works for me. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
'while <> {' in Perl 6
I was wondering whether the Perl 'while (<>){' idiom will continue to be
supported in Perl 6? I seem to recall people posting example code the list
using it (although I can't dig any up), but it seems to me that if Perl 6's
lazy list implementation is sufficiently smart, it could just be replaced with
'for <> {'. The only issues I can see are people using <> inside the loop, and
maybe something about the scope of $_. (Does a topicalized $_ change the value
of $_ outside of the loop?)
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
perl -le '$_=(split q,",,`$^Xdoc -q japh`)[1].".";y/pj/PJ/;print'
Re: [COMMIT] Register allocator for the JIT
On Wed, 7 Aug 2002, Nicholas Clark wrote:
> > > I'd not thought of this. You're right, but I think the trade off is the
> > > cumulative time you save each time the JITted routine is called, versus
> > > the time you took to track usage. I guess inside frequently called functions
> > > it could become worthwhile.
> >
> > The JITted routine is called only once, right?
>
> Er, yes, D'oh. Good point. I was thinking in terms of the JIT being run
> per subroutine, but actually it's run per block of bytecode.
>
> Except that
>
> 1: If I understand the plan, loading any sort of perl module ("use Foo.pm;")
>could cause parrot to load pre-compiled bytecode for that module, rather
>than the module. In which case, parrot is going to have multiple
>discontinuous blocks of bytecode in memory, with calls between them.
>So I assume that the JIT will be JITting the perl script first, then as
>and when each module is loaded, that gets JITted.
>
> 2: BEGIN blocks.
>(As in, they need to run as soon as the closing } is seen, which means that
> certainly bytecode, if not JITted bytecode, is going to get run in chunks
> in a script that uses a BEGIN block)
>
> 3: regexps are going to compile to bytecode, and I was assuming that in turn
>that bytecode was going to get JITted, and called into once per regexp
>match
Right.
>
> 4: We may want to create "fat" bytecode files, with pre-JITted (ie compiled)
>code next to the bytecode for CPU(s) of the machine the file is mounted to.
>
That's an idea, we can also make native executables.
> > > It would be useful if the bytecode had a way for the bytecode generator to
> > > give a hint about how hard any sort of runtime optimiser should try to
> > > optimise a function. So we'd only do this sort of thing for (say) repeatedly
> > > run regexps.
> >
> > In some time we can try to do some profiling on the fly to decide where to
> > optimise.
>
> If I follow the recent work on imcc correctly, then it is already trying to
> determine where loops are to avoid spilling registers inside loops (by
> spilling them outside. Is this the waterbed theory of graph colouring?)
> If so, imcc has already done some work about where slightly more JIT effort
> might pay off, so it seems a shame to throw that out.
Yes, that's why we are not going to do any kind of optimization that is
not required to be done at runtime, that means, we expect the most optimal
bytecode.
Daniel Grunblatt.
Re: questions about pdd03_calling_conventions.pod
On Tue, 2002-08-06 at 20:11, Sean O'Rourke wrote: > On Tue, 6 Aug 2002, Dan Sugalski wrote: > > > At 12:57 PM -0600 8/6/02, Jonathan Sillito wrote: > > >Can a prototyped sub take a variable number of parameters (ie can it > > >have 'rest' params?). If so, should there be some way for the caller to > > >specify how many params are being passed in pmc registers? > > > > A prototyped sub can take a variable number of params, and there > > should be a counter somewhere. I thought that was specified, but > > apparently not. I'll fix that. > > I'm guessing this would be: > > I1 The number of items pushed onto the stack. Though I think what is missing is the number of PMC's passed in registers. > > >The pdd mentions callcc, but the callcc op seems to be going away > > >(replaced with invoke on a continuation pmc) ... is that the plan? > > > > Callcc needs to stay--its removal is an oversight. > > Does it? We can do the same thing (and other, more devious ones) with > existing ops. From my understanding of pdd03, the exact implementation > would be this: > > # P0 contains a function object > new P1, .Continuation > set_addr I4, L1 > set P1, I4 > # Setup rest of args > invoke > L1: I like it. What do you think Dan? -- Jonathan Sillito
Re: status on matrix patch?
> > If putting all the code into matrix.pmc is going to be a problem I see another problem coming up which i dont have the exact solution to. How are we going to fit operations like det() ludcmp() inverse() solve() transp() and others into vtable. By that i dont mean that they should exist in vtable, but that they must be placed in functions in the existing vtable. (Q) What vtable function should we call to get determiant? (A) get_integer() is quite nice. Calling set I0,P0 and get determinant value.. (Q) What vtable function .. to get inverse? (A) Now this one is really tricky. As i see it there isnt any suitable vtable function for this. How are we going to solve this? I believe we need a generall interface for accesess on "custom" pmc function. Functions should also be accessable to ops... /Josef
Re: Array vs. PerlArray
On Thu, Aug 08, 2002 at 12:43:25PM -0700, Steve Fink wrote: > now thinking that we ought to have a default.pmc that throws "not > supported" for everything, but move all of the current fallback > implementations into a new class and reparent a bunch of the existing > PMCs (probably all of the non-aggregates?). The hard part will be > coming up with a name for it... DWIM.pmc? On Thu, Aug 08, 2002 at 04:19:03PM -0400, Dan Sugalski wrote: Because it can always be recovered from CVS if we decide that it's useful and what name it should have :-) Nicholas Clark
Re: [perl #16098] First draft of PerlScalar PMC
Peter Gibbs wrote: > This version is (hopefully) functionally equivalent to PerlUndef, > i.e. it acts as an uninitialised scalar. When assigned a value, > it changes itself to the appropriate type (PerlInt/PerlNum/ > PerlString). The current level of functionality is therefore > sufficient to use it for creation of new PMCs. I presume this doesn't take into account double-typed scalars (eg. $!). is this something we need to think about? > Incidentally, how would a PerlScalar be returned to undef status? what about this? new P0, .PerlScalar new P1, .PerlUndef set P0, P1 cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
[perl #16098] First draft of PerlScalar PMC
# New Ticket Created by Peter Gibbs # Please include the string: [perl #16098] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=16098 > Attached is the first draft of perlscalar.pmc (and the patches needed to add it to Parrot). (NB PerlScalar is type number 13 - but I don't think parrots are generally superstitious) This version is (hopefully) functionally equivalent to PerlUndef, i.e. it acts as an uninitialised scalar. When assigned a value, it changes itself to the appropriate type (PerlInt/PerlNum/ PerlString). The current level of functionality is therefore sufficient to use it for creation of new PMCs. Incidentally, how would a PerlScalar be returned to undef status? -- Peter Gibbs EmKel Systems -- attachment 1 -- url: http://rt.perl.org/rt2/attach/33388/27470/f149bb/perlscalar.pmc -- attachment 2 -- url: http://rt.perl.org/rt2/attach/33388/27471/74c551/perlscalar.patch perlscalar.pmc Description: perlscalar.pmc perlscalar.patch Description: perlscalar.patch
Re: status on matrix patch?
On 9 Aug 2002, Simon Cozens wrote: > [EMAIL PROTECTED] (Josef Hook) writes: > > no more matrix_core.c matrix_core.h? > > No, they've been replaced by nebuchadnezzar.c and chosen_one.h. By that you mean? > > -- > >but I'm one guy working weekends - what the hell is MS's excuse? > "We don't care, we don't have to, we're the phone company." > - Ben Jemmet, Paul Tomblin. >
Re: status on matrix patch?
[EMAIL PROTECTED] (Josef Hook) writes: > no more matrix_core.c matrix_core.h? No, they've been replaced by nebuchadnezzar.c and chosen_one.h. -- >but I'm one guy working weekends - what the hell is MS's excuse? "We don't care, we don't have to, we're the phone company." - Ben Jemmet, Paul Tomblin.
Re: status on matrix patch?
On Fri, 9 Aug 2002, Dan Sugalski wrote: > At 10:00 AM +0200 8/9/02, Josef Hook wrote: > >On Fri, 9 Aug 2002, Dan Sugalski wrote: > > > >> At 9:40 AM +0200 8/9/02, Josef Hook wrote: > >> >I hate to bring this up again but i must. Dan what's the status on my > >> >matrix patch ? I would apreciate some feedback if its good or bad? > >> >If its going to be applied or not? > >> >Do you want me to change anything? > >> > >> Sorry--you were going to redo this as a standalone PMC class, right? > >> I'm pretty sure that was the plan. > > > >I thought you werent sure wether you wanted it in the core or not. > >I guess i gave a hint that i could put everything in matrix.pmc but i > >didnt got the message that i should (my fault). Anyway you want most of > >the code in matrix.pmc ? no more matrix_core.c matrix_core.h? > >Could i keep cell.c and cell.h in core as is ? > >It would make it easier as i use them in multiarray.pmc > > Sorry, I probably wasn't clear. :( > > What I wanted originally was everything in a single file, as > matrix.pmc. While I'm considering other things now, I'm not sure if > that might not be because it's really late. > > If putting all the code into matrix.pmc is going to be a problem, > this'd be the time for us to come up with a scheme for multi-file PMC > classes. I'm not sure what, if anything, we'll do to facilitate > code-sharing between PMC classes, but I don't think putting things > into the core code is the right answer for that. I agree this would mess up the core in the long run. I just found a problem when putting everything in matrix.pmc i dont have access to matrix struct and it in turn breaks all operations in matrix.ops i guess i could figure out a workaround but as i see it i need to have access to MATRIX struct. is there any suitable .h file where i could put the struct in? /j > -- > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even >teddy bears get drunk >
Re: status on matrix patch?
At 10:00 AM +0200 8/9/02, Josef Hook wrote: >On Fri, 9 Aug 2002, Dan Sugalski wrote: > >> At 9:40 AM +0200 8/9/02, Josef Hook wrote: >> >I hate to bring this up again but i must. Dan what's the status on my >> >matrix patch ? I would apreciate some feedback if its good or bad? >> >If its going to be applied or not? >> >Do you want me to change anything? >> >> Sorry--you were going to redo this as a standalone PMC class, right? >> I'm pretty sure that was the plan. > >I thought you werent sure wether you wanted it in the core or not. >I guess i gave a hint that i could put everything in matrix.pmc but i >didnt got the message that i should (my fault). Anyway you want most of >the code in matrix.pmc ? no more matrix_core.c matrix_core.h? >Could i keep cell.c and cell.h in core as is ? >It would make it easier as i use them in multiarray.pmc Sorry, I probably wasn't clear. :( What I wanted originally was everything in a single file, as matrix.pmc. While I'm considering other things now, I'm not sure if that might not be because it's really late. If putting all the code into matrix.pmc is going to be a problem, this'd be the time for us to come up with a scheme for multi-file PMC classes. I'm not sure what, if anything, we'll do to facilitate code-sharing between PMC classes, but I don't think putting things into the core code is the right answer for that. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Request for behaviour definition for assignment to PerlScalar
At 9:55 AM +0200 8/9/02, Peter Gibbs wrote: >Peter Gibbs wrote: >> vtable method get_scalar(pmc) >> vtable method get_value(pmc, context) > >Having broken the rule of posting before drinking coffee in the morning, >this is obviously nonsense - neither of these will work, because we don't >know the return type of these functions. So, back to the original problem, >with no suggested implementation method now! I'm going to make the mistake of posting just going to bed, but... I think we can punt on the original problem. This: new P0, .PerlScalar new P1, .PerlArray assign P0, P1 isn't code that a compiler should be emitting. If it wants to duplicate perl's "array in scalar context is its length" behaviour, it should be: new P0, .PerlScalar new P1, .PerlArray set I0, P1 assign P0, I0 Though I freely admit that's a big punt on the real problem, which we still need to address. I'm up for suggestions, since sooner or later someone's going to emit code like that, and its nice to know what its supposed to do... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: status on matrix patch?
On Fri, 9 Aug 2002, Dan Sugalski wrote: > At 9:40 AM +0200 8/9/02, Josef Hook wrote: > >I hate to bring this up again but i must. Dan what's the status on my > >matrix patch ? I would apreciate some feedback if its good or bad? > >If its going to be applied or not? > >Do you want me to change anything? > > Sorry--you were going to redo this as a standalone PMC class, right? > I'm pretty sure that was the plan. I thought you werent sure wether you wanted it in the core or not. I guess i gave a hint that i could put everything in matrix.pmc but i didnt got the message that i should (my fault). Anyway you want most of the code in matrix.pmc ? no more matrix_core.c matrix_core.h? Could i keep cell.c and cell.h in core as is ? It would make it easier as i use them in multiarray.pmc /J > -- > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even >teddy bears get drunk >
Re: Request for behaviour definition for assignment to PerlScalar
Peter Gibbs wrote: > vtable method get_scalar(pmc) > vtable method get_value(pmc, context) Having broken the rule of posting before drinking coffee in the morning, this is obviously nonsense - neither of these will work, because we don't know the return type of these functions. So, back to the original problem, with no suggested implementation method now! -- Peter Gibbs EmKel Systems
Re: status on matrix patch?
At 9:40 AM +0200 8/9/02, Josef Hook wrote: >I hate to bring this up again but i must. Dan what's the status on my >matrix patch ? I would apreciate some feedback if its good or bad? >If its going to be applied or not? >Do you want me to change anything? Sorry--you were going to redo this as a standalone PMC class, right? I'm pretty sure that was the plan. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
status on matrix patch?
I hate to bring this up again but i must. Dan what's the status on my matrix patch ? I would apreciate some feedback if its good or bad? If its going to be applied or not? Do you want me to change anything? Until it gets applied i feel there's no idea to improve current code. It's hard to code with warnocks dilemma hanging over your head :-) /josef
