Subj : posix strftime To : tony summerfelt From : Maurice Kinal Date : Thu Mar 10 2005 09:41 am Hey tony! Mar 10 11:26 05, tony summerfelt wrote to Maurice Kinal: ts> actually i meant %T because you had the seconds, but yeah, anything ts> strftime compatible should be portable (all those work for both ruby ts> and tcl also) I still haven't checked out the %R thing so now I will check out %T instead. Thanks for the heads up. I currently don't have either tcl or ruby installed but thought I'd check out ruby later. Just working out a base install for multiprocessing and am just finishing off the shared libs. Development stuff, including scriptors, I'll worry about later. The perl package is going to be tricky enough given the modules I want to add so other scriptors will havee to wait a spell. You have my attention on ruby though and it'll probably get past the production stage. I plan to use a framebuffer gtk lib so I probably won't use tcl/tk. i want to see if the perl gtk modules will cooperate with a purely framebuffer gtk. I have my doubts but we'll see when I get that far. If not it isn't a big deal and will probably just program any graphical apps using gcc and include the new and improved gtk (knock on wood). ts> it's a perl problem...although activestate makes it fairly easy to ts> install modules, they aren't always uptodate OR complete compared to ts> cpan. Understood. We'll have to keep our eyes open on that aspect. Mind you the same holds true with gtk and Win32 so it isn't like this is purely a perl thing. ts> cpan is a better choice for linux users, while activestate's ppm is a ts> much better choice for windows users. We'll keep that in mind. ts> when ever i need to do any heavy duty manipulation with time, i ts> usually turn to tcl or ruby. those two languages have the ts> functionality built in and you don't need to install 3 or 4 modules ts> to do everything you want... Sounds promising for ruby then. What have they got wrt Linux daemons? Perhaps I'll put aside perl for now and check that out before jumping through perl server-type modules. I haven't committed the latest build to any scriptor, other then bash, as this point in time so maybe some research is in order very shortly. ts> yes, but other modules aren't. i've referring to the over 350 date ts> and time modules available on activestates ppm respository or cpan Right. I was just using the POSIX one. Wasn't planning to go beyond that wrt time and date. ts> they are usually full modules for something that can be done in a few ts> lines of code in tcl or ruby. Even more interesting. ts> realizing of course, it's mostly abandonware keeping fido still ts> running. anything 'new' still has to get by whatever fidoghods still ts> left controlling things... Right. I am counting on that. My whole Fido development relies on them being stick-in-the-muds since that way I have outbounds covered and can totally cconcentrate on how things will work locally. Something to be said for that mode of operation since it should have no real influence locally other then to reformat for uplinks. ts> you can write procedural code in ruby. there's no reason to design ts> any classes. etc. ts> in perl you open a file and read through it like: ts> open (fh, "") ts> while() { ts> # do something with $_ ts> } ts> in ruby it's: ts> fh=File.open("" ts> fh.each {|line| ts> # do something with 'line' ts> } ts> once you get used to 'everything is an object' in ruby things go ts> pretty quick. Yeah. That's simular to python. ts> the only reasons i'm working with ruby lately (ok, other than not ts> having to do things in python). Heh, heh. I hear ya! I have never been much of a python fan. ts> is the time manipulation, and the ts> threading. nothing extra to install...whichm means the code will run ts> all the way down to dos systems... That I have to see to believe. I am going to have to find a local DOS-person. Over a decade ago that would have been me. :::shudder::: Life is good, Maurice --- Msged/LNX 6.1.2 * Origin: Coffin Point - Ladysmith, BC Canada (1:153/401.1) .