12:48 a.m.
This will have to be fixed by the EFS maintainers. You should send
all bug reports concerning packages to the appropriate maintainers.
In many cases Lisp packages are externally maintained and we just
distribute the packages.) Forwarding to the leading maintainer, just
in case.
In this case we appreciate the report here too, since obviously it's a
generic problem with Lisp programs that any "expect"-type application
will face.
>>>> "Lionel" == Lionel Fourquaux
<lionel.fourquaux(a)wanadoo.fr> writes:
Lionel> The problem seems to come from a localized message from
Lionel> ftp.exe (the one that comes with Windows 2000).
Is this message "localized" (ie, hard-coded) or "internationalized"
(using switchable catalogs, with the appropriate language -- English
-- available on your machine)?
That is, suppose you set the environment variable "LANG" to "C". Do
you then get the French message, or do you get English?
The "right" solution to this kind of problem (short of AI) is to make
the program speak the language that EFS expects. Emacs Lisp currently
doesn't provide appropriate facilities for this, but it should. In
the meantime, EFS can probably get away with temporarily setting
LANG=C in Emacs's environment, starting the FTP process, then
resetting it to whatever. (I don't know that the EFS maintainers will
choose that solution, that's just the one I suggest.)
In the long run, I think XEmacs should grab the user's locale out of
the environment, stash it somewhere for reference (eg, to set up input
methods), and then set its internal locale to "C" so that processes
will start in a known state.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
2:46 a.m.
On 22.06.01 at 08:48, Stephen J. Turnbull <turnbull(a)sk.tsukuba.ac.jp>
wrote:
The "right" solution to this kind of problem (short of AI)
is to make
the program speak the language that EFS expects.
Well, I'd argue that the "right" solution is to speak FTP directly using
either internal protocol support or some library. I've seen the "we'll just
fake user input to an interactive FTP client" fail. Repeatedly.
Spectacularly. This is one example; the kerberized ftp in Red Hat another.
OTOH, doing FTP protocol support in Lisp may be a /leeetle/ overkill as
concerns this particular problem. :-)
7:03 a.m.
Terje Bless wrote:
On 22.06.01 at 08:48, Stephen J. Turnbull <turnbull(a)sk.tsukuba.ac.jp>
wrote:
>The "right" solution to this kind of problem (short of AI) is to make
>the program speak the language that EFS expects.
Well, I'd argue that the "right" solution is to speak FTP directly using
either internal protocol support or some library. I've seen the "we'll just
fake user input to an interactive FTP client" fail. Repeatedly.
Spectacularly. This is one example; the kerberized ftp in Red Hat another.
yes. i very much agree.
OTOH, doing FTP protocol support in Lisp may be a /leeetle/ overkill as
concerns this particular problem. :-)
i don't think it's overkill. is the ftp protocol really that hard? it's
hard
to believe this. all or most other programs do implement ftp directly.
probably the code to parse the ftp.exe output is just as hairy. 99% of the
windows efs problems would magically disappear if we implemented the protocol
directly.
--
ben
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.
7:18 a.m.
On 21.06.01 at 23:03, Ben Wing <ben(a)666.com> wrote:
>OTOH, doing FTP protocol support in Lisp may be a /leeetle/
overkill as
>concerns this particular problem. :-)
i don't think it's overkill. is the ftp protocol really that hard?
Not at all. It's not a particularly pretty protocol, but it isn't really
that hard to implement. If you go to a C implementation there should be
several available libraries (the GNU FTP client springs to mind) and I'll
bet there are a plethora of C++ classes. I don't know Lisp -- what the hell
am I doing on this list? :-) -- but networking may be a bit harder there? I
wouldn't think it all that hard to do a pure Lisp implementation if the
networking primitives are there.
probably the code to parse the ftp.exe output is just as hairy.
Exactly! People tend to choose this route for "simplicity" and it ends up
with fragile, hairy, unmaintainable code several times the size of the
equivalent "native" FTP implementation.
Of course, most FTP clients contain a whole bunch of fragile, hairy,
unmaintainable special cases to deal with the various undefined output
formats and unimplemented commands -- :-) -- but at least you'll know it
when something went wrong and can compensate or give a usefull error
message.
OTOH, I don't know EFS so there may be a good reason why it's implemented
the way it is.
8:12 a.m.
>>>> "Terje" == Terje Bless <link(a)tss.no>
writes:
Terje> On 21.06.01 at 23:03, Ben Wing <ben(a)666.com> wrote:
>> OTOH, doing FTP protocol support in Lisp may be a /leeetle/
overkill as
>> concerns this particular problem. :-)
>
> i don't think it's overkill. is the ftp protocol really that hard?
It'd actually be much easier than talking to the ftp client. However,
that zaps 99% of all gateway support right away, which is why neither
ange-ftp nor EFS go that route.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
8:26 a.m.
>>>> "Terje" == Terje Bless <link(a)tss.no>
writes:
Terje> On 22.06.01 at 08:48, Stephen J. Turnbull
Terje> <turnbull(a)sk.tsukuba.ac.jp> wrote:
> The "right" solution to this kind of problem (short of
AI) is
> to make the program speak the language that EFS expects.
Terje> Well, I'd argue that the "right" solution is to speak FTP
Yes. To the FTP problem. "This kind of problem" refers specifically
to message catalog substitution in communicating with external processes.
N.B. I suspect that one reason for the EFS implementation is to take
advantage of the forked process to allow Emacs to continue working
while FTP is downloading, which is time-consuming and error-prone.
Forking off an FTP is much less expensive than forking off an inferior
XEmacs just to speak FTP. :-)
So the "right" solution is really to implement a multithreaded Emacs,
and then teach one of the threads to speak FTP. buwhahahahaha...
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
10:13 a.m.
well, given the problems on windows, it would obviously make sense there to have
a version that speaks the ftp protocol directly.
furthermore, don't most proxies use some standard way of proxying? for example,
the little Cygwin setup program that we use for our own has a few settings for
proxies, and generally that seems to work fine.
"Michael Sperber [Mr. Preprocessor]" wrote:
>>>>> "Terje" == Terje Bless <link(a)tss.no> writes:
Terje> On 21.06.01 at 23:03, Ben Wing <ben(a)666.com> wrote:
>>> OTOH, doing FTP protocol support in Lisp may be a /leeetle/ overkill as
>>> concerns this particular problem. :-)
>>
>> i don't think it's overkill. is the ftp protocol really that hard?
It'd actually be much easier than talking to the ftp client. However,
that zaps 99% of all gateway support right away, which is why neither
ange-ftp nor EFS go that route.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
--
ben
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.
10:21 a.m.
I've sent a message to the EFS mailing list, but got no answer.
Possibly I didn't do it right, so I'll reread the instructions
and send a more informative message as soon as I have the time
to do it.
-----Message d'origine-----
De : Stephen J. Turnbull [mailto:turnbull＠sk.tsukuba.ac.jp]
Envoye : vendredi 22 juin 2001 01:49
A : Lionel Fourquaux
Cc : xemacs-beta(a)xemacs.org; mike(a)xemacs.org
Objet : forwarded message from Lionel Fourquaux
This will have to be fixed by the EFS maintainers. You should send
all bug reports concerning packages to the appropriate maintainers.
In many cases Lisp packages are externally maintained and we just
distribute the packages.) Forwarding to the leading maintainer, just
in case.
In this case we appreciate the report here too, since obviously it's a
generic problem with Lisp programs that any "expect"-type application
will face.
>>>>> "Lionel" == Lionel Fourquaux
<lionel.fourquaux(a)wanadoo.fr> writes:
Lionel> The problem seems to come from a localized message from
Lionel> ftp.exe (the one that comes with Windows 2000).
Is this message "localized" (ie, hard-coded) or "internationalized"
(using switchable catalogs, with the appropriate language -- English
-- available on your machine)?
Unfortunately, it is localized. (Messages are hard-coded in the
resource section of ftp.exe.) I understand that MS is increasingly
moving toward internationalization instead of localization, but
it's not the case yet.
That is, suppose you set the environment variable "LANG" to "C". Do
you then get the French message, or do you get English?
It's still in French. :-((
The "right" solution to this kind of problem (short of AI) is to make
the program speak the language that EFS expects. Emacs Lisp currently
doesn't provide appropriate facilities for this, but it should. In
the meantime, EFS can probably get away with temporarily setting
LANG=C in Emacs's environment, starting the FTP process, then
resetting it to whatever. (I don't know that the EFS maintainers will
choose that solution, that's just the one I suggest.)
In the long run, I think XEmacs should grab the user's locale out of
the environment, stash it somewhere for reference (eg, to set up input
methods), and then set its internal locale to "C" so that processes
will start in a known state.
It won't work for localized programs. However, I don't know
what can be done for this case. Let's hope they will disappear soon!
Best regards,
Lionel
10:29 a.m.
-----Message d'origine-----
De : Ben Wing [mailto:ben＠666.com]
Envoye : vendredi 22 juin 2001 08:04
A : Terje Bless
Cc : Stephen J. Turnbull; Lionel Fourquaux; xemacs-beta(a)xemacs.org;
mike(a)xemacs.org
Objet : Re: forwarded message from Lionel Fourquaux
Terje Bless wrote:
>
> On 22.06.01 at 08:48, Stephen J. Turnbull
<turnbull(a)sk.tsukuba.ac.jp>
> wrote:
>
> >The "right" solution to this kind of problem (short of AI)
is to make
> >the program speak the language that EFS expects.
>
> Well, I'd argue that the "right" solution is to speak FTP
directly using
> either internal protocol support or some library. I've seen
the "we'll just
> fake user input to an interactive FTP client" fail. Repeatedly.
> Spectacularly. This is one example; the kerberized ftp in
Red Hat another.
yes. i very much agree.
>
> OTOH, doing FTP protocol support in Lisp may be a /leeetle/
overkill as
> concerns this particular problem. :-)
i don't think it's overkill. is the ftp protocol really that
hard? it's hard
to believe this. all or most other programs do implement ftp
directly.
For Windows, I'd suggest to use wininet.dll: there is an
already implemented FTP there.
probably the code to parse the ftp.exe output is just as
hairy. 99% of the
windows efs problems would magically disappear if we
implemented the protocol
directly.
--
ben
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.
10:40 a.m.
>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> furthermore, don't most proxies use some standard way of
Ben> proxying?
Sure: "some" being one out of a dozen. You wouldn't believe the
variety exotic ftp environments I've received reports from.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
11 a.m.
Terje Bless <link(a)tss.no> writes:
OTOH, doing FTP protocol support in Lisp may be a /leeetle/ overkill
as
concerns this particular problem. :-)
Not really, but we need elisp bindings for listening on TCP sockets in
XEmacs to implement FTP properly.
Supporting Kerberos/GSSAPI extensions is trickier though. (TLS should
be simple, once I get around to submitting my TLS elisp bindings for
XEmacs.)
2:18 p.m.
Simon Josefsson <jas(a)extundo.com> writes:
Terje Bless <link(a)tss.no> writes:
> OTOH, doing FTP protocol support in Lisp may be a /leeetle/ overkill as
> concerns this particular problem. :-)
Not really, but we need elisp bindings for listening on TCP sockets in
XEmacs to implement FTP properly.
Not really - you could just force the use of passive mode, but that may be
a little too restrictive, even today.
-bp
--
Ceterum censeo vi esse delendam
9:33 a.m.
New subject: need volunteers to write a Lisp primitive interface for the ftp functionality in wininet.dll
Lionel Fourquaux wrote:
> -----Message d'origine-----
> De : Ben Wing [mailto:ben＠666.com]
> Envoye : vendredi 22 juin 2001 08:04
> A : Terje Bless
> Cc : Stephen J. Turnbull; Lionel Fourquaux; xemacs-beta(a)xemacs.org;
> mike(a)xemacs.org
> Objet : Re: forwarded message from Lionel Fourquaux
>
>
>
>
> Terje Bless wrote:
> >
> > On 22.06.01 at 08:48, Stephen J. Turnbull
> <turnbull(a)sk.tsukuba.ac.jp>
> > wrote:
> >
> > >The "right" solution to this kind of problem (short of AI)
> is to make
> > >the program speak the language that EFS expects.
> >
> > Well, I'd argue that the "right" solution is to speak FTP
> directly using
> > either internal protocol support or some library. I've seen
> the "we'll just
> > fake user input to an interactive FTP client" fail. Repeatedly.
> > Spectacularly. This is one example; the kerberized ftp in
> Red Hat another.
>
> yes. i very much agree.
> >
> > OTOH, doing FTP protocol support in Lisp may be a /leeetle/
> overkill as
> > concerns this particular problem. :-)
>
> i don't think it's overkill. is the ftp protocol really that
> hard? it's hard
> to believe this. all or most other programs do implement ftp
> directly.
For Windows, I'd suggest to use wininet.dll: there is an
already implemented FTP there.
is this a standard dll? [presumably]
if so, it would be great if someone wrote an interface to this, so that efs
could use it on windows instead of having to connect to a program. i presume
this is what the windows programs that do ftp that i've seen are using.
any takers?
>
> probably the code to parse the ftp.exe output is just as
> hairy. 99% of the
> windows efs problems would magically disappear if we
> implemented the protocol
> directly.
>
> --
> ben
>
> I'm sometimes slow in getting around to reading my mail, so if you
> want to reach me faster, call 520-661-6661.
>
> See http://www.666.com/ben/chronic-pain/ for the hell I've been
> through.
--
ben
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.
3:21 p.m.
New subject: need volunteers to write a Lisp primitive interface for the ftp functionality in wininet.dll
Ben Wing wrote:
> For Windows, I'd suggest to use wininet.dll: there is an
> already implemented FTP there.
is this a standard dll? [presumably]
Yes, the DLL is standard all the way back to Win95, according to MS
Knowledge Base articles. If anyone's interested in trying, search for
"wininet.dll ftp api" at msdn.microsoft.com and there are some articles on
the API..
Jay
3:31 p.m.
New subject: need volunteers to write a Lisp primitive interface for the ftp functionality in wininet.dll
Ben Wing <ben(a)666.com> writes:
> For Windows, I'd suggest to use wininet.dll: there is an
> already implemented FTP there.
is this a standard dll? [presumably]
Yup.
if so, it would be great if someone wrote an interface to this, so
that
efs could use it on windows instead of having to connect to a program. i
presume this is what the windows programs that do ftp that i've seen are
using.
any takers?
I could try and spend a few days un-GTK-ifying the foreign-function
interface (I've been meaning to do this for a while). Then, depending on
what the interface looks like (can someone send a header file?), you could
import the functions like this:
(import-function HANDLE InetOpen ((string . agent)
(dword . access-type)
(string . proxy)
(string . proxy-bypass)
(dword . flags)))
(import-function HANDLE InetOpenUrl ((HANDLE . inethandle)
(string . url)
(string . headers)
(dword . headers-length)
(dword . flags)
(dword . context))
(setq inet-handle (InetOpen (format "XEmacs/%d.%d" emacs-major-version
emacs-minor-version)
INET_OPEN_TYPE_DIRECT
nil nil nil))
(setq inet-handle (InetOpenUrl inet-handle
"ftp://ftp.xemacs.org/pub/xemacs/README"
nil nil nil nil))
etc, etc.
Personally I'd prefer seeing something written in lisp that could be used
even on unix, but maybe that's just me. :)
-bp
--
Ceterum censeo vi esse delendam
8:06 p.m.
New subject: need volunteers to write a Lisp primitive interface for the ftp functionality in wininet.dll
"William M. Perry" wrote:
Ben Wing <ben(a)666.com> writes:
>> For Windows, I'd suggest to use wininet.dll: there is an
>> already implemented FTP there.
>
> is this a standard dll? [presumably]
Yup.
> if so, it would be great if someone wrote an interface to this, so that
> efs could use it on windows instead of having to connect to a program. i
> presume this is what the windows programs that do ftp that i've seen are
> using.
>
> any takers?
I could try and spend a few days un-GTK-ifying the foreign-function
interface (I've been meaning to do this for a while). Then, depending on
what the interface looks like (can someone send a header file?), you could
import the functions like this:
that would be awesome if you could do this.
header sent in a separate message.
(import-function HANDLE InetOpen ((string . agent)
(dword . access-type)
(string . proxy)
(string . proxy-bypass)
(dword . flags)))
(import-function HANDLE InetOpenUrl ((HANDLE . inethandle)
(string . url)
(string . headers)
(dword . headers-length)
(dword . flags)
(dword . context))
(setq inet-handle (InetOpen (format "XEmacs/%d.%d" emacs-major-version
emacs-minor-version)
INET_OPEN_TYPE_DIRECT
nil nil nil))
(setq inet-handle (InetOpenUrl inet-handle
"ftp://ftp.xemacs.org/pub/xemacs/README"
nil nil nil nil))
etc, etc.
Personally I'd prefer seeing something written in lisp that could be used
even on unix, but maybe that's just me. :)
-bp
--
Ceterum censeo vi esse delendam
--
ben
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.
8:08 p.m.
New subject: need volunteers to write a Lisp primitive interface for the ftp functionality in wininet.dll
* William M Perry <wmperry(a)gnu.org> writes:
Ben Wing <ben(a)666.com> writes:
> is this a standard dll? [presumably]
Yup.
From experience, no ! It is as long as you install some recent version
of Internet Explorer (5 preferably).
Fabrice
12:11 a.m.
New subject: need volunteers to write a Lisp primitive interface for the ftp functionality in wininet.dll
* William M Perry <wmperry(a)gnu.org> writes:
Ben Wing <ben(a)666.com> writes:
>> For Windows, I'd suggest to use wininet.dll: there is an already
>> implemented FTP there.
> is this a standard dll? [presumably]
Yup.
From experience, no. I used to put an installer on the TeXLive cdrom
using this dll, and got a bunch of messages stating that they even
couldn't run the program (I did not delay load the dll).
I could try and spend a few days un-GTK-ifying the foreign-function
interface (I've been meaning to do this for a while). Then,
depending on what the interface looks like (can someone send a
header file?), you could import the functions like this:
(import-function HANDLE InetOpen ((string . agent) (dword
. access-type) (string . proxy) (string . proxy-bypass) (dword
. flags)))
I have a couple of students which did this recently (however, the
result is not that clean). They can open a dll, call any function in
there, as long as you don't need structures (for the moment).
But there is something weird : many interesting functions need to be
given some callback function (for example : monitroing the progress of
your ftp transfer). What whould be great : be able to register
emacs-lisp functions as callbacks. Probably less easy however.
Fabrice Popineau
1:34 a.m.
New subject: need volunteers to write a Lisp primitive interface for the ftp functionality in wininet.dll
Fabrice Popineau <Fabrice.Popineau(a)supelec.fr> writes:
I have a couple of students which did this recently (however, the
result
is not that clean). They can open a dll, call any function in there, as
long as you don't need structures (for the moment).
But there is something weird : many interesting functions need to be
given some callback function (for example : monitroing the progress of
your ftp transfer). What whould be great : be able to register emacs-lisp
functions as callbacks. Probably less easy however.
Providing callbacks is relatively easy - the lisp bindings for GTK need
this. That is part of the GTK specific portion, though it should be easy
to generalize that to a generic 'callback' type that specifies the
signature of the callback as well as the imported function.
-bp
--
Ceterum censeo vi esse delendam
1:13 p.m.
New subject: need volunteers to write a Lisp primitive interface for the ftp functionality in wininet.dll
> Ben Wing <ben(a)666.com> writes:
>> is this a standard dll? [presumably]
From experience, no ! It is as long as you install some recent version
of Internet Explorer (5 preferably).
Wow. How long ago was that, on which Windows version? I see an MSDN
article from 1996 describing it, so presumably, if it didn't come with
Windows 95 itself, it came with an IE shipped around that time period. Does
Xemacs try to support Win95? If so, is requiring a current IE there an
acceptable solution? I'm presuming that Win98, ME, NT 4, Win2K all shipped
with a version of IE that had it.
4:40 p.m.
New subject: need volunteers to write a Lisp primitive interface for the ftp functionality in wininet.dll
At 08:13 AM 6/25/01 -0400, Jay Levitt wrote:
Wow. How long ago was that, on which Windows version? I see an MSDN
article from 1996 describing it, so presumably, if it didn't come with
Windows 95 itself, it came with an IE shipped around that time period. Does
Xemacs try to support Win95? If so, is requiring a current IE there an
acceptable solution? I'm presuming that Win98, ME, NT 4, Win2K all shipped
with a version of IE that had it
The toolbar requires stuff from commctrl that is not present in vanilla 95,
so there is precendent for this.
andy
10:40 a.m.
New subject: need volunteers to write a Lisp primitive interface for the ftp functionality in wininet.dll
* Jay Levitt <jay(a)jay.fm> writes:
Wow. How long ago was that, on which Windows version? I see an
MSDN article from 1996 describing it, so presumably, if it didn't
come with Windows 95 itself, it came with an IE shipped around that
time period. Does Xemacs try to support Win95?
Yes.
If so, is requiring a current IE there an acceptable solution?
Well, in my cas I was told : no. Some people want windows without IE
(silly, I know !).
On the other hand, the only reliable version of wininet is the one
that comes with IE5. AFAIK, the previous ones have various kind of
problems.
Fabrice
8333
days inactive
8338
days old
21 comments
10 participants
participants (10)
-
Andy Piper -
Ben Wing -
Fabrice Popineau -
Jay Levitt -
Lionel Fourquaux -
Michael Sperber -
Simon Josefsson -
Stephen J. Turnbull -
Terje Bless -
William M. Perry