Re: HLLs needing OpenGL support
Geoffrey Broadwell a écrit :
I noticed a couple commits overnight for Lua to support OpenGL. I'm a
bit confused by them, since they don't seem to actually *do* anything,
just lots of (hopefully automatically generated!) scaffolding.
fperrad: How do these bindings actually work?
There'll work with runtime/parrot/library/OpenGL.pir.
François.
Everyone:
We're getting to the stage that HLLs are starting to want common library
access. Some of these already exist as more or less decent PIR bindings
in /runtime/parrot/library/ ; others are either very incomplete or
non-existant. Still, the time has come to be working on making it
easier for HLL authors to get a fully colloquial binding using the
common libraries, rather than having to roll their own from scratch.
pmichaud, jonathan, and I discussed a basic design a few weeks ago in
#parrot for PCT languages to use cross-language modules; the basic
protocol we sketched out should be workable for non-PCT languages as
well. That protocol needs to be fleshed out and implemented.
Also, I would love to know what I can do for the OpenGL binding to make
it more amenable to use by the HLLs. I notice that the Lua bindings
want to unflatten the namespace ('gl.Foo' rather than 'glFoo'). What
other changes do various HLLs typically make to C library bindings?
-'f
Re: language testing on pdd25cx, preparing to merge (rakudo)
Allison Randal wrote: > Allison Randal wrote: >> Moritz Lenz wrote: >>> >>> I also get errors in parrot's PGE tests (I guess they are known already; >>> if not I can happily send the details) >> >> I get no errors in PGE's tests on Mac OS X or Ubuntu as of r29552, so >> please send the details. > > Oh, but do make sure you've updated to the latest svn, and have run > 'realclean', as there have been some significant changes in the past few > days (resolving the old PGE test failures). With r29647 all parrot tests pass again (plus one TODO passed in t/op/exceptions.t) Most of the spectest_regression failures in rakudo also went away, most remaining ones are now like this one: "t/spec/S06-signature/named-parametersNo exception handler and no message" Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Perl6::Str on CPAN
Hi, today I released Perl6::Str to CPAN. It's a module for grapheme level string handling, and the methods are modeled closely after those of Perl 6. I cheated a bit in that I didn't implement codepoint and byte level semantics, since perl 5 supports them natively already. It lacks some features, some features aren't properly tested yet (like normalization), and some aren't planned at all (pack/unpack for example). It's also meant as an inspiration: grapheme level string handling doesn't have to be hard (it just becomes hard if you optimize the code ...) All comments are welcome. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
pbc install_config: howto install perl6 and languages?
How is make install for the pbc_to_exe generated languages supposed to work? For the utils you simply link to a fixed install_config.o with fixed builddir. But the languages are generated from a .pir file with hardcoded, wrong builddir. I think about adding support for an optional --install arg in all pir's for the pbc_to_exe step sub 'compile_file', and use the install builddir then. Maybe also replace in 'link_file' parrot_config with install_config. Or is there a possibility to override the config hash in the pbc somehow? -- Forwarded message -- From: Reini Urban <[EMAIL PROTECTED]> Date: 2008/7/21 Subject: Re: [ANNOUNCEMENT] Updated: parrot-0.6.4-1 with parrot-perl6 and parrot-languages To: [EMAIL PROTECTED] 2008/7/21 Michael Schaap: > On 20-Jul-2008 17:36, Michael Schaap wrote: >> On 19-Jul-2008 21:42, Reini Urban wrote: >>> Michael Schaap schrieb: Is perl6 supposed to (somewhat) work, yet? I get: % perl6 -e 'say "Hello, World!"' "load_bytecode" couldn't find file 'P6object.pbc' current instr.: 'onload' pc 0 (src/gen_builtins.pir:28) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) P6object does exist, in /usr/lib/parrot/library. If I cd to this directory first, I get: % cd /usr/lib/parrot/library; perl6 -e 'say "Hello, World!"' Null PMC access in get_string() current instr.: 'parrot;P6metaclass;add_parent' pc 119 (runtime/parrot/library/P6object.pir:137) called from Sub 'parrot;P6metaclass;add_parent' pc 241 (runtime/parrot/library/P6object.pir:215) called from Sub 'parrot;P6metaclass;register' pc 411 (runtime/parrot/library/P6object.pir:295) called from Sub 'parrot;Str;onload' pc 965 (src/gen_builtins.pir:619) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) > Hmm... I see in /usr/share/doc/parrot-0.6.4/languages/perl6/README: > If you want to create a binary executable of the compiler > that can be invoked as "perl6" from the command line, then > try "make perl6". This will create a "perl6" (or "perl6.exe") > binary that can be directly used from the command line: > > $ ./perl6 hello.pl > > This binary executable feature is still somewhat experimental, > and may not work on all platforms. Also, the binary has hardcoded > paths to the Parrot build tree (especially the dynamic libraries > and modules), so removing the build tree will cause the binary > to stop working. You are right. perl6 and all the similarlily generated parrot-languages binaries do not work. They have hardcoded paths to the builddir, which I thought I have fixed, but my fix only affected parrot itself not the dumped (with pbc_to_exe generated) languages executables. And my test did not include renaming the builddir. Best is to remove these two packages from the release dir until I fix it. I'm behind a strict firewall now, can someone do this for me? -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: 'make' concludes noisily on Darwin
On Fri, 18 Jul 2008, James E Keenan wrote: > Parrot has been building successfully, albeit slowly, for me on Darwin for > several months now. But I must say that the very last line of 'make' output > always shows a lot of warnings of "multiple definitions of symbol". Can > anyone evaluate these? Thanks. > > /usr/bin/g++ -o pbc_merge \ >src/pbc_merge.o \ >src/parrot_config.o \ >src/string_primitives.o \ >-L/Users/jimk/work/parrot/blib/lib -L/Users/jimk/work/parrot/blib/lib > -lparrot -lm -lgmp -lreadline -framework OpenGL -framework GLUT -lcrypto > -lintl -undefined dynamic_lookup -L/sw/lib > /usr/bin/ld: warning multiple definitions of symbol _str_dup > src/string_primitives.o definition of _str_dup in section (__TEXT,__text) > /Users/jimk/work/parrot/blib/lib/libparrot.dylib(string_primitives.o) > definition of _str_dup [more similar warnings omitted] The problem is that src/string_primitives.o is being included twice: It is already included in libparrot.dylib, but it is also being included explicitly on the link line. That strikes me as quite odd. I suspect the explicit linking to src/string_primitives.o can be omitted when building pbc_merge. The other odd thing about this link line is the trailing -L/sw/lib at the very very end. That's odd. Usually, the -L flags go *before* the libraries. It may be that Darwin's linker is insensitive to such details, but, parrot shouldn't assume that all linkers are similarly insensitive. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #56928] [TODO]: Remove config step auto::pack
On Fri, 18 Jul 2008, James Keenan via RT wrote:
> On Fri Jul 18 08:22:48 2008, doughera wrote:
>
> >
> > Oh yes -- I did remember one other. Configure.pl currently offers you
> the
> > opportunity to specify different sizes for opcode_t and INTVAL. However,
> > parrot itself assumes they are the same size. (See [perl #56810] for a
> > little more background.)
> >
>
> This is outside my area of competence, but I suspect the relevant code
> is this part of config/inter/types.pm:
>
> sub runstep {
> my ( $self, $conf ) = @_;
>
> my $intval = $conf->options->get('intval') || 'long';
> my $floatval = $conf->options->get('floatval') || 'double';
> my $opcode = $conf->options->get('opcode') || 'long';
>
> if ( $conf->options->get('ask') ) {
> $intval = prompt( "\n\nHow big would you like your integers to
> be?", $intval );
> $floatval = prompt( "And your floats?",
>$floatval );
> $opcode = prompt( "What's your native opcode type?",
>$opcode );
> print "\n";
> }
>
> $conf->data->set(
> iv => $intval,
> nv => $floatval,
> opcode_t => $opcode
> );
>
> return 1;
> }
>
> Would you care to submit a patch? Thanks.
I just had something trvial in mind, perhaps like this (completely
untested). It still allows the choice via command line options (which
need a reworking, so I didn't touch them) but defaults to using the same
size for both.
--- prompt.orig 2008-07-21 08:46:34.0 -0400
+++ prompt.new 2008-07-21 08:46:24.0 -0400
@@ -3,17 +3,15 @@
my $intval = $conf->options->get('intval') || 'long';
my $floatval = $conf->options->get('floatval') || 'double';
-my $opcode = $conf->options->get('opcode') || 'long';
if ( $conf->options->get('ask') ) {
$intval = prompt( "\n\nHow big would you like your integers to
be?", $intval );
$floatval = prompt( "And your floats?",
$floatval );
-$opcode = prompt( "What's your native opcode type?",
- $opcode );
print "\n";
}
+my $opcode = $conf->options->get('opcode') || $intval;
$conf->data->set(
iv => $intval,
More generally, I was just making my usual rant that prior to extensive
refactoring or testing of any file, it makes sense to consider whether the
existing behavior is even worth refactoring or testing. (Specifically,
I'm thinking about the auto/pack.pm stuff. This opcode_t stuff is more
subtle, but it came up recently in another context, so I thought I'd
mention it.)
--
Andy Dougherty [EMAIL PROTECTED]
Parrot Bug Summary
Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Jul 21 13:00:02 2008 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- Numbers Ticket Counts: 23 new + 643 open = 666 Created this week: 19 Closed this week: 19 --- New Issues New issues that have not been responded to yet 1 - 2 weeks old 56828 [PATCH] Add nativecall support for void** params 56824 [PATCH] Configure - fix SEGV in JIT has_exec_protect test on Cygwin 56782 [TODO] question in getNameForKey in Getopt::Obj 56712 [BUG] --optimize causes perl6 to segfault during make 2 - 3 weeks old 56650 [BUG] class created from namespace fails MMD 56634 [RFC] future direction for config 56622 [BUG?] 'isa' opcode returns inconsistent results 56614 [TODO] Config hash should be marked read-only 56554 [TODO] add languages/*/Makefile install targets 3 - 4 weeks old 56458 Failure to promote RetContinuation objects 4 - 5 weeks old 5 - 6 weeks old 6 - 7 weeks old 7 - 8 weeks old 8 - 9 weeks old 9 - 10 weeks old 54236 [TODO] Allow Parrot Hashes to have PMC keys 10 - 11 weeks old 11 - 12 weeks old 12 - 13 weeks old 13 - 14 weeks old 14 - 15 weeks old 15 - 16 weeks old 16 - 17 weeks old 17 - 18 weeks old 18 - 19 weeks old 19 - 20 weeks old 20 - 21 weeks old --- Overview of Open Issues PlatformSeverity Tag Lang aix0abandoned 05005threads 0 Amber 0 All1fatal 1bounce0 BASIC 0 bsdos 0High 0Bug 107 bc 0 cygwin 2low 0compiler 0 befunge 0 cygwin_nt 0medium0configure 3 bf 0 darwin 9none 1core 2 cola0 dec_osf0Normal3dailybuild0 forth 0 dgux 0unknown 0docs 3 jako0 dos0Wishlist 3duplicate 0 Lisp0 dynixptx 0 install 2 lolcode 0 freebsd6 library 0 m4 0 generic0 notabug 0 ook 0 gnu0 notok 0 perl6 2 HPUX 2 ok0 plot0 irix 0 Patch31 punie 0 irix64 0 regex 2 pynie 0 Linux 1 sendToCPAN0 python 0 lynxos 0 Todo318 ruby0 mac0 unknown 0 scheme 0 machten0 utilities 0 tcl 1 macos 0 wontfix 0 urm 0 MacOS X9 Zcode 0 mswin322 netbsd 1 next 0 openbsd2 os20 os390 0 other 0 powerux0 qnx0 riscos 0 sco0 Solaris7 sunos 1 svr4 0 svr5 0 sysv 0 unicos 0 unicosmk 0 unix 0 unknown0 uts0 vms0 VOS0 Win32 10 --- Ticket Status By Version New or OpenResolved --- Requestors with most open tickets Paul Cochrane 230 Will Coleda69 Patrick R. Michaud 33 chromatic 27 Jerry Gay 23 Bernhard Schmalhofer 17 James Keenan 17 Mark Glines16 Klaas-Jan Stol 15 Reini Urban14 --- * Total Issues * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- This page is CPU intensive to create, it will be updated only once every 30 minutes
Re: HLLs needing OpenGL support
On Mon, 2008-07-21 at 09:34 +0200, François Perrad wrote: > Geoffrey Broadwell a écrit : > > fperrad: How do these bindings actually work? > There'll work with runtime/parrot/library/OpenGL.pir. OK ... so what could be improved about runtime/parrot/library/OpenGL.pir so that you didn't have to write any bindings at all, or so that your bindings could be greatly simplified? So far, I'm seeing the following: 1. HLL access to the GL constants. At the very least, you should already be able to define your constant table using the generated constants in runtime/parrot/include/opengl_defines.pasm, rather than having to hardcode them all. Even better, this should all be wrapped up in an HLL-friendly way for you, but I've been looking for suggestions on how best to do that in a cross-HLL manner. 2. Namespace unflattening (glFoo -> gl.Foo, glutBar -> glut.Bar). That should be easy for runtime/parrot/library/OpenGL.pir to do, but may not be valuable to you if you already have to do everything else below. 3. All subs are marked :anon, and then manually added into a global LuaTable which appears to be reimplementing a namespace. Why? And if all Lua namespaces are created this way, does LuaTable implement enough of the Parrot namespace API that other HLLs will be able to work with Lua-implemented modules? 4. Ignore extra args to each function (which I'm just guessing is the purpose of the '.param pmc extra :slurpy' on every sub). Why do you want to do this? 5. All params are marked :optional (but don't have matching :opt_flag params) and seem required by the code. Again, why do this? 6. Argument type checking and conversion. This appears to be the "real" problem, though this seems like the exact kind of problem that Parrot was supposed to make easier for us. If you have to manually wrap every function in a cross-language library in every HLL because Parrot won't Do The Right Thing, that seems like a design flaw. 7. Simplified wrappers around some common functions. I've been thinking about creating some of these (most OpenGL wrappers for scripting languages seem to do this, to a greater or lesser degree). Whether it is worth it to try to do this in runtime/parrot/library/OpenGL.pir depends on how many HLL implementors are trying to get exact ports of existing bindings in the original (non-parrot) implementation of their language, and how many would be willing to share a common simplified binding. Anything else I'm missing? -'f
[perl #57170] In rakudo, defining a class deriving a not yet defined class produces a Null PMC access
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #57170]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57170 >
While
$ ./perl6 -e 'class B {}; class A is B {}'
works,
$ ./perl6 -e 'class A is B {}; class B {}'
Null PMC access in get_string()
current instr.: 'trait_auxiliary:is' pc 14236 (src/gen_builtins.pir:9180)
called from Sub '_block12' pc 52 (EVAL_13:35)
called from Sub 'parrot;PCT::HLLCompiler;evalpmc' pc 744
(src/PCT/HLLCompiler.pir:448)
called from Sub 'parrot;PCT::HLLCompiler;compile' pc 438
(src/PCT/HLLCompiler.pir:303)
called from Sub 'parrot;PCT::HLLCompiler;eval' pc 776
(src/PCT/HLLCompiler.pir:473)
called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1305
(src/PCT/HLLCompiler.pir:708)
called from Sub 'parrot;Perl6::Compiler;main' pc 14518 (perl6.pir:172)
doesn't.
[perl #57178] [BUG] Broken links on smolder site.
# New Ticket Created by Will Coleda # Please include the string: [perl #57178] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=57178 > http://smolder.plusthree.com/app/public_projects/details/8 Clicking on the "Data Feeds" links /app/public_projects/feed/8 (all) /app/public_projects/feed/8/failed (failed) Generates a server error for each link. -- Will "Coke" Coleda
Re: [perl #57178] [BUG] Broken links on smolder site.
On Mon, Jul 21, 2008 at 2:29 PM, Michael Peters via RT <[EMAIL PROTECTED]> wrote: > On Mon Jul 21 11:15:15 2008, coke wrote: >> http://smolder.plusthree.com/app/public_projects/details/8 >> >> Clicking on the "Data Feeds" links >> >> /app/public_projects/feed/8 (all) >> /app/public_projects/feed/8/failed (failed) >> >> Generates a server error for each link. > > Sorry about that. This should be fixed now. Please try it again. Much better; that gives me an RSS feed that I can subscribe to. However, the feed contains links, e.g: http://smolder.plusthree.com/app/developer_projects/smoke_report/2374 that require a login. Is this intentional? If so, how do I get one? (There's no obvious link on that page for creating a new one, just for lost passwords.) -- Will "Coke" Coleda
Re: [perl #55954] [PATCH]: Add 'make smolder_test' target
Using TAP::Harness::Archive 0.12, successfully ran a "make smolder_test" on windows. http://smolder.plusthree.com/app/public_projects/report_details/2381 --- tjh On Jul 19, 2008, at 8:51 AM, Michael Peters wrote: Tim Heckman wrote: One thing I've found is that I cannot install TAP::Harness::Archive on windows machines because of test failures. I submitted a ticket about this to rt.cpan.org for this along with possible fixes http://rt.cpan.org/Public/Bug/Display.html?id=37795 I saw those and will try to get to them today. Right now I have a screaming infant to get out of a high chair :) -- Michael Peters Plus Three, LP
Re: [perl #57178] [BUG] Broken links on smolder site.
Will Coleda wrote: On Mon, Jul 21, 2008 at 2:29 PM, Michael Peters via RT <[EMAIL PROTECTED]> wrote: On Mon Jul 21 11:15:15 2008, coke wrote: http://smolder.plusthree.com/app/public_projects/details/8 Clicking on the "Data Feeds" links /app/public_projects/feed/8 (all) /app/public_projects/feed/8/failed (failed) Generates a server error for each link. Sorry about that. This should be fixed now. Please try it again. Much better; that gives me an RSS feed that I can subscribe to. However, the feed contains links, e.g: http://smolder.plusthree.com/app/developer_projects/smoke_report/2374 that require a login. Is this intentional? No this was not. It should be fixed, so please try again. If so, how do I get one? (There's no obvious link on that page for creating a new one, just for lost passwords.) I can create a user for you if you want. If you plan on using the XML feeds then there's no reason. But if you want to use the email interface for getting the report notifications (it's more flexible and provides more options) then I can create one for you. But for most public projects, the XML feeds should be good enough. -- Michael Peters Plus Three, LP
Re: [perl #57178] [BUG] Broken links on smolder site.
On Mon, Jul 21, 2008 at 2:48 PM, Michael Peters <[EMAIL PROTECTED]> wrote: > Will Coleda wrote: >> >> On Mon, Jul 21, 2008 at 2:29 PM, Michael Peters via RT >> <[EMAIL PROTECTED]> wrote: >>> >>> On Mon Jul 21 11:15:15 2008, coke wrote: http://smolder.plusthree.com/app/public_projects/details/8 Clicking on the "Data Feeds" links /app/public_projects/feed/8 (all) /app/public_projects/feed/8/failed (failed) Generates a server error for each link. >>> >>> Sorry about that. This should be fixed now. Please try it again. >> >> Much better; that gives me an RSS feed that I can subscribe to. >> However, the feed contains links, e.g: >> >> http://smolder.plusthree.com/app/developer_projects/smoke_report/2374 >> >> that require a login. Is this intentional? > > No this was not. It should be fixed, so please try again. Nope, still asking me for a login. >> If so, how do I get one? >> (There's no obvious link on that page for creating a new one, just for >> lost passwords.) > > I can create a user for you if you want. If you plan on using the XML feeds > then there's no reason. But if you want to use the email interface for > getting the report notifications (it's more flexible and provides more > options) then I can create one for you. But for most public projects, the > XML feeds should be good enough. > > -- > Michael Peters > Plus Three, LP > > -- Will "Coke" Coleda
Re: [perl #57178] [BUG] Broken links on smolder site.
Will Coleda wrote: that require a login. Is this intentional? No this was not. It should be fixed, so please try again. Nope, still asking me for a login. Sorry, I wasn't completely clear. That URL will always prompt you for a login. The XML feed should have given the public URL, so that's where the problem was. Can you refresh the XML feed and check the URLs? -- Michael Peters Plus Three, LP
Re: [perl #57178] [BUG] Broken links on smolder site.
On Mon, Jul 21, 2008 at 3:07 PM, Michael Peters <[EMAIL PROTECTED]> wrote: > Will Coleda wrote: > that require a login. Is this intentional? >>> >>> No this was not. It should be fixed, so please try again. >> >> Nope, still asking me for a login. > > Sorry, I wasn't completely clear. That URL will always prompt you for a > login. The XML feed should have given the public URL, so that's where the > problem was. Can you refresh the XML feed and check the URLs? That URL -did- come from the feed; checking again... Going through Google Reader seems to be caching the old version of the feed. If I just wget the feed, it shows the non-developer URLS, so it'll work going forward, I suppose. Could be overeager caching, but I suspect that if you just changed the code to generate the feed but didn't mark those articles as "new" in some fashion, that the updates will be ignored. I'll keep an eye out for new smolders and see if those URLs come through properly. Thanks. > -- > Michael Peters > Plus Three, LP > > -- Will "Coke" Coleda
Re: website, OSCON
On Fri, Jul 11, 2008 at 4:59 PM, Will Coleda <[EMAIL PROTECTED]> wrote: > Can someone who is attending OSCON write up a blurb for the parrot web > site similar to the (now past) one there for YAPC::NA? > > I'd be happy to post it if the person that writes it isn't Allison or > chromatic... ^_^ > > Thanks... > > -- > Will "Coke" Coleda > Ah well. Nevermind. -- Will "Coke" Coleda
Re: pbc install_config: howto install perl6 and languages?
Reini Urban schrieb: How is make install for the pbc_to_exe generated languages supposed to work? For the utils you simply link to a fixed install_config.o with fixed builddir. But the languages are generated from a .pir file with hardcoded, wrong builddir. I think about adding support for an optional --install arg in all pir's for the pbc_to_exe step sub 'compile_file', and use the install builddir then. Maybe also replace in 'link_file' parrot_config with install_config. Or is there a possibility to override the config hash in the pbc somehow? I did it now this way: pbc_to_exe accepts a 2nd optional arg. If it's --install the exe is prefixed with "installable_", and it's not linked against parrot_config.o but against install_config.o This way I can produce installable languages. For now I did it just for perl6. Good? Bad? -- Forwarded message -- From: Reini Urban <[EMAIL PROTECTED]> Date: 2008/7/21 Subject: Re: [ANNOUNCEMENT] Updated: parrot-0.6.4-1 with parrot-perl6 and parrot-languages To: [EMAIL PROTECTED] 2008/7/21 Michael Schaap: On 20-Jul-2008 17:36, Michael Schaap wrote: On 19-Jul-2008 21:42, Reini Urban wrote: Michael Schaap schrieb: Is perl6 supposed to (somewhat) work, yet? I get: % perl6 -e 'say "Hello, World!"' "load_bytecode" couldn't find file 'P6object.pbc' current instr.: 'onload' pc 0 (src/gen_builtins.pir:28) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) P6object does exist, in /usr/lib/parrot/library. If I cd to this directory first, I get: % cd /usr/lib/parrot/library; perl6 -e 'say "Hello, World!"' Null PMC access in get_string() current instr.: 'parrot;P6metaclass;add_parent' pc 119 (runtime/parrot/library/P6object.pir:137) called from Sub 'parrot;P6metaclass;add_parent' pc 241 (runtime/parrot/library/P6object.pir:215) called from Sub 'parrot;P6metaclass;register' pc 411 (runtime/parrot/library/P6object.pir:295) called from Sub 'parrot;Str;onload' pc 965 (src/gen_builtins.pir:619) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) Hmm... I see in /usr/share/doc/parrot-0.6.4/languages/perl6/README: If you want to create a binary executable of the compiler that can be invoked as "perl6" from the command line, then try "make perl6". This will create a "perl6" (or "perl6.exe") binary that can be directly used from the command line: $ ./perl6 hello.pl This binary executable feature is still somewhat experimental, and may not work on all platforms. Also, the binary has hardcoded paths to the Parrot build tree (especially the dynamic libraries and modules), so removing the build tree will cause the binary to stop working. You are right. perl6 and all the similarlily generated parrot-languages binaries do not work. They have hardcoded paths to the builddir, which I thought I have fixed, but my fix only affected parrot itself not the dumped (with pbc_to_exe generated) languages executables. And my test did not include renaming the builddir. Best is to remove these two packages from the release dir until I fix it. I'm behind a strict firewall now, can someone do this for me? -- Reini Urban http://phpwiki.org/ http://murbreak.at/ difforig languages/perl6/config/makefiles/root.in tools/dev/pbc_to_exe_gen.pl diff -u languages/perl6/config/makefiles/root.in.orig languages/perl6/config/makefiles/root.in --- languages/perl6/config/makefiles/root.in.orig 2008-07-11 06:47:06.0 + +++ languages/perl6/config/makefiles/root.in 2008-07-21 20:14:57.25000 + @@ -113,6 +113,9 @@ perl6.pbc: $(PARROT) $(SOURCES) $(PARROT) $(PARROT_ARGS) -o perl6.pbc perl6.pir +installable_perl6$(EXE): perl6.pbc + $(PBC_TO_EXE) perl6.pbc --install + src/gen_grammar.pir: $(PERL6GRAMMAR) src/parser/grammar.pg src/parser/grammar-oper.pg $(PARROT) $(PARROT_ARGS) $(PERL6GRAMMAR) \ --output=src/gen_grammar.pir \ diff -u tools/dev/pbc_to_exe_gen.pl.orig tools/dev/pbc_to_exe_gen.pl --- tools/dev/pbc_to_exe_gen.pl.orig 2008-07-19 08:18:54.671875000 + +++ tools/dev/pbc_to_exe_gen.pl 2008-07-21 20:41:08.87500 + @@ -54,8 +54,40 @@ argc = args if argc == 2 goto proper_args +if argc == 3 goto check_install .return () +check_install: +.local string infile, install + +$P0= shift args +infile = shift args +install = shift args +if install == '--install' goto proper_install +.return () + +proper_install: +.local string cfile, objfile, obj, exefile, exe + +$P0= '_config'() +obj= $P0['o'] +exe= $P0['exe'] + +.local int infile_len +infile_len = length infile +infile_len -= 3 + +cfile = substr infile, 0, infile_len +cfile .= 'c' + +dec infile_len +objfile = substr infile, 0, infile_len +exefile = 'installable_' +exefile.= objfile +exefile.= exe +objfile.= obj +.return(infile, cfile, objfile, exefile) + proper_args: .local string infile, cfile,
ParrotSketch Cancelled for July 21, 2008
Reminder: given the number of folks attending OSCON this week, the IRC #parrotsketch is cancelled for tomorrow, and will resume again on July 29, 2008 Regards. -- Will "Coke" Coleda
[perl #56948] [BUG] .parrot_current_rev broken
Patch applied in r29660 tonight.
Common Lisp and pushaction
From: Allison Randal <[EMAIL PROTECTED]> Date: Sun, 20 Jul 2008 23:27:44 -0700 . . . That patch demonstrates the exact behaviour that is no longer supported under the new spec and implementation. Tell me more about how you're using the old pushaction, and I'll suggest alternatives for implementing that functionality. Allison I am using pushaction to implement UNWIND-PROTECT [1] and dynamic (a.k.a. "special") variable binding [2]. These features are both illustrated by the "Actions" page of my YAPC talk [3]. The diagrams on this page show how the current implementation works in gory detail. I mention this example because it is a reasonable approximation to a real-world case that illustrates why one would want continuations to invoke actions transparently. (Indeed, this is why I made the feature work the way it does in r14668. ;-) In fact, you can check out the whole talk from the Subversion repository [4] and run "make test" (after appropriate makefile editing). The test-action case does indeed fail in pdd25cx; I tried it before and thought it was working, but I must have tested it wrong. Just to be painfully clear, these are critical Common Lisp features, without which Kea-CL is not worth pursuing. -- Bob [1] http://www.lispworks.com/documentation/HyperSpec/Body/s_unwind.htm [2] http://www.lispworks.com/documentation/HyperSpec/Body/d_specia.htm [3] http://rgrjr.dyndns.org/perl/acsip/actions.html [4] https://rgrjr.dyndns.org/svn/web-site/trunk/perl/acsip/
Re: pbc install_config: howto install perl6 and languages?
On Monday 21 July 2008 13:48:41 Reini Urban wrote: > I did it now this way: > > pbc_to_exe accepts a 2nd optional arg. > If it's --install the exe is prefixed with "installable_", and it's not > linked against parrot_config.o but against install_config.o > > This way I can produce installable languages. For now I did it just for > perl6. Is there any reason to link against parrot_config.o instead of install_config.o? -- c
Re: [perl #46681] [TODO] [C] Use strerror_r instead of strerror
Andy Dougherty via RT wrote:
On Thu, 17 Jul 2008, Christoph Otto via RT wrote:
On Thu Jul 17 15:53:12 2008, julianalbo wrote:
On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT
<[EMAIL PROTECTED]> wrote:
trick. The attached patch (v5) properly fixes the problem on my system.
There shouldn't be any remaining issues, but the patch ought to be
tested on a another *nix and Windows.
[ . . . ]
char *errstr = strerror_r(errno, errmsg, ERRBUF_SIZE);
Unfortunately, that's not portable. The POSIXy version of strerror_r
returns an integer, specifically 0 if successful, and something else
otherwise. (What that "something" else actually is seems to be
defined differently by different vendors, alas. OpenBSD and Solaris
return errno. Linux/glibc returns -1.)
Thanks for pointing that out. After what it's taking to get this to work, I'm
looking forward to my next patch being silently ignored. I suppose there's a
reason my spell checker wanted to turn "strerror" to "terrorist".
This version of the patch should dtrt with all versions of strerror_r. It
works on my Debian/x86 box and I'll be testing it on any *nix I can get my
hands on Tuesday. If it works fine there, if someone can test it on windows
and if the patch looks OK, I'll commit it and close this ticket.
Christoph
Index: src/pmc/file.pmc
===
--- src/pmc/file.pmc (revision 29667)
+++ src/pmc/file.pmc (working copy)
@@ -24,8 +24,50 @@
#include "parrot/parrot.h"
-/* RT#46681 apparently, strerror_r is thread-safe and should be used instead.*/
+/* strerror_r should truncate the message if it's too long for the supplied
+ * buffer. It's probably best to just specify a sane default buffer size than
+ * to worry about retrying calls. */
+#define ERRBUF_SIZE 128
+/* feature test macro taken from Ubuntu's strerror man page */
+#if (_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE
+/* use POSIXy strerror_r */
+# define STRERROR_R_EXCEPTION(interp, func) \
+{ \
+char errmsg[ERRBUF_SIZE]; \
+int err_status; \
+err_status = strerror_r(errno, errmsg, ERRBUF_SIZE); \
+/* Linux's POSIXy strerror_r returns -1 on error, others return an error code */ \
+if (err_status == -1) \
+err_status = errno; \
+\
+if (err_status == 0 || err_status == ERANGE) { \
+STRING *errmsg_pstring = string_make((interp), errmsg, strlen(errmsg), NULL, 0); \
+real_exception((interp), NULL, E_SystemError, "%Ss", errmsg_pstring); \
+} \
+else if (err_status == EINVAL){ \
+real_exception((interp), NULL, E_SystemError, \
+"%s returned an invalid error code (%d)", #func, errno); \
+else { \
+real_exception((interp), NULL, E_SystemError, \
+"strerror_r() returned an unknown error code: %d", err_status); \
+} \
+}
+#else
+/* use GNU-specific strerror_r */
+# define STRERROR_R_EXCEPTION(interp, func) \
+{ \
+/* GNU strerror_r DTRT for unknown error codes */ \
+char errmsg[ERRBUF_SIZE]; \
+char *errstr = strerror_r(errno, errmsg, ERRBUF_SIZE); \
+STRING *errmsg_pstring = string_make((interp), errstr, strlen(errstr), NULL, 0); \
+real_exception((interp), NULL, E_SystemError, "%Ss", errmsg_pstring); \
+}
+#endif
+
+
+
+
static PMC *File_PMC;
pmclass File singleton {
@@ -89,6 +131,7 @@
*/
+
METHOD is_dir(STRING *path) {
struct stat info;
char *cpath = string_to_cstring(interp, path);
@@ -100,8 +143,11 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+#ifdef WIN32
+STRERROR_R_EXCEPTION(INTERP, stat);
+#else
+STRERROR_R_EXCEPTION(INTERP, lstat);
+#endif
}
if (S_ISDIR(info.st_mode))
@@ -131,8 +177,11 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+#ifdef WIN32
+STRERROR_R_EXCEPTION(INTERP, stat);
+#else
+STRERROR_R_EXCEPTION(INTERP, lstat);
+#endif
}
if (S_ISREG(info.st_mode))
@@ -164,8 +213,7 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION(INTERP, lstat);
}
if (S_ISLNK(info.st_mode))
@@ -199,6 +247,8 @@
string_cstring_free(cfrom);
+char errmsg[ERRBUF_SIZE];
+
if (source) {
char *cto= string_to_cstring(interp, to);
FILE *target = fopen(cto, "w+b");
@@ -223,14 +273,12 @@
fclose(target);
}
