apachetoolbox-devel — Developers Mailing list

Re: [Apachetoolbox-devel] Re: mod_watch in .58: improved (bin attached)

[Kevin J. M. Jr. <km...@WP...>]

Toni Mueller wrote:

> Then I contacted the author of that
> module who suggested using ranlib on the generated library, which
> made it work.

Ok.  I just never heard of it, so I was trying to learn a bit more about it.

> 
> So I regard the ranlib command as mandatory...
> 

Ok, then it stays :)


> PS: Do you mind setting Reply-To?

Done.  Man, I'm not a big fan of this Mozilla mail client.  I can't wait 
until my laptop gets back.  I'm only using this now for the IMAP support 
so I can download my mail when it gets back.

So far I haven't had much luck getting this to compile, but I'm sure 
it's something minor.  Also, I really don't use sed but I could figure 
out what you were doing just fine.  But do you know if there's any 
differences between gnu sed and perhaps the stock hp-ux or solaris sed? 
  I just want to make sure this works cross-platform.  Otherwise, I can 
just change it to a perl call just as easily.

-Kevin

Re: [Apachetoolbox-devel] Re: mod_watch in .58: improved (bin attached)

[Toni M. <su...@oe...>]

Hi Kevin,

On Fri, Jul 12, 2002 at 08:31:19AM -0700, Kevin J. Menard, Jr. wrote:
> Toni Mueller wrote:
> > The last patch I sent in was
> > missing a ranlib command, rendering the generated library  rather
> > useless.
> Pardon my ignorance, but what is ranlib really useful for?  I read the 
> man page, and it mentioned speed ups in library access, but is a) this 
> necessary, and b) how marginal of a speed up are we speaking?

well, ranlib generates an index... although I don't fully understand
it and am not very current in C programming anymore, I first forgot
it since I didn't know it was important. The result was that I was
getting unresolved symbols at the link stage despite seeing the
correct symbols in the library. Then I contacted the author of that
module who suggested using ranlib on the generated library, which
made it work.

So I regard the ranlib command as mandatory...


Best,
--Toni++

PS: Do you mind setting Reply-To?

[Apachetoolbox-devel] Re: mod_watch in .58: improved (bin attached)

[Toni M. <su...@oe...>]

Hi,

I just wanted to make sure that you get the latest (now a few weeks
old) I had for usage with mod_watch. The last patch I sent in was
missing a ranlib command, rendering the generated library  rather
useless.


Best,
--Toni++

[Apachetoolbox-devel] Re: thank you for a brilliant bit of software.

[Bryan <io...@ap...>]

On Sun, 30 Jun 2002, Alex Bloor wrote:

> Hi Bryan,
> 
> Just a quick note to thank you for a truly fantastic bit of software. Recent 
> 'irregularities' with GD2 and PHP have made getting a working PHP with 
> GD/TTF support something of a minefield. Your program sorted it out in a few 
> short minutes. Thank you very much indeed. 
> 
> Alex.
> 
> 
> Alex Bloor, Xela Limited
> T: 0845 130 XELA       F: 0845 658 XELA
> E: al...@xe...     W: http://www.xela.net
> 
> 

[Apachetoolbox-devel] more work done on 2.0.0

[Kevin J. M. Jr. <km...@WP...>]

Hey Apache,

  Check out the kevin/ directory on sf.  install.sh is working somewhat
  alright now.  I'd like to know if anyone sees anything really ugly with
  the code they don't like (I do, but it works :)).  The sorting is not
  correct right now, and the tabbing is not either.  Aesthetics come after
  functionality :)

  If you want to fool around with migrate.pl and module-tool.pl, go ahead
  too, but both are lacking a lot of functionality right now.  But they are
  progressing.

  Let me know.

  Thanks.

-- 
 Kevin

[Apachetoolbox-devel] Prototype almost ready

[Jay L. <jla...@in...>]

Kevin,

I think we're almost ready to test out the first prototype.

Legacy conf files to new conf file conversion would be excellent. I
think you'll find that it isn't that hard to do...but you never know.

My work is slim on docs but seems to be quite functional. The UI is a
bit clumsy but so am I. ;-)

Expect code in your hands very soon,
J

On Fri, 5 Oct 2001, Kevin J. Menard, Jr. wrote:

