Re: Binary distributions

[Andreas J. Koenig]

> On Sun, 29 Jan 2006 15:05:02 -0800, Tyler MacDonald <[EMAIL PROTECTED]> 
> said:

  > Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> wrote:
 >> Did anybody here have played with CPANPLUS::Dist::Deb?
 >> http://search.cpan.org/dist/CPANPLUS-Dist-Deb/
 >> 
 >> Believing its documentation, it should build a valid Debian package
 >> and take care of its dependencies (dunno if that means just listing
 >> or actually adding them in the package).

  > This excited me, but even with all the debian helper utils installed
  > and CPANPLUS on default settings running as root, it crashes not being able
  > to find the right dist_cpan object out of CPANPLUS. :-(

FWIW, we're using dh-make-perl to create debian packages from CPAN modules.


-- 
andreas

Re: Binary distributions

[Andreas J. Koenig]

> On Sun, 29 Jan 2006 17:13:40 -0800, Tyler MacDonald <[EMAIL PROTECTED]> 
> said:

  > Andreas J. Koenig <[EMAIL PROTECTED]> wrote:
 >> FWIW, we're using dh-make-perl to create debian packages from CPAN
 >> modules.

  > Andreas,
  > I've used this tool a few times when a CPAN module wasn't already
  > available in unstable/main, but I havent looked into it too closely. I'm
  > curious, does it do anything about .so's that XS modules need, or build vs.
  > runtime dependancies in environments that support it (Module::Build, etc)?

Recently I haven't had to work with XS modules that have not already
an associated Debian package. Support for modules that have only a
Build.PL seems to be missing. The manpage is not promising too much
when it says:

BUGS
   Several, let me know when you find them.

:/
-- 
andreas

Re: Module::Install (Was: YAML and Makefile.PL)

[Smylers]

Adam Kennedy writes:

[Tels writes:]

> > if there is a problem with Module::Install, you have to update all
> > your dists with the new version
> 
> But if there is a problem with EU::MM or Module::Build, you have to 
> update every installation in the entire world with the new version.

Not necessarily; for example if the problem is just with, say, Cygwin
then only Cygwin users need to update their installations -- something
which they have control over, and only need to do once for all module
installations to work again.

> Module::Install is more about containing the problem. If there's a bug
> related to Module::Install, at least you only have to fix the problem
> in one place. And the number of bugs that require a rerelease is
> falling, most of the recent versions have fixed things like
> cygwin-specific bugs ...

So a module author who doesn't use Cygwin might not care enough to
bother doing a new dist of my module just for a Cygwin fix in
Module::Install.

But a Cygwin user needs all of the modules she uses to have been updated
like this, otherwise some modules are no longer installable and it's
hard for her to remedy the situation -- certainly much more effort than
simply upgrading Module::Build locally.

And even if all authors did upgrade all their distributions with
Module::Install changes, that would still be less than ideal for the
amount of noise that it creates in things like Cpan recent changes
listings.

If a bug is only in one place, it only needs fixing in one place ...

Smylers

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[David Cantrell]

Adam Kennedy wrote:

A testing system should only be sending FAIL reports when it believes it 
has a platform that is compatible with the needs of the module, but when 
it tries to install tests fail.


So how, then, do I tell the testing system "this module only works on 
Unix-like filesystems on Unix-like OSes"?


--
David Cantrell

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[David Cantrell]

Luke Closs wrote:


I'm somewhat new to the Perl community, so I don't know much history
about PPM + perl, but I think PPM is actually a pretty good tool.


The history is that Activestate was originally a Windows-only product. 
Windows users generally don't have compilers, so they needed a way to 
get modules with C parts to them onto their users' machines.  And if 
you're going to invent a package manglement system for C-ish modules you 
might as well use it for pure perl modules too.



We use it extensively for the applications we develop...
This makes it really easy to deploy and re-use code.  I'm really
interested in how other people who build products in code build/deploy
their stuff.


We build modules into Debian packages.  That way those with C-ish bits 
can keep track of their dependencies on libwibble version 1.01234, or on 
version 37.4 of our database schema, or whatever.  I don't think PPM 
handles that.



I think this would be rad:


This court finds you guilty of gross abuse of language.  Your sentence 
is to translate the perl docs into Swahili.



 - PPM becomes part of the perl core


No thanks.  The core is already FAR too big, and this would just 
duplicate functionality which already exists both in the perl core 
(CPAN.pm) and in operating systems (RPM, Debs, ports, ...).


PPM is only really useful on Windows.  It makes sense for it to bundled 
with the main Windows port of perl, but not to include it otherwise.



 - All CPAN packages are built to into PPDs automatically on common
   platforms


Thankyou for volunteering to do this.  Note, however, that the only 
place that PPM is common is Windows, so that's the only one you won't be 
wasting your effort on.



This would allow non-perl people to install perl packages much easier,


There are lots of programs out there which are built using perl but for 
which the user need not know a thing about perl.  They generally use 
stuff like autoconf and make, not ppm.



without having to mess with the CPAN shell and running tests.


Tests are a Very Good Thing.  If you're installing my code on a platform 
I've never seen, such as Windows 2000, then I want you to run the tests, 
and I want my code to not install if they fail.  That way, when you 
email me to say "it doesn't work" you'll be able to include something 
useful like the test results and there's a possibility that I might be 
able to fix the code for you.


And anyway, what's so hard about "perl -MCPAN -e 'install Foo::Bar'"?

> It

would also make installing CPAN packages into hosted environments much
easier.


Can you explain why?  I don't understand.  Surely if a hosting company 
doesn't let people install stuff from the CPAN they'll be just as 
idiotic about the CPPMAN?


--
David Cantrell

Re: Binary distributions

[David Cantrell]

Tels wrote:

On Saturday 28 January 2006 08:20, Tyler MacDonald wrote:

That is such an incredibly good idea. I've got plenty of bandwidth
to burn and I'm willing to set up debian.cpan.org.
Of course you must reliaze that, except for pure-perl modules and very 
controlled environments, binary distributions are doomed to fail.


You simple cannot guess what libraries/compiler/system/kernel the user  
has installed, unless you know the distribution and version *and* require 
that the user never updates anything.


There is a reason that modules are compiled/linked against the target 
system prior to installation, and there is also a reason to run the 
tests: to assure that that step really worked.


FreeBSD might get away with that because the user will ever only install 
their ports and they can make sure that they all play together. For 
everything else, this becomes a maintanance nightmare and I wish to be no 
part of that :)


Actually, this isn't so bad on Debian.  The packaging system copes with 
having dependencies on particular versions of other packages, and Debian 
is VERY stable - libfoo just doesn't randomly change version.


--
David Cantrell

Re: Binary distributions

[Barbie]

On Sat, Jan 28, 2006 at 09:34:09AM -0800, Tyler MacDonald wrote:
> 
>   From what I gather, CPANPLUS is a linear package building
> system, whereas YACsmoke is a wrapper around that that tries to build as
> many packages as is humanly (er, computerly) possible on a system, with the
> side effect of sending it's results through Test::Reporter. YACsmoke also
> can maintain a database of what it has built and what it hasn't, allowing a
> YACsmoke system to eventually exhaustively build every single package on
> CPAN without building the same one twice. Is this correct?

