Splitting core functions into multiple shared objects: A warning

Beware of dependencies between shared objects. Let's assume 2 chunks of core functionality are seperated off into say A.so and B.so. This will work fine as long as there are no interdependencies between A.so and B.so. Let's however assume A.so needs to call something in B.so. That means before

Subscript should be known for a multidimesional array

=head1 TITLE Subscript should be known for a multidimesional array =head1 VERSION Maintainer: Suresh Kumar .R <[EMAIL PROTECTED]> Date: 2000-08-26 Version: 1 Mailing List: [EMAIL PROTECTED] Number: ? =head1 ABSTRACT When we use $ARGV[$#ARGV] it gives the Subscript of the last elemen

Builtin function to insert an element in the middle of the array (including multidimensional)

=head1 TITLE Builtin function to insert an element in the middle of the array (including multidimensional) =head1 VERSION Maintainer: Suresh Kumar .R <[EMAIL PROTECTED]> Date: 2000-08-26 Version: 1 Mailing List: [EMAIL PROTECTED] Number: ? =head1 ABSTRACT A builtin function should b

Perl should become PEARL

=head1 TITLE Perl should become PEARL =head1 VERSION Maintainer: Suresh Kumar .R <[EMAIL PROTECTED]> Date: 2000-08-26 Version: 1 Mailing List: [EMAIL PROTECTED] Number: ? =head1 ABSTRACT Perl should become PEARL which indicates the true meaning for this language =head1 DESCRIPTION

onerror() builtin function required

head1 TITLE onerror() builtin function required =head1 VERSION Maintainer: Suresh Kumar .R <[EMAIL PROTECTED]> Date: 2000-08-26 Version: 1 Mailing List: [EMAIL PROTECTED] Number: ? =head1 ABSTRACT Perl should handle all the errors and sigtraps with one onerror builtin funciton =hea

In built SGML/XML parser required

=head1 TITLE In built SGML/XML parser required =head1 VERSION Maintainer: Suresh Kumar .R <[EMAIL PROTECTED]> Date: 2000-08-26 Version: 1 Mailing List: [EMAIL PROTECTED] Number: ? =head1 ABSTRACT There is no true inbuilt parser in PERL, it has to be built. =head1 DESCRIPTION Publi

My Wish

=head1 TITLE Subscript should be known for a multidimesional array =head1 VERSION Maintainer: Suresh Kumar .R <[EMAIL PROTECTED]> Date: 2000-08-26 Version: 1 Mailing List: [EMAIL PROTECTED] Number: ? =head1 ABSTRACT When we use $ARGV[$#ARGV] it gives the Subscript of the last elemen

READ THIS: Re: My Wish

Righto. I'll coach Sumesh through how to post an RFC properly, and how to check whether something's in Perl yet or not. DO NOT fill -language with discussions of these pseudo-RFCs. Please. I'm begging you. K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source dev

Re: My Wish

Sumesh, Please read http://dev.perl.org/ for the correct way to post a Perl 6 RFC. The first thing you need to know is that they should go to [EMAIL PROTECTED], not direct to the mailing list. Secondly, you need to make sure that things your'e RFCing aren't already available in Perl. Some of t

Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

On Fri, 25 Aug 2000 20:44:32 -0400, John Porter wrote: >Nathan Wiger wrote: >> >> I do think >> it's worth considering if we're dead-set on losing =~. > >But are we? I hope not. I *like* the =~ syntax, and I would hope we could extend it to more functions that change one of their parameters, l

Global time should be made available

=head1 TITLE Global time should be made available =head1 VERSION Maintainer: Suresh Kumar .R <[EMAIL PROTECTED]> Date: 2000-08-26 Version: 1 Mailing List: [EMAIL PROTECTED] Number: ? =head1 ABSTRACT A builtin function should which returns appropriate time according to the that count

Time should be displayed depending upon the parameter

=head1 TITLE Time should be displayed depending upon the parameter =head1 VERSION Maintainer: Suresh Kumar .R <[EMAIL PROTECTED]> Date: 2000-08-26 Version: 1 Mailing List: [EMAIL PROTECTED] Number: ? =head1 ABSTRACT A builtin function should which returns appropriate time according

Re: Structured exception handling should be a core module.

Peter Scott wrote: > > Tony Olekshy wrote: > > > > In fact, not only would I be pleased and honoured to author the > > Perl 6 core Try.pm module, I'm already working on a Perl 5 standard > > reference implementation. > > > Peter, I think we should make this approach more clear in RFC 88. > > I'

Re: RFC 57 (v1) Subroutine prototypes and parameters

Chaim: ISO8859-1 on purpose, look at last paragraph. Reply on laptop in wilderness (no network) holydays me void this message by other messages sent in my absence. Ignore if so. On 7 Aug 2000 14:35:50 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote: > =head1 ABSTRACT > > Perl 6 should prov

Re: Threads and run time/compile time

On Sat, 26 Aug 2000, Steven W McDougall wrote: > However, the distinction between compile time and run time that it > relies on doesn't exist in Perl. For example, if we chase through > perlfunc.pod a bit, we find No? I'll admit that it may run through the compile and run modes multiple times, b

Re: RFC 45 (v1) || should propagate result context to bo

At 06:59 AM 8/26/00 -0600, Tom Christiansen wrote: >[I know this is not your quote, but your quotee's quote] > > >> There is obviously no need to modify the behavior of the C<&&> operator. > >Is one wholly certain of this? > > DB<1> @c = (1..3) > DB<2> @a = @b && @c > DB<3> x @a

Re: Perl should become PEARL

> Perl should become PEARL This is a joke, right? :-) Perl already *was* PEARL. Way back when. Larry changed it *to* Perl because there was already a different PEARL. > Even many books display PEARL as the Logo for the PERL > language book. Maybe they're really talking about PEARL. If not, I w

Re: Perl should become PEARL

Suresh Kumar R writes: : Perl should become PEARL Er, the folks at http://www.irt.uni-hannover.de/pearl/pearl-gb.html might have something to say about that. Larry

Re: RFC 45 (v1) || should propagate result context to bo

Tom Christiansen writes: : It would appear that altering &&/|| on LHS context would entail, : in the list assignment scenario, calling that operand in list context : and then deciding whether it were true or not by some "intuitive" : means (almost certainly by using whether its element count were

Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@>

Bart Lateur writes: : Apropos those extended mechanisms: couldn't we use the same mechanism as : is currently in use for $!, for $@ too? I mean: $! in numerical context : gives an error number, in string context a text string. Then : : die "I'm outta here: $!"; : : should assign both the n

Re: New variable type: matrix

Baris wrote: > > Suppose I am a newcomer to perl and my aim is to multiply two matrices > and I don't really care about regex's or references in perl. Currently > I have to learn a lot about perl language to begin working with matrix > multiplication. This seems to me aginst the perl culture. I k

Re: New variable type: matrix

> Not being a PDL'er myself, but interested in learning more about it and > making sure Perl 6 doesn't suck, I'd love to see a bulleted list of what > doesn't work right, even assuming that @arrays were made more flexible. > For example, if you could do this: > >@c = @a * @b; >@c = @a +

Re: RFC 146 (v1) Remove socket functions from core

On Fri, Aug 25, 2000 at 09:12:19AM -0400, Dan Sugalski wrote: > At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote: > >Isn't dynamic loading really slow? > > Not particularly, at least not as far as I know. There's some extra cost in > finding the library and loading it that you wouldn't pay if

Re: RFC 146 (v1) Remove socket functions from core

Dan Sugalski wrote: > This is actually one of the spots I'm hoping to pick up a win from--if the > only code that links against the system socket library is in the code > that's not loaded by default, then that means one fewer system library to load. > > Granted, odds are the library's in memory

Re: RFC 146 (v1) Remove socket functions from core

[EMAIL PROTECTED] wrote: > Dynamic loading can be noticeably slow if you are loading something > via NFS. In addition the PIC code and jump tables used for dynamic > linking result in a 10-15% slowdown in execution speed on SunOS and > Solaris (at least in my experiments). Not what I'd call reall

RE: RFC 146 (v1) Remove socket functions from core

I wonder if you could arrange things so that you could have statically linked and dynamic linked executable. Kind of like what they do with the Linux kernel. When your installation is configured in such a way as to make the dynamic linking a problem, just compile a version that has (almost) every

Re: New match and subst replacements for =~ and !~ (was Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.)

Nathan Wiger <[EMAIL PROTECTED]> wrote: [...] > match; # all defaults (pattern is /\w+/?) > match /pat/;# match $_ > match /pat/, $str; # match $str > match /pat/, @strs; # match any of @strs > > subst; # like s///, pretty useless :-) > subst /pat

Re: New variable type: matrix

Buddha Buck wrote: > > $matrix[$x,$y,$z] already has a reasonable meaning. If we > appropriate that syntax, how do you take slices of a matrix? My point too, only someone else pointed out that this is actually @matrix[$x,$y,$z]. STILL, the fact that I've been hacking Perl since 4 and missed th

Re: RFC 148 (v1) Add reshape() for multi-dimensional array reshaping

Nathan Wiger <[EMAIL PROTECTED]> writes: > > > > $a[$i][$j][$k] or $a[$i,$j,$k] > > > The second one has no useful meeting, "," is just an operator which > > does nothing much useful in this context. > > Not true, at least not in the Perl I know. :-) Here's a description of > what these do in P

Re: New variable type: matrix

Hi Karl, Thanks for your comments. I still think it would be a good idea to have a new type for both functional and promotional purposes. I know that Nathan Torkington answered that perl6 will support the requirements of PDL but I am hoping that having a new type for multidimentional arrays let

Re: RFC 148 (v1) Add reshape() for multi-dimensional array reshaping

On Fri, Aug 25, 2000 at 07:35:24PM -0700, Nathan Wiger wrote: > > > > $a[$i][$j][$k] or $a[$i,$j,$k] > > > The second one has no useful meeting, "," is just an operator which > > does nothing much useful in this context. > > Not true, at least not in the Perl I know. :-) Here's a description of >

perl6-meta opened, bootstrap closed.

perl6-meta is now open and it's former incarnation, [EMAIL PROTECTED], will be closed. - ask -- ask bjoern hansen - more than 70M impressions per day,

Re: RFC: Automatic accessors for hash-based objects

On Sat, Aug 26, 2000 at 08:24:19PM -0500, Dave Rolsky wrote: > This is an interesting idea. I would think that ideally it would be > combined with pre-declared limited keyspace hashes (which we currently > have in a semi-crippled way with pseudohashes). This seems like a fairly orthagonal thing

RFC: Automatic accessors for hash-based objects

It appears that the RFC Librarian doesn't work weekends, so I'm going to post this directly. Hopefuly, it doesn't have any glaringly obvious errors... =head1 TITLE Automatic accessors for hash-based objects =head1 VERSION Maintainer: James Mastros <[EMAIL PROTECTED]> Date: 25 Aug 2000 Vers

Re: RFC: Automatic accessors for hash-based objects

On Sat, 26 Aug 2000, James Mastros wrote: > This example shows how much easier it would have been to write the > example on line 170 of perltoot.pod: > > package Person; > use strict; > > ## > ## the object constructor (simplis

Re: RFC 45 (v1) || should propagate result context to bo

At 02:22 PM 8/26/00 +0200, H.Merijn Brand wrote: > > It seems that it ought to be possible to evaluate something in a list > > context and test whether there are any entries in the resulting list > > without having to reevaluate the expression in a scalar context. The > > work-around with the tri

Re: RFC 45 (v1) || should propagate result context to bo

Reply on laptop in wilderness (no network) holydays me void this message by other messages sent in my absence. Ignore if so. On 5 Aug 2000 21:40:43 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITL

Re: RFC 45 (v1) || should propagate result context to bo

[I know this is not your quote, but your quotee's quote] >> There is obviously no need to modify the behavior of the C<&&> operator. Is one wholly certain of this? DB<1> @c = (1..3) DB<2> @a = @b && @c DB<3> x @a 0 0 DB<4> x @b empty array It's hard to argue

Re: RFC 111 (v1) Whitespace and Here Docs

Reply on laptop in wilderness (no network) holydays me void this message by other messages sent in my absence. Ignore if so. On Thu, 17 Aug 2000 08:28:50 -0400 (EDT), Philip Newton <[EMAIL PROTECTED]> wrote: > On Tue, 15 Aug 2000, Michael Fowler wrote: > > > So what's insufficient about: > > >

Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

Bart Lateur wrote: > I *like* the =~ syntax, ich auch. > and I would hope we could extend it > to more functions that change one of their parameters, like > sysread/read: > > $bytes_read = $string =~ sysread FILE, $bytes_to_read; RFC139 would enable precisely that capability. -- John

Re: Are Perl6 threads preemptive or cooperative?

A couple of other scenerios Thread 1Thread 2 push(@a, @b); $a[35]++ User level cross variable consistancy. push(@a, $b); $acount++ if $b <35; Even cooperative threading doesn't help. > "SWM" == Steven W McDougall <[EMAIL PROTECT

Re: Threads and file-scoped lexicals

Thread shared variables will have to be declared. Perhaps my $foo :shared; Otherwise, the variable refers to thread specific storage. Up for grabs is what the variable contains upon thread start. undef or a copy-on-write version of the original. > "SWM" == Steven W McDougall <[EM

Re: Threads and run time/compile time

>> Users can (and do) write open code in modules. > I don't understand. Do you think that needs to be prevented? No, I just want to know what happens when they do it. Let's look at an example. 1. Non-threaded #!/usr/local/bin/perl sub foo { print 1 } foo(); eval 'sub foo { pr