> Hey guys,
>
>     Well, I finally read this email.  This idea is pretty much the route I
>     was taking (actually almost to a T), but it's a hell of a lot prettier
>     than what I was coming up with :)  Right now, in school I am pretty
>     busy, and I don't think I would have had time to write out the core
>     program.
>
>     Jay, when you get the code up, let me know ASAP though, because I plan
>     on writing a legacy module conversion script (as well as allowing one to
>     add modules quite trivially).  This I think would ease the transition
>     quite a bit.
>
>     Other than that, I would like to head up a packaging implementation with
>     this as well.  I could work no the debianification, but the RPM support
>     on debian is rather minimal, so I would encourage someone else to work
>     on it.
>
>     That's all.
>
> --
>  Kevin
>
> Sunday, September 23, 2001, 5:49:26 PM, you wrote:
>
> B> Very impressive!  I can't thank you enough for the time and effort you're
> B> putting into this!  Have a blast with the house!  I've added you into the
> B> apachetoolbox project on sourceforge, if there's something something I
> B> missed on SF let me know.
>
> B> -Bryan
>
> B> On Sat, 22 Sep 2001, Jay Lawrence wrote:
>
> >>
> >> Dear Bryan,
> >>
> >> How are things? Just a quick note to let you know I have made some
> >> excellent progress with my concept for Apachetoolbox. I think you're
> >> going to be suprised.
> >>
> >> I have to say that what I am writing is a bit of a departure from what
> >> you have so far. Although I may have taken some more elaborate
> >> approaches to programming this I think you guys will find that it
> >> works well and logically.
> >>
> >> I don't want to send you demo code *just* yet because I want to pass
> >> it through one refactoration phase. At least then I will have better
> >> method naming and probably break it apart into more logical chuncks
> >> than it currently stands.
> >>
> >> In a nutshell however, this is what I've been doing:
> >>
> >>  a - Base class Apachetoolbox drives:
> >>        - build sequence
> >>        - save/load
> >>        - global preferences
> >>        - inherits its choice of ONE UI module below
> >>
> >>  b - Each software package has its own package which inherits
> >>      Apachetoolbox::Application. This package does:
> >>        - registers itsself with Apachetoolbox class
> >>        - fetch/check/unpack
> >>        - configure, make, and install
> >>        - configuration options list
> >>
> >>  c - Each software package can have a list of modules (Apache
> >>      being the most obvious case). Each module inherits
> >>      Apachetoolbox::<application>::mod. This package
> >>       - registers itsself with its application
> >>       - configuration options related to this module for the
> >>         main app
> >>
> >>  d - There are any number of UI modules. The one that I am going
> >>      to focus on is a Curses one. It is not a big stretch to build
> >>      a CGI, Tk or GTk UI module at all.
> >>       - provides all menus and user prompts
> >>
> >> What works now:
> >>  a - building of standard modules and libraries
> >>      - the funky processes like for mod_perl and PHP still needs to be
> >>        addressed - but all in good time
> >>      - I have not tackled 3rd party apache modules just yet either
> >>
> >>      - these will come next after I've finished refactoring and can
> >>        send you demo code
> >>
> >>  b - Main menu and submenu code in Curses module
> >>      - subject of my code refactoring now
> >>
> >>  c - Src download and verification
> >>      - one idea might be to build a list of sites for a program
> >>
> >> Things for consideration
> >>  1 - conversion of current configuration to new save file format
> >>  2 - I'm only building on RedHat 7.1 for now ... but I need to build
> >>      on Solaris as well. There are necessary hints for different
> >>      architectures, I am sure. (MySQL is one of them)
> >>  3 - scads of other stuff I am sure.
> >>
> >> Unfortunately, I have to focus on some other projects around here.
> >> Namely the renovation of my house! So I cannot put as much time into
> >> this as I'd like. But, I want to take this to deliverable status ASAP
> >> because I need it for my work too.
> >>
> >> Anyway, what I can do is upload the code to sourceforge and then you
> >> guys can try it on for size.
> >>
> >> Cheers,
> >> Jay
> >>
>
>
> B> _______________________________________________
> B> Apachetoolbox-devel mailing list
> B> Apa...@li...
> B> https://lists.sourceforge.net/lists/listinfo/apachetoolbox-devel
>

-- 
Jay Lawrence  - 613-795-9169 - ja...@in...
Infonium Inc. - Open Source Information Management Strategies

Re: [Apachetoolbox-devel] Re: Perlifying AT - Continues

[Jay L. <jla...@in...>]

Kevin,

