Re: Destruction bug in make test.

[Leopold Toetsch]

Dan Sugalski <[EMAIL PROTECTED]> wrote:

> No. If any object has a destructor it should be called as the last
> interpreter is shut down. We're not guaranteeing dead-on immediate
> destruction, or if the timely flag isn't set timely destruction, but we
> *are* guaranteeing eventual destruction.

Oha. That explains the reasoning. That adds a third category to
"destruction" IMHO:

1) timely destruction on scope exits
2) eventual destruction on exit of interpreters
3) memory destruction for leak tests and such or for intermediate
   interpreters.

For 1) we have opcode support C. 2) seems to be the case
where IO objects jump in - and HLL destructors.

> We don't need to free memory, but we do need to call destructors.

So we'd better separate 2) and 3) This would simplify destruction
ordering and speedup interpreter shutdown.

>   Dan

leo

Linebuffering and readline

[Melvin Smith]

I fixed a bug in the readline routine that now allows it to act
like it should. With the ability to toggle linebuffering on IO
handles now with pioctl, do we need the explicit readline op
anymore?
-Melvin

[COMMIT] new IO op 'pioctl'

[Melvin Smith]

Added pioctl op and PIO_pioctl API call. General purpose op for IO manipulation
in tradition of UNIX ioctl call.
This will be the interface for doing all sorts of IO layer stuff such as
buffering, blocking, async, etc. At least until someone has a better
way to do it.
Also added record separator field to ParrotIO object and allow changing
from default \n. Needs finishing so we can support setting recsep to
NULL for slurp mode. Currently tests fail if I set to linebuf by default.
-Melvin

Re: References ...

[Melvin Smith]

At 11:05 PM 10/9/2003 +0100, Nicholas Clark wrote:
On Wed, Oct 08, 2003 at 06:43:27PM +0200, Leopold Toetsch wrote:
> Melvin Smith <[EMAIL PROTECTED]> wrote:
>
> > I think if you have the op for dereferencing, you don't need the
> > additional ops for
> > getting the type of the reference.
>
> Too true, thanks
Yes, but if you have to go via another PMC register then you may spill.
Whereas it seemed that the type retrieval ops went direct to S and I
registers, which may save spillage. (at a cost of more ops)
Well, 1 extra register is required which shouldn't be enough to worry
about. Spillage is pretty rare with the number of registers we have
so I doubt it will make a difference.
-Melvin

