PARROT_IN_EXTENSION

2006-01-30 Thread Nicholas Clark
has been included even earlier). The compile only works if I define PARROT_IN_EXTENSION myself (on the compiler command line) So what should be going on? Or am I missing something completely obvious? Nicholas Clark

Re: PARROT_IN_EXTENSION

2006-01-31 Thread Nicholas Clark
e that removes them. > > Hope this helps, Thanks, yes it did. It let me remove the hack to define PARROT_IN_EXTENSION in ponie's Configure.pl Nicholas Clark

Re: [perl #38348] [PATCH] Accept return values via a Continuation

2006-02-03 Thread Nicholas Clark
;ve no idea what the extra book-keeping overhead of this would be, and whether the savings would be big enough to pay for that overhead. Nicholas Clark

Re: A GraphViz eye view of Parrot

2006-02-03 Thread Nicholas Clark
rather old machines that act as X servers can actually provide. Maybe acrobat is also failing due to blowing some internal resource limits. Nicholas Clark

Re: A GraphViz eye view of Parrot

2006-02-05 Thread Nicholas Clark
on this reduces time spent on Punie. (And as I've not had occasion to say it before, thanks for all the time you're donating to Punie and the tools it creates) Nicholas Clark

Re: integer divide overflow

2006-02-10 Thread Nicholas Clark
nt $a / -1' Floating point exception (core dumped) which I never knew. Beware of assuming anything about signed integer arithmetic overflow - the vendor compiler on 64 bit Irix produces the arithmetic results that you'd expect from 2's complement, but subsequent comparisons with the result don't always "work" (eg you end up down the "wrong" side of if statements) and on Ahmdal mainframes (IIRC) MAX_INT + 1 is 0, not MIN_INT. Nicholas Clark

Re: early draft of I/O PDD

2006-03-05 Thread Nicholas Clark
nread() by pushing back a temporary buffer - this is more "peek" by "ungetc" than peek by really peeking. > be the default encoding for all data read in from a stream where a > layer's not added that explicitly states so? Ascii, binary? EBCDIC? Logically the default default is it's either compile time chosen "ASCII or EBCDIC" or "binary". Nicholas Clark

socket addresses (was Re: early draft of I/O PDD)

2006-03-05 Thread Nicholas Clark
a sufficiently flexible abstraction for address names. IPv4 and IPv6 both use addresses and port numbers. AF_LOCAL just uses a string, which is a file system path. But I think that specifying an op for just one address format is too narrow. Nicholas Clark

seek/tell (was Re: early draft of I/O PDD)

2006-03-05 Thread Nicholas Clark
unseekable file? What does tell return? IIRC sfio returned the number of bytes read (or written) for an unseekable file. Is that useful? Presumably seek() on a buffered stream discards any written but not flushed data. Mmm. Flush opcode needed for buffered streams? Nicholas Clark

basic file IO (was Re: early draft of I/O PDD)

2006-03-05 Thread Nicholas Clark
if miniparrot is built by layering Parrot IO onto C's stdio. 3STAT_ISDEV Whether the file is a device such as a terminal or a disk. Don't we need to get more flexible than this? At least file/terminal/socket/character special/block special/fifo/symlink/door Nicholas Clark

Re: early draft of I/O PDD

2006-03-05 Thread Nicholas Clark
e marked as "cacheable" and the JIT can see a cacheable function taking only constants, and hence constant fold it) Nicholas Clark

Re: early draft of I/O PDD

2006-03-05 Thread Nicholas Clark
On Sun, Mar 05, 2006 at 02:53:29PM -0600, Joshua Isom wrote: > > On Mar 5, 2006, at 1:46 PM, Nicholas Clark wrote: > > >On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote: > > > >Should the network opcodes even be loaded as standard? C et al > >aren&

Re: early draft of I/O PDD

2006-03-06 Thread Nicholas Clark
s to fnctl or ioctl given. Specifically it would be useful to have a way to set handles non-blocking (and have the entire IO system cope with synchronous-but-non-blocking IO, even if async IO is more powerful still) Nicholas Clark