Sort of. CPANPLUS also maintains a database for the current run, so if
you have a list of 20 distributions you are testing, if 5 of those have
a prerequisite for the same distribution, CPANPLUS internally only
makes/tests it once, but adding each distribution path to @INC. However,
the state information that CPANPLUS stores doesn't include the test
result of a distribution.

CPAN::YACsmoke on the other hand, does record the test result. This
means that if it tried to build a distribution (currently checks agains
the latest version), which reports a FAIL or NA, any distribution that
requires it will have their test results graded as ABORTED and NA
respectively. The ABORTED result does not get reported to CPAN Testers.

The part that is missing currently, is that if a distribution that is a
prerequisite now PASSes, there is no code to actively change all those
ABORTED to NONE, so that the requiring distribution can be retested.
This is part of my todo list.

> > What would the plugins for .deb, .rpm and .ppm do? Currently we just
> > pass the path to CPANPLUS and let CPANPLUS unwrap, make and test the
> > distribution. We then just interrogate the results.
> 
>   These plugins would execute *after* YACsmoke/CPANPLUS has done it's
> work, but before it's cleaned up after itself, and generate the actual
> .deb/.rpm/.ppm files.

I would see this as a different system, perhaps for someone who actively
maintains a repository for that particular install package. I would
prefer to see a code base that uses the YACSmoke database, rather than
used as a plugin. The .cpanplus build directories are not removed once
testing is complete, so the blib directories are all still available
after a test run.

YACSmoke does provide a purge facility, but it doesn't run automatically
after a test run, you have to manually instigate it.

> > Perhaps this is something you meant for CPANPLUS to handle, in which
> > case I'm sure that's something Jos would be interested in, as he has
> > previously looked at some kind of binary support.
> 
>   Well, maybe the actual low-level package generation could be kicked
> down a level, but the whole reason I thought of using YACsmoke for this was
> because of it's "grab everything and try to build it" nature.

YACSmoke would certianly be useful as a first stage, to ensure you
only package distributions that pass the tests for your platform.

> > I plan to find time soon to complete the tests required for the next
> > release of CPAN::YACSmoke, so if what you want does relate to
> > CPAN::YACSmoke I can start taking a look and see what needs to be done
> > to implement it.

I will look into this further, but it'll be lower on my todo list, as it
will be driven by packagers rather than testers.

Barbie.

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[demerphq]

On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote:
> Luke Closs wrote:
> PPM is only really useful on Windows.  It makes sense for it to bundled
> with the main Windows port of perl, but not to include it otherwise.

I don't know if I buy that. Im assuming that ppm is bundled with all
of the AS builds of perl, which arent restricted to Windows.

> >  - All CPAN packages are built to into PPDs automatically on common
> >platforms
>
> Thankyou for volunteering to do this.  Note, however, that the only
> place that PPM is common is Windows, so that's the only one you won't be
> wasting your effort on.

I dont agree. In my experience getting admins to compile stuff can be
a real pain. I do my main dev on win32 and sometimes have to migrate
the code over to HP-UX and in my experience getting the admins to
install stuff from CPAN is a pain, especially when it involves
compilation. If precompiled binaries were available and the install
process was smoother then I think things would be easier.

> > This would allow non-perl people to install perl packages much easier,
>
> There are lots of programs out there which are built using perl but for
> which the user need not know a thing about perl.  They generally use
> stuff like autoconf and make, not ppm.

You are speaking of developer/admin types from the *nix/dev tradition.
If you arent lucky enough to work with people like this then stuff
that requires such process is almost useless to you.

> > without having to mess with the CPAN shell and running tests.
>
> Tests are a Very Good Thing.  If you're installing my code on a platform
> I've never seen, such as Windows 2000, then I want you to run the tests,
> and I want my code to not install if they fail.  That way, when you
> email me to say "it doesn't work" you'll be able to include something
> useful like the test results and there's a possibility that I might be
> able to fix the code for you.

I agree. I think not bundling tests with ppm installs was a bad call.
The tests arent run on the target machine, and the user doesnt have a
regression framework to utilize if spot fixes are required. With a
cpan module I can tweak the package, run the regression tests and then
reinstall. With ppm tht isnt possible.

> And anyway, what's so hard about "perl -MCPAN -e 'install Foo::Bar'"?

I think the main issue is it requires a higher skill level to use than
something like ppm. Ive been surprised a number of times at the
reaction of non perl types to the requirements for using CPAN. I was
surprised at how many developer and/or admin types I have encountered
who found it too difficult to work with.

BTW, while reading this debate I cant help but think that there is a
certain amount of talking at cross purposes here. Some of the comments
suggest to me that the person stating them hasnt thought much about
other peoples needs or perceptions. This is a big issue with a lot of
angles, and what suits one person, enviornment, or tradition isnt
necessarily the end of the story. For instance comments like

"Only OS-Foo people dont have compilers, therefore a solution to the
compilation problem is only of use to the OS-Foo users and the rest of
us shouldnt care"

"My favorite OS has a perfectly good packaging system so Perl doesnt
need one at all"

"My favorite OS has a perfectly good packaging system so everybody
should use it"

don't seem to me to be very productive.

Im not saying this to anyone in particular its just a general observation.

 yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"

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

[Leopold Toetsch]

Bob Rogers (via RT) wrote:


   It seems that Continuation needs the same set_address magic as
Exception_Handler in order to return values. 


Yep. At least as long we don't have better support for creating limited 
continuations that are able to return some results. There is of course 
the 'standard' way to achieve this effect with a helper subroutine 
'call-with-current-continuation', but there are probably some more HLL 
semantics, which translate to the usage of the patch.


Thanks, applied - r11379.
leo

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[demerphq]

On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote:
> Adam Kennedy wrote:
>
> > A testing system should only be sending FAIL reports when it believes it
> > has a platform that is compatible with the needs of the module, but when
> > it tries to install tests fail.
>
> So how, then, do I tell the testing system "this module only works on
> Unix-like filesystems on Unix-like OSes"?

Hopefully it will be something like:

$I::don't::bother::to::write::portable::code=1;

;-)

How do you define "unix-like filesystems on unix-like oses" btw? Would
win32 count and what reason would you give for your answer, whatever
it is.

Yves



--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[David Golden]

demerphq wrote:

On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote:

Adam Kennedy wrote:


A testing system should only be sending FAIL reports when it believes it
has a platform that is compatible with the needs of the module, but when
it tries to install tests fail.


So how, then, do I tell the testing system "this module only works on
Unix-like filesystems on Unix-like OSes"?


Hopefully it will be something like:
$I::don't::bother::to::write::portable::code=1;

How do you define "unix-like filesystems on unix-like oses" btw? Would
win32 count and what reason would you give for your answer, whatever
it is.


Well, the more generalized problem is how to you signal to an automated 
test that you're bailing out as N/A for whatever reason?  For Perl 
itself, it's easy enough for the smoke test to check if the required 
version of Perl is available -- and the smoke test is smart enough not 
to try to install an updated version of Perl to satisfy the dependency. 
 It bails out with N/A instead.


What's a clean, generic mechanism for a distribution to signal "please 
check this dependency and abort if it's not satisfied"?  Something in 
the META.yml (e.g. Alien::*)?  Send a specific string to STDERR?  Send a 
specific exit codes?  Ugh.  Other ideas?


David

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Adam Kennedy]

David Cantrell wrote:

Adam Kennedy wrote:

A testing system should only be sending FAIL reports when it believes 
it has a platform that is compatible with the needs of the module, but 
when it tries to install tests fail.



So how, then, do I tell the testing system "this module only works on 
Unix-like filesystems on Unix-like OSes"?




Indeed, I have similar questions.

Personally, I would have expected it would have something to do with the 
Makefile.PL returning with a particular error code.


So you define a set of numbers to say things like "Will not work in this 
environment, don't even try", or "I don't have all my dependencies" etc etc.


And you maybe Makefile.PL and Build.PL share those same error codes.

But like I said, I don't know what the current situation is.

Adam K

Supporting C static storage

[Leopold Toetsch]

Below are some thoughts WRT C static vars and Perl6 INIT blocks.

Comments welcome,
leo
Supporting C static storage

There are some related Perl6 features, namely INIT and FIRST closure
traits [1], which aren't really covered by Parrot yet.

Parrot supports INIT blocks via :immediate, which allows e.g.
translation of:
  
  constant Num pi = { atan(1,1)*4 };   # [2]

But C statics can of course change. The problems is, where to
store the static variable, especially native integers.

  double gen_random(double max) {  # [3]
static long last = 42;
...
  }

We could use closures, coroutines [4], or globals. The former provide
a persistent register frame, where the static can be kept. Translating
a sub with a C static to a coroutine seems to be a bit unnatural
though.  And all these solutions are a bit slow and lexicals/globals
are only providing PMC support.

I think, we should use the constant table and allow storing into
the constant table.

E.g.

  .static int last = 42 # ldc_i_ic

(We can't use the C opcode, as this is loading constants
from the bytecode, which, when mmaped, is readonly and doesn't allow
storing)

  last += 10# add_i_ic / set_ic_i

  .static float f = 3.14# set_n_nc
  f += 2.0  # add_n_nc / set_nc_n
  f = 5.0   # set_n_nc / set_nc_n

  .static .Integer i = "42" # set_p_pc

The 'static' variables are therefore working mostly like constants,
except that they are modifyable. One difference is of course, that
there would be no constant folding, each .static needs a distinct
storage in the constant table.

We'd need a few new opcodes:

  ldc_i_ic # load int constant from constant table
  set_ic_i # store int into constant table
  set_nc_n # store num
  assign_pc_p  # assign to PMC static value

And maybe some permutations like set_pc_i.

What do you think?
leo  


[1] S04 / Closure traits

[2] # t/pmc/sub_38.pir
.sub make_pi :immediate, :anon
$N0 = atan 1.0, 1.0
$N0 *= 4
$P0 = new .Float
$P0 = $N0
.return ($P0)
.end

.sub main :main
.const .Sub pi = "make_pi"
print pi
print "\n"
.end

[3] 
http://shootout.alioth.debian.org/sandbox/benchmark.php?test=random&lang=icc&id=0

[4] examples/shootout/random.pir

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[David Cantrell]

demerphq wrote:

On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote:

So how, then, do I tell the testing system "this module only works on
Unix-like filesystems on Unix-like OSes"?

Hopefully it will be something like:
$I::don't::bother::to::write::portable::code=1;


My code is as portable as I can make it.  Feel free to submit patches 
for platforms that I don't have reasonable access to.  Portability is 
something I care a lot about.



How do you define "unix-like filesystems on unix-like oses" btw? Would
win32 count and what reason would you give for your answer, whatever
it is.


Is that Win95, NT, 2000 or Windows for Teletubbies; and is that using 
NTFS, FAT16, FAT32, ext2*, HFS+*, HPFS, or whatever the hell it is that 
MS have added in the latest version?  If it's FAT or Win95 the answer is 
"no" cos they have no concept of permissions.  If it's anything else 
then I don't know but I suspect not.  The Windows permissions model is 
VERY different, and I don't think it has a sane getpwent(), getgrent() 
or anything like Unixy mode bits.  It's arguably far superior to the 
Unix one (although IIRC neither is a patch on Novell) but that's 
irrelevant as I don't have a Windows box to play with.


The module in question is File::Find::Rule::Permissions, which just 
happens to have a very sucky test suite at the moment** because it's 
very old and also because a comprehensive test suite would have to run 
as a priveleged user which I don't like doing***.  Fixing it is on my 
to-do list.  However, when I fix it I still can't fix it for platforms I 
have no reasonable access to.


* both of these have been available as hideous hacks
** it compiles, ship it!
*** the intention is to test the logic, if not the whole thing, by
over-riding certain functions during testing; the hooks are already
in there for doing this

--
David Cantrell

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[David Cantrell]

David Golden wrote:

Well, the more generalized problem is how to you signal to an automated 
test that you're bailing out as N/A for whatever reason?  For Perl 
itself, it's easy enough for the smoke test to check if the required 
version of Perl is available -- and the smoke test is smart enough not 
to try to install an updated version of Perl to satisfy the dependency. 
 It bails out with N/A instead.


What's a clean, generic mechanism for a distribution to signal "please 
check this dependency and abort if it's not satisfied"?


die("wrong platform, you didn't read the documentation\n")
  unless(
$Config::capabilities{filesystem}{casesensitive} &&
...
  );

With the capabilities database being built when perl is built, similarly 
to how it knows about things like ldlibpathname.  But this gets REALLY 
complicated.  An OS can support several filesystems each with different 
capabilities - for example, on OS X, HFS+ is case-preserving but 
case-insensitive.  UFS is case-sensitive.  And FAT16 smashes case.


So things like that need to be figured out on the fly, based on some 
kind of context information.  And god help you if you're looking at a 
TranslateFilenamesUsingFiglet fs (which you wrote using fuse when very 
very drunk).


--
David Cantrell

Re: Please revert and explain ":non_volatile"

[Jonathan Worthington]

"Chip Salzenberg" <[EMAIL PROTECTED]> wrote:

Please revert this change,

Done, along with the docs and test changes relating to it.


and refrain from checking in user-visible or
design-significant changes to the core until I've OK'd them.

Had mentioned this to leo, who said it sounded sane, and after considering 
that it wasn't going to break any existing code figured that menat it could 
go in.  I'll just post patches to the list for approval on any non-trivial 
stuff in the future.



If this feature is necessary (which it may be),
I explained why in the bit of my mail you didn't quote.  And yes, I could 
use non-virtual registers, but then can't use .param to hide away the 
calling conventions, which is one reason I chose PIR.



the name "non_volatile" is
misleading to the point of being dead wrong ("volatility" in the C sense 
is
not exactly a helpful meme in Parrot land).  And it's ugly: negative 
options
are usually not unbad.  And this one definitely is.  (Or is it 'not'?  ... 
I

hate negative options.)
The name came direclty from the terminology used in the register allocator, 
so it was at least consistent even if not desirable.  Point taken on the 
possible confusion with volatile in the C sense - that hadn't occurred to 
me.  Better names and/or solutions welcome.


Thanks,

Jonathan 

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Chris Dolan]

