Re: loadlib and libraries with '.' in the name

[chromatic]

On Thu, 2005-09-22 at 23:43 -0700, Ross McFarland wrote:

> cross platform it would be tough b/c you need to know the full path  
> to something you can load.

Does it help to use libnci_test?  That's what t/pmc/nci.t uses.   (It's
late and I've only skimmed the code right now, so it may not be
helpful.)

-- c

Re: loadlib and libraries with '.' in the name

[Ross McFarland]

On Sep 23, 2005, at 12:00 AM, chromatic wrote:


On Thu, 2005-09-22 at 23:43 -0700, Ross McFarland wrote:



cross platform it would be tough b/c you need to know the full path
to something you can load.



Does it help to use libnci_test?  That's what t/pmc/nci.t uses.
(It's

late and I've only skimmed the code right now, so it may not be
helpful.)


good idea, provided that i can get the full path to it so that i can  
test all of the permuitations it would work.


i have all of the native \  / cases handled. i've got a little bit  
more work to do for handling things coming in as in the opposite \  /  
than the system we're running on. there's also a really hacky win32  
thing tacked on the end that removes the lib from the front, but it  
would only work for cases without a path. i can do the same, but  
that's pretty broken as is and it would seem you'd need to do the  
opposite if the lib was specified in win32 speak and you're running  
on unix-y system. there's a fixme comment saying that stuff probably  
belongs in somewhere else and i might look in to that, but i'll  
probably stick to reproducing the current behavior first.


bed time for now, i'll get back to this tomorrow.

-rm

Re: loadlib and libraries with '.' in the name

[Leopold Toetsch]

On Sep 23, 2005, at 7:51, Ross McFarland wrote:

i was playing around with NCI stuff tonight and ran across a problem 
in loadlib. the following code does not work:


.local pmc lib_gtk
lib_gtk = loadlib "libgtk-x11-2.0"


The need for such libnames arises typically on debian and alikes, where 
not all -devel packages are installed. I see two possibilities here:
1) demand from user to either install the -devel pkg or symlink the 
shortname

2) Parrot stops trying to  ...


ext_start = strrchr(*lib_name, '.');


... strip extensions.

i was planning on playing around with gtk+ bindings and parrot and 
went about looking around for the work that had already been done and 
didn't turn anything up. if anyone knows where i can find it or who i 
should talk to i would appreciate that info as well.


Google for "NCI gtk". There is also a weekly summary entry but the 
xrl.us shortcut seems to have expired.



-rm


leo

