IRIX64 6.2 cc -n32 issues 123 warnings (one per op code) complaining
that
"interpreter.c", line 219: warning(1048): cast between pointer-to-object and
pointer-to-function
BUILD_TABLE(foo);
^
This patch makes them go away.
- SWM
Index: build_interp_starter.pl
===
> Just out of interest, what are the tests looking like on IRIX?
mmm...not so good.
- SWM
world:~/src/Perl/parrot>uname -a
IRIX64 world 6.2 03131016 IP19
world:~/src/Perl/parrot>make test
perl t/harness
t/op/basic..ok 1/2skip() is UNIMPLEMENTED! at
/home/abhaile/swmcd/perl/lib/s
ite_perl/
> > -opcode_t *(*(*opcode_funcs)[2048])(); /* Opcode */
> > - /* function table */
> > -STRING_FUNCS *(*(*string_funcs)[64])(); /* String function table */
> > +opcode_t *(**opcode_funcs)(); /* Opcode function table */
> > +STRING_F
I checked out Parrot from CVS on 2002Aug30 to an IRIX64 system.
shell01:/usr/tmp/swmcd/parrot>uname -a
IRIX64 shell01 6.5 07201611 IP27
make compiled OK.
make test failed all the t/pmc/perlhash.t tests.
Running
parrot t/pmc/perlhash_1.pbc
produced a bus error.
I chased the err
> There is a fundemental issue on how values are passed between
> threads. Does the value leave one thread and enter the other or are
> they shared.
> The idea tossed around -internals was that a value that crosses a thread
> boundary would have a wrapper/proxy attached to handle the mediation.
> SWM> Question: Can the interpreter determine when a variable becomes
> SWM> shared?
> SWM> Answer: No. Then neglecting to put a :shared attribute on a shared
> SWM> variable will crash the interpreter. This doesn't seem very Perlish.
> Err, no. It won't crash the interpreter. It'll make the sc
What I'm trying to do in RFC178 is take the thread model that you get
in compiled languages like C and C++, and combine it with the Perl5
programming model in a way that makes sense.
There may be reasons not to follow RFC178 in Perl6. Maybe
- it's too hard to implement
- there are performance pr
> Single thingee access mediation, should be done automatically by perl.
> The multi-thingee complex mediation should have the user step in, since
> solving it (correctly and efficiently) is a complex problem.
I'm not sure we have a common understanding of the terms we are using.
Can you give som
I think we are talking about the same issues, but we can't seem to get
in sync on the terminology. I'm going to try to get off the
merry-go-round by recapitualting the two approaches.
RFC178
- globals are shared unless localized
- file-scoped lexicals are shared by all code in the file
- block-s
> DS> I'd definitely rather perl not do any sort of explicit user-level locking.
> DS> That's not our job, and there be dragons.
> Please explain how this is possible?
Just say no...to locks.
> Does this mean that without user specifying a lock, perl will allow
> a chaotic update pattern to b
> DS> Some things we can guarantee to be atomic.
> This is going to be tricky. A list of atomic guarentees by perl will be
> needed.
>From RFC 178
...we have to decide which operations are [atomic]. As a starting
point, we can take all the operators documented in C and
all the functions docume
> what if i do $i++ and overflow into the float (or bigint) domain? that
> is enough work that you would need to have a lock around the ++. so then
> all ++ would have implied locks and their baggage. i say no atomic ops
> in perl.
>From RFC 178
[Atomic] operations typically lock their opera
> I think there may be a necessity for more than just a work area to be
> non-shared. There has been no meaningful discussion so far related to
> the fact that the vast majority of perl6 modules will *NOT* be threaded,
> but that people will want to use them in threaded programs. That is a
> non
> > You aren't being clear here.
> >
> > fetch($a) fetch($a)
> > fetch($b) ...
> > add ...
> > store($a) store($a)
> >
> > Now all of the perl internals are done 'safely' but the result is garbage.
> >
> Example
>
> @a = ();
> async { push @a, (1, 2, 3) };
> push @a, (4, 5, 6);
> print @a;
>
> Possible output: 142536
Actually, I'm not sure I understand this.
Can someone show how to program push() on a stack machine?
- SWM
RFC 178 proposes a shared data model for Perl6 threads. In a shared
data model
- globals are shared unless localized
- file-scoped lexicals are shared unless the thread recompiles the
file
- block scoped lexicals may be shared by
- passing a reference to them
- closures
- declaring one s
> SWM> If you actually compile a Perl program, like
>
> SWM> $a = $b
>
> SWM> and then look at the op tree, you won't find the symbol "$b", or "b"
> SWM> anywhere in it. The fetch() op does not have the name of the variable
> SWM> $b; rather, it holds a pointer to the value for $b.
>
> W
17 matches
Mail list logo
