Re: unprefixed global symbols
At 12:11 PM -0500 3/14/04, Mitchell N Charity wrote: Leopold Toetsch [EMAIL PROTECTED] wrote: Marcus Holland-Moritz [EMAIL PROTECTED] wrote: One of my modules embeds the ucpp preprocessor, which has a function init_tables(). The same function exists in parrot. Renamed. Another item for the embedding/extending todo list: namespace hygiene. Ultimately the linker needs to expose only those symbols which we want exposed, and those symbols need a unique prefix. Yeah, it'll be a cross-platform pain, but it needs doing, and it is doable. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: unprefixed global symbols
One could also take a look at tools/dev/nm.pl, something I submitted to Leo a few days back. Basically, it tries to be a portable nm frontend. nm.pl -g -o libparrot.a does more or less the same what you did.
Re: unprefixed global symbols
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Mitchell N Charity) wrote: Leopold Toetsch [EMAIL PROTECTED] wrote: Marcus Holland-Moritz [EMAIL PROTECTED] wrote: One of my modules embeds the ucpp preprocessor, which has a function init_tables(). The same function exists in parrot. Renamed. Another item for the embedding/extending todo list: namespace hygiene. Some thought perhaps needs to go into creating a family of prefixes, and documenting their roles. Mitchell (nipped by mark_hash last week) I agree that this is rather important. I think all parrot externally visible macros, types and all functions should be prefixed Parrot_ as a start. Are patches welcome that change this? Changing one at a time is not going to be really helpful. All it does is make following CVS changes a bit painful. Arthur
Re: unprefixed global symbols
Arthur Bergman [EMAIL PROTECTED] wrote: I think all parrot externally visible macros, types and all functions should be prefixed Parrot_ as a start. Are patches welcome that change this? Sure. But we should allow some already used prefixes too, beside Parrot_. We have: - Parrot_ API - PDB_ Parrot Debugger - PF_ PackFile - PackFile_ PackFile - PIO_ Parrot IO ... Changing one at a time is not going to be really helpful. All it does is make following CVS changes a bit painful. Yep Arthur leo
Re: unprefixed global symbols
On 15 Mar 2004, at 12:54, Leopold Toetsch wrote: I think all parrot externally visible macros, types and all functions should be prefixed Parrot_ as a start. Are patches welcome that change this? Sure. But we should allow some already used prefixes too, beside Parrot_. We have: Cool, I still thing everything should be prefixed Parrot since we are the first and the only project named parrot - Parrot_ API - PDB_ Parrot Debugger PDB is too generic ParrotDB_ - PF_ PackFile ParrotPF , PF alone is already a taken prefix for Packet Filter if I don't recall wrong, not to mention the ancient define of PF_ - PackFile_ PackFile PackFile_ is too generic IMO too, and why PF and PackFile? - PIO_ Parrot IO ParrotIO_ Cheers Arthur
Re: unprefixed global symbols
Arthur Bergman [EMAIL PROTECTED] wrote: PDB is too generic ParrotDB_ - PF_ PackFile ParrotPF , PF alone is already a taken prefix for Packet Filter if I don't recall wrong, not to mention the ancient define of PF_ - PackFile_ PackFile PackFile_ is too generic IMO too, and why PF and PackFile? The PF_ functions are low-level. I'd started to separate packfile.c and during that used the PF_ prefix. Anyway ParrotPF_ is good for both. - PIO_ Parrot IO ParrotIO_ Ok. Thanks. Cheers Arthur May be its best if someone who has commit privs just changes the globals and puts it in - its of not much help to send around huge patches. And finally: $ perl tools/dev/nm.pl --code --global parrot | grep -v ^Parrot leo
Re: unprefixed global symbols
On Mar 15, 2004, at 7:36 AM, Leopold Toetsch wrote: Arthur Bergman [EMAIL PROTECTED] wrote: PDB is too generic ParrotDB_ Of course, ParrotDB sounds like Parrot database May be its best if someone who has commit privs just changes the globals and puts it in - its of not much help to send around huge patches. We should be able to get the linker to only expose our external entry points from libparrot. That way, we don't have to worry about the naming of API which isn't supposed to be called from outside. (If it works, it's simpler and safer than relying on a prefix.) JEff
Re: unprefixed global symbols
On 15 Mar 2004, at 17:20, Jeff Clites wrote: On Mar 15, 2004, at 7:36 AM, Leopold Toetsch wrote: Arthur Bergman [EMAIL PROTECTED] wrote: PDB is too generic ParrotDB_ Of course, ParrotDB sounds like Parrot database May be its best if someone who has commit privs just changes the globals and puts it in - its of not much help to send around huge patches. We should be able to get the linker to only expose our external entry points from libparrot. That way, we don't have to worry about the naming of API which isn't supposed to be called from outside. (If it works, it's simpler and safer than relying on a prefix.) JEff And how would this be done across platforms, if this works I am happy with it, but I don't know how. Arthur
Re: unprefixed global symbols
We should be able to get the linker to only expose our external entry points from libparrot. That way, we don't have to worry about the naming of API which isn't supposed to be called from outside. (If it works, it's simpler and safer than relying on a prefix.) JEff And how would this be done across platforms, if this works I am happy with it, but I don't know how. Arthur We could always use a source preprocessor to add a uN1qUePr1VaTe_ prefix to a list of unprefixed global symbols... ;) Mitchell (not entirely in jest -- robust prefixing so clutters code:)
Re: unprefixed global symbols
On Mar 15, 2004, at 9:22 AM, Arthur Bergman wrote: On 15 Mar 2004, at 17:20, Jeff Clites wrote: We should be able to get the linker to only expose our external entry points from libparrot. That way, we don't have to worry about the naming of API which isn't supposed to be called from outside. (If it works, it's simpler and safer than relying on a prefix.) And how would this be done across platforms, if this works I am happy with it, but I don't know how. On Mac OS X and Linux at least, as I understand it this can be done with either 'ld' or 'strip'. (The 'ld' argument for this on Mac OS X is -exported_symbols_list, and on Linux it's --retain-symbols-file, each taking the name of a file containing the list of symbols to retain.) I'd imagine that other Unices have similar linker options, and I'd think that Windows would have an equivalent also. I haven't actually tried this, but the tools seem to be there. JEff
unprefixed global symbols
Leopold Toetsch [EMAIL PROTECTED] wrote: Marcus Holland-Moritz [EMAIL PROTECTED] wrote: One of my modules embeds the ucpp preprocessor, which has a function init_tables(). The same function exists in parrot. Renamed. Another item for the embedding/extending todo list: namespace hygiene. Some thought perhaps needs to go into creating a family of prefixes, and documenting their roles. Mitchell (nipped by mark_hash last week) $ nm ./blib/lib/libparrot.a |egrep ' [TDRC] |\.o:'|grep -v Parrot_ exceptions.o: 0920 T do_exception 0034 T do_panic 086c T handle_exception T internal_exception 0498 T new_c_exception_handler 089c T new_internal_exception 0448 T pop_exception 0220 T push_exception 04d4 T push_new_c_exception_handler 0974 T real_exception 064c T rethrow_c_exception 05d8 T rethrow_exception 04fc T throw_exception global_setup.o: 0018 C class_count_mutex 0004 C class_table_size R data_types 0004 C enum_class_max T init_world 0004 C interpreter_array 0018 C interpreter_array_mutex 0004 C n_interpreters 0004 C run_native interpreter.o: 2c4c T disable_event_checking 0330 T do_prederef 256c T dynop_register 2c70 T enable_event_checking 2c94 T enter_nci_method 0898 T exec_init_prederef 0910 T init_jit 21f0 T interpinfo 0388 C interpre 1ae4 T make_interpreter 09bc T prepare_for_run 1008 T runops 0c64 T runops_int 24cc T sysinfo_i 2514 T sysinfo_s register.o: 00cc T mark_pmc_register_stack 007c T mark_register_stack 0194 T mark_string_register_stack T setup_register_stacks memory.o: 00dc T mem_setup_allocator T mem_sys_allocate 0040 T mem_sys_allocate_zeroed 00c4 T mem_sys_free 0080 T mem_sys_realloc objects.o: packfile.o: 2d28 T PackFile_ConstTable_clear 2dac T PackFile_ConstTable_unpack 2f58 T PackFile_Constant_destroy 2f30 T PackFile_Constant_new 2f70 T PackFile_Constant_pack_size 30a0 T PackFile_Constant_unpack 3584 T PackFile_Constant_unpack_key 33c8 T PackFile_Constant_unpack_pmc 25c4 T PackFile_FixupTable_clear 2a2c T PackFile_FixupTable_new_entry 127c T PackFile_Segment_destroy 1514 T PackFile_Segment_dump 1f44 T PackFile_Segment_new 11fc T PackFile_Segment_new_seg 136c T PackFile_Segment_pack 12c8 T PackFile_Segment_packed_size 144c T PackFile_Segment_unpack 09c4 T PackFile_add_segment T PackFile_destroy 2ca4 T PackFile_find_fixup_entry 0a20 T PackFile_find_segment 394c T PackFile_fixup_subs 0d40 T PackFile_funcs_register 0964 T PackFile_map_segments 0bfc T PackFile_new 0ac8 T PackFile_remove_segment_by_name 06a8 T PackFile_unpack 0f50 T default_dump_header 0004 C exec_const_table 03f4 T mark_const_subs stacks.o: 06bc T get_entry_type 003c T mark_stack 0018 T new_stack 062c T pop_dest 028c T rotate_entries 0144 T stack_destroy 01c8 T stack_entry 014c T stack_height 0654 T stack_peek 0540 T stack_pop 04a0 T stack_push T stack_system_init stack_common.o: T cst_new_stack 0088 T stack_copy 0288 T stack_prepare_pop 0130 T stack_prepare_push 00cc T stack_unmake_COW string.o: 0444 T const_string 16bc T hash_string_equal 028c T string_append 1918 T string_bitwise_and 1ae8 T string_bitwise_or 1d94 T string_bitwise_xor 2040 T string_bool 13cc T string_chopn 145c T string_compare 0c7c T string_compute_strlen 0cc8 T string_concat 0a68 T string_copy 2520 T string_cstring_free 26d4 T string_downcase 26f4 T string_downcase_inplace 179c T string_equal 03ec T string_from_cstring 246c T string_from_int 2498 T string_from_num 05a0 T string_grow 0610 T string_index 024c T string_init 2658 T string_iterator_init 05ec T string_length 0480 T string_make 0cb4 T string_max_bytes 20ec T string_nprintf 09b0 T string_ord 2538 T string_pin 0e6c T string_repeat 10e8 T string_replace 01f4 T string_set 08dc T string_str_index 0f2c T string_substr 2710 T string_titlecase 2730 T string_titlecase_inplace 24c8 T string_to_cstring 21ac T string_to_int 21dc T string_to_num 0a88 T string_transcode 25b0 T string_unpin 2698 T string_upcase 26b8 T string_upcase_inplace sub.o: 0024 T cow_copy_context 0ea0 T lexicals_mark 0168 T mark_context 071c T new_closure 0790 T new_continuation 07f8 T new_coroutine 07c4 T new_ret_continuation 08d4 T new_ret_continuation_pmc 06a0 T new_sub 0144 T restore_context T save_context 0ee0 T scratchpad_delete 0d78 T scratchpad_get 0968 T scratchpad_get_current 0e00 T scratchpad_get_index 0aa0 T scratchpad_new 0c20 T scratchpad_store 0cc0 T