On Jan 30, 2006, at 10:04 AM, David Cantrell wrote:

[...] for example, on OS X, HFS+ is case-preserving but case- 
insensitive.  UFS is case-sensitive.  And FAT16 smashes case.


And to make matters even worse (better?) Apple added a case-sensitive  
mode to HFS+ in 10.4.  It's not widely used.

Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[David Golden]

David Cantrell wrote:

David Golden wrote:
What's a clean, generic mechanism for a distribution to signal "please 
check this dependency and abort if it's not satisfied"?


die("wrong platform, you didn't read the documentation\n")
  unless(
$Config::capabilities{filesystem}{casesensitive} &&
...
  );



Well, I really meant how to signal to CPANSmoke, not the user.  I don't 
really expect CPANSmoke to read the docs -- which is the problem.


That said, the notion of Config may be a decent next step as a sane way 
of requesting certain prerequisites like OS or features like threading.


  config_prereq => {
keyname => string or regex
  }

For example:

  config_prereq => {
osname => qr/linux|bsd/,
useithreads => 'define'
  }

That doesn't solve the external library problem, but it would be a next 
step that Makefile.PL/Build.PL/CPANSmoke might be able to support for a 
bit more granularity as to what consistutes an N/A on a smoke test.


David

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[A. Pagaltzis]

* demerphq <[EMAIL PROTECTED]> [2006-01-30 14:50]:
>Hopefully it will be something like:
>
>$I::don't::bother::to::write::portable::code=1;

Yeah, those Win32:: modules are really unportable. It sucks.

Wink wink,
-- 
Aristotle Pagaltzis // 

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Tels]

Moin,

On Monday 30 January 2006 14:59, David Golden wrote:
> demerphq wrote:
> > On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote:
> >>Adam Kennedy wrote:
> >>>A testing system should only be sending FAIL reports when it
> >>> believes it has a platform that is compatible with the needs of the
> >>> module, but when it tries to install tests fail.
> >>
> >>So how, then, do I tell the testing system "this module only works on
> >>Unix-like filesystems on Unix-like OSes"?
> >
> > Hopefully it will be something like:
> > $I::don't::bother::to::write::portable::code=1;
> >
> > How do you define "unix-like filesystems on unix-like oses" btw?
> > Would win32 count and what reason would you give for your answer,
> > whatever it is.
>
> Well, the more generalized problem is how to you signal to an automated
> test that you're bailing out as N/A for whatever reason?  For Perl
> itself, it's easy enough for the smoke test to check if the required
> version of Perl is available -- and the smoke test is smart enough not
> to try to install an updated version of Perl to satisfy the dependency.
>   It bails out with N/A instead.
>
> What's a clean, generic mechanism for a distribution to signal "please
> check this dependency and abort if it's not satisfied"?  Something in
> the META.yml (e.g. Alien::*)?  Send a specific string to STDERR?  Send
> a specific exit codes?  Ugh.  Other ideas?

Makefile.PL:

PREREQ_FAIL => 1,

does it nicely for me.

Best wishes,

Tels

-- 
 Signed on Mon Jan 30 18:41:31 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "To get something done, a committee should consist of no more than three
 persons, two of them absent." -- Unknown



pgpfvPLEXFedQ.pgp
Description: PGP signature

Re: Some perplexities on S06

[Larry Wall]

On Sat, Jan 28, 2006 at 06:30:06PM +0100, dakkar wrote:
: Today I was reading S06 from
: http://dev.perl.org/perl6/doc/design/syn/S06.html, and I have some
: perplexities on what's written there.
: 
: 1) it's written:
: 
: $pair = :when;
: doit $pair,1,2,3;   # always a positional arg
: doit *$pair,1,2,3;  # always a named arg
: 
:but also:
: 
: To pass pairs out of hash without their being interpreted as named
: parameters, use
: 
:   doit %hash:p,1,2,3;
:   doit %hash{'b'}:p,1,2,3;
: 
: instead.
: 
:I interpret the last sentence as meaning that:
: 
:  $hash=:a<2>; doit %hash;
: 
:would be equivalent to:
: 
:  doit :a<2>
: 
:which contradicts what is written earlier... I'd assume I'd have to
: write:
: 
:   doit *(%hash);
: 
:for the pair to be used as a named argument. What am I missing?

You're reading "pass pairs" as meaning to return a particular value
that happens to be a pair.  That's not the purpose of :p, since that's
what happens anyway by default.  You use :p to return both the key
and the value as a pair object from the hash.  If you say:

%hash=:a<2>; doit %hash;

it's equivalent to

 doit (:a<2>)

whereas if you say

%hash=:a<2>; doit %hash:p;

it is equivalent to

 doit (:b(:a<2>))

In neither case is the argument taken as a named argument.
I have rewritten the paragraph as:

Ordinary hash notation will just pass the value of the hash entry as a
positional argument regardless of whether it is a pair or not.
To pass both key and value out of hash as a positional pair, use C<:p>.

doit %hash:p,1,2,3;
doit %hash{'b'}:p,1,2,3;

instead.  (The C<:p> stands for "pairs", not "positional"--the
C<:p> adverb may be placed on any hash reference to make it mean
"pairs" instead of "values".)

to try to make it clearer.

: 2) Consider:
: 
:  doit %*hash;   # 1 arg, the global hash
:  doit *%hash;   # n args, the key-value pairs in the hash
: 
:I think I'll use a lot of C-t while writing Perl6 code...

The * as shorthand for GLOBAL:: is allowed only where it wouldn't be confused
with unary *.  That is, only in declarative contexts or as a twigil.

: 3) What does the second line in:
: 
:   push @array, :a<1>;
:   say *pop(@array);
: 
:mean? I'd parse it as 'say (*pop)(@array)', that is, call the global
: 'pop' subroutine. But the text around this example seems to imply that
: it is to be parsed as 'say *(pop(@array))', i.e. execute 'pop' and splat
: the result. What gives?

The above rule.  If we meant the global pop we'd say:

say &*pop(@array);

or

say GLOBAL::pop(@array);

Gotto go to lunch--more in a bit.  (Please use new subjects if you want
to discuss any of these subpoints further...)

Larry

Re: Supporting C static storage

[Joshua Isom]

Currently, the .global directive for pir is unimplemented.  Other than  
being in the source code for the imcc compiler, it's absent.  Is  
.global intended to truely store to global, or be more like a mutable  
constant, applicable to only that file(and then perhaps any that  
.include it).  If it's intended to be more like a macro, "global"  
statics already have a a method to access them.  For localized statics,  
i.e. [3], I like the .static int var = 123 most for familiarity.  As  
for values, I'd say strings, floats, and ints can have a default value  
writing in plain sight for them, but for pmcs they would need to be  
initialized in an :immediate sub.  E.g.


.global int foo = 42
.global pmc bar
.sub init :immediate
bar = new .FixedIntegerArray
bar = 4
.end

On Jan 30, 2006, at 8:54 AM, Leopold Toetsch wrote:


Below are some thoughts WRT C static vars and Perl6 INIT blocks.

Comments welcome,
leo
Supporting C static storage

There are some related Perl6 features, namely INIT and FIRST closure
traits [1], which aren't really covered by Parrot yet.