>     was taking (actually almost to a T), but it's a hell of a lot prettier
>     than what I was coming up with :)  Right now, in school I am pretty
>     busy, and I don't think I would have had time to write out the core
>     program.
>
>     Jay, when you get the code up, let me know ASAP though, because I plan
>     on writing a legacy module conversion script (as well as allowing one to
>     add modules quite trivially).  This I think would ease the transition
>     quite a bit.
>
>     Other than that, I would like to head up a packaging implementation with
>     this as well.  I could work no the debianification, but the RPM support
>     on debian is rather minimal, so I would encourage someone else to work
>     on it.
>
>     That's all.
>
> --
>  Kevin
>
> Sunday, September 23, 2001, 5:49:26 PM, you wrote:
>
> B> Very impressive!  I can't thank you enough for the time and effort you're
> B> putting into this!  Have a blast with the house!  I've added you into the
> B> apachetoolbox project on sourceforge, if there's something something I
> B> missed on SF let me know.
>
> B> -Bryan
>
> B> On Sat, 22 Sep 2001, Jay Lawrence wrote:
>
> >>
> >> Dear Bryan,
> >>
> >> How are things? Just a quick note to let you know I have made some
> >> excellent progress with my concept for Apachetoolbox. I think you're
> >> going to be suprised.
> >>
> >> I have to say that what I am writing is a bit of a departure from what
> >> you have so far. Although I may have taken some more elaborate
> >> approaches to programming this I think you guys will find that it
> >> works well and logically.
> >>
> >> I don't want to send you demo code *just* yet because I want to pass
> >> it through one refactoration phase. At least then I will have better
> >> method naming and probably break it apart into more logical chuncks
> >> than it currently stands.
> >>
> >> In a nutshell however, this is what I've been doing:
> >>
> >>  a - Base class Apachetoolbox drives:
> >>        - build sequence
> >>        - save/load
> >>        - global preferences
> >>        - inherits its choice of ONE UI module below
> >>
> >>  b - Each software package has its own package which inherits
> >>      Apachetoolbox::Application. This package does:
> >>        - registers itsself with Apachetoolbox class
> >>        - fetch/check/unpack
> >>        - configure, make, and install
> >>        - configuration options list
> >>
> >>  c - Each software package can have a list of modules (Apache
> >>      being the most obvious case). Each module inherits
> >>      Apachetoolbox::<application>::mod. This package
> >>       - registers itsself with its application
> >>       - configuration options related to this module for the
> >>         main app
> >>
> >>  d - There are any number of UI modules. The one that I am going
> >>      to focus on is a Curses one. It is not a big stretch to build
> >>      a CGI, Tk or GTk UI module at all.
> >>       - provides all menus and user prompts
> >>
> >> What works now:
> >>  a - building of standard modules and libraries
> >>      - the funky processes like for mod_perl and PHP still needs to be
> >>        addressed - but all in good time
> >>      - I have not tackled 3rd party apache modules just yet either
> >>
> >>      - these will come next after I've finished refactoring and can
> >>        send you demo code
> >>
> >>  b - Main menu and submenu code in Curses module
> >>      - subject of my code refactoring now
> >>
> >>  c - Src download and verification
> >>      - one idea might be to build a list of sites for a program
> >>
> >> Things for consideration
> >>  1 - conversion of current configuration to new save file format
> >>  2 - I'm only building on RedHat 7.1 for now ... but I need to build
> >>      on Solaris as well. There are necessary hints for different
> >>      architectures, I am sure. (MySQL is one of them)
> >>  3 - scads of other stuff I am sure.
> >>
> >> Unfortunately, I have to focus on some other projects around here.
> >> Namely the renovation of my house! So I cannot put as much time into
> >> this as I'd like. But, I want to take this to deliverable status ASAP
> >> because I need it for my work too.
> >>
> >> Anyway, what I can do is upload the code to sourceforge and then you
> >> guys can try it on for size.
> >>
> >> Cheers,
> >> Jay
> >>
>
>
> B> _______________________________________________
> B> Apachetoolbox-devel mailing list
> B> Apa...@li...
> B> https://lists.sourceforge.net/lists/listinfo/apachetoolbox-devel
>

-- 
Jay Lawrence  - 613-795-9169 - ja...@in...
Infonium Inc. - Open Source Information Management Strategies

Re: [Apachetoolbox-devel] Re: Perlifying AT - Continues

[Kevin J. M. Jr. <km...@WP...>]

Hey guys,

    Well, I finally read this email.  This idea is pretty much the route I
    was taking (actually almost to a T), but it's a hell of a lot prettier
    than what I was coming up with :)  Right now, in school I am pretty
    busy, and I don't think I would have had time to write out the core
    program.

    Jay, when you get the code up, let me know ASAP though, because I plan
    on writing a legacy module conversion script (as well as allowing one to
    add modules quite trivially).  This I think would ease the transition
    quite a bit.

    Other than that, I would like to head up a packaging implementation with
    this as well.  I could work no the debianification, but the RPM support
    on debian is rather minimal, so I would encourage someone else to work
    on it.

    That's all.

--
 Kevin

Sunday, September 23, 2001, 5:49:26 PM, you wrote:

B> Very impressive!  I can't thank you enough for the time and effort you're
B> putting into this!  Have a blast with the house!  I've added you into the
B> apachetoolbox project on sourceforge, if there's something something I
B> missed on SF let me know.

B> -Bryan

B> On Sat, 22 Sep 2001, Jay Lawrence wrote:

>>
>> Dear Bryan,
>>
>> How are things? Just a quick note to let you know I have made some
>> excellent progress with my concept for Apachetoolbox. I think you're
>> going to be suprised.
>>
>> I have to say that what I am writing is a bit of a departure from what
>> you have so far. Although I may have taken some more elaborate
>> approaches to programming this I think you guys will find that it
>> works well and logically.
>>
>> I don't want to send you demo code *just* yet because I want to pass
>> it through one refactoration phase. At least then I will have better
>> method naming and probably break it apart into more logical chuncks
>> than it currently stands.
>>
>> In a nutshell however, this is what I've been doing:
>>
>>  a - Base class Apachetoolbox drives:
>>        - build sequence
>>        - save/load
>>        - global preferences
>>        - inherits its choice of ONE UI module below
>>
>>  b - Each software package has its own package which inherits
>>      Apachetoolbox::Application. This package does:
>>        - registers itsself with Apachetoolbox class
>>        - fetch/check/unpack
>>        - configure, make, and install
>>        - configuration options list
>>
>>  c - Each software package can have a list of modules (Apache
>>      being the most obvious case). Each module inherits
>>      Apachetoolbox::<application>::mod. This package
>>       - registers itsself with its application
>>       - configuration options related to this module for the
>>         main app
>>
>>  d - There are any number of UI modules. The one that I am going
>>      to focus on is a Curses one. It is not a big stretch to build
>>      a CGI, Tk or GTk UI module at all.
>>       - provides all menus and user prompts
>>
>> What works now:
>>  a - building of standard modules and libraries
>>      - the funky processes like for mod_perl and PHP still needs to be
>>        addressed - but all in good time
>>      - I have not tackled 3rd party apache modules just yet either
>>
>>      - these will come next after I've finished refactoring and can
>>        send you demo code
>>
>>  b - Main menu and submenu code in Curses module
>>      - subject of my code refactoring now
>>
>>  c - Src download and verification
>>      - one idea might be to build a list of sites for a program
>>
>> Things for consideration
>>  1 - conversion of current configuration to new save file format
>>  2 - I'm only building on RedHat 7.1 for now ... but I need to build
>>      on Solaris as well. There are necessary hints for different
>>      architectures, I am sure. (MySQL is one of them)
>>  3 - scads of other stuff I am sure.
>>
>> Unfortunately, I have to focus on some other projects around here.
>> Namely the renovation of my house! So I cannot put as much time into
>> this as I'd like. But, I want to take this to deliverable status ASAP
>> because I need it for my work too.
>>
>> Anyway, what I can do is upload the code to sourceforge and then you
>> guys can try it on for size.
>>
>> Cheers,
>> Jay
>>


