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
> > 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