than read (cf sfio).
"win32" layer that does IO straight to Handle level rather than via
MS's idea of how UNIX read/write work.
--
Nick Ing-Simmons
Uri Guttman <[EMAIL PROTECTED]> writes:
>>>>>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
>
>
> NI> I have guts of a stack-of-layers PerlIO scheme coded now
> NI> (//depot/perlio/... for those with perforce access - merg
ht now we _have_ to copy it as there is no way to tell perl
to (say) XFree() it rather than Safefree() it. Which is a pain when data
is big.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
as lasted so well
because the initial guess at the short/common opcodes was not too bad.
But the escape bytes are getting out of hand now...
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
f pos on file handles being fsetpos/fgetpos
>Maybe that should have been an rfc 3 months ago, and really doesn't even
>matter if perlio obsoletes stdio and internalises stdio's distinction between
>text and binary streams.
>
>BTW I am serious about needing a /gc not to c
Tom Hughes <[EMAIL PROTECTED]> writes:
>In message <[EMAIL PROTECTED]>
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
>> At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
>>
>> >FILE * is not a good idea. PerlIO * is fine.
>>
>
gth of the source to be read followed by the source. If set to
>> > PERL_FILE_SOURCE it's assumed to be a FILE *, while if set to
FILE * is not a good idea. PerlIO * is fine.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
care) by asking them.
>
>This only applies to external APIs. Internal APIs may well benefit from
>counted length systems
Sure we may as well re-use whatever-replaces-SV rather than invent
another counted string type.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
be separate parameters at this point - then we can decide
how best to group them and provide wrapper(s) that call the zillion
parameter version. If there turns out to be only one sensible wrapper
then it can become _the_ interface.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
o aware that I am not skilled in teaching - usually because I don't
know what is obvious vs what is obscure - so anyone "taught" by me
has to ask questions rather than be lectured to.
--
Nick Ing-Simmons
on?
>
>I supect the answers are yes and no.
I suspect the answers are "no" and (2) is eliminated as "dead code" ;-)
>
>Dave.
--
Nick Ing-Simmons
en be free to add
>variants for custom string types.
I would argue one does that by making the regex API more modular.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
t of wchar_t is subset of UNICODE.
The "Native-single-byte" would have one - global-to-interpreter
encoding object - not just iso8859-1 - basically the one that LC_CTYPE
gives the "right answers for" - though how the "£!$^¬!*% one is supposed
to find that out is beyond m
the
enormous_int ** complex_rational problem.
if ("N{gamma}".title_case(join($klingon,@welsh)) =~ /$urdu/)
who's operators get called ?
--
Nick Ing-Simmons
that "strings" are would fill the data cache much more quickly.
>
>Just a passing thought. Extrapolated up from 1 RISC CPU I know quite well.
>
>Nicholas Clark
--
Nick Ing-Simmons
David Mitchell <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
>> What are string functions in your view?
>> m//
>> s///
>> join()
>> substr
>> index
>> lc, lcfirst, ...
>> & | ~
>&
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>On Mon, Dec 18, 2000 at 03:21:05PM +0000, Nick Ing-Simmons wrote:
>> Simon Cozens <[EMAIL PROTECTED]> writes:
>> >
>> >So, before we start even thinking about what we need, it's time to look at the
>>
achine - all the language stuff is in the "data" part.
But switching lexer and parser's look-ahead "token" at language
boundaries is a tad tricky. But that is probably not what is being discussed
here.
(Nick just passing through...)
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
formal methods for writing such a "partial programs are acceptable"
>parser.
>
>
>Lisp-like languages handle this, but s-expressions are so trivial to parse
>that it's no help to simply "follow" their example.
So does Tcl - but it is also trivial to "pa
} {
set command "$name$suffix"
upvar $command [expr $level-2]
set command "$command {$value}"
set $command
}
messy foo "[$index]" 3 {expr $command+1}
That "obviously" compiles to the bytecode for
$foo{$index}++
;-)
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
nting messages can be surprisingly slow - if they go to
unbuffered stderr which is an X window of some kind they can end up
waiting for an ACK from the X server, which may have to wait for
blanking and a move of a mega-pixel or two to do a scroll.
>
>Perceived slowness is also important.
l string to numeric conversions should return
>a particular numeric type (eg NV), and that all numeric to string
>conversions should similary convert to a fixed string type (eg utf8).
>(Although I'm not sure that really helps.)
I can't see how that helps.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
nly for fear of irritating people who know what
>they are talking about, and who have to take time out to explain to me why I'm
>wrong! On the other hand, I do seem to have ended up taking a lot about
>this subject on perl6-internals!!
>So, should I have the courage of my convictions and let rip, or should I
>just leave this to wiser people? Answers on a postcard, please
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.
--
Nick Ing-Simmons
Philip Newton <[EMAIL PROTECTED]> writes:
>On 18 Dec 00, at 15:21, Nick Ing-Simmons wrote:
>
>> There needs to be a hierachy of _repertoires_ such that:
>>
>> ASCII is subset of Native is subset of wchar_t is subset of UNICODE.
>
>But we can't even rely
at
>optionally create a subsidiary string SV, then pass the call onto that
>object.
>
>Or to avoid the conditional each time, there could be 2 vtables for each
>type, containing 'with subsidiary' and 'without subsidiary' methods;
>the role of the latter being to create the subsidiary SV and update the
>type of the main SV to the 'with subsidiary' type.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
ople 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
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
(and the native form might be one of them) but as far as the
>interface is concerned we have only three. Yes, this does mean if we mess
>with strings in UTF-8 format on a non-UTF-8 system they'll need to be fed
>out in UTF-32. It's bigger, but we can deal.
--
Nick Ing-Simmons
, and that's where we want things to be in a platform convenient size.
>
>I honestly can't think of any reason why the internal representation of an
>integer matters to the outside world, but if someone can, do please
>enlighten me. :)
I can't think of anything except the range that is affected by the
representation.
--
Nick Ing-Simmons
Int for its "mantissa" and have another
int-of-some-kind as its exponent. We don't need to pack it tightly
so we should probably avoid IEEE-like hidden MSB. The size of exponent
is one area where "known range of int" is important.
--
Nick Ing-Simmons
those and sqrt() etc. is that the published algorithms
"know" how many terms of power series are needed to reach (say) IEEE-754
"double".
Thus a "big float" still needs to decide how precise it is going to
be or atan2(1,1)*4 (aka PI) is going to take a while to compute...
--
Nick Ing-Simmons
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 01:05 PM 12/29/00 +0000, Nick Ing-Simmons wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> writes:
>> >
>> >I'm reasonably certain that all platforms that perl will ultimately run on
>> >can muster hardwa
ry about
>
>Yeak, I know a lot of the old 8 and 16 bit chips are in use as control
>devices places. Those are the ones I'm thinking about. (Not that hard, but
>I don't want to rule them out needlessly)
I suspect that any that are up to running anything approximating perl
will have 32-bit ops in a library in any case.
>
--
Nick Ing-Simmons
take a while...)
I am willing to cast bleadperl5's PerlIO into the form of a _draft_ PDD
for perl6 - i.e. "this is what it does now", not "this is what it should do".
Then we can discuss it here some more.
--
Nick Ing-Simmons
somehow the next op delivered
>will be the next baseline op or the dispatch check op. that is basically
>the same as my ideas above, just a different style loop.
What I am trying to get to is adding minimal extra tests to the tight loop.
We probably need at least ONE test in the loop - let us
x27;t 2's complement for the mantissa.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
he key is not
>> checking all events on each pass thru the loop.
>
>Which is exactly what Chip did in his safe-signals patch. 33% slowdown.
I don't believe it - can we add a stub test and bench mark it?
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
ing the whole IO system, I'd
>probably be assaulting sv_gets to make up for the speed hit I introduced
>way back with the record reading code...)
Nick has yet to touch sv_gets() - partly 'cos it was too scary to mess
with - so you can if you like ;-)
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
status to pass to wait() when it did get called.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
ld develop a tool that works in the source code level and
>does the inlining of functions for us. I mean a perl program that opens the
>C/C++ source of the kernel, looks for pre-defined functions that should be
>inlined, and outputs processed C/C++ in ``spaghetti-style'', very mes
sue?
5.6.0 has serious snags with OO packages not designed to work
round its oddities.
--
Nick Ing-Simmons
ther arrangements with Larry.
>
>They certainly didn't do a, b, or c. So that leaves d.
And Larry's take could be considered that they had to provide manpower
to assist in merge
--
Nick Ing-Simmons
unity, not only to grant rights, but to say once and for all that
>we cannot tolerate abuse of those desires and our kind and generous
>spirit.
I think it will be very hard to get Perl's "spirit" into enforcable legalese
- but it may be worth trying.
--
Nick Ing-Simmons
able) so virtual functions
>can themselves call virtual functions on the same object.
Definitely. It also allows them to change what ptr_to_data is for example.
>
>-Edwin
--
Nick Ing-Simmons
pod the source before building it,
>or a -HASPOD extension to gcc
>
>Or just getting in the habit of writing
>
>/*
>=pod
>
>
>and
>
>=cut
>*/
Perhaps we could teach pod that /* was alias for =pod
and */ an alias for =cut ?
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
uncall compare (cdr x) (cdr y)))
>)
> )
> )
So can you write that in perl5 rather than LISP?
If not what does perl6 need so we can write it in perl6.
sub Schwartzian
{
...
}
>
>Do you see any ESP there? Do you see any parsing of arbitrary pieces of
>code? No, me neither.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
is
going to consume instructions and N * 32 bits of memory or so.
>
>If we made sure the arenas were on some power-of-two boundary we could just
>mask the low bits off the pointer for the base arena address. Evil, but
>potentially worth it at this low a level.
That would work ;-)
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
l me if there really is an use for overloading && and || that
>would not be better done with source filtering, then I will (maybe)
>reconsider my opinion.
>
>- Branden
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
$c = ($a && &b) ? $d : $e;
calls the bool-ness of $a and in the defered execution mode of a translator
it wants to return not true/false but "it depends on what $a is at run-time".
It cannot do that and is not passed $b so cannot return
new Operator::->('&&',$a,$b)
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
Larry Wall <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons writes:
>: >You really have to talk about overloading boolean context
>: >in general.
>:
>: Only if you are going to execute the result in the normal perl realm.
>: Consider using the perl parser to bu
is the style I use in my own (whoops sorry, TI's) code and
it does not seem to "hurt" even on X86 CISC machines.
--
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/
Uri Guttman <[EMAIL PROTECTED]> writes:
>>>>>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
> NI> "We" need to decide where a perl6 sub's local variables are going
> NI> to live (in the recursive case) - if we
e small functions rather than #define or inline,
for cache reasons - this has tended to make above show. I am delighted to
say that _modern_ (Sun) SPARCs have deep enough windows even for me -
but SPARCStation1+ and some of the lowcost CPUs didn't.)
>
>Alan Burlison
--
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/
p r
is lousy way to code r = a + b - too much pointless copying.
We want
add #a,#b,#r
were #a is a small number indexing into "somewhere" where a is stored.
>
>Graham.
--
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/
s let the compiler keep track of the register usage and just do
>individual push/pops as needed when registers run out.
That makes sense if (and only if) virtual machine registers are real
machine registers. If virtual machine registers are in memory then
accessing them "on the stack" is ju
you
ld BP[4],X
add 4,X
ST X,BP[4]
If "registers" are really memory the extra "moves" of a RISC scheme
are expensive.
What we _really_ don't want is the worst of both worlds:
push BP[4];
push 4
add
pop BP[4]
>
>i am thinking about writing a short psuedo code post about the N-tuple
>op codes and the register set design. the ideas are percolating in my
>brane.
>
>uri
--
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/
_ */
>#defineREG_ARGV66 /* @ARGV */
>#define REG_INT1 67 /* integer 1 */
>#defineREG_INT268 /* integer 1 */
>
>uri
--
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/
ense here. the data stack is just PMC pointers, the
>code call stack has register info, context, etc.
One stack is more natural for translation to C (which has just one).
One problem with FORTH was allocating two growable segments for its
two stacks - one always ended up 2nd class.
--
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/
- but compilers
can keep track of such mess for us.
>
>
>Both use the same regsters, have the same net result, but the explicit
>scheme requires an extra 11 numbers in the bytecode, not to mention all
>the extra cycles required to extract out those nunmbers from the bytecode
>in the first place.
--
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 02:08 PM 5/30/2001 +0000, Nick Ing-Simmons wrote:
>>Classic CISC code generation taught "us" that CISC is a pain to code-gen.
>>(I am not a Guru but did design TMS320C80's RISC specifically to match
>>gcc of
Uri Guttman <[EMAIL PROTECTED]> writes:
>>>>>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
> NI> The "overhead of op dispatch" is a self-proving issue - if you
> NI> have complex ops they are expensive to dispatch.
>
;*) Treating regexes as non-atomic operations brings some serious threading
>issues into things.
Leaving them atomic does as well - I will switch threads as soon
as the regexp completes ...
--
Nick Ing-Simmons
that an Anything->Unicode translation will be lossless, but this
>makes me wonder whether that assumption is correct.
One reason perl5.7.1+'s Encode does not do asian encodings yet is that
the tables I have found so far (Mainly Unicode 3.0 based) are lossy.
--
Nick Ing-Simmons
like this"---
>Dan Sugalski even samurai
>[EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
--
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/
oop.c file which is part answer
to the shadows.
Given the inner functions we could presumable generate the decode
functions (c.f. xsubpp)
--
Nick Ing-Simmons
he 1st to admit which is why it isn't released!).
It would be good if Tk-for-perl6 did not have to break the rules or
provide its own hooks for meta data and could use "the" string API.
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
David Landgren <[EMAIL PROTECTED]> writes:
>Steve Peters wrote:
>> On Tue, Mar 14, 2006 at 04:52:18PM +0100, David Landgren wrote:
>
>[...]
>
>>> /eg scripts are a nice "hands-on" way of finding out how a module works
>>> in real life.
>>>
>>> No distribution should be without one!
>>>
>>
>> Unle
so my mailfilter is filing them as SPAM
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
he "trick" before it is not uncommon
to have
enum foo {
/* auto-genererated stuff */
foo_MAX
};
where foo_MAX is a handy "number of entries" value as well
as avoiding the trailing comma issue.
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
Andrew Potozniak <[EMAIL PROTECTED]> writes:
>>I'm afraid your code won't work.
>
>As stated below I got it to work with my example :-p
>
>>Okay, you've subclassed a functional module. But this means that
>>you'll be >passing the package name as the first argument, not a test
>>name. This will
We have been discussing how to pass data to Tk callbacks.
In particular Entry widget validation routines.
There are a number of items that they _might_ be interested in
but a typical routine would only use a few.
Currently it passes them all as positional parameters.
One idea that occured to me/
Damian Conway <[EMAIL PROTECTED]> writes:
>
> From a Perl 6 perspective, it seems likely that C<%_> will be the name
>commonly used for the "slurpy hash" of a subroutine. Just as C<@_> will often
>be the name used for the "slurpy array". See Exegesis 6 for more details.
>
>Indeed, when it comes t
Matthew O. Persico <[EMAIL PROTECTED]> writes:
>On Thu, 21 Aug 2003 22:48:11 -0500, Andy Lester wrote:
>[snip]
>>The project page is at http://qa.perl.org/phalanx/. �Please take a
>>look, tell me your thoughts, and if there are any serious ommissions
>>from the Phalanx 100 module list...
>
>Tk?
If
Dave Mitchell <[EMAIL PROTECTED]> writes:
>
>1. It would be very hard to create these options.
>2. Any programmer that used an 'only these' option would almost
>certainly create a program that at best would not work, and at worst would
>coredump. Whats happens if the user forgot to copy $/ ? What d
Thomas Klausner <[EMAIL PROTECTED]> writes:
>
>Personally, I'm annoyed by dist that I cannot remove after installation.
>If files are read-only, I'll have to do extra steps during deleting. So I
>like dists which no read-only files. Which is why it's a Kwalitee indicator.
>If we (whoever is interes
Abigail <[EMAIL PROTECTED]> writes:
>
>No new keywords in perl-5.001
>New in perl-5.002: tied __DATA__ sysopen prototype
>No new keywords in perl-5.003
>New in perl-5.004: __PACKAGE__ sysseek
>New in perl-5.005: qr lock INIT
>New in perl-5.6.0: CHECK our
>No new keywords
Rafael Garcia-Suarez <[EMAIL PROTECTED]> writes:
>Thomas Klausner wrote:
>> there are currently 4 dists on CPAN that only include a configure script
>> (makepp-1.19, glist-0.9.17a10, swig1.1p5, shufflestat-0.0.3)
>>
>> 179 do not include any of Makefile.PL, Build.PL or configure.
>>
>> Quite a l
Rafael Garcia-Suarez <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
>> >Could we infer that a distribution that comes with several Makefile.PLs
>> >may have an overcomplicated build process, maybe indicating a low
>> >kwalite
Michael G Schwern <[EMAIL PROTECTED]> writes:
>One thing to keep in mind is portability. In order for this to be useful
>it has to run on pretty much all platforms. Unix, Windows, VMS, etc...
>So I'm trying to keep it as simple as possible.
>
>
>On Wed, Feb 18, 2004 at 05:29:49PM +, Adrian Ho
Michael G Schwern <[EMAIL PROTECTED]> writes:
>On Thu, Feb 19, 2004 at 08:35:28AM +0000, Nick Ing-Simmons wrote:
>> Michael G Schwern <[EMAIL PROTECTED]> writes:
>> >One thing to keep in mind is portability. In order for this to be useful
>> >it has to
Brian Cassidy <[EMAIL PROTECTED]> writes:
>Hi Leon,
>
>> -Original Message-
>> Does anyone have any features they'd like to see on the website? I'm
>> looking at extracting more information (Perl version, platform) and
>> having pages (and thus RSS) per author.
>
>If you're going to do RSS,
Andrew Dougherty <[EMAIL PROTECTED]> writes:
>Whilst trying to build ponie-2 on Solaris 8, I came across the following
>issue: In order to use threads, both perl-5.[89].x and parrot need to
>call some sort of yield() function.
>
>In parrot, sched_yield is used; this function is available in the -l
Arthur Bergman <[EMAIL PROTECTED]> writes:
>This is Ponie, development release 2
>
>
> "And, isn't sanity really just a one-trick ponie anyway? I mean all
>you get is one trick, rational thinking, but when you're good and
>crazy, oooh, oooh, oooh, the sky
Dan Sugalski <[EMAIL PROTECTED]> writes:
>In an attempt to drain the swamp...
>
>So far as I can see, we need, in descending order of importance (and
>speed) (And if there's stuff missing, add them):
>
>1) A timestamp value
>2) A way to chop the timestamp to pieces
>3) A way to turn the timestamp
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 10:11 AM -0800 3/10/04, Brent \"Dax\" Royal-Gordon wrote:
>>Josh Wilmes wrote:
>>>It's also quite possible that miniparrot is a waste of time. I'm
>>>pretty much of the opinion myself that it's an academic exercise at
>>>this point, but one which keep
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 11:12 AM -0800 3/10/04, Brent \"Dax\" Royal-Gordon wrote:
>>Dan Sugalski wrote:
>>>Which, unfortunately, will end up making things a hassle, since
>>>there's no platform-independent way to spawn a sub-process, dammit.
>>>:(
>>
>>Unixen seem to support
Larry Wall <[EMAIL PROTECTED]> writes:
>
>That would seem like good future proofing. Someday every computer will
>have decentish subsecond timing. I hope to see it in my lifetime...
It isn't having the sub-second time in the computer it is the API
to get at it...
>
>My guess is that eventuall
Mark Sparshatt <[EMAIL PROTECTED]> writes:
>
>I'm not 100% certain about the details but I think this is how it works.
>
>In languages like C++ objects and classes are completely seperate.
>classes form an inheritance heirachy and objects are instances of a
>particular class.
>
>However in some lan
bootstrap a
> parrot/tinyperl6 based solution.
>
>or
>
>d,e,f, and g) There are always other options.
>
>As I said above, I'm trying to trigger a discussion to build at least
>an initial direction that we want to aim for. People are already
>running into porting issues
that Perl 5 did not segfault.
Irritating though the popups are they do at least allow me to get
a backtrace to the segfault.
Maybe have the handler unless -DDEBUGGING ?
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
SVOP (0x163e68) gvsv GV (0x10a98c) *r
>-e syntax OK
>
>
>For "much" equal to 1 op in total.
>
>I think that the answer is "no, do it by hand if it matters that much",
>doesn't it?
>
>This also might be a perl6 question, for a more "serious" -O2 optimiser.
>Hmm. Would parrot benefit from nand and nor ops?
>
>[beware of cross posting when replying]
>
>Nicholas Clark
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
hyper cube of a Karnaugh map.
>However, I just don't
>think most programs spend enough time doing logical comparison to
>really matter. Besides which, such techniques work best on complex
>expressions, which are rare indeed.
>I could be wrong, of course. Maybe someone could run some benchmarks?
>
>brian.
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
ble @b, and pass it a
>DS> pointer to @c, and let it Do The Right Thing.
>
>But that was my question in the _other_ thread. How?
>
>Given N different fundemental types, we end up with NxN vtbl entries.
Which is not necessarily a problem if N is small (a 4x4 vtable is easy).
--
Nic
me - what are (hopefully) indistinguishable from native
in the UNIX case at least.
--
Nick Ing-Simmons
shift;
print Dumper($arg);
print STDOUT "Dumped ",ref($arg),"\n";
}
select(STDERR);
show_things({a => 1});
open(my $foo,">dump");
select($foo);
show_things({b => 2});
close($foo);
select(STDOUT);
show_things({c => 3});
__END__
This technique is extremely handy!
Now if only one could divert warn/die messages to STDERR by a similar trick
--
Nick Ing-Simmons
s is almost certainly NOT a global 'use' option but a "mode" of
a particular handle.
We want $/ to go away and become a property of the handle.
Perhaps $/ or the 'use' can set the _default_ which is passed to the "open"
when nothing more specific is given.
>
>-Hao
--
Nick Ing-Simmons
m, $args;
should "just work" if the module is in the right place, and give
a meaningful error if it isn't.
>
> open MyHttp, 'http://www.yahoo.com/', $custom, $args;
>
>Allows you to do this simply, in a syntax that is already established.
The URI syntax is also well established.
--
Nick Ing-Simmons
ified it does NOT
change STDOUT.
It will be impossible to translate many perl5 programs to perl6 if
that difference is not retained somehow.
--
Nick Ing-Simmons
probably mention here that the single-arg form of select() is the
>one you're suggesting for deprecation, and not the four-arg form.
The 4 arg form will be deprecated somewhere else. Splitting the function
is a good idea...
--
Nick Ing-Simmons
s it is SLOW.
Sort of automatically and liberally inserted assert() statements.
--
Nick Ing-Simmons
n other words: things like
>the protocol, the port number, the username, the password, could
>be part of a "file spec".
Quite.
--
Nick Ing-Simmons
1 - 100 of 170 matches
Mail list logo