[perl #24662] [PATCH] Mac OS X dynamic loading using the primary API
# New Ticket Created by Jeff Clites # Please include the string: [perl #24662] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=24662 > This patch allows dynamic loading to work on Mac OS X (without using the dl* compatibility API included with Mac OS 10.3). A couple of notes: 1) Mac OS X distinguishes between two types of "shared libraries": dylibs, which are meant to be linked at compile-time (and automatically loaded by the dynamic linker at runtime), and bundles, which are meant to be loaded "by hand", via explicit API. This implementation of the Parrot_dl* API attempts to hide the distinction and "do the right thing" for either case, but the two types of libraries do act differently--they are manipulated via different API, and among other differences dylibs cannot be unloaded (bundles can be), and bundles aren't searched for in any standard locations (dylibs can be). 2) The ncurses-life demo works partially with this patch applied--ncurses is clearly invoked (there is a generation count in green, counting up on a black background), but there doesn't seem to be any "life" animation. But I suspect that this is not a library loading issue. 3) There's some logging still in place which should be cleaned up long-term (maybe once Parrot_dlerror is implemented), but which is useful for the moment. (For instance, the ncurses-life demo will log when it fails to find its libraries without an extension.) JEff macosx-dynamic-loading.patch Description: Binary data
Segfault in extend.c/ parrot_pmc_get_pointer
Hi, today I hit a little bug
#0 0x081cef45 in Parrot_PMC_get_pointer (interp=0x82d7f78,
pmc=0x8a0)
at src/extend.c:44
#1 0x080c5403 in Perl_macro_LvTYPE (sv=0x82d3410) at sv.c:1280
#2 0x080b196f in Perl_hv_fetch_ent (hv=0x8387588, keysv=0x82d3400,
lval=0,
hash=4044421188) at hv.c:402
#3 0x080be9cc in Perl_pp_helem () at pp_hot.c:1675
#4 0x080a24f5 in Perl_runops_debug () at dump.c:1439
#5 0x08060e00 in S_run_body (oldscope=1) at perl.c:1711
#6 0x08060968 in perl_run (my_perl=0x82d1b68) at perl.c:1630
#7 0x0804bfed in main (argc=4, argv=0xbfffdbe4, env=0xbfffdbf8)
at miniperlmain.c:86
#8 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
As far as I can tell the parrot interp is correct and the PMC too, the
class is a perl5lv.pmc and it has a init that looks like this:
void init () {
PMC_data(SELF) = malloc(sizeof(perl5lv_pmc_data));
}
and it also has
void init () {
PMC_data(SELF) = malloc(sizeof(perl5lv_pmc_data));
}
Any suggestions?
Arthur
ps, does parrot have an abstraction for malloc? also, please reply to
both ponie-dev/perl6-internals
Re: Segfault in extend.c/ parrot_pmc_get_pointer
Arthur Bergman <[EMAIL PROTECTED]> wrote: > #0 0x081cef45 in Parrot_PMC_get_pointer (interp=0x82d7f78, > pmc=0x8a0) That looks like the vtable could be corrupted. $ p *pmc $ p *pmc->vtable > Any suggestions? Maybe the PMC got destroyed by a DOD run. You can check that by disabling DOD after Parrot_new(). (Parrot has a commandline option -G for this). Also the pmc's flags should reflect that. > Arthur > ps, does parrot have an abstraction for malloc? mem_sys_allocate mem_sys_allocate_zeroed mem_sys_realloc in src/memory.c leo
Re: Vocabulary
According to Larry Wall: > Actually, I think making people declare what they want to extend > might actually provide a nice little safety mechanism for what can > be modified by the eval and what can't. Well, I don't know about such 'safety' ... seems like a bone in a pond to me ... but as a means to optimization it's a good idea, AFAICT. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K
Re: Vocabulary
On Sun, Dec 14, 2003 at 06:14:42PM -0800, Larry Wall wrote: > On Sun, Dec 14, 2003 at 03:16:16AM -0600, Jonathan Scott Duff wrote: > [ my ramblings about a mechanism for role methods to supercede class > methods elided ] > > I think there's a simple way to solve this: If you're changing the > policy of the class, then you're changing the class! Derive from the > "defective" class and pull in the roles the way you prefer. D'oh! You are absolutely correct. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
[CVS ci] event-handling-4
I've committed a first attempt towards event handling. Caused by the absence of further design docs it might be not a scheme, that will finally be run, but I hope that at least parts are useful. Its a bit tested w. dynoplibs/alarm.pasm $ parrot dynoplibs/alarm.pasm 0 1 alarm Please s. docs/dev/events.pod for more Comments welcome, leo
Re: pthreads-win32
At 2:01 PM +0100 12/14/03, Leopold Toetsch wrote: Can we use this lib: http://sources.redhat.com/pthreads-win32/ distributed under the GNU Lesser General Public License (LGPL) I think so, yes. I'd rather use windows native threading if we can, though. If perl 5 is anything to go by, it shouldn't be a problem, and I think we're going to have to handle some pretty platform-specific stuff with threads as part of Parrot. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #24662] [PATCH] Mac OS X dynamic loading using the primary API
At 12:00 AM + 1/1/04, Jeff Clites (via RT) wrote: # New Ticket Created by Jeff Clites # Please include the string: [perl #24662] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=24662 > This patch allows dynamic loading to work on Mac OS X (without using the dl* compatibility API included with Mac OS 10.3). I've committed (or will commit, depending on mail ordering) this patch. While I've not looked at ncurses_life to see why things don't display, I can say that it *does* work for me on another project, so... woohoo! :) It did tickle a bug I'd introduced (or that was already introduced) in dynext.c, which is also fixed. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More object stuff
At 9:47 PM + 12/11/03, Harry Jackson wrote: Dan Sugalski wrote: Yep, though that's a big part of it. postgres.pasm is generated from postgres.declarations, FWIW--there's a script in the library somewhere. Is /parrot/build_tools/build_nativecall.pl the script in question and if so whats its usage. It's util/ncidef2pasm.pl, actually. build_nativecall builds the stub routines for the interpreter if a JIT isn't available. The definitions of the characters are the same, but ncidef2pasm's a bit better documented. (There's embedded POD) Invocation is: util/ncidef2pasm.pl definition_file output.pasm I have done postgres.declarations, please see below. Woo! And, might I add, hoo! :) Thanks. Revision 1.100 Gah. Good indication that it's time to get the metadata for library versioning in place. #extern void PQreset(PGconn *conn); # This was set to "c PQreset p" was this correct. v PQreset p Yours is right. (I expect it was a typo on my part, unless Postgres' interface changed, which is really unlikely) # Need function pointers. Can't do that yet # New IN 7.4 #i PQsetNoticeReceiver p p # # i PQsetNoticeProcessor p p I think, oddly enough, that we can actually do these, but I'm not sure it can be done with the nci interface as it currently stands. The callback function can be an entry to the interpreter runops loop and the parameter the pointer to the closure to execute, but I'm not sure how to express that one properly at the moment. # The following functions are missing from the original 7.3 version # so I am leaving these as well. I am including the declarations here # to let people know the ommission was deliberate. Not 100% why # though ;-) Because of the FILE * argument. I didn't have a good way at the time to get one,so I left the functions out. They're just debugging/convenience functions, so I was fine with that one. Looks really good, though. Thanks heaps -- now it's on to higher-level stuff! :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
bug? in Test::More error counting ?
hi folks, I just got a CPANTS report.. I am puzzled how 5 tests could fail 10 times DIED. FAILED tests 1-5 Failed 5/5 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t\speed.t255 65280?? ?? % ?? t\warns.t 2 512 5 10 200.00% 1-5 later in the report, I see following, which may be a factor, but I cant see how it happens, much less how it alters the test-count. You tried to plan twice! Second plan at t\warns.t line 5 any comments ? thx
Re: bug? in Test::More error counting ? MINIMIZED TEST CASE
Jim Cromie wrote: hi folks, Failed Test Stat Wstat Total Fail Failed List of Failed --- t\warns.t 2 512 5 10 200.00% 1-5 You tried to plan twice! Second plan at t\warns.t line 5 It appears that this doesnt error on 5.8.2, but is repeatable on 5.00503, as follows: cat warns.t-2warns #!perl use Test::More (tests => 5); eval "use Test::Warn"; plan skip_all => "Test::Warn needed to test that warnings are properly issued" if $@; __END__ [EMAIL PROTECTED] Data-Dumper-EasyOO-0.01]$ perl5.00503 warns.t-2warns 1..5 You tried to plan twice! Second plan at warns.t-2warns line 5 # Looks like your test died before it could output anything.
Re: bug? in Test::More error counting ? MINIMIZED TEST CASE
> It appears that this doesnt error on 5.8.2, but is repeatable on 5.00503, > as follows: I don't see any problem here. You can't have more than one plan. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: bug? in Test::More error counting ? MINIMIZED TEST CASE
Andy Lester wrote: It appears that this doesnt error on 5.8.2, but is repeatable on 5.00503, as follows: I don't see any problem here. You can't have more than one plan. xoa The different Version responses threw me.. I worked out a way... use Test::More; use Benchmark(); plan skip_all => "Benchmark::cmpthese not implemented in this Benchmark version $Benchmark::VERSION" unless defined &Benchmark::cmpthese; plan (tests => 2); IOW - plan only after skip_all special case... thx
Re: bug? in Test::More error counting ? MINIMIZED TEST CASE
On Mon, Dec 15, 2003 at 11:32:12AM -0600, Andy Lester wrote: > > It appears that this doesnt error on 5.8.2, but is repeatable on 5.00503, > > as follows: > > I don't see any problem here. You can't have more than one plan. t\warns.t 2 512 5 10 200.00% 1-5 Five tests. Ten failures. Tests 1 through 5 failed. That might be a problem. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ What about MY need to be generalized and easily dismissed? http://www.goats.com/archive/000221.html
[perl #24667] IMCC not handling some integer constant parameters properly
# New Ticket Created by Dan Sugalski # Please include the string: [perl #24667] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=24667 > If, as part if a prototyped .pcc_begin/.pcc_end function call set, you try and set an integer parameter equal to the register number the integer would go into. If you do this, the assignment to that integer register will be discarded and the register will have whatever it started with in it. The upshot is that this: .pcc_begin prototyped .arg 1 .arg 6 .arg 7 .pcc_call foo .pcc_end emits this pasm: set_i_ic I5, 1 set_p_p P0, P16 rather than this pasm set_i_ic I5, 1 set_i_ic I6, 6 set_i_ic I7, 7 set_p_p P0, P16 Which, as you might expect, leads to some bizarre behaviour. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: pthreads-win32
From: "Dan Sugalski" <[EMAIL PROTECTED]> > At 2:01 PM +0100 12/14/03, Leopold Toetsch wrote: > >Can we use this lib: > >http://sources.redhat.com/pthreads-win32/ > >distributed under the GNU Lesser General Public License (LGPL) > > I think so, yes. I'd rather use windows native threading if we can If by "native threading" you mean bare Win32 API functions, I'd rather use the multithread version of the Microsoft C Run Time library. First of all, 'cause we have already been linking against it, and the second, it provides a proper initialization for threads, and the third, it's been supporting by Microsoft, not by a single man. Well, I surmise that the pthreads lib either uses native threading, the main difference beetween CRT and pthreads being that the later just is a new wheel conforming the POSIX standard Hope the pthreads library won't turn out a way to go for Parrot. 0x4C56
Object Order of Precedence (Was: Vocabulary)
Larry Wall wrote: > Jonathan Lang wrote: > : Let's see if I've got this straight: > : > : role methods supercede inherited methods; > > But can defer via SUPER:: > > : class methods supercede role methods; > > But can defer via ROLE:: or some such. Check, and check. Of course, SUPER:: works well in single inheritence, but runs into problems of "which superclass?" in multi-inheritence; ROLE:: would on the surface appear to have that same problem, except that... > : conflicting methods from multiple roles get discarded... > > They aren't silently discarded--they throw a very public exception. > (But methods with differing "multi" signatures are not considered to > be conflicting, I hope.) (OK.) > : ...but the class may alias or exclude any of the conflicting methods > : to explicitly resolve the dispute. > > Right. Another possibility is that the class's method could be > declared to be the default multi method in case the type information > is not sufficient to decide which role's multi method should be called. > Maybe if it's declared "multi" it works that way. Otherwise it's just > called first automatically. ...meaning that the question of "which role do you mean?" has already been addressed by the time the ROLE:: "deference" gets used. Although I'm not following what you're saying here in terms of the third means of disambiguation. Could someone provide an example, please? > : trait methods supercede class methods; > > I'm not sure traits work that way. I see them more as changing the > metaclass rules. They feel more like macros to me, where anything > goes, but you have to be a bit explicit and intentional. Well, the question is: the trait is providing a method with the same name as a method provided by the class, and type information is insufficient to distinguish between them; which one do I use? In the absence of additional conflict resolution code, the possible options as I see them would be: 1) the class supercedes the trait 2) the trait supercedes the class 3) an ambiguity exception gets thrown 4) the trait's method can't be called without explicitly naming the trait Which of these three ought to hold true? Second, where does the additional conflict resolution code go? In the trait, in the class, or somewhere else? > : Am I right so far? Maybe not; I noticed earlier that you've mentioned > : that roles can be applied at compile-time using "does" or at run-time > : using "but"; might _that_ be the defining feature as to whether the > : role supercedes the class or vice versa? "does" supercedes > : inheritence, "has" and "method" supercedes "does", "is" and "but" > : supercedes "has" and "method"... > > No, I think I'm rejecting that notion as too complicated to keep > track of from moment to moment, and too much like slatherons in > policy wishy-washiness. The method precedence won't change from > compile time to run time. OK. My concern is that things like properties add new factors to the ambiguity issue that you can't expect the class to know about, because they're being introduced after the class was written. The fact that a role supercedes inheritence makes sense to me (more precisely, it isn't counterintuitive); that a class supercedes a role also makes sense to me, as long as the role was there when the class was defined. But when you add a role to the class after the fact, as in the case of properties, I don't see how you can expect the class to be able to resolve the conflict. What happens when the sticky note that you put on a microwave oven covers up the display panel? It's not so much run-time vs. compile-time as it is "while the class is being written" and "after the class has been written", and the principle that he who knows the most about what's going on should make the decisions. Perhaps this could be handled by requiring "sticky-note" roles (of which properties are a subset) to be explicitly named when their methods are called? That is, "after the fact" roles don't get flattened into the class the way that normal roles do. That way, you're not requiring either the class _or_ the role to resolve the conflict. This would be similar to the relationship between positional parameters and named parameters, in that the latter is there to let you add capabilities to an existing function without disrupting the way that the function normally operates. (OTOH, that's just about _all_ that it has in common.) > : So how do you resolve conflicts between things that supercede the > : class? First come first serve (as per slatherons)? > > Well, nothing much really supercedes the class. Even traits have > to be requested by the class, and if you have an entirely different > metaclass, it's probably declared with a different keyword than > C. (But sure, multiple traits will have to applied in order > of declaration, and I don't doubt there will be ordering dependencies.) My apologies; I'm apparently a bit weak on my object-or
Re: Vocabulary
On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote: But the agreement could be implied by silence. If, by the time the entire program is parsed, nobody has said they want to extend an interface, then the interface can be considered closed. In other words, if you think you *might* want to extend an interface at run time, you'd better say so at compile time somehow. I think that's about as far as we can push it in the "final" direction. That seems a very fair rule, especially if it adds a smidge more speed. Runtime extension will likely be very unusual -- requiring it to be explicit seems reasonable. I'm probably spouting nonsense. I just hope it's good-sounding nonsense... It's beyond good-sounding, it's frickin' awesome. MikeL
