Re: [perl #47560] [BUG]: 'make realclean' not exiting cleanly
James Keenan (via RT) schrieb: # New Ticket Created by James Keenan # Please include the string: [perl #47560] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47560 Coke reported this evening that 'make realclean' was not exiting cleanly: 08:18 Coke make -C languages realcleanmake[1]: *** No rule to make target `realclean'. Stop. 08:19 Coke (from `make realclean`) I confirmed this on Darwin which recently had been svn-updated: make -C languages realclean make[1]: Entering directory `/Users/jimk/work/parrot/languages' make[1]: *** No rule to make target `realclean'. Stop. make[1]: Leaving directory `/Users/jimk/work/parrot/languages' make: *** [languages-realclean] Error 2 I called svn update in a sandbox that had not been updated since r22850 and got: Uconfig/gen/makefiles/root.in Uconfig/gen/makefiles/languages.in Ulanguages/jako/config/makefiles/root.in Ulanguages/PIR/config/makefiles/root.in Ulanguages/APL/config/makefiles/root.in The effect should go away with the next 'perl Configure.pl svn up'. The 'realclean' target of Makefile now depends on the new 'realclean' target of 'languages/Makefile'. The two changes were done atomically in a single commit. That's why I didn't expect this effect. I assume that the root Makefile was updated by the automatically by usr/bin/perl tools/dev/reconfigure.pl --step=gen::makefiles --target=Makefile which didn't look for changes in 'config/gen/makefiles/languages.in'. I'll take a brief look at reconfigure.pl . Regards, Bernhard
Perl 6 Junctions and MMD
Hi,
Back at OSCON, under the influence of beer, I agreed to take a crack at
implementing junctions in Perl 6 on Parrot. I've started working on
making good on that. I've not got any of this in a state where I'm happy
to send in a patch for people to play with, and it's my first time
hacking on the Perl 6 compiler so I won't check it in without review
first. However, with the very, very basic stuff I have implemented I can
now do things like:
my $x = 1 | 2 | 3; $x = $x * 5; my @y = $x.values; say @y;
5 10 15
my $x = 1 | 2 | 3; if $x == 2 { say true } else { say false }
true
my $x = 1 2 3; if $x == 2 { say true } else { say false }
false
if none(1,2,3) == 4 { say true } else { say false }
true
if none(1,2,3) == 3 { say true } else { say false }
false
I've run up against a Parrot issue that is kinda getting in the way.
Basically, all comparison operations have been implemented in Parrot
using the cmp function rather than having separate MMD methods for less
than and greater than. I've got equality to work by tweaking the == and
!= operators to not use cmp, but rather the is_equal_num MMD method.
However, the current state of affairs stops me implementing , , = and =.
The problem is that cmp can't give sensible answers with regard to
junctions. For example, what should it return for all(1,2) cmp 2?
They're not all less than 2, so it can't return -1. Clearly 1 isn't the
right answer, and clearly 0 isn't either.
The only sensible thing to do is to thread the junction through cmp
outside of the implementation of the operator and get a junction of
results - and as far as I understand that is what it's spec'd to do in
Perl 6. It'd be desirable for operations that really do support
junctions and can give back a boolean result to be able to do so,
however, without going through constructing an intermediate junction and
then having to analyse that. Thus I think we need , =, and = MMD
methods (plus the string variants) rather than relying on cmp for
everything. Maybe we can write some default implementations of these
that fall back on cmp, though, since in the majority of cases just
having cmp is fine.
Thoughts?
Thanks,
Jonathan
Re: [svn:parrot] r22864 - trunk/src/pmc
On 17/11/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: chromatic Date: Sat Nov 17 14:06:29 2007 New Revision: 22864 Modified: trunk/src/pmc/closure.pmc trunk/src/pmc/key.pmc trunk/src/pmc/object.pmc trunk/src/pmc/slice.pmc trunk/src/pmc/timer.pmc Log: [PMC] Cleaned up some compiler warnings, mostly related to missing defaults in switch statements. I added a couple of exceptions which may need review and testing. Who reads commit messages? Let's see if you're on the ball here. It looks ok to me. After I added the warning flag for default cases I noticed that in quite a few instances a Cswitch was used for a single item and therefore where an Cif would have done the job more than adequately. Is there reason to use a Cswitch in such instances? Is it more efficient? Or is it just trying to anticipate the future a bit? Paul
Re: [perl #47531] [BUG] t/src/intlist.t and t/src/io.t: 'undefined reference' test failures
On Nov 17, 2007, at 5:50 PM, chromatic wrote: On Saturday 17 November 2007 12:35:34 James E Keenan wrote: There's the problem them. Assuming you're using gcc 4.x, I'm not. Remember all that problem I was having at the hackathon getting my first build of Parrot. You and Chip and subsequently Coke diagnosed it as due to my botched attempt to build my own gcc 4.x. So ever since, I've specified the Apple-supplied build of gcc as a command- line option. (Not sure how that affects the current problem, however.) That explains everything. Visibility hiding is only available in gcc 4.x, so you don't need PARROT_API at all; every symbol in a shared library is visible to anything that dynamically loads that shared library. It surprises me that Coke's x86/Darwin doesn't support visibility hiding, as I thought he was using Mac OS X 10.4 which I thought also used gcc 4.x, so there may be compiler option detection problems there. When installing the dev tools, you can pick a few different gcc options, as I recall; you can switch between which one is used by using 'sudo gcc_select'. $ gcc_select --list Available compiler versions: 3.3 3.3-fast4.0 $ gcc_select Current default compiler: gcc version 4.0.1 (Apple Computer, Inc. build 5363) So, I'm using the apple supplied gcc 4. I am also using ccache explicitly when building parrot. CC=ccache gcc-4.0 CX=ccache g++-4.0 perl Configure.pl --cc=$CC --cxx=$CX --link=$CX --ld=$CX $@ $ grep -ai visibility Makefile CFLAGS = $(CC_INC) -fno-common -no-cpp-precomp -pipe - Wdeclaration-after-statement -pipe -fno-common -Wno-long-double - DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED - DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL - DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED - DHASATTRIBUTE_WARN_UNUSED_RESULT -I/opt/local/include -I /opt/local/ include -g -W -Wall -Waggregate-return -Wbad-function-cast -Wcast- align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit - Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline - Wmain -Wmissing-braces -Wmissing-declarations -Wmissing-prototypes - Wnested-externs -Wno-unused -Wnonnull -Wpacked -Wparentheses - Wpointer-arith -Wreturn-type -Wsequence-point -Wsign-compare -Wstrict- aliasing -Wstrict-prototypes -Wswitch -Wswitch-default -Wnested- externs -Wundef -Wunknown-pragmas -Wwrite-strings -Wsign-compare - falign-functions=16 -Wdisabled-optimization -Wformat-nonliteral - Wformat-security -Wpacked -Wbad-function-cast -Wdeclaration-after- statement -Wextra -Winit-self -Winvalid-pch -Wold-style-definition - Wstrict-aliasing=2 -fvisibility=hidden -Wmissing-field-initializers - Wno-shadow -DHAVE_COMPUTED_GOTO $(CC_SHARED) I do have visibility hidden enabled. (I wonder if this is related to my tcl bug.) Anyway, I've resolved these failures temporarily in r22866 by marking the tests as TODO on non-Darwin platforms. I'd like to see these tests go away, though. Their approaches are flawed. -- c -- Will Coke Coleda [EMAIL PROTECTED]
[perl #47560] [BUG]: 'make realclean' not exiting cleanly
Problem persists, albeit with a different directory as last visited, with an svn up to r22876. make -C languages realclean make[1]: Entering directory `/Users/jimk/work/parrot/languages' make[1]: *** No rule to make target `realclean'. Stop. make[1]: Leaving directory `/Users/jimk/work/parrot/languages' make: *** [languages-realclean] Error 2
[perl #47560] [BUG]: 'make realclean' not exiting cleanly
The patch attached reverts changes to config/gen/makefiles/root.in, config/gen/makefiles/languages.in and languages/jako/config/makefiles/root.in that appear to be associated with the recent problems in 'make realclean'. I applied this patch in two different sandboxes on two different OSes and it DWIMmed. It may not, however, have addressed the original 'jako' problem Bernhard was looking at. kid51 Index: config/gen/makefiles/root.in === --- config/gen/makefiles/root.in(revision 22876) +++ config/gen/makefiles/root.in(working copy) @@ -1282,9 +1282,6 @@ languages-clean : $(MAKE) languages clean -languages-realclean : - $(MAKE) languages realclean - ### # # compiler implementation targets: @@ -1661,7 +1658,7 @@ $(IMCC_DIR)/*$(O) \ $(IMCC_DIR)/imcparser.output -realclean : clean languages-realclean +realclean : clean $(RM_RF) \ $(STICKY_FILES) \ blib \ Index: config/gen/makefiles/languages.in === --- config/gen/makefiles/languages.in (revision 22876) +++ config/gen/makefiles/languages.in (working copy) @@ -120,8 +120,6 @@ urm.clean \ smoke-clean -realclean: \ -jako.realclean # # Language specific targets @@ -257,8 +255,6 @@ - $(MAKE) jako test jako.clean: - $(MAKE) jako clean -jako.realclean: - - $(MAKE) jako realclean lisp: lisp.dummy lisp.dummy: Index: languages/jako/config/makefiles/root.in === --- languages/jako/config/makefiles/root.in (revision 22876) +++ languages/jako/config/makefiles/root.in (working copy) @@ -66,10 +66,6 @@ clean: $(RM_F) examples/*.pir examples/*.list t/*.pir -realclean: clean - $(RM_F) Makefile - - over: @$(MAKE) clean @$(MAKE) all
Re: [svn:parrot] r22864 - trunk/src/pmc
On Sunday 18 November 2007 04:36:15 Paul Cochrane wrote: On 17/11/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: chromatic Date: Sat Nov 17 14:06:29 2007 New Revision: 22864 Modified: trunk/src/pmc/closure.pmc trunk/src/pmc/key.pmc trunk/src/pmc/object.pmc trunk/src/pmc/slice.pmc trunk/src/pmc/timer.pmc Log: [PMC] Cleaned up some compiler warnings, mostly related to missing defaults in switch statements. I added a couple of exceptions which may need review and testing. Who reads commit messages? Let's see if you're on the ball here. It looks ok to me. After I added the warning flag for default cases I noticed that in quite a few instances a Cswitch was used for a single item and therefore where an Cif would have done the job more than adequately. Is there reason to use a Cswitch in such instances? Is it more efficient? Or is it just trying to anticipate the future a bit? It looks like a case of anticipating the future. What I meant by the commit message was Do these exceptions look reasonable, and can someone who isn't me add tests for them? I'm sort of on a hack-and-slash Sherman-style quest to clean up all of the warnings at the moment and feeling a bit lazy -- c
Re: [perl #47572] [BUG] Memory leak with PMCProxy
On Sunday 18 November 2007 08:08:25 Mehmet Yavuz Selim Soyturk wrote: If you have defined an .HLL in your program, any pmc leaks. I could track the problem down to PMCProxy::init_pmc. If these lines of PMCProxy::init_pmc are removed, the leak disappears: if (!PMC_IS_NULL(proxy_info-_namespace)) Parrot_PCCINVOKE(interp, proxy_info-_namespace, string_from_literal(interp, set_class), P-, SELF); /* Extract any methods from the namespace */ Parrot_oo_extract_methods_from_namespace(interp, SELF); Did you happen to catch which PMC it is that's leaking? Also, is this with PIR or PBC or both? Do you have a short test case that Valgrind catches? -- c
NEWS and PLATFORMS Updates Requested
The next release will be on Tuesday evening. Committers, please review your checkins and update NEWS appropriately. Everyone, please submit updates to PLATFORMS. Running make fulltest and reporting any failures would be very handy as well. -- c
[perl #47572] [BUG] Memory leak with PMCProxy
# New Ticket Created by Mehmet Yavuz Selim Soyturk # Please include the string: [perl #47572] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47572 If you have defined an .HLL in your program, any pmc leaks. I could track the problem down to PMCProxy::init_pmc. If these lines of PMCProxy::init_pmc are removed, the leak disappears: if (!PMC_IS_NULL(proxy_info-_namespace)) Parrot_PCCINVOKE(interp, proxy_info-_namespace, string_from_literal(interp, set_class), P-, SELF); /* Extract any methods from the namespace */ Parrot_oo_extract_methods_from_namespace(interp, SELF); Summary of my parrot 0.4.17 (r22872) configuration: configdate='Sun Nov 18 14:02:27 2007 GMT' Platform: osname=linux, archname=i486-linux-gnu-thread-multi jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl Compiler: cc='cc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -I /usr/include', Linker and Libraries: ld='cc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-ldl -lm -lpthread -lcrypt -lrt -lgmp -lreadline' Dynamic Linking: share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC', load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8 -- Mehmet
Re: [svn:parrot] r22876 - trunk/t/codingstd
On Sun, Nov 18, 2007 at 06:03:28AM -0800, [EMAIL PROTECTED] wrote: Log: [codingstd] If a comma is followed by a single quote, it very likely in a situation like: moo = ','; In which case, there shouldn't be a space after the comma. Updating test to handle this situation. Shouldn't the test simply completely ignore commas (and semicolons) that happen to appear in strings and comments? Pm
Re: [perl #47572] [BUG] Memory leak with PMCProxy
[Sorry chromatic, forgot to send to the list] Did you happen to catch which PMC it is that's leaking? I don't know which PMC, but the leak happens when you create a PMCProxy with init_pmc. Also, is this with PIR or PBC or both? Both. Do you have a short test case that Valgrind catches? I did not test it with Valgrind (I'm not sure how to use it), but I see increasing memory usage in the task manager. .sub _ :main loop: $P0 = new 'Integer' $P0 = 27 $P1 = new 'PMCProxy', $P0 goto loop .end And a more general test that causes a PMCProxy creation, thus a leak: .HLL 'Foo', '' .sub _ :main loop: $P0 = new 'Float' goto loop .end
Re: [svn:parrot] r22876 - trunk/t/codingstd
On Nov 18, 2007, at 12:47 PM, Patrick R. Michaud wrote: On Sun, Nov 18, 2007 at 06:03:28AM -0800, [EMAIL PROTECTED] wrote: Log: [codingstd] If a comma is followed by a single quote, it very likely in a situation like: moo = ','; In which case, there shouldn't be a space after the comma. Updating test to handle this situation. Shouldn't the test simply completely ignore commas (and semicolons) that happen to appear in strings and comments? Pm Agreed. -- Will Coke Coleda [EMAIL PROTECTED]
Re: Perl 6 Junctions and MMD
I agree. See http://www.nntp.perl.org/group/perl.perl6.internals/2007/08/msg39889.html
