Ticket #128 (closed patch: wontfix)

Opened 13 years ago

Last modified 11 years ago

Honor source types in Parrot_locate_runtime_file

Reported by: rurban Owned by: jkeenan
Priority: minor Milestone:
Component: core Version: branch
Severity: medium Keywords: pdd30install
Cc: Language:
Patch status: new Platform: all

Description (last modified by rurban) (diff)

Forcing getting a pir or pasm with PARROT_RUNTIME_FT_SOURCE and PARROT_RUNTIME_FT_PIR are ignored in the load_bytecode library search.

If there's a .pbc it is always returned, even if the requested type was source or pir.

I've added a todo t/src/library.t testcase for this problem.

This is currently nowhere used, might be wanted to force recompilation, instead of loading the already compiled pbc.

Attachments

trac128-FT_SOURCE-ignored.patch Download (4.8 KB) - added by rurban 13 years ago.

Change History

Changed 13 years ago by rurban

Changed 13 years ago by rurban

  • owner set to rurban
  • status changed from new to assigned
  • description modified (diff)

Changed 13 years ago by rurban

  • description modified (diff)

Changed 13 years ago by rurban

  • keywords pdd30install added
  • version set to branch
  • patch set to applied

Added a third argument to try_bytecode_extensions() to pass the file_type down. Only on PARROT_RUNTIME_FT_PBC we find a .pbc now, on PARROT_RUNTIME_FT_SOURCE and PARROT_RUNTIME_FT_PIR we find no existing .pbc. TBD: No check for PIR or SOURCE yet. Do we want this?

Applied to pdd30install_stage3 as r34944  http://www.parrotvm.org/svn/parrot/revision?rev=34944

Changed 12 years ago by jkeenan

  • type changed from bug to patch
  • patch changed from applied to new

Since this ticket had not been touched in 12 months, tonight I tried running the tests in the patch against trunk. Given the patch's relative age, it is perhaps not surprising that the tests failed:

prove -v t/src/library.t 
t/src/library.t .. 
1..3
not ok 1 - Parrot_locate_runtime_file

#   Failed test 'Parrot_locate_runtime_file'
#   at t/src/library.t line 40.
# Exited with error code: [SIGNAL 11]
# Received:
# 
# Expected:
# ./runtime/parrot/library/Data/Dumper.pir
# ./runtime/parrot/library/Data/Dumper.pbc
# ./runtime/parrot/library/Data/Dumper.pbc
# (null)
# ./runtime/parrot/library/Data/Dumper.pir
# 
# 'cc -o t/src/library_2 t/src/library_2.o src/parrot_config.o 
-L/home/jimk/work/parrot/blib/lib -lparrot 
-Wl,-rpath=/home/jimk/work/parrot/blib/lib  
-fstack-protector -L/usr/local/lib -Wl,-E  
-lpthread -lm -L/usr/lib  -licuuc -licudata 
-lpthread -lm -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp -lreadline ' 
failed with exit code 1
# Failed to build 't/src/library_2': t/src/library_2.o: In function `main':
# /home/jimk/work/parrot/t/src/library_2.c:18: undefined reference to `const_string'
# /home/jimk/work/parrot/t/src/library_2.c:19: undefined reference to `const_string'
# /home/jimk/work/parrot/t/src/library_2.c:19: undefined reference to `string_concat'
# collect2: ld returned 1 exit status
not ok 2 - FT_DYNEXT

#   Failed test 'FT_DYNEXT'
#   at t/src/library.t line 86.
not ok 3 - FT_SOURCE, FT_PIR # TODO TT #128 force pir
#   Failed (TODO) test 'FT_SOURCE, FT_PIR'
#   at t/src/library.t line 132.
# Exited with error code: [SIGNAL 11]
# Received:
# 
# Expected:
# ./runtime/parrot/library/Data/Dumper.pir
# ./runtime/parrot/library/Data/Dumper.pir
# 
# Looks like you failed 2 tests of 3.
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/3 subtests 

Test Summary Report
-------------------
t/src/library.t (Wstat: 512 Tests: 3 Failed: 2)
  Failed tests:  1-2
  Non-zero exit status: 2
Files=1, Tests=3,  2 wallclock secs ( 0.01 usr  0.00 sys +  0.59 cusr  0.14 csys =  0.74 CPU)
Result: FAIL

Is there anything that can be salvaged here? Or should we simply reject?

Thank you very much.
kid51

Changed 12 years ago by coke

  • status changed from assigned to new
  • owner rurban deleted

Changed 11 years ago by jkeenan

  • owner set to jkeenan
  • status changed from new to assigned

Changed 11 years ago by jkeenan

  • status changed from assigned to closed
  • resolution set to wontfix

In 14 months, no one has spoken up about the possibility of salvaging anything from the patch. I am therefore closing the ticket.

Thank you very much.

kid51

Note: See TracTickets for help on using tickets.