B> _______________________________________________
B> Apachetoolbox-devel mailing list
B> Apa...@li...
B> https://lists.sourceforge.net/lists/listinfo/apachetoolbox-devel

Re: [Apachetoolbox-devel] Your versions of perl?

[Jay L. <jla...@in...>]

Agreed - I am so used to 5.6 now but can downgrade with little
difficulty. Also the case of the termcap - I am writing the UI as a
separate module - a plain text is not out of the question. Very
similar to the Curses but no real jazz.

Stay tuned.

j

On Mon, 24 Sep 2001, Kevin J. Menard, Jr. wrote:

> Hey Jay,
>
>
> Tuesday, September 25, 2001, 3:17:07 AM, you wrote:
>
>
> JL> Hey guys,
>
> JL> What versions of Perl do you have on your systems?
>
> I use 5.6.1.  SF has 5.003 or something.  I ran into issues when I tried to
> use the "our" scope operator and found it was 5.6 dependent.  So, I ended up
> using use vars.  I guess we should decide what version to aim for, but i
> think cutting the 5.00x crowd out would be a bad idea.
>
> --
>  Kevin
>

-- 
Jay Lawrence  - 613-795-9169 - ja...@in...
Infonium Inc. - Open Source Information Management Strategies

Re: [Apachetoolbox-devel] Your versions of perl?

[Kevin J. M. Jr. <km...@WP...>]

Hey Jay,


Tuesday, September 25, 2001, 3:17:07 AM, you wrote:


JL> Hey guys,

JL> What versions of Perl do you have on your systems?

I use 5.6.1.  SF has 5.003 or something.  I ran into issues when I tried to
use the "our" scope operator and found it was 5.6 dependent.  So, I ended up
using use vars.  I guess we should decide what version to aim for, but i
think cutting the 5.00x crowd out would be a bad idea.

--
 Kevin

[Apachetoolbox-devel] Your versions of perl?

[Jay L. <jla...@in...>]

Hey guys,

What versions of Perl do you have on your systems?

I tried to use Sourceforges but the curses stuff does not work due to
missing termcap files. :(

J

[Apachetoolbox-devel] Re: Perlifying AT - Continues

[Bryan <io...@ap...>]

Very impressive!  I can't thank you enough for the time and effort you're
putting into this!  Have a blast with the house!  I've added you into the
apachetoolbox project on sourceforge, if there's something something I
missed on SF let me know.

-Bryan

On Sat, 22 Sep 2001, Jay Lawrence wrote:

>
> Dear Bryan,
>
> How are things? Just a quick note to let you know I have made some
> excellent progress with my concept for Apachetoolbox. I think you're
> going to be suprised.
>
> I have to say that what I am writing is a bit of a departure from what
> you have so far. Although I may have taken some more elaborate
> approaches to programming this I think you guys will find that it
> works well and logically.
>
> I don't want to send you demo code *just* yet because I want to pass
> it through one refactoration phase. At least then I will have better
> method naming and probably break it apart into more logical chuncks
> than it currently stands.
>
> In a nutshell however, this is what I've been doing:
>
>  a - Base class Apachetoolbox drives:
>        - build sequence
>        - save/load
>        - global preferences
>        - inherits its choice of ONE UI module below
>
>  b - Each software package has its own package which inherits
>      Apachetoolbox::Application. This package does:
>        - registers itsself with Apachetoolbox class
>        - fetch/check/unpack
>        - configure, make, and install
>        - configuration options list
>
>  c - Each software package can have a list of modules (Apache
>      being the most obvious case). Each module inherits
>      Apachetoolbox::<application>::mod. This package
>       - registers itsself with its application
>       - configuration options related to this module for the
>         main app
>
>  d - There are any number of UI modules. The one that I am going
>      to focus on is a Curses one. It is not a big stretch to build
>      a CGI, Tk or GTk UI module at all.
>       - provides all menus and user prompts
>
> What works now:
>  a - building of standard modules and libraries
>      - the funky processes like for mod_perl and PHP still needs to be
>        addressed - but all in good time
>      - I have not tackled 3rd party apache modules just yet either
>
>      - these will come next after I've finished refactoring and can
>        send you demo code
>
>  b - Main menu and submenu code in Curses module
>      - subject of my code refactoring now
>
>  c - Src download and verification
>      - one idea might be to build a list of sites for a program
>
> Things for consideration
>  1 - conversion of current configuration to new save file format
>  2 - I'm only building on RedHat 7.1 for now ... but I need to build
>      on Solaris as well. There are necessary hints for different
>      architectures, I am sure. (MySQL is one of them)
>  3 - scads of other stuff I am sure.
>
> Unfortunately, I have to focus on some other projects around here.
> Namely the renovation of my house! So I cannot put as much time into
> this as I'd like. But, I want to take this to deliverable status ASAP
> because I need it for my work too.
>
> Anyway, what I can do is upload the code to sourceforge and then you
> guys can try it on for size.
>
> Cheers,
> Jay
>

[Apachetoolbox-devel] Howdy guys

[Jay L. <jla...@in...>]

Hey,

I have joined the list now that I see that it is just the two of you
on here! ;-)

