r "depbc" or something cryptic like that.
Again, I dont have a problem with "pbc_disassemble".
--Andrew Whitworth
ion,
>> or is it gone entirely? If it's completely gone, then this ticket is
>> moot and should be closed.
>>
>> --Andrew Whitworth
>
> The original ticket said 'extend.c', not 'embed.c', which is where that
> function still is today.
(me reading good)--
Sorry.
--Andrew Whitworth
it's still used in a lot of places. If we
don't want to rename a bunch of functions and variables, we should
change the PDD to say that the term is not completely deprecated.
This is just the first half of the PDD, I'm sure I'll generate more
questions as I try to read through it more.
--Andrew Whitworth
ores we're
making (src/gc/gc_gms.c, src/gc/gc_ims.c, src/gc/gc_it.c), and keeps
GC hackers from having to jump back and forth between files to see
functions that are part of the same essential subsystem. Any
disagreements?
--Andrew Whitworth
pecially true with all sorts of
automatically uniquely named variables from PGE and .macro_local
variables (when and if they ever get implemented).
I would be more comfortable with 128 or 256 if we can get away with it.
--Andrew Whitworth
s code that needs to be dealt with, if anybody has good
information about it I can take a stab. Any code that becomes less
stable without running the current GC must be in pretty bad shape.
--Andrew Whitworth
what PASM opcodes to "<<" and "<<=" produce? are they the same opcodes
or something different?
-Andrew Whitworth
On Fri, Oct 10, 2008 at 4:07 PM, Patrick R. Michaud (via RT)
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Patrick R. Michaud
>
ble could simply
bind the preferred one to the "$optable" variable.
--Andrew Whitworth
On Sun, Oct 12, 2008 at 9:27 AM, via RT Klaas-Jan Stol
<[EMAIL PROTECTED]> wrote:
> currently, the .line directive takes both an integer (for line number) and a
> string (for filename) argument.
> I propose to split these into a separate .line and .file directives, both
> only taking 1 argument.
>
ed phase is over,
return the local value to the global store. This way should solve the
problem relatively quickly, we really need to do a lot more work on
IMCC to kill globals and make it more reentrant all the way around
--Andrew Whitworth
On Tue, Oct 21, 2008 at 9:28 AM, Andy Dougherty <[EMAIL PROTECTED]> wrote:
> On Mon, 20 Oct 2008, Andrew Whitworth via RT wrote:
>
>> On Fri Mar 31 13:29:46 2006, leo wrote:
>> > I've tried:
>> >
>> > $ perl Configure.pl --cc=gcc --link=gcc --ld=g
Since I'm monkeying around in the relevant code anyway, this might be
a good task for the next calling_conventions branch. Or, if you
prefer, we could create a second branch for this conversion and do the
work there.
--Andrew Whitworth
On Sun, Nov 16, 2008 at 2:02 AM, via RT Allison R
on specific functions where appropriate post 1.0.0.)
>
> this is the rt tracking ticket. the work has begun in the api2export branch.
Is this the only purpose of the branch, to change PARROT_API to
PARROT_EXPORT? If so, it seems like it could be done in a single sed
job and not need an entire branch for it.
--Andrew Whitworth
With closures deprecated, we can kill this example from the tutorial?
--Andrew Whitworth.
lity IMHO (the argument-side using arrows, OTOH,
> is useful I think, and does add to readability, e.g. foo("answer"=>42).
I'm in favor of removal, personally. I agree that this syntax doesnt
do anything to help readability.
--Andrew Whitworth
ny changes into IMCC that don't have a major benefit
when we're planning to replace IMCC wholesale. If other people say we
should reject this, I certainly won't complain.
--Andrew Whitworth
e able to prove that some errors still exist or not.
--Andrew Whitworth
On Tue, Dec 16, 2008 at 12:49 AM, Will Coleda via RT
wrote:
> On Thu Jan 11 09:55:40 2007, stmpeters wrote:
>> On Thu Jan 11 08:57:22 2007, coke wrote:
>> > Need details.
>>
>> A recent p
On Tue, Dec 16, 2008 at 1:20 PM, Ron Blaschke wrote:
> Some time ago, because of this ticket, I tried with Borland C++ 5.5.1
> and 5.82, and failed miserably. But that may just be my bad bcc-foo.
> Unless someone's keen for this platform and has access to a fairly new
> ("within two years") versi
he morph opcode isn't used often, the morph VTABLE interface
is used quite a bit internally. There really isn't any easier and
still standard way of changing between types for PMCs. It certainly
beats having to invoke PMC methods internally to switch between types.
--Andrew Whitworth
sideeffect of a different operation. If we want PMCs to be able to
change their types, we want to use something that's specific for that
behavior, not a copy that happens to be able to change the type of the
things it copies.
--Andrew Whitworth
" or
something. Then the bytecode generator can check that flag to make
sure the syntax matches the given opcode. This is bad for a number of
reasons, but there don't seem to be many other ways to get all the
information we need in one place.
--Andrew Whitworth
On Wed, Feb 11, 2009
http://nopaste.snit.ch/15851
ossible, and our sponsors
for supporting this project. Our next scheduled release is 21 February 2012.
Enjoy!
--Andrew Whitworth
interests and skill sets.
Thanks,
--Andrew Whitworth
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #50770]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50770 >
This is a patch for RT#48276 "Warn when failure occurs in
P
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #50768]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50768 >
I've updated some of the documenation and comments in
config/pl
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #50882]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50882 >
Fixed two compile-time warnings in spf_render.c.
1) redefinitio
Forgot the patch in the last email.
--Andrew Whitworth
exceptions_c.patch
Description: Binary data
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #50880]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50880 >
Fixed a warning in src/exceptions.c. the dumpcore() macro alread
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #50886]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50886 >
..forgot the patch, again. I'll get better at this, i swear.
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #50884]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50884 >
I fixed a few compile-time warnings in src/spf_vtable.c,
src/threa
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #51980]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51980 >
the snprintf macro was defined in Parrot/misc.h and src/spf_rend
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #51976]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51976 >
I'm fixing a compile error that's generated (at least) on
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #51982]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51982 >
src/string_primitives.c:Parrot_char_digit_value was producing a
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #51984]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51984 >
The file src/utils.c was producing a number of compile-time warni
Forgot the patch. Here's the file.
--Andrew Whitworth
stringprimitivestypecast2.patch
Description: Binary data
On Fri, Mar 21, 2008 at 12:55 PM, Mark Glines via RT
<[EMAIL PROTECTED]> wrote:
> On Fri, 21 Mar 2008 09:06:59 -0700
> "Andrew Whitworth" (via RT) <[EMAIL PROTECTED]> wrote:
>
> > # New Ticket Created by "Andrew Whitworth"
> > # Please inc
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #51988]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51988 >
A number of small updates to file descriptor duplication functions
Shoot, i forgot the file. Eventually I'm going to learn to proplerly
use this new-fangled email contraption.
--Andrew Whitworth
iofddupfix.patch
Description: Binary data
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #51990]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51990 >
Fixed two compiler warnings in src/io/io_win32.c, and updated a
Oh, i'm glad this is a bug in the repository, when it happened to me,
I assumed that my SVN client was broken. Now I dont need to go through
the effort of uninstalling my SVN client, installing a new one, and
checking out the entire repository again.
--Andrew Whitworth
On Sat, Mar 29, 2008
submitted to be more comprehensive. I'll post it as soon as I
have something that makes sense.
--Andrew Whitworth
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #52596]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52596 >
I updated to the latest parrot revision this morning, m
Okay, I think Coke fixed this in r26855.
--Andrew Whitworth
PDD09 lists 3 stacks which are cleaned by the collector, the system
stack, the pmc register stack, and the general/user stack. Do all of
these still exist? If not, this is a small update to make.
--Andrew Whitworth
On Thu, Apr 24, 2008 at 2:10 AM, Patrick R. Michaud via RT
<[EMAIL PROTEC
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #53916]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53916 >
This is a documentation-only patch, no code is affected. The "
ant files in that branch and update everything to match this
patch.
I'll take a close look at this branch in the coming week.
-Andrew Whitworth
re.
Based on what i've seen today, I would venture to say (and chromatic
might have a different opinion of this) that it is not worthwhile to
merge this branch back to trunk. I am going to see if any individual
algorithms or functions can be salvaged from this, but I don't have
high hopes.
--Andrew Whitworth
n exception.
Either way, this is a recoverable error and we shouldn't close down
the whole program here.
--Andrew Whitworth
load.
Merging these two files together, there are a lot of simplifications
that could easily be made. We wouldn't want to oversimplify if it was
our intention to add new stacks and new types of stacks in the future,
but there is a lot we could do without limiting our future options.
--Andrew Whitworth
to the namespace PMC as well.
--Andrew Whitworth
This error hasn't been duplicated in nearly three months, and nobody
else has commented on it. I'm marking this one resolved for now.
--Andrew Whitworth
-specific sub-tickets for each
failing platform.
--Andrew Whitworth
Is this still an issue? A quick check of src/embed.c shows that there is
no function Parrot_call_sub. Has it been moved to some other location,
or is it gone entirely? If it's completely gone, then this ticket is
moot and should be closed.
--Andrew Whitworth
use "struct _IMC_Unit" instead
of "IMC_Unit" which would resolve the problem. Alternatively, we could
rearrange the way the header files are ordered/created, and ensure all
function prototypes are included after all data type definitions.
Neither fix should be too difficult, but I don't know which we would
prefer to pursue.
--Andrew Whitworth
es on this ticket? Maybe this
ticket should be closed out (since it's vague) and replaced with another
ticket or tickets for individual places where exit_fatal should be
replaced with real_exception, if any.
--
Andrew Whitworth
a.k.a Whiteknight
re migrating to www.parrot.org instead, is this much of an
issue? If not, I think we can close this ticket.
--
Andrew Whitworth
a.k.a Whiteknight
I know pmichaud was talking about a major rewrite of PGE in the future,
maybe this change could be included in the laundry list of things to do
during that time?
--
Andrew Whitworth
a.k.a Whiteknight
g arity on these subs?
--
Andrew Whitworth
a.k.a Whiteknight
s? Or, is finalization
called from somewhere else automatically?
That, and what is meant here by "reset stacktop"? I have no idea what
that's supposed to mean.
--
Andrew Whitworth
a.k.a Whiteknight
On Sun Aug 15 13:21:16 2004, coke wrote:
> Make the MMD tables shareable between interpreters for faster
> startup. (Though there are issues with this)
>
> (From the TODO file)
With the pdd27mmd branch merged in now, what's the status of this request?
--
Andre
nybody put any thought into this? Do we have any documents or
drafts which address this issue? We are getting close enough to the 0.8
release that's mentioned here as a specific milestone for getting this done.
--
Andrew Whitworth
a.k.a Whiteknight
escriptive
2) Rename seatbelts.pod to something more descriptive, like
/docs/dev/C_Functions.pod or something.
3) Expand that documentation to include more cases (ARGIN, ARGMOD,
ARGOUT, all the *_NULLOK variants of those, etc).
Any suggestions?
--
Andrew Whitworth
a.k.a Whiteknight
ng to mark it resolved. There was
a lot of good information discussed here though, about register
allocators and other stuff, so forgetting about this ticket entirely is
probably not a good idea. I'll try to merge some more of these ideas
into documentation in various files throughout /docs/
http://rt.perl.org/rt3/Ticket/Display.html?id=57636
--
Andrew Whitworth
a.k.a Whiteknight
Or, if somebody can point me to the
relevant code, I can try to hack together some docs for it.
--
Andrew Whitworth
a.k.a Whiteknight
,
or some function of it. Are there any specific boundaries on how
large/small this number has to be, whether it has to be prime or
pseudoprime, etc?
I'll throw it together if somebody will tell me what the requirements
are (if any).
--
Andrew Whitworth
a.k.a Whiteknight
> > > non-n_-prefixed ones).
> > >
> > > I guess what my question is, what's the reason for removing this?
> >
> > I think all this means is that the pragma itself is deprecated.
> > I would presume that the n_operators remain, and that programs
On Fri Feb 22 00:59:47 2008, kjs wrote:
> a patch was sent but never applied.
>
> I suggest to apply this patch, possibly with minor changes, and close
> this ticket.
Applied in r32003. I hope Allison doesn't mind if I close this ticket?
--
Andrew Whitworth
a.k.a Whiteknight
I can take a stab at that task tonight or over
the weekend, if that's the path that we want to take.
--
Andrew Whitworth
a.k.a Whiteknight
ticket stopped
almost a year ago now. Is there still outstanding documentation work to
do on this topic, besides the general "all documentation should be
improved" work that always needs to be done? Are there any specific
changes in the code that have not yet been reflected in the documentation?
--
Andrew Whitworth
a.k.a Whiteknight
going to be a lot of uses
> of the old syntax throughout the repo that will need to be updated. Do
> any of our code generators like PCT use the old syntax? If so, how hard
> would it be to update them?
>
>
Forgot to post this reply to perl6-internals
--
Andrew Whitworth
a.k.a Whiteknight
ax.
> >
> > This syntax needs to be added, and then the comma version can go
> > through a deprecation cycle before removal.
> >
> > --
> > Will "Coke" Coleda
> >
This syntax was added by kjs++ and it appears to work properly. The
deprecation of the comma form of .HLL_map is being handled by RT#57432,
so we can close this ticket now.
--
Andrew Whitworth
a.k.a Whiteknight
nders this workaround neccessary.
> >
> > So this ticket is probably good to be closed again, though it still
> > leaves me somewhat puzzled. :)
> >
> > Audrey
>
> --
> Will "Coke" Coleda
> [EMAIL PROTECTED]
>
>
This ticket is ove
t)
>
> leo
>
This ticket is over two years old and the problem described appears to
be, at least in part, dependent on the faulty config system of years
gone by. Do we have any Solaris users who can double-check this and see
if we still have a problem here?
--
Andrew Whitworth
a.k.a Whiteknight
;s the status of this ticket now? From the last message here, it
looks like maybe a solution was found (or an offending commit isolated).
Does this still fail? If not, we can close this ticket.
--
Andrew Whitworth
a.k.a Whiteknight
string(
> interp, _type,
> string_from_cstring(interp, "(2, 2, 34)", 0),
> PObj_constant_FLAG
> );
>
> PObj_live_CLEAR(param_sig);
> PObj_live_CLEAR(_type);
> }
>
> So it would seem that perhaps FixedIntegerArray objects are leaking
Is this still an issue? I've never even heard of the "PCCMETHOD
Compiler", does it still exist? Is it used? Is FixedIntegerArray known
to be leaking any memory?
--
Andrew Whitworth
a.k.a Whiteknight
update that could be
tackled in the next month if we wanted something that was more
internally consistent.
--
Andrew Whitworth
a.k.a Whiteknight
y or early
next week.
--Andrew Whitworth
ver, the
patches are very very small and I don't forsee them being a problem
(unless my knowledge of bison has degraded significantly in the past few
months).
--Andrew Whitworth
pircnamespacefix.patch
Description: Binary data
imccnamespacefix.patch
Description: Binary data
initions for
snprintf, and I wanted to know if a unification could go further then
that as well.
--Andrew Whitworth
is this ticket (#51944) resolved? I don't see any outstanding todo items
here that need to be considered further, and the submitted patch has
already been applied. Can we close this, or is this a placeholder for us
to further improve cygwin documentation?
--Andrew Whitworth
been testing this patch locally for about a week and there are no
issues with it. If nobody has any questions/comments/objections I'd like
to apply it later today. Anybody?
--Andrew Whitworth
is done in PIR and we are encouraging new users to learn PIR instead of
PASM.
If people think this is a good idea, I'll implement it and a test or two
for it.
--Andrew Whitworth
Index: compilers/imcc/imcc.l
===
--- compilers/i
General consensus (at least from what I've heard) is that this is useful
to add in PIR files, so I've applied the patch and a few other updates
and tests for it in r28473.
Resolving ticket.
--Andrew Whitworth
but it isn't being passed in the first place. On
invokes, we should be passing the object itself as a "self" parameter,
although I don't know how to make that happen.
On an odd note, generating PASM output of the above example with "$P1()"
and "$P1($P1)" using pa
ngy").
I assume the :method invocation changes the PMC type of the self
parameter, or adds some kind of class field to it that isn't there
otherwise. I don't know enough about PCC internals to fix this part of
the problem, although I will keep looking at it.
--Andrew Whit
I took another long look at this branch, and see nothing here that is
salvageable for current use. I have deleted the branch as of r28915.
--Andrew Whitworth
TOP rule should
> contain;
> I decided for now that it would be just *
>
> Running the pct-based JSON language, just input some string on the command
> line, like [1, 2, 3], and the output is dumped to stdout.
>
> kjs
Thanks, applied in r28923.
--Andrew Whitworth
not
exist anymore. We should close this ticket if nobody can duplicate it.
--Andrew Whitworth
89 matches
Mail list logo
