> autoconf automake libtool
Has anyone said 'Jam' on this thread yet? Jam is a platform-independent
make replacement, see http://www.perforce.com/jam/jam.html
--
Alan Burlison
--
$ head -1 /dev/bollocks
build high-visibility pervasive knowledge capital
ar\n");
prints out "FOO | BAR"
This is a really useful feature because it means that you don't need huge
lookup tables to convert from the numeric to the string version of a
constant - it is both at the same time.
--
Alan Burlison
--
$ head -1 /dev/bollocks
immutably engage omnipresent server-centric drivers
ring :-)
Oops - so you were. Soz!
--
Alan Burlison
--
$ head -1 /dev/bollocks
visioneer 24/365 niches
s...
Yes, all platforms that support LP64, i.e. virtually all 64-bit address
space platforms.
Sparc is just one example.
--
Alan Burlison
--
$ head -1 /dev/bollocks
refactor service-led meta-services, going forwards
in parrot?'
> It is also slow, and speed is priority #1.
As far as I'm aware, trading correctness for speed is not an option.
--
Alan Burlison
--
$ head -1 /dev/bollocks
effectively incubate innovative network infrastructures
d CV garbage collector.
--
Alan Burlison
--
$ head -1 /dev/bollocks
systematically coordinate e-business transactional integrity
ker, but that looks *very* suspect to me. Some compilers
may choose to reorder even without optimization turned on. I'd say that it
is a bug in Parrot if it requires optimization to be off for this code - how
many different compilers have you tried?
--
Alan Burlison
--
kes assumptions about execution order without using the necessary
mutexes/cvs to enforce these assumptions, it is very unlikely to work on
large SMP machines, for example.
--
Alan Burlison
--
nals during the queue operations, take out the
lock, do the work, drop the lock then reenable signals.
--
Alan Burlison
--
r to re-modify
| them just corrupts them.
|
| Now, if there is a lock that is acquired *only* while in a signal
| handler, then it is sufficient to block all signals while in the signal
| handler (and this can be accomplished with no additional overhead by
| doing sigfillset(&action.sa_mask) before using 'action' to set up
| the signal handler).
Hope that helps,
--
Alan Burlison
--
Dan Sugalski wrote:
The more I think about this the more I want to punt on the whole idea.
Cross-platform async IO is just one big swamp.
Agreed. Glug, glug, glug ;-)
--
Alan Burlison
--
to dry
deserts and make them safe for camel caravans. :)
I'll be at yapc::eu
--
Alan Burlison
--
;ve been down that path already - Topaz. With all due respect this is
supposed to be a community rewrite. Your proposal doesn't seem to be
along those lines.
Alan Burlison
be used to provide a working
> Perl5 -> Perl6 migration path.
I'm not saying it was. However I don't see how the proposal would aid
the migration - after all what he is writing will be neither perl5 nor
perl6.
Alan Burlison
t Pentium at least follows
> same pattern.
It does. However my understanding Pentium stops the pipeline if it has
to do a TLB walk, which it then does in hardware. This mitigates the
effect of the TLB miss somewhat.
Alan Burlison
n, as you intend doing it all
yourself.
> > I'm not saying it was. However I don't see how the proposal would aid
> > the migration - after all what he is writing will be neither perl5 nor
> > perl6.
>
> I am not "writing". I am "transforming&qu
odules
and shared objects/DLLs.
Alan Burlison
rable to the
currently used horrible hacks involving either LD_LIBRARY_PATH or
greping and patching the executable.
--
Alan Burlison
Graham Barr wrote:
> It is not just libraries, but also the perl @INC that needs to
> be dynamic
Yes, but that seems a bit more tractable - surely we could fiddle with
@INC based on the location of the perl interpreter?
--
Alan Burlison
Solaris Kernel Development, Sun Microsystems
John Tobey wrote:
> Both Windows and Linux can swing this, too. I believe linux (GNU
> Libc, to be precise) uses $ORIGIN in a Solaris-compatible way.
So I've just been told by our linker expert. Nice to have it confirmed
though.
--
Alan Burlison
more benefit than avoiding a few inline bit
twiddles.
I think a range of alternative implementation mechanisms needs to be
benchmarked very carefully on a range of architectures before making a
choice. The one thing that is certain about cache behaviour is that it
is very difficult to predict without actually trying stuff out.
Alan Burlison
ome bits of the core so that they don't
depend on anything else, but I'm far from persuaded the overall benefit
will be worth the extra complications.
Alan Burlison
piped in on stdin, it might mean a few milliseconds shaved off
> startup.
You already have this win:
# Force symbol resolution on startup
$ LD_BIND_NOW=1 ptime perl -e 'exit(0)'
real0.029
user0.021
sys 0.007
# Default lazy linking
$ ptime perl -e 'exit(0)'
real0.019
user0.010
sys 0.007
Alan Burlison
ow some bits
of a .so may not be shared, but most of it is). Paging involves disks,
and they are orders of magnitude slower than the dynamic linking
overhead. Repeat the excercise with a couple of hundred concurrent
copies of your test. Drawing conclusions based on a single test can be
misleading.
--
Alan Burlison
of joint, but
it is true. Doesn't it occur to people that if it was easy to add
automatic locking to a threaded language it would have been done long
ago? Although I've seen some pretty whacky Perl6 RFCs, I've yet to see
one that says 'Perl6 should be a major Computer Science research
project'.
--
Alan Burlison
be utterly useless. And, how on earth will you
identify sections that "only operate on internal data"?
--
Alan Burlison
This will however require that different threads
are allowed to have different optrees - perhaps some sort of 'copy on
write' semantic should be used so that optrees can be shared cheaply for
the cases where no changes are made to it.
Alan Burlison
ild a seperate optree for each module as
it is loaded, and for each thread/interpreter to hold a reference to the
ones that it uses. This way the optrees could remain readonly, but
still be shared if required and safe to do so. If no extant threads
refer to the optree, it could perhaps be freed - sort of
reference-counted optrees. I'm winging it a bit here becasue I don't
know if this is a good idea/vaguely possible/barking mad (choose one).
--
Alan Burlison
is a fools
errand. It is about as sensible as removing BLOCKS and getting perl to
guess where they should go.
--
Alan Burlison
ue :shared;
> push(@queue, $b);
Again, all of these would have to be OK in an interpreter that ensured
internal consistency. The trouble is if you want to update both $a, %h
and @queue in an atomic fashion - then the application programmer MUST
state his intent to the interpreter by providing explicit locking around
the 3 updates.
--
Alan Burlison
non-trivial problem that may best be solved by keeping the entirety of
such modules private to a single thread. In that case the optree might
also have to be private, and with that and private work area it looks
very much like a full interpreter to me.
--
Alan Burlison
please sumbit an RFC entitled "Why perl6 should
automatically fix all the broken programs out there and how I suggest it
should be done". Then you can sit back and wait for the phonecall from
Stockholm ;-)
--
Alan Burlison
controlled by the
> programmer.
Exactly. The intention behind the proposal to do auto-locking is
praiseworth - to make the programmers life easier. However, the
suggested solution is more akin to killing him with kindness.
--
Alan Burlison
nd to allow this, how
will you know when to stop chasing references? What happens if there
are circular references? How much time do you think it will take to
scan a 4Gb array to find out which elements need to be checkpointed?
Please consider carefully the potential consequences of your proposal
ddressed the issue of what
constitutes and atomic operation.
> I think we all would agree that an op is atomic. +, op=, push, delete
> exists, etc. Yes?
Sorry - no I don't agree. As I said, what about map or grep, or sort?
I have an alternative proposal - anything that can be the target of a
tie is atomic, i.e. for scalars, STORE, FETCH, and DESTROY etc.
--
Alan Burlison
he change could not have taken
> place without an exclusive lock on the variable.)
>
> Then the execution stack and program counter would be reset to the
> checkpoint. And then restarted.
Sigh. Think about references. No, think harder. See?
--
Alan Burlison
t unsubscribe.
It's doomed.
Alan Burlison
Simon, which I think is a really, really useful thing - you can use
it to get the essence of what went on and why, and then drill down to
the meat if you need to.
Alan Burlison
s generated by writing
a DTD for the spec and then transforming the document into the frameset
and html files. That would be the obvious way to do it. That way when
writing the document the commentary could be kept inline, which would
make it much easier for the author.
Alan Burlison
Nathan Torkington wrote:
> Alan Burlison writes:
> > seem a very optimal way to go about it. How about a design document
> > (format to be decided) and a 'design + commentary' document which is the
> > design document with the condensed email discussion inserte
cursing/hacking/cursing
cycle on the existing POD tools. Do we really want to continue?
Personally I think POD sucks bigtime, although I'm sure hordes of people
will now spring up to defend it. I still think that with the correct
DTD writing the specs in XML would be doable.
Alan Burlison
y sense to tag the various
bits.
Alan Burlison
from being one character
shorter, that is.
However, having previously been told to shut up on this subject, I now
will.
Alan Burlison
n of apps are MT vs AIO, and which is
most likely to be available, well tested and well supported?
Alan Burlison
> But the short answer (while it may suffice for perl6) is no use to me
> as a perl5 maintainer.
Well, we all have our particular crosses to bear ;-)
At the risk of being boring: Threads in perl5 are irredeemably broken
and should not be used.
Alan Burlison
is is the smallest safe set
> of things we can do, and I'm reasonably sure that everything else anyone
> might want can be layered on top, albeit slowly in some cases.
A very sound strategy IMHO.
Alan Burlison
-- thread# 3
ff35d6e4 _reap_wait (ff382a50, 20bf8, 0, ff37e000, 0, 0) + 38
ff35d43c _reaper (ff37ee80, ff3847b0, ff382a50, ff37ee58, 1, fe40)
+ 38
ff36b4a0 _thread_start (0, 0, 0, 0, 0, 0) + 40
Alan Burlison
easier than faking threads. so we code all the internals to an
> event loop api and fake it underneath as needed on various
> platforms. much more on this soon.
As Jarkko would say:
Yes, yes yes.
:-)
Alan Burlison
Branden wrote:
> Where can I find how Perl5's stack works (specially about parameter passing
> and returning from subs)?
Oh boy. What a masochist.
;-)
Alan Burlison
cted regime - even with
this restriction, and with the bugs I've already fixed the test suite
contains 141 memory errors.
The truth of the matter is that I suspect eval and die will always leak
until it is re-architected in perl6 - whenever that might be.
Alan Burlison
Branden wrote:
> Any suggestions?
Yes, but none of them polite.
You might do well to study the way perl5 handles these issues.
Alan Burlison
t;bar\n";
}
At present "file" will contain "foo\nbar\n". Without DF it could just
as well be "bar\nfoo\n". Make no mistake, this is a major change to the
semantics of perl.
Alan Burlison
slate
situation. We may well have to deliberately carry over questionable but
depended-upon behaviour into perl6.
my $fh = do { local *FH; *FH; }
for example, better continue to work.
Alan Burlison
scheme will
require the heay use of mutexes in a MT program.
Alan Burlison
't be freed and re-malloced much. If we're passing in a PMC
> pointer, we won't be reallocating the memory pointed to--rather we'll be
> reusing it.
So how do you get hold of a PMC from the arena in the first place?
Alan Burlison
hink macro languages suck, whether they are the C macro preprocessor,
or some fancy dohickey that we knock together. I think that having to
have perl5 around to build perl6 also sucks. For example, in our case
we build perl5 every night with the rest of Solaris. It already takes
too long. Adding a build of perl5 just to build perl6 - well, forget
it.
Alan Burlison
Dan Sugalski wrote:
> Grab one via a utility function. getPMC() or something of the sort.
newPMC() ? ;-)
Alan Burlison
Alan Burlison wrote:
> I've attached the HTML
Well it was there when I sent it... does this list strip attachments or
something?
Here is is as badly-formatted text - sorry!
Alan Burlison
Appendix A: How Sun WorkShop Memory Monitor Works
Memory management in C/C++ is both time c
only works with the Sun compilers.
However, there is an explanation of how it works that might be useful
when considering how to do this for perl6. I've attached the HTML -
sorry about the broken links, but I don't think this is on any
externally-visible webpage.
Alan Burlison
Uri Guttman wrote:
> malloc normally doesn't care about alignment.
I'll think you will find it does care.
Alan Burlison
I see nothing about namespacing, e.g. Perl_
Alan Burlison
Dave Mitchell wrote:
>
> All entities should be prefixed with the name of the subsystem they appear
> in, eg C, C. They should be further prefixed
> with the word 'perl' if they have external visibility or linkage,
>
Duh! Missed it. Thanks.
Alan Burlison
straction is a
laudable aim, in the case of perl it has turned from abstraction into
obfustification.
Alan Burlison
ters.
Not a system call but a trap - they aren't the same thing (pedant mode off
;-). The register spill trap handler copies the relevant registers onto the
stack - each stack frame has space allocated for this.
Alan Burlison
tem has real registers, it's just at some
point they may end up in memory. That's not the same as indexing into
memory on every access.
Alan Burlison
65 matches
Mail list logo