Re: [perl #27003] bytecode (header?) problem in tru64/alpha

[Jarkko Hietaniemi]

> 
> Jarkko,
> 
> Are there still outstanding issues on IRIX?  AFAIK nobody else has been
> building parrot on that platform.

Unfortunately I no more have access to that platform.

> -J
> 
> 
> 
> 

[perl #37242] [TODO] IMCC - separate PASM and PIR parsers

[via RT]

# New Ticket Created by  Joshua Hoblitt 
# Please include the string:  [perl #37242]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=37242 >


* split PASM and PIR lexer and parser into two distinct sets
  (the -p prefix option for bison is helpful here, see ast/ast.[ly])

-J

--

[perl #37243] [TODO] IMCC - generate exact location info

[via RT]

# New Ticket Created by  Joshua Hoblitt 
# Please include the string:  [perl #37243]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=37243 >


* generate exact location information, again see above files

Leo - can you clarify what exactly this means?

-J

--

[perl #37247] [TODO] IMCC - remove globals

[via RT]

# New Ticket Created by  Joshua Hoblitt 
# Please include the string:  [perl #37247]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=37247 >


* get rid of the still existing globals, move all into appropriate
  structures, mostly IMC_Unit.

-J

--

[perl #37244] [TODO] IMCC - cleanup grammar

[via RT]

# New Ticket Created by  Joshua Hoblitt 
# Please include the string:  [perl #37244]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=37244 >


* Cleanup and straighten the grammar files

-J

--

[perl #37248] [TODO] IMCC - create a compiler API

[via RT]

# New Ticket Created by  Joshua Hoblitt 
# Please include the string:  [perl #37248]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=37248 >


* and a lot more todo, e.g. create a compiler API

-J

--

[perl #37245] [TODO] IMCC - fix symbol handling

[via RT]

# New Ticket Created by  Joshua Hoblitt 
# Please include the string:  [perl #37245]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=37245 >


* fix names handling: global constants, locals per unit, subroutine
  names per namespace

-J

--

[perl #37246] [TODO] IMCC - remove stack calling conventions

[via RT]

# New Ticket Created by  Joshua Hoblitt 
# Please include the string:  [perl #37246]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=37246 >


* get rid of support for stack calling conventions (.param and friends)
  in PIR mode

* get rid of related cruft in imcc/cfg.c

-J

--

Re: Stringification, numification, and booleanification of pairs

[Damian Conway]

Juerd wrote:


I think separating stringification and interpolation leads to
unpredictability, and is a very bad thing.


I disagree. I think it's likely that people will think of ~$val and +$val the 
same way (i.e. as "coerce the value"), but that they will think of "$val" 
quite differently (i.e. as "interpolate a useful string representation of the 
entire value").


More importantly, as we have already seen with regexes, inconsistent 
numerification and stringification is an even more serious problem.


Damian

Re: New kwalitee test, has_changes

[Thomas Klausner]

Hi!

On Fri, Sep 23, 2005 at 12:54:42PM +1000, Adam Kennedy wrote:

> Collecting any sort of coverage data is a complete bitch. Let me just 
> say right now that doing it across _all_ of CPAN is flat out impossible.
> 
> It's impossible.

I completly agree.

Now, if somebody sets up a system to collect coverage data thats generated
at various decentralised machines and provides a nice interface to the
results, CPANTS might be able to use coverage statistics as a metric.

-- 
#!/usr/bin/perl   http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: New kwalitee test, has_changes

[Adam Kennedy]

Michael Graham wrote:

As I was downloading the newest version of Devel::Cover this morning, I
pondered on the concept of 1 Kwalitee point for coverage >= 80%, and
another for 100%, and how absolutely impossible it would be to set out
to establish these points for all the modules on CPAN. But it would be Good.



I think a point for >= 80% would be okay (for some definition of 80%).

But I think a more useful measure of kwalitee would be a 20%-30%
coverage test.


Something like that sounds much more reasonable than a high number.

Of course, if you've seen the first third of the PPI talk you realise we 
still have all the problems of having to use perl itself...


  #!/usr/bin/perl

  use Test::More 'no_plan';
  use Suitcase::Nuke trigger_in_seconds => 1;

  pass("Looks good");


oops, there goes the neighbourhood.

Collecting any sort of coverage data is a complete bitch. Let me just 
say right now that doing it across _all_ of CPAN is flat out impossible.


It's impossible.

Adam K

Re: Stringification, numification, and booleanification of pairs

[Juerd]

Damian Conway skribis 2005-09-22 23:04 (+1000):
> I disagree. I think it's likely that people will think of ~$val and +$val 
> the same way (i.e. as "coerce the value"), but that they will think of 
> "$val" quite differently (i.e. as "interpolate a useful string 
> representation of the entire value").

But will they also see "foo" ~ $bar as something different from
"foo$bar"? And what context does "foo{ $bar }" use?

In my opinion, making the string value in interpolation different from
the value in Str context is madness.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: [perl #25265] [PATCH] peek opcode

[Cory Spencer]

I'm closing this bug as 'rejected' because a corrected patch was never
submitted.  If you ever get it work, please do resubmit it.


Actually, I believe it was eventually applied, although I'm not sure why 
it wasn't updated in the RT.  In any event, two peek opcodes currently 
exist in the tree...


Thanks!

Cory

Re: Stringification, numification, and booleanification of pairs

[Nathan Gray]

On Thu, Sep 22, 2005 at 11:59:32AM -0400, Matt Fowles wrote:
> Well said!  I completely agree that string interpolation should be
> handled exactly the same as stringification.  I would like C< ("foo is
> $foo of course") eq ("foo is " ~ $foo ~ " of course") > at all times.

Yes.

S03 states:

  Unary ~ now imposes a string context on its argument, and + imposes a
  numeric context (as opposed to being a no-op in Perl 5). Along the
  same lines, ? imposes a boolean context, and * imposes a list context.

That seems to indicate that ~$foo eq "$foo".

If however, you want $foo to interpolate to something else, you can do
that in several ways:

  "hello { +$foo }"
  "hello { $foo.as(...) }"

Or when concatenating:

  "" ~ +$foo ~ ""
  "" ~ $foo.as(...) ~ ""

-kolibrie

Re: loadlib and libraries with '.' in the name

[Roger Browne]

Ross McFarland <[EMAIL PROTECTED]>

> > i'm not really sure what the solution here would be. you'd have to know  
> > what all of the possible extension types were and look to remove them if  
> > found...

How about removing the extension only if the rightmost dot is followed
by a letter?

Regards,
Roger Browne

Re: New kwalitee test, has_changes

[Paul Johnson]

On Fri, Sep 23, 2005 at 12:06:43PM +0200, Thomas Klausner wrote:

> Hi!
> 
> On Fri, Sep 23, 2005 at 12:54:42PM +1000, Adam Kennedy wrote:
> 
> > Collecting any sort of coverage data is a complete bitch. Let me just 
> > say right now that doing it across _all_ of CPAN is flat out impossible.
> > 
> > It's impossible.

And remember folks, only perl can parse Perl.

> I completly agree.

However, the problem is only slightly harder than testing all of CPAN.

> Now, if somebody sets up a system to collect coverage data thats generated
> at various decentralised machines and provides a nice interface to the
> results, CPANTS might be able to use coverage statistics as a metric.

This has been on the Devel::Cover TODO list for a while now.  I have
some ideas but nothing implemented.  If someone wants to take a look at
this, I suggest basing your work on cpancover in the Devel::Cover
distribution.  (I think I have mentioned this before.)

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Re: New kwalitee test, has_changes

[David Landgren]

Adam Kennedy wrote:

Michael Graham wrote:

[...]

But I think a more useful measure of kwalitee would be a 20%-30%
coverage test.



Something like that sounds much more reasonable than a high number.

Of course, if you've seen the first third of the PPI talk you realise we 
still have all the problems of having to use perl itself...


  #!/usr/bin/perl

  use Test::More 'no_plan';
  use Suitcase::Nuke trigger_in_seconds => 1;

  pass("Looks good");


oops, there goes the neighbourhood.

Collecting any sort of coverage data is a complete bitch. Let me just 
say right now that doing it across _all_ of CPAN is flat out impossible.


It's impossible.


Quite. I believe the only way is for the author to do the Devel::Cover 
dance and forward the results. It also distributes the workload out to 
where it should be done.


Since it's an optional step that has no direct bearing on the 
functionality of the module, it's a sign that the author takes care. In 
fact, uploading any coverage statistics would already be a sign of quality.


David

--
"It's overkill of course, but you can never have too much overkill."

Re: loadlib and libraries with '.' in the name

[Jonathan Worthington]

"Ross McFarland" <[EMAIL PROTECTED]> wrote:
there's also a really hacky win32  thing tacked on the end that removes 
the lib from the front, but it  would only work for cases without a path. 
i can do the same, but  that's pretty broken as is and it would seem you'd 
need to do the  opposite if the lib was specified in win32 speak and 
you're running  on unix-y system.


Taking the "lib" off the start on Win32 always felt a little hacky to 
me...it's certainly not a hard and fast rule but does apply in some cases. 
I guess it's a last-ditch effort - that whole chunk of code feels very 
"let's try everything we can possibly think of".  I think it's worth 
remembering that NCI = *Native* Calling Interface, so by using it you are 
inherently doing something platform specific anyway.  We can only hide away 
platform differences so far...the question is how far should we go.


Jonathan 

Re: [Maybe Spam] Re: DBD-mysql coverage == 56% - am I on drugs ??

[Paul Johnson]

On Fri, May 13, 2005 at 05:18:40PM +0100, Tim Bunce wrote:

> On Fri, May 13, 2005 at 10:51:56AM +0200, Paul Johnson wrote:
> > On Fri, May 13, 2005 at 03:00:39PM +1000, [EMAIL PROTECTED] wrote:
> > 
> > > [EMAIL PROTECTED] wrote:
> > > 
> > > >Covering the XS portion of the code with gcov is possible, and 
> > > >Devel::Cover
> > > >will create all kinds of nice webpages and statistics for you too.  
> > > >Paul Johnson may have this written up somewhere, but, if not, I should 
> > > >really write something up about this since I've used it to determine 
> > > >Perl's
> > > >test coverage.
> > 
> > I don't think I have written anything except the docs for gcov2perl,
> > which are minimal and incomplete.  I'd be happy to take doc patches for
> > gcov2perl if you think that's the right place to document this.
> > 
> > > Generating coverage tests for XS code - why are my hands shaking ?
> > 
> > It's not really that difficult.  You just need to get the right options
> > to gcc, either by compiling your perl with those options which means
> > they will automatically be passed to your XS code, or by making sure
> > your XS code is compiled with those options.  Then, on running your
> > tests, you will get one or more gcov files which you can run through
> > gcov2perl to add the gcov data to your perl coverage database.  Then,
> > running one of Devel::Cover's reports will report on your XS code along
> > with your Perl code.
> > 
> > OK.  In principle it's not really that difficult.
> 
> Would be _great_ if that could all be automated as far as possible.
> I presume the gcov files could be automatically detected and processed,
> for example.

I have recently released Devel::Cover 0.55 which has support for this.

If you are in a standard ExtUtils::MakeMaker environment you should just
be able to type

  $ perl Makefile.PL
  $ cover -test

and get a report with all your coverage, including gcov information if
available.

In a slightly less standard environment, such as that provided by
Module::Build, that might not work.  In that case the (recently updated)
docs for gcov2perl might give some clues on what to do, and I'd be
pleased to receive patches to make cover -test more general (and
robust).

The slides for my presentation at YAPC in Braga also have a little
information on this topic.

  http://www.pjcj.net/yapc/yapc-eu-2005-dc-advanced/slides/

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Re: skippable arguments in for loops

[Carl Mäsak]

I'm not sure we've reached consensus here, so I will try to summarize
what everyone said so far in order to clear my own head a bit. :)
Sorry in advance if i horribly misrepresent anyone's opinions.

Luke: Thinks the "_" syntax is no joke, since every language with
pattern matching abilities has it. Further, using "undef" won't work
because it means "this has to be undef" in signature unification.

Dks: Replies to Luke. Thinks that "undef" is more perl5ish, and that
"_" can disappear too easily, and is too Huffmanized. Doesn't think
"_" is obvious, but is sure we will end up using it if this feature is
added.

TSa: Prefers to rely on lazy evaluation, and says both tounge-in-cheek
and philosophically that if I don't want to care about some elements,
I should do so, and let Perl6 optimize. Proposes several ways of not
giving a name to a variable.

Yuval Kogman: Replies to David. Seems to repeat Luke's point about
value binding in signatures. Shows an example of value binding in
action. Argues for the "_" or "__" syntax. Thinks that making this
feature easy encourages reuse of calling code, not only callee code.

So, in summary, it's not obvious that this feature is needed at all
because things can be optimized away. Also, neither the "undef" nor
the "_" syntax have 100% support, and "undef" seems to have problems
related to signature unification.

Hm. For the time being I will assume that this functionality is not
sufficiently wanted to deserve its own syntax. But I must admit I'm
actually starting to like "_" in subroutine signatures... not sure if
it works well with positionals and the like, however.

// Carl

Re: [perl #17490] Magic is useless unless verifiable.

[Joshua Hoblitt]

On Thu, Sep 22, 2005 at 05:00:11PM +0100, Jonathan Worthington wrote:
> Interesting, thanks - they make some good suggestions there.  Our current 
> magic number is "13155a1" - I'm unsure of the rationale behind it, but 
> there may be a reason.  If we're going to change the packfile format, we 
> may as well make sure we're squeezing whatever use we can out of our magic 
> number.

You raise a good question; how was the magic number chosen?

> "Mark A. Biggar" <[EMAIL PROTECTED]> wrote:
> >Joshua Hoblitt wrote:
> >
> >>a) live with it
> >>b) change the magic number to be two identical bytes so the byte
> >>   ordering doesn't matter
> >>c) shrink the magic number to be a single byte

I left out another good option ... 4 identical bytes. ;)

> When I talked about doing something endian-independent, I meant something 
> along the lines of store a sequence of, say, 4 bytes that will have certain 
> values.  Forget reading the 4 bytes as an int at all, read it as a char[4] 
> and check each element is what it should be.  Makes adding support to 
> "file" easy enough, and is my preferred solution.

That would work if the magic 'number' was written as a 'string', which
is not.  Currently on x86 the magic number as written by parrot is
0x55a1 0x0131.

I've figured out how to make C to understand the current scheme
but it's rather ugly. 

--
16  lelong  0x013155a1 Parrot Bytecode (PBC),
>0  bytex   wordsize %d bytes,
>1  byte=0  little endian,
>1  byte=1  big endian,
>2  bytex   major %d,
>3  bytex   major %d,
>4  bytex   sizeof(INTVAL) == %d,
>5  byte=0  FloatType is IEEE 754
>5  byte=1  FloatType is i387 `long double'

16  belong  0x013155a1 Parrot Bytecode (PBC),
>0  bytex   wordsize %d bytes,
>1  byte=0  little endian,
>1  byte=1  big endian,
>2  bytex   major %d,
>3  bytex   major %d,
>4  bytex   sizeof(INTVAL) == %d,
>5  byte=0  FloatType is IEEE 754
>5  byte=1  FloatType is i387 `long double'
--

> So, now we have two design decisions:-
> 1) How to store the magic "number"
> 2) What the magic "number" should be

Good questions.

Cheers,

-J

--


pgpqYYa7Uy4K7.pgp
Description: PGP signature

Re: [perl #25265] [PATCH] peek opcode

[Joshua Hoblitt]

--
On Thu, Sep 22, 2005 at 05:47:31AM -0600, Cory Spencer wrote:
> 
> >I'm closing this bug as 'rejected' because a corrected patch was never
> >submitted.  If you ever get it work, please do resubmit it.
> 
> Actually, I believe it was eventually applied, although I'm not sure why 
> it wasn't updated in the RT.  In any event, two peek opcodes currently 
> exist in the tree...

Thanks for following up.

I guess I should have done a better job of checking to see if a similar
patch was ever applied.  I've changed the bug to 'resolved' for
posterity.

Cheers,

-J

--


pgpx6ohcrOCI0.pgp
Description: PGP signature

Re: loadlib and libraries with '.' in the name

[Ross McFarland]

On Sep 23, 2005, at 12:47 AM, Leopold Toetsch wrote:



On Sep 23, 2005, at 7:51, Ross McFarland wrote:


i was playing around with NCI stuff tonight and ran across a  
problem in loadlib. the following code does not work:


.local pmc lib_gtk
lib_gtk = loadlib "libgtk-x11-2.0"



The need for such libnames arises typically on debian and alikes,  
where not all -devel packages are installed. I see two  
possibilities here:
1) demand from user to either install the -devel pkg or symlink the  
shortname

2) Parrot stops trying to  ...



ext_start = strrchr(*lib_name, '.');



... strip extensions.


as my original email mentioned i think all of this try everything  
possible permutation is hacky and not a good idea. i think the real  
solution is to require that loadlib only gets the stem of the  
library. we can then reliably put on the appropriate extension for  
the platform and go about the normal searching stuff. if we know we  
always get the prefix we can also safely and correctly do the win32.  
if you look at the doc for loadlib it talks about library names, not  
files with paths with and without extensions. all of the examples are  
name only as well.


i think that library name (without extension and with or without lib  
on the front) is the best route. the doc almost already says as much,  
and i can extend it to be more explicit. we could cleanly handle all  
of the cases then. i don't want to make the decision for everyone.


-rm

Re: loadlib and libraries with '.' in the name

[Ross McFarland]

On Sep 23, 2005, at 3:43 AM, Roger Browne wrote:


Ross McFarland <[EMAIL PROTECTED]>


i'm not really sure what the solution here would be. you'd have  
to know
what all of the possible extension types were and look to remove  
them if

found...



How about removing the extension only if the rightmost dot is followed
by a letter?


that would solve the gtk case, but you can still envision legal  
library names that break this.


loadlib liborg.perl.something

that's a perfectly legal, albeit weird, library name.

-rm

Re: loadlib and libraries with '.' in the name

[Ross McFarland]

On Sep 23, 2005, at 4:41 AM, Jonathan Worthington wrote:


"Ross McFarland" <[EMAIL PROTECTED]> wrote:

there's also a really hacky win32  thing tacked on the end that  
removes the lib from the front, but it  would only work for cases  
without a path. i can do the same, but  that's pretty broken as is  
and it would seem you'd need to do the  opposite if the lib was  
specified in win32 speak and you're running  on unix-y system.



Taking the "lib" off the start on Win32 always felt a little hacky  
to me...it's certainly not a hard and fast rule but does apply in  
some cases. I guess it's a last-ditch effort - that whole chunk of  
code feels very "let's try everything we can possibly think of".  I  
think it's worth remembering that NCI = *Native* Calling Interface,  
so by using it you are inherently doing something platform specific  
anyway.  We can only hide away platform differences so far...the  
question is how far should we go.


yeah and no, it's native as in C not really platform. something like  
libm would be a good, though trivial, example. it's likely on every  
system you come across and if you want to get at something in it you  
should be able to. there's nothing platform specific about libm other  
than the file name. if we allow to code to say either


loadlib libm
or
loadlib m

then bindings for it would work on any platform that had lib m. i'm  
all for not trying every perm, in fact there's several of them that  
aren't handled in the current code as it stands. i think the real  
solution is to define what loadlib expects more thoroughly so that a  
reasonable and completely set of things can be attempted.


-rm

Graphing Perl Packages, updated

[Tels]

-BEGIN PGP SIGNED MESSAGE-

Moin,

I updated the graph-perl-usage package, to be found on my site or CPAN:

http://bloodgate.com/perl/graph/usage/
http://search.cpan.org/~tels/

(0.07 is the latest version, please use together with 0.30 of Graph::Easy)

I incorporated one idea from Randy, namely the --skip option. Give it a
regexp to skip packages matching that regexp. Example

./gen_graph --recurse=Math::BigInt --skip='^[a-z]+\z'

to skip all pragmas. (lowercase a-z package names).

There is also a new --flow option, that you can use to control the general
flow direction (up, north, left, right, down etc) of the resulting graph.

On the output side, you can now generate SVG and dot-output (to look at 
it) via Graph::Easy.

And you can now pass the desired format (as file extension) to "dot", 
meaning you can generate other file formats than png like:

./gen_graph --recurse=Math::BigInt --skip='^[a-z]+\z' --ext=ps

This would create a .ps file. :)

If you have any ideas how to make this even more usefull, please speak
now. I will have limited email reading/writing capabilities the next two
weeks, but I *will* respond to all emails/critics/praises, even though it 
may only be when I return. :)

Enjoy,

Tels

- --
 Signed on Fri Sep 23 17:25:30 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Build a man a fire, and he'll be warm for a day. Set a man on fire, and
 he'll be warm for the rest of his life." -- Terry Pratchett

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQzQheHcLPEOTuEwVAQHkrgf+LcaFo8wsAh75NShFF+CE4KJBRwVanoU0
AC2v4a694BSopxG1uLuUNLy5mHVqI+suvWzBkFvnkwtuEvGQNTm9zVOM8p3LeJx+
rU7Y3CtIti/zEWR+ZGVccl6EaN9bu4i3xPnZY4UNEAhmc8DaQMvfsV8Lnxab5ojs
pSJ2KRF1/80vBY6cGXYCXiDqsGEaXQ0+r8IluY3FknXjf7I/88mQNB4Fau5PzpEd
nyxcSXNVRYhZrrGSSimeB3afmvohMzKbdi36rXfG05/+oc94q/wYnK1Yap9rs+Ht
rCbjrr9abUb+wrx4x94LcyglHMgX2DXlYP5WAA2f9pjcTM/sEbvosQ==
=ZQ93
-END PGP SIGNATURE-

Re: Graphing Perl Packages, updated

[Michael G Schwern]

On Fri, Sep 23, 2005 at 05:38:32PM +0200, Tels wrote:
> If you have any ideas how to make this even more usefull, please speak
> now. I will have limited email reading/writing capabilities the next two
> weeks, but I *will* respond to all emails/critics/praises, even though it 
> may only be when I return. :)

Is the dependency detector pluggable?  The code I'm interested in graphing
requires modules indirectly through things like aliased.pm, base.pm and
Class::Autouse's superloader.  It would be nice if I could extend its dep
scanner to take these into account.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
'All anyone gets in a mirror is themselves,' she said. 'But what you
gets in a good gumbo is everything.'
-- "Witches Abroad" by Terry Prachett

Re: Graphing Perl Packages, updated

[Tels]

-BEGIN PGP SIGNED MESSAGE-

Moin,

On Friday 23 September 2005 19:15, Michael G Schwern wrote:
> On Fri, Sep 23, 2005 at 05:38:32PM +0200, Tels wrote:
> > If you have any ideas how to make this even more usefull, please
> > speak now. I will have limited email reading/writing capabilities the
> > next two weeks, but I *will* respond to all emails/critics/praises,
> > even though it may only be when I return. :)
>
> Is the dependency detector pluggable?  The code I'm interested in
> graphing requires modules indirectly through things like aliased.pm,
> base.pm and Class::Autouse's superloader.  It would be nice if I could
> extend its dep scanner to take these into account.

Not yet. Good idea. The relevant code is in parse_file() in gen_graph - it 
gets as option one .pm file and then does something with it.

The lopp for each file is in gather_data(), under the recurse branch:

I'll redesign the code to be more re-usable and move away from the "file" 
methodology. But I won't have time until mid-October.

Best wishes,

Tels

- -- 
 Signed on Fri Sep 23 19:29:38 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "If you want to travel around the world and be invited to speak at a lot
 of different places, just write a Unix operating system." -- Linus
 Torvalds

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQzQ8WHcLPEOTuEwVAQHvzQf9Fe7T0Q8gZ8Tm5x0OvgBsOflftLptABJJ
syBXXamTDtIqA2dABbdxXRCfp1wZna/V7MzZmhJoxaChFdCXAQHfCJLNHxMLZaha
wwu9HBm8edfATkDbS0pft4RmETR66gjSHHUrGyPutKBCfmuOx1Waqp/462xagAOf
lxxeyUOUp/D+qAQTqBP1uWjZ1T0RM4dGdvII9M59vKh6KRf9Sqtjnl3+CXFF2vTX
VwVyybGxG8yq4zgX7IbRrOQu+tQzn7mt+I2H9hjNIFLF+O/DccPv9IbygsCgKTRT
aLmGb2lb+OISyxDi3+t7ZZ+7xpd9me0Az0eNvCBSd2mOd65486MWRA==
=zn3o
-END PGP SIGNATURE-

TODO: Find Copied and Pasted Code?

[chromatic]

I wonder what running PMD's CPD plugin on all of our .c files would
discover.  Maybe it'd find places of insufficient abstraction.

Does anyone have a working Java development environment and sufficient
time to experiment?

http://pmd.sourceforge.net/cpd.html

-- c

Re: TODO: Find Copied and Pasted Code?

[Steve Peters]

On Fri, Sep 23, 2005 at 12:52:04PM -0700, chromatic wrote:
> I wonder what running PMD's CPD plugin on all of our .c files would
> discover.  Maybe it'd find places of insufficient abstraction.
> 
> Does anyone have a working Java development environment and sufficient
> time to experiment?
> 
>   http://pmd.sourceforge.net/cpd.html
> 

Actually, you don't need much of a development environment to use it.  The
page above has a link to a Java WebStart link that will allow you to install
and use it directly.

Steve Peters
[EMAIL PROTECTED]

Re: TODO: Find Copied and Pasted Code?

[Steve Peters]

On Fri, Sep 23, 2005 at 03:04:42PM -0500, Steve Peters wrote:
> On Fri, Sep 23, 2005 at 12:52:04PM -0700, chromatic wrote:
> > I wonder what running PMD's CPD plugin on all of our .c files would
> > discover.  Maybe it'd find places of insufficient abstraction.
> > 
> > Does anyone have a working Java development environment and sufficient
> > time to experiment?
> > 
> > http://pmd.sourceforge.net/cpd.html
> > 
> 
> Actually, you don't need much of a development environment to use it.  The
> page above has a link to a Java WebStart link that will allow you to install
> and use it directly.

A slight correction.  You will need a Java 1.4 or higher installed on your
system.  Mac OS X 10.3 and above should have that by default.  Users on
other environments may need to install a Java runtime (JRE) for Java 1.4
before trying.

Steve Peters
[EMAIL PROTECTED]  

Re: loadlib and libraries with '.' in the name

[Joshua Juran]

On Sep 23, 2005, at 3:47 AM, Leopold Toetsch wrote:


On Sep 23, 2005, at 7:51, Ross McFarland wrote:

i was planning on playing around with gtk+ bindings and parrot and 
went about looking around for the work that had already been done and 
didn't turn anything up. if anyone knows where i can find it or who i 
should talk to i would appreciate that info as well.


Google for "NCI gtk". There is also a weekly summary entry but the 
xrl.us shortcut seems to have expired.


I was wondering about that.  I Googled for "tinyurl considered harmful" 
and was surprised to find only one message, discussing the phishing 
risks.  I found no mention of the risk of outsourcing a bottleneck to a 
third party who has zero obligation or direct interest to continue 
providing the service.


From :


Do Metamark links expire?

The Metamark urls expire after five years or two years after the last 
usage - whichever comes later. However, if a link is never used, it 
will expire after two years. This should mean that as long as a link 
is on a public page, some search engine will visit it and keep it 
alive.


Of course, this is subject to change and is no promise but just my 
intentions as of this writing. If you want guarantees you can make 
your own service.


To be quite frank, I'm astonished the practice exists here in the first 
place.  In my opinion it goes directly against the spirit of the Web 
envisioned by Tim Berners-Lee.  A better practice would be to post long 
URL's within angled brackets.  And there's no reason you can't do both, 
either.


Josh

Re: Graphing Perl Packages, updated

[Michael G Schwern]

On Fri, Sep 23, 2005 at 07:33:04PM +0200, Tels wrote:
> Not yet. Good idea. The relevant code is in parse_file() in gen_graph - it 
> gets as option one .pm file and then does something with it.
> 
> The lopp for each file is in gather_data(), under the recurse branch:
> 
> I'll redesign the code to be more re-usable and move away from the "file" 
> methodology. But I won't have time until mid-October.

Ok, thanks.  I'll let you know if I get any tuits to work on it before
then.

-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Reality is that which, when you stop believing in it, doesn't go away.
-- Phillip K. Dick

Re: Graphing Perl Packages, updated

[Michael G Schwern]

On Fri, Sep 23, 2005 at 04:03:32PM -0700, Jan Dubois wrote:
> > Ok, thanks. I'll let you know if I get any tuits to work on it
> > before then.
> 
> Maybe I'm missing something, but wouldn't it make sense to use
> Module::ScanDeps for this and put any additional heuristics in
> there?

Module::ScanDeps isn't pluggable, either.  In fact, none of the dep scanners
I've come across are. 

Some of the heuristics I need are general purpose, some are specific to my
company's code.  But they fall into two categories:

*  A module which loads another named module.  base.pm and aliased.pm are 
   examples.  For these your dep scanner needs to know the syntax of the
   loading module.  Sometime of these are on CPAN and thus of general use,
   some are not.

use base 'Foo::Bar';

use aliased 'Foo::Bar';

use aliased;
my $Customer = alias 'My::Company::Customer';


*  Loading of modules on demand, such as Class::Autouse's superloader.
   In this case your dep scanner has to find class method calls and infer
   module use from that.

use Class::Autouse qw(:superloader);

print CGI->b("Wow!");


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Life is like a sewer - what you get out of it depends on what you put into it.
- Tom Lehrer

[ANNOUNCE] Test::Simple/More/Builder 0.61

[Michael G Schwern]

http://www.pobox.com/~schwern/src/Test-Simple-0.61.tar.gz
or
http://svn.schwern.org/CPAN/Test-Simple/trunk
or 
a CPAN mirror near you.

A small raft of small fixes have happened between 0.60 and 0.61 as well
as a few new features.

New Features:

* Test::Builder::Module has been added to help test module authors.  It
  implements the oft requested import() method to parse plan information
  on the use line just as Test::More does.  If you base your testing
  module on Test::Builder::Module it will no longer need to rely on
  Test::More to set the plan.

* Added the oft requested BAIL_OUT() function to Test::More.

* Added a no_diag() method to Test::Builder.

* The standard failure diagnostics now include the name of the test for
  easier recognition when run through Test::Harness.

* cmp_ok(), like() and unlike() will now warn if given uninitialized values.

* cmp_ok() will now throw warnings if the given comparison warrents it.
  For example, cmp_ok(2, '==', 'foo') will warn about 'foo' not being
  numeric.

* Test will now report *both* the number of tests failed and if the
  wrong number of tests was run.  Previously if both occured it would
  only report the latter.

* For the purposes of calculating the exit code, missing or extra tests
  are not considered failures.  Should there be no failures but the wrong
  number of tests the exit code will be 254.


Deprecations:

* The "no_diag" option to Test::More has been deprecated.  Use
  Test::More->builder->no_diag(1) instead.

* Test::Builder->BAILOUT is now BAIL_OUT to match all the other naming
  conventions.  BAILOUT has been deprecated.


Bug fixes:

* A large number of bugs related to overloaded objects have been fixed.
  See the change log below for details.



0.61  Fri Sep 23 23:26:05 PDT 2005 
- create.t was trying to read from a file before it had been closed 
  (and thus the changes may not have yet been written). 
* is_deeply() would call stringification methods on non-object strings 
  which happened to be the name of a string overloaded class. 
  [rt.cpan.org 14675] 
 
0.60_02  Tue Aug  9 00:27:41 PDT 2005 
* Added Test::Builder::Module. 
- Changed Test::More and Test::Simple to use Test::Builder::Module 
- Minor Win32 testing nit in fail-more.t 
* Added no_diag() method to Test::Builder and changed Test::More's 
  no_diag internals to use that. [rt.cpan.org 8655] 
* Deprecated no_diag() as an option to "use Test::More".  Call the 
  Test::Builder method instead. 
 
0.60_01  Sun Jul  3 18:11:58 PDT 2005 
- Moved the docs around a little to better group all the testing 
  functions together. [rt.cpan.org 8388] 
* Added a BAIL_OUT() function to Test::More [rt.cpan.org 8381] 
- Changed Test::Builder->BAILOUT to BAIL_OUT to match other method's 
  naming conventions.  BAILOUT remains but is deprecated. 
* Changed the standard failure diagnostics to include the test name. 
  [rt.cpan.org 12490] 
- is_deeply() was broken for overloaded objects in the top level in 
  0.59_01.  [rt.cpan.org 13506] 
- String overloaded objects without an 'eq' or '==' method are now 
  handled in cmp_ok() and is(). 
- cmp_ok() will now treat overloaded objects as numbers if the comparison 
  operator is numeric. [rt.cpan.org 13156] 
- cmp_ok(), like() and unlike will now throw uninit warnings if their 
  arguments are undefined. [rt.cpan.org 13155] 
- cmp_ok() will now throw warnings as if the comparison were run  
  normally, for example cmp_ok(2, '==', 'foo') will warn about 'foo'  
  not being numeric.  Previously all warnings in the comparison were 
  supressed. [rt.cpan.org 13155] 
- Tests will now report *both* the number of tests failed and if the 
  wrong number of tests were run.  Previously if tests failed and the 
  wrong number were run it would only report the latter.  
  [rt.cpan.org 13494] 
- Missing or extra tests are not considered failures for the purposes 
  of calculating the exit code.  Should there be no failures but the 
  wrong number of tests the exit code will be 254. 
- Avoiding an unbalanced sort in eq_set() [bugs.perl.org 36354] 
- Documenting that eq_set() doesn't deal well with refs. 
- Clarified how is_deeply() compares a bit. 
* Once again working on 5.4.5. 


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Insulting our readers is part of our business model.
http://somethingpositive.net/sp07122005.shtml

Re: loadlib and libraries with '.' in the name

[Ross McFarland]

On Sep 22, 2005, at 10:51 PM, Ross McFarland wrote:



i was playing around with NCI stuff tonight and ran across a  
problem in loadlib. the following code does not work:


for those of you interested:
https://rt.perl.org/rt3/Ticket/Display.html?id=37258

i'll work on porting the pir to a .t test at some point if that would  
be desirable.


later,
-rm

Re: Stringification, numification, and booleanification of pairs

[TSa]

HaloO Juerd,

you wrote:

Damian Conway skribis 2005-09-22 23:04 (+1000):

I disagree. I think it's likely that people will think of ~$val and +$val 
the same way (i.e. as "coerce the value"), but that they will think of 
"$val" quite differently (i.e. as "interpolate a useful string 
representation of the entire value").


Aha, that to me implies three things

  1) the circumfix operator " " has an arity >= 1 with the not yet
 interpolated string beeing the only non-invocant parameter
 (that is somewhat untrue because the string is sliced into
  a list of strings of the stuff between the variable data
  interleaved with links to the enteties what replaces it
  ---in other words there is a parser macro that converts "..."
  to a call of a printf like multi dispatched on all the variables
  and code literals mentioned in the string)

  2) The arity > 1 part is dispatched according to SMD/MMD in effect
 at the call site or according to the definition the compiler
 knows about when compiling it. Question: which is it?

  3) there's an arity == 1..Inf catch-all implementation that (eagerly?)
 iterates the incoming arglist and invokes the stringification
 prefix op ~ on them---these are of course dispatched as well

