[REBOL] script not terminating, continues to replicate Re:(3)
Shucks. Hm So, this script had been working when tested? Adding QUIT to the end? The script as it appears to me, as a regular CGI, shouldn't behave that way, so I'd conjecture there's something about the SSI method that causing the problem. Wish I could be more helpful. -jeff > >A) You are not using a REBOL/view to serve this cgi, yes? > > I am using /Core 2.3 for Solaris on Sparc. > > >B) You are using an expired experimental? > > It is not an experimental version of /Core. > > >So is the #! line pointing to the correct REBOL? > > Yes. The script is in the same directory as the binary. > > >How is this invoked, through an IMG tag? > > The script is invoked using an exec statement which is > invoked by an include statement. > > >I see that it is ending with .cgi. Perhaps another > >copy of it is lying around in another directory > >getting invoked erroneously? > > nope. > >
[REBOL] script not terminating, continues to replicate Re:
Howdy, Ryan.
Sorry to hear about your CGI woes.
Two considerations:
A) You are not using a REBOL/view to serve this cgi, yes?
If so, a REBOL/view would fail on boot trying to connect to
an X host that is not available. The process then hangs
out. This is a known problem. Use REBOL/core.
B) You are using an expired experimental? This would also
fail on boot-- though I don't know if it will hang out.
Maybe check to see if you can run the version of REBOL
directly.
So is the #! line pointing to the correct REBOL?
Otherwise, this script doesn't look like it could be
causing that problem.
How is this invoked, through an IMG tag?
You could also add a little logging:
write/append %banner-script.log now
I see that it is ending with .cgi. Perhaps another copy of
it is lying around in another directory getting invoked
erroneously?
-jeff
> My hosting service said they suspended my site because "This script has been
> running constantly since the site was re-enabled, with 10 plus copies running
> on each webserver. Not only does this monopolize system resources, but the
> script does not terminate properly and continues to replicate. We cannot
> permit scripts with programming errors on our servers as they
> impact the behavior of other customer sites."
>
> -Ryan
>
> #!rebol -cs
>
> REBOL [
> Title: "Banner Ad Randomizer"
> File: %webbanner.cgi
> Date: 16-Apr-2000
> Author: "Ryan Christiansen"
> Purpose: {
> Generate HTML code that displays a linked banner advertisement
> }
> ]
[REBOL] Rebol web servers Re:
Howdy, Sharriff: Sorry for the delayed response. The webserver you're referring to went like this. Originally, Tyler and I built a version with the goal of making a working webserver in as few lines as possible. This was 20 lines, if I remember right. Bo, later, reworked the webserver to add REBOL cgi support. So the goal wasn't really robustness, though it looks like Ryan put it through its paces :-). A more robust webserver could be achieved using port multiplexing. A good example of this is Sterling Newton's http proxy script: http://www.rebol.org/web/proxy.r Certainly you could add mime types and all sorts of stuff. There's also (Ingo Hohmann's) YaRWeS (Yet another rebol web server -- did I get that right?) that had a bunch more direct support for mime types and lots of other goodies as does Cal Dixon's REBOL webserver: http://www.rebol.org/web/webserv.html (I can't seem to find Ingo's webserver. It's not on his site or on rebol.org-- maybe it's not released anymore) As far as licensing goes, the script is public domain, and REBOL has it's own EULA (end user license agreement). So, that's my understanding of that stuff. Salutations-- -jeff > Hi Mr.Tyler Booth, Jeff Kreis and Bohdan Lechnowsky ! > > Have you done a stress test with The "microweb server" or > "small web server" ? I had in mind to deployour > applications with another free web server, but it would be > nice if everything was in REBOL, code and deployment, how I > want it, transparently ( human readable REBOL code) . > > I would like to serve XML, XHTML and HTML pages in an > Intranet situation ( 40-50 users ). Can I add other > MIME types? I use FLASH a lot for navigation menus, so > I´ll be needing SWF support. Since its written in > rebol, one could tailor an install routine accordingly. > > Any ideas? Please advise ASAP, if this idea is feasible, > let me know more about licensing, I´ll speak to my boss > about it. > > > Sharriff Aina med.iq information & quality in healthcare AG
[REBOL] System/? Re:
> Where can I find all the refinements or path values and what is the best way > to probe them. > > Paul Tretter With the newest experimental versions of REBOL you can just do: PROBE SYSTEM and a huge pile (~64k) of source code will fly by. That's information overload, so to see what words are at each level of the system object you can do the following: probe first system [self version build product components words license options user script console ports network schemes error standard view stats locale] then probe first system/ports ;-for instance [self input output echo serial] Bo made a script to help people navigate the system object: http://rebol.org/script/browse-system.r A view version would be neat. -jeff
[REBOL] rebol.org seems to be down Re:
> I can't seem to get through to rebol.org tonight (it is now 4:30am PST September 30, > 2000)... Anybody else having problems? Looks up to me. 5:30am PST, September 30, 2000 AD. -jeff
[REBOL] Small admin/report benchmark Re:(4)
Hash! and list! datatypes are fixed up in the upcoming experimental view builds. -jeff > Hi Joel, > > You wrote: > Ladislav's comes next (this is the second > script he > posted; the first one blew up on my box > repeatedly). > > Confused, I expected the SECOND script (the script using > Hash! datatype) to blow up - it looked to me like RT didn't > succeed to implement of Hash! datatype reliably, or like > there was another sign of the GC bug... > > Regards > Ladislav
[REBOL] What should we bake? Re:(4)
Howdy, Ted: > Personally, I'd say that a discussion board/BBS system > would be step one, with file archives and email alerts > being step two. Now there's a real good one. Take a look at the Ultimate BBS (http://infopop.com), which is written in PERL and is like 250k worth of scripts in size. The equivalent REBOL code should be like 50k or something. The key issue for doing a cgi based BBS is session management, authentication, authorization. Those issues have to be dealt with first in the design and implementation before moving on to any of the screens. > A really good environment would be standards-based, so you > could use any handy browser or email client, or enjoy the > enhanced benefits of using a unified, properietary (a la > /VIEW). Ofcourseto remain competitive, Palm > synchronization will be an absolute requirement. A BBS that you can get to from the REB! How cool is that? -jeff
[REBOL] Small admin/report benchmark Re:(3)
Howdy, Joel: > As for Jeff's... > > First, I had to comment out all of the code that was > specific to /View and replace it with equivalent code. (I > needed /Core syntax, and needed to run it in the same > fashionas the others,in order to keep the > apples-to-apples comparison. Hey, no fair! Mine was supposed to be PRETTY not FAST!!! :-) -jeff
[REBOL] REALLY DISCOVER THE POWER OF REBOL Re:(6)
Howdy, Ted: > [re: FUD].. > > And, I don't think it's FUD to offer candid advice with > specific suggestions for change. Naw, my intention was not to rebuke your efforts toward calling it as you see it. Just the feeling was a little demoralizing and ominous the way it comes across on my side of the screen-- > His Majesty's Loyal Advocate, We are all the new Jedi knights of the computing world and we must not turn to the darkside! As say Master Yoda: "Fear leads to anger, anger leads to hatred, hatred leads to suffering!!" :-) :-) ;-) -jeff
[REBOL] REALLY DISCOVER THE POWER OF REBOL Re:(4)
Howdy, Ted: Isn't one of there an Open Source mantra about running around spreading FUD? (Fear, Uncertainty and Doubt) ;-) *grin* -jeff > On 9/22/2000 at 8:51 AM [EMAIL PROTECTED] wrote: > > You are starting to sound a little disheartened in your recents > posts.. :-( > > Oh, I've always been a little cranky, just haven't been > posting as much. The sad part is I'm still saying the same > things I said a year ago. My concern is that people get so > excited about REBOL as a language, they overlook its basic > needs as a competitive product. It would be nice to see > thoughtful, efficient design actually win for a change.
[REBOL] The Industry Needs REBOL But Thinks it Wants Perl Re:(6)
Hello, Mr Siegel! I'm always happy to offer any help I can provide those new to learning REBOL, as are many on this list. I offer my hearty encouragement to you in your ambitious endeavor! -jeff > > > Now that smells like a good business plan, teach > > programming using REBOL. $x per person per lesson x > > times a week adds up well. I am tempted to try this one > > out. > > I am a non-programmer new to the list. I might be working > with Rebol soon, and it is possible that I will have a > patron who would sponsor tutorials for me and my son, 16, > to learn Rebol programming. As I am a writer, these lessons > could then be developed into a commercial or non-commercial > tutorial. > > I'd be interested in hearing some ideas on the feasibility > of this as well as a show of hands from possible tutors. > > > > > -- > JULESSIEGEL Apdo1764Cancun Q. Roo77501 > http://www.cafecancun.com Fax1.530.706.8739 Tel1.52.98 > 83.36.29 > >
[REBOL] pinging SELMA Re:(4)
Howdy, Brian: > >Hmmm, I don't believe this is a bug. The 0 2 "a" matches > >two instances of "a". Check out: > > Well, it took me a long time, but I figured out a bug in my > test code that made it look like parse had a bug. It's not > whitespace, but I still feel foolish now :( Don't! Your efforts are not wasted. Someone may well have learned more about PARSE as a result of it. Reminds me of a story a pilot once told me about "flying the seatbelt". That's when the seatbelt gets caught in the door and when you're up in the air it starts rattling like mad and you start freaking out looking around for the problem and you end up "flying the seatbelt", instead of the plane, so you end up plowing into a mountain! :) Even pilots fly seatbelts occasionally. (How's that for a cheery anecdote?) > I formally apologize for the Feedback messages I sent. No apologies. That's what feedback's there for, but I think we could/should have spotted that earlier and saved you some frustration. :-) Hmm.. I suppose I should see if any bug reports were filled out on this one. (Yep) Well -- all's well that ends well. > Reviewing the SELMA source I can't reproduce the bug I > found before so it must have been fixed. Good! > > Another thing I haven't figured out is how Gabriele is able > to consistently end up with a Re: after the list tag on all > of his posts. Hey, Gabriele has magic SELMA confusing powers! -jeff
[REBOL] parse or Re:(5)
Howdy, Joel:
> Notice that now the result block has only TWO elements!
> Since the first test (the thru {.^/} part) can succeed by
> grabbing text all the way to the end of the SECOND
> paragraph, >it does so, putting the first two paragraphs
> into the first >output string. I assumed that this is NOT
> what you wanted, >but rather you wanted to copy through
> either {.^/} or {."^} >WHICHEVER COMES NEXT. (Natural
> language text munching is a >real pain, speaking from
> personal experience! ;-)
Sure. In the interests of advancing its popularity, I
offered up a simplistic example of PARSE. :-)
Paragraphs can end in a variety of punctuation ("!?.-;:),
with different quantities (as Russ pointed out), no?
-jeff
[REBOL] parse or Re:(3)
Howdy, Ryan:
> > paragraphs: {First paragraph.^/Second "paragraph."^/Third paragraph.}
> > parse paragraphs [some [thru {.^/} | thru {."^/} | thru "." end]]
>
> This returns "true"
Yep, that means that PARSE successfully made it through the
whole string.
To break up your paragraphs, copy out the parts thru each
paragraph ending, like this:
pb: copy []
parse paragraphs [
some [
copy part [thru {.^/} | thru {."^/} | thru "." end]
(append pb part)
]
]
pb
== ["First paragraph.^/" {Second "paragraph."
} "Third paragraph."]
> Sorry if I'm being a pain, but when I read the "parse
> rules" documentation it doesn't make any sense to me. I
> can't see theusefulness of returning "true" in this
> situation.
No pain whatsoever. I like trying to help.
-jeff
[REBOL] parse or Re:
Howdy, Ryan:
paragraphs: {First paragraph.^/Second "paragraph."^/Third paragraph.}
parse paragraphs [some [thru {.^/} | thru {."^/} | thru "." end]]
-jeff
> == {First paragraph.
> Second "paragraph."
> Third paragraph.}
> >> probe parse paragraphs [{.^/} | {."^/}]
> false
> == false
> >> probe parse paragraphs ({.^/} or {."^/})
> ** Script Error: Cannot use or~ on string! value.
> ** Where: ".^/" or {."
>
> So how DO I parse by a value OR another value?
>
> -Ryan
[REBOL] pinging SELMA Re:(2)
Howdy, Brian:
> There is a long-standing bug in the
> parse native in all versions of REBOL that affects the code
> in SELMA that parses subject lines.
> ; Second, with optional more than one "a"
> y-cnt: 0
> parse a: "y a a y z" [
> some [
> to "y" here: "y"
> 0 2 "a" ; Note more than one "a" optional here
> any " " there:
> (y-cnt: 1 + :y-cnt remove/part :here :there) :here
> ] ; This block should run twice, but doesn't
> ]
> print [mold a y-cnt {(should be "z" 2)}]
Hmmm, I don't believe this is a bug. The 0 2 "a" matches
two instances of "a". Check out:
http://www.rebol.com/users/parspace.html
"The parse function ignores all intervening whitespace
between patterns that it scans."
Try these:
parse "a a a a a b" [0 1 "a" m: (print m)]
parse "a a a a a b" [0 2 "a" m: (print m)]
parse "a a a a a b" [0 3 "a" m: (print m)]
. . .
[0 2 "a"] is like saying [0 1 "a" 0 1 "a"]
-jeff
[REBOL] pinging SELMA Re:(8)
You really just need this function: get-head-next-by-XSELMA returns a block containing two URLS and/or none values. You really would want the list archiver to make available a simple REBOL data file of thread info for SELMA to grok on. -jeff > Re threading, I think your suggestion is really good because it is both > useful and simple. > > However I guess there will be a non-trivial amount of work > to get the threading result/functionality from archival > program into Selma. > > Nevertheless, the user archive would be a lot more useful. > > Brett.
[REBOL] pinging SELMA Re:(2)
Howdy, T: Nice idea, senior! :) Anyone actually hacked some improvements to the SELMA code? (You can obtain a copy of the selma source by sending the subject "selma-source" to SELMA. Now there's a mouthful!) -jeff > Here's a thought.. some sort of thread > control/filtering? Enjoy monitoring the conversation, > but deleting upwards of 100 e-mails on busy days. > > T Brownell > > > --- [EMAIL PROTECTED] wrote: > > > BTW: Anyone made any improvements to SELMA that they would > like to share? > > -jeff > > > > __ Do You > Yahoo!? Yahoo! Mail - Free email you can access from > anywhere! http://mail.yahoo.com/ > >
[REBOL] Small admin/report benchmark Re:
Howdy, Joel: > REBOL solution: > > My effort at producing a comparable REBOL script is > given next. I tried to use appropriate REBOLish > idioms to accomplish equivalent results. > > begin REBOL script > #!/usr/local/bin/rebol -sq > > REBOL [] > > shells: copy make block! 5 > countshell: func [sh [string!] /local shr] [ > either none? shr: find shells sh [ > append shells reduce [sh 1] > ][ > change shr: next shr 1 + shr/1 > ] > ] > > foreach line read/lines %passwords.txt [ > countshell any [pick parse/all line ":" 7 "(none)"] > ] > > foreach [sh n] sort/skip shells 2 [ > n: to-string n > while [3 > length? n] [insert n " "] > print [n sh] > ] > = end REBOL script = Here's an alternate approach: (I skipped the sort for now..) REBOL [] shells: make block! 5 ;- no need for xtra copy do func [/sh/blk][ foreach line read/lines %passwords.txt [ sh: pick parse/all line ":" 7 append any [ select shells sh all [ append shells reduce [sh blk: copy []] blk ] ] sh ] blk: copy [backdrop 20.40.200 title "Shells" across] foreach [name sh] shells [ append blk compose [text (form length? sh) tab text (form name) return] ] view layout blk ] ;-- Note, we used rebol's NONE datatype to represent those ;whose shells are NONE. The approach taken is to use blocks to accumulate data and use length? and index? and what not to do the bean counting. I did cheat, though, and didn't bother sorting. Sorry! Reason why is the REBOL sort function is getting some much needed work done to it right now and the new sort function will make this kind of thing a lot easier. Might even use it to sort the actual layout produced! :-) Perl is likely faster for various tasks to REBOL, but REBOL makes many tasks much easier to do. It's all how you slice it. :) -jeff
[REBOL] best means of passing refinements from main to helper function? Re:(4)
> But then this (the example below) explicitly lists the > refinements in the function body. I think the "ultimate" > solution would process an arbitray list, as with a loop. It > is fairly short though :) and IS a step up from 'if > statements, esp for more than 2 refinements. > > - Michael Jelinek Yes, like I meant to say: it's not exactly elegant. (: Refinement transferal is at the frontiers of REBOL research. ;) -jeff > main: func [ > /use-month month-to-use /use-day day-to-use > ] [ > go?: func ['what /it][either it: get what [either true = it [what][it]][]] > do reduce compose/deep [ > to-path [deduction (go? use-month) (go? use-day)] > (go? month-to-use) (go? day-to-use) > ] > ]
[REBOL] debugging rebol apps Re:(2)
Howdy, Michael: > Well, since you asked... > > I have a fairly large application, divided into several > files (modules). . . . > eprint: make object! [ > adv: func [msg-raw [series!]][ if any [testing/adv > testing/all][print > [ "^(tab)ADV: " reduce msg-raw ]]] > dun: func [msg-raw [series!]][ if any [testing/lib > testing/all][print > [ "^(tab)DUNGEON: " reduce msg-raw ]]] Wow, when do we get to see that? (-: -Jeff
[REBOL] debugging rebol apps Re:(2)
Incrementally. Each time I make a change that I think is
trivial, I still go make sure it works as expected. I break
out common code into functions, and then debug those functions
individually. Always add type specifiers to function arguments
to be sure you're being passed what is expected.
The thing that always seems to help for me is I'll try to make
each module do something very simple successfully before
elaborating. Like, for instance, if the goal of a function is
to generate some data and then display it (or have another
function display it) I make my first goal to successfully:
print mold data
When a script reaches the couple pages mark, I find it helps
to break out common parts, like utility functions, to go into
their own file. They can always be recombined later, but the
more scrolling you end up doing the more confusing it can become.
Nothing revolutionary in those approaches, but I find them
helpful in building larger apps.
-jeff
> Hi. Since rebol does not have a compiler, I find it a bit
> more difficult to debug large rebApps. Anyone have any
> debugging tips/strategies? Curious how others debug their
> scripts...
>
> Rishi
[REBOL] pinging SELMA
Just FYI: If you think one of the lists is down you can always send SELMA a message with only the word "help" on the subject line. If she's running she'll let you know with a copy of the commands she knows: -- Here is some helpful information: Commands to REBOL SELMA are given on the subject line of your message. These commands are currently supported: help - get this information suggest - make a suggestion about the list selma-source - get the current source code to SELMA get msg N - send yourself message #N subscribe - add yourself to the list unsubscribe - remove yourself from the list No other commands are provided at this time. -SELMA --- BTW: Anyone made any improvements to SELMA that they would like to share? -jeff
[REBOL] best means of passing refinements from main to helper function? Re:(3)
> Howdy, Michael: > >The following approach is exactly elegant, but it gets I meant to say "ISN't exactly elegant"... sorry. That wasn't very elegant either! :) >the job done and it's fairly short. I think it's kind of >cute. -jeff
[REBOL] another parsing problem: converting dos filenames to rebol Re:
-jeff REBOL [ Title:"DOS-REBOL File Name Conversion Routines" File: %dosbol.r Author: "Terrence Brannon" Email:[EMAIL PROTECTED] Purpose: "Ease working with dos filename in REBOL programs" Category: 'file ] dosbol: make object! [ out: make string! 100 path-char: complement charset ":\/" rules: [ copy char path-char ":" (out: rejoin [ "/" char ]) | "\" (append out "/") | copy char some path-char (append out char) ] d2r: func [ dos-fn [string!] "takes a dos filename and converts to rebol format" ][ parse dos-fn [ some rules ] out ] ] dosbol/d2r "c:\temp\file" == "/c/temp/file" > Could someone please fix this? It hung my interpreter: > > REBOL [ > Title: "DOS-REBOL File Name Conversion Routines" File: > %dosbol.r > Author:"Terrence Brannon" Email: > [EMAIL PROTECTED] Purpose: "Ease workingwith > dos filename in REBOL programs" > Category: 'file > ] > > dosbol: make object! [ > char: make string! 0 out: make string! 0 > drive-letter: charset [ #"A" - #"F" ] > > rules: [ copy char drive-letter ":" (out: rejoin [ "/" > dl ]) | > "\" (append out "/") | copy char (append out char) > ] > d2r: func [ > dos-fn [string!] "takes a dos filename and converts to > rebol format"] [ >parse/all dos-fn [ any rules ] >out ] > ] > > >> dosbol/d2r "c:\temp\file" > > terrence-brannon: [[EMAIL PROTECTED] perl-refugee > myth-gamer] free-email: http://www.MailAndNews.com > free-usenet: http://www.mailAndNews.com ; all the above is > real REBOL code, believe it or not. > >
[REBOL] checking for localhost versus remote host Re:
Howdy, Terrence: my-box: "bluelightspecial" if my-box <> read dns:// [do-remote-trace-info] -jeff > I am writing a script and I only want the trace info created > and logged if the script is running on a remote machine, not > my own. > > Is there a programmatic way to check for what machine my > script is running on? > > terrence-brannon: [[EMAIL PROTECTED] perl-refugee > myth-gamer] free-email: http://www.MailAndNews.com > free-usenet: http://www.mailAndNews.com ; all the above is > real REBOL code, believe it or not. > >
[REBOL] best means of passing refinements from main to helper function? Re:(2)
Howdy, Michael: The following approach is exactly elegant, but it gets the job done and it's fairly short. I think it's kind of cute. -jeff REBOL [] deduction: func [ /use-month month-to-use /use-day day-to-use ][ rejoin [ "file-" either use-month [ month-to-use ] [ now/month ] either use-day [ day-to-use ] [ now/day ] ] ] main: func [ /use-month month-to-use /use-day day-to-use ] [ go?: func ['what /it][either it: get what [either true = it [what][it]][]] do reduce compose/deep [to-path [deduction (go? use-month) (go? use-day)] (go? month-to-use) (go? day-to-use)] ] > This seems to be an occasionally reoccurring topic. In > short I don't think anyone has come up with a simple > elegant way of doing this. A few of us have come up with > solutions whichinvolve building the helper-function > call/refinements string. You might find, however, that you > would rather use a bunch of 'if statements. > > - Michael Jelinek > > > > > > [EMAIL PROTECTED]@MailAndNews.com> on 09/15/2000 > 03:30:03 PM > > From:[EMAIL PROTECTED]@MailAndNews.com on > 09/15/2000 03:30 PM > > Please respond to [EMAIL PROTECTED] > > Sent by: Terrence Brannon <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] cc: Subject: [REBOL] best means of > passing refinements from main to helper >function? > > > I want to know the best way to propagate refinement > selections (or their lack) to a function which actually > does the processing for them.
[REBOL] parse question Re:
Howdy, Terrence: Neat stuff. Planning on making web page out of the result? > In order to improve my skills with the REBOL parse word, I thought I would go > through "Mastering Regular Expressions" by Jeffrey Freidl and do all the > examples in REBOL. Here is my first attempt and it does not work. [ . . .] > rules: [ > to "resetsize"(size-cmds: size-cmds -1) | to > "setsize" (size-cmds: size-cmds + 1) > ] > > proc: func [ filenames [block!] ] [ > foreach file filenames [ > size-cmds: 0 parse read to-file file rules prin > reform [ "in" file ": " ] either size-cmds = 0 [ > print "resetsize cmds matched # of setsize > cmds" > ][ either size-cmds > 0 [ > print "resetsize cmds > # of setsize cmds" > ][ print "resetsize cmds < # of setsize cmds" ] > ] ] > ] Try this: s-size: ["setsize" (size-cmds: size-cmds + 1)] rs-size: ["resetsize" (size-cmds: size-cmds - 1)] rules: [some [rs-size | s-size]] -jeff
[REBOL] Rebol Tech, please answer. Two questions. Re:(7)
> > REBOL doesn't want your fingers to hurt. > > But here I need shift for the semicolon, and "ALT GR" for > the square brakets (on the Amiga it's better, the [] don't > need shift on the keypad). :-( > > Should I buy an US keyboard? :) Wow-- why do all these international keyboards make everything so inconvenient to type? [Ducks and runs for cover] ;-) [Maybe the send key should be harder to hit on my keyboard (-:] -jeff
[REBOL] Rebol Tech, please answer. Two questions. Re:(9)
Howdy Elan: > Hi Jeff, > > whynotinclude anoptionalkey mapping for > system/ports/input? Perhaps system/ports/input/state/misc > could be used for this, if it is not already being used for > something else? > > Then the input of Umlaut characters could be replaced by > brackets before they are passed to REBOL for processing and > to the console output. I think sytem/console/keys is there for this kind of thing, but currently it doesn't appear to me that anything uses it. Aye Jim? -jeff
[REBOL] How do I dynamically extend an object! instance Re:(5)
> So this used-to-work but for reasons of our own protection
> has been made unworkable?
Right, what happens if you remove one of the values from the
middle of the value block? Do all the other words now point
to new values? What does the word at the end point at?
Likewise, adding a new word without a corresponding value.
> perhaps I should try another track...
Are you opposed to using blocks inside objects?
> most object based
> systems try to respect that an object should resist
> external change and only undergo transformation when
> initiated from within. you cant change an object unless it
> wants to change {reminds me of an old light bulb joke} or
> provides an access method to facilitate the change.
>
> can a function be made (within the object) that
> self-extends the object? what would that function look
> like?
Yes, using blocks.
obj: make object! [
a: [b: 2]
]
obj/a/b: 4
obj/a/b
== 4
append obj/a [c 6]
obj/a/c
== 6
etc..
If you were sadistic, you might use self modifying
functions. Here's a rather counter intuitive way to add and
remove refinements from an object:
fobj: make object! [
p-words: []
path: func refs: [/add what /remove who] body: [
either add [
path: func head insert refs to-refinement what body
append p-words what
][
either remove [
system/words/remove find p-words who
system/words/remove find refs to-refinement who
path: func refs body
][
foreach item bind p-words 'add [
print [item "==" get item]
]
]
]
]
]
fobj/add 'a
fobj/add 'b
fobj/remove 'a
Of course this isn't that much different from using
blocks, though, and you still have to add logic in the
body of the function to act on the activation of different
refinements.
Blocks are a much better and simpler way to go.
-jeff
[REBOL] How do I dynamically extend an object! instance Re:(3)
Bob: > ok here is my latest method for extending anobject > in-situ. the example hasnt been turned into a function and > I hope I am not violating any storage but here goes... [ > > a: make object! [ >addr: "417 howser st" name: "joyce haversham" ] > > wds: first a vals: second a > > append wds 'email append vals "joyce@someplace" > > probe a > > ] > > now this -looks- fine, you can save/probe/mold the object > and read it back in with no problems. FIRST obj and SECOND obj have returned copies of the object word and value blocks since last year or so. Modifying those blocks will not affect the original object. -jeff
[REBOL] Rebol Tech, please answer. Two questions. Re:(7)
Howdy Holger: > > REBOL doesn't want your fingers to hurt. > > The fingersof Americans anyway. German fingers are > supposed to hurt, I guess :-). Utilitarianism: Do the thing that will make the most people happy. If German keyboards were the most common, then I'm sure we'd all be programming in umlauts instead! (And you'd have to hit shift-alt-[ to get an umlaut on the less common American layout keyboard.. haha). > > Everyone essentially got the answer right-- A+! :-) > > Or "1+" in German grades. Of course everyone's grade for > "international awareness" would be a little lower :-). Allen did allude to other keyboard layouts of different nationalities. The Australians always get high points for international awareness. -jeff
[REBOL] Rebol Tech, please answer. Two questions. Re:(5)
As Carl once related to me: Semicolon was not picked because it's the LISP comment character, the square brackets are not in REBOL because they're found in FORTH, the reason for their use is based on their position on the keyboard (home row) and the fact that they are UNSHIFTED!! People will be typing these things ALOT so they'd better be conveniently located and easy to hit. REBOL doesn't want your fingers to hurt. That's just an indication of the attention to detail that is the REBOL standard. Everyone essentially got the answer right-- A+! :-) -jeff
[REBOL] Rebol Tech, please answer. Two questions. Re:(2)
Howdy Bob: > >Always creating a new object from the old one when I want > >to add a refinement doesn't appeal to me. > > it bugs me too, further it makes incorporation of that > object into some other(s) a chore to track if it is linked > in multiple places. > > does anyone have an elegant/quick way to see who refers to > an object? (IE who else has an == link to the same self' > value?) Here's a way: Every object has a block of referring objects and referred to objects. When ever you link to an object, you add yourself to that object's referring block. When ever you unlink, you remove yourself from their referring block. Etc.. a: make object! [referring: copy [] points-to: copy []] b: make object! [ referring: none points-to: reduce ['a a] append a/referring reduce ['b self] ] link-obj: func ['from 'to /obj1 /obj2][ obj1: get from obj2: get to append obj2/referring reduce [from obj1] append obj1/points-to reduce [to obj2] ] unlink-obj: func ['from 'to][ remove/part find obj2/referring from 2 remove/part find obj1/points-to to 2 ] Now you can: b/points-to/a/referring/b/points-to/a etc... So we're making a graph? Maybe start a "how do I represent graphs in REBOL" thread? :) By the way: The way we used the two blocks above is a general mechanism for easily adding and removing refinements to an object: foo: make object! [ a: b: none x-refs: copy [] ] Let's add 'c: append foo/x-refs [c 99] ;-- can also bind things into foo here foo/x-refs/c Removal is similarly easy: remove/part find foo/x-refs 'c 2 Blocks, the universal dynamic container, are best for things where you want to add and remove from frequently. In REBOL, objects are less dynamic than blocks. Use them together and make the world a better place. -jeff
[REBOL] Rebol Tech, please answer. Two questions. Re:(3)
Howdy, Kevin: (REBOL also uses international date standards.) > The language was obviously designed with this as a > conscious choice. I'm dying to know what the reasoning > was. That's a Q. only Carl can really A. He's been figuring out how REBOL should work for more than a decade and a half, so that question is pretty deep in the philosophy. What you say about deliberateness is true about most (but not all) things in REBOL. Here's two of those kinds of questions I know the "answer" to, but let's see if any one else has some ideas: Why is semicolon (;) the REBOL comment character? Why are square brackets ([]) used for REBOL blocks? What do the above reasons have in common? > Could it be possible that this way is more natural to me > only because I'm a native English speaker? Holger would probably do [answer :your-question 'yes] :-) -jeff
[REBOL] does REBOL run on Palm or not? Re:(5)
Howdy, Ryan: > > Under 20 ? I wish... Try 5 :-) > > You all deserve a raise. GRIN. to-money make hash! [] -jeff
[REBOL] Problem with newsgroup message count Re:(2)
> > When requestingnumber of messages for newsgroup
> > fr.misc.finance we got 100 ! although there are less
> > than 3000 messages. How can we cope with that ?
>
> The built-in nntp protocol (nntp://) appears to always
> return 100 as the length of the group.
>
> The external news:// protocol ('do %nntp.r) has a count
> command which looks like it correctly obtains article
> counters from the news server. However, I can't figure out
> the proper way to issue the count command via news://
> ... I'm copying this to Jeff directly (as the all-knowing
> master of the news:// protocol) to see if he can explain
> it.
>
> Cheers, Kev
yo:
The problem is news servers lie. One of the aspects of the
built in nntp handler is that it is supposed to provide a
series metaphor for a newsgroup, but we can't be assured of
total ordering of the messages there (many may be missing
from the total that is returned). This is as the nntp spec
goes-- since articles may be expiring at the time you
inquire. The count data returned from nntp servers isn't
supposed to be reliable, so the series metaphor is kind of
weak in this case (especially compared to pop:// for
instance). 100 was just an arbitrary large number for
the length of the port since it is indeterminable. Do you
think it would be better to have whatever the server said
about the message count there?
Anyhow, here's a post I made a while back that talks about
this issue and what someone might do to guarantee message
ordering, at least with nntp.r:
NNTP servers lie. They tell you a range of numbers of
articles that MAY be there. They may well not be there,
though. It's a funny thing.
The only way to really get the true number of articles in a
newsgroup is to get the headers for each article (which over
a 22kb modem 'aint always a good idea).
NNTP.r, as it is, also provides the optional NNTP "XHDR"
command which lets you quickly download just the subject
lines (or any other given header field: from, to, keywords,
etc..) of all the headers in the group. Having all the
subject lines, you can then know for sure (unless some of
those articles expire while you are reading) the count of
articles in a newsgroup.
One of the things NNTP does when it connects to a news
server is determine if it can do XHDR. Interactively you
can ask an open news port what it can do by inserting [help]
into the port. Here's how you can determine
non-interactively if the server you are talking to has XHDR:
np: open news://news.somewhere
found? find np/handler/commands 'xhdr
Using XHDR you can do something like the following:
np: open news://news.somewhere
set [total start end] insert np [count from "alt.test"]
x-mids: rejoin ["Message-ID " start "-" end]
message-ids: insert np [xhdr x-mids from "alt.test" please]
;- please is optional :)
The XHDR command gives you back a big string in a block.
Yes, that is a little odd (XHDR was added at the last
minute just to help aspiring news bot writers, if you want
to know!). The string you will find in the block has the
number of each article followed by the message id. It's
trivial to parse the string and it'll allow you to ask for
individual articles by their message-ids in order. There's
examples of getting articles by message id in the NNTP.r
howto. Using XHDR, you'll have an efficient way of
obtaining true newsgroup ordering with no gaps (for news
severs that support the feature ... If they don't well, you
probably have to fall back on getting all the message
headers in a group if you want to insure total
ordering... that's what Forte' free agent does!!).
Boy, nntp.r really is in need of an update. Looking at
NNTP.r it's doing all sorts of dialecting things by hand
that would be a lot easier to do today in modern REBOL with
things like parse block. The whole thing could be shrunk
by at least a half. So many things rattling around on our
overly loaded wagon trains...
[still need to get to that... arg.. too much stuff.. head
caving in... must.. alert the others... desk jobs sometimes
aren't "cushy".. but can be fun anyhow]
[REBOL] Challenging script idea Re:(6)
Howdy, Sterling: > If it's a GPF that takes down the universe, you would be > implying that we're all living in MS Universe 2000 or > something like that. Maybe that's why we die, eh? It's a > bug in the system. That theory sounds as good as any to me -- or maybe a bus error in the brain. If Microsoft created the universe, then we all know that there could be no heaven. "Welcome to heaven, click the start button to begin." Sounds like hell to me. -jeff
[REBOL] /deep versus /only Re:
Just to throw in some more commentary from "the boys" :-) : The /only refinement is used for more than just referring to nested blocks. It means to consider the item in question as a single series type, instead of as a bunch of separate items. Change/only means to apply the changes as a single series, and not as individual items, for example: >> ser: ["str1" "str2" "str3"] >> change ser [1 2] >> ser == [1 2 "str3"] ;-- CHANGE took the 1 and 2 and applied the change ; to ser like two separate changes. >> ser: ["str1" "str2" "str3"] >> change/only ser [1 2] >> ser == [[1 2] "str2" "str3"] ;-- Change/only took the [1 2] and thought of it as a single ; value which it changed the first value of ser to. The /only refinement is like saying "There's ONLY one value here, not many values". "Deep" really is very different. -jeff > Thought you would like to hear what "the boys" have to say > about /deep versus /only > > > - Forwarded Message - > > DATE: Mon, 28 Aug 2000 17:21:39 From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > > > princepawn, > > The /only refinement is used for a block nested within > another block. The /deep refinement is used for recursing > through any number of nested blocks. > > This may not sound like much of a difference, but it is > felt that the difference is sufficient enough to note by > two different refinements. > > If you have any additional questions/comments/suggestions, > please let us know! > > REBOL Support --
[REBOL] Rebol - The Official Guide Re:
Howdy Andrew: > Finally got my copy. It's nice to see my name in it. That's now the second > book my name is in. :-) > > Just a note to Elan, if there's a second edition, the two > lists of name on page xvi need to be swapped. It really is pretty fitting, though, you know. RT's motto is that the users always come first! (-: -jeff Proud rebol mailing list member since 1998
[REBOL] recent experimental core builds
Brief notes on items found in the latest experimental versions: Serial port support under windows and unix (others are being added as we go along..) Tcp ports are now asynchronous. If you want the "old" behavior, you need to do OPEN/wait, ie: tcp-port: open/lines/wait tcp://example.com:80 (Jim said he'll come along and say more about some changes to ports...) LOAD has a new refinement: /ALL -- this will ignore REBOL headers when loading. The current and previous experimental versions use the new command line argument passing scheme. There have been a number of bug fixes here and there as well. See if *your* favorite bug is still in there! :-) For lack of any better current documentation on these new features, below are our REPs for the new serial ports, the change in command line passing, and the new LOAD/all refinement. I did not make them into attachments. Hope you all don't mind. -jeff -- REBOL SERIAL PORT SPECIFICATION REBOL Enhancement Proposal: REP004 Version: 1.0.1 Author: Jim Goodnow II ===PURPOSE This specification describes the creation and operation of serial communication ports within REBOL. ===CREATION Serial ports are created in the same manner as other ports within REBOL. The scheme name for serial ports is "serial:". The specification of a serial port may include the device number, the communication speed, the number of data bits, the parity and number of stop bits. The specification information can be specified directly by setting the appropriate fields within the port specification object or by creating a URL which contains the same information. Any field not specified will be given a default value. The default values are: device: port1 speed: 9600 data bits: 8 parity: none stop bits: 1 URL's are encoded with the different fields separated by slashes. For example, serial://port1/9600/8/none/1 The order of fields is not significant, as the type of field can be determined by the content. Within a port specification, the various parameters are stored in the following object fields: host: device speed: speed data-bits: data bits parity: parity stop-bits: stop bits The portN specification is an indirect reference to the communication device. It refers to the Nth device defined in the System/ports/serial block. This block is initialized by default depending on the system being used and can be modified in user.r to reflect any local requirements. For example, on Windows the block might be defined as: System/ports/serial: [ com1 com2 ] or if COM1 is being used by the mouse, it might just be: System/ports/serial: [ com2 ] On unix-style systems, the block might be defined as: System/ports/serial: [ ttyS0 ttyS1 ] or if the first device should correspond to COM2: System/ports/serial: [ ttyS1 ttyS0 ] Thus, the ports can be specified in a machine indpendent manner while the machine specific definition can be controlled using the serial definition block in System/ports/serial. ===OPERATION Serial ports are always opened as direct ports in much the same way as console and network ports. They may be opened as either /STRING or /BINARY with the default being /STRING. They are opened by default as asynchronous, but may be made synchronous by using the /WAIT refinement. When operating asynchronously, any attempts to copy data from the port will return NONE if no data is present. When operating synchronously, the copy will block until data is available. Data can be written to the port using the INSERT native. Data can be read from the port using the PICK, FIRST or COPY natives with the usual ramifications. As usual with direct ports, the REMOVE, CLEAR, CHANGE and FIND functions are not supported. The UPDATE function can be used to change port parameters. For example, to change the speed after an initial connection has been established, you could just do: ser-port: open serial://9600 ser-port/speed: 2400 update ser-port Changing the device number or the System/ports/serial and calling UPDATE will have no effect. Once the port has been opened with a particular device, the device can't be changed. There are two additional port fields that can't be set with a URL, but can be set in a port specification block or by manually changing them. The RTS-CTS field specifies whether hardware handshaking should be used on the port. The default is ON. To change the default, do: ser-port/rts-cts: off update ser-port A timeout value can be specified by modifying the timeout field in the port structure. The timeout value only applies to serial ports that are opened with the /wait refinement. When the timeout expires, a serial port timeout error will be generated. To set the timeout value do:
[REBOL] A small security hole REBOL, and a huge one! Re:(6)
Howdy, Brian: > >The security risks of modifiable REBOL code will be best > >dealt with by modules. Untrusted REBOL code can evaluate > >in a module prevented from affecting the surrounding > >execution environment. > > I'd be curious to see how that is done. The current module > spec doesn't prohibit the kind of change to the code of the > mezzanine functions that I outlined, nor the hacks > involving changes to the specs that Ladislav mentioned. The current spec doesn't directly address this issue, but essentially the idea is that modules will provide secure execution environments. It's a deep question, and one that the final design will address. I'm looking forward to the "answer" myself. > The problem with the current module spec is that once you > make a function visible inside a module so that it can be > used there, that function can be modified. Maybe, and maybe not... :-) > Don't misunderstand, I'm as much a fan of self-modifying > code as the next mad scientist - it's just that I'm willing > to give up modifiable functions for security reasons. We > should be able to get by with replaceable functions, since > we can easily track assignment if we want to. If we still > need self-modifying code we can still do blocks. Insightful observations, Brian. > >Besides, only goodhackers use REBOL!;-) Why would > >someone be so evil as to makegood little REBOL do > >something bad?! (-; > > A jealous Perl enthusiast, perhaps? :-) Ditto. (-: -jeff
[REBOL] spaces in file names Re:(3)
Howdy, Andrew and Fantam and all: > >>> to url! join ftp://usr:[EMAIL PROTECTED]/ %"test/test > >>> test.txt" > > == ftp://usr:[EMAIL PROTECTED]/test/test%20test.txt The to-url is redundant, actually: join ftp://ftp.example.com/ %"spaces in file.txt" == ftp://ftp.example.com/spaces%20in%20file.txt You can also do: site: ftp://ftp.example.com/ site/%"spaces in file.txt" == ftp://ftp.example.com/spaces%20in%20file.txt Above is handy if you're doing a number of files. > > I hope that helps! > > > Andrew Martin ICQ:26227169 > > http://members.xoom.com/AndrewMartin/ > ->><- > > -- > Fantam
[REBOL] A small security hole REBOL, and a huge one! Re:(4)
Launch, at least in its present form, will not likely be in the regular distribution. It went out in the windows view version by accident. The security risks of modifiable REBOL code will be best dealt with by modules. Untrusted REBOL code can evaluate in a module prevented from affecting the surrounding execution environment. Besides, only good hackers use REBOL! ;-) Why would someone be so evil as to make good little REBOL do something bad?! (-; Just goofin' -- head reverse mold disarm catch reduce [ func [[throw]][throw-on-error [no flames]] ] -jeff > Hi, > > the following code was posted by me some time ago and the > principle was sent to feedback too. Here it is again: > > protect'secure system/error/script/type: "" > system/error/script/expect-arg: [ > ( > change pick third :secure 3 reduce [word! block!] > secure allow "I love you" > ) > ] change pick third :secure 3 reduce [unset! none!] > > ; the results are: > > >> secure throw > ** : I love you. Where: secure throw > >> secure [] > == [net allow file allow] > > Regards > Ladislav > > - Puvodní zpráva - > Od: <[EMAIL PROTECTED]> Komu: <[EMAIL PROTECTED]> Odesláno: > 21. srpna 2000 0:59 Predmet: [REBOL] A small security hole > REBOL, and a huge one! Re:(2) > > > > Ladislav, > > > > Can you provide some example code that demonstrates this > security hole. > > > > Paul Tretter > > > > -Original Message- From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 20, > > 2000 5:43 PM To: [EMAIL PROTECTED] Subject: [REBOL] A small > > security hole REBOL, and a huge one! > Re: > > > > > > Hi Brian, > > > > the problem is, that even the natives are mutable, as can > > be > seen > in Mutable natives thread. > > > > Regards > > Ladislav
[REBOL] command/mySQL Re:
Howdy, Hendrik-Jan: > Dear List, > > I was wondering if someone has tried to let rebol/command > use the %libmySQL.dll from MySQL. > > at the moment i can get several routines working > (e.g. connecting to MySQL, getting stats, create database > etc) > > but, i am failing to get to the 'real' stuff Which API functions are you finding problematic? -jeff
[REBOL] Anyone doing something with LDAP? Re:(2)
When your dealing with LDAP, you have to first deal with BER (basic encoding rules -- a subset of ASN.1 -- abstract syntax notation, spec 1). This is a binary TLV (Type Length Value) encoding scheme for sending "self describing" objects around the network. The implementation details are a little hairy, but one of the motivations for expanding support for manipulating the binary! datatype in REBOL was in consideration of things like BER. If you create a BER.r script (which should only take as long as it takes to understand BER, and maybe a day or so to implement it) then it will also help someone to create SNMP which also uses BER. Another way to do it: REBOL/command can import an API implemented in a shared library, such as Netscape's LDAP sdk. -jeff > There is a free LDAP perl/cgi script called > LDAP express at http://www.browserexpress.com/LE-Features.shtml > > It looks like about 7 or 8 pages of perl -script. It can > be translated to REBOL, but also looks like it depends on > some other serious looking perl mods (.pm files). > > Anybody, know of some other sources that maybe could be > translated into REBOL? or any better ideas? > > > > -Original Message- > From: Vos, Doug Sent: Tuesday, July 25, 2000 2:49 PM To: > [EMAIL PROTECTED] Subject: [REBOL] Anyone doing something with > LDAP? > > > Has anyone put together any scripts using LDAP? > > LDAP (light-weigt directory access protocal) > > There was some talk of LDAP going into /command at one > time. > > - Doug
[REBOL] Words, Bindings and Contexts. (5) Re:
I've always thought that someone could use REBOL/view to
create an animated colored map presentation which
demonstrates the nature of contexts...
-jeff
> In the part 4 I forgot to introduce a special kind of Contexts:
>
> f) Dangerous Contexts. Example:
>
> f: func [x] [] special-context? first first :f
>
> CRASH
>
> I obviously cannot claim that Same-context? works in this
> case.
>
> Now I supply another interesting function:
>
> ; actually, Thomas Jensen was first there (nice work), but
> ; this
> functionis able tofind eventhe Unset Words
> context-words: func [
> {returns all Context Words of a Word's Context} word
> [word!] /local result c-word
> ] [
> either special-context? word [
> ; we are out of luck in this case
> none
> ] [
> result: copy [] foreach g-word first system/words [
> if not same? g-word c-word: bind g-word word [
> append result c-word
> ]
> ] result
> ]
> ]
>
> to be continued...
>
>
[REBOL] know bugs - how to get? Re:(5)
Howdy, Tim: What you're saying works for me. I'm sorry if what your seeing from RT appears as unresponsiveness to issues like publication of bugs, but these issues are a matter of policy which myself and the other developers don't really have anything to do with. We're the ones always yakking on the list but our sphere of influence is really just in matters directly related to the production of code (which unfortunately will contain an occasional bug (-:) Whether the approach you and Ted are suggesting is best is not for me to say. But if there is popular consent that we're picking the wrong route in some of our practices.. well... What the community says is often going to have a greater influence than what the developers say. You are all doing _us_ a favor by telling us when you think we're goofing it. So, if you folks see us missing the boat, keep letting us know (please: in a nice, reasonable, and non flaming way). Someone's always bound to answer a ringing phone, so to speak. I don't know that that's a satisfactory answer, but that's just more or less my frank opinion. Surrender? We have not yet begun to fight! -jeff > ... which is why I'm CC'ing Jeff on this, because I'm really > having a hard time getting a response from rebol folks on > this matter, and I think that they would jump at such an > opportunity and give me some feedback. > > BUT: (Sorry to shout here, I'll try to keep my voice > softer). I've submitted several bugs myself and I'm myself > rather appalled that rebol isn't addressing these more > openly. > > It is a truism that is older than the Internet that people > respect you more when you are honest about your > shortcomings. > > Rebol guys and gals: Lissen 'up here.!! Stomp out those > bugs that you can and post the rest of them. > > You will be rewarded for it, in the long run. There are > more watching you than you know, and you also have made a > lot of friends. Those friends can help. > > Best Wishes -Tim
[REBOL] know bugs - how to get? Re:(3)
I, for one, truly appreciate what you are saying Ted. Sometimes the issue for RT is man power -- balancing spinning plates on sticks can keep everyone pretty busy. :-) Automation is the key. We've been working recently on some internal automations to help us address this "active development" question that you mention. Stay tuned and keep the faith! -jeff > Personally, I've always felt that this is a strategic > error. > > I think the fact that REBOL.COM doesn't mention bugs, or > offer a standard knowledgebase, makes it look like a beta > site. (Hasn't been out long enough to generate reports -- > or no one's using it long enough to find them!) > > Every active software project has defects. The difference > between the good projects and bad projects is whether they > get fixed. Looking at the REBOL site, there's not a lot to > show someone that that the language is being actively > supported. > > Of course, those of us on the list know better, but you > shouldn't have to wade through all this for bug reports. A > strong knowledgebase would save a lot of debugging time, > and keep new users from being frustrated too early. > > http://bugs.perl.org/http://www.python.org/python-bugs/ > http://developer.java.sun.com/developer/support/ -- option > for Bug database http://bugzilla.redhat.com/bugzilla/ > > To name a few. > > -Ted.
[REBOL] know bugs - how to get? Re:
Howdy, Volker: At one time we kicked around the idea of a WAK. A WAK (We Already Know) unlike a FAQ would be something like a list of known bugs, but a little broader like covering certain common usability issues that people encounter. I can't remember the whole definition we came up with, but to answer your question (sorry for my longwindedness): No, there's presently nothing like that other than searching the mailing list archives for a description of your bug or asking Bo at [EMAIL PROTECTED] -jeff > can i get a list of the feedback - "known bugs" somewhere? > > Volker
[REBOL] /core 2.3 cli-args changed - bug?! Re:
Yes, sir. Unfortunately a known bug. Please use FIRST or FORM as a work around in the meantime until the next release. -jeff > What happens to command-line-arguments (on linux)? 1) i > get now the string in a block 2) the space immediate after > the command is included as argument. > > bugs or hidden sense? before i simple used [to file! > system/options/args] > > demo: ;with rebol[file: %showargs.r] print[mold > system/options/args"->" moldto file! > system/options/args] quit > > ;the shell-script: > rebol-22 -q showargs.r a-filename rebol-23 -q showargs.r > a-filename rebolv -q showargs.r a-filename > > ;gives > "a-filename" -> %a-filename [" a-filename"] -> > %%20a-filename ; ?!?!?! "a-filename" -> %a-filename > > Volker > >
[REBOL] CGI saftey -- was (New REBOL Networking Document) Re:
Howdy, Petr:
Reducing or DOing the decoded cgi-query block is not
the recommended approach. That method allows the world
to assign arbitrary words in your script to strings.
Imagine this REBOL cgi program:
#!/path/to/rebol -cs
REBOL []
print "Content-type: text/html^/"
reduce decode-cgi system/options/cgi/query-string
;- Expecting user to be passed in
page: [print reform ["Hello" user]]
do page
quit
See the danger? I can go up to my browser and type in
this url:
http://site/cgi-bin/script.r?page=send+me@somewhere+allyourfiles
Of course, you can still be perfectly safe if the
script establishes a sensible sandbox with SECURE, but
the point is you don't want the outside world to be
able to globally define words to strings in your CGI
script. If, in the course of your CGI script, those
strings could ever get interpreted as code then anyone
can make your script DO arbitrary code.
By making the query block into an object, this problem
is completely avoided. REBOL CGI script writers
should be aware of this issue. REBOL provides
powerful tools to make REBOL cgi scripts air tight
secure, but if the script lowers the shields then
REBOL can't help you. :-)
Cheers--
-jeff
> 8) as for cgi - another option could be added - when not
> creating object out of query-string, we need to 'reduce
> block to get its words loaded. My friend struggled with
> that one, as molded value of block seemed to him everything
> is ready :-)
>
> Later, -pekr-
[REBOL] Rebol's argument handling is broken Re:(5)
Howdy, Sean: > Jeff, > you seem to be missing the point by comparing REBOL to grep. Point taken. Not arguing or debating, was just offering up another program that works like REBOL does now. There are many aspects of REBOL that we're working on improving. Appreciate all the feedback. -jeff
[REBOL] Rebol's argument handling is broken Re:(3)
> This bit me too. Rebol apparently parses everything that looks like an > option on the command line, not just up to the script name. > > I consider this a bug and not a feature. > > Garold (Gary)L. JohnsonDYNAMIC Alternatives > [EMAIL PROTECTED] Grep works similarly as REBOL currently does, considering arguments preceded by - to be switches regardless of where they are placed. For example: Before and after args: grep -A 3 foo * -vi In between and after args: grep foo -B 10 *.txt -A 20 -jeff
[REBOL] stdin type? was: impossible email dream Re:(2)
> message: import-email stdin: copy system/ports/input > > and I get: > > ** Script Error: import-email expected data argument of > ** type: string. Where: message: import-email stdin Sure enough.. you wind up with a block of lines from stdin. try: message: copy "" stdin: copy system/ports/input foreach line stdin [append message append line newline] message: import-email message sorry for any confusion -- -jeff
[REBOL] stdin type? was: impossible email dream Re:(2)
> message: import-email stdin: copy system/ports/input > > and I get: > > ** Script Error: import-email expected data argument of > ** type: string. Where: message: import-email stdin > > So I did: > > stdin: copy system/ports/input > > print type? stdin > > And it's a block... How did this work for you? Sure enough.. you wind up with a block of lines from stdin. try: message: copy "" stdin: copy system/ports/input foreach line stdin [append message append line newline] message: import-email message
[REBOL] code as data Re:
foreach [condition action] code [ if all condition action ] or.. if any condition action -jeff >I want to evaluate a block of code like the following : > >code: [ [condition1][action1] [condition2] [action2] >[condition3] [action3] ] > >forskip code 2 [if do first code [do second code]] > >The above works only when [condition] has one value. My >actual code is : > > code: [ >[condition1a [condition1b]][action1] [condition2] >[action2] [[condition3a] [condtion3b] condition3c] >[action3] ] > > >Any idea ? > > -- > [EMAIL PROTECTED] http://perso.worldonline.fr/mutant
[REBOL] Rebol's argument handling is broken Re:(4)
Howdy, Sean: > 2) the Rebol developers (if jeff is representative) aren't > aiming at any kind of cross platform compatibility except > within Rebol itself, or this issue would have surfaced long > ago. There also seems to be a bit NIHilism (Not Invented > Here-ilism) regarding making Rebol work the way that people > experienced in other environments might expect. Naw. Be patient. These things are still evolving. Under windows and mac we have drag and drop support for scripts, and we arrange associations so you can start a script by double clicking on it. Similarly, we should expect REBOL in unix environments to follow suit with the way other applications fit in. It was my own concern with improving the way REBOL operates from the command line that set me off on exploring this issue to begin with. As a result, I've gotten a lot of good feedback from people (thanks) and the info is being formulated into improved arg handling which (hopefully) will meet all our needs and make us all happy. Cheers-- -jeff
[REBOL] Rebol's argument handling is broken Re:(2)
> I note that REBOL doesnt pass on all the command line args > anyway. See example below. This - along with all the > escaping nonsense suggested earlier - means that it looks > impossible to use REBOL to implementsomething with a > predefined command line syntax. > > I have C, C++ and Delphi command-line programs that work > with identical command line args, containing switches like > -v etc, and was hoping to write REBOL equivalents, using > same arg convention. > > Is REBOL not a suitable language for this kind of task? > (REBOL newcomer, not yet sure what its good for). > > Sean Howdy, Sean: If you pass items beginning with a dash (-switch) as arguments to the script, how would you suggest REBOL find it's own command line switches? -jeff
[REBOL] Rebol's argument handling is broken Re:(5)
Okay, so let me see if I can tie everything together: 1) What's really wrong with DOing formed strings? Well, besides the inefficiency factor (and every little bit counts -- lots of little inefficiencies pile up...) there's also a base philosophical issue. Can I get away with just saying that "DO FORM block" is sort of unREBOLish? 2) What about cluttering the system object? When you start something from the command line, both system/script/args and system/options/args are set to the same args. (Remember that system/script/args is what's used for DO/args). By making one of the two slots a block of the separate arguments, we'll actually be lowering the redundancy of information in the system object for from the command line case. The caveat, of course, is that which ever form of the args goes in system/script/args on boot up, that data will be clobbered by DO/args so the programmer will need to ferret it away if they want it later on-- but everyone should be able to live with that... 3) What do people want DOable args for? It's part of better command line integration. Below is a little example of the use of DOable args. I call the script "reb" and put it in my private bin/ directory: - #!/path/to/rebol -qs REBOL [File: %/home/me/bin/reb] random/seed now print do system/options/args - Using the above script opens up lots of possibilities. From the command line you can do stuff like this: ## Quick command line calculator reb "1 + 2" ## Help create filenames -- nicer than using unix 'date' command cat log > log`reb now/date`.txt ## pick a random file foo=`reb x: read %. prin pick x random length? x` ## dump mail to file reb read pop://me:pass@site > mail-box The possibilities are endless. REBOL one liners really can be handy from the shell. You can mix in a little bit of REBOL into shell expressions and you get a pretty swell enhancement to life in the process. :) Any other args, pro and con welcome. I'll put the whole thing together into a "Request For Enhancement" and nail it to Carl's door.. (; -jeff
[REBOL] Writing to a half-byte Re:(2)
Just FYI: Recent REBOL's include the ability to perform
bitwise operations on binary types using AND, OR, and
XOR. -jeff
---
nibble: func [
a [binary!] "Binary Byte"
b [integer!] "0-15" /high
][a or to-binary to-char either high [b * 16][b]]
comment [
nibble/high #{01} 15 == #{F1}
nibble #{10} 15 == #{1F}
]
> >In Assembler class we called a *niblet*
> >the lower- or higher- order 4 bits in
> >a byte. I'd like a function that would
> >would write a niblet in a char! type.
> >It would something like this:
> >
> > >>niblet/low #"a" 2; write 0010 to low-order "niblet"
> >==#"b" ; changed low-order "niblet" = 2
> > >>niblet/high #"b" 7 ; write 0111 to high-order "niblet"
> >== #"r"; r is ascii 72
>
> Well, this function is kinda ugly and could probably be
> done MUCH better, but it works:
>
> niblet: func [ base new /low /high ] [
> either high [
>or~ (and~ base to-char 15)
> to-char (16 * to-integer and~ new to-char 15)
>][ or~ (and~ base to-char 240) (and~ new to-char 15)
>]
> ]
>
> I've been meaning to write decent functions for doing
> binary manipulations in REBOL but I haven't had time yet,
> but when I do I'll post them on rebol.org (and maybe to the
> list)
>
> Hope this helps,
>
> Cal Dixon ([EMAIL PROTECTED]) -><-
>
> >This is for a high-school course that I'm designing as an
> >intro to programming using rebol.
> >
> >Thanks: -Tim
[REBOL] Rebol's argument handling is broken Re:(3)
Howdy, Jake: > 1) How many people are going to *want* an immediately DOable > REBOL expression? Lots of people! ;-) > Maybe I'm missing something, but what about FORM? For > example, assume I pass this to my script: DOing formed blocks is sort of inelegant. You're taking a REBOL data structure, a block, and then turning it into a string. By the DOing the string the interpreter actually turns the string back into a block of REBOL data types before evaluating it. It's not very optimal. Just DOing the original string ends up being half as much work. I do agree with what you're saying, though, about the need to distinguish command line args. Believe me-- I want REBOL to excel at command line integration as much as the next guy! Another idea that was brought up was that you could have more than one view of the command line args available, so those that want the separation of args would have it in a block somewhere, and those that want just a doable string would have it somewhere else. Best of both methods approach. Would that work for us disgruntled REBOL command liners? (-: Command-linely yours, -jeff
[REBOL] Rebol's argument handling is broken Re:
Howdy, Jussi:
[arg passing]
> As this probably is the suggestion already discussed and
> turned down I would like to hear the reason and a work
> around for us, who use spaces in filenames.
The argument passing scheme for REBOL needs to address two
things: 1) Providing args from command line, of course
and 2) providing an immediately DOable REBOL expression.
With just a string for command line args, the second case
is easy-- just do the system/options/args. In the first
case there are situations where the distinction between
args is unrecoverable, however you can force distinctions
using escaped quotes, eg:
\"first arg\" \"second arg\"
or
{first arg} {second arg}
Using escaped quotes or curly braces on command line args,
you can create needed delimiters that can be broken up in
your script using PARSE, for instance.
If you get a block of separate args in strings then the
result is not easily DOable. The alternative is to have
the args prescanned (essentially the LOAD of the command
line args). The prescan creates a potential for
syntax errors in the command line arguments preventing a
script from running. That's not very advantageous.
In the end, it was decided the best course of action was
to leave it as it is because people COULD make delimiters
using shell escaping measures and what not.
So that's what the reasoning was. Make sense?
-jeff
[REBOL] impossible email dream Re:(2)
Boy, guess I'm a little absent minded these days (too much on the mind): Here's a more correct version of the example mail filter I sent... -jeff > #!/path/to/rebol -qws > REBOL [ > Title: "Mail filter" > ] > > stdin: copy system/ports/input > message: import-email stdin > > foreach [item file][ > "REBOL" %rebol-box "Debian" %deb-box "me" %me-box > ][ > if find item message/content [ > write/append file stdin exit > ] > ] write/append %default-box stdin > > quit ;-same thru REBOL header ;- saves a step message: import-email stdin: copy system/ports/input foreach [item file][ "REBOL" %rebol-box "Debian" %deb-box "me" %me-box ][ ;- the args to find were backwards if find message/content item [ write/append file stdin QUIT ;- instead of exit (not in function) ] ] write/append %default-box stdin quit
[REBOL] impossible email dream Re:
Howdy, Tom:
Say you run a REBOL script from a .forward:
| /path/to/filter.r
then executable script filter.r might look like this:
#!/path/to/rebol -qws
REBOL [
Title: "Mail filter"
]
stdin: copy system/ports/input
message: import-email stdin
foreach [item file][
"REBOL" %rebol-box
"Debian" %deb-box
"me" %me-box
][
if find item message/content [
write/append file stdin
exit
]
]
write/append %default-box stdin
quit
{
Of course you can filter on message/subject,
message/to, message/from, etc...
The principle is the same using pop, but you use a pop
port to retrieve the mail and you need to export messages
you take from pop back to mailbox format (easy).
-jeff
> howdy guys,
>
> I have this crazy idea that I can use REBOL to filter my
> mail to different files as I receive it. Ok, starting with
> this:
>
> match: ["REBOL"
> "Debian"
> "me"
> ]
>
> I'm gonna wing it, here:
>
> no I'm not, either. can someone give me a hint?
>
> thanks, -tom
}
[REBOL] Parse differenece in Core 2.3 Re:
> I have a script which works under Core 2.2 but fails under 2.3: > > The problem appears to be in the way I use parse, but I > cant see what is wrong, particularly since it worked > under 2.2 > > Thanks, > > Garold(Gary) L. Johnson DYNAMIC Alternatives Try: print mold system/options/args 2.3 contains a goof with how the command line args are passed. What once was a string is now a block containing a string. Yeah I know: that's silly. The change slipped in there by accident while the args passing mechanism was being revamped. (The args passing mechanism used to have a size limitation. While that limitation was being fixed there was a proposed plan to change the args string to a pre-scanned block. However, that plan was decided against but some intermediate code was accidently left in. Yours truly is the one to blame for the blunder.) The next version will correct the arg passing behavior back to the old style. Your script should work again with you do: first system/options/args My apologies for any command line inconveniences. -jeff
[REBOL] REBOL and the unix shell Re:(2)
Sorry. It was taken down as it is being considered for a pubication.. Will deliver news about it soon.. -jeff > > [...] I put up an article I wrote this weekend [...] > > > > http://www.cs.unm.edu/~whip/rebol-unix-shell.html > > Hi Jeff, > > I know I am late, but it really would be nice to read > that. It seems that the article has been censored from the > site :) > >Forbidden > >Youdon't have permission to access >/~whip/rebol-unix-shell.html on this server. > > > -- > Jussi Hagman CS in Åbo Akademi University Studentbyn 4 D 33 > [EMAIL PROTECTED] 20540 Åbo [EMAIL PROTECTED] Finland > >
[REBOL] func[func] Re:(5)
Howdy, Galt: > Galt wrote: make-adder: func [x] [func [y] [+ x y]] > > I am guessing that the problem is that there is only one > copy of the block [+ x y] and that it has a context, > whatever that is, and that it can only have one context, > and that one gets changed everytime you run make-adder > again with a new parameter value for x. So running > make-adder a 2nd time messes up the value hidden in the > context of the first? There's only one context for make-adder where the value for x is looked up in your returned adder function. You'd need to create a new context for each x. You'll also need to keep those contexts around to be GC safe. Here is one possible way of creating these functions based solely on contexts: save-em: copy [] make-adder: func [x][ get in last append save-em make object! [ z: x f: func [y][+ z y] ] 'f ] The above creates new contexts to hold the different values of X in your separate add functions. (It also creates new functions that use those X values). -jeff
[REBOL] [ANN] 2KB News Reader 0.1.1 Re:(3)
Howdy, Ryan, and others interested in REBOL's nntp.r: NNTP servers lie. They tell you a range of numbers of articles that MAY be there. They may well not be there, though. It's a funny thing. The only way to really get the true number of articles in a newsgroup is to get the headers for each article (which over a 22kb modem 'aint always a good idea). NNTP.r, as it is, also provides the optional NNTP "XHDR" command which lets you quickly download just the subject lines (or any other given header field: from, to, keywords, etc..) of all the headers in the group. Having all the subject lines, you can then know for sure (unless some of those articles expire while you are reading) the count of articles in a newsgroup. One of the things NNTP does when it connects to a news server is determine if it can do XHDR. Interactively you can ask an open news port what it can do by inserting [help] into the port. Here's how you can determine non-interactively if the server you are talking to has XHDR: np: open news://news.somewhere found? find np/handler/commands 'xhdr Using XHDR you can do something like the following: np: open news://news.somewhere set [total start end] insert np [count from "alt.test"] x-mids: rejoin ["Message-ID " start "-" end] message-ids: insert np [xhdr x-mids from "alt.test" please] ;- please is optional :) The XHDR command gives you back a big string in a block. Yes, that is a little odd (XHDR was added at the last minute just to help aspiring news bot writers, if you want to know!). The string you will find in the block has the number of each article followed by the message id. It's trivial to parse the string and it'll allow you to ask for individual articles by their message-ids in order. There's examples of getting articles by message id in the NNTP.r howto. Using XHDR, you'll have an efficient way of obtaining true newsgroup ordering with no gaps (for news severs that support the feature ... If they don't well, you probably have to fall back on getting all the message headers in a group if you want to insure total ordering... that's what Forte' free agent does!!). Boy, nntp.r really is in need of an update. Looking at NNTP.r it's doing all sorts of dialecting things by hand that would be a lot easier to do today in modern REBOL with things like parse block. The whole thing could be shrunk by at least a half. So many things rattling around on our overly loaded wagon trains... :-) Hope that info may be useful on your projects. -jeff > As for the message count, that seems > screwed up, too, because I always end up reading fewer messages than what the > nntp.r returns. > > I'm not sure if trying to fix this would be more than just > butting heads with nntp.r which may have some issues. > > >Pretty impressive. It's about time someone made some > >public use of NNTP.r. I found one problem, it either > >reports the wrong number of messages available or else it > >can't always find the next message. After 3 or so > >messages, if I press "n" for next message, I just get the > >instructions again for each time I press "n". > > > >Cheers, > > > >Allen K
[REBOL] XMLRPC Re:
Hearty pat on the back for Thomas Jensen! A number of people have expressed an interest in XML-rpc and they ought to be happy to hear of your efforts. > Hello, > > I am in the process of creating a XMLRPC framework for > REBOL, according to the specs at http://www.xmlrpc.com/ > > currently most of the marshalling is done, and I'm able to > actually call a procedure on thier test server and get back > a result. > > > > > Best regards Thomas Jensen > >
[REBOL] Ping Tool Re:(4)
> "I believe IRC uses UDP which should be fully supported > very soon." - Those were the words of Bo some time ago :-) Nope, it's TCP/IP.
[REBOL] Ping Tool Re:(5)
Petr quoting me:
> For some reason
> it doesn't seem possible to create a udp listen port,
> though.
In view you can see that udp listen ports are working:
;-- UDP listen and send --
x: open udp://:9090
close insert open udp://localhost:9090 "hello udp!"
y: wait reduce [x 1]
copy y
== "hello udp!"
-jeff
[REBOL] A data inconsistency Re:
It's a problem with the declaration of CHANGE, like this: f: func [x][] g: func [x [any-type!]][] >> f ** Script Error: f is missing its x argument. ** Where: f >> g >> > Hi, > > did anyone report The following? > > >> head insert copy [] () > == [unset] >> change copy [1] () ** Script Error: change is > missing its value argument. ** Where: change copy [1] () > > Ladislav > > >
[REBOL] Curious Re:
Howdy, Deryk: > Now, knowing that index.html is _usually_ the desired > target, it isn't _always_ the target itself. Index files > can be almost anything the web server has support for, > i.e. .php, .php3, .asp, .shtml, etc. Why was this chosen > to be a fillin and not what the server itself returns to be > the _actual_ target? Yup. That's a bug. I forwarded your message to feedback so it will get put into our Rebol Automated Master Bug Organizer. I'm surprised that that one hasn't shown up before for someone... or maybe it did and they didn't realize what was happenening. -jeff
[REBOL] No longer dangerous (use of) Secure Re:(3)
Howdy, Ladislav:
You really ought to write up a little explanatory
article for that, how you created a separate execution
context for the untrusted code, why you needed to do a
double bind, etc.
In briefly studying your script, I didn't spot any real
dangers of the untrusted script being able to escape
its secure context and modify the top level context.
If there is that sort of danger what is it?
One principle "danger" involved with executing
arbitrary REBOL code is that an untrusted script might
never finish executing. While not dangerous to your
files or the security of your computer, this could be
an annoying drain of CPU cycles. Of course, the way
security works now, a human operator has to okay
lowering security transitions so that same person can
hit escape if the untrusted script seems to be
endlessly looping. :-) For non-interactive setups, you
could write a file before doing a script and remove it
when the script is done. A watching process may
shutdown and restart the REBOL process if it sees that
the timestamp on the "I'm going to do a script" file is
older than a certain predetermined age.
Moral of the story? There are always inherent risks in
arbitrarily executing random code. Careful
consideration has to be given to the full range of
possibilities. We're very security minded here at
REBOL Tech. as rock solid security is a prerequisite
for successful distributed computing-- and these kinds
of questions are guiding the evolution of REBOL's
security model.
As it stands today, you can build REBOL scripts that
can inspect arbitrary REBOL code, and scripts that can
DO untrusted code. Just turn on all the security and
never try and lower it again.
secure [file throw net throw]
With all the sheilds raised you can DO whatever walks
through the door with out any fear of it resulting in
harm to your system.
Non-interactively (cgi, shell, etc), raise the sheilds,
DO the script, end of program (script gets respawned
later) -- any impact the script could have on your
execution environment will be wiped from memory, so
it's no bother.
-jeff
> If you got here, I have got a problem for you: the present
> code is still dangerous. Could you find why and suggest a
> solution?
>
> {8^D Ladislav
[REBOL] REBOL and the unix shell Re:(2)
Thank you kindly, Larry, for your encouraging words. Hopefully I will get out more such articles soon. They're an after hours thing, ya know. The grand picture is for a variety of domain specific articles which discuss particular specific applications of REBOL. The next one in the works is all about the ins and outs of REBOL bots-- stuff you gotta do to filter mail, running via .forwards, exporting to unix mail format, etc. I've got a number of other topics but I won't go into them now because that's the cart in front of the horse. Another goal is to provide both an html and a view version of the articles, generated from the same source files. Right now I've got a little parser that generates the html for the articles based on a very minimally tagged plain text file. It won't be too much work to get it to spit out view source at the same time, but once I got the html to spit out more or less the way I wanted I moved on to writing the articles. Can always add the view support latter. My real hope is that if I get a bunch of these articles together, other people would be interested in contributing some domain specific articles of their own to the collection. REBOL is used for a universe of tasks, and various people out there know the complete ins and outs of doing a particular task with REBOL. IMHO, their specialized REBOL knowledge should be recorded and shared with the rest of the community. -jeff > Hi Jeff > > Very nice! I reallylike short command utilities like > these. > > -Larry > > - Original Message - > From: <[EMAIL PROTECTED]> > > > > Say folks: I put up an article I wrote this weekend on > > using REBOL with the unix shell. It's a part of some > > other domain specificREBOL materials I've been > > assembling. Have a look and please feel free to send me > > any feedback you have. > > > > http://www.cs.unm.edu/~whip/rebol-unix-shell.html > > > > -jeff
[REBOL] No longer dangerous (use of) Secure Re:
> if I understood you correctly, you are asking what happens, > if the untrusted script were: > > untrusted: [ > security: [file allow] get: func [/any][ > do %bad-stuff.r > ] ] > > let's try it with a more comfortable/debugged secure-do > (sent to [EMAIL PROTECTED]): Howdy, Ladislav: Had a look at what you put there-- really neato. It's great to see that some of the finer higher level aspects of REBOL, the context dependent nature of REBOL (the R.E.B. in REB-ol), are being so well absorbed by people such as yourself. I think the way contexts work is one of the neatest things since sliced bread! At some point there will be more built in support for protected execution environments. Can't say when-- scheduling and development priorities are a complicated thing. :) -jeff
[REBOL] CGI Re:(2)
Howdy, Daniel: > Thank you for your help, everyone. > > This is how far I've got until now : > > Apparently, file access is working normally only in the > first cgi script launchedby Apache, all itschild > processes (subsequent calls of scripts, whether they reside > in cgi-bin or elsewhere) have problems to access the local > file system. That's an odd one. We'll have a closer look at that one when we can (cgi with apache for windows, right?), but unfortunately don't have a decent answer for why you're seeing that behavior right now. Is having your cgi-bin script reading and writing files outside of cgi-bin what you want to accomplish? Perhaps you could have a separate rebol process running living in the directory that you want to write files in that talks through ports to the cgi-bin program. This background REBOL process could do the writing and reading of files on the cgi-bin script's behalf. -jeff
[REBOL] Dangerous (use of) Secure Re:(10)
Cool stuff, Ladislav! Someone's going to accuse you of
being a guru here at the rate you're going! (Or maybe
someone just did (; ) I love your "MY" function, saves
typing and works nicely with the way compose works,
allowing you to sculpt the context of words that are
executed in a block. It's wild in REBOL how a given
block of words to be executed could have words that are
bound to a million different places:
Like this silly thing comes to mind:
REBOL [Title: "Mind num'in magic"]
contexts: [a b c d e f g]
i: 0
foreach context contexts [
set context make object! compose [num: (i: i + 1)]
]
;- in this hand we have an ordinary block of
; nums.. nothing up our sleeves.. ;)
nums: [[(num)] [(num)] [(num)] [(num)] [(num)] [(num)] [(num)]]
;- allow me to fan the nums out here on the table:
forall nums [
bind first nums in get first contexts 'self contexts: next contexts
] nums: head nums
;-- Abracadabra!! Alacazoo!
; All the nums come back to you!
print [mold nums "==" mold compose/deep nums]
halt
;=
Enough silly business, though...
What happens if someone does something like this in
your secure-do, though?:
secure-do [
security: [file allow] get: func [/any][
do %bad-stuff.r
]
] 'throw [] []
-jeff
> Hi,
>
> the GC problem has a work-around as can be seen below:
>
> secure-do: func [
> {secure script execution} untrusted [block! file!
> string!] {untrusted script} security [block!word!]
> {specify net/file policy} hidden [block!] {words to
> hide} protected [block!] {words to protect} /local
> my-words my result sec-do
> ] [
> ; tell GC about secure-do
> sec-do: :secure-do ...
[REBOL] Parsing command line arguments Re:
Howdy, Garold:
Command line args that use - or + can be quoted. If you
need quotes, at least under unix, you can escape the
quotes.
Using the following script which I called "rargs":
#!/usr/local/bin/rebol -q
REBOL [Title: "Rargs"]
foreach item [
system/options/args
system/script/args
][ print [mold :item "==" item]]
You can see some examples:
rargs print \"hello\"
system/options/args == print "hello"
system/script/args == print "hello"
rargs \"+-\"
system/options/args == "+-"
system/script/args == "+-"
or...
rargs {+-}
system/options/args == {+-}
system/script/args == {+-}
If you're running under windows, I'm not sure what the
comparable .bat file for above would be like. Would it
just call rebol on the script you wanted? Maybe so... Not
sure about what you'd do under mac or amiga to do shell
script kind of stuff. Maybe someone will educate me. :-)
Oddly enough, I just wrote a little article on using REBOL
for shell scripts:
http://www.cs.unm.edu/~whip/rebol-unix-shell.html
-jeff
> Since I didnt find anything for processing command line
> arguments, I decided to investigate the issue as my first
> REBOL script.
>
> I use command line programs heavily from other programs.
>
> REBOL eats ALL arguments starting with - or
> +. Since / is used in paths, it isnt
> available as a flag either.
>
> Is there a REBOL standard for option flags?
>
> Is there a standard REBOL script for handling command line
> arguments that I missed?
>
> Any suggestions for improvements of this script?
>
> Should I move the parse rules inside the parse-args
> function?
>
> Is there a better choice for names?
>
> Thanks,
>
> Garold (Gary) L.Johnson DYNAMIC Alternatives
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 562 802 1639
[REBOL] CGI Re:(3)
So, Daniel: what do you see if you do what-dir in the other script? Can you change-dir? What are the system/options/path, and system/script/path values? Can your script write out a test file, if so, where does it show up? The exists? function actually makes this determination by attempting to open a port to the file or url your specified. If opening the port results in an error it does not exist (for all practical purposes that's true as far as REBOL's concerned there)-- otherwise it does exist. Point being that other things can make it appear to not exist. -jeff > > Just a guess, but does the same happen if you add a > > trailing slash, ie: print exists? %./ > > Yes it does. I guess it has to do with file permissions. > I'm running NT, the script does some stuff on files but > it's local. The rebol script invoked with the do/args is > outside of the cgi-bin directory defined in Apache. Is this > a problem ? (it runs fine, it just seems oblivious to what > local files pertains). > > daniel
[REBOL] Dangerous (use of) Secure Re:(7)
If you want to be really paranoid about running an untrusted script: my-words: make system/words [] unset bind difference [my-words system] copy next first system/words 'system my-words/unset my-words/in system 'words export-these-words: [ print + - help ... etc ] ;-- Export some words that the untrusted script ; is allowed to use. my-words/foreach word export-these-words [ my-words/set word my-words/get my-words/in my-words word ] my-words/if my-words/error? my-words/try [my-words/do %untrusted][... ;- Crazy, no? With REBOL you can be very possesive about your words. No, they're MY words! :-) In fact, the object you create doesn't have to be called "my-words". It could be a randomly generated word. Then even if people know your souce code they'll have a pretty hard time knowing where you hid the words because they can't look in system words. rand-word: does [to-word loop 10 [append "" #"A" + random 63]] set rword: rand-word make system/words [] do compose/deep [ unset bind difference [system (rword)] copy next first system/words 'system ( bind [ unset in system 'words foreach word export-these-words [ set word get in (to-lit-word rword) word ] ] rword ) etc... ; In the second case we can avoid using all those paths by binding our unset and foreach code to the context referred to by our random word before that code is dropped into our block we're going to do (and before all the global words are unset). What a swell language... -jeff > On the subject: as long as you want to hide something in > Rebol, you should consider System as the first candidate, > otherwise you allow the script to try to look for what it > needs in System/words. > > Ladislav > >
[REBOL] %detach.r Re:(4)
> thru {==} (append imagecode text)]]
>
>
> insert imagecode "64#{" append imagecode "}"
>
>
> write/binary %image.jpg imagecode
write/binary %image.jpg load imagecode
maybe?
[REBOL] rebol/view without X Re:
Yep, that's a bug in the current release of VIEW that will go away in the next. REBOL/view will be able to run with out talking to X at all. Can't presently offer a work around. -jeff > I dont use rebol for anything usefull or important, so when > I got hold of /view I replaced the old /core, as I > understand /view has /core in it. One problem though, I > often used rebol from a terminal, with no $DISPLAY set, > /view being an X client claims it needs the display even > though it really doesnt. > > How to get around this? > > Ofcourse the best would be that if there is no $DISPLAY > set, it would simply drop back to /core without /view, or > even better, implement /view in cursers, hehe :) > > > -- kolla > >
[REBOL] Dangerous (use of) Secure Re:(6)
Clever! Okay, so untrusted isn't allowed to use load
bind or do.
REBOL []
if error? err: try [
do func [/system/rebol/query] compose/deep [
do [(script: read %untrusted.r
foreach nope ["load" "bind" "do"][
replace/all script nope "none"
]
load script
)]
]
][print "Error with untrusted" print mold disarm err]
check query/clear system/words
Of course, you can always move the system out of the way
temporarily:
moved: :system
unset [system rebol]
if error? try [do %untrusted.r][dump-it]
system: :moved
check query/clear system/words
-jeff
> how about:
>
> do load {query/clear system/words}
>
> ?
[REBOL] Dangerous (use of) Secure Re:(4)
Howdy, Gabriele: The new capability of QUERY was mentioned in the last changes file for view beta 4.1. I figured it was easy to overlook so I've been hoping to find a good oportunity to mention it. :-) x: make object! [a: 1 b: 2] query/clear x == none ;- nothing when it's brand new set in x 'a 33 z: query/clear x == [a] reduce z == [33] ;- block returned bound to the queried object c: to-set-word 'b x/:c 99 query/clear x == [b] ;- even round about modifications are remembered New strains of REBOL introspection! (-: -jeff > On 09-Giu-00, you wrote: > > w> Using the new ability to QUERY objects, you can do the > w> following: > > Is this documented somewhere? There's no hint to this in > the help for QUERY. > > Anyway, this is VERY interesting.
[REBOL] [REBOL]Finding characters in strings Re:
Howdy Tim: I'm a big fan of ANY and ALL for instance like that char-pos: func [str [string!] ch [char!] /r][ any [all [r: find/case str ch index? r] 0] ] > Hi: > I have written a function to find the matching index > for a character in a string: > > ;code follows: > char-pos: func [str[string!] ch[char!] /local result] [ >result: find/case str ch either equal? result none >[return 0] [return index? find/case str ch] > ] ;I have had to use find/case twice because if ; I use > index? find str ch ; and i submit a character that is not > found in str ; I get the following error message from the > interpreter ** ScriptError: index? expected series > argument of type: series port How can Ichange this > function so that I don't have to call find/case twice? > > Thanks In advance Tim > >
[REBOL] emacs colors Re:(5)
Howdy, Fredrik
( and other brothers and sisters of the EMACS faith (-: ):
Okay, you may want to byte-compile the file first:
M-x byte-compile-file
This will produce "rebol.elc". Then you might put this in
your home directory. You may need to add your home
directory to the search path. Add this to your .emacs:
(setq load-path (cons "/path/to/your-home-dir" load-path))
After that you can add this line:
(load "rebol")
To associate the mode with .r files add:
(setq auto-mode-alist
(cons '("\\.r$" . rebol-mode)
auto-mode-alist))
Now here's a real handy piece of elisp to rebol glue code:
(defun go-rebol ()
(interactive)
(progn
(mark-whole-buffer)
(write-region (buffer-string) 0 "/path/to/somewhere/.temp.r")
(switch-to-buffer (process-buffer (setq proc (start-process "subrebol" "subrebol"
"/path/to/rebol" "-s"
"/path/to/somewhere/.temp.r"
(comint-mode)
)
)
(global-set-key "\M-e" (quote go-rebol))
;- changing all the paths to where ever they are.
Now you can be in a buffer making a script, type M-e and it
will pass your script to rebol and start it in a separate
buffer.
Good luck!
If any one out there has some experience dealing with emacs
modes, the rebol.el emacs mode could use your help. There
are still a couple things wrong with the way it parses
strings in particular and where it places close square
brackets.
-jeff
> src> print emacs-mode: read http://www.rebol.org/rebol.el
>
> Thank you.
>
> Now I'm not this good at emacs, the program is very good,
> but i cannot figure out where to put the rebol.el file and
> how to include/start it in emacs.
>
> I tried: ESC-x load-file rebol.el (add-hook
> 'rebol-mode-hook 'turn-on-font-lock)
>
> neither one works, may be because this isn't the right way?
>
> Regards, Fredrik Bergstrom
>
> --
>
> [ PowerWebs have a good Webhotel for everyone, supports
> Rebol to =) ] [ www.powerwebs.se ]
>
> PowerWebs AB Wåxnäsgatan 10 S-653 40 Karlstad Sweden Tel:
> +46-(0)54-103377 Fax: +46-(0)54-103376 ICQ# 7654213
>
>
>
[REBOL] Re: [ALLY] big mails filtering Re:(2)
[x-posted to list]
How to get REBOL to tell you how big the messages are
with the pop:// protocol.
> Bo wrote:
> Well, it's kind of a hack, but you can do this with the
> standard REBOL:
>
> echo %popread.txt trace/net on mbx: open/direct
> pop://user:[EMAIL PROTECTED] echo none
> ...
Whoah. That was inspiring. :-) Below is a slightly modified
version of the pop:// protocol which will store the message
numbers and sizes together in a block within the port/locals
sub-object. For instamce:
pop-port: open pop://user:pass@server
probe pop-port/locals
;- and you'll see a field called total size and sizes which
; contains the total size of your mail, and the sizes block
; contains the message number followed by the size of that
; message.
We'll go ahead and add this to the next version, but until
then here it is:
--
REBOL [
Title: "A slightly modified version of pop"
]
make Root-Protocol [
{Communicate with POP. This protocol is block oriented not
string oriented.}
port-flags: system/standard/port-flags/pass-thru
open-check: [ ; port is bound to confirm frame
none "+OK"
["USER" port/user] "+OK"
["PASS" port/pass] "+OK"
]
close-check: ["QUIT" "+OK"]
write-check: [none "+OK"]
stat-check: ["STAT" "+OK"]
list-check: ["LIST" "+OK"]
open: func [port /total][
open-proto port
port/state/tail: second total: load net-utils/confirm port/sub-port stat-check
port/locals: make object! [
total-size: third total
net-utils/confirm port/sub-port list-check
sizes: load read-til-dot port make string! 100
msg-nums: make block! port/state/tail
repeat n port/state/tail [append msg-nums n] ; lookaside index
]
port/state/index: 0 ; a zero based index
]
read-til-dot: func [port buf][
while [(line: system/words/pick port/sub-port 1) <> "."] [
insert tail buf line
insert tail buf newline
]
buf
]
read-message: func [
"Read a message from the POP server"
port
n [integer!]
/local buf line
][
insert port/sub-port reform [
"RETR" system/words/pick port/locals/msg-nums port/state/index + n]
net-utils/confirm port/sub-port write-check
read-til-dot port buf: make string! 1024 ; guess at size
]
pick: func [
"Read the Nth message from the POP port"
port
][
read-message port 1
]
copy: func [
"Copy a set of messages into a block"
port
/local msgs n
][
msgs: make block! port/state/num
repeat n port/state/num [
append msgs read-message port n
]
msgs
]
remove: func [
"Remove the current message"
port
][
while [ port/state/num > 0 ][
insert port/sub-port reform [
"DELE" system/words/pick port/locals/msg-nums port/state/index + 1]
net-utils/confirm port/sub-port write-check
system/words/remove at port/locals/msg-nums port/state/index + 1
port/state/tail: port/state/tail - 1
port/state/num: port/state/num - 1
]
port
]
net-utils/net-install POP self 110
]
[REBOL] load/next - bug?! (repost) Re:(2)
References: <[EMAIL PROTECTED]>
Howdy Gabriele, agem:
Load/next will only skip past a REBOL header when it
sees something like this:
{ something something ^/REBOL []}
If you have a block like this:
[something something rebol []]
and you SAVE it, you won't wind up with "REBOL []"
preceded by a newline, so it will LOAD/next back in as
you like, an element at a time. Also, you can always
TRIM/lines other strings that you want to LOAD/next if
you suspect there may be REBOL headers within the
string.
-jeff
> Hello [EMAIL PROTECTED]!
>
> On 06-Mag-00, you wrote:
>
> a> the "REBOL-header" is skipt even if it is somewhere in
> a> the code, even in nested blocks?! when at start of
> a> line! this means i have to check for occasional REBOL
> a> everywhere in my save - databases?! Bug, yes?
>
> No, I think this is intended behaviour. (rip works thanks
> to this, too.) If the string contains a REBOL header, it is
> assumed to be a script... but perhaps this should happen
> for files only, and not for strings?
>
> Regards,
> Gabriele.
> --
> Gabriele Santilli <[EMAIL PROTECTED]> - Amigan - REBOL
> programmer AmigaGroupItalia sez. L'Aquila --
> http://www.amyresource.it/AGI/
>
>
[REBOL] Parse this: Sassenrath gets herbal facial! Re:(3)
Reply-to: jeff <[EMAIL PROTECTED]> FCC: /home/jeff/outgoing References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > Oh, and the money wagon passed by while I was relaxing in > the mineral tub. Darn. > > -Carl Gee, we should invite that reporter down here around the next time we get ready to release. Then they can also add to that article how much we enjoy watching the sun rise in the morning... :) -jeff
[REBOL] Rebol on Sun Server and scripting? Re:
Howdy Kelby Cody: > I have Rebol installed on a Sun Solaris web server. Now > I'm wanting to use the script tag within an HTML document > to run a Rebol script. How do I configure my server to run > the rebol script??Iknow I justput
[REBOL] Where is that string comming from? Re:(3)
Already fixed, you big meanie finger pointer! (-; -jeff > Good job Elan! Yes, the bug is in compose. Yo Jeff! ( Jim > points his finger... ;-) > > At 02:39 PM 1/25/00 -0800, you wrote: >Hi Steve, > > > >if you look at the source of build-tag, you will find that > >the culprit is compose:
[REBOL] How do I test for simple regex from external string Re:(4)
Howdy senator Racko:
> to go from
> ^(ted|admin|bobr|andrew|elan|keith|cheryl|joel|brady)$
> which is what is literally in the input stream/file to
> ["ted" "admin" "bobr" "andrew" "elan" "keith" "cheryl" "joel" "brady"]
> needs to be explained. the rest using 'find is trivial.
> (though you don't cover excluded values or prefixes or suffixes)
Apologies in advance if I'm missing the mark (haven't been
able to really read this or any other thread very deeply
lately, but isn't the situation you are addressing one of sets:
---
;- given data of the form:
data: {^^(ted|admin|bobr|andrew|elan|keith|cheryl|joel|brady)$}
split-it: func [what][difference parse/all what "^^|$()" [""]]
split-data: split-it data
users: ["ted" "admin" "bobr" "andrew" "elan" "keith"
"cheryl" "joel" "brady"]
some-other-data: split-it {^^(tom|dick|harry|ted|ivan)}
whos-in: intersect some-other-data users== ["ted"]
whos-out: differece whos-in some-other-data == ["tom" "dick" "harry" "ivan"]
---
If not, pardon my intrusion in this knowledge base building
thread.
(Wondering to myself: if polymorphic set operations were
available in languages that rely heavily on regular
expressions, would those regexps still be used just as much?)
-jeff
[REBOL] [REBOL] Message box? Re:
Howdy Ridley: > Is there any way to access the security check box and > use it for general messages? > > The kids hang on the computer all day and I can never > call home. I'd like to run a script that will pop a > message whenever I hit a particular port. Something > like "get off the phone" or "call me at 123-4567". Sure: You fire up the windows version of REBOL and: write/binary %hacked-rebol.exe head change find read/binary %rebol.exe "Script requests permission to" "Hey kids! Get off the phone!!" (There's more text on the message that you can change, if you want to add expletives and stuff.. but of course, be sure to only overwrite the text that's there. Don't change the length of the text.) Then you start up your hacked version of REBOL, (W/O modifying the default security) and you run this following: REBOL [] wait reduce [open tcp://:9911] secure none Then, when you send something to port 9911, the message box with your message will pop up. What a hack... :-) Of course, this letter in no way implies that REBOL Technologies encourages people to arbitrarily hack REBOL! Be kind to the old rebol binary... -jeff
[REBOL] rebol.org purpose (was "archive" ) Re:(14)
Howdy Doug:
> Did I miss something?
>
> What list did I not hear about? I might be interested
> also.
>
> { So, the other mailing list is being set up right now.
> I've
> subscribed those who have expressed an interest.
> }
There's been set up a mailing list for people interested in
developing rebol.org, the REBOL community web site.
Since the list is aimmed at a specific development task and not
about rebol in general it hasn't been made public. But send me an
email off list if you are interested in joining the rebol.org
development group.
(-:
-jeff
[REBOL] rebol.org purpose (was "archive" ) Re:(11)
> to clarify, Ted's project is "kabob" on husted.com > > my done-one's source code is at kehei.com . if you want to > see a biginstance ofone runningtry > http://www.worldforge.org > > everything with /website in the url uses it. > > > now the bad news: sadly, it was written before we knew > about rebol. > > it does shell-out via system() and examine environment > variables so it will have trouble getting by with > rebol/core even if we did convert it to another language. > > so while free/open source, jeff will not allow it. Well, some shell script glue (that collect environment variables and passes them in via stdin to the REBOL script, or what have you) where needed is fine, but the bigger point is that REBOL is highly capable of creating all the content on its own (when it comes to scripts, that is. Of course people can use whatever editor they want, as long as it's emacs! (-:) Often enough, machine dependencies created by shelling-out can be avoided. Shelling languages end up making shell calls rather frivolously sometimes. As a simple matter of principle, the REBOL community website should be totally "powered by REBOL". It should also reflect the shared interests of that community, so, in my humble opinion, it shouldn't just be a matter dropping a bunch of already made non-REBOL components in there. It should be like a "hey, guys, we need one of these and one of those..." or "hey, I got this kooky idea to run past you all." And on from there. I can't promise this at all, but the development group might be entitled to a non-distributable pre-beta copy of command if it would help the site. No promises, though. So, the other mailing list is being set up right now. I've subscribed those who have expressed an interest. Trying to strike while the iron's hot, Jeff
[REBOL] rebol.org purpose (was "archive" ) Re:(6)
Ted said: > This might be a bit much to put on one person's door-step. > > Why not post some "help wanted" notices on the site, and > take applications for a few days. > > Possible roles might be Script Librarian, Mailing List > Moderator, HTMLDeveloper, CGI Developer, Site > Administrator. Okay, I sent off that message last night with out stating a few small qualifications. First, preferably, a single person is given the password to the site who is ultimately responsible for the well being of the entire site. This would be the Site Administrator above. They have final say over decisions about the site. It would be great to form a rebol.org development group which might elect this administrator for a term. A mailing list can be established for this group. They can break down development tasks among themselves, brainstorm, etc. Perhaps the various people developing stuff for the site can upload files via authenticated http into designated directories. Of course, it should be established that everything is tested off site before it goes into operation. One other important ground rule is that everything has got to be done with REBOL. No name-your-other-script language allowed !!! (-: Of course, we at REBOL Tech. will lend as much direct support as possible, and would certainly like to contribute items to the cause when possible. So, does this approach still interest people? I would be happy to immediately set up another selma list here for the rebol.org group if three or more people are interested in getting involved in this effort? (Dare I ask for people to "me-to" on this on the mailing list??) ;-) AND THANKS YOU GUYS, for showing interest in helping to improve rebol.org! My faith in humanity is reaching new heights! (-: (-: (-: -jeff
[REBOL] rebol.org purpose (was "archive" ) Re:(4)
What people are saying about REBOL.org: > Andrew said: > > If improvements were made to this script, such as converting "<" to "<" > and similar modifications were made, could this new script then be > installed/added to the REBOL.org site? > Cheryl said: > > Well, I hope whoever maintains rebol.org will not ignore you any longer. You > have presented two very good solutions. Perhaps, one day we'll learn who is > actually maintaining that site and makes the decisions. > Ted said: > > If you think Rebol.org needs better technology (and, of course, it > does), a good response would be to provide the REBOL scripts that can > do the job the way you would like. From REBOL's viewpoint, it may be > better to leave it bare bones, hoping that someone will come along and > volunteer to improve it. > > Right now, I think a lot of us would prefer REBOL put their extremely > limited resources into getting REBOL/View and REBOL/Command out the > door. Any of us could help to improve the Web site if we chose, but > right now only REBOL Tech can work on these other products. > Elan said: > > Then [the changes] should be made. Perhaps some people could > declare themselves responsible for the submission script and whoever > is managing the script can release the source to this group? > Bob said (in regards to super rebol.org wikiness): > > I am also not about to ask REBOL Technologies to "take this over" > as they have a full plate. Why slow them up when we on the outside > have the time/resources of our own to make it happen. Welp, I sincerely hope this energy spewing forth about rebol.org is a signal of people eager to make the site better. With that in mind, I dropped what I was doing tonight and revamped for public consumption the submit-bot script so that ya'll can hack it, improve it, fix it, etc. and get a sense for what rebol.org is presently doing. Download it at: http://rebol.org/internal/submit-bot.r A couple times before I've BEGGED people to help rebol.org and the silence was amazing. Sterling and I, along with Andrew Grossman have been the creators of the scripts there when time allowed, which is less and less all the time. We wanted to get something up there that mostly ran, that soaked up scripts, and provided a threaded mailing list archive. We weren't even asked to do it by Carl or anyone else in the company. We just felt someone had to get that ball rolling so we did it after hours. There's certainly kinks in those scripts, and forget about the low budget appearance of the site. But it's there and it generally works. There's more than 110 scripts in the site, and the mailing list has thousands of messages processed and archived. We wanted to get it off to a good start, but we can't possibly maintain it while doing our day jobs as developers on REBOL. So we've longed for someone to leap up from the community: a scripter extraordinaire who wanted to own the site, take pride in it, help it to prosper and grow. If someone really wanted to take the project on, manage changes to the system sent in, etc. then we'd happily turn over the account and break a champagne bottle across the stern. Imagine yourself maintaining the flagship website of the REBOL community! The site is a well run linux box with REBOL cgi, as well as most all other unix utilities you'd expect. Somebody take this site over or I will loose all faith in humanity. ;-) -jeff
