Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

read ftp:// error

 [1/38] from: moeller_thorsten:gmx at: 29-May-2001 13:16


Hi all, i am playing around with ftp and /view 1.2 on a win98-box. I tried to read a file on a HPUX-Server and always get the following error: Script Error: Invalid argument: 29/Mai/2001/4:04 Where: to-date Near: to date! :value Any ideas out there? Thorsten

 [2/38] from: gjones05:mail:orion at: 29-May-2001 6:57


From: "Thorsten Moeller"
> i am playing around with ftp and /view 1.2 on a win98-box. I tried to
read a
> file on a HPUX-Server and always get the following error: > > Script Error: Invalid argument: 29/Mai/2001/4:04 > Where: to-date > Near: to date! :value > > Any ideas out there?
My version of REBOL does not recognize the month abbreviation "Mai". Is this a typo? 29/Mar/2001/4:04 is correctly made into a date. --Scott Jones

 [3/38] from: chris:starforge:demon at: 29-May-2001 13:08


GS Jones wrote:
> From: "Thorsten Moeller" > My version of REBOL does not recognize the month abbreviation "Mai". Is > this a typo? > "29/Mar/2001/4:04" is correctly made into a date.
Looks like a translation problem - Mai is probably May in German? Chris

 [4/38] from: moeller_thorsten:gmx at: 29-May-2001 14:36


Hi Scott, this is no typo, maybe it is depending to the "German"-Version of HPUX 11. I looked into the filesystem and there the month is Mai (german) for May (eng.). Perhaps RT should consider local Versions of OS's. Perhaps there could be a workaround. Thorsten

 [5/38] from: cybarite:sympatico:ca at: 29-May-2001 7:57


Can you reveal your codes lines where you are getting the problem? At 01:16 PM 5/29/01 +0200, you wrote:

 [6/38] from: chris:starforge:demon at: 29-May-2001 14:03


Thorsten Moeller wrote:
> Perhaps there could be a workaround.
Persuade all of Germany to use May instead of Mai? :) Seriously though, you could preprocess the string converting DD/Mai/YYYY into DD/May/YYYY I suppose. Chris

 [7/38] from: moeller_thorsten:gmx at: 29-May-2001 15:09


Hi Mike, here is an the Code incl. error-message:
>> print read ftp://user:[pass--192--168--200--10]/home/whc/tsbewout
** Script Error: Invalid argument: 29/Mai/2001/4:04 ** Where: to-date ** Near: to date! :value Perhaps i should send this to RT feedback. Thorsten

 [8/38] from: belymt:saunalahti:fi at: 29-May-2001 16:41


