any module list maintainers around?

2000-08-11 Thread Charles Ying

I'm curious as to when the next time the module list will be updated...

-- Charles





Re: Register DBD::DB2 for OS/390

2000-08-11 Thread Tim Bunce

On Thu, Jul 20, 2000 at 01:14:09PM -0700, [EMAIL PROTECTED] wrote:
> 
> Name: Thanh Dao
> Email address: [EMAIL PROTECTED]
> Prefered ID on CPAN: DAOT
> Contribution: Port DBD::DB2 driver to OS/390:
> Name  DSLI  Discription   Info
> DBD::DB2  adcO  DBD::DB2 driver on OS/390
> 
> Regards,
> Thanh
> Internet Address : [EMAIL PROTECTED]
> Lotus Notes : Thanh Dao/Santa Teresa/IBM
> VM Node : IBMUSM50(daot)
> Phone : (408)463-3298,  TL: 8-543-3298

I'm not sure what you're actually registering for.

CPAN doesn't usually store pre-built binaries of modules.

If what you've got is source code changes to the existing IBM DBD::DB2
module, to make it build on OS/390, then they should be fed back to the
maintainers of the module.

Or am I misunderstanding you?

Tim.



Re: Register DBD::DB2 for OS/390

2000-08-11 Thread daot




I have put some changes in the source code of DBD-DB2-0.70 and modify the
readme and the CAVEAT files to make the driver work on OS/390. Because it
has some differences in the code such as the method to build the driver and
the level of the driver  I 'd like to have the driver separated for OS/390.
I have uploaded to PAUSE 2 files: DBD-DB2-0.70.OS390.pax.gz ( the source
code) and DBD-DB2_0.70.0S390.readme ( the read me file)

Regards,
Thanh
Internet Address : [EMAIL PROTECTED]
Lotus Notes : Thanh Dao/Santa Teresa/IBM
VM Node : IBMUSM50(daot)
Phone : (408)463-3298,  TL: 8-543-3298


Tim Bunce <[EMAIL PROTECTED]> on 08/11/2000 10:33:31 AM

To:   Thanh Dao/Santa Teresa/IBM@IBMUS
cc:   [EMAIL PROTECTED], Sandy Hartman/Santa Teresa/IBM@IBMUS
Subject:  Re: Register DBD::DB2 for OS/390



On Thu, Jul 20, 2000 at 01:14:09PM -0700, [EMAIL PROTECTED] wrote:
>
> Name: Thanh Dao
> Email address: [EMAIL PROTECTED]
> Prefered ID on CPAN: DAOT
> Contribution: Port DBD::DB2 driver to OS/390:
> Name  DSLI  Discription   Info
> DBD::DB2  adcO  DBD::DB2 driver on OS/390
>
> Regards,
> Thanh
> Internet Address : [EMAIL PROTECTED]
> Lotus Notes : Thanh Dao/Santa Teresa/IBM
> VM Node : IBMUSM50(daot)
> Phone : (408)463-3298,  TL: 8-543-3298

I'm not sure what you're actually registering for.

CPAN doesn't usually store pre-built binaries of modules.

If what you've got is source code changes to the existing IBM DBD::DB2
module, to make it build on OS/390, then they should be fed back to the
maintainers of the module.

Or am I misunderstanding you?

Tim.






It's not about Rollerblading ...

2000-08-11 Thread B . Ingerson

... or Inline skating.

Inline.pm is about making C extensions easy to write in Perl.

Sorry to use a cheap tactic to get your attention. (But I guess I've gotten
it :-) This is the third post I sent regarding what is, IMO, an extremely
provocative module. And I have yet to receive one comment from *anyone*. I
guess the Perl 6 list (which has generated ~6meg of traffic in 3 weeks) is
taking up everyone's time.

I *have* gotten a lot of ethusiasm on the Seattle Perl User's Group list
([EMAIL PROTECTED]). They have now tested it successfully on 5 Unix
variants, using both Perl v5.005 and v5.6. And Damian Conway *has* got back
to me now. He really likes it.

The module is packaged and ready to upload as soon as I get the word from
PAUSE. But I noticed today that modules list has not been updated since
June 27th. Again, here is my request info and the text version of the
module doc.

Thanks in advance, Brian


Name   DSLI  Description  Info
-     -
Inline adhh  Use other programming languages inside Perl  INGY


NAME
Inline - Use other languages inside your Perl scripts and
modules.

SYNOPSIS
print "9 + 16 = ", add(9, 16), "\n";
print "9 - 16 = ", subtract(9, 16), "\n";

use Inline C => <<'END_OF_C_CODE';

int add(int x, int y) {
  return x + y;
}

int subtract(int x, int y) {
  return x - y;
}

END_OF_C_CODE

DESCRIPTION
  Overview

The `Inline' module allows you to put source code from other
programming languages directly "Inline" in a Perl script or
module. The code is automatically compiled as needed, and then
loaded for immediate access from Perl.

`Inline' saves you from the hassle of having to write and
compile your own glue code using facilities like XS or SWIG.
Simply type the code where you want it and run your Perl as
normal. All the hairy details are handled for you. The
compilation and installation of your code chunks all happen
transparently; all you will notice is the delay of compilation.

The `Inline' code only gets compiled the first time you run it
(or whenever it is modified) so you only take the performance
hit once. Code that is Inlined into distributed modules (like on
the CPAN) will get compiled when the module is installed (during
"`make test'"), so the end user will never notice the
compilation time.

  Why Inline?

Do you want to know "Why would I use other languages in Perl?"
or "Why should I use `Inline' to do it?"? I'll try to answer
both.

Why would I use other languages in Perl?
The most obvious reason is performance. For an interpreted
language, Perl is extremely fast. But like my co-workers say
"Anything Perl can do, C can do faster". (They never mention
the development time ;-) Anyway, you may be able to remove a
bottleneck in your Perl code by using another language,
without having to write the entire program in that language.
This keeps your overall development time down, because
you're using Perl for all of the non-critical code.

Another reason is to access functionality from existing API-
s that use the language. Some of this code may only be
available in binary form. But by creating small subroutines
in the native language, you can "glue" existing libraries to
your Perl. As a user of the CPAN, you know that code reuse
is a good thing. So why throw away those Fortran libraries
just yet?

Maybe the best reason is "Because you want to!". Diversity
keeps the world interesting. TMTOWTDI!

Why should I use `Inline' to do it?
There are already two major facilities for extending Perl
with C. They are XS and SWIG. Now if you're familiar with
either, then I may be preaching to the choir. Well, here
goes:

 

Greetings congregation. This morning I want to open your
eyes to the virtues of Inline and the perils of XS. Let us
compare the two.

---

Inline - You can use it from a regular script.

XS - Requires you to create a module and an XS file and a
makefile, in addition to your regular script. Actually, the
program `h2xs' does a nice job of getting you started, but
that's still a lot of junk to maintain.

---

XS - You need rebuild every time you want to test a small
change.

Inline - Perl programmers cannot be bothered with silly
things like compiling. "Tweak, Run, Tweak, Run" is our way
of life. `Inline' does all the dirty work for you.

---

XS - There is a difficult learning curve involved with
setting up and using the XS environment. (At least for a
simple Perl preacher lik