Parrot supports INIT blocks via :immediate, which allows e.g.
translation of:

  constant Num pi = { atan(1,1)*4 };   # [2]

But C statics can of course change. The problems is, where to
store the static variable, especially native integers.

  double gen_random(double max) {  # [3]
static long last = 42;
...
  }

We could use closures, coroutines [4], or globals. The former provide
a persistent register frame, where the static can be kept. Translating
a sub with a C static to a coroutine seems to be a bit unnatural
though.  And all these solutions are a bit slow and lexicals/globals
are only providing PMC support.

I think, we should use the constant table and allow storing into
the constant table.

E.g.

  .static int last = 42 # ldc_i_ic

(We can't use the C opcode, as this is loading constants
from the bytecode, which, when mmaped, is readonly and doesn't allow
storing)

  last += 10# add_i_ic / set_ic_i

  .static float f = 3.14# set_n_nc
  f += 2.0  # add_n_nc / set_nc_n
  f = 5.0   # set_n_nc / set_nc_n

  .static .Integer i = "42" # set_p_pc

The 'static' variables are therefore working mostly like constants,
except that they are modifyable. One difference is of course, that
there would be no constant folding, each .static needs a distinct
storage in the constant table.

We'd need a few new opcodes:

  ldc_i_ic # load int constant from constant table
  set_ic_i # store int into constant table
  set_nc_n # store num
  assign_pc_p  # assign to PMC static value

And maybe some permutations like set_pc_i.

What do you think?
leo


[1] S04 / Closure traits

[2] # t/pmc/sub_38.pir
.sub make_pi :immediate, :anon
$N0 = atan 1.0, 1.0
$N0 *= 4
$P0 = new .Float
$P0 = $N0
.return ($P0)
.end

.sub main :main
.const .Sub pi = "make_pi"
print pi
print "\n"
.end

[3]  
http://shootout.alioth.debian.org/sandbox/benchmark.php? 
test=random&lang=icc&id=0


[4] examples/shootout/random.pir

Re: Supporting C static storage

[Nicholas Clark]

On Mon, Jan 30, 2006 at 03:54:51PM +0100, Leopold Toetsch wrote:

> I think, we should use the constant table and allow storing into
> the constant table.

I don't know the parrot source code well enough to know whether the constant
table is static const at the C level. (Or capable of being compiled that way).
But my comment is that Jarkko recently put considerable effort into cleaning
up the Perl 5 core so that as much data as possible was static const, so that
it facilitated shared library use. (In this case for Symbian)

So I (mis)interpret "storing to the constant table" as "aaargh, can't be static
const" which feels bad to me. So if the constant table can be static const,
does this mean that parrot would benefit from a compile time initialised
constant table, and a "run time" initialised constant table? With your
proposed writable C static variables in the run time initialised table.
 

Nicholas Clark

Re: Some perplexities on S06

[Larry Wall]

On Sat, Jan 28, 2006 at 06:30:06PM +0100, dakkar wrote:
: 4) It's written:
: 
:(Conjectural: Within the body you may also use exists on the
: parameter name to determine whether it was passed. Maybe this will have
: to be restricted to the ? form, unless we're willing to admit that a
: parameter could be simultaneously defined and non-existant.)
: 
:Ok, this is 'conjectural', but... if i don't pass a parameter in an
: invocation, and that parameter had a defined default, that it would be
: both defined and non-passed... here I'm sure I'm missing something

That's precisely the point.  It's just a bit strange to have something
that is defined but doesn't "exist".

: 5) while talking about pipes, it says that
: 
:  (0..2; 'a'..'c') ==> my @;tmp;
:  for @;tmp.zip { say }
: 
:produces
: 
:   [0,'a']
:   [1,'b']
: 
:etc. Right. But then it says:
: 
:  for @;tmp.each -> $i, $a { say "$i: $a" }
: 
:as far as I understand, this should say
: 
:  0: undef
:  'a': undef
: 
:etc., since 'each' is visiting the multidimensional array 'by rows',
: and producing 1 value at a time, which when bound to the 2-ary signature
: would leave the $a parameter without a value, and so undef (I'm assuming
: that pointy sub positional parameters are implicitly optional, otherwise
: that statement would be a run-time error). I'm pretty sure I don't know
: what 'each' does...

The "each" is just producing a sequence of values (without bundling
them up into tuple objects like "zip").  It's the "for" that is
deciding to take these list values 2 at a time because of the arity
of the block's signature.  That is why, if you use "zip", you have
to put the args as [$i, $a] in order to present an arity of 1 to "for".

: 6) It's written:
: 
:  Every lexical scope gets its own implicitly declared @; variable,
: which is the default receiver.
: 
:To me, that is a variable with a null name ('@;' being a twigil).
: Should it not be @;_ ?

I suppose there's an argument for that.  We certainly haven't hesitated
(much) to define $! differently from $!foo, for instance.  And Perl 5
distinguishes $#foo from $# (that latter being deprecated, of course).
On the other hand there's no reason in principle that a twigil *has*
to mean something entirely different just because it has a null name.
Plus I think people would rebel if all "underlying" objects had to have
an underline.  We'd end up with $/_ instead of $/, and $!_ instead of $!,
and would $!_ then be misinterpreted as a private attribute named "_"?

Larry

PARROT_IN_EXTENSION

[Nicholas Clark]

I think that I must be missing something. In ponie, src/pmc/perl5pmcs.h looks
like this:

--
/*
 * !!!   DO NOT EDIT THIS FILE   !!!
 *
 * This file is generated automatically from 'various files'
 * by /home/nick/Ponie/ponie00/parrot/tools/build/pmc2c.pl.
 *
 * Any changes made here will be lost!
 *
 */

#define PARROT_IN_EXTENSION
PARROT_DYNEXT_EXPORT Parrot_PMC Parrot_lib_perl5pmcs_load(Parrot_INTERP 
interpreter);
--

To me, that PARROT_IN_EXTENSION is not helping. The relevance seems to be
for :

/* Symbol export and import decoration. At the time of writing, note that
 * PARROT_IN_CORE won't always imply !PARROT_IN_EXTENSION. */
#if defined(PARROT_IN_EXTENSION)
#define PARROT_API
#define PARROT_DYNEXT_EXPORT
#else
#define PARROT_API
#endif


yet the way it's currently defined it's too late to be of any use -
 has already been and gone. And even if I re-order the
include files so that src/pmc/perl5pmcs.h is included before
 in my source, then it still doesn't help. (Probably because
 has been included even earlier).

The compile only works if I define PARROT_IN_EXTENSION myself (on the compiler
command line)

So what should be going on? Or am I missing something completely obvious?

Nicholas Clark

Re: Supporting C static storage

[Leopold Toetsch]

On Jan 30, 2006, at 22:00, Nicholas Clark wrote:


On Mon, Jan 30, 2006 at 03:54:51PM +0100, Leopold Toetsch wrote:


I think, we should use the constant table and allow storing into
the constant table.


I don't know the parrot source code well enough to know whether the 
constant
table is static const at the C level. (Or capable of being compiled 
that way).


