Parrot link failure imc_yyin_set/get
Hi, since yesterday, Parrot breaks during compiling, with the following output: c++ -o miniparrot -L/usr/local/lib -Wl,-E compilers/imcc/main.o \ -Wl,-rpath=/home/klaas/parrot/blib/lib -L/home/klaas/parrot/blib/lib -lparrot -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp src/null_config.o compilers/imcc/main.o(.text+0xd85): In function `main': compilers/imcc/main.c:494: undefined reference to `imc_yyin_set' compilers/imcc/main.o(.text+0xe03):compilers/imcc/main.c:504: undefined reference to `imc_yyin_set' compilers/imcc/main.o(.text+0xfcf):compilers/imcc/main.c:551: undefined reference to `imc_yyin_get' compilers/imcc/main.o(.text+0x1125):compilers/imcc/main.c:580: undefined reference to `imc_yyin_get' compilers/imcc/main.o(.text+0x118b):compilers/imcc/main.c:591: undefined reference to `imc_yyin_get' collect2: ld returned 1 exit status gmake: *** [miniparrot] Error 1 [EMAIL PROTECTED]:~/parrot$ imc.c is compiled, and the Makefile looks ok too. regards, klaas-jan
Re: Parrot link failure imc_yyin_set/get
Klaas-Jan Stol wrote: Hi, since yesterday, Parrot breaks during compiling, with the following output: c++ -o miniparrot -L/usr/local/lib -Wl,-E compilers/imcc/main.o \ -Wl,-rpath=/home/klaas/parrot/blib/lib -L/home/klaas/parrot/blib/lib -lparrot -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp src/null_config.o compilers/imcc/main.o(.text+0xd85): In function `main': compilers/imcc/main.c:494: undefined reference to `imc_yyin_set' compilers/imcc/main.o(.text+0xe03):compilers/imcc/main.c:504: undefined reference to `imc_yyin_set' compilers/imcc/main.o(.text+0xfcf):compilers/imcc/main.c:551: undefined reference to `imc_yyin_get' compilers/imcc/main.o(.text+0x1125):compilers/imcc/main.c:580: undefined reference to `imc_yyin_get' compilers/imcc/main.o(.text+0x118b):compilers/imcc/main.c:591: undefined reference to `imc_yyin_get' collect2: ld returned 1 exit status gmake: *** [miniparrot] Error 1 [EMAIL PROTECTED]:~/parrot$ imc.c is compiled, and the Makefile looks ok too correction: it seems the file imc.o is not linked at the Parrot and Miniparrot targets in the Makefile (line ~800). regards, klaas-jan
Re: Peforming newclosure at compile time?
Audrey Tang (autrijus) wrote: I'm glad to report the soon-to-be-released Pugs 6.2.11 now targets Parrot with the new calling convention and lexical pad syntax. However, the explicit demand on a newclosure runtime call makes package-scoped subroutines awkward to generate and use -- please see this journal entry for details: http://pugs.blogs.com/pugs/2006/01/pir_compilation.html so my question is, is it sane to get a :closure trait to go with :outer(foo) so it can perform newclosure at compile time? That will make it agree with Perl5 and Perl6's closure composition semantics for package-scoped subroutines. This is now implemented (r11212), except that a special :closure trait isn't needed, as :outer(foo) is used as an indicator that a Clsoure should be created. Thanks, Audrey leo
Re: argument count mismatch
Roger Browne wrote: Wow, it really does work. Thanks! Although it misses the case where the called sub has zero .params: .sub 'main' :main errorson 0x0C foo(5) .end .sub foo print Not OK\n .end As said, get_params isn't emitted at all, if there are no params. A simple work-around could be: .macro .no_params # maybe defined internally get_params '()' .endm ... .sub foo .no_params # could of course just emit the get_params directly ... With r11213 this throws an exception for the above sample code. Should we just use this syntax? leo
Re: how to detect that we're running under CPAN::Testers?
On Thu, Jan 12, 2006 at 03:17:55AM +0100, Sébastien Aperghis-Tramoni wrote:
AFAICT, serious smokers (the ones that automatically and regularly
send CPAN Testers reports) all use CPAN::YACSmoke. The previously
used one was cpansmoke, included with previous versions of CPANPLUS:
http://search.cpan.org/dist/CPANPLUS-0.0499/bin/cpansmoke
Currently there are no other ways of detecting automaing testing
reliably. Prior to YACSmoke there was $ENV{VISUAL} eq 'echo', but even
that wasn't guaranteed. I was working on adding the AUTOMATED_TESTING
flag to CPANPLUS, when the smoke testing got dropped from the
distribution. As such it was one of the first things to go into
YACSmoke. I did write to other writers of smoke test scripts suggesting
they do the same, but AFAIK none of them have implemented it.
I don't think it provided a hint for telling a module whether it was
automated testing or not, but I don't think that anybody still use it.
It didn't, and from the reports I've seen I don't think any automated
testing uses anything less than CPANPLUS 0.050.
That's something not indicated in the CPAN Testers Statistics site,
which was finally made available (but very silently) by Barbie:
http://perl.grango.org/
I wouldn't say silently, as I did announce it in my use.perl journal.
However, I wasn't convinced that many people would be interested in it,
so I didn't make a big song and dance about it.
Anyhow, I haven't added the stats about whether a report is from
automated testing as you can't tell unless the test is using YACSmoke
as it adds a tag line in the report. Incidentally, Adam it would be
worth you doing the same with PITA, so these sorts of stats could be
gleaned in the future.
Other reports may be send by people like me when they interactively
install modules using CPANPLUS, or by hand using Test::Reporter.
There are still quite a number of interactive reports submitted,
although the bulk is automated.
Barbie.
Re: argument count mismatch
On Mon, 2006-01-16 at 14:51 +0100, Leopold Toetsch wrote: As said, get_params isn't emitted at all, if there are no params. A simple work-around could be: .macro .no_params # maybe defined internally get_params '()' ... With r11213 this throws an exception for the above sample code. Should we just use this syntax? It works for me. Thanks! Regards, Roger Browne
[perl #38252] [TODO] create YAML::Emitter::Syck that does what Data::Dumper does.
# New Ticket Created by Will Coleda # Please include the string: [perl #38252] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38252 [1:37p] audreyt : chromatic: there is already PIR binding for libsyck's parsing part, fwiw [1:37p] chromatic : How about for emitting? [1:38p] audreyt : there is currently none [1:38p] chromatic : There's the TODO then!
[perl #38253] [TODO] PMC introspection API from PASM
# New Ticket Created by Will Coleda # Please include the string: [perl #38253] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38253
Re: how to detect that we're running under CPAN::Testers?
Anyhow, I haven't added the stats about whether a report is from automated testing as you can't tell unless the test is using YACSmoke as it adds a tag line in the report. Incidentally, Adam it would be worth you doing the same with PITA, so these sorts of stats could be gleaned in the future. Sorry, what _specifically_ do you want me to add, and to where? At the moment all our output is structured XML files, so at some point I need to write an XSL to translate it back down into something CPAN Testers can deal with, and I can add whatever you want me to at that time. Do you want the tag saying it's PITA-XSL-generated content, or the owner of the testing system? (because I imagine we'll end up with a number of those) Adam K
[perl #38255] [TODO] YAML::Parser::Syck for parsing YAML
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #38255]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38255
Parrot bindings for libsyck have been started, but never really
completed. Some notes on YAML::Parser::Syck are at
http://yaml.kwiki.org/index.cgi?ParrotDev
TODO: Bring the needed patches to libsyck to some repository,
or bundle them with Parrot.
The latest, November 2004, patches to the libsyck source are attached.
Anybody who wants to delve into that, please feel free to take over.
CU, Bernhard
? Makefile
? Makefile.in
? aclocal.m4
? autom4te.cache
? config.h
? config.h.in
? config.log
? config.status
? configure
? diff.out
? libtool
? stamp-h1
? config/depcomp
? config/install-sh
? config/missing
? lib/.deps
? lib/.libs
? lib/Makefile
? lib/Makefile.in
? lib/bytecode.lo
? lib/emitter.lo
? lib/gram.c
? lib/gram.h
? lib/gram.lo
? lib/gram.output
? lib/handler.lo
? lib/implicit.lo
? lib/libsyck.la
? lib/node.lo
? lib/syck.lo
? lib/syck_st.lo
? lib/token.lo
? lib/yaml2byte.lo
? tests/.deps
? tests/.libs
? tests/Makefile
? tests/Makefile.in
? tests/test-basic
? tests/test-emit
? tests/test-parse
Index: configure.in
===
RCS file: /var/cvs/syck/syck/configure.in,v
retrieving revision 1.20
diff -u -u -r1.20 configure.in
--- configure.in2 Aug 2004 17:32:34 - 1.20
+++ configure.in14 Nov 2004 12:51:27 -
@@ -10,10 +10,12 @@
AC_PROG_CC_STDC
AC_PROG_INSTALL
AC_PROG_LN_S
-AC_PROG_RANLIB
+#AC_PROG_RANLIB
AC_PROG_MAKE_SET
AC_PROG_AWK
AC_PROG_YACC
+# Added by bernhard 2004-08-18
+AC_PROG_LIBTOOL
AM_PROG_LEX
# Checks for libraries.
Index: ext/ruby/ext/syck/rubyext.c
===
RCS file: /var/cvs/syck/syck/ext/ruby/ext/syck/rubyext.c,v
retrieving revision 1.33
diff -u -u -r1.33 rubyext.c
--- ext/ruby/ext/syck/rubyext.c 18 Aug 2004 17:49:47 - 1.33
+++ ext/ruby/ext/syck/rubyext.c 14 Nov 2004 12:51:30 -
@@ -673,12 +673,11 @@
* - Converts data into native Ruby types
*/
SYMID
-rb_syck_load_handler(p, n)
-SyckParser *p;
+rb_syck_load_handler(bonus, n)
+struct parser_xtra *bonus;
SyckNode *n;
{
VALUE obj = Qnil;
-struct parser_xtra *bonus;
/*
* Attempt common transfers
@@ -699,7 +698,6 @@
obj = n-id;
}
-bonus = (struct parser_xtra *)p-bonus;
if ( bonus-taint) OBJ_TAINT( obj );
if ( bonus-proc != 0 ) rb_funcall(bonus-proc, s_call, 1, obj);
Index: lib/Makefile.am
===
RCS file: /var/cvs/syck/syck/lib/Makefile.am,v
retrieving revision 1.20
diff -u -u -r1.20 Makefile.am
--- lib/Makefile.am 18 Aug 2004 17:49:47 - 1.20
+++ lib/Makefile.am 14 Nov 2004 12:51:31 -
@@ -4,10 +4,12 @@
AM_YFLAGS = -d -t -v -p syck
-lib_LIBRARIES = libsyck.a
+#lib_LIBRARIES = libsyck.a
+lib_LTLIBRARIES = libsyck.la
include_HEADERS = syck.h syck_st.h
-libsyck_a_SOURCES = \
+# libsyck_a_SOURCES =
+libsyck_la_SOURCES = \
emitter.c \
handler.c \
node.c \
Index: lib/handler.c
===
RCS file: /var/cvs/syck/syck/lib/handler.c,v
retrieving revision 1.25
diff -u -u -r1.25 handler.c
--- lib/handler.c 13 Oct 2003 01:54:00 - 1.25
+++ lib/handler.c 14 Nov 2004 12:51:31 -
@@ -16,7 +16,7 @@
if ( ! n-id )
{
-n-id = (p-handler)( p, n );
+n-id = (p-handler)( p-bonus, n );
}
id = n-id;
@@ -39,7 +39,7 @@
if ( n-kind != syck_str_kind )
{
n-id = bad-id;
-(p-handler)( p, n );
+(p-handler)( p-bonus, n );
}
}
}
@@ -83,7 +83,7 @@
}
if ( ! st_lookup( p-bad_anchors, (st_data_t)a, (st_data_t
*)n ) )
{
-n = (p-bad_anchor_handler)( p, a );
+n = (p-bad_anchor_handler)( p-bonus, a );
st_insert( p-bad_anchors, (st_data_t)a, (st_data_t)n );
}
}
@@ -92,7 +92,7 @@
if ( n == NULL )
{
-n = (p-bad_anchor_handler)( p, a );
+n = (p-bad_anchor_handler)( p-bonus, a );
}
if ( n-anchor )
Index: lib/syck.c
===
RCS file: /var/cvs/syck/syck/lib/syck.c,v
retrieving revision 1.52
diff -u -u -r1.52 syck.c
--- lib/syck.c 2 Aug 2004 17:32:34 - 1.52
+++ lib/syck.c 14 Nov 2004 12:51:32 -
@@ -260,6 +260,13 @@
}
void
+syck_parser_bonus( SyckParser *p, void * bonus )
+{
+ASSERT( p != NULL );
+p-bonus = bonus;
+}
+
+void
syck_parser_implicit_typing( SyckParser *p, int flag )
{
p-implicit_typing = (
Re: Parrot link failure imc_yyin_set/get
I just had the same problem, and chased it down to the fact that it was using -L/usr/local/lib ahead of its own blib, so it was linking against an old libparrot of some sort or other. I'm not sure what the correct solution is, but as a workaround I deleted /usr/local/lib/libparrot* and then it links. Larry
Re: Parrot link failure imc_yyin_set/get
On Mon, Jan 16, 2006 at 02:48:57PM -0800, Larry Wall wrote: : I just had the same problem, and chased it down to the fact that it was : using -L/usr/local/lib ahead of its own blib, so it was linking against : an old libparrot of some sort or other. I'm not sure what the correct : solution is, but as a workaround I deleted /usr/local/lib/libparrot* : and then it links. Maybe because I had LD_LIBRARY_PATH=/usr/local/lib so that pugs would run? Larry
Re: Parrot link failure imc_yyin_set/get
Larry Wall [EMAIL PROTECTED] wrote: I just had the same problem, and chased it down to the fact that it was using -L/usr/local/lib ahead of its own blib, so it was linking against an old libparrot of some sort or other. I'm not sure what the correct solution is, but as a workaround I deleted /usr/local/lib/libparrot* and then it links. Ooh, nice catch - I'm to blame for the addition of those two functions but (a) develop on Win32 where this likely wouldn't show up and (b) don't have an installed Parrot anyway, thus meaning I've had a rather hard time trying to find the problem. ;-) Solution may be to have the full path to libparrot in the link line, to ensure we get the right one. Thoughts, anyone? Thanks, Jonathan
Re: Parrot link failure imc_yyin_set/get
What about the whole parrot/installable_parrot difference? On Jan 16, 2006, at 5:33 PM, Jonathan Worthington wrote: Ooh, nice catch - I'm to blame for the addition of those two functions but (a) develop on Win32 where this likely wouldn't show up and (b) don't have an installed Parrot anyway, thus meaning I've had a rather hard time trying to find the problem. ;-) Solution may be to have the full path to libparrot in the link line, to ensure we get the right one. Thoughts, anyone? Thanks, Jonathan
Re: The old $x will not stay shared thing.
On Mon, Jan 16, 2006 at 02:38:14PM +0800, Audrey Tang wrote:
: -BEGIN PGP SIGNED MESSAGE-
: Hash: SHA1
:
: I'm almost sure this had been covered before, but I failed to find a
: reference in either the archives or in synopses, so here goes again:
:
: sub f ($x) {
: sub g ($y) { $x + $y }; g($x);
: }
: f(10); # 20?
:
: Currently in Pugs, g is built at BEGIN time when f had not finished
: building up its lexical environment, and as such fails to see the
: runtime $x. The desugared form is:
:
: our g;
: BEGIN { g := sub ($y) { $x + $y } }
:
: However, the following form does work in the Parrot, JavaScript and
: Haskell runcore:
:
: sub f ($x) {
: my sub g ($y) { $x + $y }; g($x);
: }
:
: the reason it works is that g's body is replaced every time upon f's
: entry. This is probably the expected behaviour.
Yup.
: What would happen for the our sub g form, where it becomes possible to
: call g directly without entering f? This shows Pugs's current behaviour:
:
: sub f ($x) {
: our sub g ($y) { $x + $y }; g($x);
: }
: f(10); # 20 for sure
: our g; # gets visibility to g
: g(100); # 110 this time?
:
: So my questions are:
:
: * Is the treatment above sane?
I think so, under the theory that g is just a persistent form of the
closure that happens to be cached in the symbol table rather than
in some $ref variable. Though I can see temp our g being put
to interesting uses if g is getting arbitrarily rebound at various
points whenever f is called...
: * Does it make sense to change the undecorated sub g's behaviour to
: match our sub g?
Yes, at least for any block that really is capturing a closure.
Perhaps we need to distinguish those from accidentally nested
top-level functions. But undecorated sub is more-or-less defined
to be our sub anyway, just as with package, module, and class
these days. The only difference is that our explicitly introduces
a lexically scoped alias, while the undecorated form presumably doesn't.
Though we could break that too, I suppose.
: * If we insert a call to g() above without calling f() first, should it
: assume an uninitialized $x, or throw an exception (Pugs currently does
: the latter)?
An exception is fine, modulo what I said about accidental nesting.
When do you detect the condition? If the inner function can't
reference $x, does it still fail? On the other hand, we can get into
eval issues where it might or might not reference $x. I'm okay
with requiring lexical scopes to have some existing relationship
with dynamic scopes, especially when we know some initialization is
required.
Larry
FrOSCon Call for Papers
The first Free and Open Source Conference (FrOSCon) [1] takes place on June, 24th and 25th 2006 in Sankt Augustin, near Bonn, Germany. Organized by a commited team, it aims to become a significant event for free software in the Rhineland. The conference is hosted by the faculty of Computer Science [2] of the University of Applied Sciences Bonn-Rhein-Sieg [3] in collaboration with the student body and the Linux/Unix User Group Sankt Augustin [4]. In a Call for Papers [5], the organizers ask for submission of contributions. A broad variety of topics concerning free and open source software is desired. Particularly welcome are contributions about programming languages, free software on the desktop, security, systems administration and networks. Aspects of free software in busincess and industry are also a focus of the conference. Contributions can be submitted in English or German and should summarize the intended talk concisely and succinctly; talks should range from 45 to 60 minutes in length. Deadline for submission is March, 15th 2006. FrOSCon will offer Developer Rooms (just like FOSDEM [6] does) to Open Source projects. These projects can use the rooms to organize developer meetings as well sub-conferences dedicated to their project. Projects that have already registered a room or are interesting in doing so include: Gentoo Linux [7], GNOME [8], Mozilla [9], OpenOffice.org [10], OpenWRT [11], PHP [12], and Wikipedia [13]. [1]: http://www.froscon.org/ [2]: http://www.inf.fh-brs.de/home-lang-en.html [3]: http://www.fh-brs.de/ [4]: http://www.luusa.org/ [5]: http://www.froscon.org/wiki/CallforPapers [6]: http://www.fosdem.org/2006 [7]: http://www.gentoo.org/ [8]: http://www.gnome.org/ [9]: http://www.mozilla.org/ [10]: http://openwrt.org/ [11]: http://www.php.net [12]: http://www.wikipedia.org -- :: Marcus Thiesen :: [EMAIL PROTECTED] :: www.thiesen.org :: :: ICQ#108989768 :: 0x754675F2 :: [EMAIL PROTECTED] :: The human race has one really effective weapon, and that is laughter Mark Twain
Re: Need help diagnosing Test-Simple-0.62 make test error
David Golden wrote: Dear Michael and Perl QA colleagues, Wes Barris was trying to install one of my modules and encountered a dependency problem when Test-Simple-0.62 failed to make on his system. I was able to get some additional details, but I'm not sure what advice to offer him. The problem appears to be in the t/sort_bug.t test, but the error messages aren't very revealing: t/sort_bugdubious Test returned status 255 (wstat -1, 0x) test program seems to have generated a core after all the subtests completed successfully What happens with: prove -vb t/sort_bug.t jimk
Re: Need help diagnosing Test-Simple-0.62 make test error
James E Keenan wrote: What happens with: prove -vb t/sort_bug.t It was in the next section via make with TEST_VERBOSE. Subtests complete successfully then the test dies. t/sort_bug1..2 # parent 2267: continue # kid 1 before eq_set # parent 2267: continue # parent 2267: waiting for join # kid 2 before eq_set # kid 1 exit ok 1 - threads exit status is 42 # parent 2267: waiting for join # kid 2 exit ok 2 - threads exit status is 42 dubious Test returned status 255 (wstat -1, 0x) after all the subtests completed successfully
Re: The old $x will not stay shared thing.
On 1/16/06, Larry Wall [EMAIL PROTECTED] wrote:
Yes, at least for any block that really is capturing a closure.
Perhaps we need to distinguish those from accidentally nested
top-level functions. But undecorated sub is more-or-less defined
to be our sub anyway, just as with package, module, and class
these days. The only difference is that our explicitly introduces
a lexically scoped alias, while the undecorated form presumably doesn't.
Though we could break that too, I suppose.
What is the benefit for -not- explicitly introducing a lexically
scoped alias? Is there some performance reason why the undecorated
form wouldn't?
: * If we insert a call to g() above without calling f() first, should it
: assume an uninitialized $x, or throw an exception (Pugs currently does
: the latter)?
An exception is fine, modulo what I said about accidental nesting.
When do you detect the condition? If the inner function can't
reference $x, does it still fail? On the other hand, we can get into
eval issues where it might or might not reference $x. I'm okay
with requiring lexical scopes to have some existing relationship
with dynamic scopes, especially when we know some initialization is
required.
What other forms would be useful other than our sub g {...}? If
they're useful, shouldn't they have keywords?
Rob