Re: early draft of I/O PDD

2006-03-11 Thread Nicholas Clark
n") # throw exception on failure Oooh. Useful. >* C returns a string representing a socket address >[Nicholas] "I don't think that this is appropriate. It's IPv4 > specific." > > A more general SocketAddr PMC seems to be needed here. I think someone else said it too, but more a SocketAddr PMC hierarchy? At least, a PMC class for each distinct way of describing addresses, that all fulfil a SocketAddr role. Nicholas Clark

Re: early draft of I/O PDD

2006-03-14 Thread Nicholas Clark
than a call to C? If not, > there's probably a simpler way to handle it. >From memory, socket addresses show up as results from C, C, C and C/C, and are also used as arguments to C/C Nicholas Clark

Re: basic file IO (was Re: early draft of I/O PDD)

2006-03-14 Thread Nicholas Clark
On Sun, Mar 05, 2006 at 07:11:59PM +, Nicholas Clark wrote: > =item * > > C retrieves information about a file on the filesystem. It takes a > string filename or an integer argument of a UNIX file descriptor, and an > integer flag for the type of information reques

Re: early draft of I/O PDD

2006-03-18 Thread Nicholas Clark
On Fri, Mar 17, 2006 at 06:40:32PM -0800, Allison Randal wrote: > On Mar 6, 2006, at 4:06, Nicholas Clark wrote: > > >On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote: > > > > =head2 Network I/O Opcodes > > > > > >Functionality wise, th

Re: [svn:parrot-pdd] r11923 - in trunk: . docs/pdds/clip

2006-03-19 Thread Nicholas Clark
#define AF_INET 2 /* internetwork: UDP, TCP, etc. */ #define AF_INET628 /* IPv6 */ What about #define AF_UNIX 1 /* standardized name for AF_LOCAL */ ? (of the rest, this is the most widely used) Nicholas Clark

Re: second draft of I/O PDD

2006-03-19 Thread Nicholas Clark
t us just write the first implementation, and allow people to write platform specific optimisations later? Nicholas Clark