At 14:03 29.5.2001 +0100, you wrote:
>Thorsten Moeller wrote: >>Perhaps there could be a workaround. >Persuade all of Germany to use May instead of Mai? :)
Not using localizated dates on places it cause troubles. Like in international communication (FTP, http, E-mail)
>Seriously though, you could preprocess the string converting >DD/Mai/YYYY into DD/May/YYYY I suppose.
Yes.. But it's not just that.. it's goes much further For example .. Its "Maj" in swedish and "Tou" in finish.. (Short of Toukokuu ) So in the end.. you need to check over 100 languages for all possible words you might encounter, in this case all 12 months names.. Not a good solution. :-( I remember this issue came up when Commodore decided to localize AmigaOS.. Suddenly some time-releated scripts stopped worlking.. (Whops) Joanna

 [9/38] from: moeller_thorsten:gmx at: 29-May-2001 16:40


Hi Joanna, i completely agree with you regarding the implementation of all variations of month names around the world. But, we received our sever preconfiguered from HP. And Users of Applications don't care about what version of OS is running on a server they want to access with an FTP-Client. Why must there be any to-date conversion when i want to read a file via FTP? Thorsten -----Ursprungliche Nachricht----- Von: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]Im Auftrag von Joanna Kurki Gesendet: Dienstag, 29. Mai 2001 15:42 An: [rebol-list--rebol--com] Betreff: [REBOL] Re: read ftp:// error At 14:03 29.5.2001 +0100, you wrote:
>Thorsten Moeller wrote: >>Perhaps there could be a workaround. >Persuade all of Germany to use May instead of Mai? :)
Not using localizated dates on places it cause troubles. Like in international communication (FTP, http, E-mail)
>Seriously though, you could preprocess the string converting >DD/Mai/YYYY into DD/May/YYYY I suppose.
Yes.. But it's not just that.. it's goes much further For example .. Its "Maj" in swedish and "Tou" in finish.. (Short of Toukokuu ) So in the end.. you need to check over 100 languages for all possible words you might encounter, in this case all 12 months names.. Not a good solution. :-( I remember this issue came up when Commodore decided to localize AmigaOS.. Suddenly some time-releated scripts stopped worlking.. (Whops) Joanna

 [10/38] from: cyphre:volny:cz at: 29-May-2001 17:07


Hello Thorsten, Have you tried: probe info? ftp://user:[pass--your-server]/some-path/any-file If not try it...I am curious for the result Regards Cyphre

 [11/38] from: gjones05:mail:orion at: 29-May-2001 10:28


From: "Thorsten Moeller" ...
> here is an the Code incl. error-message: > > >> print read ftp://user:[pass--192--168--200--10]/home/whc/tsbewout > ** Script Error: Invalid argument: 29/Mai/2001/4:04 > ** Where: to-date > ** Near: to date! :value > > Perhaps i should send this to RT feedback.
Hello, again, Thorsten, The reason that I originally asked about a typo was because of the context of the question. (I assumed that "Mai" was a German word:-) However, from the initial post I was unable to tell whether the word was being read because of specific code segment that you had written, versus something internal to another function. Your example above clarifies the context. I assume that the tsbewout refers to a file (otherwise REBOL ftp would require a terminating slash). The question in my mind was also why would this error be thrown in this circumstances? Normally a 'read under these circumstances would return a string. While 'print contains an implied 'reduce, REBOL would not need to reduce anything from a read request of a file, so, as you originally figured, this statement should print the file following the read without complaint. When I browsed the ftp scheme, I can see where the scheme makes string to date coversions, but I have been unable to figure out how this gets called with the simple command string you've listed above. Perhaps this is a REBOL bug. Wouldn't hurt to submit it to REBOL feedback as a possible one. Quite a mystery, at least for me. --Scott Jones

 [12/38] from: belymt:saunalahti:fi at: 29-May-2001 23:02


At 16:40 29.5.2001 +0200, you wrote:
>Hi Joanna, > >i completely agree with you regarding the implementation of all variations >of month names around the world. But, we received our sever preconfiguered >from HP. And Users of Applications don't care about what version of OS is >running on a server they want to access with an FTP-Client.
I know. Users just want everything to happen smoothly... (even when it's not possible) Unfortunately that kind of server dependancy it's next to impossible to hide 100% because there is no sureproof way to know where all possible FTP servers are located and to what language they happen to use. If your clients are having limited set of known servers you can patch Rebol (At least I belive it ought to be possible) to handle this ..
>Why must there be any to-date conversion when i want to read a file via FTP?
I can't tell for Rebol but most logical explanation might be that it's tries to collect all info of files for displaying it on neat form. Unfortunately FTP-servers directory list output is not standatized strictly enough for it to be easily parseable. In this case looks like FTP-client tries to extract file modification date info and fails because server does not respond as expected. For more accurate quess you need to get ansver from those who really know internals of Rebol. Joanna

 [13/38] from: agem:crosswinds at: 29-May-2001 23:39


>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 29.05.01, 14:09:33, schrieb "Thorsten Moeller" <[moeller_thorsten--GMX--De]> zum Thema [REBOL] Re: read ftp:// error:
> Hi Mike, > here is an the Code incl. error-message:
<<quoted lines omitted: 3>>
> ** Near: to date! :value > Perhaps i should send this to RT feedback.
i think so. all needed is like if error? Try[ the-date: to date! :value] ][the-date: some-dummi-date] as long as the date is not really needed. But thats then somewhere in ftp-protokoll, where rebol should fix it themself. Except they think dummi-dates will cause problems of course.
> Thorsten
-Volker

 [14/38] from: moeller_thorsten:gmx at: 30-May-2001 9:58


Hi, thanks for all your postings. I submitted the problem to feedback. If i will get a result i will inform you via this list. Meanwhile i think i have to change something on the server to get this running, maybe the easier and faster way. I hoped that perhaps Holger would give his $0.2, as he his the RT-Expert for this. Thorsten

 [15/38] from: gjones05:mail:orion at: 30-May-2001 6:53


From: "Thorsten Moeller"
> thanks for all your postings. I submitted the > problem to feedback. If i will get a result i
<<quoted lines omitted: 4>>
> I hoped that perhaps Holger would give his > $0.2, as he his the RT-Expert for this.
If you can supply a list of HP's month abbreviations and a safe ftp account that demonstrates the problem, I may be able to hack the FTP scheme for you. (I did it for SMTP to allow for authentication for Microsoft exchange server.) I have a feeling that the hack won't be too difficult on this problem. --Scott Jones

 [16/38] from: moeller_thorsten:gmx at: 30-May-2001 15:24


Hi Scott, thanks for your offer. HP`s moth abbreviations wouldn't be the problem, but the server is just internal and running our ERP-System. So, it is not possible to give you even a secure access to it for demonstration. Perhaps you can give me some instructions what to do, or what you have in mind, so i can put it together. Any results can be emailed off-list. Think about it !? Thanks again, Thorsten -----Ursprüngliche Nachricht----- Von: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]Im Auftrag von GS Jones Gesendet: Mittwoch, 30. Mai 2001 13:53 An: [rebol-list--rebol--com] Betreff: [REBOL] Re: read ftp:// error From: "Thorsten Moeller"
> thanks for all your postings. I submitted the > problem to feedback. If i will get a result i
<<quoted lines omitted: 4>>
> I hoped that perhaps Holger would give his > $0.2, as he his the RT-Expert for this.
If you can supply a list of HP's month abbreviations and a safe ftp account that demonstrates the problem, I may be able to hack the FTP scheme for you. (I did it for SMTP to allow for authentication for Microsoft exchange server.) I have a feeling that the hack won't be too difficult on this problem. --Scott Jones

 [17/38] from: gjones05:mail:orion at: 30-May-2001 9:57


From: "Thorsten Moeller"
> Hi Scott, > > thanks for your offer. HP`s moth abbreviations wouldn't be the
problem, but
> the server is just internal and running our ERP-System. So, it is not > possible to give you even a secure access to it for demonstration. > > Perhaps you can give me some instructions what to do, or what you have
in
> mind, so i can put it together. > Any results can be emailed off-list. > > Think about it !?
Yeah, best not to tinker too much with the multi-million dollar/franc/pound/mark/xxxx ERP system! :-) This is my generic approach to hacking a scheme: First, here is how to get your very own copy of the FTP scheme with which to play. To get a separate copy of the FTP scheme, type the following (changing the path to an appropriate one): echo %/path/to/my/ftp-hack.r probe system/schemes/ftp echo none Then, edit the file to remove the chevrons (">>") at the beginning and end. Add "FTP:" as the very first line of the code so that it starts off like: FTP: make object! [ scheme: 'FTP host: none port-id: 21 user: none ... Save this file. This is your working copy of the to-be hacked FTP scheme. After hacking, save the file, then with a fresh REBOL session, type: do %/path/to/my/ftp-hack.r which loads up the hacked ftp scheme. Then see the effects. Without change, the routine should fail in the same way. The first thing I would probably do at this point is verify where the error is occurring. (I still don't see how a simple FTP read gets to this code.) Search the FTP scheme for the word "to-date". There is only one occurence and is inside the parse-files function's subfunction add-date. You will notice a lot of action with a series 'pdate. I would add some print request to figure out both the structure of pdate and the values. For example: ... add-date: func [] [ month: first pdate system/words/remove pdate system/words/insert skip pdate 1 month if (length? pdate) < 3 [ system/words/append pdate now/year system/words/append pdate to-time time ] loop length? loc: pdate [insert loc "/" loc: skip loc 2] system/words/remove pdate ;added commands on the left for easy spotting foreach pdate-part pdate [print pdate-part] if (now + 1) < loc: to-date rejoin pdate [loc/year: loc/year - 1] system/words/append info-block loc ] ... This example would accomplish two things: first find out about the pdate series and to verify the potential point of failure in that this foreach loop should execute shortly before failure. If this is the point of failure and if pdate is indeed showing the German(?) abbreviations for the months, then I would write a work-around to-date function that is local to this scheme, only. Of course, this exercise could lead in a number of directions, so there is no way to anticipate the directions. If you would like to share your results on or off list, that is fine with me. At some point if you/we get a work-around, we out to "publish" the result to the list so that the next poor soul will have an easier time. What do you think? --Scott Jones

 [18/38] from: moeller_thorsten:gmx at: 31-May-2001 10:37