If that does not give enough rope the users have to switch from
operator " " to output formatters or whatever.



But will they also see "foo" ~ $bar as something different from


I might *not* be representative but nonetheless I try to explain what
I perceive. Sorry, if that is intimidating this list. And please tell
me if that is the case---thanks.

That beeing said here I come:

  We have:  "foo" ~ $bar
  I see: a juxtaposition of two operators and an item,
 all three separated by whitespace

At that point I start to wonder: "What do I know about these three things?"
And I guess the compiler does the same ;)



"foo$bar"? And what context does "foo{ $bar }" use?


We have: "foo$bar"
I see: a single invocation of operator " " with a string and an item.
   (In other words, a parametric string!)



In my opinion, making the string value in interpolation different from
the value in Str context is madness.


I would call it late binding!
The decision what difference it makes is deferred :)

But I agree that the catch-all case from 3) above should
result in whatever you mean with "the value in Str context".
Actually, the outcome then still depends on what is bound lately
to the implicit, dispatched calls of prefix ~ and again I agree
that the default behaviour shouldn't have any surprises in store.
Or in yet another way: all the MTOWTDIs should yield the same
result unless the hooks on particular ways are bound to something
non-standard.

If you feel at unease with these multiple levels of lately bound
uncertainties when you write your code, then just put in more
type constraints. Unfortunately the enforcement level of such
contraints seems to be bound lately as well---and that puts me
at unease *before* I have even started writing Perl6 code =8)


What could $someone.sees($helicopter) mean?
Think e.g.

   $someone := 'vietnamese child in the sixties';
   $someone := 'insured person waiting for the rescue team';
   $someone := 'paraglider flying high in the air';
   $someone := your_pick();

Questions I pose myself while flying in

   my TSa $helicopter;

through spacetime are for example:

   Does the vietnamese child expect medical help?
   How does the rescue team arrive? By car?
   What sex does the paraglider have?
   What type of action does the .sees method do
   with my $helicopter, when invoked
   on the return type of &your_pick?
   Should I be carefull and allow only read access to my $helicopter?
   What $word.does(German) yields a %dictionary lookup where
   :key.does(English)?

--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Stringification, numification, and booleanification of pairs

[Juerd]

TSa skribis 2005-09-23 15:42 (+0200):
>   1) the circumfix operator " " has an arity >= 1

I think it's parsed, not having specific arity.

>   We have:  "foo" ~ $bar
>   I see: a juxtaposition of two operators and an item,
>  all three separated by whitespace

I can only hope you mean two items and one operator.

> At that point I start to wonder: "What do I know about these three things?"

> >"foo$bar"? And what context does "foo{ $bar }" use?
> We have: "foo$bar"
> I see: a single invocation of operator " " with a string and an item.

I see a shorter way to write "foo" ~ $bar, as implemented by the
circumfix "" operator.