Re: [perl #32642] [TODO] Remove Perl* PMCs from parrot's basic PMCs, src and languages

2006-04-07 Thread Nicholas Clark
On Thu, Apr 06, 2006 at 02:17:21PM -0700, chromatic wrote: > On Thursday 06 April 2006 14:04, Bernhard Schmalhofer via RT wrote: > > > 'punie' seems to be the only maintained language implementation using > > Perl* PMCs. > > What about Ponie? Ponie isn't using them. Nicholas Clark

Re: [svn:parrot] r12129 - trunk/src

2006-04-07 Thread Nicholas Clark
with the temporary on the stack it doesn't get garbage collected. This is a hunch. But as far as I can make out there is no semantic difference in the change you made to the C, so it should not have changed anything. Nicholas Clark

Re: Duplicated code

2006-04-08 Thread Nicholas Clark
xx/xxx.pl" at the top. Maybe it's better to run it on a fresh checkout of the parrot source code, rather than a built tree. Nicholas Clark

Re: [perl #38896] [TODO] Integer PMC missing math methods.

2006-04-11 Thread Nicholas Clark
r" when asked what type it is, because the internal representation would be a mere implementation detail. But I'd expect a type .Float to behave much like a C float and coerce values fed to it, rather than metamorphose to their type. Was this built in morphing the cause of the problems Leo was describing in trying to make a user defined class that is derived from Int? Nicholas Clark

Re: [svn:parrot] r12129 - trunk/src

2006-04-11 Thread Nicholas Clark
On Tue, Apr 11, 2006 at 06:15:32PM +0200, Leopold Toetsch wrote: > > On Apr 7, 2006, at 19:38, Nicholas Clark wrote: > > >>-STRING *fill = CONST_STRING(interpreter, info->flags & > >>FLAG_ZERO ? "0" : " "); > > > >

Re: [perl #38931] [RFE] Double-quoted strings automatically determine string type

2006-04-16 Thread Nicholas Clark
; when encountering a string literal with bytes outside the range 0-127. If so, then I assume that the behaviour of your second example is wrong - it should also be a malformed string. If PGE is always outputting UTF-8 literals, what stops it from always prefixing every literal "unicode:", even if it only uses Unicode characters 0 to 127? Nicholas Clark

Re: [perl #38931] [RFE] Double-quoted strings automatically determine string type

2006-04-16 Thread Nicholas Clark
width from the other 2. (That's before you get to special cases such as Greek sigma) Presumably therefore Dan's view was that while constants to the assembler might well be fed in as UTF-8, the generated bytecode should be using the tersest fixed width it can. I can see sense in this. Nicholas Clark

Re: [perl #39142] [TODO] pmc2c.pl doesn't allow mixed case groups/pmc filenames.

2006-05-17 Thread Nicholas Clark
properly > setup the PMCs during 'loadlib'. > > pmc2c.pl should be case agnostic for both group names *and* pmc file > names. Case agnostic at a Unicode level? Nicholas Clark -- I'm looking for a job: http://www.ccl4.org/~nick/CV.html

Re: languages/ Cleanup

2006-05-27 Thread Nicholas Clark
control history is added to a Changes file, which has each commit message along with the perforce revision number. It makes it very easy to search for these sorts of things. I assume that it's trivial to automate the generation of such a file for subversion, if it's desired. Nicholas Clark -- I'm looking for a job: http://www.ccl4.org/~nick/CV.html

Re: lexical lookup and OUTER::

2006-06-24 Thread Nicholas Clark
esn't mean that I wouldn't like an opcode to do it for > me. :-) Is Parrot assembler considered a more productive language to write in than C? If yes, is it logical to write opcodes such as this one in Parrot assembler itself? Nicholas Clark

Re: lexical lookup and OUTER::

2006-06-24 Thread Nicholas Clark
On Sat, Jun 24, 2006 at 10:41:44AM -0500, Patrick R. Michaud wrote: > On Sat, Jun 24, 2006 at 08:03:47AM -0700, Audrey Tang wrote: > > 2006/6/24, Nicholas Clark <[EMAIL PROTECTED]>: > > >Is Parrot assembler considered a more productive language to write in than > >

Re: Parrot Platform API

2006-06-26 Thread Nicholas Clark
ing it might be a little while before he gets a chance to read any of his e-mail. Nicholas Clark

Re: Cage Cleaning for dummies? Re: Call for Parrot Janitors

2006-07-05 Thread Nicholas Clark
r surprising unwary source code. And something (Amdahl mainframes?) aren't 2's complement. Nicholas Clark

Re: [CAGE] Coverity and Splint: Has anyone started using these with Parrot?

2006-07-18 Thread Nicholas Clark
n all use it. config/auto/gcc.pm has logic to enable gcc warnings by gcc version. At one time we had more warnings on that we do now. Turning the alignment warnings on gets "interesting" (for a very noisy value of interesting) on architectures less forgiving than x86, such as sparc. Nicholas Clark

Re: Inf and NaN

2006-07-31 Thread Nicholas Clark
On Sun, Jul 30, 2006 at 10:45:29PM -0700, jerry gay wrote: > don't forget about negative-not-a-number, and the quiet (or signaling) Ah yes. that oxymoron. I've never yet seen the reasons for why it exists at all. Does anyone have a URL? Nicholas Clark

Re: async i/o (was Re: RFC 310 (v1) Ordered bytecode)

2000-09-27 Thread Nicholas Clark
have Solaris here, so I can't try this The alternative approach to figuring out what is happening is to write a program with AIO, and see what it looks like under truss. truss is your friend :-) Hmm. But solaris doesn't ship with a compiler, does it? Nicholas Clark

Re: RFC 334 (v1) Perl should allow specially attributed subs to be called as C functions

2000-09-29 Thread Nicholas Clark
ils/typemap? If so, will there be the "terse" column in the typemap file to associate "i" with "T_IV" ? To me it would seem sensible to define the mapping from perl to C types and from C to perl types just once, and use it both for calling external libraries, and for being called by external things Nicholas Clark

Re: RFC 334 (v1) Perl should allow specially attributed subs to be called as C functions

2000-09-29 Thread Nicholas Clark
On Fri, Sep 29, 2000 at 12:37:15PM -0400, Dan Sugalski wrote: > At 04:13 PM 9/29/00 +0100, Nicholas Clark wrote: > >Are you suggesting that the attributes use the same mapping system as > >the XS (or son-of-XS (XS++)) typemaps in lib/ExtUtils/typemap? > >If so, will there be

Re: data storage and representation when designing bytecode (and VM)

2000-10-02 Thread Nicholas Clark
ASCII Then reader can fall back to parsing in the ASCII if the binary isn't edible. Nicholas Clark

Re: data storage and representation when designing bytecode (and VM)

2000-10-03 Thread Nicholas Clark
as it goes along, rather than bytecode being a reverse engineering of package symbol tables. Nicholas Clark

Re: data storage and representation when designing bytecode (and VM)

2000-10-03 Thread Nicholas Clark
On Tue, Oct 03, 2000 at 12:27:03PM -0500, Jarkko Hietaniemi wrote: > On Tue, Oct 03, 2000 at 05:32:48PM +0100, Nicholas Clark wrote: > > Were you thinking that p6 bytecode has 2 functions > > > > 1: putting a perl virtual machine into suspended animation (or cloning i

Re: data storage and representation when designing bytecode (and VM)

2000-10-03 Thread Nicholas Clark
On Tue, Oct 03, 2000 at 02:38:01PM -0400, Dan Sugalski wrote: > At 06:42 PM 10/3/00 +0100, Nicholas Clark wrote: > >But I seem to remember someone who should know (Tom Christiansen?) at > >YAPC::Europe being confident that bytecode would never be faster. > > Really? I t

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

2000-10-13 Thread Nicholas Clark
ou can do is something like (void *, ...). (Perl_Interpreter *, ...) surely? [Having seen the pTHX_ appear all over perl5] Nicholas Clark

Re: Perl's parser and lexer will likely be in Perl (was Re: RFC 334 (v1) I'm {STILL} trying to understand this...)

2000-10-17 Thread Nicholas Clark
e very doable. To allow the lexer to influence the tokeniser, what characters are we going to use in (? ) for smoke and mirrors extensions? (?s) and (?m) are already taken. [Seriously, I was under the impression that the perl tokenizer was influenced by the state of the lexer] Nicholas Clark

Re: Perl's parser and lexer will likely be in Perl (was Re: RFC 334 (v1) I'm {STILL} trying to understand this...)

2000-10-17 Thread Nicholas Clark
. Hence if perl6 contains a generic parser powerful enough to parse perl (if this can be done), to me this would suggest that it would allow a lot of other people to use it to rapidly implement parsers for just about anything else. Nicholas Clark

Re: [not quite an RFC] shared bytecode/optree

2000-10-25 Thread Nicholas Clark
r) and MOVing them to the PC, or loading the PC from a branch table in memory. Nicholas Clark

Re: [not quite an RFC] shared bytecode/optree

2000-10-25 Thread Nicholas Clark
On Wed, Oct 25, 2000 at 12:05:22PM -0400, Dan Sugalski wrote: > At 05:02 PM 10/25/00 +0100, Nicholas Clark wrote: > >On Wed, Oct 25, 2000 at 11:45:54AM -0400, Chaim Frenkel wrote: > > > I vaguly can see a TIL that uses machine code linkage (real machine code > > > ju

Re: [not quite an RFC] shared bytecode/optree

2000-10-25 Thread Nicholas Clark
On Wed, Oct 25, 2000 at 12:28:55PM -0400, Dan Sugalski wrote: > At 05:21 PM 10/25/00 +0100, Nicholas Clark wrote: > >"fixup sections" sound horribly like something I've read in association > >with a.out or ELF shared libraries. (I forget which) > > Both, th

Re: [not quite an RFC] shared bytecode/optree

2000-10-25 Thread Nicholas Clark
means fixup unshared bytecode > at load time (or page fault time, or whatever). :-) I thought so far we'd only had "use more". I like "use less" and what it offers us: use English; can be replaced with use less "line noise"; :-) Nicholas Clark

Re: [not quite an RFC] shared bytecode/optree

2000-10-25 Thread Nicholas Clark
On Wed, Oct 25, 2000 at 06:23:20PM +0100, Tom Hughes wrote: > In message <[EMAIL PROTECTED]> > Nicholas Clark <[EMAIL PROTECTED]> wrote: > > > Specific example where you can't: > > on ARM, the branch instructions (B and BL) are PC relative, but on

SvPV*

2000-11-21 Thread Nicholas Clark
ld mean things like $a=$b wouldn't actually copy anything (wasting time and (shared) memory pages) until either $a or $b got changed. [I have this feeling that there's a bit of this already in sv.c, but I'm not sure how much] Nicholas Clark

Re: SvPV*

2000-11-22 Thread Nicholas Clark
token is needed. How about `\C' for chunk? Or is this > already taken? \C Match a single C char (octet) even under utf8. however, with UTF we now have thousands more glyphs to use as escapes in regexp :-) [aargh. I'm off topic for this list] > Hmm, what about string comparisions? `eq' and friends should simply > conmtinue to work as usual on the string contents. Do we need some > kind of meta-eq to be able to compare the attribs also? I think that that becomes a method call on one of the scalars. Nicholas Clark

Re: SvPV*

2000-11-22 Thread Nicholas Clark
with the code for this. > > Agreed. How does the regexp replacement engine cope with this? By implementing all replacements as substr() type ops? [or behaving as if it implements... whilst cheating and doing it direct for scalars it understands?] Or don't we need to work this out at this time? Nicholas Clark

Re: SvPV*

2000-11-22 Thread Nicholas Clark
its value Are those end members in a continuum? or are hybrids of the 2 impossible? Am I barking up the wrong tree completely? Nicholas Clark

Re: Guidelines for internals proposals and documentation

2000-11-15 Thread Nicholas Clark
cess. I'm uncomfortable leaving such decisions > to such a small number of people. How about nominating/electing a If PDDs start as "Proposed" without needing any approval does this remove the problem of a small group having a stranglehold? Nicholas Clark

Re: Opcodes (was Re: The external interface for the parser piece)

2000-11-30 Thread Nicholas Clark
mpting to make pp_add in perl5 do this sort of thing, so I may be missing a better way of doing it] > But that probably doesn't help much. Let me throw together something more > detailed and we'll see where we go from there. Hopefully it will cover the above case too. Nicholas Clark

Re: Proposal for groups

2000-12-03 Thread Nicholas Clark
ist Scientist and the Church of the Latter Day Saints in your list of organisations. Do we need a sub list perl6-conspiracy-theories so that we can keep the main lists free for other discussions? Nicholas Clark

Re: Meta-design

2000-12-06 Thread Nicholas Clark
nks that perl5 Configure found (for our information on user platforms) (void flags, volatile, const, headers absent, functions absent) ] Nicholas Clark

Re: Meta-design

2000-12-06 Thread Nicholas Clark
ing useful for someone to maintain on the meta-design list. (Is maintaining such a document an "apprentice" job? (see perl6-meta)) Nicholas Clark

Re: Meta-design

2000-12-06 Thread Nicholas Clark
On Wed, Dec 06, 2000 at 01:15:07PM -0500, Dan Sugalski wrote: > What I'm thinking is that we'll have a scoped destruct stack that gets > pointers to variables that explicitly need destruction, and as we exit > levels of scope we call the destructors of those variables that need it. > (They can

Re: Perl6 in Java? (was Re: Meta-design)

2000-12-07 Thread Nicholas Clark
(or anything else for that matter), just that I'd feel we'll have a more portable design if we don't constrain our choices now] Nicholas Clark

Re: Meta-design

2000-12-07 Thread Nicholas Clark
27;t pick up squirrels. The pointed end bites] Not that that's important. But fflush(NULL) is, and we still seem to run into that one on one current platform But I agree with what you're saying. Nicholas Clark

Re: Opcodes (was Re: The external interface for the parser piece)

2000-12-07 Thread Nicholas Clark
essing that Dan is planning to take advantage of addition and multiplication being commutative. sv1->add[UNKNOWN](sv2) swaps to sv2->add[NUM](sv1) (It's "obvious" in the usual way - not obvious until you see it. I've been prodding in pp_add in perl5, so I've been thinking about these sort of things) Nicholas Clark

Re: Guaranteed object destruction (was Re: Meta-design)

2000-12-07 Thread Nicholas Clark
st reference, and turn any other references to it to dust (or undef)) SMITE is hard work if you're not omniscient, as you have to go round searching for everyone who might refer to it, or fake it by holding a back reference to everyone who references you. Nicholas Clark

Re: Meta-design

2000-12-07 Thread Nicholas Clark
its lessons? Probably more useful than backwards-forwards polite, well reasoned but ultimately theoretical arguments. [Was it medieval scientists who preferred reasoning to experiments?] Nicholas Clark

Re: Opcodes (was Re: The external interface for the parser piece)

2000-12-12 Thread Nicholas Clark
7;t make it faster, just claws back the slowdown other parts of my provisional changes have made] hangon, there was a point that was supposed to back up. Accuracy is needed, but I fear that a single general scheme to deliver this will slow down the common cases. Nicholas Clark

Re: Opcodes (was Re: The external interface for the parser piece)

2000-12-12 Thread Nicholas Clark
On Tue, Dec 12, 2000 at 06:05:30PM +, David Mitchell wrote: > Nicholas Clark <[EMAIL PROTECTED]> wrote: > > On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote: > > > If we assume that ints and nums are perl builtins, and that some people > > &g

Re: Opcodes (was Re: The external interface for the parser piece)

2000-12-13 Thread Nicholas Clark
ess $c has overloaded = this is probably a language issue, and waiting on the language spec Nicholas Clark

Re: String representation

2000-12-18 Thread Nicholas Clark
e substitution part of regex could easily be re-expressed as a series of substr operations. This doesn't answer the real challenge which is matching. Nicholas Clark

Re: String representation

2000-12-18 Thread Nicholas Clark
ake longer because we're doing it less efficiently. Just a passing thought. Extrapolated up from 1 RISC CPU I know quite well. Nicholas Clark

Re: String representation

2000-12-19 Thread Nicholas Clark
arsers than I do. (I know nothing, so I try to keep quiet) Nicholas Clark

Re: mixed numeric and string SVs.

2000-12-20 Thread Nicholas Clark
LL (or "string") or something token but different from all real numbers if the scalar isn't a number, which will prompt numeric conversion to the best sort of number as need-be. (so "3.1 + 5i" would do the right thing. presumably complex floating point) And (like perl5) if you alter a numeric scalar as a string, it becomes just a string [so {(3.1 + 5i) . ''} is a string] Nicholas Clark

Re: mixed numeric and string SVs.

2000-12-20 Thread Nicholas Clark
On Wed, Dec 20, 2000 at 09:00:47AM -0600, Jarkko Hietaniemi wrote: > struct { > IV whatitis; more a perl5 question - why IV not int? int might be smaller and "more natural" (your words) eg why does looks_like_number return IV not int? and various other bits of the perl API u

Re: mixed numeric and string SVs.

2000-12-20 Thread Nicholas Clark
th TomC and Ilya would agree on something - that this is not desirable behaviour (TomC because it's not backwards compatible, Ilya because you can alter a scalar's value as a side effect of accessing it, so what a scalar appears to contain becomes a function of its access history, not simply and solely what you assigned to it) Nicholas Clark

Re: String representation

2000-12-21 Thread Nicholas Clark
e may not be 1 top to the tree (at least for builtin numbers). Which may also hold for strings. > We old'ns need people that don't know "it can't be done" to tell us > how to do it - but we reserve the right to say "we tried that it didn't > work" too. ^ because Nicholas Clark

Re: String representation

2000-12-21 Thread Nicholas Clark
On Thu, Dec 21, 2000 at 05:36:05PM +, Nick Ing-Simmons wrote: > Nicholas Clark <[EMAIL PROTECTED]> writes: > >> > >> where it is possible to get "smart" when one arg is a "special case" of > >> the other. > > > >>

Re: Perl 6 compiling Perl 6?

2000-12-22 Thread Nicholas Clark
ight take quite a lot of perl5 messy guts hacking to make perl5's compiler good enough to bootstrap a clean perl6 compiler to compile the perl systems to a binary. Nicholas Clark

Re: Perl6 compatibility with non-C enviornments (was Re: Perl6 in Java? (was Re: Meta-design))

2000-12-08 Thread Nicholas Clark
ngs possible. We seem to be arguing about the best method for making it *im*possible to use anything but the initially-chosen-implementation language to implement perl. This feels like a bad thing. Nicholas Clark

Re: standard representations

2001-01-05 Thread Nicholas Clark
the compiler couldn't do native 32 bits. Nicholas Clark

Re: Anyone want to take a shot at the PerlIO PDD?

2001-01-05 Thread Nicholas Clark
'I/O complete' marker so async I/O > will work out properly. Nicholas Clark

Re: standard representations

2001-01-05 Thread Nicholas Clark
e > >portable part of perl6 will have now idea how far it can go > >with native numbers. > > Yes, they will. Each chip family, at least. I'm thinking we'll have a > generic CHECK_OVERFLOW macro that's redefined on a per-CPU basis and > handled by whoever's doing the port for that system, with some generic Were you (both) meaning integer, floating point, or both sorts of overflow detection here? Nicholas Clark

safe signals (was Re: perl IS an event loop (was Re: Speaking of signals...))

2001-01-06 Thread Nicholas Clark
ndlers other than default or ignore assigned to it. Would that be an acceptable perl5 compromise? [follow up to p5p please] Nicholas Clark

Re: Speaking of signals...

2001-01-09 Thread Nicholas Clark
eir new equivalent) as buffers for the IO system rather than plain pointers and lengths, then I'd consider it sensible to consider this design goal met if async i/o subsystem has a dependency on the scalar buffer subsystem (or at least one part of it, as SVs in turn might make requirements on memory allocation APIs). That's still not the whole perl runtime though. Nicholas Clark

Re: AIO and threads - my prejudices

2001-01-20 Thread Nicholas Clark
going to do this for the general case) (java does do it, but as it's all going through Java's windowing library, the implementation know where the windowing system calls are going to be) Upshot is that threading can be written if need be, so that's one less (admittedly now obscure) platform that isn't excluded by threading. Nicholas Clark

Re: PDD 2, vtables

2001-02-07 Thread Nicholas Clark
been suggested, with the speed up hack for the common case. Nicholas Clark

Re: PDD 2, vtables

2001-02-07 Thread Nicholas Clark
On Wed, Feb 07, 2001 at 05:19:16PM +, David Mitchell wrote: > Nicholas Clark <[EMAIL PROTECTED]> mused: > > On Wed, Feb 07, 2001 at 04:03:49PM +, David Mitchell wrote: > > > BTW, should the vtable include all the mutator operators too, ie > > > ++, +=

Re: PDD 2, vtables

2001-02-07 Thread Nicholas Clark
the inside of another integer scalar looks like, and that 2 + 3 doesn't overflow. Hmm. += isn't another opcode it's a special case of a = b + c where the PMCs for a and b are the same thing. And I see no real reason why it can't be part of the + entry. Nicholas Clark

Re: PDD 2, vtables

2001-02-08 Thread Nicholas Clark
On Wed, Feb 07, 2001 at 01:24:27PM -0500, Dan Sugalski wrote: > At 06:12 PM 2/7/2001 +0000, Nicholas Clark wrote: > >But I don't like the thought of going in and out of a lot of generic > >routines for > > > >$a = 3; > >$a += 2; > > > >when t