If you have a chance, please feel free to add me to the project. My
sourceforge ID is "jlawrenc"

Thanks,
Jay

Re: [Apachetoolbox-devel] Re: Perlifying AT

[Kevin J M. <km...@WP...>]

Awesome.  I've been hesitant about the making a module object thus far
(and objects for everything else).  This sounds very similar to what I
have proposed thus far.  Once we have the class form, writing a utility to
convert legacy modules over would be quite trivial.  Please check the
archives on my past proposals.  And if you join the project, check out the
kevin/ directory on sf.

On Tue, 18 Sep 2001, Bryan wrote:

> You've got me very excited now! I can't wait to see an alpha version.  Its
> hard to get started, but I feel once you have a working framework it will
> be easy for us to get going.  If you'd like on the offical ATB devel list
> let me know your handle on sourceforge.  If not don't worry about it, not
> really needed.
>
> The only catch I see so far (from what I've read) is a lack of module
> dependancie, freetype2 is needed by GD which needs libPNG, etc.  Shouldn't
> be too difficult I guess.  I can't thank you enough!
>
> -Bryan
>
> On Tue, 18 Sep 2001, Jay Lawrence wrote:
>
> >
> > Dear Bryan,
> >
> > I have been making a stab at the perlification process. Here is the
> > general gist of what I'm doing.
> >
> > a - every application, module or library is its own class file that
> > inherits basic operations from a base class
> >
> > b - there's a main class for all general configurations.
> >
> > c - all "configured" or "configurable" parameters are expressed in
> > each class file as a multilevel hash. Have a program - configure2pl
> > that extracts ./configure --help output to ease the development
> > process.
> >
> > d - nothing is/will be hardcoded except default values - but then we
> > can make anything configurable.
> >
> > e - each application, module or library has a descriptive block all
> > about itsself
> >
> > f - provisions for descriptions and help text for everything
> >
> > g - provisions for pick lists of value choices
> >
> > h - provisions for several prompt levels = basic choices -> advanced
> > user choices
> >
> > i - No module dependancies for Perl (at this point) - I have even
> > elected to use "wget" as it seems like a pretty slick tool! Not
> > everybody has "LWP" installed but existing Apachetoolbox users will no
> > doubt have wget.
> >
> >
> > I've been working with MySQL as my first app and am now up to:
> >  - get source
> >  - unpack
> >  - configure
> >  - make
> >  - test
> >  - install
> >
> > I've included a mechansim to check source files using md5sum or
> > expected file length.
> >
> > There's no practical limitations that I know of at this time.
> >
> > -----------
> >
> > I don't want to steal your thunder on Apachetoolbox - I just sat down
> > tonight and got on a roll. ;-)
> >
> > I do hope you're cool if I put my name on the copyright ALONG with
> > yours for the stuff that I write? Is that ok?
> >
> > Anyway, once I get load/save and menu prompts working I'll send you
> > demo.
> >
> > Cheers,
> > Jay
> >
> > On Mon, 10 Sep 2001, Bryan wrote:
> >
> > > I'd love the help!  I've currently setup a project on sourceforge.net for
> > > the development of ATB v2.0.  Besides me, there's currently 1 other
> > > member, and he's back in school now.  I'm just beginning with perl and I
> > > don't feel like I'm at the level I need to be for ATB 2.0 yet.  So I'll
> > > take any and all help I could get!
> > >
> > > -Bryan
> > >
> > > On Sun, 9 Sep 2001, Jay Lawrence wrote:
> > >
> > > >
> > > > Hey Bryan,
> > > >
> > > > I have been exercising AT recently. (Myself, I had my own automated
> > > > build system underway before seeing yours). Anyway, I really like what
> > > > I see but of course have uncovered a number of limitations that I'd
> > > > like to work around.
> > > >
> > > > Being that I program in Perl 99% of my life I'd like to migrate Bourne
> > > > shell code to Perl. I thought I saw a reference somewhere that said
> > > > you'd like to see that happen.
> > > >
> > > > I have been thinking/sketching out what I think is a very viable way
> > > > to offer a flexible and robust interface to what has been written
> > > > already.
> > > >
> > > > Is this of interest to you?
> > > > Have you written anything to this end already?
> > > > Do you have things that you want to achieve going forward?
> > > >
> > > > Lemme know - I'd be glad to collaborate and have prototyped some stuff
> > > > already.
> > > >
> > > > Cheers,
> > > > Jay
> > > >
> > > >
> > > >
> > >
> >
> >
>
>
> _______________________________________________
> Apachetoolbox-devel mailing list
> Apa...@li...
> https://lists.sourceforge.net/lists/listinfo/apachetoolbox-devel
>

