Re: Parrot on mobile platforms?
Thanks for the quick answer. Then I have another few questions :-) Don't you think it would be important to start working in this direction? Maybe to try to get someone work on this or to get sponsorship in that direction? Gabor On Thu, Oct 23, 2008 at 8:33 AM, chromatic [EMAIL PROTECTED] wrote: On Wednesday 22 October 2008 23:23:46 Gabor Szabo wrote: I am totally lack of relevant knowledge so I'd like to get some from you. There are many mobile platforms out there. Linux based, Symbian, Blackberry, iPhone, Windows, Palm, Android, etc.. I wonder what are the chances of Parrot running on any of these? Decent, with some work. Has anyone tried? Not to my knowledge. What needs to be done in order to get Parrot on these devices? With the iPhone or Android-based phones, someone would have to crack the phone such that we have access to what passes for bare OS, instead of the Objective C/NeXT runtime or Dalvik. For the other platforms, we need to: 1) Figure out a cross-compilation strategy (which means improving our configuration system such that it takes hints from a file, not from direct probes and Perl 5's Config.pm) 2) Disable certain features (different runcores, JIT, much of NCI) 3) Add architecture and platform-specific files for the parts of POSIX they don't already support 4) Figure out an installation and execution strategy for bytecode 5) Revisit #2, to get the installation size down further (500k for a Parrot binary seems like a maximum) -- c
Re: the future of testing
On Jan 10, 2008 12:23 PM, Allison Randal [EMAIL PROTECTED] wrote: Aye, I would want to improve on the Python solution. But maintaining a config file something like: [darwin] t/pmc/foo.t 3 5-7 9 # platform doesn't support libfoo t/pmc/bar.t 1 42 ... [MSWin32] t/pmc/foo.t 32 ... This seems to be too obvious to be a real question but what if someone adds a new test in the middle of bar.t ? Will she have to remember to update the numbers in the central config file? Gabor
Workshop and Hackathon in Israel
Hi, I have announced it elsewhere but I hope it is OK to do it here as well. On 31 December 2007 we are going to have a one day Perl Workshop in Israel http://act.perl.org.il/ilpw2007/ Following the workshop, between 1-5 January 2008 we are going to have a Hackathon in Tel Aviv. http://act.perl.org.il/ilpw2007/hackathon.html On the Hackathon we would like to deal with all kinds of Perl related issues including Parrot. I hope to see some of you on the Hackathon. If you are interested please register on the site and add yourself to the wiki page. If you are coming from overseas, please do it ASAP so we'll see how many international guests to expect. regards Gabor -- Gabor Szabo http://www.szabgab.com/
Re: Parrot configuration system: weaknesses and strengths
I am not sure what to quote so let me reply on a clean page. I would like to see invalid configuration options and values as being always fatal. They indicate some kind of user error, a typo or similar that would probably cause trouble to the Parrot developer as well as the Parrot user. In order to archive that I wonder if it would be possible to allow two methods: 1) The individual configuration step could report an error as a return value so the harness can decide if this particular failure is fatal or not. 2) In addition the individual configuration step could declare a fatal error (e.g. by die-ing) that would be respected by the harness and reported as fatal. Gabor
Re: [PATCH] don't allow invalid --gc options
On 9/3/07, Andy Dougherty [EMAIL PROTECTED] wrote: On Sat, 1 Sep 2007, Gabor Szabo wrote: It has biten me so let's make sure invalid --gc options are not allowed. But what if I want to work on --gc=libc? How can I override this? I am not sure I understand you. If you want to work on --gc=libc then you shuold put just that on the command line, it is a valid option. You should not make a mistake as I did, giving --gc-libgc as that would silently fall back to --gc=gc Gabor
Re: [perl #45137] [TODO] Add a revision control test in Configure.pl
Can someone explain, please why are there tests that need a version control system? It sounds strange to me. Gabor On 9/3/07, via RT Paul Cochrane [EMAIL PROTECTED] wrote: # New Ticket Created by Paul Cochrane # Please include the string: [perl #45137] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45137 Many tests in the Parrot test suite check for the existence of a given revision control system (e.g. svn/svk/git) before determining if the test should be run. This can be done just the once at Configure time; the tests can then probe the result. A new configure step will need to be added, and then any tests containing direct tests of the existence of svn/svk/git will need to be changed to probe for the relevant result.
Re: Build Farm
Hi David, if non of the core Parrot developers answer you then let me, the newcomer do so. Recently I have been involved in a little research where I was looking at various automatic build and test smoking systems. Among others I looked at the PostgreSQL build farm as well. See my blog entries: http://www.szabgab.com/blog/2007/07/1183825266.html I liked it very much though I have some issues that I think should be improved there too. Regarding Parrot, I think there was some discussion of moving it to use TAP::Harness and to use Smolder to collect the TAP based results. I am quite in favor of having something like the PostgreSQL build farm integrated with TAP::Parser and possibly Smolder and adding some other features as well. So I'd be glad to participate in your project and help making sure that the all the needs of the Parrot team are addressed. Gabor On 8/30/07, David Fetter [EMAIL PROTECTED] wrote: Folks, I'm working on generalizing PostgreSQL's buildfarm code http://www.pgbuildfarm.org/, an automated build and test system, and of course I thought of Parrot. The requirements are very light: * Disk space for the source code and build * Connectivity to the internet via HTTP or HTTPS * Some way (cron, e.g.) to run jobs regularly * Some way to get regular updates to one or more branches of the source code Would people here be interested in running clients on various architectures, OSs, compilers, etc.? What kinds of things would you like to see in a status overview page like this one: http://www.pgbuildfarm.org/cgi-bin/show_status.pl How about in detailed build reports? Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate -- Gabor Szabo http://www.szabgab.com/
Re: [PATCH] don't allow invalid --gc options
On 9/1/07, James E Keenan [EMAIL PROTECTED] wrote:
(Gabor: You didn't cc: the list on this, so I'm replying directly to
you. But I think the issues you are raising merit discussion on the
list. So please feel free to copy what I write below to the list.)
Sure, I meant to send it to the list actually.
It seems the beer from YAPC::EU still have not fully settled down..
On Sep 1, 2007, at 12:35 PM, Gabor Szabo wrote:
Thanks for the pointers, I was not sure where to add this.
On 9/1/07, James E Keenan [EMAIL PROTECTED] wrote:
2. Modify config/auto/gc.pm to have configuration step auto::gc
fail if
any invalid option is provided. (I did a quick grep on config/
and this
is the only place I saw the 'gc' option handled -- but I might have
gotten confused by the many instances of 'gcc'.) A statement
along the
lines of 'return unless $gc =~ /list|of|valid|options/;' around
line 62
of that package would probably be the way to go.
The problem is that if I place a return; in the function you
recommended
the configuration process displays a small error message, then
a bigger unrelated one (at least unrelated from the point of view
of the
user running it) , creates the Makefile and exit()s with exit value 0
meaning success.
It also suggests to type in 'make' to build Parrot.
Even if I croak() in that function, the same happens.
I understand your point -- but it's a much larger point than the
permissible values for the --gc option. Read on.
IMHO if a user supplies an invalid option (to --gc or any other
parameter)
an appropriate error message should be printed, the configuration
process
should be halted and exit() should indicate failure.
All of the (currently) 58 Parrot configuration steps are set up to
return undef on failure. But Parrot::Configure::runsteps() is set up
as a harness that reports failures in individual steps/tasks but
nonetheless tries to keep going forward. It does nothing with the
return value of a particular step.
#
sub runsteps {
my $conf = shift;
my $n = 0;# step number
my ( $verbose, $verbose_step, $ask ) =
$conf-options-get( qw( verbose verbose-step ask ) );
foreach my $task ( $conf-steps ) {
$n++;
$conf-_run_this_step( {
task= $task,
verbose = $verbose,
verbose_step= $verbose_step,
ask = $ask,
n = $n,
} );
}
return 1;
}
#
Whether that's what it ideally *should* be doing is a valid
question. But in the refactoring/testing work I've been doing on it
in recent months, I've viewed it as my mandate to preserve its
current functioning unless there's a strong consensus that change is
needed.
Some might argue, If you're foolish enough to continue on to 'make'
when your configuration process is spewing error messages, you get
what you deserve. That's in effect what happens now.
Another alternative would be to note whether any of the configuration
steps fails, then change the message which
Parrot::Configure::Messages::print_conclusion() prints after all the
configuration steps complete.
At this point I really don't want to get involved any deeper in the development
and I am sure you will clean this up later so I'll try to send a patch according
to what you wrote.
One thing though, I think it would be really good if at least the exit code of
the script would be something different from 0 when any of the steps failed.
That will be very important when we try to integrate with the PG Build Farm
or any other fully automated smoke test suite to make sure we won't go on
when the configuration step fails.
Gabor
[PATCH] don't allow invalid --gc options (2nd try)
Index: config/auto/gc.pm
===
--- config/auto/gc.pm (revision 20963)
+++ config/auto/gc.pm (working copy)
@@ -107,7 +107,7 @@
gc_flag = '-DGC_IS_MALLOC',
);
}
-else {
+elsif ( $gc eq 'gc' ) {
$gc = 'gc';
$conf-data-set(
TEMP_gc_c = EOF,
@@ -116,7 +116,11 @@
TEMP_gc_o = \$(SRC_DIR)/gc/resources\$(O),
gc_flag = '',
);
-}
+} else {
+print STDERR Inavlid value '$gc' for the --gc option\n;
+return;
+}
+
print( ($gc) ) if $conf-options-get('verbose');
return $self;
perl Configure.pl --gc=malloc does not build either
gcc --version gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) perl Configure.pl --gc=malloc make this is the STDERR: [...] newpdd15class_p_s 1254 experimental, not in ops.num newpdd15class_p_sc1255 experimental, not in ops.num newpdd15class_p_p 1256 experimental, not in ops.num newpdd15class_p_pc1257 experimental, not in ops.num setstdout_p SKIPPED: not in ops.num nor ops.skip setstderr_p SKIPPED: not in ops.num nor ops.skip hash_i_p SKIPPED: not in ops.num nor ops.skip src/exceptions.c: In function âdo_panicâ: src/exceptions.c:152: warning: ânoreturnâ function does return src/gc/dod.c: In function âclear_cowâ: src/gc/dod.c:471: warning: request for implicit conversion from âvoid *â to âstruct Buffer *â not permitted in C++ src/gc/dod.c: In function âused_cowâ: src/gc/dod.c:512: warning: request for implicit conversion from âvoid *â to âconst struct Buffer *â not permitted in C++ src/gc/dod.c:530: warning: cast discards qualifiers from pointer target type src/library.c: In function âParrot_locate_runtime_file_strâ: src/library.c:442: warning: ignoring return value of âParrot_get_runtime_prefixâ, declared with attribute warn_unused_result src/packfile.c: In function âParrot_load_bytecodeâ: src/packfile.c:3388: warning: ignoring return value of âPackFile_append_pbcâ, declared with attribute warn_unused_result src/pmc_freeze.c: In function âpush_opcode_numberâ: src/pmc_freeze.c:627: warning: ignoring return value of âPF_store_numberâ, declared with attribute warn_unused_result src/pmc_freeze.c: In function âpush_opcode_stringâ: src/pmc_freeze.c:648: warning: ignoring return value of âPF_store_stringâ, declared with attribute warn_unused_result src/spf_render.c: In function âhandle_flagsâ: src/spf_render.c:179: warning: ignoring return value of âstring_substrâ, declared with attribute warn_unused_result src/spf_render.c: In function âParrot_sprintf_formatâ: src/spf_render.c:294: warning: ignoring return value of âstring_substrâ, declared with attribute warn_unused_result src/spf_render.c:807: warning: ignoring return value of âstring_substrâ, declared with attribute warn_unused_result src/stack_common.c: In function âregister_new_stackâ: src/stack_common.c:57: warning: ignoring return value of âmake_bufferlike_poolâ, declared with attribute warn_unused_result src/stm/backend.c: In function âParrot_STM_allocâ: src/stm/backend.c:216: warning: ignoring return value of âmake_bufferlike_poolâ, declared with attribute warn_unused_result In file included from src/exec.c:26: src/jit_emit.h: In function âdiv_rr_nâ: src/jit_emit.h:1720: warning: cast discards qualifiers from pointer target type src/jit_emit.h: In function âmod_rr_nâ: src/jit_emit.h:1759: warning: cast discards qualifiers from pointer target type src/jit_emit.h: In function âopt_div_rrâ: src/jit_emit.h:1953: warning: cast discards qualifiers from pointer target type src/jit_emit.h: In function âParrot_emit_jump_to_eaxâ: src/jit_emit.h:2202: warning: cast from function call of type âint *â to non-matching type âlong intâ In file included from src/exec_cpu.c:51: src/jit_emit.h: In function âdiv_rr_nâ: src/jit_emit.h:1720: warning: cast discards qualifiers from pointer target type src/jit_emit.h: In function âmod_rr_nâ: src/jit_emit.h:1759: warning: cast discards qualifiers from pointer target type src/jit_emit.h: In function âopt_div_rrâ: src/jit_emit.h:1953: warning: cast discards qualifiers from pointer target type src/jit_emit.h: In function âParrot_emit_jump_to_eaxâ: src/jit_emit.h:2202: warning: cast from function call of type âint *â to non-matching type âlong intâ In file included from src/jit.c:35: src/jit_emit.h: In function âdiv_rr_nâ: src/jit_emit.h:1720: warning: cast discards qualifiers from pointer target type src/jit_emit.h: In function âmod_rr_nâ: src/jit_emit.h:1759: warning: cast discards qualifiers from pointer target type src/jit_emit.h: In function âopt_div_rrâ: src/jit_emit.h:1953: warning: cast discards qualifiers from pointer target type src/jit_emit.h: In function âParrot_emit_jump_to_eaxâ: src/jit_emit.h:2202: warning: cast from function call of type âint *â to non-matching type âlong intâ In file included from src/jit_cpu.c:51: src/jit_emit.h: In function âdiv_rr_nâ: src/jit_emit.h:1720: warning: cast discards qualifiers from pointer target type src/jit_emit.h: In function âmod_rr_nâ: src/jit_emit.h:1759: warning: cast discards qualifiers from pointer target type src/jit_emit.h: In function âopt_div_rrâ: src/jit_emit.h:1953: warning: cast discards qualifiers from pointer target type src/jit_emit.h: In function âParrot_emit_jump_to_eaxâ: src/jit_emit.h:2202: warning: cast from function call of type âint *â to
build error
I am experimenting a bit with the compilation of Parrot perl Configure.pl --gc=malloc-trace make stopped with: src/malloc.c:4719: warning: function call has aggregate value make: *** [src/malloc-trace.o] Error 1 below is the stderr Gabor print_newline 1211 experimental, not in ops.num print_newline_p 1211 experimental, not in ops.num gcd_i_n_n 1212 experimental, not in ops.num gcd_i_nc_n1213 experimental, not in ops.num gcd_i_n_nc1214 experimental, not in ops.num gcd_i_nc_nc 1215 experimental, not in ops.num gcd_i_i_i_i_i 1216 experimental, not in ops.num gcd_i_i_i_ic_i1217 experimental, not in ops.num gcd_i_i_i_i_ic1218 experimental, not in ops.num gcd_i_i_i_ic_ic 1219 experimental, not in ops.num splice_p_p_i_i1220 experimental, not in ops.num splice_p_p_ic_i 1221 experimental, not in ops.num splice_p_p_i_ic 1222 experimental, not in ops.num splice_p_p_ic_ic 1223 experimental, not in ops.num slice_p_p_k 1224 experimental, not in ops.num slice_p_p_kc 1225 experimental, not in ops.num slice_p_p_k_ic1226 experimental, not in ops.num slice_p_p_kc_ic 1227 experimental, not in ops.num iter_p_p 1228 experimental, not in ops.num morph_p_i 1229 experimental, not in ops.num morph_p_ic1230 experimental, not in ops.num exec_s1231 experimental, not in ops.num exec_sc 1232 experimental, not in ops.num classname_p_p 1233 experimental, not in ops.num trap 1234 experimental, not in ops.num pow_n_n_i 1235 experimental, not in ops.num pow_n_nc_i1236 experimental, not in ops.num pow_n_n_ic1237 experimental, not in ops.num pow_n_nc_ic 1238 experimental, not in ops.num getclass_p_i 1239 experimental, not in ops.num getclass_p_ic 1240 experimental, not in ops.num new_p_i_s 1241 experimental, not in ops.num new_p_ic_s1242 experimental, not in ops.num new_p_i_sc1243 experimental, not in ops.num new_p_ic_sc 1244 experimental, not in ops.num instantiate_p 1245 experimental, not in ops.num pmcinfo_i_p_ic1246 experimental, not in ops.num new_p_p 1247 experimental, not in ops.num new_p_p_p 1248 experimental, not in ops.num new_p_p_pc1249 experimental, not in ops.num add_io_event_p_p_p_ic 1250 experimental, not in ops.num need_finalize_p 1251 experimental, not in ops.num runinterp_p_p 1252 experimental, not in ops.num runinterp_p_pc1253 experimental, not in ops.num newpdd15class_p_s 1254 experimental, not in ops.num newpdd15class_p_sc1255 experimental, not in ops.num newpdd15class_p_p 1256 experimental, not in ops.num newpdd15class_p_pc1257 experimental, not in ops.num setstdout_p SKIPPED: not in ops.num nor ops.skip setstderr_p SKIPPED: not in ops.num nor ops.skip hash_i_p SKIPPED: not in ops.num nor ops.skip src/exceptions.c: In function âdo_panicâ: src/exceptions.c:152: warning: ânoreturnâ function does return src/gc/dod.c: In function âclear_cowâ: src/gc/dod.c:471: warning: request for implicit conversion from âvoid *â to âstruct Buffer *â not permitted in C++ src/gc/dod.c: In function âused_cowâ: src/gc/dod.c:512: warning: request for implicit conversion from âvoid *â to âconst struct Buffer *â not permitted in C++ src/gc/dod.c:530: warning: cast discards qualifiers from pointer target type src/library.c: In function âParrot_locate_runtime_file_strâ: src/library.c:442: warning: ignoring return value of âParrot_get_runtime_prefixâ, declared with attribute warn_unused_result src/packfile.c: In function âParrot_load_bytecodeâ: src/packfile.c:3388: warning: ignoring return value of âPackFile_append_pbcâ, declared with attribute warn_unused_result src/pmc_freeze.c: In function âpush_opcode_numberâ: src/pmc_freeze.c:627: warning: ignoring return value of âPF_store_numberâ, declared with attribute warn_unused_result src/pmc_freeze.c: In function âpush_opcode_stringâ: src/pmc_freeze.c:648: warning: ignoring return value of âPF_store_stringâ, declared with attribute warn_unused_result src/spf_render.c: In function âhandle_flagsâ: src/spf_render.c:179: warning: ignoring return value
Re: build error
On 8/30/07, chromatic [EMAIL PROTECTED] wrote: What's your platform? Which compiler are you using? sorry. this was my third attempt to post this report. I might have forgotten to include this information: gcc --version gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) uname -a Linux notebook 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux Gabor ps. the previous attempt to post were rejected with the error about possible Hi virus. Even though it seems the problem was that I tried to attach the stderr file.
