Re: French translation updated & Yet Another Scripting Idea.

On Tue, Nov 08, 2005 at 05:27:06AM +0100, Nicolas Noble wrote:
> Okay, long time I didn't update this translation. It deadly needed one.

Translation committed to CVS. Thanks!

> Oh, and, some things I spotted doing this:
> 
> The help message
>   {"source",  cmd_source, N_("source <file>"),
>         N_("Execute commands recorded in file <file>\n")},
> at line 456 of commands.cc doesn't match:
>         eprintf(_("Usage: %s [-e] <file|command>\n"),args->a0());
> at line 1824 of commands.cc

I'll change that.

> And at FileSetOutput.cc at line 141, you're asking the translators to 
> translate the LC_TIME strings:
> 
> "%b %e  %Y"
> "%b %e %H:%M"
> 
> but I am not exactly sure if this is the right thing to do (to leave 
> that up to the translator that is); since they sound quite commonly used 
> strings, I wonder if they're not available thru some obscure gettext's 
> calls, in order to match current users's locale settings. In all cases, 
> I left them as it, since they match french way of displaying timestamps.

The time format is `ls' specific. I don't think it is available in locale
information.

> About scripting, which is an old-and-already-way-long discussed topic... 
> I just came up with a new idea, yet I know one of your favorite answer 
> about this topic is "it's okay with me if you do it", I'd still want to 
> know if you think it's right or not. Some time ago, I discovered the LUA 
> language (http://www.lua.org), and I am now actively using it into my 
> own code and already produced some software with it. And just now, I had 
> the idea that writing some LUA bindings into Lftp would be a nice thing 
> to have.

You can start with making a module which implements "lua" command.
See CmdExec::RegisterCommand function.

> I somewhat think it'd be "quite easy" to convert commands.cc into LUA 
> bindings, returning values to the LUA stack instead of printing them 
> onscreen, or something similar, even though I know there will most 
> probably be some pitfalls doing this task. Anyway, we'd only need a

That can be done later, if needed.

> The only thing I am a bit affraid of would be to make LUA's coroutine to 
> work nicely within lftp's built-in thread system. I'd need to go back 

That can be a problem indeed. Are LUA routines blocking?

> digging Lftp in order to understand again how your funky task switch is 
> handled. I did that years ago to get inspiration when I was trying to 
> design my own task system, but I am affraid that my model is now way 
> different than yours :) While LUA is "thread safe" (meaning it's 

Mine is built on the principle of non-blocking calls. It is something
similar to java (run method), but the method (Do) is non-blocking.
It was inspired by Java and Erlang.

> So if you think having LUA scripting abilities inside Lftp is a good 
> idea, I could try to handle most parts of it if you me help a bit about 
> the task system by pointing me exactly at where task switch occurs and 
> how it's handled :)

An "runnable" class is a derivative of SMTask. It has to implement Do method
which is non-blocking, i.e. does not wait for external events itself. Instead,
it sets wake-up condition (poll on a file descriptor, a timeout) and returns.
It can return MOVED if it's internal state has changed so that other objects
can check for it. STALL means that internal state has not changed significantly.

-- 
   Alexander.                      | never mind that noise you heard