[Apachetoolbox-devel] Re: Perlifying AT

[Bryan <io...@ap...>]

You've got me very excited now! I can't wait to see an alpha version.  Its
hard to get started, but I feel once you have a working framework it will
be easy for us to get going.  If you'd like on the offical ATB devel list
let me know your handle on sourceforge.  If not don't worry about it, not
really needed.

The only catch I see so far (from what I've read) is a lack of module
dependancie, freetype2 is needed by GD which needs libPNG, etc.  Shouldn't
be too difficult I guess.  I can't thank you enough!

-Bryan

On Tue, 18 Sep 2001, Jay Lawrence wrote:

>
> Dear Bryan,
>
> I have been making a stab at the perlification process. Here is the
> general gist of what I'm doing.
>
> a - every application, module or library is its own class file that
> inherits basic operations from a base class
>
> b - there's a main class for all general configurations.
>
> c - all "configured" or "configurable" parameters are expressed in
> each class file as a multilevel hash. Have a program - configure2pl
> that extracts ./configure --help output to ease the development
> process.
>
> d - nothing is/will be hardcoded except default values - but then we
> can make anything configurable.
>
> e - each application, module or library has a descriptive block all
> about itsself
>
> f - provisions for descriptions and help text for everything
>
> g - provisions for pick lists of value choices
>
> h - provisions for several prompt levels = basic choices -> advanced
> user choices
>
> i - No module dependancies for Perl (at this point) - I have even
> elected to use "wget" as it seems like a pretty slick tool! Not
> everybody has "LWP" installed but existing Apachetoolbox users will no
> doubt have wget.
>
>
> I've been working with MySQL as my first app and am now up to:
>  - get source
>  - unpack
>  - configure
>  - make
>  - test
>  - install
>
> I've included a mechansim to check source files using md5sum or
> expected file length.
>
> There's no practical limitations that I know of at this time.
>
> -----------
>
> I don't want to steal your thunder on Apachetoolbox - I just sat down
> tonight and got on a roll. ;-)
>
> I do hope you're cool if I put my name on the copyright ALONG with
> yours for the stuff that I write? Is that ok?
>
> Anyway, once I get load/save and menu prompts working I'll send you
> demo.
>
> Cheers,
> Jay
>
> On Mon, 10 Sep 2001, Bryan wrote:
>
> > I'd love the help!  I've currently setup a project on sourceforge.net for
> > the development of ATB v2.0.  Besides me, there's currently 1 other
> > member, and he's back in school now.  I'm just beginning with perl and I
> > don't feel like I'm at the level I need to be for ATB 2.0 yet.  So I'll
> > take any and all help I could get!
> >
> > -Bryan
> >
> > On Sun, 9 Sep 2001, Jay Lawrence wrote:
> >
> > >
> > > Hey Bryan,
> > >
> > > I have been exercising AT recently. (Myself, I had my own automated
> > > build system underway before seeing yours). Anyway, I really like what
> > > I see but of course have uncovered a number of limitations that I'd
> > > like to work around.
> > >
> > > Being that I program in Perl 99% of my life I'd like to migrate Bourne
> > > shell code to Perl. I thought I saw a reference somewhere that said
> > > you'd like to see that happen.
> > >
> > > I have been thinking/sketching out what I think is a very viable way
> > > to offer a flexible and robust interface to what has been written
> > > already.
> > >
> > > Is this of interest to you?
> > > Have you written anything to this end already?
> > > Do you have things that you want to achieve going forward?
> > >
> > > Lemme know - I'd be glad to collaborate and have prototyped some stuff
> > > already.
> > >
> > > Cheers,
> > > Jay
> > >
> > >
> > >
> >
>
>

[Apachetoolbox-devel] Slow website?

[Bryan <io...@ap...>]

Is www.apachetoolbox.com painfully slow for you today? I'm thinkin about
moving the site from the andover shell to SF, as soon as the SF guys make
a mysql table for us.

-Bryan

[Apachetoolbox-devel] first working copy

[Kevin J. M. Jr. <km...@wp...>]

