Status of my patches ...
Leopold Toetsch
sometimes, so I'll ask.
Here is a list of current open patches in decreasing priority:
#17578 imcc including all fixes sent to the list except todays fix
by Andy.
- actually the 3rd fix summary IIRC I sent in (s. there for a list of
patches, which are obsolete)
- CRUCIAL for non i386 platforms to run perl6
#17193 necessary for imcc to write out PBC
#17517 build system, permanent Configure runs - annoying at least
#17353/17323 test for Parrot_sprintf
#17549, 17569 intlist bugfix, speedup, test
#17524 packfile key cleanup
#17468 prederef init cleanup
#17352, 17358, 17361 classes cleanup/reorg
(+ the whole thing I sent to Dan)
#17455, 17469 readable core_ops files
Potentially dangerous:
#17495 putting lo_var_ptr beyond jump table
and, last but not least, only mentioned by Piers (thanks) my 2. proposal
WRT keyed access, else ignored.
Actually I'm running parrot/imcc with all these changes (+LEA ;-), so
they are well tested and work(tm).
If people don't have the time to look at it, it's ok. But then, it would
be fine, if I could checkin at least the imcc changes myself, so that
not 3 different people send patches WRT missing commas in imcc.y.
Thanks for reading,
leo
Tom Hughes
Leopold Toetsch <l...@toetsch.at> wrote:
> #17578 imcc including all fixes sent to the list except todays fix
> by Andy.
> - actually the 3rd fix summary IIRC I sent in (s. there for a list of
> patches, which are obsolete)
> - CRUCIAL for non i386 platforms to run perl6
Applied.
> #17193 necessary for imcc to write out PBC
Applied. Like you I don't like it much but there aren't any other
obviously better ways.
I missed that when it went through originally, but I don't like
your first two suggestions as they have nasty speed and/or memory
overhead issues. I don't really understand what you mean by the
third one so I can't comment much on that...
Tom
--
Tom Hughes (t...@compton.nu)
http://www.compton.nu/
Tanton Gibbs
I wish someone would commit this one as this does fix a very annoying
problem, especially on cygwin.
Tanton
Leopold Toetsch
>>#17578
> Applied.
First of all, thank you for comitting these. I hate 3-way rediff's ;-)
>>#17193 necessary for imcc to write out PBC
> Applied. Like you I don't like it much but there aren't any other
> obviously better ways.
Yes, seems so.
> I missed that when it went through originally, but I don't like
> your first two suggestions as they have nasty speed and/or memory
> overhead issues. I don't really understand what you mean by the
> third one so I can't comment much on that...
imcc (when preparing the compiled code to run) produces a packed key
structure (the bytecode of a _kc constant). This bytecode gets unpacked
by the standard packfile.c, which generates the linked key structure for
runtime.
For the reverse thing in packout.c I could provide above bytecode
directly via some callback function:
opcode_t (*packout_keys_helper)(Interp interp,
opcode_t key_const_nr,
opcode_t * byte_stream);
If packout.c find's a non null function pointer, it calls this function,
which fills byte_stream with the appropriate bytes. This function could
live in interpreters PackFile structure.
This solution could be used as an additional shortcut for packout users,
that - like imcc - know, how to produce this bytestream. So the current
hack should stay in place (for the general case) and above would save
the linear search in the Constant_Table.
leo
>
> Tom
>
>
Tom Hughes
Tanton Gibbs <thg...@deltafarms.com> wrote:
> > #17517 build system, permanent Configure runs - annoying at least
>
> I wish someone would commit this one as this does fix a very annoying
> problem, especially on cygwin.
Applied.
The problem here is that the rule in the Makefile that causes it to
rerun Configure.pl if any of the Configure.pl generated files is out
of date clashes with the recently introduced edit to stop Configure.pl
updating a file that hasn't actually changed.
As a result the Makefile continues to think it needs to rerun
Configure.pl ad infinitum.
I'm not quite sure how to resolve this in the long term as there are
conflicting goals here, but I've committed the patch for now.
Steve Fink
> .... or who applies what when and why or not? This questions arises
> sometimes, so I'll ask.
>
>
> If people don't have the time to look at it, it's ok. But then, it would
> be fine, if I could checkin at least the imcc changes myself, so that
> not 3 different people send patches WRT missing commas in imcc.y.
I definitely vote for you to be given commit privileges. Not all of
those patches should be applied without posting them for review, but
most could be.
I see imcc as a particularly troublesome area right now. I'm too
uncertain of the ownership/maintainership of that area right now to be
comfortable committing stuff just because it looks good to me. What's
the current state? Melvin, how much are you okay with?
The intlist stuff looked great to me when I skimmed through it, but I
haven't had the time recently to give it as close a look as I'd like
before committing. (The intlist test cases are harsh enough that it's
hard to go too far wrong before breaking them anyway.) If anyone else
with commit privs could take a look at it, I think it's a no-brainer
to commit unless you see something horribly wrong. (Updated data
structure documentation would be kind of nice, though...) Otherwise,
I'll hopefully be able to do it myself within a few days.
Tom Hughes
Leopold Toetsch <l...@toetsch.at> wrote:
> #17353/17323 test for Parrot_sprintf
Applied.
I've also updated MANIFEST and the .cvsignore files to try and match
something approaching reality. The outstanding question here is anyop.h
and anyop.c in languages/imcc as they are not built, and seem to have
been removed from the MANIFEST but are still in the repository.
Are these now dead? If they are then I'll remove them, otherwise they
need to go back into the manifest.
Leopold Toetsch
> On Wed, Sep 25, 2002 at 11:44:11PM +0200, Leopold Toetsch wrote:
>
>>.... or who applies what when and why or not? This questions arises
>>sometimes, so I'll ask.
>>If people don't have the time to look at it, it's ok. But then, it would
>>be fine, if I could checkin at least the imcc changes myself, so that
>>not 3 different people send patches WRT missing commas in imcc.y.
>>
>
> I definitely vote for you to be given commit privileges. Not all of
> those patches should be applied without posting them for review, but
> most could be.
Thank you for your confidence. Of course I wouldn't apply e.g. the
classes restructuring or the Lea collector ;-)
But obvious bugfixes (to imcc in the first place) would go in, as the
series, posted since 0.0.9 went in.
> I see imcc as a particularly troublesome area right now. I'm too
> uncertain of the ownership/maintainership of that area right now to be
> comfortable committing stuff just because it looks good to me. What's
> the current state? Melvin, how much are you okay with?
Melvin did commit 0.0.9 after review, all changes WRT syntax are
discussed and when people agree, we change it.
As Melvin wrote, he's currently short of spare time - but he might
speak for himself..
> The intlist stuff looked great to me when I skimmed through it, but I
> haven't had the time recently to give it as close a look as I'd like
> before committing. (The intlist test cases are harsh enough that it's
> hard to go too far wrong before breaking them anyway.)
Yep, the src-tests are really very valuable, they check each border case
thoroughly - great thing.
> ... If anyone else
> with commit privs could take a look at it, I think it's a no-brainer
> to commit unless you see something horribly wrong. (Updated data
> structure documentation would be kind of nice, though...)
Ok, I'll add some documentation for the chunk_list stuff/direct access.
> ... Otherwise,
> I'll hopefully be able to do it myself within a few days.
What aboud my proposal, to base all array classes on intlist?
Thanks,
leo
Leopold Toetsch
> In message <lists.perl6.internals/3D922E2B...@toetsch.at>
> Leopold Toetsch <l...@toetsch.at> wrote:
>
>
>>#17353/17323 test for Parrot_sprintf
> Applied.
Thank you.
> ... The outstanding question here is anyop.h
> and anyop.c in languages/imcc as they are not built, and seem to have
> been removed from the MANIFEST but are still in the repository.
>
> Are these now dead? If they are then I'll remove them, otherwise they
> need to go back into the manifest.
They are dead and can be deleted.
> Tom
Thanks,
leo
Tom Hughes
> #17549, 17569 intlist bugfix, speedup, test
Applied.
One slight query I had was the meaning of the extra parameter added
to intlist_new() by this patch. I assume the idea is that you can call
it with a value of 0 to reset the intlist?
I suspect that it might be better to have a separate intlist_reset or
intlist_empty or something to do that rather than a wierd boolean
parameter like that. Not a major issue though.
Andy Dougherty
> > > #17517 build system, permanent Configure runs - annoying at least
> The problem here is that the rule in the Makefile that causes it to
> rerun Configure.pl if any of the Configure.pl generated files is out
> of date clashes with the recently introduced edit to stop Configure.pl
> updating a file that hasn't actually changed.
I think that the 'recently-introduced-edit' is wrong. Make's dependency
system requires that the stated commands actually bring something
up-to-date.
--
Andy Dougherty doug...@lafayette.edu
Tom Hughes
Andy Dougherty <doug...@lafayette.edu> wrote:
On the other hand, without that edit it winds up rebuilding everything
every time you run Configure, even if it doesn't have to...
Andy Dougherty
> Andy Dougherty <doug...@lafayette.edu> wrote:
>
> > > The problem here is that the rule in the Makefile that causes it to
> > > rerun Configure.pl if any of the Configure.pl generated files is out
> > > of date clashes with the recently introduced edit to stop Configure.pl
> > > updating a file that hasn't actually changed.
> >
> > I think that the 'recently-introduced-edit' is wrong. Make's dependency
> > system requires that the stated commands actually bring something
> > up-to-date.
>
> On the other hand, without that edit it winds up rebuilding everything
> every time you run Configure, even if it doesn't have to...
Yes. That is correct expected 'make' behavior (assuming the dependencies
are correctly listed). By analogy, a Makefile can also assume that
cc -c foo.c
will re-run the compiler, not just run it only if the compiler decides the
output will change in some significant way.
Yes, I know that's often annoying. I often change things where I *know*
that not everything needs to be rebuilt. In those cases, I don't rely on
'make' to get it right. I manually get it right -- either by running a
shell script to rebuild just what needs to be rebuilt, or by judicious use
of 'touch' to pretend I rebuilt everything, or by use of cccache to speed
up rebuilds, or by some other trick.
These are, of course, obvious tricks, and I sometimes wish I didn't have
to do them. However, the alternative is to have incorrect dependencies in
the Makefile and rely on manually rebuilding everything that needs to be
rebuilt. I don't think that's a good plan.
--
Andy Dougherty doug...@lafayette.edu
Tanton Gibbs
rebuilds everything starting from Configure. It doesn't matter if I have
touched anything or not. In other words
perl Configure.pl && make
will run Configure.pl twice.
Very annoying.
Tanton
Andy Dougherty
> What is annoying is that on my cygwin system, everytime I type make it
> rebuilds everything starting from Configure. It doesn't matter if I have
> touched anything or not. In other words
> perl Configure.pl && make
>
> will run Configure.pl twice.
Yes, I know. All I'm saying is that's a Configure bug, not a Makefile
one. If you replace the copy_if_diff() commands in Configure.pl with
plain copy() commands, it should stop doing that.
--
Andy Dougherty doug...@lafayette.edu
Leopold Toetsch
> In message <lists.perl6.internals/3D922E2B...@toetsch.at>
> Leopold Toetsch <l...@toetsch.at> wrote:
>
>
>>#17549, 17569 intlist bugfix, speedup, test
> Applied.
Thanks again for all the checkins.
> One slight query I had was the meaning of the extra parameter added
> to intlist_new() by this patch. I assume the idea is that you can call
> it with a value of 0 to reset the intlist?
No it's not a reset thing. I should have documented it better, though i
thought the wod "initial" would tell it ;-)
The intlist structure is a little bit special, the first chunk - and
after shift/unshift maybe another entry - is the head of the list, which
carries additional information: Before my patch only the length of the
list, and now additionally e.g. the junk_list member.
This head chunk or "the list" is the parameter for the intlist
functions, in case of shift/unshift you pass an address, because the
head might move.
The "intial" parameter now constructs such an head entry, is it 0, then
a "normal" entry is allocated.
> Tom
leo
Tom Hughes
Leopold Toetsch <l...@toetsch.at> wrote:
> No it's not a reset thing. I should have documented it better, though i
> thought the wod "initial" would tell it ;-)
Well I was thinking of it as initial allocation versus reallocation.
> The intlist structure is a little bit special, the first chunk - and
> after shift/unshift maybe another entry - is the head of the list, which
> carries additional information: Before my patch only the length of the
> list, and now additionally e.g. the junk_list member.
>
> This head chunk or "the list" is the parameter for the intlist
> functions, in case of shift/unshift you pass an address, because the
> head might move.
>
> The "intial" parameter now constructs such an head entry, is it 0, then
> a "normal" entry is allocated.
So it's an implementation detail that doesn't need to be exposed
outside of the intlist code and therefore probably shouldn't be ;-)
Seriously, I'd suggest putting the common code into intlist_new_chunk
or something and then have intlist_new call that before doing the
other setup. That way you don't need the extra argument.
Tom
--
Tom Hughes (t...@compton.nu)
http://www.compton.nu/
Steve Fink
> On 26 Sep 2002, Tom Hughes wrote:
>
> > Andy Dougherty <doug...@lafayette.edu> wrote:
> >
> > > > The problem here is that the rule in the Makefile that causes it to
> > > > rerun Configure.pl if any of the Configure.pl generated files is out
> > > > of date clashes with the recently introduced edit to stop Configure.pl
> > > > updating a file that hasn't actually changed.
> > >
> > > I think that the 'recently-introduced-edit' is wrong. Make's dependency
> > > system requires that the stated commands actually bring something
> > > up-to-date.
> >
> > On the other hand, without that edit it winds up rebuilding everything
> > every time you run Configure, even if it doesn't have to...
>
> Yes. That is correct expected 'make' behavior (assuming the dependencies
> are correctly listed). By analogy, a Makefile can also assume that
> cc -c foo.c
> will re-run the compiler, not just run it only if the compiler decides the
> output will change in some significant way.
But it's perfectly valid to have portions of the system outside of
make's dependency tree. So if the Makefile makes something dependent
on Configure.pl, then it means that the something's timestamp must be
updated whenever Configure.pl is run. However, if the makefile is
unaware of anything depending on Configure.pl, then it's fine for
Configure.pl to avoid updating timestamps when it doesn't change
files.
Which means we need to make a choice: we can either avoid needless
rebuilds after running Configure.pl, or we can have a slightly more
complete dependency graph and hence reduce the chance of some
autogenerated .h file being out of date. Pick one of the other, but
not both!
I've done it either way in the past. When I'm messing with .in files
or the configuration scripts, I always want it to avoid rebuilds. But
when I'm answering bug reports that can be tracked down to people
forgetting to re-run configure, I want everything laid out in the
makefile. For Parrot, I would probably go for the latter (maybe with a
flag to Configure.pl for when I think I know what I'm doing) -- except
that the makefile rule is probably too much of a pain to maintain, so
we might as well go with the former.
To expand on that: the currently commented-out dependency on
Configure.pl in the makefile is wrong. It says the $(STICKY_FILES)
depend only on the Configure.pl script itself, which is woefully
incomplete: they also depend on all of the *.in files, all of the
configuration scripts, the Configure/*.pm modules, and probably other
stuff I've neglected. And those are much more likely to change than
Configure.pl, which is just a driver script.
Leopold Toetsch
> To expand on that: the currently commented-out dependency on
> Configure.pl in the makefile is wrong. It says the $(STICKY_FILES)
> depend only on the Configure.pl script itself, which is woefully
> incomplete:
There are a lot more dependencies, that are uncovered:
classes/derived class: class e.g. perlarray: array default
*.pmc: pmc2c.pl
core_*.c: ops2c*.pl, lib/Parrot/Op*/*, *.ops
jit_cpu.c: jit2h.pl lib/Parrot/Op*/* *.ops
and all depend on the Makefile's which depend on *.in and the scripts
building them and so on.
The problem is, that for joe user, you need a save i.e. complete
rebuild. For parrot hacker you want a minimal rebuild, that covers
common cases. Unsolvable with one set of rules IMHO.
leo