I've decided it's time for me to take another break from this list.
Not that any of you care, but I think the reason is important.
Due to a silly misunderstanding -- one which could have been easily
avoided by a simple request for clarification -- our Illustrious
Summarizer decided to be
Piers Cawley wrote:
Juergen Boemmels [EMAIL PROTECTED] writes:
But how do I represent them at parrot-level.
{ type = '*environment*' value = {scratchpad = aScratchPadPMC}
Etc.
The point being, we're building these things into parrot so that
HLLs can use them natively, rather than have to
Steve Fink wrote:
Here is the new PMC I keep babbling about. Before I commit it, any
comments? Like, does anybody think this should be named differently?
It's really a dequeue (double-ended queue), ...
I for one think it ought to be called what it is - a dequeue.
--
John Douglas Porter
Sean O'Rourke wrote:
... I don't see how giving the list a
different name will have any real effect ...
?
It will have a huge psychological effect, at least outside our tight
little club. But if that's only as far as you can see...
--
John Douglas Porter
Bryan C. Warnock wrote:
IANADan, but he's aware of these issues, and is/has been thinking about
them.
Fine. But what does Larry think?
We're not going to fool anyone that this isn't a Pet Perl Project, and
while other communities are eyeing us, it's not clear that the amount of
work to
Dan Sugalski wrote:
What's more likely is that Parrot will accumulate bits from
other languages--rather than losing Perl we'll gain Ruby and Python.
Maybe others too.
But that doesn't address the real issue, which is --
Are we really serious about enabling other languages to target this
Dan Sugalski wrote:
The intent ultimately
is that you hand an AST, and potentially some rules, to IMCC and it
creates bytecode for you from it.
That's different, then. Then the whole issue of syntax goes away.
Unless the data interchange format is textual; but even then, you'd
want a
Angel Faus wrote:
I am all for the creation of a new list for stuff such as imcc, and perl6
compilers. ([EMAIL PROTECTED]?)
I wonder if maybe perl6-internals should have been named parrot, anyway.
By being less overtly perl-centric, and thus more HLL-neutral, we could
have gotten more direct
Leopold Toetsch wrote:
I don't understand why it is so hard to adopt. imcc is supposed to be
a step closer to higher level languages, which is why I went that way.
No problem here, it is called _intermediate_ ..., which is a worthful
step in code generation, but - as always - there is a
Brent Dax wrote:
John Porter:
# languages. Seems to me that to say that every feature of parrot
# must be exposed in imcc is to imply that all upper-level
# languages must go through imcc -- and that's something I
Let me see if I can follow your logic: IMCC gives access to all Parrot
Sean O'Rourke wrote:
However, if we already have a working register
allocator and peephole optimizer, I see little reason to write another.
Maybe you're taking a very perl6-centric view. (I don't know.)
But as someone who's writing an Tcl-to-parrot compiler
(for (hypothetical) example), I
Melvin Smith wrote:
Good question. The problem is, there is no one but us to answer
that question. Or who are we waiting for?
I'd like to think that Dan would just declare on the matter
and put it to rest. But what I *really* think is that Larry,
or at least Damian, might have something very
Dan Sugalski wrote:
I expect a UINTVAL should be sufficient to hold the counter.
Why? Because you don't expect a perl process to run longer
than a couple hours? Or because rollover won't matter?
--
John Douglas Porter
Aldo Calpini wrote:
I have to disagree. the corresponding Perl script
does not show this behaviour:
It all depends. :-)
$\ = \n;
$#a = 100;
print scalar(a);
$x = $a[1][0];
print scalar(a);
101
10001
Perl has to autoviv if it has to drill down.
--
John Douglas Porter
Sean O'Rourke wrote:
I read that as expressions are evaluated once, not PMC's are accessed
once. So something like
2 $i++ 23
will do the expected -- increment $i once, keeping the result in a PMC
temporary.
I don't see that. $i++ increments the original PMC.
2 $i+1 23
Aldo Calpini wrote:
this is a little tutorial about submitting patches
(should be added to a FAQ, or somewhere where it's handy
I think this deserves its own page somewhere on
dev.perl.org.
--
JohnDouglasPorter
__
Do You Yahoo!?
Yahoo!
[EMAIL PROTECTED] wrote:
Also, how deep should we go if we decide to have the hash algorithm
work on the contents?
One starts to understand why scheme has Ceqv?, Ceq? and
Cequal?.
Indeed. It's also why it allows to specify, in AA accesses,
what equality-testing operator you want keys to
[EMAIL PROTECTED] wrote:
My opinion: rename the current PerlHash to Hash, and create
a new PMC PerlHash that does PMC-PMC mappings.
How about two hash types: one that does shallow comparisons
and one that does deep comparisons.
Which one Perl6 should use would be an open question, I guess...
Dan Sugalski wrote:
Yes. Hashes will take either strings or object IDs, depending on the
hash. (The hash can choose)
Seems to me it would be mighty useful to have integer keys as well.
For large sparse arrays, e.g.
--
John Douglas Porter
Melvin Smith wrote:
Hmm, looking at the source directory, I'm starting to think
maybe that isn't so good, it is pretty busy already.
We have one vote for a /dev directory.
Actually, I think Dan did -- or at least was going to do --
something about this last night. Part of it was to shove
Tanton Gibbs wrote:
. . . That saves a person digging through
the .c file to find what they are looking for.
Perhaps we could automatically update the .dev
file with the POD found in the .c file?
As someone else has already said, a better place
for the .dev information might be inside the
Brent Dax wrote:
Do you really want to see a ten-page discussion of hashing
algorithms and why the current one was chosen in the middle
of classes/perlhash.pmc?
I guess that wouldn't bother me as much as it might bother
some other people.
*That's* the sort of thing the .dev files are for,
Andy Dougherty wrote:
I think the purpose of the .dev files, as laid out in
docs/pdds/pdd07_codinstd.pod, is a reasonable one.
Here's an edited excerpt: . . .
(Thanks, Andy.)
Well, given that definition of the purpose, I must
persist in my opinion that the proper place for that
kind of
very recently I wrote:
... fine. Whatever.
People, if I'm coming across with a nasty or petulant tone,
I sincerely apologize. It's really not what I was going for.
jdp
__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
Damien Neil wrote:
I'm not familiar with predictive seeks,
can you give a quick explanation?
It's very much like predictive loading of the instruction cache
in a cpu. It makes a heuristic guess that since you just read
1000 bytes in order, you're probably going to want to read the
next 1000
Scott Walters wrote:
* PMC's be accepted in place of or in addition to KEY *'s
in variants taking multidim subscripts.
In particular, a PMC containing a vector (aka tuple, aka array)
of indices, one per dimension.
As in so many other cases, the array object and the key vector
object should
But what about setting size on multdimensional PMC's
would it also be:
set P0,5,5,5
assembler.pl would try to call
set_p_ic_ic_ic
This will break things when having N dimensions..
I don't see how it could possible be workable
to have all the indices listed out in the
David M. Lloyd wrote:
John Porter wrote:
The MM dispatch problem is pretty much solidly in
the realm of pmc inheritance,
There _is_ no pmc inheritance right now.
There's just a set of default functions.
Call it what you want.
The point is that this type schema is at the parrot level
John Porter wrote:
The point is that this type schema is at the parrot level,
and is not the concern of a user-level language like perl
Of course this is not really true; perl scalars, arrays, and
hashes (etc.?) are implemented as PMCs under the hood, so
in that sense they are related
David M. Lloyd wrote:
No, the point is that all this talk about type-space mm dispatch
depends on there *being* type space. Since there is currently
no inheritance to speak of then there really is no typespace so
all of this talk is moot,
I agree; but you did express a concern earlier that
Nicholas Clark wrote:
... PerlIO::subfile (treats a section
of a file as if it is a whole file - lets you read direct from a tar
on an uncompressed file stored in a zip file)
Ah -- just like Virtual File Systems (VFS) from Tcl-land.
Good idea!
('COURSE it's a good idea!)
--
Melvin Smith wrote:
I put it temporarily in the root dir, which I know is wrong.
Where should .dev files go, anyway?
Actually, I think that's right.
..dev files live alongside their .c/.h siblings, no?
--
JohnDouglasPorter
__
Do You Yahoo!?
David M. Lloyd wrote:
Do we really want *two* inheritance trees per object
in Perl 6? One language-level and one PMC-level?
Well, parrot != perl6, so I don't see a problem.
The MM dispatch problem is pretty much solidly in
the realm of pmc inheritance, and that's something
we have control
Sean O'Rourke wrote:
NOTE: this may be part of the monster-patch to fix the over-agressive
string GC (814), but it's much more palatable in this form.
PerlInt's
cmp() method was backwards, and would truncate floats on the other
side of the comparison.
This patch always uses
Sean O'Rourke wrote:
... all it buys you is a few bits of precision when your ints
and floats are both 64-bit, and slower comparisons all the time.
IMHO it's a wash, so I did it this way.
I would point out that integers have infinite precision.
More than a few bits' difference, I'd say.
But
Brent Dax wrote:
2. What does having a Parrot_ prefix signify, considering
both the opcodes and the embed api use it?
It signifies one of the following:
-This function is externally visible.
-This function belongs to Parrot at large, and not any particular
subsystem (e.g.
Brent Dax wrote:
Ashley Winters:
c. parrot_sprintf
Lowercase is always the hallmark of struct names, i.e.
parrot_string_t.
Ehhh... you yourself said something about plat_ and misc_
as (theoretical) alternatives.
Anyway, it's a silly rule. Upper-case (and lower-case) are
going to have
Brent Dax wrote:
If people want that scheme, speak now or forever hold your peace.
Sounds reasonable to me. (FWIW)
_Parrot
_parrot
__Parrot
__parrot
The last four are reserved by various C and C++ standards.
Damn, I forgot about that. I'm a C coder from Way Back;
still
Ask Bjoern Hansen wrote:
[EMAIL PROTECTED] (John Porter) writes:
Yeah, look at the so-called Parrot FAQ. Someone needs to
get serious and make a real FAQ for parrot developers.
I'm sure noone would mind if you start one!
Does no one on this mailing see my point?
It does not work
I have to say that I am extremely disappointed at the
paucity of internal documentation.
One of the goals of the p6 rewrite is to make the code
more accessible for maintainers who will come along later.
This cannot happen without good, substantial internal
documentation.
And I don't wanna hear
Which IRC network, which channel?
I use irc.pobox.com, you can also try irc.rhizomatic.net
Channel is #parrot
Problem I have with irc (besides the fact that I don't, can't
and won't use it) is that all the good stuff that flows by
isn't getting captured and archived anywhere. I'm sure
Melvin Smith wrote:
Guys, look at the facts. We have a very small number of
internals hackers here, and only one who actually gets
paid for it. . . . We are not an army.
I'm so busy building this tower single-handedly,
I don't have time to teach anyone else how to cut
stone or mix mortar.
Melvin Smith wrote:
What parts particularly bug you? Maybe we can address a few.
Well, basically, AFAICT, virtually none of the parrot code
is adequately documented. So, pick a random entry point. :-)
But this is why I'm not suggesting that someone drop what
they're doing and going in and
Andreas J. Koenig wrote:
... trimming CC list always would probably be an overreaction.
Sounds like you have good reasons.
Oh well, some people win, some people lose.
:-/
--
John Douglas Porter
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial
Brent Dax wrote:
Nicholas Clark wrote:
Unless I'm being thick, x² y² whenever x y for positive x
and y (ie you don't need to take the square root of the
hypotenuse to work out which hypotenuse is shorter. And all
we're actually interested in which one is shorter, aren't we?)
Dan Sugalski wrote:
lookup is O(n) since we precompute the dispatch table.
Oh. So the cost of computing the table is amortized over all the
mm calls that go to the table for resolution. Could be Bad,
for the typical small Perl program.
Then there's the issue of the size of the table.
Dan Sugalski wrote:
Nicholas Clark:
Unless I'm being thick, x y whenever x y for positive x
and y (ie you don't need to take the square root of the
hypotenuse to work out which hypotenuse is shorter. And all
we're actually interested in which one is shorter, aren't we?)
We can also
Dan Sugalski wrote:
That trades space for speed,
Ain't it always the way. ! :-)
In general that's potentially unbounded, but for the specific
case of PMC vtable methods it's a fixed number.
It gets more interesting for general methods and subs,
but we can deal with that a bit later.
Andy Dougherty wrote:
Assuming x and y are coordinates in a 2-d space, and that both are
integers = 0, why not just use what is affectionately called the
taxicab metric: x+y? It is just as valid and even quicker to
compute than the Euclidean metric sqrt(x^2 + y^2).
Yes! Very incisive
Nicholas Clark wrote:
I was thinking that the metric (x*x + y*y) would be fast to
calculate, as that's all we need for ordering.
Point is, it's rather *more* than we need for ordering.
x + y will suffice.
And I live in London, where we don't have a regular grid of
streets, so our taxis
Dan Sugalski wrote:
Piers Fermat Cawley wrote:
Oh yes, and I recently wiped it (p5 port included) by accident.
And didn't have a backup. Ah well...
That's just a bit of self-preservation on the part of the universe,
I expect... ;-P
Then the universe hasn't evolved to the point where
Dave Mitchell wrote:
IIRC, all metrics of the form (x^n + y^n)^(1/n), n=1,2,...Inf
are strongly equivalent, ie they give rise to the *same* ordering.
(In the limit as n - Inf, the metric is max(x,y).)
I'm sorry, YDNRC.
Consider the distance from the origin to the points (0,6) and (3,4).
Clark C . Evans wrote:
So, I propose that Parrot supports both of these attitudes
of reasoning by using a flag. Initially, all strings
are 'mutable'.
I concur with Clark. What he's proposing is (it seems to me)
nothing more than a read-only flag, and that's as
immutable as a variable
umm... has anyone else noticed that pdd02 in the distribution (0.4)
is spouged, and that pdd03 is completely missing?
--
John Douglas Porter
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
Florian Haeglsperger wrote:
But isn't this partly addressed with COW?
. . .
Thus I don't see a very big performance win in introducing mutable
strings.
Good point.
But some people maintain that there could be a need for truly
constant strings, that should never be modified, and any
Dan Sugalski wrote:
These 'add-on' bytecode interpreters don't get any special
consideration in the core. That means they *can* have:
*) A custom bytecode loader to translate their bytecode format
to ours, or something we can use
*) As many custom PMC classes as they want
*)
Dan Sugalski wrote:
What we're
doing is assuming we don't know and letting the variables decide
whether they'll care. Perl's will, though other languages can decide
differently.
Letting the variables decide?
So, we take a poll of all the arguments, and ask each one
which they think ought
Dan Sugalski wrote:
I'm not sure that the place to enforce read-onlyness is at the
string/buffer level. Doing it at the PMC level is more likely the
right place to do it.
Yes; but what about non-PMC variables?
--
John Douglas Porter
__
Do
Would I be out of line to request that people edit their email
headers so that replies only go to the list?
I'm tired of getting two (or more) copies of everything on
any thread I've posted in.
Thanks,
John Douglas Porter
__
Do You Yahoo!?
Sign
Dan Sugalski wrote:
John Porter wrote:
but what about non-PMC variables?
Generally speaking, there aren't any. Everything else (in this case
the buffer/string things) is for internal use only. Languages aren't
supposed to expose strings directly.
Languages are only supposed to expose
Dan Sugalski wrote:
John Porter wrote:
I assume (but I'm open to correction) that it is *not* to simulate
the vm of other language environments, so as to execute faithfully
bytecode produced in those environments. (That is, taking object
code from a python compiler (e.g.) and executing
Garrett Goebel wrote:
John Porter wrote:
Not to beat on Dan (or anyone else), but for the sake of those
[...]
Please don't beat on Dan... ;)
I'm not!
Parrot isn't Perl. I.e., your Perl-vision blinders are on a tad
tight. It's the first general purpose vm for dynamic languages
Dan wrote:
Okay, here are some tasks for the interested. They're all related
(I expect you'll see the pattern), but independent anyway.
1) Dig through the perl source and find out all the opcodes.
(pp.c and friends) Document the opcodes and what they do.
2) The same as #1, only for
[restricted to -internals, since that's the only one I'm on]
[EMAIL PROTECTED] wrote:
Oh yes. John Porter suggested that 'maybe Damian should write
[the grammar]?'. Which leads me to postulate an analog to Godwin's
Law, tailored to the perl 6 process, stating that at some point in
any
http://www.complang.tuwien.ac.at/anton/vmgen/
(Sorry if this has been mentioned before...)
--
John Douglas Porter
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
(I don't have the original msg in my mbox, so I'm jumping in here...)
The following is from the Tcl bytecode compiler [1] FAQ:
Why doesn't Tcl use the Java bytecodes?
I [2] had originally hoped to use Java bytecodes because they have a
mature design and because Java is widely available. I
For some reason I feel really, really bad saying this --
in fact, I'm warming up the flog right now -- but, um,
maybe Damian should write it?
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
Simon Cozens wrote:
On Thu, Dec 07, 2000 at 11:22:35AM -0500, John Porter wrote:
[C++]
It's nearly as portable,
Uhm. Is this actually true?
I don't know. Sounds reasonable! :-)
Aside from lame-o solutions like C-front and cross-compiling,
I'd say, screw 'em if they don't have a C
Compatibility Beast rears its slathering, kerotic heads...
--
John Porter
I saw the final vicar
make confession to a dancer
We stood upon the bridge at dawn
and the dancer kissed my cancer
aking away Perl6, which is vaporware.
I wonder: In what order will the following exist on Handheld Device
Foo:
- C
- C++
- Java
- Perl6
--
John Porter
Simon Cozens wrote:
Great. When it comes down to it, what are you doing here?
Excellent question.
--
John Porter
Dan Sugalski wrote:
You forgot:
* Secret vote of the Perl Cabal...
;-)
And also:
* Behind-the-scenes string-pulling by corporate interests.
--
John Porter
* the Triads
Do you mean:
* The Trilateral Commission
* the Freemasons
And/Or:
* The OTO
* the Illuminati
Sure. And what about:
* The Drug Cartels
* The Media
* Joggers :-)
--
John Porter
A cop knelt and kissed the feet of a priest,
and a queer threw up
For those of you who may not have heard of it -- there's
an implementation of Scheme called Elk ("Extension Language
Toolkit"), which seems to have done a fabulous job of
dealing with the inter-language interface, C/C++ - Scheme.
http://www-rn.informatik.uni-bremen.de/software/elk/
Garrett Goebel wrote:
eval { prototype "CORE::$func" };
Strangely, prototype() "works" in 5.004_04, but does not throw
the exception for non-existent functions.
--
John Porter
Garrett Goebel wrote:
I'm sure you won't be surprised by this, but I recall John
Porter as being a C-- fan. Now why is he being mysteriously silent?
Nope, wasn't me. Never heard of it until someone brought it up earlier.
I do admit, it sounds intriguing.
I just wanted to mention
) monstrosity.
This is a case of me agreeing with Simon 1000%.
I was going to just let it go by, but I thought it might
be nice to add my aol/ for a change.
--
John Porter
Dan Sugalski wrote:
Well, damn. And I mean that sincerely. :(
I don't think it's that big a deal. Easy enough to wrap in a macro.
--
John Porter
Jarkko Hietaniemi wrote:
On Thu, Oct 12, 2000 at 10:55:52PM -0400, John Porter wrote:
I don't think it's that big a deal. Easy enough to wrap in a macro.
I thought (hoped) that the plan was the avoid the cpp like the plague
and cancer it is.
Well, yes, definitely; but we're just
split /\s+/; # non-magical now, thanks. :-(
pop @a if @a $a[-1] eq '';
shift @a if @a $a[ 0] eq '';
I think the choice is obvious.
--
John Porter
By pressing down a special key It plays a little melody
now checked out Dia, and I'm not
enthusiastic about it. It seems to be a good start, but maturity is
a long way off. Not only that, but it is cumbersome (imho) to set up.
I still think I'd rather see a java or web-based solution.
--
John Porter
e.
UML is extremely useful as a design language. I wonder, though, how
a distributed collaborative effort can utilize it. Anyone know of any
open-source web-enabled UML tools? Or do I gotta write one myself? :-)
--
John Porter
Jetzt schalten wir das Radio an. Aus dem Lautsprecher klingt es dann...
Simon Cozens wrote:
(The deadline for collecting ideas passed two weeks ago. Why is this all
still going on?)
Because there are still many worthy ideas which have not surfaced yet.
Which is the higher priority?
--
John Porter
We're building the house of the future together.
Ken Fox wrote:
Perl is more like lisp with a good syntax -- in other
words about as far from C as you can get.
I agree 100%.
--
John Porter
scope.
eval {
$foo = 1;
trans {
local $foo = 2;
die;
}
};
As a trivial case, perhaps exceptions are not being caught at all.
--
John Porter
We're building the house of the future together.
ly, I'd rather see transaction-enabling requested on
a per-variable basis.
--
John Porter
We're building the house of the future together.
Steve Fink wrote:
"cond" for conditional?
I was thinking along that line, too. But coopting "conditional" in any way
is probably an ungood idea.
Probly "trans" is good; it has multiple useful mnemonic values: transactional,
transfer, transparent...
--
John
this in Tie::Multidim... and it is *hairy*. And slow.
--
John Porter
We're building the house of the future together.
should be a well-designed, consistent, integrated opus.
If it goes against the grain of perl6's design to have system-specific
system calls built in, then they shouldn't be built in, regardless of
how it was in perl5.
--
John Porter
We're building the house of the future together.
Larry Wall wrote:
Dan Sugalski writes:
: Or, more succinctly, we're not going to screw with perl without a *darned*
: good reason.
Er, perl is already screwed--it's Perl we're trying to preserve and grow.
Man; leave it to Larry to say the right thing, in the best way. :-)
--
John
in, regardless of
how it was in perl5.
That's silly. *ALL* syscalls are system specific.
Well, duh. So what? Did you really miss my point by so many furlongs?
You'll take my fork when you pry it out of my cold, dead hands.
Perl will ship with fork. But maybe in a loadable library, eh?
--
John
Tom Christiansen wrote:
Why don't we just say that Perl isn't for
systems work anymore, and remove everything that diddles $!,
or $?, or anything that might call anything from the C library.
As in "remove mountains", yes.
--
John Porter
We're building the house of
. Urghh.
--
John Porter
the foreign code is welcome
to override if it wishes.
I wonder if this idea was (or could yet be) informed by CORBA IDL,
or perhaps some other IDL, such as Xerox ILU?
--
John Porter
94 matches
Mail list logo
