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 online.
> > 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: http://carol.gimp.org/writing/listsoflists/cgo-Y3K.html > 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. :) carol _______________________________________________ Gimp-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
