Am Mittwoch, 29. Mai 2002 08:20 schrieb Boleslav Brezovsky:
> I'm really sorry, it's on http://www.sweb.cz/rebolek/castro.r
>
> or sites/rebolek/castro
>
> and - if you does not have directories %/c/ and %/c/view/ then the
> script crashes so you have to change the sourcecode.
>
Crashing on a reb-site?
why not
dir1: %./
dir2: dirize view-root/public
also to use editor without security-question,
you can use something like
append ctx-edit [
prefs: clean-path %./edit-prefs.r
]
next wishes:
saving current directories,
entering ftp-urls, with seperate password-question :)
> it was written under View 1.2.5 (the new beta) so it may look strange in
> 1.2.1
>
> ***
>
> > Well, this one appears to have made it. I'm starting to think that
>
> people
>
> > should include a real-time stamp from REBOL just when they send it,
> > so we can see what delivery patterns are like. Granted, you could
>
> check
>
> > the headers, but sometimes I'm not so sure which time zone they use,
> > if it's the time from the sender's computer or from his mail server,
>
> etcetc
> ****
> It took just hour or less for me to get this mail, it's OK now.
>
> > Any known limits on sizes of pictures and text files (what editor
>
> does it use?),
>
> > or depth of subdirectories, and "funny-names", ie My%20Documents?
> >
> >****
>
> It uses inbuild VIEW editor (just type editor in console or run it from
> desktop to see it) so it has its limits. The image viewer is just simple
> view/new layout [image (load %some-image)] - I have to enhance it
> somehow.
>
> The depth of subdirectories is AFAIK unlimited - if REBOL can read the
> path then it can be shown in castro.
> Same with funny names - depends only on REBOL.
>
> > Yeah, those are relatively simple tasks. And I understand the,
> > "It's 1am, so deal with it." ;) I do it too often myself.
> >
> :-))
>
> **
>
> > If I recall previous discussions on here, some suggested that
> > you create a temp buffer for copying, with a size cap; create
> >and open the target file, read in the cap amount of data (if there
> >is at least that much) from the source file, then dump it into the
> >target file. Once it's been dumped, re-fill the buffer from the source
> >
> >file, dump again, etcetc, until the remaining data is <= the buffer.
> > I'm sure this isn't the absolutely most efficient method, though.
> > I have yet to do it myself, but I haven't really needed to.
> > The only large files I've really manipulated with REBOL were when
> > I wrote a static download assistant to download MP3s from a friend's
> >machine via http and write them to disk locally.
>
> ****
>
> Hmm, buffer...I think that the size of the buffer is very system
> dependent...I'll rather use write/read first (so I'll have some room for
> improvements and service packs ;-)
> I'll add FTP for sure and maybe HTTP dir-browser?
>
> > Yeah, that's the beauty of open source. At least, if you're
> > willing to share your code. If not, then you're screwed ;) Hehehe.
>
> I like open source very much. And it's really must with REBOL 'coz the
> Very-Well-Known-Lack-Of-Documentation :-)
>
> The next version will support browsing thru ZIP and RAR archives (no
> unpack or pack, sorry) thanks to magical Oldes.
>
> bye Bolek
>
> ---
> Odchozí zpráva neobsahuje viry.
> Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
> Verze: 6.0.351 / Virová báze: 197 - datum vydání: 19.4.2002
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