No it's not a C static const and it can't be considered a such. It's 
built at compile/PBC load time incrementally by appending e.g. doubles 
or PMC constants, like subroutine PMC, or STRING constants. A C static 
const alike is e.g. used for STRING constants in the source code, via 
the CONST_STRING macro.


But my comment is that Jarkko recently put considerable effort into 
cleaning
up the Perl 5 core so that as much data as possible was static const, 
so that

it facilitated shared library use. (In this case for Symbian)


Good point, albeit it doesn't apply to the thing currently called 
constant table.


So I (mis)interpret "storing to the constant table" as "aaargh, can't 
be static
const" which feels bad to me. So if the constant table can be static 
const,
does this mean that parrot would benefit from a compile time 
initialised

constant table, and a "run time" initialised constant table? With your
proposed writable C static variables in the run time initialised table.


The constant table is currently a list of pointers to unions of 
'constant' values. It's created when loading a bytecode file (or 
equivalently during compile/run cycle). *If* the the constant table 
were split into more dedicated parts, a const list of doubles could be 
part of the PBC and be considered as read-only/shared because it would 
be just mmaped, if possible.


The 'constant' part of the table means for Parrot internals that it 
isn't marked being alive by the GC, because these items (STRINGs, PMCs) 
in the constant table have a dedicated storage arena, which is only 
freed at program end (and possibly with --leak-test enabled).



Nicholas Clark


leo

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[brian d foy]

In article
<[EMAIL PROTECTED]>, demerphq
<[EMAIL PROTECTED]> wrote:

> On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote:
> > Adam Kennedy wrote:

> > > A testing system should only be sending FAIL reports when it believes it
> > > has a platform that is compatible with the needs of the module, but when
> > > it tries to install tests fail.

> > So how, then, do I tell the testing system "this module only works on
> > Unix-like filesystems on Unix-like OSes"?

> Hopefully it will be something like:
> 
> $I::don't::bother::to::write::portable::code=1;
> 
> ;-)

Seriously though, I would expect things in Win32::* to only work on
Windows, things in Linux::* only to work on linux, and so on for many
other sections (including Mac::* where I have some modules).  Portable
code isn't always the goal.

\c[NAMED UNICODE CHARACTER]?

[Audrey Tang]

Is it possible to have it as part of Synopsis 02?  It's mentioned
variously in A05, E05 and E07 (where it permits a \c[2026] form, but
should be spelled \d[2026] nowadays), but is not currently part of any
Synopses.

Audrey

Re: YAML and Makefile.PL (was various topics)

[brian d foy]

In article <[EMAIL PROTECTED]>, Adam
Kennedy <[EMAIL PROTECTED]> wrote:

> > And if there is a problem with Module::Install, you have to update all 
> > your dists with the new version - solve one problem, create two new 
> > ones :)

> But if there is a problem with EU::MM or Module::Build, you have to 
> update every installation in the entire world with the new version.

That's not entirely fair. If I personally had to update all of my 
distributions and re-upload them to CPAN, it would never get done. If I
(or the other users) have to upgrade EU::MM or Module::Build, they just
install the latest from CPAN.

If I had the old versions in my dist, I would have configured @INC to
look for them, and that's where they'd be found regardless of what else
is installed. I could code all sorts of conditionals to check if the
module is already installed and of the right version and so on, but
then things are getting pretty complex.

It would be nice if some of these modules could do their magic at 
`make dist` time so they didn't have to show up in the dist. :)

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[demerphq]

On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote:
> demerphq wrote:
> > On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote:
> >>So how, then, do I tell the testing system "this module only works on
> >>Unix-like filesystems on Unix-like OSes"?
> > Hopefully it will be something like:
> > $I::don't::bother::to::write::portable::code=1;
>
> My code is as portable as I can make it.  Feel free to submit patches
> for platforms that I don't have reasonable access to.  Portability is
> something I care a lot about.

It was a joke. Really. :-)

>
> > How do you define "unix-like filesystems on unix-like oses" btw? Would
> > win32 count and what reason would you give for your answer, whatever
> > it is.
>
> Is that Win95, NT, 2000 or Windows for Teletubbies; and is that using
> NTFS, FAT16, FAT32, ext2*, HFS+*, HPFS, or whatever the hell it is that
> MS have added in the latest version?  If it's FAT or Win95 the answer is
> "no" cos they have no concept of permissions.  If it's anything else
> then I don't know but I suspect not.  The Windows permissions model is
> VERY different, and I don't think it has a sane getpwent(), getgrent()
> or anything like Unixy mode bits.  It's arguably far superior to the
> Unix one (although IIRC neither is a patch on Novell) but that's
> irrelevant as I don't have a Windows box to play with.

Sorry, i guess my comment was in bad taste. I was just alluding to
observations made in the p5p lists and elsewhere that basing file
system behaviour on the OS isnt entirely safe, and even expecting the
same semantics in the a tree could be unsafe.

cheers,
yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: \c[NAMED UNICODE CHARACTER]?

[Larry Wall]

On Tue, Jan 31, 2006 at 12:15:31AM +0800, Audrey Tang wrote:
: Is it possible to have it as part of Synopsis 02?  It's mentioned
: variously in A05, E05 and E07 (where it permits a \c[2026] form, but
: should be spelled \d[2026] nowadays), but is not currently part of any
: Synopses.

Now reads:

=item *

You may interpolate any Unicode codepoint by name using C<\c>
and square brackets:

"\c[NEGATED DOUBLE VERTICAL BAR DOUBLE RIGHT TURNSTILE]"

Multiple codepoints constituting a single character may be
interpolated with a single C<\c> by separating the names with
comma:

"\c[LATIN CAPITAL LETTER A, COMBINING RING ABOVE]"

Whether that is regarded as one character or two depends on the
Unicode support level of the current lexical scope.  It is also
possible to interpolate multiple codepoints that do not resolve
to a single character:

"\c[LATIN CAPITAL LETTER A, LATIN CAPITAL LETTER B]"

[Note: none of the official Unicode character names contains comma.]

Larry

Re: testers.cpan.org out of sync with search.cpan.org?

[Leon Brocard]

On 1/27/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:

> Usually this clears up in about a day, but in some cases it's been 3 or 4
> days now and search.cpan.org is telling me that tests have run, but
> testers.cpan.org doesn't seem to know anything about them.

Sorry, I'll prod testers.cpan.org again. Give it a while to sync up.

Leon