Hey guys,

    Well, I've been cracking away on this project, and I think I finally got
    some code that might be worth taking a look at.  Really, it's still
    nothing extremely functional, and probably not the prettiest code of
    all.  I figured I'd send this out before I got too involved though.
    Perhaps I can get some feedback.

    The file is named test.pl.  It is in the
    /home/groups/a/ap/apachetoolbox/kevin folder on the SourceForge servers.
    Right now, the code works like this:

    test.pl -- contains all the main code.  I will probably delegate some of
    this code to a separate file with subroutine definitions.  As of right
    now, I've encapsulated certain relevant blocks of code within curly
    braces, but have not yet made them into subroutines.  There are 2 hashes
    that really drive this program as of right now:

         %versions -- through a nifty little hack if you will, I came up
         with a way to use our old versions file.  Originally, I was going
         to change the entire format of it, but then it dawned on me to make
         a hash.  It works very nicely, as something like $version{'MODMP3'}
         gets you the version of mod_mp3, and you have a really good idea of
         what this variable actually does :)

         %menu -- this is really a hash of hashes.  All the files in bin/
         are read in and parsed.  Each one of these files is treated as a
         module prototype (TM? :)) if you will.  Intentions right now are to
         add depth corresponding to other modules (e.g. a bin/php which
         would then contain one file per php module to add in).  These files
         contain minimum data right now, just enough to build a working
         menu (more below).

    etc/versions.conf -- file with version information.  For the most part,
    ripped right out of the 1.5.x distro.  There's a couple things that need
    to change, and I haven't updated this file yet to reflect that.  The
    general format is MODULENAME=VERSION.

    bin/ files -- used to load in info representing a single module.  Right
    now, I'm using a tags based system for this.  Not tags as in ML, but as
    in CAPITALLETTERS=value.  Right now, INDEX is the index value on the
    menu.  TITLE is the title to display.  The TITLE value can take a
    variable for the version, which is '$' followed by the value from
    etc/versions.conf.  The test.pl emulates interpolation of this variable.
    In reality, the line is parsed, the '$' discarded, and the value after
    the '$' is used as a key in the %version hash.  This only works if the
    version is the last part of the title (only place it makes sense, but
    too restricting, rather too ugly from a coding perspective).

    I think within the near future, I will write a perl class for the
    modules.  The class itself will be a pure virtual one.  Then each module
    will inherit it, and have to set certain values itself.  This would in
    effect, allow ATB itself to be infinitely extensible.  Plop the new
    module file into bin/ and add a line to etc/versions.conf.  I'll
    probably write a tool to add new modules too :)

    One last note: this script is written with an 80 character / line
    display in mind (what most ssh clients are).  It should look fine at
    higher rates, but most systems are this by default, so this is what I
    coded for.  So, with the number of modules increasing, assuming 25 line
    display, we'll have to add page1) page2) page3) and so on links.  I'll
    come up with a way to do that dynamically :)  Now, that's extensibility
    for ya :-P

    Please review the code.  Ask any questions.  I've provided comments
    rather graciously, but not superfluously.  I use a pretty strict coding
    style.  I know a lot of people don't exactly do it the same way I do.  I
    think we should draft some sort of best practices coding standard, but
    it's not an issue as of yet.  I don't expect everyone to do what I do,
    but I expect it to be clear as to what you're doing, and commented well.

    You'll notice that I prefer to space '('s away from if, for, while, and
    so on, as in

    if ($yo eq "true").

    I also, like to drop my curly braces down to the next line.  It looks
    more like a block to me and is easier to read.

    That is:

    if ($yo eq "true")
    {
       print "yo\n";
    }

    Rather than:

    if ($yo eq "true") {
       print "yo\n";
    }

    Except for one line code jobs.  Then I put it all on one line.

    Like I said.  Questions.  Comments.  Complaints.  All is welcome.

-- 
 Kevin

Re[2]: [Apachetoolbox-devel] First Pass Implementation

[Kevin J. M. Jr. <km...@wp...>]

Hey Bryan,


Monday, July 23, 2001, 11:09:32 AM, you wrote:

B> This is a very good idea!

Thanks.

B> I was thinkin along the same line, could we use
B> directories in the bin/ directory to build a submenu from?

That's something I'm still working out.  I'm thinking a new mapping would be
bin/apache-modules bin/apache-modules/core-modules
bin/php-modules and then just bin/ for misc stuff.  Provides a little better
organization.

B> it would be nice to have the menu placement information, the module
B> version information, and the actions the module needs to do, all right
B> there in 1 file.

Well, I was thinking still have a separate versions file.  If the files in
bin/ read the info from etc/versions.conf, then multi module updates really
could be handled with a single file change :)

B> We'll need to take into consideration global modules like openssl. it
B> needs to be a module to install, but it also needs to be called from
B> mod_php if the --with-openssl option was selected from mod_php. and of
B> cource mod_ssl needs to run it to make sure openssl is installed before it
B> runs. we'll have to have bin/openssl (or whatever it's callee) 'export' a
B> global variable with openssl's version number after it runs the first
B> time. this way any modules afterward that need openssl wont have to run
B> anything.

Ok.  I was just thinking hardlinks to each directory it might be needed, but
whatever ;)

B> you know this is a seperate program in of itself.  a lot of poeple would
B> have a use for this menu-system-framework. make it easy and stablable and
B> we'll have to register it's own domain just for it!

Heh.  So, I should have all the various options needed loaded in by a
separate config file too.  And then in the config file, say
"title;code;whatever".  We'll see.  I'll probably embed it into the
subroutines parameters.  Gets to a point where it's a pain in the ass to
keep track of so many different files too ;)

B> hehe I've been working more and more in perl (little system utilities) so
B> I shouldn't be completely worthless.

That's what perl's useful for ;)  Seriously though, if you know C, perl
won't be that hard to pick up on.  Just get Programming Perl 3rd Edition :)

B> Do you want ke...@ap... to forward to your real account? Do
B> you even want an @apachetoolbox.com email address? It's yours if you want
B> it.

Yeah, that'd be cool.  But I'd probably have it nir...@ap...
so it parallels my forum name, if that's no biggie.

B> -Bryan

-- 
 Kevin

Re: [Apachetoolbox-devel] First Pass Implementation

[Bryan <io...@ap...>]

This is a very good idea! I was thinkin along the same line, could we use
directories in the bin/ directory to build a submenu from? it would be
nice to have the menu placement information, the module version
information, and the actions the module needs to do, all right there in 1
file.