Re: Generating Perl 6 source with Perl

2001-02-16 Thread Nicholas Clark
like the idea of making the bootstrap process more of a "microperl followed by configure probing written as a perl script" rather than "complex shell scripts followed by miniperl and a few Makefile.PLs", which is one of the possibilities having perl5 around would offer. Nicholas Clark

Re: Generating Perl 6 source with Perl

2001-02-17 Thread Nicholas Clark
he system-specific crap wouldn't show up in > the generated C files, so they'd actually be *easier* to handle. Cool. I'd been failing to understand that the intent was to make human readable C files (as opposed to obfuscation for cpp) Nicholas Clark

Re: PDD for code comments ????

2001-02-20 Thread Nicholas Clark
ssent to everything I have ever said or > will ever say. ;-) I don't think "will ever say" holds. And I think I'd phrase it as "ongoing silence". But apart from that, it seems to be a working assumption for design proposals. Nicholas Clark

Re: Tolkein (was Re: PDD for code comments ????)

2001-02-20 Thread Nicholas Clark
7;t in danger yet. However, Larry has already commented on the danger of running out of LOTR quotes: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-02/msg00369.html Nicholas Clark

Re: Questions about PDD 4: Internal data types

2001-03-02 Thread Nicholas Clark
s us anything in terms of speed. If that turns out to be wrong, > I'm all for changing it. At the risk of contagious MACRO-itis might it be an idea to define clear macros to get this information out? That way it is possible to change the underlying representation from something packed to unpacked whenever it seems appropriate without breaking anything that plays by the rules. Nicholas Clark

