# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #37673]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37673 >
This transaction appears to have no content- Forwarded message from Fran?ois PERR
I've imported File::Which 0.05 into the parrot tree as r9959 and I've
applied this patch as r9960. If or when there is a workable parrot
'maintainer' bundle on CPAN and an optional module detection mechanism
as part of the configure system r9959 can be backed out.
Cheers,
-J
--
[Sorry if this doesn't thread in your reader]
Jonathan Worthington wrote:
> I'm looking to work
> on enabling Parrot to store away HLL debug info - that is, the file name,
> line number, columns etc in the high level language source code. This data
> can then be used to emit useful error message
Jonathan,
My highest priority requests (for use by the Amber compiler
and toolset) are:
1. To store away, for each part of the compiled program:
- the name of the HLL source filename
- the line and column numbers
2. For PIR error messages to be presented using the HLL source
location r
"Will Coleda" <[EMAIL PROTECTED]> wrote:
Storing the information is very good: how do we extract it, again? we
have {get,set}{file,line} opcodes, but if we're going to store more
generic information, we need a more generic way to extract it.
My current thinking on this is that a HLL will defin
[Disclaimer: I've only just started thinking about this in the last
hour, and don't want to appear all knowledgeable or anything!]
On 11/14/05, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> My current thinking on this is that a HLL will define a sub that knows how
> to print errors for that HL
On Sat, 12 Nov 2005, Larry Wall wrote:
For example, this is guaranteed to have the side effect of running
out of memory before it starts to print anything:
print **1...;
Speaking of which I wonder if it can be detected and cause an error to be
emitted. Which is to say, if it is possible f
On Fri, 11 Nov 2005, Eric wrote:
I think 'subset' might be a nicer colour for this bikeshed. For an
[snip]
Ehh. By that definition arn't all sets subsets? Anyway I didn't see
It depends on the axiomatic model of your choice. Speaking of which it is
perhaps not terribly OT to discuss here
On Fri, 11 Nov 2005, Jonathan Lang wrote:
That wasn't the intent; the intent was to define a
"something-or-other" C that represents the fact that whatever
does this sometimes behaves like a complexRectilinear and other times
behaves like a complexPolar. Even the underlying information (the
attr
On Mon, 2005-11-14 at 12:31 +, Jonathan Worthington wrote:
> My current thinking on this is that a HLL will define a sub that knows how
> to print errors for that HLL...
The HLL could register a PMC or object class (instead of just a sub),
using the existing "Parrot_register_HLL_type" call (
On 11/14/05, Nick Glencross <[EMAIL PROTECTED]> wrote:
> Jonathan Worthington wrote:
>
> > I'm looking to work
> > on enabling Parrot to store away HLL debug info - that is, the file name,
> > line number, columns etc in the high level language source code. This data
> > can then be used to emit u
On Fri, 11 Nov 2005, Will Coleda wrote:
> On Nov 11, 2005, at 5:15 PM, Joshua Hoblitt wrote:
> > As in my original proposal, Configure.pl would have to set the order
> > that the steps run in. Longer term it'd be nice to build a dependency
> > tree between the steps and execute them in order of
I propose a new Kwalitee metric, released_while_burning_midnight_oil.
Authors who released their modules between 8AM and 1AM the next day
(local time) will be awarded one point. Authors who, despite their
girlfriend's pleading, stay awake at stupid hours of the night to hack
on and then release Per
Hello all,
I've just published an article about public vs. private regression
tests. I've defined private tests as t/*.t files that are for the
author only and don't go in MANIFEST. Naturally, those don't get as
much publicity as tests included in CPAN distributions.
In the article I ad
Nick Glencross wrote:
> > Does it make sense to have nestable structures?
Not always. Consider debug info that includes "line number" and
"statement number". You could have multiple statements per line, or
multiple lines per statement.
> Actually the example notation looks quite different from w
At 15:59 +0100 11/14/05, Michele Dondi wrote:
>I must say that I didn't follow the discussion (complex) very much. But this
>makes me think of this too: the two representations are handy for different
>calculations. It would be nice if they somehow declared what they can do
>better (or at all) a
HaloO,
Larry Wall wrote:
Another possibility is to take $? away from the compiler. All the
compiler variables could go under $= instead, since pod is actually
just one particular kind of compiler-time data, and there's really
no particular mnemonic relationship between ? and the compiler.
But $
My main comment would be that it can be very easy to get seduced in to
dependency bloat when writing Test:: modules, and you should pay extra
attention to avoiding it if possible.
This is especially so if you have a dependency on a Module::Build Test::
modules, which is going to want to instal
Ian Langworth wrote:
I propose a new Kwalitee metric, released_while_burning_midnight_oil.
Authors who released their modules between 8AM and 1AM the next day
(local time) will be awarded one point. Authors who, despite their
girlfriend's pleading, stay awake at stupid hours of the night to hack
On Mon, 2005-11-14 at 14:02 -0500, Ivan Tubert-Brohman wrote:
> Hey, this gives me an idea! Let's also add
> released_while_not_under_the_influence. Authors could be required to
> pass a breathalyser test to make sure that they are not drunk while
> uploading to the PAUSE. I'm sure that the inc
Hello all,
I've just published an article about public vs. private regression
tests. Private ones are t/*.t files that are for the author only and
don't go in MANIFEST. Naturally, those don't get as much publicity
as tests included in CPAN distributions.
In the article I advocate that s
Due to new calling scheme this is obsolete.
"Roger Browne" <[EMAIL PROTECTED]> wrote:
> Does it make sense to have nestable structures?
Not always. Consider debug info that includes "line number" and
"statement number". You could have multiple statements per line, or
multiple lines per statement.
Actually the example notation looks qui
> [pmichaud - Thu Jul 21 02:10:03 2005]:
>
> On Wed, Jul 20, 2005 at 10:25:08AM -0700, Mitchell N Charity wrote:
> > PGE is currently passing all tests, but failing to run a "large" pugs
> > grammar (one for p6 regexps). So I transliterated part of the grammar
> > into a (failing) test. Attach
On Fri, Nov 11, 2005 at 11:23:34AM -0800, Jerry Gay via RT wrote:
> has this been addressed, even partially? it seems that it has, but this
> ticket, nor the related email thread
> (http://www.nntp.perl.org/group/perl.perl6.internals/29394) has been
> updated since may 2005.
The ticket can be clos
Hello,
I'm the maintainer of the parrot Debian packages which are in Debian
unstable now. All Debian packages usually get built by the Debian build
daemon network so binaries for all architectures are available to the
users. This was also done with parrot. The [0] results scared me a bit.
Parrot o
> [bernhard - Mon Jun 13 12:16:32 2005]:
> It might be nice to have the SVN revision, or a list of SVN revisions,
> as a keyword of the RT tickets. For example when a bug was reported,
> when a Patch was applied and when a problem was declared to be fixed.
>
yes, it can see it being useful. then a
--- Ivan Tubert-Brohman <[EMAIL PROTECTED]> wrote:
> Hey, this gives me an idea! Let's also add
> released_while_not_under_the_influence. Authors could be required to
> pass a breathalyser test to make sure that they are not drunk while
> uploading to the PAUSE. I'm sure that the incidence of si
Roger Browne wrote:
Nick Glencross wrote:
.hll_debug_end line
.hll_debug_begin line 2
I don't think the "end" directives add much. There's almost always going
to be an "end line" before a "begin line", so why not let 'begin line'
to imply the end of any previously-declared line?
On Nov 14, 2005, at 21:06, Nick Glencross wrote:
While nesting one begin/end line number directly inside another
doesn't make much sense, my reasoning for this is for inlining of code
where you nest a new filename/line/column and then these are popped to
get back to the original calling locat
--- Adam Kennedy <[EMAIL PROTECTED]> wrote:
> My main comment would be that it can be very easy to get seduced in
> to dependency bloat when writing Test:: modules, and you should pay
> extra attention to avoiding it if possible.
Yes, I can see that. I could actually have dropped Test::Differenc
On Mon, 2005-11-14 at 12:45 -0800, Ovid wrote:
> Yes, I can see that. I could actually have dropped Test::Differences
> "eq_or_diff" and just used the "is_deeply" function from Test::More,
> but when working with large data structures, there's just no comparison
> between the two. I suppose I co
i've added six more tests to PGE for nested matches, (based on a perl5
bug report i saw,) as parrot revision 9973, in t/p6rules/capture.t. it
seems that
rx /((\w+)+)/
is failing on long strings, just like it does in the perl5 bug i saw
(#8685). however, parrot doesn't segfault like perl does, at
On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
* I'm thinking of a PIR syntax along the lines of this:-
The discussion goes forth and back, like all other discussion we
already had WRT syntax, months and years ago.
I'd much more prefer that a compiler (amber anyone ;) just emits PIR
On 11/14/05, jerry gay <[EMAIL PROTECTED]> wrote:
> i've added six more tests to PGE for nested matches, (based on a perl5
> bug report i saw,) as parrot revision 9973, in t/p6rules/capture.t. it
> seems that
> rx /((\w+)+)/
> is failing on long strings, just like it does in the perl5 bug i saw
>
On Mon, 2005-11-14 at 22:33 +0100, Leopold Toetsch wrote:
> I'd much more prefer that a compiler (amber anyone ;) just emits PIR
> with debug syntax so that folks get a feeling how it looks like.
Good idea. I'll do it tomorrow (off to bed now).
Regards,
Roger Browne
On Mon, Nov 14, 2005 at 01:17:05PM -0800, chromatic wrote:
> On Mon, 2005-11-14 at 12:45 -0800, Ovid wrote:
>
> > Yes, I can see that. I could actually have dropped Test::Differences
> > "eq_or_diff" and just used the "is_deeply" function from Test::More,
> > but when working with large data str
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
* I'm thinking of a PIR syntax along the lines of this:-
The discussion goes forth and back, like all other discussion we already
had WRT syntax, months and years ago.
What syntax we parse no
"Will Coleda" <[EMAIL PROTECTED]> wrote:
The actual source code is definitely needed, and is what I thought you
were talking about before. I don't particularly care about where it gets
stored, as either "debug segment" or "source segment" are below the level
I interact with parrot on.
I'
* Ian Langworth <[EMAIL PROTECTED]> [2005-11-14 18:15]:
> PS. If you feel that sarcasm and satire are not best reflected
> in email, I cordially suggest that you eat a helicopter.
What wine is more appropriate with helicopters, though, white or
red?
Regards,
--
Aristotle
“If you can’t laugh at y
Doug McNutt wrote:
> As for complex operations which have multiple results I think a principle
> value approach makes more sense than a list. It's well established for the
> inverse trigonometric functions. Leave RootOf( ) to Maple and Mathematica.
In the hypothetical module that I'm describing, t
On Mon, Nov 14, 2005 at 11:07:55PM -, Jonathan Worthington wrote:
> "Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
> >On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
> >
> >>* I'm thinking of a PIR syntax along the lines of this:-
> >
> >The discussion goes forth and back, like all other di
On Nov 14, 2005, at 7:31 AM, Jonathan Worthington wrote:
"Will Coleda" <[EMAIL PROTECTED]> wrote:
Storing the information is very good: how do we extract it, again?
we have {get,set}{file,line} opcodes, but if we're going to store
more generic information, we need a more generic way to extr
--- "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> * Ian Langworth <[EMAIL PROTECTED]> [2005-11-14 18:15]:
> > PS. If you feel that sarcasm and satire are not best reflected
> > in email, I cordially suggest that you eat a helicopter.
>
> What wine is more appropriate with helicopters, though, white
while adding some shiny new pge tests for return context, i came
across this PIRism:
using keyed string access to the match object
##...
rulesub = p6rule('$:=(.)')
match = rulesub('abc')
.local string res
res = match['A']
print res
## prints: a
using keyed
On Sun, Nov 13, 2005 at 11:33:07AM +0100, Leopold Toetsch wrote:
> On Nov 13, 2005, at 4:45, Chip Salzenberg wrote:
> > $P0 = callframe 1
>
> We already have this kind of introspection: $ grep caller t/pmc/sub.t
OK, the Interpreter PMC interface is certainly flexible enough to
handle the introsp
Jonathan Lang wrote:
In the hypothetical module that I'm describing, the principle value
approach _would_ be used - in scalar context. The only time the "list
of all possible results" approach would be used would be if you use
list context. If you have no need of the list feature, then you don
47 matches
Mail list logo