> $TSa.greeting := "HaloO"; # mind the echo!

echo off


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: skippable arguments in for loops

[TSa]

HaloO Carl,

you wrote:

TSa: Prefers to rely on lazy evaluation, and says both tounge-in-cheek
and philosophically that if I don't want to care about some elements,
I should do so, and let Perl6 optimize. Proposes several ways of not
giving a name to a variable.


This hits home. And I did at no point impute carelessness on your part
---unless of course if you don't want to, err? ... care!
Sorry, couldn't resist ;)



Hm. For the time being I will assume that this functionality is not
sufficiently wanted to deserve its own syntax. But I must admit I'm
actually starting to like "_" in subroutine signatures... not sure if
it works well with positionals and the like, however.


And could easily give a type markup with sigils and get $_, &_, @_ and %_ 
ignored. I here $Yoda speak "funny that is" :)

--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Stringification, numification, and booleanification of pairs

[Mark Reed]

On 2005-09-23 06:08, "Juerd" <[EMAIL PROTECTED]> wrote:
> In my opinion, making the string value in interpolation different from
> the value in Str context is madness.

Hear, hear!  I agree 100%.  This is another place where we should move the
Rubyometer down rather than up, I think (to_s vs. to_str, anybody?).

Re: Stringification, numification, and booleanification of pairs

[TSa]

Halo,

someone has switched off my echo ;)

Juerd wrote:

TSa skribis 2005-09-23 15:42 (+0200):


 1) the circumfix operator " " has an arity >= 1



I think it's parsed, not having specific arity.


Of course it's parsed, how else should it reach the semantic analyzer?
And I don't consider (arity >= 1) as a very specific constraint :)
Actually the subtyping rules should distinguish between optional and
required arity with the latter beeing more specific. But I've no idea
what distance quantification they should have such that e.g. 5 optionals
are outperformed by one required or whatever.



 We have:  "foo" ~ $bar
 I see: a juxtaposition of two operators and an item,
all three separated by whitespace



I can only hope you mean two items and one operator.


So, at last there is hope somewhere. But I fear I'm hopelessly
drowned in my own misconceptions and really meant two ops and an
item. But I hope---ahh hope again---that the optimizer boils down
the "foo" invocation to 'foo' at compile time. Which immediately
raises the question whether I consider ' ' as an operator or not :)
Do you?

OTOH, I think we agree that a "foo $bar" is parametric with respect
to $bar and as such requires some code to evaluate it? The same applies
to matches /foo.*/ which are backed by some code that is build from
the text between the //. And how is this creation process of a match
closure parameterizable other then giving the resulting code a parameter
from which a new closure is created at runtime? And why is this not the
case for string interpolation? To a certain extent I see these two
closure manipulations as inverse operations. Interpolation creates
strings while matching analyzes them. But they don't guarranty mutual
round-trip invariance.

So the only thing that the language specification has to define in|for
my eyes is a level of unspecificity that the return value of " "
shouldn't exceed. In other words it's forced to return a Str and
nothing less specific like a Value or an Item. And then my mind
transforms the "foo" ~ $bar perception of my eyes into the mental
typing Str ~ Item.


Just ranting again a bit of my difficulties of integrating junctions
into my mental picture. How many times do you expect foo and ~ in

  "{foo}" ~ $bar

beeing called? Consider ($bar = 42) versus ($bar = any(1,2,3)).

In the latter case we expect the junctive value to contain something
like any( "{foo}" ~ 1, "{foo}" ~ 2, "{foo}" ~ 3 ), right? That might
interpolate "{foo}" once and call infix ~ three times, but what if
foo shall count the number of invocations of ~ on Ints? Not to mention
that the possibility of a junction in $bar means that it becomes a
potential postfix meta operator that swallows ~ and after analyzing
it as an infix operator reaches out---at runtime fully dynamic---and
pulls in the return value of "{foo}" three times, or perhaps calculates
it three times.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Stringification, numification, and booleanification of pairs

[Juerd]

TSa skribis 2005-09-23 19:11 (+0200):
> >> We have:  "foo" ~ $bar
> >> I see: a juxtaposition of two operators and an item,
> >>all three separated by whitespace
> >I can only hope you mean two items and one operator.
> So, at last there is hope somewhere. But I fear I'm hopelessly
> drowned in my own misconceptions and really meant two ops and an
> item. But I hope---ahh hope again---that the optimizer boils down
> the "foo" invocation to 'foo' at compile time. Which immediately
> raises the question whether I consider ' ' as an operator or not :)

