Re: Regarding status of Parrot and pure perl Perl6 compiler
On 6 Apr 2005, at 13:50, Nicholas Clark wrote: The roadmap starts with an introduction to Ponie, gives instructions on how to check it out of CVS and build it, and other useful information, so I'll avoid duplicating its contents here. Ponie is using released versions of Perl 5.9.x, rather than tracking the day to day core perl development. As Rafael released 5.9.2 last week, on Monday I updated Ponie's source to 5.9.2. Given that Ponie has made quite a lot of changes to odd parts of the Perl source, and there has been a lot of core Perl development since 5.9.1, this upgrade was never going to be trivial. In the end it took a the whole day of hard work, but it seems to be working now. [You are in a twisty maze of CVS conflicts, all alike. :-( Banging my head trying to work out why ExtUtils::MakeMaker is ignoring miniperl. etc] Nicholas Clark I see a need for subversion/svk to help with this :-) Cheers Arthur - CTO @ Fotango Ltd +447834716919 http://www.fotango.com/
Re: Functions for embedders to override
On 11 Aug 2004, at 06:10, Dan Sugalski wrote: * Networking: socket, accept, connect, listen, etc. (see Files) Yeah, and this'll be ever so much fun too. We need to add in select and poll to that list. Modern operating systems all have a way to get around the suckiness of poll/select when you have large number of fds (epoll/aio/kqueue/whatever), there should be away to override those interfaces as well :-) (maniac laugh) Arthur - Infrastructure Manager @ Fotango Ltd +447834716919 http://www.fotango.com/
Re: ponie roadmap
On 18 May 2004, at 08:10, Leopold Toetsch wrote: I don't think that this is the best idea. You are later stopping refcounting anyway. But I can imagine that you might present an SV with a refcount to (GC-unaware, unmodified) XS code. It is not the best idea, but it is a temporary solution to the problem ;), we need somewhere to store the flags for the time being and we want to get rid of the SV head. And yes, I see a refcount happening outside the core and internally we use the parrot GC. Cheers Arthur
Re: Outstanding parrot issues?
On 3 May 2004, at 09:11, Leopold Toetsch wrote:
Arthur Bergman wrote:
On 2 May 2004, at 12:37, Leopold Toetsch wrote:
Can't you call that somewhere in an outer frame? E.g. where you
create
the interpreter.
No, because I might be creating the interpreter in a callback from
the application, and then access that interpreter in ANOTHER callback
from the application.
Your are speaking of a usage like perldoc perlembed here, I presume.
For old code that is totally unaware that its running on Parrot,
you'll have to anchor (dod_register) returned PMCs. dodregister()
works like REFCNT_inc(), i.e. you can register a PMC multiple times.
unregister is like REFCNT_dec(), except there is no immediate
destruction if the register count reaches zero.
Such an embeded usage might also need a flag for entering the run
loop, so that the stack top is always set at the run loop stack frame.
Arthur
leo
IGNORE PERL5 IGNORE PERLEMBED, IGNORE ANY FUCKING REFERENCE TO PERL5,
ALSO USE THE EMBEDDING API NAMES NOT THE INTERNAL ONES
Let us say I want to embed parrot in application x, application x is
binary only and has an plugin API, this has three callbacks
app_x_init_plugin
app_x_run_plugin
app_x_destroy_plugin
When the app loads the plugin, it calls app_x_init_plugin, in this
routine I load parrot using Parrot_init(Parrot_Interp); I return from
my init function and the program continues to run, ANY STACK AUTO
VARIABLE CAPTURED IN THIS FRAME IS FROM NOW ON USELESS
Then when it runs and wants to use me it calls app_x_run_plugin, in
here I set up some PMCs,underlinedboldREGISTER
THEM/bold/underlined using Parrot_register_pmc, then call into
parrot using for example void Parrot_runcode(Parrot_Interp, int argc,
char *argv[]); Now my argument is that currently this does not work
because the stacktop is not set! so what Parrot_runcode should do is in
{
if(!parrot-stacktop) {
set_stacktop
}
Perl_runcode_real(...)
}
So for the embedder it is transparent if the stacktop is set or not.
Arthur
Re: Outstanding parrot issues?
On 3 May 2004, at 13:27, Leopold Toetsch wrote:
because the stacktop is not set! so what Parrot_runcode should do is
in
{
if(!parrot-stacktop) {
set_stacktop
When you call Capp_x_run_plugin from different locations, this
wouldn't work. So the correct sequence is:
app_x_run_plugin(...) {
void stk;
Parrot_init_stacktop(interp, stk);
Parrot_call(interp, the_sub, ...);
}
Arthur
Not if you clear the stacktop if you set it in Parrot_call, I thought
this was obvious so I left it out, but here we go.
parrot_call {
if(stacktop) {
parrot_call_real
} else {
set_stacktop
parrot_call_real
unset_stacktop
}
}
Re: Outstanding parrot issues?
On 2 May 2004, at 10:54, Leopold Toetsch wrote:
Arthur Bergman [EMAIL PROTECTED] wrote:
... The obvious answer
seems to be to have the embedding interface set the top of stack in
each embedding function if it is not set. This would do the right
thing
and make it easy to embed parrot.
No. I've posted already this example:
{
PMC *some = pmc_new(...);
{
PMC *another = pmc_new(...);
}
// some may be dead here
}
The braces denote stack frames.
No you have not, you have pasted something that has no relevance what
so ever to what I am saying unless you give it some more verbosity.
Yes, I know this is the case which is why I have to do
{
a = pmc_new
register_pmc(a)
{
b = pmc_new
register_pmc(b)
}
a should still be alive here
}
By leaving out the needed function you do not convey any response to my
proposal that parrot embedding functions that detect that no stacktop
to be set to set them before calling onwards into parrot. Yes, if no
stacktop is set in my code I need to carefully use regster_pmc, but I
know that already and it is something I agree to do.
Arthur
Re: Outstanding parrot issues?
On 2 May 2004, at 11:47, Leopold Toetsch wrote: All I want to do is. 1) create a parrot interpreter 2) create some pmcs 3) call some code inside parrot with those pmcs I've now added a missing init function that sets the stack top: Parrot_init_stacktop(Interp*, void*); This function can be used as a replacement for Parrot_init(). I hope that simplifies step 1) No, it entirely misses the point, every time I call into parrot the place I called parrot_init_stacktop might not, or most likely will not be in my current stack. Is the stacktop per interpreter? What then would be needed is a set_stacktop(Interp*, void*) function. Arthur
Re: Outstanding parrot issues?
On 2 May 2004, at 12:37, Leopold Toetsch wrote: that simplifies step 1) No, it entirely misses the point, every time I call into parrot the place I called parrot_init_stacktop might not, or most likely will not be in my current stack. Can't you call that somewhere in an outer frame? E.g. where you create the interpreter. No, because I might be creating the interpreter in a callback from the application, and then access that interpreter in ANOTHER callback from the application. Arthur
Re: Outstanding parrot issues?
On 30 Apr 2004, at 12:54, Leopold Toetsch wrote:
... Would it be possible for parrot to
provide an embedder's interface to all the (exported) functions that
checks whether the stack top pointer is set, and if not (ie NULL) it
pulls the address of a local variable in it
This doesn't work:
{
PMC *x = pmc_new(..);
{
some_parrot_func();
}
}
Cx would be outside of the visible range of stack items. The braces
do
of course indicate stack frames.
Since in this case I am outside or parrot and have chosen to use the
interface, i better use register_pmc and if I did, then this sceme
would work?
Arthur
Re: Outstanding parrot issues?
On 30 Apr 2004, at 19:30, Leopold Toetsch wrote: Like it or not DOD/GC has different impacts on the embedder. Above rules are simple. There is no when the PMC isn't used any more decrement a refcount and when you do that and that then icnrement a refcount or some such like in XS. This is really simple. Simplest is to just set the top of stack. I am now going to be impolite. THERE ARE CASES WHERE YOU CAN NOT SET A TOP OF STACK, FOR EXAMPLE IF YOU ARE WRITING A PLUGIN TO A BINARY ONLY APPLICATION LIKE INTERNET EXPLORER OR WRITING AN APACHE2 SHARED LIBRARY THAT IS SUPPOSED TO WORK WITH PRE COMPILED BINARIES, NOT TO MENTION A LOT OF APPLICATIONS THAT MIGHT WANT TO EMBED PARROT AS AN OPTION MIGHT FEEL IT IS A TAD FUCKING UNCLEAN TO RUN THEIR ENTIRE APPLICATION THROUGH PARROT (THINK OPENOFFICE) I am amazed by the fact that parrot seems determined to redo the same misstakes perl5 did. Arthur
Re: Outstanding parrot issues?
On 2 May 2004, at 00:20, Leopold Toetsch wrote: Arthur Bergman [EMAIL PROTECTED] wrote: THERE ARE CASES Arthur, please let's quietly talk about possible issues. Many libraries that you want to use, demand that you call The_lib_init(bla). This isn't inappropriate, it's a rule. (dot). Parrot is GC based. (dot). Yes, but they don't demand that at the top level, by demanding that at a top level you cut out all non opensource applications with a plugin based API, if this is your goal then I am going to stop playing right now. This imposes different semantics for embedders. I've listed four different very simple ways to not get your PMC collected to early. GC and refcounting are different schemes to achieve the same thing. You know that. But nethertheless you have to follow these GC specific rules. Leo, I am not an idiot, please do not treat me like one. I fail to see how the register/unregister PMC issue is semantically different from a reference count. All I want to do is. 1) create a parrot interpreter 2) create some pmcs 3) call some code inside parrot with those pmcs Now I am fine registering those PMCs that I create and unregister them afterwards, but inside the call to parrot everything should behave as normal! Currently there is no easy way to do this. The obvious answer seems to be to have the embedding interface set the top of stack in each embedding function if it is not set. This would do the right thing and make it easy to embed parrot. Arthur
Re: Parrot hijacks SIGINT
On 16 Mar 2004, at 06:36, Leopold Toetsch wrote: This is a snipped from the stress example program I posted some days ago with an additional check if events are to be handled. Both functions might not be in the extension interface[1]. Would it be possible to have a global variable that indicates if I have to poll for events, calling a function in-between every perl opcode is going to be very slow. Signals are converted to Parrot events and in the case of a program termination signal get broadcasted to all running interpreters. [1] BTW: Why does Ponie use the rather limited extension interface? Because Dan said so, and because doing an include parrot.h in perl leads to one million or so cpp and gcc errors. Arthur
Re: Parrot hijacks SIGINT
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Dan Sugalski) wrote: At 12:25 PM + 3/12/04, Arthur Bergman wrote: Hi, Tracking down test failures in ponie I noticed some tests using SIGINT failing, they don't fail when I change the tests using SIGUSR1, making me think that parrot somehow hijacks SIGINT but not other signals. Is this per design or is it something that should be fixed? It'll ultimately be by design--parrot'll end up snagging all the signals. We need to put together some sort of scheme for it, though, since that's untenable in an embedding environment. -- So, we need a design that works for embedded environments where parrot cannot grab signals. A way for the embedding app to raise signals in parrot using the embed.api? Arthur
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
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
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: Parrot hijacks SIGINT
On 15 Mar 2004, at 17:25, Jeff Clites wrote: We shouldn't, I would think, be snagging any signals unless user code expresses an interest in the signal. The default disposition of every signal is either to be ignored, or to abruptly terminate the process, and we preserve that behavior if we just do nothing, unless someone does the parrot analog of registering a signal handler. That works equally well in embedded and non-embedded environments. Jeff No it doesn't, because an embedding environment might not want to let parrot deal with signals, ever, and it might feel to restrict when it sends them off. Signals are an environment issue and thus should be controlled from the host app. Arthur
Parrot hijacks SIGINT
Hi, Tracking down test failures in ponie I noticed some tests using SIGINT failing, they don't fail when I change the tests using SIGUSR1, making me think that parrot somehow hijacks SIGINT but not other signals. Is this per design or is it something that should be fixed? Arthur
Re: ponie unwell without --gc=libc
On 12 Mar 2004, at 19:26, Leopold Toetsch wrote: Nicholas Clark [EMAIL PROTECTED] wrote: On Thu, Mar 11, 2004 at 10:33:24PM +0100, Leopold Toetsch wrote: All PMCs are anchored properly? Yes. Arthur and I got it down to the appended test case, which is pure C embedding and extending parrot. I already had mailed earlier with Arthur about that very problem. Parrot needs a stack_limit (interprer-lo_var_ptr) for stack tracing. This includes tracing processor registers which are placed on the stach in trace_system_areas(). When this stack limit isn't set, stack walking can not be done and all PMCs in hardware CPU registers and on the stack are missed, which normally leads to ugly DOD bugs - they are really hard to trace down. I think this idea is flawed when it comes to embedding and extending. Parrot should never walk the stack outside of itself (the embedding applications stack should be off limit). Also note that in this example, there never are any dead objects to find. So you have two possibilities to set the stack limit: interpreter-lo_var_ptr = interpreter; // a local in the outermost // stack frame I can't do this from embedding space since the internals of interpreter are not known. or better, you run all your code through the wrapper: - Parrot_run_native() which enters a run loop after doing normal initialization (which includes setting up a Parrot_exception which is used for exception handling. The ops that get run are enternative yourcode ; end; I am sorry, but all I can say is yuck, you can't expect embedders to have to wrap their main in Parrot. Below is a working revision of your code. (I know, that extend.c is missing some bits but that shouldn't be the problem, we have just to add it) leo /* Needed to turn off GC */ #if 1 #include parrot/parrot.h #endif This is the luxury I cannot do :( In fact, as an embedder, I cannot be sure I always have a local variable on a stack frame available to me, so I will end up having to set lo_var_ptr every time I call into the parrot API, hence I suggest this setting should be in extend.c and embed.c Arthur
CPAN Upload: A/AB/ABERGMAN/ponie-2.tar.gz - Ponie Development Release 2
This is Ponie, development release 2 And, isn't sanity really just a one-trick ponie anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit. -- the tick Welcome to this second development release of ponie, the mix of perl5 and parrot. Ponie embeds a parrot interpreter inside perl5 and hands off tasks to it, the goal of the project is to hand of all data and bytecode handling to parrot. With this release all internal macros that poke at perl data types are converted to be real C functions and to check if they are dealing with traditional perl data types or PMC (Parrot data types) data. Perl lvalues, arrays and hashes are also hidden inside PMCs but still access their core data using traditional macros. The goal and purpose of this release is to make sure this approach keeps on working with the XS modules available on CPAN and to let people test with their own source code. No changes where made to any of the core XS modules. This is based on perl 5.9.1 as it existed in September, when 5.9.1 is really released ponie will be updated to that version, this might lead to there being perl bugs in ponie that are fixed in later versions on ponie. If you embed perl, nothing should have changed but parrot takes control over a substantial part of the interface to the operating system, this might cause problems for you. (One example is that parrot seems to hijack SIGINT currently, and weird issues with STDERR). --- Enjoy Arthur
Re: status update
On 3 Mar 2004, at 08:09, Leopold Toetsch wrote: follow the scheme used in t/src/basic_3, i.e. run your code via Parrot_run_native(). Tried this, I think the interface to Parrot_run_native() is wrong, it should most likely be void* Parrot_run_native(Parrot, func, void*) ; so you can pass in arguments and return them Cheers Arthur
Re: status update
On 3 Mar 2004, at 08:09, Leopold Toetsch wrote: I wasn't aware that the Parrot DOD/GC would run even if I wasn't running any parrot bytecode, so when we started executing larger amounts of perl code, things got ugly because parrot was GCing from under our feet! Do you initialize interpreter-lo_var_ptr? If you aren't entering any runloop and this pointer isn't set, you will still have DOD bugs, because the processor stack will not be marked properly. You can set this pointer to the address of an automatic variable in main (or wherever you construct Parrot_Interp) or follow the scheme used in t/src/basic_3, i.e. run your code via Parrot_run_native(). Cheers Arthur leo All I do is PL_Parrot = Parrot_new(0) Parrot_init(PL_Parrot) Are you saying I have to initialize PL_Parrot- lo_var_ptr ? I cannot actually do that using the current extending API :/ Arthur
Parrot_PMC_new vs Parrot_register_pmc
Hi, Just a quick check, why is Parrot_register_pmc not named as the other Parrot_PMC_* functions in the external interface? Cheers Arthur
Valgrind shouting
Hi, So I am currently trying to find another segfault, valgrind is helping me but the only thing it really says is ==24093== Conditional jump or move depends on uninitialised value(s) ==24093==at 0x8273227: compact_pool (src/resources.c:301) ==24093==by 0x827300C: mem_allocate (src/resources.c:149) ==24093==by 0x82736C6: Parrot_reallocate (src/resources.c:500) ==24093==by 0x8182513: expand_hash (src/hash.c:509) ==24093==by 0x81826C5: new_bucket (src/hash.c:587) ==24093==by 0x8182B66: hash_put (src/hash.c:891) ==24093==by 0x81816B3: dod_register_pmc (src/pmc.c:1009) ==24093==by 0x81C0973: Parrot_register_pmc (src/extend.c:791) ==24093==by 0x80DA233: S_new_xpvav (sv.c:1084) ==24093==by 0x80DB0AE: Perl_sv_upgrade (sv.c:1568) ==24093== and a couple of statements later on this, in something that shouldn't be able to segfault ==24093== Invalid write of size 4 ==24093==at 0x80DB162: Perl_sv_upgrade (sv.c:1577) ==24093==by 0x80C8E0D: Perl_newAV (av.c:386) ==24093==by 0x809976E: Perl_pad_push (pad.c:1525) ==24093==by 0x80D76D8: Perl_pp_entersub (pp_hot.c:2640) ==24093==by 0x80AF5C2: Perl_runops_debug (dump.c:1439) ==24093==by 0x8064E15: S_run_body (perl.c:1713) ==24093==by 0x806481A: perl_run (perl.c:1632) ==24093==by 0x804C720: main (miniperlmain.c:86) ==24093== Address 0x18 is not stack'd, malloc'd or free'd So, it is increasing the registered hash, doing something weird, and then promptly corrupting memory, or am I just guessing wrong here? Cheers Arthur
Valgrind and parrot
Using valgrind 1.9.6 I find it impossible to use with parrot, is this a known issue, should I try and get someone to upgrade valgrind for me? The following impossible happens. switch% valgrind --num-callers=100 ./parrot examples/assembly/mops.pasm ==23809== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==23809== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==23809== Using valgrind-1.9.6, a program instrumentation system for x86-linux. ==23809== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==23809== Estimated CPU clock rate is 2846 MHz ==23809== For more details, rerun with: -v ==23809== vg_malloc_aligned(0x401C9020, 524288, 524288) bad alignment request valgrind: the `impossible' happened: vg_malloc_aligned Basic block ctr is approximately 0 sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==23809==at 0x401672B0: memalign (vg_clientfuncs.c:299) ==23809==by 0x808B9B7: Parrot_memalign (src/platform.c:221) ==23809==by 0x80C1DCE: alloc_objects (src/smallobject.c:386) ==23809==by 0x80C1B7E: get_free_object (src/smallobject.c:217) ==23809==by 0x80C200F: get_free_buffer (src/headers.c:87) ==23809==by 0x80C23DD: new_string_header (src/headers.c:330) ==23809==by 0x8085309: string_make (src/string.c:367) ==23809==by 0x81A3BFD: Parrot_Array_class_init (array.c:929) ==23809==by 0x81A126A: Parrot_initialize_core_pmcs (src/core_pmcs.c:65) ==23809==by 0x819D903: init_world (src/global_setup.c:76) ==23809==by 0x80BADE9: Parrot_init (src/embed.c:67) ==23809==by 0x807F472: make_interpreter (src/interpreter.c:1587) ==23809==by 0x80BADB6: Parrot_new (src/embed.c:41) ==23809==by 0x807D0D7: main (imcc/main.c:403) ==23809==by 0x42017588: __libc_start_main (in /lib/i686/libc-2.2.5.so) ==23809==by 0x807C490: (within /home/abergman/Dev/ponie/parrot/parrot) Cheers Arthur
References to hash elements?
Hi,
I am wondering how the references to hash elements are planned to be
done? The call to set_ must somehow be delayed until the time is right.
$foo = \$hash{key};
$$foo = bar;
$has{key} is now bar
I don't see how the current vtable setup will allow for this in a tied
situation, or will a tied hash just return a hashelement pmc type that
will do the call later on?
On another note, is there going to be a PMC flag for tainted data?
Arthur
ps, please respond to both ponie-dev and perl6-internals
Re: References to hash elements?
On 6 Jan 2004, at 17:05, Simon Cozens wrote: I would have thought that a hash element would itself be a PMC rather than an immediate value, so a reference to that should be treated just like any other reference to a PMC. But this does not hold true if the hash element is in fact conjured up by a call to STORE Arthur
Re: Segfault in extend.c/ parrot_pmc_get_pointer
On Monday, December 15, 2003, at 12:58 pm, Leopold Toetsch wrote:
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
So, after a couple of days struggling to find a lost off64_t I am able
to try again, (plus side is, I now build a threaded perl to make it
work (otherwise nasty IO problems hit me)).
So the result.
Most likely,
(gdb) p *pmc
$2 = {obj = {u = {b = {bufstart = 0x4212dfd8, buflen = 137797904}, ptrs
= {_struct_val = 0x4212dfd8, _pmc_val = 0x836a110},
int_val = 1108533208, num_val = 4.2834352799906154e-269,
string_val = 0x4212dfd8}, flags = 1886221358, pobj_version = 0}, vtable
= 0x18,
pmc_ext = 0x10}
Of course followed by a
(gdb) p *pmc-vtable
Cannot access memory at address 0x18
If it wasn't for pobj_version = 0 I would suggest it was all just
random memory I was looking at.
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.
I doubt this happens since I never give parrot a chance to do anything,
there is no step that I call into parrot, just
PL_Parrot = Parrot_new(0);
Parrot_init(PL_Parrot);
then a bit later
Parrot_Int type = Parrot_PMC_typenum(PL_Parrot, Perl5LV);
Parrot_PMC_get_pointer(PL_Parrot, SvANY(sv));
Arthur
-lpthread
After updating and building I notice... make[1]: Entering directory `/home/abergman/Dev/ponie/perl' cc -L/home/abergman/Dev/ponie/parrot/blib/lib -o miniperl \ miniperlmain.o opmini.o libperl.a -lnsl -ldl -lm -lcrypt -lutil -lc -lparrot /home/abergman/Dev/ponie/parrot/blib/lib/libparrot.a(events.o): In function `init_events_first': /home/abergman/Dev/ponie/parrot/src/events.c:83: undefined reference to `pthread_create' /home/abergman/Dev/ponie/parrot/blib/lib/libparrot.a(tsq.o): In function `queue_timedwait': /home/abergman/Dev/ponie/parrot/src/tsq.c:164: undefined reference to `pthread_cond_timedwait' collect2: ld returned 1 exit status Am I right to assume that I always need to build a threaded perl if I want to link against parrot? Arthur
Re: -lpthread
On Wednesday, December 17, 2003, at 11:35 am, H.Merijn Brand wrote: Unacceptable IMHO. Many people getting prebuild binaries on commercial OS's have no choice I don't see how this is relevant, prebuilt perl or prebuilt parrot? I don't think we need to worry about prebuilt parrot, and ponie will need to be built anyway. However, I would still like a flag that doesn't make it link against libpthread. Arthur
Re: -lpthread
On Wednesday, December 17, 2003, at 12:38 pm, Leopold Toetsch wrote: $ grep thr_pthread config/gen/platform/*.h config/gen/platform/darwin.h:# include parrot/thr_pthread.h config/gen/platform/generic.h:# include parrot/thr_pthread.h config/gen/platform/openbsd.h:# include parrot/thr_pthread.h However, I am building this on Linux switch.work.fotango.com 2.4.23-rc5 #3 SMP Wed Nov 26 10:05:52 GMT 2003 i686 unknown And I still get unknown references to lipthread, meaning I need link to it, meaning I need to build my perl threaded. Arthur
Re: -lpthread
On Wednesday, December 17, 2003, at 02:06 pm, Dan Sugalski wrote: Well... yes and no. You need to make sure Parrot links against the thread libraries. You don't, strictly speaking, need to have perl linked against the threading libraries except... several (perhaps most) platforms *really* hate it when you dlopen (or its equivalent) the thread libraries and *haven't* linked your main executable against them. Tends to crash or lock up your process, which kind of sucks. If you have it such that parrot is linked directly into the main perl executable so that it's loaded as part of the process startup, then you don't need to link in the thread libraries to perl. If you're loading parrot as a perl extension, then you will. (It isn't necessary to build a threaded perl for this, FWIW, you just need to make sure perl loads in the thread library) -- Dan Yes, but making sure perl loads the thread library is pretty much the same as saying that perl needs be threaded :). I don't really like that you cannot build parrot without linking in pthread. Arthur
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
#define version obj.version is a kind of generic thing
Hi, Upgraded parrot today and ran into some snags with in my own perl5lv.pmc that includes perl.h The error was /Users/sky/Documents/Projects/ponie/perl/proto.h:778: parse error before '.' token That line is PERL_CALLCONV void Perl_utilize(pTHX_ int aver, I32 floor, OP* version, OP* idop, OP* arg); Which convienently gets converted to void Perl_utilize ( int aver , I32 floor , OP * obj . version , OP * idop , OP * arg ) ; because of include/parrot/pobj.h:# define version obj.version So I am wondering about the status of how to write my own pmc, should it not include parrot/parrot.h ? If it should, perhaps it would be good if all parrot things are prefixed as suck, at least when they have very generic meanings? Arthur
Re: #define version obj.version is a kind of generic thing
On Monday, October 27, 2003, at 02:10 pm, Leopold Toetsch wrote: Arthur Bergman [EMAIL PROTECTED] wrote: include/parrot/pobj.h:# define version obj.version Sorry for that :) We can AFAIK toss the version part of a PObj. Its almost unused and hardly needed. It could be renamed too inside parrot. It should be out of the way, if you #define DISABLE_GC_DEBUG 1 before including parrot.h For the time being I just did #define version version :) Arthur
Using extend.h to create a specific PMC
Hi, Quick question, is it possible to create a specific type of PMC using extend.h? Arthur
Storing external data in PMCs
Hi, So I am currently trying to do a Perl5LVALUE pmc, a stumbling block is however that I need to pass the PMC the thing that it is lvalueling, I was planning to use the pmc data field for storing this but I cannot access it as a extender without violating the API and guessing at layouts which is kind of bad (Dan says so ;) Arthur
Re: Storing external data in PMCs
On Monday, October 27, 2003, at 03:26 pm, Melvin Smith wrote: At 02:56 PM 10/27/2003 +, Arthur Bergman wrote: So I am currently trying to do a Perl5LVALUE pmc, a stumbling block is however that I need to pass the PMC the thing that it is lvalueling, I was planning to use the pmc data field for storing this but I cannot access it as a extender without violating the API and guessing at layouts which is kind of bad (Dan says so ;) I don't know Perl5 internals enough to know exactly what Perl5LVALUE does. Do you want a way to pass a value to the PMC and let the PMC type morph itself based on the data representation? -Melvin An lvalue holds usually a function, and when set is called that function is called. So no morthing required at all! For example: perl -le '$foo = hi; $bar = \substr($foo,1); print $bar-$foo; $$bar = b; print $bar-$foo'; LVALUE(0x513ec)-hi LVALUE(0x513ec)-hb so the reference points to a lvalue which has a reference to $bar and a special function on the set to actually execute the substr. The reason I am starting with this is that it is so obscure that it is hardly used anywhere and is limited to a few small areas in the core making it a good testing ground. Arthur
Re: Storing external data in PMCs
On Monday, October 27, 2003, at 04:44 pm, Melvin Smith wrote: In this case I assume the function can either be Perl5 or Parrot? Sounds like a custom PMC to me. Given the PMC that could stash function pointers and correctly dispatch gets/sets you have the option of writing a PNI method for setting the stashed routine from C or we have to add a call to the extension API to stash a raw pointer. -Melvin The function is a C function. And yes it is a custom PMC which I have already created. Dan pointed out the unmanagedstruct.pmc which but I fail to see how that would help me, I think we need an external API for stashing raw pointers. (I don't know what PNI is, but I assume it is to execute bytecode from C and I do not want to do that). Arthur
Re: Storing external data in PMCs
On Monday, October 27, 2003, at 05:20 pm, Melvin Smith wrote: Apologies for the formatting of these replies, I'm at work with Lotus Notes. PNI (Parrot Native Interface) is for writing native extensions in C. So, what I meant is you can write a method for stashing a raw pointer with the API today (probably using char *). I'm not sure if it is your preferred method, and I understand your wariness of bytecode in this case. I was 1/2 asleep this morning on IRC when I suggested it, not understanding the case you were dealing with. You can see samples that Dan has played with such as ncurses somewhere in the examples area. (I'm still not saying you don't need API added to extend.h though, but I'd have to be very clear on what you are asking for...) -Melvin I just want to be able to say Parrot_PMC_attach_data(Parrot, PMC, *void); so the PMC code can get to it Arthur
Re: [PATH] Get rid of very annoying header warnings on darwin
On Thursday, September 11, 2003, at 07:50 pm, Brent Dax wrote: Arthur Bergman: # This gets rid of the very annoying long double might change warning # under Darwin... Thanks, applied (config/init/hints/darwin.pl version 1.7). However, can you see if the diff below my sig (applied against 1.7, not 1.6) works too? If so, it's probably a more appropriate place to put it. Nope, that doesn't work, cc_warn munges the input and only removes things from the command line, not adds new ones. so -Wno-shadow gets turned into remove -Wshadow Arthur
[PATH] Get rid of very annoying header warnings on darwin
Hi, This gets rid of the very annoying long double might change warning under darwin, the warning comes from my config.h which has typedef long double HUGEFLOATVAL; Arthur Index: config/init/hints/darwin.pl === RCS file: /cvs/public/parrot/config/init/hints/darwin.pl,v retrieving revision 1.6 diff -u -r1.6 darwin.pl --- config/init/hints/darwin.pl 7 Jun 2002 19:21:17 - 1.6 +++ config/init/hints/darwin.pl 11 Sep 2003 14:38:57 - @@ -1,6 +1,6 @@ my($ccflags, $ldflags)=Configure::Data-get(qw(ccflags ldflags)); -$ccflags .= -pipe -fno-common ; +$ccflags .= -pipe -fno-common -Wno-long-double ; $ccflags =~ s/-flat_namespace\s*//; $ldflags =~ s/-flat_namespace\s*//; $ldflags .= -flat_namespace ;
Re: [PATCH] Small test case exception for ponie
On Wednesday, September 10, 2003, at 05:55 pm, Leopold Toetsch wrote: From: Leopold Toetsch [EMAIL PROTECTED] Date: Wed Sep 10, 2003 5:55:59 pm Europe/London To: [EMAIL PROTECTED] (Arthur Bergman) Cc: [EMAIL PROTECTED] Subject: Re: [PATCH] Small test case exception for ponie Reply-To: [EMAIL PROTECTED] Arthur Bergman [EMAIL PROTECTED] wrote: Hi, I am adding an additional pmc (Perl5LV), however a test fails t/pmc/pmc...NOK 75# Failed test (t/pmc/pmc.t at line 1650) # got: 'Perl5LV PMCs have incorrect name # ' # expected: 'All names and ids ok. # ' t/pmc/pmc...ok 91/91# Looks like you failed 1 tests of 91. This is the builtin ponie protection ;-) These come to my mind: $ make realclean perl Configure.pl ... (We are still missing some dependencies) If that doesn't: A PMCs name() is coming from the name() vtable, which is handled in default.pmc. default.name() returns vtable-whoami. This is a STRING set up by pmc2c.pl. You can see these in $class.c files. Normally a class shouldn't handle the name() and type() vtables, the default implementation does it. If you have a base class, that has these functions then you must handle it in all your derived classes. Finally: $ perl classes/pmc2c.pl --tree classes/perl*.pmc should give you a class hierarchy tree. If that still isn't: then set a break point in Parrot_class_name, where the class is that one you see in Perl5LV.c:temp_base_vtable in the Cname slot. HTH leo Aha, that explains it, I assumed that genclass produced something that was correct, apparently it didn't :), fixed now and I withdraw my patch. (I just removed the name and id functions and inherit them instead) Arthur
Embedding interface to PMCs
Hi, Is there any documentation, or code I can read to figure out how use PMCs in embedded mode? I tried to just include parrot/parrot.h in sv.c but that results in a million (or so ;) errors, so using parrot/embed would be nice. (it looks like it isn't finished yet, so it is more a question of what plans exists?) Arthur
[PATCH] Build system command line options
Currently if you specify cc and ld flag options at the command line it
totally overrides the ones it finds, this seems non DWIM and non
optimal. This little patch fixes it.
Reason I need this is am moving in pmcs into classes that #include
perl.h and thus need patch/to/perl.h in -I
Arthur
--- config/inter/progs.pl 10 Jul 2003 06:54:06 - 1.11
+++ config/inter/progs.pl 10 Sep 2003 15:15:47 -
@@ -48,9 +48,9 @@
$cc=$args{cc} if defined $args{cc};
$link=$args{link} if defined $args{link};
$ld=$args{ld} if defined $args{ld};
- $ccflags=$args{ccflags} if defined $args{ccflags};
+ $ccflags.=$args{ccflags} if defined $args{ccflags};
$linkflags=$args{linkflags} if defined $args{linkflags};
- $ldflags=$args{ldflags} if defined $args{ldflags};
+ $ldflags.=$args{ldflags} if defined $args{ldflags};
$libs=$args{libs} if defined $args{libs};
$debug='y' if defined $args{debugging};
$cc_warn=$args{ccwarn} if defined $args{ccwarn};
[PATCH] Small test case exception for ponie
Hi,
I am adding an additional pmc (Perl5LV), however a test fails
t/pmc/pmc...NOK 75# Failed test (t/pmc/pmc.t at line 1650)
# got: 'Perl5LV PMCs have incorrect name
# '
# expected: 'All names and ids ok.
# '
t/pmc/pmc...ok 91/91# Looks like you failed 1 tests of 91.
t/pmc/pmc...dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 75
Failed 1/91 tests, 98.90% okay
so this patch just ignores Perl5 types, (if someone knows why the test
fails and how I can fix it, that would of course be even better :)
Arthur
diff -u -r1.59 pmc.t
--- t/pmc/pmc.t 9 Sep 2003 10:25:43 - 1.59
+++ t/pmc/pmc.t 10 Sep 2003 15:48:58 -
@@ -1629,6 +1629,7 @@
while (my ($type, $id) = each %pmc_types) {
next if $type eq Iterator;
next if $type eq Ref;
+next if $type =~ /^Perl5/; #ignore the perl5 pmcs
my $set_ro = ($type =~ /^Const\w+/) ? EOPASM : '';
new P10, .PerlInt
inc P10
Re: [PATCH] Build system command line options
On Wednesday, September 10, 2003, at 05:40 pm, Brent Dax wrote:
Got something a bit better.
Parrot Configure has had syntax for modifying settings without removing
them for a long time:
:add{foo}
:rem{foo}
Until now, it only worked when Configure prompted you interactively for
the settings; I've now changed it (applied to
Parrot--config/inter/progs.pl 1.12, lib/Parrot/Configure/Step.pm 1.14)
so that it works on most of the settings progs.pl handles, including
all
the /..flags/ settings.
So to append to ccflags, you'd just do:
perl Configure.pl --ccflags=:add{stuff to append}
Will this suffice?
Most certainly.
Thanks
arthur
Abandoning Subversion
Hi, After a weeks vacation, returning back to work on Ponie I have frequent motivational problems because subversion is treating me so badly. (ie, I don't want to change something because it is such a pain then to commit it, I don't want to upgrade to latest parrot because it will take a whole work day, and so on). That together with questiones raised by several other developers I think it is time to abandon subversion and go to CVS. Since it then can live in cvs.perl.org/ponie I will not have to import parrot, just use the parrot/ directory during development. perl5 sources will have to be imported but that is not such a big deal. Robert, Ask, I am sorry it hasn't worked out with subversion, is it a lot of work involved in setting me up for cvs? Arthur
Parrot and STDOUT/STDERR
Hi, In my efforts to embed parrot into perl I stumbled upon something mildly interesting but most likely terribly hard to track down problem. If I execute a miniperl (but linked into parrot and with it's own parrot interpreter) it works, but if the caller closes(STDERR) before invoking miniperl no output is ever seen on STDOUT. This is terribly annoying since ExtUtils::MakeMaker does silly things like this, could there be some code in parrot that becomes really unhappy if STDERR is not open? Arthur
Re: ponie-dev list
On Thursday, July 10, 2003, at 08:47 am, Jerome Quelin wrote: May I ask why ponie doesn't use the p6i ml since as I see it, it's another project for parrot and thus will use $PARROT/languages/ponie (or perl5 or whatever)? Jérôme I think the same reason we don't do it on perl5-porters (because it is also a does touch a lot of the perl5 core), we don't want to force people to read one list or the other (I am not reading p6i for example), and to minimize cross posting between p5p and p6i. Arthur
SV: Parrot multithreading?
Arthur Bergman wrote: In an effort to rest my braine from a coredumping perl5 I started to think a bit on threading under parrot? While it has been decided that perl should be using ithread like threading, I guess that is irelevant at the parrot level. Are you going to have one virtual cpu per thread with it's own set of registers or are you going to context switch the virtual cpu? If it was one virtual cpu per thread then one would just create a new virtual cpu and feed it the bytecode stream? Is there anything I could help with regarding this? Arthur The context is almost identical to that of Perl5's MULTIPLICITY which passes the perl-interpreter to each op-code. Thus there is inherent support for multiple ithread-streams. In the main-loop (between each invoked op-code) there is an event-checker (or was in older versions at any rate). It doesn't do anything yet, but it would make sence to assume that this is where context-switches would occur, which would simply involve swapping out the current pointer to the perl-context; A trivial matter. Uhm, are you talking perl 5 here? The event checker checks for signals, we got safe signals now. MULTIPLICITY is just allowing multiple interpreters, ithreads is letting them run at the same time and properly clone them. If you want to use it switch interpreters at runtime for fake threads, patches are welcome, send it and I will apply it. The easiest threading model I can think of would be to have a global var called next_interpreter which is always loaded in the do-loop. An asynchronous timer (or event) could cause the value of next_interpreter to be swapped. This way no schedule function need be checked on each operation. The cost is that of an extra indirection once per op-code. True MT code simply has each thread use it's own local interpreter instance. MT-code is problematic with non MT-safe extensions (since you can't enforce that). I am sorry to say, but perl 5 is true MT. In iThread, you don't have a problem with atomic operations, but you can't take advantage of multiple CPUs nor can you garuntee prevention of IO-blocking (though you can get sneaky with UNIX-select). Where did you get this breaking info? ithread works with multiple CPUs and IO blocking is not a problem. Arthur
