Leopold Toetsch:
# It's totally sane with the standard copying allocator. But the malloc
# allocator tracks resources (i.e. strings bufstart) only via
# the header.
# So, when you reuse the header, the old bufstart which was
# there before
# is unmanaged and leaks.
Can we add a way to
Brent Dax wrote:
Leopold Toetsch:
# It's totally sane with the standard copying allocator. But the malloc
# allocator tracks resources (i.e. strings bufstart) only via
# the header.
# So, when you reuse the header, the old bufstart which was
# there before
# is unmanaged and leaks.
Can we
[EMAIL PROTECTED] wrote:
Leo --
Here's one of the messages about how I'd like to see us link op
implementations with their op codes:
http://archive.develooper.com/perl6-internals;perl.org/msg06193.html
Thanks for all these pointers.
I did read this thread WRT dynamic opcode loading.
My last patch did break runops_slow_core (first instruction got traced)
- fixed.
And finally I found an hopefully sane way, to implement the idea from
#17495:
- stacktop is initially set in test_main
- if running the CGgoto core and it's cleared in interpreter
- in cg_core stacktop get's set
Nicholas --
I agree it would be good to see CG performance (compilation and exeuction
speed) with and without
optimizations. I haven't done the experiment myself.
I had tinkered with some asm-comment ideas last year when discussing JIT
with Daniel Grunblatt. For
your amusement, I've attached a
At 18:57 on 11/04/2002 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
atexit is not an alternative, because we might have multiple
interpreters to clean up like in t/op/interp_2.
So the issue here is that on_exit can take a parameter to be passed into
the handler function, right?
We could
Nicholas Clark wrote:
I believe that your understanding of the JIT and the GC cores are still
correct. The problem would be solved if we had some nice way of getting the
C compiler to generate us nice stub versions of all the non-inline ops
functions, which we could then place inline.
At 12:41 PM +0100 10/30/02, Leopold Toetsch wrote:
Nicholas Clark wrote:
Also, no-one commented on my suggestion a long time back to remove
-fno-strict-aliasing from gcc's flags. In theory we're stopping some possible
gcc optimisations with this.
I don't see a reason, why we would need
At 9:41 AM +0100 10/30/02, Leopold Toetsch wrote:
Jason Gloudon wrote:
... By default both compilers align stack variables at their natural
alignment, so PMC pointers would normally fall on 4 byte boundaries.
However, it is also possible that someone might save a PMC pointer to an
unaligned
On 2 Nov 2002, Juergen Boemmels wrote:
Ok, I tested the patch (I tried to use this scratchpads for the scheme
compiler)
One thing I missed (or at least didn't find): How can I generate a new
scope? new_pad generates a new one one the pad stack with a size which
is actually smaller than the
[EMAIL PROTECTED] wrote:
Leo --
I don't know much about the CG core, but prederef and JIT should be able
to work with dynamic optables. For prederef and JIT, optable mucking does
expire your prederefed and JITted blocks (in general), but for
conventional use (preamble setup), you don't pay a
Dan Sugalski [EMAIL PROTECTED] writes:
[...]
No, it doesn't. It needs to preallocate a few entries in the TOC at
the start of the chunk, but that's it. Not that much waste, even if
some of the metadata's in the TOC.
The point is to have a file format that does what we need it
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #18219]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18219
The Solaris tinderbox is currently failing with
gcc -o parrot [...]
Jason --
Originally, I considered adding an optable segment to the packfile format
and no useop op.
After considering useop, I found the idea of a conventional (but
technically optional, TMTOWTDI) preamble
and the ability to modify the optable while running intriguing.
There is value to using
Andy Dougherty wrote:
Alternatively, developers could always try to ensure they checkin patches
in the correct order so that the timestamps stay correct.
I would prefer such a solution - or better something a long:
info cvs
The commit support files
i.e. a
Andy Dougherty wrote:
I have committed the following patch:
-//mem_sys_free(p);
+/* mem_sys_free(p); */ /* XXX ??? */
Sorry for that, must have slipped through during my different trials to
clean up PIO.
It would also be nice if someone who understood this could add
Andy Dougherty wrote:
Alternatively, developers could always try to ensure they checkin patches
in the correct order so that the timestamps stay correct.
Or yet another one:
$ cat bison
touch imcparser.c imcparser.h imclexer.c
in languages/imcc should do it.
leo
Andy Dougherty (via RT) wrote:
That's because Solaris doesn't have on_exit. It does have atexit, but
atexit doesn't take any parameters so it's not a direct drop-in
replacement. The correct fix is not obvious to me. I suppose
someone could have Configure.pl test for on_exit and only use it
[EMAIL PROTECTED] wrote:
Leo --
... Optable build time is not a function of program
size, but rather of optable size
Ok, I see that, but ...
I don't think it remains a problem how to run ops from different oplibs
_fast_.
the problem is, that as soon as there are dynamic oblibs,
Leo --
Ah. It seems the point of divergence is slow_core vs. cg_core, et al.
As you have figured out, I've been referring to performance of the non-cg,
non-prederef, non-JIT (read: slow ;) core.
I don't know much about the CG core, but prederef and JIT should be able
to work with dynamic
Leopold Toetsch:
# the problem is, that as soon as there are dynamic
# oblibs, they can't
# be run in the CGoto core, which is normally the fastest core, when
# executions time is depending on opcode dispatch time. JIT is (much)
# faster, in almost integer only code, e.g. mops.pasm, but
On Sun, Nov 03, 2002 at 04:59:22PM -0500, [EMAIL PROTECTED] wrote:
What I advocate is having possibly only one (maybe too extreme, but
doable) built-in op pre-loaded
at opcode zero. This op's name is useop, and its arguments give an
opcode (optable index), and
sufficent information for the
When I trycd languages/perl6; make; the build stops with
bison -v -y -d -o imcparser.c imcc.y
sh: bison: not found
The above-referenced patch includes changes to
config/gen/makefiles/imcc.in to avoid this problem.
That patch has the disadvantage of requiring developers to remember
I have committed the following patch:
diff -r -u parrot-orig/io/io.c parrot-andy/io/io.c
--- parrot-orig/io/io.c Mon Nov 4 11:26:09 2002
+++ parrot-andy/io/io.c Mon Nov 4 12:02:22 2002
@@ -160,7 +160,7 @@
down = p-down;
if (p-api-Delete)
(*p-api-Delete) (p);
-
Leopold Toetsch [EMAIL PROTECTED] writes:
Andy Dougherty wrote:
Alternatively, developers could always try to ensure they checkin patches
in the correct order so that the timestamps stay correct.
Does cvs change the timestamps at checkout/update according to the
checkin timestamp?
Or
What is the official position with respect to laundry services in the
Parrot memory allocation code?
Some code assumes that the memory returned by Parrot_allocate
and its cousins will be pre-washed, while other code does its own
laundry. The same applies to 'bufferlike' headers - the buffer
On Mon, Nov 04, 2002 at 10:09:06AM -0500, [EMAIL PROTECTED] wrote:
While I don't think I'm sophisticated enough to pull it off on my own, I
do think it should be possible to use what was learned to build the JIT
system to build the equivalent of a CG core on the fly, given its
structure. I
[Note to all: yes, this is me, despite the weirdities of the quoting
and headers. This is how it looks when I using mutt out of the box,
because I haven't yet customized it like I have pine. But I do like
being able to see my own Unicode characters, not to mention everyone
else's. If you don't
ralph wrote:
It's clear you could have come up with
something like one of these:
method f ($a, $b) is invoked_by($self)
method f ($a, $b) is invoked_by($self is topic)
method f ($a, $b) is invoked_by($_)
but you didn't. Any idea why not?
Because most methods need some kind of
Larry Wall:
(B# for @x $B!B(B @y $B!B(B @z - $x, $y, $z { ... }
(B
(BEven if you decide to use UTF-8 operators (which I am Officially
(BRecommending Against), *please* don't use this one. This shows up as a
(Bbox in the Outlook UTF-8 font.
(B
(B--Brent Dax [EMAIL PROTECTED]
On 04/11/02 17:52 -0800, [EMAIL PROTECTED] wrote:
[Note to all: yes, this is me, despite the weirdities of the quoting
and headers. This is how it looks when I using mutt out of the box,
because I haven't yet customized it like I have pine. But I do like
being able to see my own Unicode
Larry wrote:
I've actually got my eye on ≈ (U+2248 ALMOST EQUAL TO) as a
replacement for ~~ someday in the distant future.
I suppose it could be argued that we should use ≅ (U+2245
APPROXIMATELY EQUAL TO) instead. That's what =~ was supposed to
represent, after all...
Yeah, either of those
Smylers summarized (beautifully, thank-you):
* the looks like an array option: [op]
» Seemed a nice idea, but doesn't work with other use of square
brackets.
Could be made to work. Suppose that every operator definition (explicit or
implicit) automagically also defined a variant
Larry wrote:
But at the moment I'm thinking there's something wrong about any
approach that requires a special character on the signature side.
I'm starting to think that all the convolving should be specified
on the left. So in this:
for parallel(x, y, z) - $x, $y, $z { ... }
the
--- Matthew Zimmerman [EMAIL PROTECTED] wrote:
On Sun, Nov 03, 2002 at 09:41:44AM -, Rafael Garcia-Suarez wrote:
Matthew Zimmerman wrote in perl.perl6.language :
So let me make my original question a little more
general: are Perl 6 source files encoded in Latin-1,
UTF-8, or
I'm probably opening up a whole new can of worms here, but if we said
that the following were both vector operators:
^ == intersection operator
v == union operator
then these could have potentially useful meanings on their *own* as set
operators, as well as modifying other
Ed Peschko asked:
ps - as an aside, are the apocalypses going to be backdated as changes to the
design come up?
Yes.
Or are the apocalypses just a first draft for more enduring
documentation?
Yes.
;-)
Damian
On Mon, Nov 04, 2002 at 10:19:55AM -0800, Michael Lazzaro wrote:
UTF-8 «op» representations have the advantage of trivially not
conflicting with _any_ existing operators, and being visually distinct
from all of them. There may be a few other things in
easy-to-find-and-type Latin1, like one
Something from [EMAIL PROTECTED] about the relative frequency made me
wonder:
What's the order of evaluation or nestedness for separate streams
in a for loop?
That is, can I meaningfully say:
for my $i; $j - 0 .. @array.length - 1; $i + 1 .. @array.length
{
..
}
And get the equivalent of two
On Mon, Nov 04, 2002 at 11:27:16AM -0800, Austin Hastings wrote:
--- Matthew Zimmerman [EMAIL PROTECTED] wrote:
On Sun, Nov 03, 2002 at 09:41:44AM -, Rafael Garcia-Suarez wrote:
Matthew Zimmerman wrote in perl.perl6.language :
So let me make my original question a little more
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Mon, 4 Nov 2002 12:09:12 -0800 (PST)
From: Austin Hastings [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
Something from [EMAIL PROTECTED] about the relative frequency made
--- [EMAIL PROTECTED], UNEXPECTED_DATA_AFTER_ADDRESS@.SYNTAX-ERROR.
wrote:
Mmm, I view one-character Unicode operators as more of an escape
hatch
for the future, not as something to be made mandatory. But then,
I'm one of those ugly Americans.
EBCDIC didn't support brackets, originally, so
--- Luke Palmer [EMAIL PROTECTED] wrote:
I don't know where to correct you first... :)
Is that a dunce-hat? Is there an ISO version I could use instead? :-
I'll start by saying your variables are on the wrong side of the
pointy sub. Also, presuming you switched the order, that Cmy
On 2002-11-04 at 12:26:56, Austin Hastings wrote:
1- ? and ? are really useful in my context.
Okay. Now can you get your mailer to send them properly? :)
Austin Hastings wrote:
At this point, Meestaire ISO-phobic Amairecain Programmaire, you have
achieved keyboard parity with the average Swiss six-year-old child.
The question is not about being ISO-phobic or pro-English. **
The question is whether we want a pictographic language. I like
the
After all, there's gotta be some advantage to
being the Fearless Leader...
Larry
Thousands will cry for the blood of the Perl 6
design team. As Leader, you can draw their ire.
Because you are Fearless, you won't mind...
--
ralph
Ken Fox wrote:
I know I'm just another sample point in a sea of samples, but
my embedded symbol parser seems optimized for alphabetic symbols.
The cool non-alphabetic Unicode symbols are beautiful to look at,
but they don't help me read or write faster.
Once again: we're only talking about «
--- Ken Fox [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
The question is not about being ISO-phobic or pro-English. **
The two gripes I've heard have been:
1- It's hard to type.
2- I don't know how to type it on platform X.
With combo gripe It'll be hard to remember how to type it
Garrett Goebel wrote:
Can't we have our cake and eat it too? Give ASCII digraph or trigraph
alternatives for the incoming tide of Perl6 Unicode?
Allow both * and »*«?
I'd really prefer we didn't. I'd much rather keep and for other
things.
Or something similar '*', [*], etc...
Much as I
people on the list who can't be bothered to read
the documentation for their own keyboard IO system.
Most of this discussion seems to focus on keyboarding.
But that's of little consequence. This will always be
spotted before it does much harm and will affect just
one person and their software
On 04/11/02 12:12 -0800, [EMAIL PROTECTED]
aka Larry Wall wrote:
If you want trigraph support, you'll have to put
use encoding 'ugly-american';
at the top of your files. ;-) ;-) ;-)
Otherwise, it'll be one-character ?fancyops? all the way.
Mmm, I view one-character Unicode
--- Me [EMAIL PROTECTED] wrote:
people on the list who can't be bothered to read
the documentation for their own keyboard IO system.
Most of this discussion seems to focus on keyboarding.
But that's of little consequence. This will always be
spotted before it does much harm and will
--- Brian Ingerson [EMAIL PROTECTED] wrote:
FWIW, ebcdic *does* have the cent sign!
And the not sign. Damian may force us to abandon ASCII entirely...
=Austin
__
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
I'm having trouble this is even being considered. At all. And especially for
these operators...
So, yeah, include trigraph sequences if it will make happy the people
on the list who can't be bothered to read the documentation for their
own keyboard IO system.
But don't expect the rest of
There is a (partial) book-style chapter describing Perl6 values,
variables, and primitive/promoted types at:
http://cog.cognitivity.com/perl6/val.html
The entire thing is one page, for easy printing. It works out to about
15-20 pages, depending on your printer. There is *much* more coming
On Mon, Nov 04, 2002 at 12:26:56PM -0800, Austin Hastings wrote:
In short:
1- ? and ? are really useful in my context.
2- I can make my work environment generate them in one (modified)
keystroke.
3- I can make my home environment do likewise.
4- The ascii-only version isn't faster and
On Sun, Nov 03, 2002 at 11:17:32PM -0600, Me wrote:
I started with a simple thought:
is given($foo)
seems to jar with
given $foo { ... }
One pulls in the topic from outside and
calls it $foo, the other does the reverse --
it pulls in $foo from the outside and makes
it the
[EMAIL PROTECTED] (Ken Fox) writes:
The question is whether we want a pictographic language.
So far we've managed to avoid turning Perl into APL. :-)
-- Larry Wall in [EMAIL PROTECTED]
Although that was some time ago... :)
--
The FSF is not overly concerned about security. -
[EMAIL PROTECTED] (Damian Conway) writes:
Or something similar '*', [*], etc...
Much as I hate the notion of di- and trigraphs, this is a possibility.
I do like this too, because it reminds me of C trigraphs, which had precisely
the same purpose - allow people with old-fashioned sub-standard
--- Rafael Garcia-Suarez [EMAIL PROTECTED] wrote:
Austin Hastings wrote in perl.perl6.language :
What we've got is an encoding problem at the MUA level. Mark Reed
says
my mailer (Yahoo!) tagged a message containing high-bit characters
as
US-ASCII. Several people the other day reported
[EMAIL PROTECTED] (Austin Hastings) writes:
Yeah, but ActiveState does Perl, and Microsoft owns ActiveState
To what extent are *either* of those statements true? :)
--
All the good ones are taken.
Damian Conway wrote:
Larry Wall wrote:
That suggests to me that the circumlocution could be *.
A five character multiple symbol??? I guess that's the penalty for not
upgrading to something that can handle unicode.
Unless this is subtle humor, the Huffman encoding idea is getting
seriously
Ken Fox wrote:
Damian Conway wrote:
Larry Wall wrote:
That suggests to me that the circumlocution could be *.
A five character multiple symbol??? I guess that's the
penalty for not upgrading to something that can handle
unicode.
Unless this is subtle humor, the Huffman encoding
Garrett Goebel:
# Ken Fox wrote:
# Unless this is subtle humor, the Huffman encoding idea is getting
# seriously out of hand. That 5 char ASCII sequence is *identically*
# encoded when read by the human eye. Humans can probably type the 5
# char sequence faster too. How does Unicode win
This ¶ is a pilchrow, which shows up for me as one of those
paragraph-sign looking backwards P's with two vertical bars. Sorry if
it doesn't come out for you.
--- Brent Dax [EMAIL PROTECTED] wrote:
The Unicode version is more typing than the non-Unicode version, so
what's the advantage?
On Monday, November 4, 2002, at 08:55 AM, Brent Dax wrote:
# Can't we have our cake and eat it too? Give ASCII digraph or
# trigraph alternatives for the incoming tide of Perl6 Unicode?
The Unicode version is more typing than the non-Unicode version, so
what's the advantage? It's prettier?
Austin Hastings wrote:
The and ... are just as pictographic (or
not) as [ and ].
I'm not particularly fond of or either. ;) Damian just
wrote that he prefers non-alphabetic operators to help
differentiate nouns and verbs. I find it helpful when people
explain their biases like that. What's
On Monday, November 4, 2002, at 11:58 AM, Larry Wall wrote:
You know, separate streams in a for loop are not going to be that
common in practic, so maybe we should look around a little harder for
a supercomma that isn't a semicolon. Now *that* would be a big step
in reducing ambiguity...
Or
--- Simon Cozens [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Austin Hastings) writes:
Yeah, but ActiveState does Perl, and Microsoft owns ActiveState
To what extent are *either* of those statements true? :)
Hmm. Well, last time I checked you could still download a perl binary
from
--- Adam D. Lopresto [EMAIL PROTECTED] wrote:
I'm having trouble this is even being considered. At all. And
especially for these operators.
Heute vektoren, morgen das welt!
Uniperl, Uniperl uber alles,
Uber alles in der welt!
With hyper-states through choose and true();
Masterfully golf
On 04/11/02 14:09 -0800, Austin Hastings wrote:
--- Rafael Garcia-Suarez [EMAIL PROTECTED] wrote:
Austin Hastings wrote in perl.perl6.language :
What we've got is an encoding problem at the MUA level. Mark Reed
says
my mailer (Yahoo!) tagged a message containing high-bit
[EMAIL PROTECTED] (Austin Hastings) writes:
If @a [*=] @b; doesn't scan like rats chewing their way into your
cable, what does?
This is why God gave us functions as well as operators.
--
I _am_ pragmatic. That which works, works, and theory can go screw
itself.
- Linus Torvalds
The many recent suggestions for denoting vector operators all seem to
have problems, with some having significant impact elsewhere in the
language. After reading a few hundred mails on the subject I'm no
longer sure what I prefer, but thought I'd be in a better position to
have an opinion if I at
[EMAIL PROTECTED] (Smylers) writes:
Thank you very, very much for this; this is supremely helpful.
» No character left for eating whitespace.
That's a feature, not a bug! The space-eater alternately worries, confuses
and scares me.
--
I want you to know that I create nice things like
(naming) the invocant of a method involves
something very like (naming) the topic
Generally, there's no conceptual link...
other than
The similarity is that both are implicit
parameters
which was my point.
Almost the entirety of what I see as relevant
in the context of deciding
75 matches
Mail list logo
