wxWindows support?
Back in July, I asked if it was possible to interface Parrot with the wxWindows (an open source, cross platform, native UI framework). The answer was (1) it could be done via NCI, but *ick*, and (2) custom PMCs plus object support might be a better route, but they hadn't been implemented yet. Since that point, objects have been added to Parrot, and there's been a lot of progress on other things. I'm wondering if it's now possible to interface wxWindows to Parrot. Thanks! -- David Cuny
IMCC bug: newclass optimized away
Both newclass and addattrib are optimized away by the 'used_once' optimization under -O2. This is obviously incorrect, since they have side-effects. Luke
Re: Strangeness with '.sub' in macros
Bernhard Schmalhofer [EMAIL PROTECTED] wrote: When a macro contains a '.sub' call, and that macro is used twice, then I get a 'memory error'. Confirmed. The segfault is in expand_pcc_sub_call(), the sub SymReg is NULL on the second expansion. How can I tell 'parrot' to dump a core file? Tell your OS to dump core :) $ man bash /ulimit $ ulimit -c 2 CU, Bernhard leo
Re: IMCC keyed crasher
Dan Sugalski [EMAIL PROTECTED] wrote: IMCC bus errors (at least on OS X) when presented with the construct: set $P0[$I1], Params[$I1] That's an unimplemented multi-keyed operation. leo
Re: Problem during make test
Harry Jackson [EMAIL PROTECTED] wrote: It gets even stranger. If I do a make clean and make test again it does not necessarily stop in the same place each time ie. Do you have a SMP machine with SMP enabled in your OS? The unpredictable behavior of your freezes makes me think, that it could be related to multi-threading. OTOH arithmetic tests or such don't utilize threads and no events are being generated. leo
Re: More calling convention stuff
Dan Sugalski [EMAIL PROTECTED] wrote: I've added a new op to the list, foldup, to make unprototyped calls (and some prototyped calls) a bit easier. The syntax is: foldup Px Now, as there is a second (almost duplicate) incarnation, the implementation should really be an external subroutine as opcodes code is expanded into each run core. The question is - into which C file does it fit best? leo
Re: IMCC bug: newclass optimized away
Luke Palmer [EMAIL PROTECTED] wrote: Both newclass and addattrib are optimized away by the 'used_once' optimization under -O2. This is obviously incorrect, since they have side-effects. Please don't use -O2 :) Its experimental and its not up to all changes. Luke leo
Re: PMC registry
Dan Sugalski [EMAIL PROTECTED] wrote: register Px unregister Px Done. Its using a custom hash with the ref count being the value. Tests wanted :) leo
Shared arena threads, GC, executable memory allocator
As already outlined the current copying GC isn't really thread-safe. A possible solution is to suspend all threads, while the shared interpreter is running garbage collection. A shared-all thread type could use the same scheme, instead of explicitely declare a PMC to be shared, all is shared implicitely and is living in the shared interpreters arena_base. OTOH the copying collector has disadvantages for the unthreaded case too (e.g. hash buckets can get moved during string_compare). We already have a non-moving GC system selectable at configure time. But when the external LEA allocator is used, memory allocation isn't thread safe. Libc's allocator is based on ptmalloc[1] - an early offspring of the LEA allocator, but ptmalloc isn't portable. We can use the underlaying C-library as our allocator, but there are AFAIK speed issues on some systems. And finally: Recent issues with fedora and non-executable JIT code also show a demand for an allocator inside parrot. Writing a full-fledged allocator isn't trivial. Following the glossary and bibliography links from e.g. [2] may keep you reading for a while :) Having an own allocator would have another advantage: We can pass hints to the allocator about the usage of the memory block. Executable code for JIT is long-living and unlikely to be resized. String buffers used e.g. in string_append, freeze, or Parrot_sprintf are very likely of having a short life-time and being subject to resizing. leo [1] http://www.malloc.de [2] http://www.memorymanagement.org
Re: Change 22021: Upgrade to Test::Harness 2.40.
Andy Lester wrote: wrt RGS feedback,
I don't get the rationale for this change; diag() is supposed to be
used for error/diagnostic messages, right ? not for comments, more
mundane in nature. (This perturbs the nice line-up of my test logs.
Go ahead and patch it. I'll add an unless $ENV{PERL_CORE} in the next
release.
Darn dual-life modules...
xoa
Well, it seems Ive been abusing diag() for some time now :-O
Is there a 'right' way to do this ? perhaps just using ok() ?
or maybe a new function, ex: note() is better:
note..ok# YOUR INFORMATIONAL
MESSAGE HERE
Since Ive been using diag() to denote groups of tests,
which separates chunks of foo . ok,
But this appears to be precisely what RGS doesnt like.
Hence ive UPCASEd the note to give it some of the visual distinction
that I got from diag(), hopefully w/o the annoyance.
Is this worthwhile ? If so, Ill work up a patch
Re: Change 22021: Upgrade to Test::Harness 2.40.
Jim Cromie wrote: Well, it seems Ive been abusing diag() for some time now :-O Is there a 'right' way to do this ? perhaps just using ok() ? ok() goes to stdout by default, diag() to stderr or maybe a new function, ex: note() is better: note..ok# YOUR INFORMATIONAL MESSAGE HERE if that goes to stdout, that won't appear in the default harness output Since Ive been using diag() to denote groups of tests, which separates chunks of foo . ok, But this appears to be precisely what RGS doesnt like. Or use separate .t files ? Hence ive UPCASEd the note to give it some of the visual distinction that I got from diag(), hopefully w/o the annoyance. Is this worthwhile ? If so, Ill work up a patch
Re: Change 22021: Upgrade to Test::Harness 2.40.
Rafael Garcia-Suarez wrote: Jim Cromie wrote: Well, it seems Ive been abusing diag() for some time now :-O Is there a 'right' way to do this ? perhaps just using ok() ? ok() goes to stdout by default, diag() to stderr which is, I presume, why perl -Ilib t/foo.t produces more output than make test. I see that as a feature.I guess note() should go to stderr - for my preferences at least. I guess I should just do it here, and see how it turns out ;-) or maybe a new function, ex: note() is better: note..ok# YOUR INFORMATIONAL MESSAGE HERE if that goes to stdout, that won't appear in the default harness output Im not sure whether you regard this as a problem or a feature. Since Ive been using diag() to denote groups of tests, which separates chunks of foo . ok, But this appears to be precisely what RGS doesnt like. Or use separate .t files ? for some cases, thats overkill. For example, Ive got several sets of 2-nested for loops doing a single tests combinatorially with 2 options. The loops are so similar, it seems silly to put them in separate files. the diag()s just helped me find the broken tests. Hence ive UPCASEd the note to give it some of the visual distinction that I got from diag(), hopefully w/o the annoyance. Is this worthwhile ? If so, Ill work up a patch even with it in - theres a long delay before it becomes ubiquitious, so it cant be used with out dependency consequences.
Re: More calling convention stuff
At 11:51 AM +0100 12/31/03, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: I've added a new op to the list, foldup, to make unprototyped calls (and some prototyped calls) a bit easier. The syntax is: foldup Px Now, as there is a second (almost duplicate) incarnation, the implementation should really be an external subroutine as opcodes code is expanded into each run core. The question is - into which C file does it fit best? It's probably a misc.c or util.c thing. Seems the right place for it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
More Windows dev questions: Core dumps
Or something much like them. On a Unix system, a core dump is a file with a raw (mostly) copy of a process' current memory image that's written whenever a process does something profoundly illegal, like accessing an inaccessible section of memory with no trap handler that allows recovery or something of the sort. They're handy, because it means you can go and debug a process after the fact, and don't have to be there on the spot to figure out what's going on. Really handy for things that die overnight, or when you're not around, and you don't want the defunct process hanging around until you can attach to it with a debugger. Does Windows do this? (I know other OSes, like VMS, do *not* do it) If so, how do I enable it? If not, I presume there's some reasonably simple way to attach a debugger to a process that's died. (I hope) No, I'm not getting turned into a windows programmer, but until I get the Gameboy port of parrot going (or someone slides me an Alpha or Itanium VMS box) it's the only non-Unix platform I've got handy to work with. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More Windows dev questions: Core dumps
From: Dan Sugalski [EMAIL PROTECTED] On a Unix system, a core dump is a file with a raw (mostly) copy of a process' current memory image that's written whenever a process does something profoundly illegal, like accessing an inaccessible section of memory with no trap handler that allows recovery or something of the sort. They're handy, because it means you can go and debug a process after the fact, and don't have to be there on the spot to figure out what's going on. Really handy for things that die overnight, or when you're not around, and you don't want the defunct process hanging around until you can attach to it with a debugger. Does Windows do this? (I know other OSes, like VMS, do *not* do it) No, Windows does not use core files. If you run your code outside of a debugger and a problem occurs you will be given the option of either debugging the code or killing the executing process. If so, how do I enable it? If not, I presume there's some reasonably simple way to attach a debugger to a process that's died. (I hope) Yeah. That's it. A debugger. Do you have one? If no, try to pull WinDbg about. http://www.microsoft.com/whdc/ddk/debugging/default.mspx?gssnb=1 It's free for downloading. You will find some HOW TO there either. No, I'm not getting turned into a windows programmer, but until I get It's a pity that you ain't =) Dan 0x4C56
Re: More Windows dev questions: Core dumps
At 11:51 PM +0300 12/31/03, Vladimir Lipsky wrote: From: Dan Sugalski [EMAIL PROTECTED] On a Unix system, a core dump is a file with a raw (mostly) copy of a process' current memory image that's written whenever a process does something profoundly illegal, like accessing an inaccessible section of memory with no trap handler that allows recovery or something of the sort. They're handy, because it means you can go and debug a process after the fact, and don't have to be there on the spot to figure out what's going on. Really handy for things that die overnight, or when you're not around, and you don't want the defunct process hanging around until you can attach to it with a debugger. Does Windows do this? (I know other OSes, like VMS, do *not* do it) No, Windows does not use core files. If you run your code outside of a debugger and a problem occurs you will be given the option of either debugging the code or killing the executing process. Bummer. Ah, well, one of the few Unix development things that I really like. If so, how do I enable it? If not, I presume there's some reasonably simple way to attach a debugger to a process that's died. (I hope) Yeah. That's it. A debugger. Do you have one? If no, try to pull WinDbg about. http://www.microsoft.com/whdc/ddk/debugging/default.mspx?gssnb=1 It's free for downloading. You will find some HOW TO there either. I've probably got that installed already with the VS/.NET kit, but if not I'll go get it. Thanks. No, I'm not getting turned into a windows programmer, but until I get It's a pity that you ain't =) I've too many systems stuck in my brain as it is--between VMS, various Unices, OS X userland, RSTS/E, remnants of the much lamented Amiga, and bits of the Gameboy Advance, there's not much space left. It's a wonder I can find my car keys in the morning. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More Windows dev questions: Core dumps
0x4C56 - Original Message - From: Dan Sugalski [EMAIL PROTECTED] To: Vladimir Lipsky [EMAIL PROTECTED] Cc: perl6-internals [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 10:49 PM Subject: Re: More Windows dev questions: Core dumps At 11:51 PM +0300 12/31/03, Vladimir Lipsky wrote: From: Dan Sugalski [EMAIL PROTECTED] On a Unix system, a core dump is a file with a raw (mostly) copy of a process' current memory image that's written whenever a process does something profoundly illegal, like accessing an inaccessible section of memory with no trap handler that allows recovery or something of the sort. They're handy, because it means you can go and debug a process after the fact, and don't have to be there on the spot to figure out what's going on. Really handy for things that die overnight, or when you're not around, and you don't want the defunct process hanging around until you can attach to it with a debugger. Does Windows do this? (I know other OSes, like VMS, do *not* do it) No, Windows does not use core files. If you run your code outside of a debugger and a problem occurs you will be given the option of either debugging the code or killing the executing process. Bummer. Ah, well, one of the few Unix development things that I really like. Well, debug prompts not that bad. Still better than nothing. If so, how do I enable it? If not, I presume there's some reasonably simple way to attach a debugger to a process that's died. (I hope) Yeah. That's it. A debugger. Do you have one? If no, try to pull WinDbg about. http://www.microsoft.com/whdc/ddk/debugging/default.mspx?gssnb=1 It's free for downloading. You will find some HOW TO there either. I've probably got that installed already with the VS/.NET kit, but if Oh! Then you might have got it. I read somewhere that one can do a crash dump, an windows equivalent of unix core dumpes, with windbg. So if you wish, you could look for how to create that thing in docs. Dan 0x4C56
Object system
Since I'm working on a compiler that requires objects, and seeing as how we have a python compiler now hanging over our heads, what work is necessary to finish up the object system? I notice that ParrotObject only has [get|set]_integer_keyed. I assume we intend to make those for the rest of the data types. Also, in order to support anonymous classes, I'd like the method table to be in the class object itself, as opposed to in mangled globals. Is this also something I could tackle? What else could I do? Thanks, Luke
