Re: [perl #33747]

2005-01-11 Thread Leopold Toetsch
Simon Glover <[EMAIL PROTECTED]> wrote:

>  ..., but I'm posting it to the list rather than simply applying it
>  because it is not clear to me that the behaviour described above is
>  precisely what we want.

We have to precisely define what should happen with these corner cases.
We should implement the most common behavior of target languages. The
problem is probably that throwing an exception inside the string.c
implementation isn't the best thing, when target languages' behavior
differ.

Applied anyway, its more correct then before,
leo


Re: solution to TODO #32365

2005-01-11 Thread Leopold Toetsch
Peter Christopher <[EMAIL PROTECTED]> wrote:

> I'll check out the build scripts and see what flags will do to compile
> the t/src/*.c and put them in. Further, I'll try to determine good
> values for --cflags, --include, etc. from the Makefile.

Ok. Can you move the build script to F and provide another
patch with the mentioned shortcuts.

Thanks.

> ... different set of values (in $(EXEC_PREFIX)/bin, $(EXEC_PREFIX)/lib
> $(EXEC_PREFIX)/include for example). I suppose one could have a
> parrot-config during `make' and leave it in the build directory and then
> if someone `make install'ed generate another version and copy it into
> $(EXEC_PREFIX)/bin. No?

Yep. We have that problem already with runtime paths. My proposal was to
initially set these paths to build paths and during "make install" redo the
relevant build steps with these paths set to actual installed paths.

> Best,Pete

leo


Perl 6 Summary for 2004-01-03 through 2004-01-11

2005-01-11 Thread Matt Fowles
Perl 6 Summary for 2004-01-03 through 2004-01-11
Welcome to another Perl 6 summary. In this summary, we will explore such
thrilling issues as multi-dimensional slices of Chinese food. After all,
the amount of sauce any piece of Chinese food can absorb is proportional
to its surface area, which is a direct function of the number of
dimensions in which it is sliced (provided that we ignore degenerate
cases like fractal cuts of Peking duck).

  Perl 6 Language
   1x6 vs 6
Craig DeForest wondered how to disambiguate a 1x6 2D array slice from a
6 element 1D array slice. He suggested a syntax inspired by PDL. Larry
admitted to not having examined this particular issue and stated that he
was open to suggestions. Some suggestions arrived.



   code as comment
Stéphane Payrard wanted to know if there is an easy way to alias
arguments to a function. Thus allowing a longer version for readability
when calling the function and a short version inside the function. Larry
suggested "$s is named", which I like. The thread then devolved
into punning in French.

 -- main thread on p6l

 -- initial post on p6c

  Perl 6 Compiler
   Pascal -> Pcode -> Parrot -> Profit
Sven Schubert asked about the feasibility of putting Pascal on Parrot.
He noted that with the infrastructure mentioned in "Perl 6 and Parrot
Essentials" the problem would not be too bad. Apparently "Essentials"
makes a few promises that we have yet to live up to. But we are working
towards it. In the mean time, Stéphane Payrard suggested a way for him
to kill to bird with one stone: Pcode.

 -- Pcode suggestion

 -- initial post

   Grammar improvements
Luke Blanshard submitted some rules for Perl6::Grammar. Luke Palmer
committed a slight variantion of his work, and the hacking commences...



  Parrot
   pop_pad
Peter Christopher wondered why pop_pad had not been implemented last
week. This week Leo implemented it and asked for tests.



   Resizable arrays
Simon Glover asked why ResizablePMCArray was so different from all of it
Resizable*Array bretheren. The answer is the Leo improved it. This
brings up an obvious task for someone looking for a reasonably friendly
chunk of Parrot to work on. Rationalizing the implementation of the
various Resizable*Arrays would probably be a good task for a novice
looking to dig into something. Perhaps one who is on winter break...



   Parrot 0.1.1 nci troubles
Ian Joyce noticed that parrot 0.1.1 was having some trouble with nci.t.
Leo admitted that this was the case, but it is fixed in CVS.



   test or benchmark
Nicholas Clark wondered if resizablestringarray.t was actually a
benchmark, because it had a big number which was really hurting his poor
machine. Simon Glover admitted to the copy paste error.



   x86 solaris 2.5.1 and 2.7
Andy Bach and Nicholas Clark worked towards getting parrot happier on
the aforementioned architecture. This thread seemed to peter out when
Nicholas asked "how do we run a callback unconditionally after
gccversion is known, independent of its value?".



   VTABLE_call_method
Leo and Sam had a disagreement about whether a call_method vtable would
make sense. I think that we are waiting for higher intervention...



   updated perlhist.txt
Will Coleda applied Bernhard's patch updating perlhist.txt and
streams.t.



   Warnock Warnocked
Will Coleda applied the long Warnocked update to Warnock's contact
information with only a trace of irony.



   gcov of perlarray.pmc reaches 100%
Simon Glover got perlarray.pmc to have full test coverage. Nifty. Some
brave soul (possibly fitting an earlier description) should try this
with the Fixed*Arrays...



   Parrot under Solaris 9
Nicholas Clark, Andy Doughery, and Christian Aperghis-Tramoni all tried
to convince Parrot to work on Solaris. They are brave souls.



   parrot-config updates
Peter Christopher asked questions about the parrot-config.imc. He also
provided an initial solution.

 -- questions

 -- solutions

   Key Question
Simon Glover noticed some bad behavior with respect to Key PMCs. Leo and
Sam both admitted that it was bad and that some work needed to be done.



   Parrot PDL
Bernhard Schmalhofer posted a pointer to PDL. Luke Palmer pondered
Piddles as Parrot PMCs. Craig DeForest proposed a path passing through
PDL's PP and pausing at Parrot. (Parenthetically, 

archive search?

2005-01-11 Thread Peter Christopher
Hi Listers,

Last I checked (which was moments ago) it was either (a) 
impossible to, or (b) I couldn't figure out how to, search the parrot 
mailing list archive. I.e. I can't search 
www.nntp.perl.org/group/perl.perl6.internals 
for key words. Could someone give me the heads up on how to search this 
list? If the search can't be done, is there a way that I can download 
the archive en mass: so that I can grep to my hearts delight? 

Thanks for any information,
Pete




blib vs. icu

2005-01-11 Thread Peter Christopher
Hi again Listers,

Ok it looks like to me that the ./blib directory is associated
in some way with the ./icu directory [same header files, vague
references to blib from icu README, etc.]. The (installation) MANIFEST
never mentions blib but installs icu. BUT cc_inc [of the build process
fame] contains pointers to the include files in blib but not in icu.
Puff. So could someone please give me the quick 25 second tutorial on
(a) if icu and blib are related and if so (b) how they are related? This
information relates to the "what flags do we need to compile a parrot
extension in AND out of the build directory" question. Thanks for any
help.

Best,Pete






Re: archive search?

2005-01-11 Thread Steve Fink
On Jan-11, Peter Christopher wrote:
> 
>   Last I checked (which was moments ago) it was either (a) 
> impossible to, or (b) I couldn't figure out how to, search the parrot 
> mailing list archive. I.e. I can't search 
> www.nntp.perl.org/group/perl.perl6.internals 
> for key words. Could someone give me the heads up on how to search this 
> list? If the search can't be done, is there a way that I can download 
> the archive en mass: so that I can grep to my hearts delight? 

Use Google groups search.

Specifically: go to groups.google.com. To search for "aardvark", enter

  group:perl.perl6.internals aardvark



Re: Dimension of slices; scalars versus 1-element arrays?

2005-01-11 Thread Dave Whipp
Larry Wall wrote:
On Sat, Jan 08, 2005 at 11:37:06AM -0700, Craig DeForest wrote:

: Is the perl6 expression
:   @a[4; 0..5];
: a 1x6 array (probably correct)?  Or a 6 array (probably not correct)?
Certainly the former.  I don't think dimensions should ever disappear
accidentally.
Except when you assign in scalar context -- which I guess isn't accidental.
We know that
@a = (1, 2, 3);
$b = @a[1];
Loses the dimension as a DWIM.
So perhaps we could say that assigning to a lower dimension always gets 
rid of a dimension of size 1 -- or error if it can't:

@c = ( 1,2,3 ; 4,5,6 );
@d[*;*] = @c[ 1 ; * ]; # @d is 2d
@e[*] = @c[ 1 ; * ];  # @e is 1d
@f = @c[1;1];  # @f is 2d: no dimensions lost
@g[*] = @c[ 0,1 ; 0,1 ]; # error: cannot collapse
as our disambiguator.
{ @c[;*] but shape(*) } wouldn't work, because the :shape option leaves 
additional dimensions open.

Dave.


Re: Dimension of slices; scalars versus 1-element arrays?

2005-01-11 Thread Craig DeForest
On Tuesday 11 January 2005 10:06 pm, Dave Whipp wrote:
> We know that
>
> @a = (1, 2, 3);
> $b = @a[1];
>
> Loses the dimension as a DWIM.
>
> So perhaps we could say that assigning to a lower dimension always gets
> rid of a dimension of size 1 -- or error if it can't:
>
> @c = ( 1,2,3 ; 4,5,6 );
> @d[*;*] = @c[ 1 ; * ]; # @d is 2d
> @e[*] = @c[ 1 ; * ];  # @e is 1d
> @f = @c[1;1];  # @f is 2d: no dimensions lost

Hmmm   I'm sorry, but I'm not quite following what you mean by 
the '=' in this case.  I've been thinking of '=' as a full-on, 
dimensional-context-free assignment, and of ':=' as a shaped, elementwise 
assignment, by analogy to the current perl5/PDL setup.  In that paradigm, 
"@e[*] = @c[1;*]" doesn't mean anything, since the LHS isn't really a
full-on lvalue -- it's an array slice with (already) a definite shape (an 
"l2value"?).

But I could just be confused about intent here. I'm used to thinking of 
piddles, which are pretty regimented -- they have a definite size along each 
axis.  Do perl6 multi-dimensional arrays have definite sizes, or are they 
"just" lists of lists of whatevers, under the hood?  Each of those structures 
would be very useful for an almost completely different set of things.

I guess Larry was right when he hinted that there're still dragons here... so,
er, sorry to have opened a can of wyrms...