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
x syntax is removed
+ Capture_PIR (runtime/parrot/library/Parrot/Capture_PIR.pir)
Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next scheduled release is 20 January 2009.
Enjoy!
--Andrew Whitworth
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
# 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 #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 #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 #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
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
;the place to go for supported and tested
library packages for Perl and maybe other languages", not "the place
where people dump assorted unrelated shit".
--Andrew Whitworth
On Sat, May 30, 2009 at 7:56 AM, Mark Overmeer wrote:
> * Andrew Whitworth (wknight8...@gmail.com) [090530 00:24]:
>> I agree. Doing one thing well is so much better for everybody then
>> doing a million things poorly. An assorted "blob of data" repository
>> is
and examples to support experimental HLL import
Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next scheduled release is 21 July 2009.
Enjoy!
--Andrew Whitworth
r
+ Update PGE Documentation
- Miscellaneous
+ Added tests
+ Fixes to code, documentation, and standards
Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next scheduled release is 15 September 2009.
Enjoy!
--Andrew Whitworth
items that have no prior support for them (like Parrot
objects) would be very nice to have on Parrot in particular where
language interoperation could be a big deal in the future.
+1
--Andrew Whitworth
On Wed, Apr 21, 2010 at 3:16 AM, Stefan O'Rear wrote:
> (The following describes a pro
projects accepted to GSoC
+ Improve use of const and other compiler hints
Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next scheduled release is 15 June 2010.
Enjoy!
--Andrew Whitworth
2011.
The SHA256 sum for the download tarball is:
1a62db8793a5baf727a790d9fd58415dcc9f2c0c28b44608701b39792627241c
Enjoy!
--Andrew Whitworth
That looks like a Parrot problem, trying to force input characters to
UTF8. Can you open a ticket at trac.parrot.org for it? Thanks
--Andrew Whitworth
On Tue, Dec 28, 2010 at 5:41 AM, Hiroki Horiuchi wrote:
> Hello.
>
> This program
> --
> #!/usr/bin/env perl6
>
> use
tarballs are:
8f474d44a0137a3fd5296c019dbccc6ae64193ff12ce799babc362567115c1ad
parrot-3.3.0.tar.bz2
99b81a84bf55a69bc3bbf8bf8dd65bee1417fd1c30c7d08c6859a7a3db892b8f
parrot-3.3.0.tar.gz
Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next scheduled release is 17 May 2011.
Enjoy!
--Andrew Whitworth
On Mon, Jul 18, 2011 at 10:41 AM, Peter Lobsinger wrote:
> The destructor does exactly that, but is not triggered by global teardown.
That seems wrong to me, we should be sweeping pools and destroying
PMCs on global teardown. If we aren't doing that, it's a bug.
--Andrew Whitworth
or even tickets requesting fixes would be a great place to
start. My suggestion so far would be to add in a destroy override to
6model, try to use it, and see what blows up. Then open a ticket with
Parrot and we'll do our best to make it work the way you need.
--Andrew Whitworth
that we would try to *borrow* it in Parrot core directly.
What's standing in our way right now is the need to support multiple
different languages. We want to provide something, but if we provide
too much it's going to create problems with different HLLs, etc. If
Rakudo can prototype so
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
tted into Parrot
distributions or, as might be more favorable from a Rakudo
perspective, to have Parrot snapshotted into Rakudo release packages.
I obviously am not making the releases myself, so I don't know if this
is any easier for people in that role.
--Andrew Whitworth
On Sat, Apr 7,
That solution is fine by me. The real source of the problem is on the
Parrot side, and our extremely fragile versioning system for bytecode.
This is something that we need to address to help fix the problem in
the long term.
Exactly how we fix it is a matter for discussion, of course.
--Andrew
13fc136afc74a7b50b094f64d8cb00f83f0cd3d59acc6fa4e63c824fa4d
parrot-4.4.0.tar.bz2
02495c0d11d3977a615bb76d3219f12bc6543b8cf12c596dfd5c35e98d95218a
parrot-4.4.0.tar.gz
Alvis Yardley (or a delegate) will release Parrot 4.5.0, the next scheduled
monthly release, on June 16th 2012. Subsequent rele
parrot-4.7.0.tar.bz2
c0bffd371dea653b9881ab2cc9ae5a57dc9f531dfcda0a604ea693c9d2165619
parrot-4.7.0.tar.gz
Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next scheduled release is 18 September 2012.
The release is indeed a day late. I apologize for the unusual lateness.
--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
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
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
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
;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
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
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
s:
.return("name"=>value)
MySub("name"=>value)
("name"=>value) = MySub()
I assume that we want to be able to use SREGs (and string variables) in
all of these places? Or, are we looking to be more general to try and
include all stringifiable registers and variables here?
--
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
1 - 100 of 107 matches
Mail list logo
