On Sun, Aug 14, 2005 at 10:55:29PM -0400, michael chang wrote:
> On 8/14/05, Carol Spears <[EMAIL PROTECTED]> wrote:
> > On Sun, Aug 14, 2005 at 07:37:20PM -0400, michael chang wrote:
> > i think that the web page generated by the script i am sharing later in
> > this  email is much much worse!
> If I get a chance, I'll maybe take a look at it...
in a less than a half an hour i will see if cron puts my new efforts

> > well, i was mostly scripting.  not that the script is any prettier...
> > the images were made by another resource script i wrote, this one a
> > plugin for gimp http://carol.gimp.org/resources/python/resources.py
> > it would be trivial to change that script to make different shapes of
> > images.  and also trivial to use parts of that to make gimp make these
> > pages and images at the same time.  better because new patterns and
> > other resources can be added and you know the image will exist.  not
> > better because i am uncertain if i am able to run gimp in a way that
> > cron can use.
> So don't use cron.
cron might work tonight though, just not with gimp.

> > my script shuffles the list of available resources.  it can just as
> > easily not shuffle them.  it reads the available patterns from the
> > system files, so the resources which are in my ~/.gimp-2.3/ are never
> > seen.  it can just as easily read different resources from a different
> > directory.
> How about multiple directories?
well, a look at the script you can see it involves a multitude of
multiple directories.

> > see them? one day.  and that is how this page is written to work.
> > 
> > contribute examples of using a resource?  a five day week seems fair for
> > this.  two days off inbetween "projects" for lack of a better name.
> Sounds fair.  Would it be ideal to have last week's contributions
> shown on the weekends (or two any other days of the week)?  E.g. Week
> 1, Day one, results recieved on day 6, shown on week 2.
i would first need to understand that before i could even consider it.

> Well, people have reimplemented stuff before (e.g. Apache 2, and other
> 2 projects) -- sometimes you learn lots of things after doing things
> the first time around that you can re apply.  Or sometimes it's nice
> to take a different look at things.
this is not a reimplementation.  it should build on something that
worked fine.  the software that is.  gamers.org left it broken in
gnomecvs and it magically became fixed just in time for the last contest
needing a reliable server.  then it worked for the gnome splash contest.
thank you for comparing it to Apache2, though.  probably it is more like
gimp2 to gimp2.2 though.

> Have you tried perl?  It seems readily available for web usage (IIRC
> most CGI scripts are written in either Perl or C++), and handles text
> rather well, as well as a couple of other things...
no, do you think it would work better?

i have an ongoing theory about the destruction that has befallen my
life; occasionally, everything makes sense if i blame it all on daring
to ask perl questions via the irc on #gimp.

i have seen python scripts used in the cgi-bin. 

> > the web authors of the first generation of the gimps web site had a
> > tarball of something like 40,000 gradients you could get and install if
> > you wanted.  i want to avoid this.  i have personally collected brushes
> Sounds like a good idea.  A tarball is definately a bad idea, but that
> said, we still want to make things available when people want them. 
> Static serving is good for this.
tomorrows task will be to make the script only write a link to the
different r-o-d if its page has been modified since its creation.

> > here is a version of the script that has more information than the web
> > page it makes uses:
> > http://carol.gimp.org/gimp2/resources/grod.py
> > 
> > my version here is already making index pages that list all of the
> > resources it reads.  if i can match that with a template of the same
> > name, i think it is easy to work with the contest stuff at wgo to put
> > something together.
> I'll take a look at this some time.  Later, I might end up dealing
> with Python to mess around with it ( - does Python have a steep
> learning curve? ) or trying to rewrite it in Perl/CGI with a couple of
> things added in.
i do not know about that.  a lot depends on whether my script sends all
that crap to my web site or not before anything can be said about python
and its learning curve.

> > it does need to be cleaned up to read the ChangeLog less hacky.
this is not unlike how i read the ChangeLog, however:

> Perl, IIRC, is designed to handle text, so you could try using python
> to fetch a processed chunk from a perl script on a web site...
> That said, Perl, I'm very sure, is not good for everything. It's just
> what I know (in addition to POV-Ray SDL, and Game Maker Language
> (www.gamemaker.nl); and a basic comprehnsion of Java and C++; of which
> only Perl and POV-Ray I use commonly).  I might end up learning Python
> if I get the time.  I'll look at your script later.
i am too old and blameless to learn c++.  

> It's a pity the ideas we have aren't ready now -- It'd be nice to have
> your "back-to-school" competition on the last two weeks of August, as
> opposed to the first two weeks of September.  It'd be easier for me
> try and scribble something out, at the very list.
i dunno, i am watching the network seem to gurgle here with rsync.  this
is the one time i know that the net traffic on my computer was from
something i did.  :)


Gimp-user mailing list

Reply via email to