We'll need to take into consideration global modules like openssl. it
needs to be a module to install, but it also needs to be called from
mod_php if the --with-openssl option was selected from mod_php. and of
cource mod_ssl needs to run it to make sure openssl is installed before it
runs. we'll have to have bin/openssl (or whatever it's callee) 'export' a
global variable with openssl's version number after it runs the first
time. this way any modules afterward that need openssl wont have to run
anything.

you know this is a seperate program in of itself.  a lot of poeple would
have a use for this menu-system-framework. make it easy and stablable and
we'll have to register it's own domain just for it! hehe I've been working
more and more in perl (little system utilities) so I shouldn't be
completely worthless.

Do you want ke...@ap... to forward to your real account? Do
you even want an @apachetoolbox.com email address? It's yours if you want
it.

-Bryan


On Mon, 23 Jul 2001, Kevin J. Menard, Jr. wrote:

> Hey guys,
>
>     So, yeah, I haven't actually started to code anything yet <g>, but I
>     came up with an awesome idea this weekend (or so it seems atm).
>
>     This really should allow us to do a drop in module type thing.
>     Basically, the main atb program contains a hash of hashes.  When the
>     script starts up, we read all the entries in bin/ (or where ever),
>     which would correspond to one module accordingly.  This would populate
>     the hash and it's child hash.
>
>     Now, follow me here.
>
>     We sort the hash based on keys, and have a little for loop spit out the
>     menu, so it'll look like the existing one.
>
>     Now, the parent hash uses the value to select on the menu as the key.
>     So, for instance, PHP would have the key "php".  Then the sub hash would
>     have for instance a "title" key, which would say "PHP Menu" or what have
>     you.  Then a "code" key could contain a reference to code block
>     contained in the bin/ entry.
>
>     So, ideally, to add a new module, all you need to do is drop it into
>     bin, and hope the index value doesn't conflict with any others.  I'm
>     gonna try to start coding this soon.  Just been busy as hell lately.
>
>

[Apachetoolbox-devel] First Pass Implementation

[Kevin J. M. Jr. <km...@wp...>]

Hey guys,

    So, yeah, I haven't actually started to code anything yet <g>, but I
    came up with an awesome idea this weekend (or so it seems atm).

    This really should allow us to do a drop in module type thing.
    Basically, the main atb program contains a hash of hashes.  When the
    script starts up, we read all the entries in bin/ (or where ever),
    which would correspond to one module accordingly.  This would populate
    the hash and it's child hash.

    Now, follow me here.

    We sort the hash based on keys, and have a little for loop spit out the
    menu, so it'll look like the existing one.

    Now, the parent hash uses the value to select on the menu as the key.
    So, for instance, PHP would have the key "php".  Then the sub hash would
    have for instance a "title" key, which would say "PHP Menu" or what have
    you.  Then a "code" key could contain a reference to code block
    contained in the bin/ entry.

    So, ideally, to add a new module, all you need to do is drop it into
    bin, and hope the index value doesn't conflict with any others.  I'm
    gonna try to start coding this soon.  Just been busy as hell lately.

-- 
 Kevin

Re[2]: [Apachetoolbox-devel] gonna start

[Kevin J. M. Jr. <km...@WP...>]

Hey Bryan,


Thursday, June 28, 2001, 11:15:23 AM, you wrote:

B> I'm having a hard time getting mail to go through on the mailing list.

B> *hopes this goes through*

B> -Bryan

Got it.

-- 
 Kevin

Re: [Apachetoolbox-devel] gonna start

[Bryan <io...@da...>]

I'm having a hard time getting mail to go through on the mailing list.

*hopes this goes through*

-Bryan

On Thu, 28 Jun 2001, Kevin J. Menard, Jr. wrote:

> Hey guys,
>
>     Well, I'm going to start my first take on the 2.0 release.  I created a
>     directory called "kevin".  My files will go in there.  I want to get a
>     workable version before we commit anything.  I have a feeling this project
>     is going to take many structural twists and turns.
>
>     I ssh'ed to the compile farm server today, and that apparently is back up.
>     So, once we get a release that can download and compile stuff, I guess
>     that's where we should try it out.  They offer several platforms, which is
>     nifty.  However, I think not having root access is going to limit us.
>
>     Unless we offer the ability to build apache without root access, that is,
>     within a local directory, and binding to a non-priveleged port.  Just a
>     thought.
>
>

[Apachetoolbox-devel] gonna start

[Kevin J. M. Jr. <km...@WP...>]

Hey guys,

    Well, I'm going to start my first take on the 2.0 release.  I created a
    directory called "kevin".  My files will go in there.  I want to get a
    workable version before we commit anything.  I have a feeling this project
    is going to take many structural twists and turns.

    I ssh'ed to the compile farm server today, and that apparently is back up.
    So, once we get a release that can download and compile stuff, I guess
    that's where we should try it out.  They offer several platforms, which is
    nifty.  However, I think not having root access is going to limit us.

    Unless we offer the ability to build apache without root access, that is,
    within a local directory, and binding to a non-priveleged port.  Just a
    thought.

-- 
 Kevin

[Apachetoolbox-devel] test

[Bryan <io...@da...>]

test 4

[Apachetoolbox-devel] test

[Bryan <io...@da...>]

testing 3