Ah, the "" operator. But still, "foo" as a whole is an item too. (The
entire expression is too, but I'm not considering that, for simplicity)

> OTOH, I think we agree that a "foo $bar" is parametric with respect
> to $bar and as such requires some code to evaluate it? The same applies
> to matches /foo.*/ which are backed by some code that is build from
> the text between the //. And how is this creation process of a match
> closure parameterizable other then giving the resulting code a parameter
> from which a new closure is created at runtime? And why is this not the
> case for string interpolation? To a certain extent I see these two
> closure manipulations as inverse operations. Interpolation creates
> strings while matching analyzes them. But they don't guarranty mutual
> round-trip invariance.

I have a hard time parsing this. Are you suggesting that interpolation
is somehow translated to a sub call like i("foo ", $bar)?

> Just ranting again a bit of my difficulties of integrating junctions
> into my mental picture. How many times do you expect foo and ~ in
>   "{foo}" ~ $bar
> beeing called? Consider ($bar = 42) versus ($bar = any(1,2,3)).

Once. The foo is not part of the junction, so it is not changing in
different iterations of autothreading.

Consider:

sub foo { @_.join(":") }
my $bar = 2;
my $baz = foo($bar *= 2, 1|2|3);
say $bar;

The foo call line evaluates to:

my $baz = foo(4, 1) | foo(4, 2) | foo(4, 3);
# Except that the 4 is really $bar, the lvalue return value of *=

not to:

my $baz = foo($bar *= 2, 1) | foo($bar *= 2, 2) | foo($bar *= 2, 3);

So eventually, "4" is said, not "16", and there is no question of which
$bar *= 2 is evaluated first.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html