Re: PDD 4: Internal data types

2001-03-02 Thread Nicholas Clark
me points it becomes necessary to have an unsigned type for "the largest integer" which in this case would be 72 bits. [and on a machine with nothing larger than 32 will be 32] The type that used to be known as "unsigned long" [before "unsigned long long" appeared on some machines and made life confusing] Nicholas Clark

Re: PDD 4: Internal data types

2001-03-08 Thread Nicholas Clark
signed integers overflow. It's undefined by ANSI, so it's legal. (Thanks Helmut for persevering until we tracked this one down) Nicholas Clark

Re: PDD 4: Internal data types

2001-03-08 Thread Nicholas Clark
On Thu, Mar 08, 2001 at 01:55:57PM -0500, Dan Sugalski wrote: > At 06:49 PM 3/8/2001 +0000, Nicholas Clark wrote: > >On Thu, Mar 08, 2001 at 11:43:31AM -0500, Dan Sugalski wrote: > > > I was thinking maybe (length/4)*31-bit 2s complement to make portable > > > overflow

Re: PDD 4: Internal data types

2001-03-08 Thread Nicholas Clark
bove work on 64 bit Irix? The overflow in c = a + b is undefined behaviour in C. Irix gave the bit value that was expected, but didn't execute subsequence > conditions in the way that would be expected by an assembly programmer. [However, I like the elegant sign bit testing logic you give.] Nicholas Clark

Re: PDD 4: Internal data types

2001-03-08 Thread Nicholas Clark
On Thu, Mar 08, 2001 at 04:28:48PM -0500, Dan Sugalski wrote: > At 08:43 PM 3/8/2001 +0000, Nicholas Clark wrote: > I think most processors that do 32x32 multiply provide a way to get the > 64-bit result. Whether *we* can is another matter, of course, but if > platform folks wan

Re: Unicode handling

2001-03-22 Thread Nicholas Clark
the original UTF8 and a (cached copy) normalized form but at this point I'll shut up as I expect I'm ignorant of an RFC on how this works without hitting either of the above problems. Nicholas Clark

Re: Unicode handling

2001-03-23 Thread Nicholas Clark
8 bit xterm. Let alone some crufty 7 bit serial login. I think it would be a bad thing to effectively mandate that to use certain features you had to use a Unicode aware editing system Nicholas Clark

Re: Perl_foo() vs foo() etc

2001-04-13 Thread Nicholas Clark
nkers. Presumably there are internal functions that aren't part of the public API, but because they are used in more than 1 source file do need external linkage. Or were your "linkers are dead-stupid" words meaning that we can't tell linkers to partially link libperl.a and then declare a whole bunch of symbols that now can't be used for any purpose external to libperl.a Nicholas Clark

<    4   5   6   7   8   9   10   >