[REBOL] Re: read ftp:// error
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