[perl #38371] [BUG] t/op/calling.t is failing (IREGs aren't being cleared)

[via RT]

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


on platforms sensitive to IREGs with junk data, or on any platform
when running `TEST_PROG_ARGS=-D40 perl -Ilib t/op/calling.t`, test 78
is failing (as reported on #parrot by jisom)

it seems to me, from the trace below, that IREGs aren't being zeroed
properly. jisom aka joshua isom should be looking at this, but leo
suggested it be ticketed, so it doesn't get lost.
~jerry

below is the failing test output, and the trace.


D:\usr\local\parrot\trunk>parrot t/op/calling.t
error:imcc:syntax error, unexpected IDENTIFIER, expecting $end
in file 't/op/calling.t' line 5

D:\usr\local\parrot\trunk>prove t/op/calling.t
t/op/callingok 77/86
# Failed test (t/op/calling.t at line 2007)
#  got: '10 1 20 1
t/op/callingNOK 78# 10 1 20 1
# 10 1 20 1
# 10 1 20 1
# ok
# '
# expected: '10 1 20 1
# 10 1 0 0
# 0 0 20 1
# 0 0 0 0
# ok
# '
t/op/callingok 86/86# Looks like you failed 1 test of 86.
t/op/callingdubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 78
Failed 1/86 tests, 98.84% okay
Failed TestStat Wstat Total Fail  Failed  List of Failed
---
t/op/calling.t1   256861   1.16%  78
Failed 1/1 test scripts, 0.00% okay. 1/86 subtests failed, 98.84% okay.









D:\usr\local\parrot\trunk>parrot -t t/op/calling_78.pir
 0 set_args PMC_C[7] (4), "a", 20, "b", 10
 6 set P0, PMC_C[15]- P0=PMCNULL,
 9 get_results PMC_C[9]
11 invokecc P0  - P0=Sub=PMC(0x6257b8 pc:47)
47 get_params PMC_C[12] (6), "b", I0, I2, "a", I3, I1   - , , I0=0, I2=0
, , I3=0, I1=0
55 print_item I0- I0=10
57 print_item I2- I2=1
59 print_item I3- I3=20
61 print_item I1- I1=1
63 print_newline
10 1 20 1
64 set_returns PMC_C[9]
66 returncc
13 set_args PMC_C[2] (2), "b", 10
17 set P0, PMC_C[15]- P0=Sub=PMC(0x6257b8 pc:47),
20 get_results PMC_C[9]
22 invokecc P0  - P0=Sub=PMC(0x6257b8 pc:47)
47 get_params PMC_C[12] (6), "b", I0, I2, "a", I3, I1   - , , I0=10, I2=
1, , I3=20, I1=1
55 print_item I0- I0=10
57 print_item I2- I2=1
59 print_item I3- I3=20
61 print_item I1- I1=1
63 print_newline
10 1 20 1
64 set_returns PMC_C[9]
66 returncc
24 set_args PMC_C[2] (2), "a", 20
28 set P0, PMC_C[15]- P0=Sub=PMC(0x6257b8 pc:47),
31 get_results PMC_C[9]
33 invokecc P0  - P0=Sub=PMC(0x6257b8 pc:47)
47 get_params PMC_C[12] (6), "b", I0, I2, "a", I3, I1   - , , I0=10, I2=
1, , I3=20, I1=1
55 print_item I0- I0=10
57 print_item I2- I2=1
59 print_item I3- I3=20
61 print_item I1- I1=1
63 print_newline
10 1 20 1
64 set_returns PMC_C[9]
66 returncc
35 set_args PMC_C[9]
37 set P0, PMC_C[15]- P0=Sub=PMC(0x6257b8 pc:47),
40 get_results PMC_C[9]
42 invokecc P0  - P0=Sub=PMC(0x6257b8 pc:47)
47 get_params PMC_C[12] (6), "b", I0, I2, "a", I3, I1   - , , I0=10, I2=
1, , I3=20, I1=1
55 print_item I0- I0=10
57 print_item I2- I2=1
59 print_item I3- I3=20
61 print_item I1- I1=1
63 print_newline
10 1 20 1
64 set_returns PMC_C[9]
   DOD
   GC
66 returncc
44 print "ok\n"
ok
46 end

D:\usr\local\parrot\trunk>

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

[Bob Rogers]

   From: "Leopold Toetsch via RT" <[EMAIL PROTECTED]>
   Date: Mon, 30 Jan 2006 05:48:42 -0800

   Bob Rogers (via RT) wrote:

   >It seems that Continuation needs the same set_address magic as
   > Exception_Handler in order to return values. 

   Yep. At least as long we don't have better support for creating
   limited continuations that are able to return some results.

I'm afraid I don't follow.  What would you consider better?

   There is of course the 'standard' way to achieve this effect with a
   helper subroutine 'call-with-current-continuation', but there are
   probably some more HLL semantics, which translate to the usage of the
   patch.

Seems to me that call-with-current-continuation uses the identical
underlying mechanism as what I've been trying to do with Continuation,
at least as "implemented" by the t/op/lexicals.t "closure 4" test case.
It invokes its continuation in the same way as the new "set_args via
explicit continuation" test (invokecc_p in both cases) -- but has always
worked just because it has always used a RetContinuation instead of a
Continuation.  I think that's the only real difference.

   But, FWIW, I am coming around to the view that continuations
shouldn't ever be invoked like this.  Plain function calling is likely
to confuse optimizers, since they won't understand that you don't ever
expect to return.  I was about to propose a new op when I discovered
that tailcall works just fine for this purpose (see below).  I hope to
document this, so that it can become the standard idiom.

   We may want to go farther, though.  Since optimizers could still lose
on code that doesn't conform to this convention, perhaps Parrot should
enforce the distinction by throwing an error if invokecc is used to call
something that can't return?

-- Bob


Index: t/op/lexicals.t
===
--- t/op/lexicals.t (revision 11383)
+++ t/op/lexicals.t (working copy)
@@ -651,7 +651,7 @@
  our_try = find_lex "try"
  $P2 = find_lex "choices"
  $P3 = our_try($P2)
- our_cc($P3)
+ .return our_cc($P3)
 .end
 
 .sub _fail :outer(main)

Re: YAML and Makefile.PL (was various topics)

[Adam Kennedy]

brian d foy wrote:

In article <[EMAIL PROTECTED]>, Adam
Kennedy <[EMAIL PROTECTED]> wrote:

And if there is a problem with Module::Install, you have to update all 
your dists with the new version - solve one problem, create two new 
ones :)


But if there is a problem with EU::MM or Module::Build, you have to 
update every installation in the entire world with the new version.


That's not entirely fair. If I personally had to update all of my 
distributions and re-upload them to CPAN, it would never get done. If I

(or the other users) have to upgrade EU::MM or Module::Build, they
install the latest from CPAN.


s/just// auto-applied :)

The big advantage I see here is it's not you doing the work, it's 
everybody else.


I generally don't have too much of a problem doing incrementals...

cd trunk/Module-Name
ppichangeversion 0.14 0.15
perl ../../tools/build_cpan.pl --install --commit --upload Module-Name

Give me another 6 months to accrete small improvements and I expect that 
to be..


cd tools
./build_cpan.pl --increment --commit --install --upload Module-Name

And 6 months after that...

./incremental_release.pl Module-Name Other-Module Etc-Etc

Incremental releasing is a toolchain problem. You can automate the thing 
down to a single command if you care enough. (even if it's a bit at a time)


And aren't you writing Module::Release or something to do exactly that?

Adam K


If I had the old versions in my dist, I would have configured @INC to
look for them, and that's where they'd be found regardless of what else
is installed. I could code all sorts of conditionals to check if the
module is already installed and of the right version and so on, but
then things are getting pretty complex.

It would be nice if some of these modules could do their magic at 
`make dist` time so they didn't have to show up in the dist. :)

Re: YAML and Makefile.PL (was various topics)

[chromatic]

On Monday 30 January 2006 20:40, Adam Kennedy wrote:

> Incremental releasing is a toolchain problem.

Having to rerelease more than one module and making every one of my users 
upgrade every module that uses this tool -- not just my one or more modules 
-- rather than making every one who uses the tool upgrade just the tool is a 
bigger problem.

I might be missing something here, but the math for the "Oh no, there's a 
problem in the tool" doesn't seem to favor Module::Install.  If there's a 
problem in the build tool:

With Module::Build or MakeMaker:

- either (Ken and Randy) or Schwern have to upload a new version to the 
CPAN
- everyone who wants to get the bugfix has to install the new version, 
once 
per installation

With Module::Install:

- you or Ingy or Audrey have to upload a new version to the CPAN
- everyone who wants to get the bugfix has to install the new version, 
once 
per installation
- everyone who wants to use the bugfixed version has to release a new 
version 
of each module that uses it
- everyone who wants to use the buildbugfixed version of each new 
module has 
to install each distribution, once per installation

I don't say this often, but that really doesn't seem scalable to me.  If I 
have to re-release a distribution because of a bug in the build system that 
users can't upgrade on their own, the build system sucks for my purposes.

Now I know you and Ingy and Audrey and Jesse are all very smart, so am I 
completely misunderstanding things?

-- c

Re: YAML and Makefile.PL (was various topics)

[Adam Kennedy]

chromatic wrote:

On Monday 30 January 2006 20:40, Adam Kennedy wrote:


Incremental releasing is a toolchain problem.


Having to rerelease more than one module and making every one of my users 
upgrade every module that uses this tool -- not just my one or more modules 
-- rather than making every one who uses the tool upgrade just the tool is a 
bigger problem.


I might be missing something here, but the math for the "Oh no, there's a 
problem in the tool" doesn't seem to favor Module::Install.  If there's a 
problem in the build tool:


With Module::Build or MakeMaker:

- either (Ken and Randy) or Schwern have to upload a new version to the 
CPAN
	- everyone who wants to get the bugfix has to install the new version, once 
per installation


(cut/paste)
> Now I know you and Ingy and Audrey and Jesse are all very smart, so
> am I completely misunderstanding things?
(cut/paste)

To answer that question, the bit you missed is here.

Why would any client get the bugfixed version? Nothing else they use is 
explicitly saying they need it, so the CPAN(PLUS) client wouldn't bother 
to install a new version.


The only 2 ways for them to get it is to either start doing incremental 
releases of lots of other modules that explicitly up their dep on it. In 
fact, because people are going to have old versions of the module around 
for years, you really do need to release an incremental of everything 
that uses EUMM/MB to up the dependency in order to be 100% sure. (note, 
that's for 100%, for less things aren't that bad)


The second way is for the user to spot there's a problem somewhere in 
the 300 pages of CPAN output, diagnose the problem, research the 
problem, find the answer "update your Module::Build", and upgrade it 
once per installation.


Unless of course they use a packaging system (PPM/deb/RPM) in which case 
they won't be hit by the problem.


There isn't really any very good way (that I can see at least) to ensure 
that an end-user gets an update to EUMM/MB, just the module packager.



With Module::Install:

- you or Ingy or Audrey have to upload a new version to the CPAN
	- everyone who wants to get the bugfix has to install the new version, once 
per installation


That should read once per CPAN author. Normal users do not ever need to 
install the actual Module::Install dist. Only module authors.


	- everyone who wants to use the bugfixed version has to release a new version 
of each module that uses it


Yes, in the "oh fuck we broke everything" scenario, all most authors are 
forced to increment. This is a big downside. In the Cygwin case for 
example, a bunch of authors won't care and won't increment immediately, 
because their userbase is doing just fine. And then when they do their 
next normal release, the upgraded Module::Install comes along for the ride.


	- everyone who wants to use the buildbugfixed version of each new module has 
to install each distribution, once per installation


Yes, but they install the module that threw the error, not an unnamed 
dependency somewhere down the chain.


Unless of course they use a packaging system (PPM/deb/RPM) in which case 
they won't be hit by the problem either, just the module packager.


I don't say this often, but that really doesn't seem scalable to me.  If I 
have to re-release a distribution because of a bug in the build system that 
users can't upgrade on their own, the build system sucks for my purposes.





I guess the best difference in attitude I can provide is this one
(without declaring either a clear and obvious winner in all cases)

EUMM/MB's response to a worst-case scenario optimises for smart users, 
minimizes the work for the author, and allows the problem to dissipate 
over time (spread across all dists)


MI's response to a worst-case scenario optimizes for stupid users, or 
robot users, creates more work for the authors, but allows the problem 
to be fixed immediately for each dist on all platforms.


So, MI simplifies and saves time when writing installers, and makes 
certain the solution to a problem is propogated to 100% of all users.


Certainly this does come at some cost to the author, particularly in a 
worst-case scenario.


Of course, in other scenarios such as problems related to particular 
user subsets, or where there are small ordinary improvements, there will 
be different behaviours by both.


WRT to all of this, all I can say is that just like Module::Build, 
Module::Install is not at 1.00 yet, and so is not recommended for 
widespread (i.e. all modules) use.


There are still some nigglies being worked out of both MB and MI (the MB 
PREFIX problem, and the MI cygwin problem for example). However an 
individual MI author doesn't ever need to worry about hitting old broken 
versions on some machines. A MI dist can install in most cases on a 
default Perl 5.005 straight out the box.


I leave it to the MB author to make recommendations for adoption there, 
but for MI my personal recomm

Re: YAML and Makefile.PL (was various topics)

[Adam Kennedy]

chromatic wrote:

On Monday 30 January 2006 20:40, Adam Kennedy wrote:


Incremental releasing is a toolchain problem.


Having to rerelease more than one module and making every one of my users 
upgrade every module that uses this tool -- not just my one or more modules 
-- rather than making every one who uses the tool upgrade just the tool is a 
bigger problem.


One thing I missed here was to mention that the above just won't happen. 
Once a module is already installed, there is no problem. It's only when 
there are critical errors INSTALLING modules incorrectly that you 
trigger the worst-case scenario.


Adam K

Re: YAML and Makefile.PL (was various topics)

[A. Pagaltzis]

* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-31 07:50]:
>There isn't really any very good way (that I can see at least)
>to ensure that an end-user gets an update to EUMM/MB, just the
>module packager.

So maybe that is the fundamental problem that should be
addressed?

Regards,
-- 
Aristotle Pagaltzis // 

Re: YAML and Makefile.PL (was various topics)

[chromatic]

On Monday 30 January 2006 23:15, A. Pagaltzis wrote:

> * Adam Kennedy <[EMAIL PROTECTED]> [2006-01-31 07:50]:

> >There isn't really any very good way (that I can see at least)
> >to ensure that an end-user gets an update to EUMM/MB, just the
> >module packager.

> So maybe that is the fundamental problem that should be
> addressed?

Perhaps CPAN/CPANPLUS should check for updates?

-- c

Re: YAML and Makefile.PL (was various topics)

[A. Pagaltzis]

* chromatic <[EMAIL PROTECTED]> [2006-01-31 08:20]:
>Perhaps CPAN/CPANPLUS should check for updates?

Maybe just add EUMM+MB to Bundle::CPAN? (Does CPANPLUS have an
equivalent?)

Regards,
-- 
Aristotle Pagaltzis //