Re: [perl #24169] pthread required to build parrot on freebsd

[Nicholas Clark]

On Thu, Oct 09, 2003 at 09:53:02AM +, Peter Sinnott wrote:
> # New Ticket Created by  Peter Sinnott 
> # Please include the string:  [perl #24169]
> # in the subject line of all future correspondence about this issue. 
> # http://rt.perl.org/rt2/Ticket/Display.html?id=24169 >
> 
> 
> Hi,
>parrot is not currently building on freebsd as it requires 
> pthread to be included in its libraries. The aix hint file
> currently ensures pthread is included in the libs linked into parrot.
> 
> A proposed freebsd hint file is attached( a copy of the current aix
> hint file )

I'm having trouble testing this because I can't get CVS parrot to build on
my (friend's) freebsd box. I think that this ought to restore 5.005_03
compatibility:

===
RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v
retrieving revision 1.138
diff -p -u -r1.138 root.in
--- config/gen/makefiles/root.in8 Oct 2003 10:14:03 -   1.138
+++ config/gen/makefiles/root.in9 Oct 2003 22:39:18 -
@@ -22,7 +22,8 @@ RANLIB = ${ranlib}
 LINK = ${link}
 LD = ${ld}
 LD_SHARED = ${ld_shared}
-TOUCH  = perl -e ${PQ}open(A,q{>>},$$_) or die foreach @ARGV${PQ}
+# 3 arg open not in 5.005
+TOUCH  = $(PERL) -e ${PQ}open(A,qq{>>$$_}) or die foreach @ARGV${PQ}
 YACC = ${yacc}
 LEX = ${lex}

but it then fails with

imcc.y:20: imc.h: No such file or directory
imcc.y:21: pbc.h: No such file or directory
imcc.y:22: parser.h: No such file or directory


This is with gcc version 2.95.4 20020320 [FreeBSD]

Have the rules about where to find header files in directories relative
to source files been changed between gcc 2.95 and gcc 3?

Nicholas Clark

Re: References ...

[Nicholas Clark]

On Wed, Oct 08, 2003 at 06:43:27PM +0200, Leopold Toetsch wrote:
> Melvin Smith <[EMAIL PROTECTED]> wrote:
> 
> > I think if you have the op for dereferencing, you don't need the
> > additional ops for
> > getting the type of the reference.
> 
> Too true, thanks

Yes, but if you have to go via another PMC register then you may spill.
Whereas it seemed that the type retrieval ops went direct to S and I
registers, which may save spillage. (at a cost of more ops)

Nicholas Clark

Re: An evil task for the interested

[Luke Palmer]

Thomas Fjellstrom writes:
> On October 9, 2003 09:57 am, Dan Sugalski wrote:
> > On Thu, 9 Oct 2003, Dave Mitchell wrote:
> > > On Thu, Oct 09, 2003 at 11:43:41AM -0400, Dan Sugalski wrote:
> > > > We've got ordered destruction on the big list 'o things to do, and it
> > > > looks like we need to get that done sooner rather than later. So, this
> > > > is a good chance for someone to burn those surplus SAN points and
> > > > become one with the great gibbering chaos at the center of the universe
> > > > (no, wait, that's not it) by digging into the DOD system.
> > > >
> > > > Not a huge task, we just need to order PMCs before destroying them, to
> > > > make sure we don't call the destructor for a PMC before we destroy the
> > > > things that depend on it. A quick run through the PMC pools to build up
> > > > a dependency chain if there's more than one PMC that needs destruction
> > > > should do it.
> > >
> > > I always thought that was a rather hard issue, due to circular
> > > dependencies. It's certainly the case that Perl5 is very poor at global
> > > destruction of objects.
> >
> > In the circular case you just pick a place and go from there -- there's no
> > good way to handle those. There are a lot of cases where there are
> > non-circular dependencies, though, so it seems worthwhile to take those in
> > order. Probably ought to be optional for all the sweeps except, perhaps,
> > the final one, though I expect perl, python, and ruby code will all enable
> > ordered destruction.
> 
> I've been interested in how to clean up circular dependencies... Just how easy 
> is it to find all cases? Is it possible? Like say a really really deep 
> case... Should you just not care at that point, and say the programmer 
> deserves what [s]he gets?

Well, you don't really need to *find* the circular dependencies,
considering you can't really do anything with them once you do.

To destroy in a good order, you just have to topologically sort the
dependency graph, which isn't terribly hard.  The way circular
dependencies are destroyed depends on the edge cases of the topological
sort algorithm you use.  It would probably be best to 'prefer' objects
with explicit destructors, such that they appear earlier in the sort.

Luke

> > Dan
> 
> -- 
> Thomas Fjellstrom
> [EMAIL PROTECTED]
> http://strangesoft.net
> 

Re: [perl #24167] `#' comment signs not at the very beginning of a line

[Nicholas Clark]

On Thu, Oct 09, 2003 at 08:54:10AM +, Martin Mokrejs wrote:
> # New Ticket Created by  Martin Mokrejs 
> # Please include the string:  [perl #24167]
> # in the subject line of all future correspondence about this issue. 
> # http://rt.perl.org/rt2/Ticket/Display.html?id=24167 >
> 
> 
> Hi,
>   I get from my compiler:
> 
> cc: Warning: 
> /software/@sys/usr/lib/perl5/5.8.1/alpha-dec_osf-thread-multi-ld/CORE/cop.h, line 
> 40: # not in column 1 is ignored, skipping to end of line. (ignoretokens)
>  #ifdef NETWARE
> -^

That's compiling perl5 isn't it? So it's perl5 bug, not a parrot bug?
I've moved the ticked onto the perl5 queue


>  I can get around by using anothe rcompile mode, but I believe it should be fixed 
> anyway.

Having had a look at cop.h, I think so to.
There appear to be some more indented # constructions, but they're all
inside blocks that are only true on dosish platforms.

Nicholas Clark

[perl #24177] [PATCH] Make Parrot dlcompat aware on OS X

[via RT]

# New Ticket Created by  Michael Scott 
# Please include the string:  [perl #24177]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=24177 >


If someone happens to have dlcompat

http://www.opendarwin.org/projects/dlcompat/

installed on OS X then the following patch will let Parrot be aware of 
this and use it.

The following changes are made:

config/auto/headers.pl
Add dlfcn.h to @extra_headers so it will be detected even if dlcompat 
has been installed after Perl.

config/gen/platform/darwin.c
Add conditional code for PARROT_HAS_HEADER_DLFCN.

config/init/hints/darwin.pl
Add values for libs and so.

dynext.c
Replace SO_EXTENSION with PARROT_DLL_EXTENSION which is already 
defined in config.h.

nci_test.c
Remove #include  because it is unused.

t/pmc/nci.t
Remove the $PConfig{jitcpuarch} eq 'i386' condition from the SKIP 
conditional.

conf/gen/makefiles/root.in
Change libnci.so target to libnci and use $(SO).

Running

make libnci
perl t/harness --running-make-test --gc-debug t/pmc/nci.t

passes all tests with this patch applied.



-- attachment  1 --
url: http://rt.perl.org/rt2/attach/65884/49191/1922d1/dlcompat.patch



dlcompat.patch
Description: dlcompat.patch

Re: An evil task for the interested

[Thomas Fjellstrom]

On October 9, 2003 09:57 am, Dan Sugalski wrote:
> On Thu, 9 Oct 2003, Dave Mitchell wrote:
> > On Thu, Oct 09, 2003 at 11:43:41AM -0400, Dan Sugalski wrote:
> > > We've got ordered destruction on the big list 'o things to do, and it
> > > looks like we need to get that done sooner rather than later. So, this
> > > is a good chance for someone to burn those surplus SAN points and
> > > become one with the great gibbering chaos at the center of the universe
> > > (no, wait, that's not it) by digging into the DOD system.
> > >
> > > Not a huge task, we just need to order PMCs before destroying them, to
> > > make sure we don't call the destructor for a PMC before we destroy the
> > > things that depend on it. A quick run through the PMC pools to build up
> > > a dependency chain if there's more than one PMC that needs destruction
> > > should do it.
> >
> > I always thought that was a rather hard issue, due to circular
> > dependencies. It's certainly the case that Perl5 is very poor at global
> > destruction of objects.
>
> In the circular case you just pick a place and go from there -- there's no
> good way to handle those. There are a lot of cases where there are
> non-circular dependencies, though, so it seems worthwhile to take those in
> order. Probably ought to be optional for all the sweeps except, perhaps,
> the final one, though I expect perl, python, and ruby code will all enable
> ordered destruction.

I've been interested in how to clean up circular dependencies... Just how easy 
is it to find all cases? Is it possible? Like say a really really deep 
case... Should you just not care at that point, and say the programmer 
deserves what [s]he gets?

>   Dan

-- 
Thomas Fjellstrom
[EMAIL PROTECTED]
http://strangesoft.net

Re: test_main.c can die

[Leopold Toetsch]

Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Hi,

> test_main.c is not used any more.

parrot.c was built all the time and was unused :)

> Shouldn't test_main.c be removed completely? Maybe as part of the big
> imcc-move.

Yep.

> bye
> boe

leo

Re: Destruction bug in make test.

[Leopold Toetsch]

Juergen Boemmels <[EMAIL PROTECTED]> wrote:

> It turned out, that it was even simpler. The explicit sweeping is
> already in the code, but is only triggered if there are objects which
> need _early_ destruction, not if objects just need
> destruction. Removing this test made it work.

Why can't you call PIO_finish(DO_FLUSH) before the sweep? I don't
understand these workarounds. Also you mark the IOdata live, only that
they are destroyed 3 lines later then.

If there are no objects that need timely destruction, the sweep is wasted
time.

> Fix is commited.

Not IMHO.
PIO_finish still does not release the standard handles and valgrind
complains about invalid reads in PIO_flush_down.

> cu
> boe

leo

Re: An evil task for the interested

[Dan Sugalski]

On Thu, 9 Oct 2003, Dave Mitchell wrote:

> On Thu, Oct 09, 2003 at 11:43:41AM -0400, Dan Sugalski wrote:
> > We've got ordered destruction on the big list 'o things to do, and it
> > looks like we need to get that done sooner rather than later. So, this is
> > a good chance for someone to burn those surplus SAN points and become one
> > with the great gibbering chaos at the center of the universe (no, wait,
> > that's not it) by digging into the DOD system.
> >
> > Not a huge task, we just need to order PMCs before destroying them, to
> > make sure we don't call the destructor for a PMC before we destroy the
> > things that depend on it. A quick run through the PMC pools to build up a
> > dependency chain if there's more than one PMC that needs destruction
> > should do it.
>
> I always thought that was a rather hard issue, due to circular
> dependencies. It's certainly the case that Perl5 is very poor at global
> destruction of objects.

In the circular case you just pick a place and go from there -- there's no
good way to handle those. There are a lot of cases where there are
non-circular dependencies, though, so it seems worthwhile to take those in
order. Probably ought to be optional for all the sweeps except, perhaps,
the final one, though I expect perl, python, and ruby code will all enable
ordered destruction.

Dan

Re: An evil task for the interested

[Dave Mitchell]

On Thu, Oct 09, 2003 at 11:43:41AM -0400, Dan Sugalski wrote:
> We've got ordered destruction on the big list 'o things to do, and it
> looks like we need to get that done sooner rather than later. So, this is
> a good chance for someone to burn those surplus SAN points and become one
> with the great gibbering chaos at the center of the universe (no, wait,
> that's not it) by digging into the DOD system.
> 
> Not a huge task, we just need to order PMCs before destroying them, to
> make sure we don't call the destructor for a PMC before we destroy the
> things that depend on it. A quick run through the PMC pools to build up a
> dependency chain if there's more than one PMC that needs destruction
> should do it.

I always thought that was a rather hard issue, due to circular
dependencies. It's certainly the case that Perl5 is very poor at global
destruction of objects.

-- 
SCO - a train crash in slow motion

An evil task for the interested

[Dan Sugalski]

We've got ordered destruction on the big list 'o things to do, and it
looks like we need to get that done sooner rather than later. So, this is
a good chance for someone to burn those surplus SAN points and become one
with the great gibbering chaos at the center of the universe (no, wait,
that's not it) by digging into the DOD system.

Not a huge task, we just need to order PMCs before destroying them, to
make sure we don't call the destructor for a PMC before we destroy the
things that depend on it. A quick run through the PMC pools to build up a
dependency chain if there's more than one PMC that needs destruction
should do it.

Takers?

Dan

Re: Destruction bug in make test.

[Juergen Boemmels]

Dan Sugalski <[EMAIL PROTECTED]> writes:

> > I disagree :) We already have a 2 stage IO destroy. The first shall
> > flush its files. This get called even if destroy-at-end isn't set.

The two stage IO destroy is a problem that we don't have destruction
ordering yet. Closing the standard handles to early leads to failed tests.

> > The
> > second phase (clean allocated memory) isn't called for the last
> > interpreter, if this option isn't given. So either this test has to set
> > the "needs_destroy" on the IO object or IO has a bug.

No, needs_destroy marks the object that it needs _early_ destruction,
not that it needs destruction at all. The problem that the
destruction code is not run run at all.

> > If there are objects that did "needs_destroy" then a lazy sweep is done,
> > which should flush the IO object or release resources or whateve rsuch
> > an object might need.
> 
> No. If any object has a destructor it should be called as the last
> interpreter is shut down. We're not guaranteeing dead-on immediate
> destruction, or if the timely flag isn't set timely destruction, but we
> *are* guaranteeing eventual destruction.
> 
> We don't need to free memory, but we do need to call destructors.

Exactly. My first idea --destroy-at-end only removed the symptom. The
real problem was that the final sweep, which should have run the
destructor code, was only triggered if there was still an object left
which needs early destruction. I changed this to run the final sweep
unconditionally and the problem disappeared. I did not touch any of
the --destroy-at-end semantics.

I thought one moment about introducing a variable
interpreter->has_destroy analog to interpreter->has_early_DOD_PMCs but
rejected it. This would slow down the DOD because it has to take care
of this variable also. I think its better to force one sweep at the
end than slowing down every DOD.

bye
boe
-- 
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik  Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F  23 F6 C7 2F 85 93 DD 47

Re: Destruction bug in make test.

[Dan Sugalski]

On Thu, 9 Oct 2003, Leopold Toetsch wrote:

> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Thu, 9 Oct 2003, Juergen Boemmels wrote:
>
> >> Hi,
> >>
> >> I just discovered a really subtele bug:
> >> Normaly the test are not run with --destroy-at-end. This has not many
> >> consequences yet because the only PMCs with active destruction are
> >> IOs, in fact only one test is really sensitive to t/pmc/io_4.pasm, it
> >> won't flush its buffers without --destroy-at-end. The print op also
> >> did not use this buffer so this bug didn't even show up.
> >>
> >> There are several ways to solve this:
> >> - run the test always with --destroy-at-end
> >> - make --destroy-at-end the default and have an option --no-destroy-at-end
> >> - add a explicit flush to the test just before the end.
> >>
> >> I think we should take the second route: destroy-function should be
> >> run by default at the end of program.
>
> > Option 2 is the right one. (Well, OK, having parrot do an explicit sweep &
> > destroy's the right option, but until then...) Go ahead and add a patch to
> > whatever you need to make this happen.
>
> I disagree :) We already have a 2 stage IO destroy. The first shall
> flush its files. This get called even if destroy-at-end isn't set. The
> second phase (clean allocated memory) isn't called for the last
> interpreter, if this option isn't given. So either this test has to set
> the "needs_destroy" on the IO object or IO has a bug.
> If there are objects that did "needs_destroy" then a lazy sweep is done,
> which should flush the IO object or release resources or whateve rsuch
> an object might need.

No. If any object has a destructor it should be called as the last
interpreter is shut down. We're not guaranteeing dead-on immediate
destruction, or if the timely flag isn't set timely destruction, but we
*are* guaranteeing eventual destruction.

We don't need to free memory, but we do need to call destructors.

Dan

Re: Destruction bug in make test.

[Leopold Toetsch]

Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Thu, 9 Oct 2003, Juergen Boemmels wrote:

>> Hi,
>>
>> I just discovered a really subtele bug:
>> Normaly the test are not run with --destroy-at-end. This has not many
>> consequences yet because the only PMCs with active destruction are
>> IOs, in fact only one test is really sensitive to t/pmc/io_4.pasm, it
>> won't flush its buffers without --destroy-at-end. The print op also
>> did not use this buffer so this bug didn't even show up.
>>
>> There are several ways to solve this:
>> - run the test always with --destroy-at-end
>> - make --destroy-at-end the default and have an option --no-destroy-at-end
>> - add a explicit flush to the test just before the end.
>>
>> I think we should take the second route: destroy-function should be
>> run by default at the end of program.

> Option 2 is the right one. (Well, OK, having parrot do an explicit sweep &
> destroy's the right option, but until then...) Go ahead and add a patch to
> whatever you need to make this happen.

I disagree :) We already have a 2 stage IO destroy. The first shall
flush its files. This get called even if destroy-at-end isn't set. The
second phase (clean allocated memory) isn't called for the last
interpreter, if this option isn't given. So either this test has to set
the "needs_destroy" on the IO object or IO has a bug.
If there are objects that did "needs_destroy" then a lazy sweep is done,
which should flush the IO object or release resources or whateve rsuch
an object might need.

Destroying the last interpreter can be very time consuming, when
millions of objects are allocated. I don't think this should be the
default.

Note: only the last interpreter is effected  - all other interpreters
allways clean up behind them.

>   Dan

leo

test_main.c can die

[Juergen Boemmels]

Hi,

test_main.c is not used any more. The only references are from make.pl
(which also does not seem to work), a comment in imcc/main.c that it
is mostly stolen from there, and docs/embed.pod giving test_main.c as
an example.

Shouldn't test_main.c be removed completely? Maybe as part of the big
imcc-move.

bye
boe
-- 
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik  Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F  23 F6 C7 2F 85 93 DD 47

Re: Destruction bug in make test.

[Juergen Boemmels]

Dan Sugalski <[EMAIL PROTECTED]> writes:

[...]

> Option 2 is the right one. (Well, OK, having parrot do an explicit sweep &
> destroy's the right option, but until then...) Go ahead and add a patch to
> whatever you need to make this happen.

It turned out, that it was even simpler. The explicit sweeping is
already in the code, but is only triggered if there are objects which
need _early_ destruction, not if objects just need
destruction. Removing this test made it work.

Fix is commited.

cu
boe
-- 
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik  Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F  23 F6 C7 2F 85 93 DD 47

Re: Destruction bug in make test.

[Dan Sugalski]

On Thu, 9 Oct 2003, Juergen Boemmels wrote:

> Hi,
>
> I just discovered a really subtele bug:
> Normaly the test are not run with --destroy-at-end. This has not many
> consequences yet because the only PMCs with active destruction are
> IOs, in fact only one test is really sensitive to t/pmc/io_4.pasm, it
> won't flush its buffers without --destroy-at-end. The print op also
> did not use this buffer so this bug didn't even show up.
>
> There are several ways to solve this:
> - run the test always with --destroy-at-end
> - make --destroy-at-end the default and have an option --no-destroy-at-end
> - add a explicit flush to the test just before the end.
>
> I think we should take the second route: destroy-function should be
> run by default at the end of program.

Option 2 is the right one. (Well, OK, having parrot do an explicit sweep &
destroy's the right option, but until then...) Go ahead and add a patch to
whatever you need to make this happen.

Dan

parrot_assembly.pod

[Michael Scott]

docs/parrot_assembly.pod is just an earlier version of PDD 6.

An empowered person should remove it.

Mike

Destruction bug in make test.

[Juergen Boemmels]

Hi,

I just discovered a really subtele bug:
Normaly the test are not run with --destroy-at-end. This has not many
consequences yet because the only PMCs with active destruction are
IOs, in fact only one test is really sensitive to t/pmc/io_4.pasm, it
won't flush its buffers without --destroy-at-end. The print op also
did not use this buffer so this bug didn't even show up.

There are several ways to solve this:
- run the test always with --destroy-at-end
- make --destroy-at-end the default and have an option --no-destroy-at-end
- add a explicit flush to the test just before the end.

I think we should take the second route: destroy-function should be
run by default at the end of program.

bye
boe
-- 
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik  Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F  23 F6 C7 2F 85 93 DD 47

[perl #24169] pthread required to build parrot on freebsd

[via RT]

# New Ticket Created by  Peter Sinnott 
# Please include the string:  [perl #24169]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=24169 >


Hi,
   parrot is not currently building on freebsd as it requires 
pthread to be included in its libraries. The aix hint file
currently ensures pthread is included in the libs linked into parrot.

A proposed freebsd hint file is attached( a copy of the current aix
hint file )

Thanks
Peter Sinnott
-- 
It is our mission to enthusiastically engineer high-payoff technology and 
continually leverage existing economically sound services while maintaining 
the highest standards


-- attachment  1 --
url: http://rt.perl.org/rt2/attach/65855/49177/a86508/freebsd.pl



freebsd.pl
Description: freebsd.pl

[perl #24168] gmake required to build imcc on freebsd

[via RT]

# New Ticket Created by  Peter Sinnott 
# Please include the string:  [perl #24168]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=24168 >


Hi,
   currently gmake seems to be required to build imcc on freebsd.
   
When using gmake

$(IMCC_DIR)/%.o : $(IMCC_DIR)/%.c
$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) -I$(IMCC_DIR) $(CFLAGS) -o $@ -c 
$<

is used to build languages/imcc/imcparser.c

When using the system make 

.c$(O) :
@$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS) -o $@ -c $<
is used. This fails as it can find some of the imcc header files (
imc.h pbc.g parser.h )

For some reason languages/imcc/cfg.c builds correctly even though it
uses some of the same header files.


Thanks
Peter Sinnott

-- 
It is our mission to enthusiastically engineer high-payoff technology and 
continually leverage existing economically sound services while maintaining 
the highest standards

[perl #24167] `#' comment signs not at the very beginning of a line

[via RT]

# New Ticket Created by  Martin Mokrejs 
# Please include the string:  [perl #24167]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=24167 >


Hi,
  I get from my compiler:

cc: Warning: 
/software/@sys/usr/lib/perl5/5.8.1/alpha-dec_osf-thread-multi-ld/CORE/cop.h, line 40: 
# not in column 1 is ignored, skipping to end of line. (ignoretokens)
 #ifdef NETWARE
-^

 I can get around by using anothe rcompile mode, but I believe it should be fixed 
anyway.

-- 
Martin Mokrejs <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics 
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585