Hi Scott, thanks for your detailed explanation what to do. I produced the file, studied its working, and did some modification, mainly for data tracking. But for some purposes, when i "do" the generated file as described, it doesn't seem to have any effect. Is there a way to verify that REBOL uses my scheme, not the standard one? As well REBOL ask me for a header when doing the .../ftp_hack.r, so my file has to look like this REBOL [] FTP: make object! [ scheme: 'FTP host: none port-id: 21 user: none ..... Bringing this task to a success, i will post a workaround to the list. Thorsten -----Ursprüngliche Nachricht----- Von: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]Im Auftrag von GS Jones Gesendet: Mittwoch, 30. Mai 2001 16:57 An: [rebol-list--rebol--com] Betreff: [REBOL] Re: read ftp:// error From: "Thorsten Moeller"
> Hi Scott, > > thanks for your offer. HP`s moth abbreviations wouldn't be the
problem, but
> the server is just internal and running our ERP-System. So, it is not > possible to give you even a secure access to it for demonstration. > > Perhaps you can give me some instructions what to do, or what you have
in
> mind, so i can put it together. > Any results can be emailed off-list. > > Think about it !?
Yeah, best not to tinker too much with the multi-million dollar/franc/pound/mark/xxxx ERP system! :-) This is my generic approach to hacking a scheme: First, here is how to get your very own copy of the FTP scheme with which to play. To get a separate copy of the FTP scheme, type the following (changing the path to an appropriate one): echo %/path/to/my/ftp-hack.r probe system/schemes/ftp echo none Then, edit the file to remove the chevrons (">>") at the beginning and end. Add "FTP:" as the very first line of the code so that it starts off like: FTP: make object! [ scheme: 'FTP host: none port-id: 21 user: none ... Save this file. This is your working copy of the to-be hacked FTP scheme. After hacking, save the file, then with a fresh REBOL session, type: do %/path/to/my/ftp-hack.r which loads up the hacked ftp scheme. Then see the effects. Without change, the routine should fail in the same way. The first thing I would probably do at this point is verify where the error is occurring. (I still don't see how a simple FTP read gets to this code.) Search the FTP scheme for the word "to-date". There is only one occurence and is inside the parse-files function's subfunction add-date. You will notice a lot of action with a series 'pdate. I would add some print request to figure out both the structure of pdate and the values. For example: ... add-date: func [] [ month: first pdate system/words/remove pdate system/words/insert skip pdate 1 month if (length? pdate) < 3 [ system/words/append pdate now/year system/words/append pdate to-time time ] loop length? loc: pdate [insert loc "/" loc: skip loc 2] system/words/remove pdate ;added commands on the left for easy spotting foreach pdate-part pdate [print pdate-part] if (now + 1) < loc: to-date rejoin pdate [loc/year: loc/year - 1] system/words/append info-block loc ] ... This example would accomplish two things: first find out about the pdate series and to verify the potential point of failure in that this foreach loop should execute shortly before failure. If this is the point of failure and if pdate is indeed showing the German(?) abbreviations for the months, then I would write a work-around to-date function that is local to this scheme, only. Of course, this exercise could lead in a number of directions, so there is no way to anticipate the directions. If you would like to share your results on or off list, that is fine with me. At some point if you/we get a work-around, we out to "publish" the result to the list so that the next poor soul will have an easier time. What do you think? --Scott Jones

 [19/38] from: gjones05:mail:orion at: 31-May-2001 7:18


Hi, Thorsten, My suggestions yesterday clearly suffered from sloppiness. Sorry! I've corrected the oversites AND tested what I could of the result. It should work now. Comments interspersed below: From: "Thorsten Moeller"
> Hi Scott, > > thanks for your detailed explanation what to do. > I produced the file, studied its working, and did > some modification, mainly for data tracking. > But for some purposes, when i "do" the generated > file as described, it doesn't seem to have any effect.
I forgot to have you assign the new scheme to the original system ftp scheme word path! Use this line to load your hacked version: system/schemes/ftp: do %/path/to/my/ftp-hack.r
> Is there a way to verify that REBOL uses my > scheme, not the standard one?
The simplest way to be sure it has been loaded in the proper space is to re-probe at the console: probe system/schemes/ftp and scroll up to verify that the hacked lines appear. Additionally, placing a {print "I'm here"} statement at the earliest possibly entry points can give some reassurance while running trials on the hack.
> As well REBOL ask me for a header when doing > the .../ftp_hack.r, so my file has to look like this
<<quoted lines omitted: 6>>
> user: none > .....
Silly me. Of course you have done the correct thing. Sorry to waste your time.
> Bringing this task to a success, i will post a > workaround to the list. > > Thorsten
Great! By the way, I added the foreach print loop to my sample hack, and did simple ftp directory and file reads, and to my amazement, this function is called each time (I wish I could figure out where this is getting called. Grrr!). So I feel confident that this is where the error is occurring. Check it out with your system, and you should see the German versions of the month(s). These then cause the error on the 'to-date line. I have not checked out the following (and really have no convenient way to test it), but these are my thoughts on the work-around, assuming that the above results yield the German names for the months. At the top of the add-date function, you see: add-date: func [] [ month: first pdate system/words/remove pdate system/words/insert skip pdate 1 month ... Try adding the following: add-date: func [] [ month: first pdate if find ["Mär" "Mai" "Okt" "Dez"] month [month: select ["Mär" "Mar" Mai "May" "Okt" "Oct" "Dez" "Dec"] month] system/words/remove pdate system/words/insert skip pdate 1 month ... Of course, I don't know the actual way that the German month names are abbreviated (I used alta-vista's babel-fish), so these series may need to be altered to suit. Hopefully, this is self-evident (which guarantees that it won't be! ;-). Then once this new hack is reloaded, then the program will hopefully work on English and German versions of file systems. Now we only have the other 100+ languages!!! ;-) I suspect that this functionality could be made more generic, but first see if any of the above is helpful. Best wishes, --Scott Jones

 [20/38] from: moeller_thorsten:gmx at: 31-May-2001 17:28


Hi Scott, Tried it out with "Mai" to "May" and works fine for the file i was trying to read. I have to find files for the other months to be tested. Keep you informed via the list. For a more generic use, perhaps there could be a kind of library-file containig the translations even for other languages. This file could be modified by any user out there running into these problems. What do you think? Thorsten -----Ursprüngliche Nachricht----- Von: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]Im Auftrag von GS Jones Gesendet: Donnerstag, 31. Mai 2001 14:19 An: [rebol-list--rebol--com] Betreff: [REBOL] Re: AW: Re: read ftp:// error Hi, Thorsten, My suggestions yesterday clearly suffered from sloppiness. Sorry! I've corrected the oversites AND tested what I could of the result. It should work now. Comments interspersed below: From: "Thorsten Moeller"
> Hi Scott, > > thanks for your detailed explanation what to do. > I produced the file, studied its working, and did > some modification, mainly for data tracking. > But for some purposes, when i "do" the generated > file as described, it doesn't seem to have any effect.
I forgot to have you assign the new scheme to the original system ftp scheme word path! Use this line to load your hacked version: system/schemes/ftp: do %/path/to/my/ftp-hack.r
> Is there a way to verify that REBOL uses my > scheme, not the standard one?
The simplest way to be sure it has been loaded in the proper space is to re-probe at the console: probe system/schemes/ftp and scroll up to verify that the hacked lines appear. Additionally, placing a {print "I'm here"} statement at the earliest possibly entry points can give some reassurance while running trials on the hack.
> As well REBOL ask me for a header when doing > the .../ftp_hack.r, so my file has to look like this
<<quoted lines omitted: 6>>
> user: none > .....
Silly me. Of course you have done the correct thing. Sorry to waste your time.
> Bringing this task to a success, i will post a > workaround to the list. > > Thorsten
Great! By the way, I added the foreach print loop to my sample hack, and did simple ftp directory and file reads, and to my amazement, this function is called each time (I wish I could figure out where this is getting called. Grrr!). So I feel confident that this is where the error is occurring. Check it out with your system, and you should see the German versions of the month(s). These then cause the error on the 'to-date line. I have not checked out the following (and really have no convenient way to test it), but these are my thoughts on the work-around, assuming that the above results yield the German names for the months. At the top of the add-date function, you see: add-date: func [] [ month: first pdate system/words/remove pdate system/words/insert skip pdate 1 month ... Try adding the following: add-date: func [] [ month: first pdate if find ["Mär" "Mai" "Okt" "Dez"] month [month: select ["Mär" "Mar" Mai "May" "Okt" "Oct" "Dez" "Dec"] month] system/words/remove pdate system/words/insert skip pdate 1 month ... Of course, I don't know the actual way that the German month names are abbreviated (I used alta-vista's babel-fish), so these series may need to be altered to suit. Hopefully, this is self-evident (which guarantees that it won't be! ;-). Then once this new hack is reloaded, then the program will hopefully work on English and German versions of file systems. Now we only have the other 100+ languages!!! ;-) I suspect that this functionality could be made more generic, but first see if any of the above is helpful. Best wishes, --Scott Jones

 [21/38] from: gjones05:mail:orion at: 31-May-2001 11:24


From: "Thorsten Moeller"
> Tried it out with "Mai" to "May" and works fine for the file i was
trying to
> read.
Great!
> I have to find files for the other months to be tested. > > Keep you informed via the list. > > For a more generic use, perhaps there could be a kind of library-file > containig the translations even for other languages. This file could
be
> modified by any user out there running into these problems. > > What do you think?
We are thinking along the same lines. I was thinking intially that a path refinement could specify the language, but I didn't like the idea of a user necessarily having to specify a language. When I scrounged up what I believe are the German versions, I realized that the words may be different, but the abbreviations are frequently the same! As long as any language month abbreviation is unique, then once the FTP scheme is patched, the select block would substitute the correct English abbreviation if needed. The patching function would be a great place for a user to add his/her own language's month abbreviations if necessary. The patching function could update the select block, and then patch the FTP scheme with this line. I've not experimented with just patching a scheme, as opposed to replacing it, but I do believe it is possible in REBOL. For now, in a separate email thread I'll poll for other languages. I collected what I believe are the months and abbreviations for English, Spanish, French, German, Italian, and Portuguese (the languages available through BabelFish). So far the only redundancy is that the first 3 letters of June and July in French are Jui so I don't know the way that the French deal with this. Hopefully I can flush out enough examples to see if this is a viable approach. If it is not possible to include many common languages, then we could always fall back to a few common ones and allow the user to add any necessary. Is this similar to what you are thinking? --Scott Jones

 [22/38] from: sterling:rebol at: 31-May-2001 10:33


The real issue is of localization which is an issue all to itself and not particularly related to FTP. However, for the purposes of patching your FTP scheme and following the ideas already put forth in this thread, let me suggest the following change. As you have noticed, the problem is that REBOL is reading the directory before the download abd is having trouble parsing the directory information. It does this because it is trying to find out how large the file is before download so that it can download most efficiently... almost all FTP clients do this in order to display a progress bar. Anyhow, here's an added function to convert a month abbreviation to the REBOL readable version and a change to the first line of the add-date function in the FTP protocol. convert-month: func [month [string!] /local conv seek] [ conv: [ "Mai" ["May"] ] if seek: find conv month [return first first find seek block!] month ] add-date: func [] [ month: convert-month first pdate ; these lines reverse the month and day so we can make a date of it ... ... ... ] The conv block in convert-month can be extended to handle any number of languages simply by adding another string before the block containing the result version. For example, if May were also abbreviated as "Moi", and "Mal" in some other languages then conv would have a line like this: Mai "Moi" "Mal" ["May"] The function finds what you have, "Mai" or other abbreviation in the list. If it does find it, it then grabs the element in the first block. This way you can have as many mappings from other languages to the result as you want. If you do compile a list of abbreviations from elsewhere please post them as we might include this type of solution in the next versions. Needless to say, this blowout will be fixed one way or another. Sterling

 [23/38] from: moeller_thorsten:gmx at: 31-May-2001 21:13


Hi Scott, Sterling, Scott, i totally agree with your thoughts. Have you looked at Sterling's function? Sterling, thanks a lot for your contribution. I think that this function is the one we can easily use for this purpose, what do you think Scott? Together with your collected abbreviations this will do it. I hope that i can test it tomorrow, back in my company. But there should be a more easy way to do the patching, like a script you only have to add to your user.r Any other ideas? Thorsten

 [24/38] from: gjones05:mail:orion at: 31-May-2001 14:12


From: <[sterling--rebol--com]>
> The real issue is of localization which is > an issue all to itself and not particularly
<<quoted lines omitted: 10>>
> most efficiently... almost all FTP clients do > this in order to display a progress bar.
Makes sense. I simply seem unable to see where this code gets called during the directory/file entry read. It doesn't really matter, of course, it just bugs me. ...
> if seek: find conv month [return first first find seek block!]
... Hey, I didn't know 'find could accept type. Cool! And of course I should have known that REBOL would offer this more generic approach.
> This way you can have as many mappings > from other languages to the result as you want.
Precisely what I was thinking, but my solution would have been both longer and less elegant. You are good at this. Maybe RT will give you a job! ;-)
> If you do compile a list of abbreviations from elsewhere please post > them as we might include this type of solution in the next versions.
No problem. But so far few takers as you can see. Maybe the Subject of the post was poorly named.
> Needless to say, this blowout will be fixed one way or another.
We all new RT would! Thanks for your input, Sterling. --Scott Jones

 [25/38] from: gjones05:mail:orion at: 31-May-2001 15:10


From: "Thorsten Moeller"
> Scott, i totally agree with your thoughts. Have you > looked at Sterling's function?
Yes. As you will notice my email arrived shortly after your email (major list latency today). Sterling's version is shorter and more elegant. The version that he included in the other thread returns the block instead of the month abbreviation, but simply adding another 'first fixes it, as he did in the shorter version in this thread. ... if seek: find conv month [return first find seek block!] ... becomes ... if seek: find conv month [return first first find seek block!] ...
> Sterling, thanks a lot for your contribution. > I think that this function is the one we can > easily use for this purpose, what do you think > Scott? Together with your collected abbreviations this > will do it.
I agree. I'm disappointed that no one has posted more versions to the list, and I still don't know how the French handle June/July with "Jui" being the first three letters of both. Oh well, it didn't hurt to try.
> I hope that i can test it tomorrow, back in my company. > But there should be a more easy way to do the patching, > like a script you only have to add to your user.r > > Any other ideas?
Later today, I'll work on a way to add the patch to the existing scheme (maybe someone has already done this?), and adding Sterling's convert-month function and patch to the user.r file is surely the best way to do it. I'll post what I find when I can take some time to look/experiment. --Scott Jones

 [26/38] from: sterling:rebol at: 31-May-2001 14:06


Ah yes. Guru tricks not yet in the documentation most likely.
> > if seek: find conv month [return first first find seek block!] > ....
<<quoted lines omitted: 6>>
> We all new RT would! Thanks for your input, Sterling. > --Scott Jones
The fix in the next release will be that the error is caught and the date wil be set to NONE. You'll see no difference in file or directory reading but if you use MODIFIED? or INFO? on one of these files, the date will come back as NONE. Basically, and FTP server that is responding with localized dates is bad. The only way to deal with that would then be to have all abbreviations for all languages of the world in your program and that's ridiculous. Sterling

 [27/38] from: agem:crosswinds at: 31-May-2001 22:57


Hi Thorsten, Scott, Sterling! Congratulations! Great to see this volleyball-programming in the list :) my $0.02: would work system/schemes/ftp: make system/schemes/ftp[ the-new-functions ] ? if ftp playes clean with contexts, it should work after that. Small enough for the user.r ? -Volker
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 31.05.01, 20:13:51, schrieb "Thorsten Moeller" <[moeller_thorsten--GMX--De]> zum Thema [REBOL] Re: read ftp:// error:

 [28/38] from: agem:crosswinds at: 31-May-2001 23:53


>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 31.05.01, 22:06:27, schrieb [sterling--rebol--com] zum Thema [REBOL] Re: read ftp:// error:
> Ah yes. Guru tricks not yet in the documentation most likely. > > > if seek: find conv month [return first first find seek block!]
<<quoted lines omitted: 17>>
> with that would then be to have all abbreviations for all languages of > the world in your program and that's ridiculous.
Was my first though, but then all dates are none with no workaround. This translate-trick impresses me. Thinking about /desktop with broken smart-update -brrr. Patching ftp again ;-) Better would be a) a block system/schemes/ftp/translate-month (initial empty) b) and/at least a /custom which understands 'translate-month c) =a extended to a server-specific host-list with server-specific translations(like proxy. to big?) its users response then. If they know their host they have dates.
> Sterling
-Volker

 [29/38] from: gjones05:mail:orion at: 31-May-2001 22:01


Hi, Thorsten, Sterling, Volker, VN> Great to see this volleyball-programming in the list :) Yes, it takes a hard hit to get the volleyball all the way from central US to central Europe! VN> my $0.02: VN> would work VN> system/schemes/ftp: make system/schemes/ftp[ VN> the-new-functions VN> ] VN> ? This would be a great idea if the critical part were not buried with in a function of a function. VN> if ftp playes clean with contexts, it should work after that. VN> Small enough for the user.r ? This was exactly what I was looking for. I am certain that I am as skilled as you, Volker. You will probably show me a nice short way to do this. What I was wanting to do was to surgically implant a patch in the FTP scheme. It took a lot of peeking, poking and hacking to figure this out, but I believe that I have it. I have looked the world over (OK, maybe only a tiny fraction of the world) for a comprehensive list of month abbreviations. I give up!!!! I have at least assured myself that my earlier list seems OK except that I am still unsure about the June and July issue (Juin and Juillet -> Jui and Jui???). I think I'll just leave it as Sterling left it in his script. Here is the proposed script and patch, with the buglet fixed in the script. ;;;;;;;;; ;Sterling's script convert-month: func [month [string!] /local conv seek] [ conv: [ Ene "Gen" ["Jan"] Fév "Fev" ["Feb"] Mär ["Mar"] Avr "Abr" ["Apr"] Mag "Mai" ["May"] Jui "Giu" ["Jun"] Lug ["Jul"] Aoû "Ago" ["Aug"] Set ["Sep"] Ott "Out" ["Oct"] ; ["Nov"] ; none here Dic "Déc" "Dez" ["Dec"] ] if seek: find conv month [return first first find seek block!] month ] ;Scott's surgical insertion patch tool ;note, this will likely need to be on one line ;changes {month: first pdate} to {month: convert-word first pdate} insert next find pick pick get in system/schemes/ftp/handler 'parse-files 2 31 to-set-word 'month 'convert-month ;;;;;;;; This leaves the 'convert-month script in the global namespace, which would be an benefit if needed elsewhere. I guess it could also be put into the FTP scheme object block. My surgical insertion tool is admittedly fragile in that it is not checking for versions. I started out putting in a version checker, but left it out in the end. If this blowout will be fixed in the next release, then the user would have to specifically remember to remove this patch from the user.r file or risk corrupting the code. Thorsten can check it out, and you are all welcome to comment. --Scott Jones

 [30/38] from: brett:codeconscious at: 1-Jun-2001 14:23


Hi Scott, I just want to comment on the patching process. I recognise that you made the decision to leave out the check which I respect. But I think it should be highlighted for people that are maybe new to this concept that patches introduce risk of unexpected/unpredictable behaviour if the right set of remote circumstances arise - which is generally considered by pessimists/realists guaranteed to happen :-) So, patches are generally to be avoided unless really required. Also, because of the way we patch Rebol code, old patches are still applied to new versions. This is different to the traditional patch which is applied directly to the old executable and lost when a new version is installed. I had to patch the FTP scheme recently and because I couldn't trust myself to remember the patch, I've put in version checking and a paranoid test to ensure that the patch is changing what it thinks it is changing. You can have a look at if it is of interest. It doesn't handle the user-unaffected-by-bug-case though. http://www.codeconscious.com/rebol-library/patches.r Regards, Brett. ----- Original Message ----- From: "GS Jones" <[gjones05--mail--orion--org]> To: <[rebol-list--rebol--com]> Sent: Friday, June 01, 2001 1:01 PM Subject: [REBOL] Re: read ftp:// error Hi, Thorsten, Sterling, Volker, VN> Great to see this volleyball-programming in the list :) Yes, it takes a hard hit to get the volleyball all the way from central US to central Europe! VN> my $0.02: VN> would work VN> system/schemes/ftp: make system/schemes/ftp[ VN> the-new-functions VN> ] VN> ? This would be a great idea if the critical part were not buried with in a function of a function. VN> if ftp playes clean with contexts, it should work after that. VN> Small enough for the user.r ? This was exactly what I was looking for. I am certain that I am as skilled as you, Volker. You will probably show me a nice short way to do this. What I was wanting to do was to surgically implant a patch in the FTP scheme. It took a lot of peeking, poking and hacking to figure this out, but I believe that I have it. I have looked the world over (OK, maybe only a tiny fraction of the world) for a comprehensive list of month abbreviations. I give up!!!! I have at least assured myself that my earlier list seems OK except that I am still unsure about the June and July issue (Juin and Juillet -> Jui and Jui???). I think I'll just leave it as Sterling left it in his script. Here is the proposed script and patch, with the buglet fixed in the script. ;;;;;;;;; ;Sterling's script convert-month: func [month [string!] /local conv seek] [ conv: [ Ene "Gen" ["Jan"] Fév "Fev" ["Feb"] Mär ["Mar"] Avr "Abr" ["Apr"] Mag "Mai" ["May"] Jui "Giu" ["Jun"] Lug ["Jul"] Aoû "Ago" ["Aug"] Set ["Sep"] Ott "Out" ["Oct"] ; ["Nov"] ; none here Dic "Déc" "Dez" ["Dec"] ] if seek: find conv month [return first first find seek block!] month ] ;Scott's surgical insertion patch tool ;note, this will likely need to be on one line ;changes {month: first pdate} to {month: convert-word first pdate} insert next find pick pick get in system/schemes/ftp/handler 'parse-files 2 31 to-set-word 'month 'convert-month ;;;;;;;; This leaves the 'convert-month script in the global namespace, which would be an benefit if needed elsewhere. I guess it could also be put into the FTP scheme object block. My surgical insertion tool is admittedly fragile in that it is not checking for versions. I started out putting in a version checker, but left it out in the end. If this blowout will be fixed in the next release, then the user would have to specifically remember to remove this patch from the user.r file or risk corrupting the code. Thorsten can check it out, and you are all welcome to comment. --Scott Jones

 [31/38] from: agem:crosswinds at: 1-Jun-2001 7:26


>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 01.06.01, 04:01:04, schrieb "GS Jones" <[gjones05--mail--orion--org]> zum Thema [REBOL] Re: read ftp:// error:
> Hi, Thorsten, Sterling, Volker, > VN> Great to see this volleyball-programming in the list :) > Yes, it takes a hard hit to get the volleyball all the way from
central
> US to central Europe!
!!
> VN> my $0.02: > VN> would work
<<quoted lines omitted: 3>>
> VN> ? > This would be a great idea if the critical part were not buried with
in
> a function of a function. > VN> if ftp playes clean with contexts, it should work after that. > VN> Small enough for the user.r ? > This was exactly what I was looking for. I am certain that I am as > skilled as you, Volker. You will probably show me a nice short way to > do this.
Sorry. I thought you used full source for better patching. it was Thorsten who asked for a shorter version. Of course i should wait for you to tell, but there was the ball, quick coming, iam standing ready.. ;-) Playing with the parts of my swiss-knife, for the nice part: p: second get in system/schemes/ftp/handler 'parse-files p: first find/tail p [add-date: func[]] insert next p [convert-month] ? p for the short, no chance. I was below. You are to picky :)
> What I was wanting to do was to surgically implant a patch in the FTP > scheme. It took a lot of peeking, poking and hacking to figure this > out, but I believe that I have it. > I have looked the world over (OK, maybe only a tiny fraction of the > world) for a comprehensive list of month abbreviations. I give up!!!! > I have at least assured myself that my earlier list seems OK except
that
> I am still unsure about the June and July issue (Juin and Juillet -> Jui > and Jui???). I think I'll just leave it as Sterling left it in his
<<quoted lines omitted: 26>>
> insert next find pick pick get in system/schemes/ftp/handler > 'parse-files 2 31 to-set-word 'month 'convert-month
could not be shorter.
> ;;;;;;;; > This leaves the 'convert-month script in the global namespace, which
<<quoted lines omitted: 3>>
> out putting in a version checker, but left it out in the end. If this > "blowout" will be fixed in the next release, then the user would have
to
> specifically remember to remove this patch from the user.r file or
risk
> corrupting the code.
The saw and the screwdriver and the - ah here: v: system/version v/4: v/5: 0 if 1.2.0 <> v [request/confirm "BANG?"] ;write/append %hidden-patches-log "i patched ftp-scheme!!" ? :-)
> Thorsten can check it out, and you are all welcome to comment. > --Scott Jones
-Volker

 [32/38] from: moeller_thorsten:gmx at: 1-Jun-2001 9:53


Hi Scott, Sterling, the only thing i can say is WELL DONE, works great. Just inserted your script into my user.r and off we go, without any problems. I kept my self informed that i am using a patched version of REBOL with adding print "" print {"++++++++++++++++++++++++++++++++++++++++++++++++++++ ATTENTION - ATTENTION - ATTENTION - ATTENTION + Your ftp-scheme has been patched to suite international abbreviations. + Please remove this patch from your user.r if you upgrade to a higher + Version in which the problem is fixed by REBOL-Technologies!! + ATTENTION - ATTENTION - ATTENTION - ATTENTION + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"} print "" print "" after your script. It is enough for me cause i am mainly working on the console. For apps running in quiet mode this won't be enough. Disabling the patching by Version verification could be a problem as we don't know the next Version numbers and if the Problem will be fixed in this Release. So, the earliest date we can make the patching related to Versions is when these Versions are out and we could be sure that the problem is fixed. Do you have any other suggestions? Thorsten

 [33/38] from: gjones05:mail:orion at: 1-Jun-2001 7:20


Hi, Thorsten, Sterling, Volker, Brett, This volleyball game now spans the globe. Brett, you are really going to have to hit the ball hard from "Down Under" BH> I just want to comment on the patching process. BH> I recognise that you made the decision to leave BH> out the check which I respect. ... Brett, thank you for being so diplomatic. My decision for this final beta was based more on fatique than anything else. I've not messed with version checking before, so when I started setting up the different product and version checks, I realized that it was going to get involved. I wanted to get the script-patch posted so that Thorsten could give it a test drive in his morning. BH> But I think it should be highlighted for people that BH> are maybe new to this concept that patches BH> introduce risk of unexpected/unpredictable BH> behaviour if the right set of remote circumstances BH> arise - which is generally considered by BH> pessimists/realists guaranteed to happen :-) I absolutely agree that before this is submitted to some "patch library" (is there such a beast?), the product-version checking is a better idea. You've set up a nice framework in the patches.r file. I'm trying to grok the content (like using 'use); lot's to learn, but Thorsten's theorem and Brett's bric-a-brac and Volker's volleys and Sterling's stuff are giving me lots of good material. Thanks. (I was struggling with the rhymes, as is probably obvious.) VN> Sorry. I thought you used full source for better patching. VN> it was Thorsten who asked for a shorter version. Yes, we were hacking on the full source; it is easier for lead-poisoned people like me to see what I am doing. Originally I envisoned leaving the hacked scheme as a separate file, like I did with the ESMTP version of SMTP. But I realized that since "all the code is just data", that there's got to be a way to poke the part need into the code. I highly suspected that someone had done this before, but I couldn't remember seeing it on the list nor on all the sites that I have viewed. Again, fatique kept me from doing another search, so I started kacking and came up with my one liner. VN> Of course i should wait for you to tell, VN> but there was the ball, quick coming, iam VN> standing ready.. ;-) Yes, those "spiked balls" come fast. VN> Playing with the parts of my swiss-knife, for the nice part: VN> VN> p: second get in system/schemes/ftp/handler 'parse-files VN> p: first find/tail p [add-date: func[]] VN> insert next p [convert-month] VN> ? p Your version (and Brett's) is infinitely easier to read (OK, maybe not inifinitely; just more like 1/0.0000000001; I'm prone to exageration sometimes ;-). There is no doubt about it, I've got to get me a Swiss knife just like yours!!! SJ> My surgical insertion tool is admittedly fragile in that it is SJ> not checking for versions. I started out putting in a version SJ> checker, but left it out in the end. If this "blowout" will be SJ> fixed in the next release, then the user would have to SJ> specifically remember to remove this patch from the user.r SJ> file or risk corrupting the code. VN> The saw and the screwdriver and the - ah here: VN> v: system/version VN> v/4: v/5: 0 VN> if 1.2.0 <> v [request/confirm "BANG?"] VN> ;write/append %hidden-patches-log "i patched ftp-scheme!!" Got to get me one of those knives! Here was the framework that I put together: if either system/view [ equal? rejoin [system/version/1 "." system/version/2] "1.2"][ equal? rejoin [system/version/1 "." system/version/2] "2.5"][ ;do stuff here ] While it seemed to work, I started thinking about /Command and /Express (nee Link), and started thinking that I was in over my head for how tired I was feeling. Hence, leaving the product-version stuff out. Combining the if and either works but suffers from readability (I've never quite figured out how to indent this type of construct for maximum understandability). TM> the only thing i can say is WELL DONE, works great. TM> Just inserted your script into my user.r and off we go, TM> without any problems. Thanks. TM> I kept my self informed that i am using a patched TM> version of REBOL with adding... I am not sure that it is attention-grabbing enough. Just joking! :-) TM> after your script. It is enough for me cause i am TM> mainly working on the console. For apps running TM> in quiet mode this won't be enough. With a slight alteration, it can be made to work with /Core or /View ftp-patch-alert: {++++++++++++++++++++++++++++++++++++++++++++ ATTENTION - ATTENTION - ATTENTION + Your ftp-scheme has been patched to suit international abbreviations. + Please remove this patch from your user.r if you upgrade to a higher + Version in which the problem is fixed by REBOL-Technologies!! + ATTENTION - ATTENTION - ATTENTION + ++++++++++++++++++++++++++++++++++++++++++++} either system/view [ request/ok ftp-patch-alert ][ print ftp-patch-alert ] TM> Disabling the patching by Version verification could be TM> a problem as we don't know the next Version numbers TM> and if the Problem will be fixed in this Release. So, the TM> earliest date we can make the patching related to Versions TM> is when these Versions are out and we could be sure that TM> the problem is fixed. Excellent points! TM> Do you have any other suggestions? No, I really don't. I've truly not had enough experience in this sort of thing. All I would know to do would be to make the patch as specific as possible to products-versions, so that it wouldn't accidentally trash incompatible versions. I would think it would be easier to patch the patch if needed, than have someone spend countless hours tracking down something that was only due to a patch. I will gladly defer to anyone else in this area. Sterling, Volker, Brett? I take on these types of challenges because it helps me to improve my skills and it contributes to the community. Like the ESMTP scheme, I suspect that few will actually need this patch, but I don't know. I do know that for every person who speaks up, there are probably ten others with the same problem who don't speak up. So we never know how many people give up on REBOL just because their first FTP session failed just because the server file dates were localized. This may sound overly dramatic, but when a product line promotes itself as making easy things easy, well, FTP should clearly fall into the easy category. Yes? I am glad that the patch worked. I enjoyed working with you on this mini-task. And thanks to all for the nifty things you taught me! --Scott Jones

 [34/38] from: brett:codeconscious at: 1-Jun-2001 23:16


> Hi, Thorsten, Sterling, Volker, Brett, > > This volleyball game now spans the globe. Brett, you are really going > to have to hit the ball hard from "Down Under"
Ow. It stings don't it?
> BH> I just want to comment on the patching process. > BH> I recognise that you made the decision to leave > BH> out the check which I respect. ... > > Brett, thank you for being so diplomatic.
:) Nah, not diplomatic. Just trying to acknowlege your message about deciding not to include checking - I guessed it was from lack of time, because it took me a while before I could root out some of the conditions in my code as well. .....
> I will gladly defer to anyone > else in this area. Sterling, Volker, Brett?
Ooops - sorry missed the ball... :)
> I take on these types of challenges because it helps me to improve my > skills and it contributes to the community. Like the ESMTP scheme, I
<<quoted lines omitted: 5>>
> dramatic, but when a product line promotes itself as making easy things > easy, well, FTP should clearly fall into the easy category. Yes?
Yes. :) And I've learnt quite a bit from just reading the posts on the thread to this point (wow, FTP being brought done by localisation problems - gee whiz)... Thanks for you numerous contributions on this list Scott. Regards, Brett.

 [35/38] from: agem:crosswinds at: 2-Jun-2001 14:16


[REBOL [] { Hi, Scott, Thorsten, Sterling, Brett, Anton regarding version-security i'm very reluctant to suggest this, after all our clever injection stuff, :) but maybe using the molded source is the safest thing? We can have version-check with 1234 = probe checksum mold ftp we can create patcher with parsing the source, instead of stepping through blocks. (Ok, not really needed.) we can rename the patched protocol, have original ftp:// and patched-ftp:// parallel then. (Hm, a 'make would do this too.) after that we write a %patched-ftp.r to be called by %user.r (more overhead.. but) this should be mostly version-safe? ok, gets pretty long now. maybe simply posting full source ;-) but the [probe checksum] is clever, yes? ;-) (hope it works everywhere..) -Volker } ;------ ;---------------- convert-date-source: { {not handy yet, insert please} } ;---------------- either 5772242 <> probe checksum mold system/schemes/ftp [ request/ok "wrong rebol-version! patched ftp disabled!" ] [ either not parse mold/only system/schemes/ftp [ copy begin thru { add-date: func [] [ month: } copy rest to end ] [request/ok "could not parse right. check script!"] [ body: rejoin [convert-date-source begin " convert-month " rest] save/header save-file: %patched-ftp.r compose/deep [ system/schemes: make system/schemes [ patched-ftp: (load body) ] ] [title: "patched ftp protocol"] ] ;check it do save-file probe first system/schemes ;read patched-ftp://something ] ]
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 01.06.01, 13:20:35, schrieb "GS Jones" <[gjones05--mail--orion--org]> zum Thema [REBOL] Re: read ftp:// error:
> Hi, Thorsten, Sterling, Volker, Brett, > This volleyball game now spans the globe. Brett, you are really going > to have to hit the ball hard from "Down Under"
<-- lots of great & funny stuff snipped, think you have it allready ;-) -->

 [36/38] from: brett:codeconscious at: 2-Jun-2001 23:32


Hi Voker,
> but the [probe checksum] is clever, yes? ;-) (hope it works > everywhere..)
Very clever - yes :) It certainly dramatically reduces the risk of error. Though it cannot completely remove the risk of an error. Nice idea - thanks! Regards, Brett.

 [37/38] from: gjones05:mail:orion at: 2-Jun-2001 8:48


Sports Announcer's Voice: ... Volker makes a long lob of the volley ball. It's headed to the back of the court. Scott, who had been guarding the net, suddenly finds he's running to the back of the court. Will he be able to get there in time? ... From: "Volker Nitsch"
> i'm very reluctant to suggest this, after all our > clever injection stuff, :) > but maybe using the molded source is the safest thing?
I have gone back and forth on this issue. There seem to be benefits and drawbacks to both, and I suspect it would get down to personal preferences. I guess I don't feel strongly about it one way or another.
> We can have version-check with > 1234 = probe checksum mold ftp > > we can create patcher with parsing the source, > instead of stepping through blocks. > (Ok, not really needed.)
But, the idea of having a source-parsing, patch generator is really a neat idea in the long run. I'm sure it will be needed more than once ... at least until /Core 3.0, which we all know will be perfect!!!
> we can rename the patched protocol, have original ftp:// > and patched-ftp:// parallel then. > (Hm, a 'make would do this too.) > > after that we write a %patched-ftp.r to be called by %user.r > (more overhead.. but) > this should be mostly version-safe?
Yes, I thought about this also. It was what I did on the ESMTP scheme. But on this mini-project for Thorsten, I suspected that a more transparent approach might provide more utility. Again, I can see benefits and drawbacks to both approaches.
> ok, gets pretty long now. maybe simply posting full source ;-) > but the [probe checksum] is clever, yes? ;-) (hope it works > everywhere..)
I think the checksum is very clever. It could serve as yet another double check. If a scheme has already been patched elsewhere, like Brett mentioned, then this double check would be sure and not mess up a patched version. Very interesting...
> -Volker > }
Uh, oh. I just realized that there is code included. I'm out of time (need to run errands). I'll look over your code later. Sorry. Neat ideas, Volker. From the many things that you contribute to the list, I can see that you are a person that regularly thinks "outside of the box." This is a Good Thing. Thanks. --Scott Jones

 [38/38] from: gjones05:mail:orion at: 2-Jun-2001 16:37


Sports Announcer's Voice: ...And the volley ball bops Scott right on the nose. Ohhhh. It looks like a nose bleed. Scott goes to the sidelines while Brett takes Scott's place .... OK, I got the errands taken care of (Mother-in-law is coming to visit ... oh, is that the "Ride of the Valkyries" I hear? Just teasing.), and I have now had a chance to look at the code. Let me start by saying that your code is far more clever than I am. After a bit of study, I finally figured out what you were doing. (It reminds of the analogy that I know the notes on a musical scale, but I can't hear the music by just reading a symphonic score like a conductor can. Oh, there's that musical theme, again. Oh, I see, the volley ball game is in a time out and the band is playing! I guess that ball hit harder than I realized.) Once, again, this is amazingly clever stuff that you have written. Bravo. So I inserted the convert-month source into the convert-date-source and braced for the Volker Auto-ftp-scheme-patch-maker. Then, then, then .... my nose started to bleed again. Rats. First, an unexpected blow to the checksum idea. I discovered that my Win98 ftp scheme checksum was 5504709 for /View and 7796860 for /Core. I guess between line terminators and (???) tabs, there seems to be different checksum for different products and platforms! It was really a good idea, too. I changed the checksum to match. Next, I was unable to get the scheme parser to find the beginning of the add-date stuff. So far I have been unable to determine what is causing a mismatch (could it be the brackets?). On a whim, I reduced it to copy through "month:", and it worked correctly. And the script completed without incident. However, placing the "convert-date-source" word in front of the scheme body causes the function definition to preceed the "make object!" Seeing stars .... So I readjust the parse scheme and changed the ordering of the body definition, placing the new function right at the start of the add-date function and success! At least, it appears to be a success, since I cannot check it against a German, etc, localized FTP server. It works on an English localized server. So, there is definite promise in this approach, and of course, I'm speaking beyond this FTP patch issue (I think we all are!?) and to more general distributed patch techniques. This is some nifty, code, Volker. I've learned yet more techniques. Thanks. I'll send the current version back for your information. Note it currently has my checksum value in it. --Scott Jones convert-date-source: { convert-month: func [month [string!] /local conv seek] [ conv: [ Ene "Gen" ["Jan"] Fév "Fev" ["Feb"] Mär ["Mar"] Avr "Abr" ["Apr"] Mag "Mai" ["May"] Giu ["Jun"] Jui "Lug" ["Jul"] Aoû "Ago" ["Aug"] Set ["Sep"] Okt "Ott" "Out" ["Oct"] ; ["Nov"] ; none needed yet Dic "Déc" "Dez" ["Dec"] ] if seek: find conv month [return first first find seek block!] month ] } ;---------------- either 5504709 <> probe checksum mold system/schemes/ftp [ request/ok "wrong rebol-version! patched ftp disabled!" ][ either not parse mold/only system/schemes/ftp [ copy begin to {month:} thru {month:} copy rest to end ][ request/ok "could not parse right. check script!" ][ body: rejoin [begin convert-date-source "month: convert-month " rest] save/header save-file: %patched-ftp.r compose/deep [ system/schemes: make system/schemes [patched-ftp: (load body)] ] [title: "patched ftp protocol"] ] ;check it do save-file probe first system/schemes ;yep, there it is! ;read patched-ftp://something ]

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted