[REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle IN 0 BYTES
Hi Ryan, > Incedently, > This is 3 bytes shorter: > > w: 100 print loop w [w: w - last random [0 0 1]] > > Of course more could be shave off, at the loss of readablility, but would > better > match the examples from other languages given. > And, losing the readability as you suggest, this is 8 bytes shorter still: w: 100 loop w[w: w - last random[0 0 1]] 40 bytes, and counting, Sunanda. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Perl is to stupid to understand this 1 liner.
On 18-Dec-01, Joel Neely wrote: > Whether a human manufactures the rules, or a piece of AI software > attempts to do so (and I suspect the human will do a better job at > this point in history), the problem remains that the size of the > rule set itself undergoes a combinatorial explosion as we try to > take into account the variations in the data. Perhaps, instead of trying to make software understand documents written any old which way by humans, we should create strictly formal versions of current human languages that can be tested for correctness by computer? We'd then be able to have documents that could be examined by computer without the need to worry about an infinate number of special cases. -- Carl Read -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Perl is to stupid to understand this 1 liner.
Hi Joel, << That's an interesting (although severely non-trivial) approach to the development issue...>> Well, I never said it would be *easy*. :) <<...but I was describing a property of the problem space itself. >> Right. This is where my thinking diverges...I'm not sure to where. Rather than trying to identify all the ways a phone number could be formatted, because there are just too many of them even if we don't account for typographical errors in formatting, let's just say that a phone number is: A bunch of numbers with, possibly, some separators at the start or between them. Once you get to something other than a number, separator, or one of our "special" text strings (e.g. x, ext, pin), that's it. OK, that's a little vague, so we need to add some more rules. If it comes after 'at, that's a good clue. If it comes after 'is, that's a good clue. If it looks like one of the following, that's a *really* good clue. 551-1211 800-552-1212 1-800-553-1213 1+800-554-1214 800/555-1215 (800)556-1216 (800) 557-1217 800.558.1218 1.800.559.1219 If there are from 7 to 12 digits, and they're broken up into tuple-like groups, that's a good clue. If you find a proper name, and that name is in our address book, you can verify their number or maybe their country at least. Is this enough to handle all we might every want? Probably not. Do you want to allow things like1.2/3)4(5-6.7 8.9? Perhaps...no. :) --Gregg -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Network Guru...
Hi Louis, > I took your advice---read the articles and installed zonealert. Nothing > seems to be trying to access the internet from my computer, so I suppose > that is good news. > However, zonealert shows that rebol is constantly > running, even when my scripts are not running. Your script example earlier showed this: forever [ do %sendfiles.r ; rebol script to do. wait 00:50:00 ; wait hours:minutes:seconds. ] ZoneAlarm probably *would* indicate Rebol was running but not producing network activity during the 50 minute period for this bit of code. If you were sure that this code or any other Rebol script were not running and yet ZoneAlarm shows Rebol running - then not so good. But I really doubt this. Recheck you setup. Perhaps you are automatically running Rebol on boot up of your machine. > Since I must manually relax > security (both read and write) for my script to run, and the security seems > to stay relaxed after my script runs, I am still concerned. Security is relaxed for the lifetime of the Rebol interpreter instance you started - unless you set it back. You wording makes me think that you believe %sendfiles.r is the script that you are apply the security setting to. This is not the case. You are applying the security setting to the Rebol interpreter instance that is evaluating the script that has the "forever" loop in it, or whatever calls it. > Is there some > way the script itself can set security---open the door, do its work, then > shut and lock the door? I'm not sure you need that because I'm presuming you know exactly what your scripts are doing, probably because you wrote them yourself and so you trust them. If you run your trusted scripts in a relaxed security setting and are confident that those trusted scripts have no possibility of calling or evaluation untrusted scripts or code then I don't think you have a problem. Just let them do their work. If you are using someone else's scripts and you are not confident it is trus tworthy in regards to security, then consider asking about the suspect code on the Rebol mailing list. Security in relation to Rebol hasn't been discussed too much yet. I suggest you read the security section of the Core manual and create some dummy test scripts to see what happens in various situations. Brett -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle IN 0 BYTES
Incedently,
This is 3 bytes shorter:
w: 100 print loop w [w: w - last random [0 0 1]]
Of course more could be shave off, at the loss of readablility, but would better
match the examples from other languages given.
--Ryan
Reichart wrote:
> There are some pretty cool examples here!
>
> What is really nice about this little "detour" is that we are all learning
> some interesting interpretations of the Rebol words, and their use.
>
> However, we need to keep in mind that we can't loose focus on the goal,
> which is to write a model of the real problem...in the least number of
> bytes. I condensed even further this one:
>
> w: 100 print [loop w [w: w - first random [0 0 1]]]
>
> Which, although a VERY COOL example of Rebol, is not a good example of the
> problem.
>
> This exact same problem in other languages would be just:
> Matlab: sum(rand(100,1)>1/3)
> C: for(int i=0,j=0;i<100;i++)j+=rand(3)>1;cout< In Perl:$i=0;$j=0;for(;$i<100;$i++){$j+=rand(3)>1;}print $j
> Rebol: w: 100 print [loop w [w: w - first random [0 0 1]]]
>
> Does not look good for Rebol.
>
> Not that I judge a language by its compatibility at all, but it is just
> plain fun to compare, we are mostly boys after all.
>
> So...
>
> The problem stated clearly is:
>
> Monty shows you three curtains.
> Behind one curtain is a prize, the others nothing.
>
> REBOL: Set up THREE variables in Rebol, 1 "different" than the other two.
>
> Pick a door at random.
>
> REBOL: Pick a variable at random.
>
> Once picked, one of the doors will be revealed to you, which is guaranteed
> to be empty.
>
> REBOL: Search through the variables until an empty one is found, remove it
> from the list. Or mark it in some manner.
>
> Offer chance to switch.
>
> REBOL: Always switch, and if percentage chance of receiving prize
> ("different") of the remaining two variables, print a statement, or even the
> simple number which is the percentage chance of receiving the prize.
>
> We have to include the spaces and the "rebol[]_" in our count. Just this
> header is 8, since Rebol requires spaces. So use 1 letter variable names.
>
> If you write something "tricky" then simply break it down in your email.
> This will both prove that it is a good model, and teach the rest of us more
> about the nature of writing good programs, and make yourself a god, all at
> the same time!
>
> If you think you have really modeled the problem correctly, and in the LEAST
> number of bytes, then append the statement to the Subject line "IN n bytes."
> Where n is the actual number you were able to achieve.
>
> Reichart...
> [EMAIL PROTECTED]
> "Be useful."
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 17, 2001 6:40 AM
> To: [EMAIL PROTECTED]
> Subject: [REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle
>
> Hi Joel,
>
> > It seems to me that the problem in the original post was persuasion
> > and not just computation. That being the case, the text of the
> > program itself (or its derivation) should be a compelling argument
> > for the right answer.
> >
> > IOW, if I had trouble understanding/accepting an answer, I would
> > not be very persuaded simply by the output of a highly compact
> > program that seemed to contain assumptions about the very answer
> > I was having trouble with.
>
> I completely agree that a highly compressed program isn't often a great way
> to win an argument. But (just to defend myself for a moment) my attempt
> embodied all the "rules": I picked a door; Monty picked an empty one of the
> other two; I swap to his unopened one. No built-in assumptions there.
>
> i also agree with an earlier post of yours (about Perl and parlor games).
> The
> best test of a programming language isn't how compact a program it can
> write,
> but (I would claim) how easy it is to write maintainable programs in it. But
>
> even that tests mainly the design skills and long-term vision of the
> programmer.
>
> A good test of all of our (and Perl and Matlab) solutions is how easily can
> they be modified as various "real world" changes are required. Almost by
> definition, we can't know what our programs will face over there lifetimes,
> but here are a few of the sort of things that might beset a Monty simulator:
>
> -- Not three doors, but 10
>
> -- Not 10 but 25 million doors (challenging many language implementations to
>
> handle this as in-store arrays)
>
> -- Monty opens more than one door
>
> --there is more than one door with a car behind it
>
> -- I get to pick more than one originally, but can only open ONE of mine, OR
>
> one of his once Monty has opened the ones on his side
>
> -- I get to pick more than one door, and Monty opens N of mine and M of his.
>
> -- There are several prizes (a Saab and a Mercedes) including some booby
> prizes (A tribe and a yugo maybe). Monty will open up to N doors at random;
> I
> can't win the prize behind an opened door;
[REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle IN 0 BY TES
Hi Reichart,
> This exact same problem in other languages would be just:
> Matlab: sum(rand(100,1)>1/3)
> C: for(int i=0,j=0;i<100;i++)j+=rand(3)>1;cout< In Perl: $i=0;$j=0;for(;$i<100;$i++){$j+=rand(3)>1;}print $j
> Rebol: w: 100 print [loop w [w: w - first random [0 0 1]]]
>
> Does not look good for Rebol.
We can use the same algorithm as you have for Perl and C, and get something
like:
s: 0 n: 100 loop n[if 1 < Random 3 [s: s + 1]]s
Which is 47 bytes -- exactly the same as your C (actually C++) example And
shorter than your Perl, though longer than Joel's improvement.
(You ask that we count the Rebol [] as an extra 8 bytes overhead. Fair
enough, but shouldn't your C++ have a standard header include?)
Unlike Perl and C, Rebol needs an explicit type cast to go from true/false
to an integer, so to follow exactly the Perl/C++ examples we'd have to write
something like:
s: 0 n: 100 loop n[s: s + to-integer (1 < Random 3)]
or
s: 0 n: 100 loop n[s: s + pick[0 1](2 < Random 3)]
but they are longer.
Rebol "loses out" on sheer shortness here because it needs spaces between
operators, and its RAND function is spelt RANDOM. Some people would see these
as sufficient compensation for coming second in such a race.
An, of course, bear in mind that the entire Rebol environment needed to run
these programs is under 252K (Rebol/Core, Windows 3.1).
If I am allowed to have a slightly larger environment (though still way
smaller than C or Perl -- I don't know about Matlab), then I'd define:
L: :Loop
R: :Random
And roll my code home in 39 bytes:
s: 0 n: 100 L n[if 1 < R 3 [s: s + 1]]s
Sunanda.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
[REBOL] Re: Perl is to stupid to understand this 1 liner.
Hi, Gregg,
Gregg Irwin wrote:
>
...
>
> Now, you run it and it shows you the results for confirmation,
> just like a new assistant you hire. You give it feedback, which
> it remembers, and over time it builds new rules to account for
> your style. At some point, it may do so well that you tell it
> "Don't ask me to proof your work unless you have some doubt about
> something". If something, like your example, is of a critical
> nature, you can always tell it "run this by me before you send it
> out", or "Add your own 'signature' so, if something is wrong,
> they can blame you." :)
>
That's an interesting (although severely non-trivial) approach to
the development issue, but I was describing a property of the
problem space itself. Using myself as a case in point, I made up
a list of the ways I've actually seen US phone numbers written or
typed/typeset:
551-1211
800-552-1212
1-800-553-1213
1+800-554-1214
800/555-1215
(800)556-1216
(800) 557-1217
800.558.1218
1.800.559.1219
Even handling this short list (with nicely commented/named code ;-)
to find phone numbers in a text file required something roughly
like the following:
8<
phones: make object! [
defaultarea: "123"
areadata: none
exchdata: none
linedata: none
digits:charset "0123456789"
plusminus: charset "+-"
ldcode: ["1" plusminus | none]
optgap: [" " | none]
area: [copy areadata 3 digits]
exch: [copy exchdata 3 digits]
line: [copy linedata 4 digits]
phonepatterns: [
exch "-" line (areadata: none)
| ldcodearea "-"exch "-" line
| area "/"exch "-" line
| "(" area ")" optgap exch "-" line
| ["1." | none] area "."exch "." line
]
findphones: func [st [string!] /local result] [
result: clear []
parse/all st [
any [
phonepatterns (
append result rejoin [
any [areadata defaultarea]
"-" exchdata "-" linedata
]
)
| skip
]
]
result
]
run: func [fn [file!] /local text] [
text: read fn
print rejoin [{"^/} text {^/"}]
foreach phone findphones text [
print [tab phone]
]
print ""
]
]
phones/run %phones.txt
8<
I'm sure someone could tighten it up a bit, but that's not my
main point here. This quick draft version is still sensitive
to false positives (e.g. a line with a product number in it
resembling
#AB-1234-56789
In addition, when I described this to a collegue, she immediately
asked, "What about extensions?", raising the issue of multi-line
phone systems where the numbers might be written/typed as
800-555-1212x123
808-554-1212 x 234
888-556-1232 ext 456
889-567-1242 ext. 9876
898-576-1252/1234
(with the extension in combination with other phone number formats
as appear in the code above).
Whether a human manufactures the rules, or a piece of AI software
attempts to do so (and I suspect the human will do a better job at
this point in history), the problem remains that the size of the
rule set itself undergoes a combinatorial explosion as we try to
take into account the variations in the data.
And we haven't even tackled odd cases like the following
You may call me at my office at 1-800-555-1212--I expect to be
there until 5:00PM--to discuss our presentation.
which ultimately require an actual *understanding* of the text to
achieve high accuracy.
Hence my description of the problem domain itself as being
metaphorically fractal.
-jn-
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
[REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle
RE: [REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle [EMAIL PROTECTED] wrote: > > On 17-Dec-01, Carl Read wrote: > > > Here's a fixed version... > > > rebol[]k: s: 0 r: func[n][random n]m: does[p: r 3 c: r 3 p = c] loop > > 1 [if m[k: k + 1]if not m[s: s + 1]]print ["Kept" k "Switched" > > s] > > > Nowhere near as short as some of the other posts, but anyway, here's > > my reasoning behind it... > > > The prize is placed behind one of 3 doors... > > >prize: random 3 > > > You choose one of the doors... > > >chosen: random 3 > > > Now, Monty can see if they're a match - ie, if you've picked a > > winner... > > >matched?: prize = chosen > > > Which returns true if you've chosen the prize. If you decide to keep > > this then it's obvious (I hope:) that you had 1 chance in 3 of > > picking the prize. > > > But what if you accept Monty's offer to switch? Well, there's only > > two posibilities: > > > 1) You'd chosen the prize, so switching from that means you lose > > regardless of what Monty does. > > > 2) You hadn't chosen the prize, Monty exposes the other losing door, > > and so you switch to the winning door. > > > So a switch always means a reversal of your original choice - a > > winning choice becoming a losing one and vice-versa. So... > > >matched?: not matched? > > > But what happens to the "1 chance in 3 of picking the prize."? Well > > that also means you had 2 chances in 3 of losing, right? And the > > switch makes an original loss a win, so switching gives you 2 > > chances in 3 of winning, thus doubling your chances of a win. > > After showing the above explaination to someone (not on this list) > they still didn't believe it, so I've written a graphical version in > the hope that pictures will win out where words fail... (Not a View > version though - run it from the Console.) > well, thats to complicated to me, i give up. i have a 2/3 choice to get a priceless door, this chances are better, and so i want to be priceless. hey, and if i hit, Monty will show me the other priceless door! so i have two :) happy without a price -Volker ;-) > > rebol [] > doors: func [n c][ > d: copy/deep ["[ ]" "[ ]" "[ ]"] > d/:n/2: c > return d > ] > game: does [ > print " Switching Keeping" > prize: random 3 > print ["Prize: " doors prize #"P" " " doors prize #"P"] > guess: random 3 > print ["Guess: " doors guess #"G" " " doors guess #"G"] > opened: first random difference [1 2 3] reduce [prize guess] > prin ["Opened:" doors opened #"X"] > prin " " > print either prize = guess [kept: kept + 1 "Win"]["Loss"] > sw: first difference [1 2 3] reduce [guess opened] > print ["Switch:" doors sw #"S"] > prin " " > print either prize = sw [switched: switched + 1 "Win"]["Loss"] > > played: played + 1 > print [ > "Wins: " switched "" > kept > " Played:" played > ] > ] > played: 0 > kept: 0 > switched: 0 > quit?: false > print "" > while [not quit?][ > game > print "" > print "Enter to continue - Esc to quit." > > inp: input > quit?: inp = "q" > ] > > > Enough! (: > > -- > Carl Read > > -- > To unsubscribe from this list, please send an email to > [EMAIL PROTECTED] with "unsubscribe" in the > subject, without the quotes. > -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Can a script run another script?
> Is "the first script" the first one run by the REBOL? It doesn't include the ones in Rebol. Just your scripts. > Does that include, for instance, the /View desktop? It shouldn't include the desktop in View. Andrew Martin ICQ: 26227169 http://valley.150m.com/ -><- -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Console current path
On 18-Dec-01, [EMAIL PROTECTED] wrote: > On Mon, Dec 17, 2001 at 07:32:37PM -, John R wrote: >> Hi all, >> Why does my console apparently change directory after an error >> occurs in program (halted etc.)? >> Console session example below show:-> do/args %myprogs/ftget.r "FTX1" >> Program FTGet begin >> ["FTX1"] >> Invalid FTSE Index argument : FTX1 do/args %myprogs/ftget.r "FT1" >> ** Access Error: Cannot open /C/rebol/view/myprogs/myprogs/ftget.r >> ** Where: halt-view >> ** Near: do/args %myprogs/ftget.r "FT1" > That's a bug. Please submit it to feedback. 'do needs to switch > directories in order to run the script (scripts expect their own > directory to be current), but is supposed to switch back after the > script has completed. Apparently that does not happen if an error > occurs. Just checked what feedback told me about this. (I submitted it way back in May 2000)... "After running a script which exits with an error, the current directory becomes the one where the script was in. You can check this out with the WHAT-DIR command." I wasn't told then it was a bug so I've always assumed it's intended REBOL behaviour... -- Carl Read -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle
On 17-Dec-01, Carl Read wrote: > Here's a fixed version... > rebol[]k: s: 0 r: func[n][random n]m: does[p: r 3 c: r 3 p = c] loop > 1 [if m[k: k + 1]if not m[s: s + 1]]print ["Kept" k "Switched" > s] > Nowhere near as short as some of the other posts, but anyway, here's > my reasoning behind it... > The prize is placed behind one of 3 doors... >prize: random 3 > You choose one of the doors... >chosen: random 3 > Now, Monty can see if they're a match - ie, if you've picked a > winner... >matched?: prize = chosen > Which returns true if you've chosen the prize. If you decide to keep > this then it's obvious (I hope:) that you had 1 chance in 3 of > picking the prize. > But what if you accept Monty's offer to switch? Well, there's only > two posibilities: > 1) You'd chosen the prize, so switching from that means you lose > regardless of what Monty does. > 2) You hadn't chosen the prize, Monty exposes the other losing door, > and so you switch to the winning door. > So a switch always means a reversal of your original choice - a > winning choice becoming a losing one and vice-versa. So... >matched?: not matched? > But what happens to the "1 chance in 3 of picking the prize."? Well > that also means you had 2 chances in 3 of losing, right? And the > switch makes an original loss a win, so switching gives you 2 > chances in 3 of winning, thus doubling your chances of a win. After showing the above explaination to someone (not on this list) they still didn't believe it, so I've written a graphical version in the hope that pictures will win out where words fail... (Not a View version though - run it from the Console.) rebol [] doors: func [n c][ d: copy/deep ["[ ]" "[ ]" "[ ]"] d/:n/2: c return d ] game: does [ print " Switching Keeping" prize: random 3 print ["Prize: " doors prize #"P" " " doors prize #"P"] guess: random 3 print ["Guess: " doors guess #"G" " " doors guess #"G"] opened: first random difference [1 2 3] reduce [prize guess] prin ["Opened:" doors opened #"X"] prin " " print either prize = guess [kept: kept + 1 "Win"]["Loss"] sw: first difference [1 2 3] reduce [guess opened] print ["Switch:" doors sw #"S"] prin " " print either prize = sw [switched: switched + 1 "Win"]["Loss"] played: played + 1 print [ "Wins: " switched "" kept " Played:" played ] ] played: 0 kept: 0 switched: 0 quit?: false print "" while [not quit?][ game print "" print "Enter to continue - Esc to quit." inp: input quit?: inp = "q" ] Enough! (: -- Carl Read -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Network Guru...
Marj and Brett, I took your advice---read the articles and installed zonealert. Nothing seems to be trying to access the internet from my computer, so I suppose that is good news. However, zonealert shows that rebol is constantly running, even when my scripts are not running. Since I must manually relax security (both read and write) for my script to run, and the security seems to stay relaxed after my script runs, I am still concerned. Is there some way the script itself can set security---open the door, do its work, then shut and lock the door? Louis At 11:45 AM 12/17/2001 +1100, you wrote: >I doubt that your Rebol script is accepting connections only opening a >connection to your target machine when required. >So on that basis there would be no ports open due to Rebol. Unless you were >running a FTP server script or something. > >However I think you have bigger concerns than Rebol if your machine is full >time connected (actually same problem for >dial up) to the internet. There are constant network port scans occurring >across the internet. > >I suggest you go to http://grc.com and read the "Shields Up" information >provided there. Also look for the information about >denial of service. > >Brett. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Network Guru...
Marj and Brett, I took your advice---read the articles and installed zonealert. Nothing seems to be trying to access the internet from my computer, so I suppose that is good news. However, zonealert shows that rebol is constantly running, even when my scripts are not running. Since I must manually relax security (both read and write) for my script to run, and the security seems to stay relaxed after my script runs, I am still concerned. Is there some way the script itself can set security---open the door, do its work, then shut and lock the door? Louis At 11:45 AM 12/17/2001 +1100, you wrote: >I doubt that your Rebol script is accepting connections only opening a >connection to your target machine when required. >So on that basis there would be no ports open due to Rebol. Unless you were >running a FTP server script or something. > >However I think you have bigger concerns than Rebol if your machine is full >time connected (actually same problem for >dial up) to the internet. There are constant network port scans occurring >across the internet. > >I suggest you go to http://grc.com and read the "Shields Up" information >provided there. Also look for the information about >denial of service. > >Brett. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Network Guru...
Marj - I agree, ZoneAlarm, on my home PC has been a boon. At work, I've got a firewall to protect me, but my Home PC really didn't have much, and since I run Win2K, I've never had too much faith that my system was secured. In my original posting, I indicated that I was running ZA, and that's what tipped me off to these constant probes against my system. And, then I noticed that my ISP's news server was probing against my port 1080... So I posted looking for something to help me analyze the probes a little bit better than the rather simplistic messages ZA records. After running a script to setup a "server" on port 1080, I've caught some traffic, but it's just pings really. All the attempted intrusion seems to be doing is "pinging" to see if the port is open (1080 is commonly used as a Windows proxy port for HTTP) - nothing more. It's strange to see if coming from the news server of my ISP though. I assume they've been compromised, and mailed them about it twice. - Porter - Original Message - From: "M. A. Tiefert" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]@mta0x15.coxmail.com> Sent: Sunday, December 16, 2001 11:27 AM Subject: [REBOL] Re: Network Guru... > Louis -- > > At 01:53 PM 12/14/01 -0600, you wrote: > >Also, how can I know if an invasion has happened? > > > You can get ZoneAlarm (a firewall) free for personal use from > http://www.zonelabs.com/ > > I've been satisfied with it. > > cheers, > > Marj > > * * * > Marj Tiefert > Technical Writer, Website Manager -- and more! > http://www.mindspring.com/~mtiefert/resume/MTiefert.html > > -- > To unsubscribe from this list, please send an email to > [EMAIL PROTECTED] with "unsubscribe" in the > subject, without the quotes. > > -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Can a script run another script?
--- Andrew Martin <[EMAIL PROTECTED]> wrote: > Alan wrote: > > The above works as a script unto itself, but > within the larger script, I > get the following error message... > > > > "Launch can only be used by launcher programs" in > a REBOL/View Dialog Box. > > > > Since 'launch is undocumented, do you know what > this error means? > > 'Launch is designed to launch programs only from the > first script. Is "the first script" the first one run by the REBOL? Does that include, for instance, the /View desktop? Chris Dicely __ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle IN 0 BY TES
Hi, Reichart,
Just a minor quibble and a major coincidence...
Reichart wrote:
>
...
>
> w: 100 print [loop w [w: w - first random [0 0 1]]]
>
> Which, although a VERY COOL example of Rebol, is not a good example of the
> problem.
>
> This exact same problem in other languages would be just:
> Matlab: sum(rand(100,1)>1/3)
> C: for(int i=0,j=0;i<100;i++)j+=rand(3)>1;cout< In Perl:$i=0;$j=0;for(;$i<100;$i++){$j+=rand(3)>1;}print $j
> Rebol: w: 100 print [loop w [w: w - first random [0 0 1]]]
>
Actually, it can be written in Perl as
for(1..100){$j+=rand(3)>1}print $j
dropping 17 bytes from 51 to 34 (concidentally 2/3!!!)
-jn-
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
[REBOL] Re: Console current path
John wrote: > Why does my console apparently change directory after an error occurs in program (halted etc.)? > > Console session example below show:-> > > >> do/args %myprogs/ftget.r "FTX1" > Program FTGet begin > ["FTX1"] > Invalid FTSE Index argument : FTX1 > >> do/args %myprogs/ftget.r "FT1" > ** Access Error: Cannot open /C/rebol/view/myprogs/myprogs/ftget.r > ** Where: halt-view > ** Near: do/args %myprogs/ftget.r "FT1" > >> Rebol changes the current directory to %myprogs/ so that %ftget.r is running with the correct current directory. When the error occurs in %ftget.r, the current directory is still %myprogs/ so that's why the current directory seems to have changed for the console -- you're still in the context of %ftget.r, which is different from where you were before. I hope that helps! Andrew Martin ICQ: 26227169 http://valley.150m.com/ -><- -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Console current path
On Mon, Dec 17, 2001 at 07:32:37PM -, John R wrote: > Hi all, > > Why does my console apparently change directory after an error occurs in > program (halted etc.)? > > Console session example below show:-> > > >> do/args %myprogs/ftget.r "FTX1" > Program FTGet begin > ["FTX1"] > Invalid FTSE Index argument : FTX1 > >> do/args %myprogs/ftget.r "FT1" > ** Access Error: Cannot open /C/rebol/view/myprogs/myprogs/ftget.r > ** Where: halt-view > ** Near: do/args %myprogs/ftget.r "FT1" > >> That's a bug. Please submit it to feedback. 'do needs to switch directories in order to run the script (scripts expect their own directory to be current), but is supposed to switch back after the script has completed. Apparently that does not happen if an error occurs. -- Holger Kruse [EMAIL PROTECTED] -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Console current path
On 18-Dec-01, John R wrote: > Hi all, > Why does my console apparently change directory after an error > occurs in program (halted etc.)? > Console session example below show:-> >>> do/args %myprogs/ftget.r "FTX1" > Program FTGet begin > ["FTX1"] > Invalid FTSE Index argument : FTX1 >>> do/args %myprogs/ftget.r "FT1" > ** Access Error: Cannot open /C/rebol/view/myprogs/myprogs/ftget.r > ** Where: halt-view > ** Near: do/args %myprogs/ftget.r "FT1" >>> I've heard the reason, (from RT), but forgotten it. But if it happens, change your 'do path to a full path and your program will run again without you having to close the console down and start again. (No doubt someone could write you/us a reset-path function we could add to our REBOL startups?) > John -- Carl Read -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Can a script run another script?
Alan wrote: > The above works as a script unto itself, but within the larger script, I get the following error message... > > "Launch can only be used by launcher programs" in a REBOL/View Dialog Box. > > Since 'launch is undocumented, do you know what this error means? 'Launch is designed to launch programs only from the first script. It's a security measure. It's best to restructure your script. Andrew Martin ICQ: 26227169 http://valley.150m.com/ -><- -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Console current path
Hi all, Why does my console apparently change directory after an error occurs in program (halted etc.)? Console session example below show:-> >> do/args %myprogs/ftget.r "FTX1" Program FTGet begin ["FTX1"] Invalid FTSE Index argument : FTX1 >> do/args %myprogs/ftget.r "FT1" ** Access Error: Cannot open /C/rebol/view/myprogs/myprogs/ftget.r ** Where: halt-view ** Near: do/args %myprogs/ftget.r "FT1" >> John -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: BNF grammar of REBOL for code "obfuscator"
Hi Geza, look at http://www.rebol.com/docs/core25.html#section-7 and http://www.reboltech.com/library/html/parse-code.html --- Ciao Romano -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Cool Cursor Console Counter
I needed a good progress indicator / counter mechanism today. Here is what I came up with - works with CORE. (this example just counts to 999,000 and shows every 1000) REBOL [] count: 1 until [ count: count + 1 if (count // 1000) = 0 [ prin ["^(1B)[7D" count] ] ; count by 100's, 1000's or whatever you need count = 999000 ] For more info on how this works - see: http://www.rebol.com/docs/core23/rebolcore-18.html#sect5.1. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle IN 0 BYTES
There are some pretty cool examples here!
What is really nice about this little "detour" is that we are all learning
some interesting interpretations of the Rebol words, and their use.
However, we need to keep in mind that we can't loose focus on the goal,
which is to write a model of the real problem...in the least number of
bytes. I condensed even further this one:
w: 100 print [loop w [w: w - first random [0 0 1]]]
Which, although a VERY COOL example of Rebol, is not a good example of the
problem.
This exact same problem in other languages would be just:
Matlab: sum(rand(100,1)>1/3)
C: for(int i=0,j=0;i<100;i++)j+=rand(3)>1;cout<1;}print $j
Rebol: w: 100 print [loop w [w: w - first random [0 0 1]]]
Does not look good for Rebol.
Not that I judge a language by its compatibility at all, but it is just
plain fun to compare, we are mostly boys after all.
So...
The problem stated clearly is:
Monty shows you three curtains.
Behind one curtain is a prize, the others nothing.
REBOL: Set up THREE variables in Rebol, 1 "different" than the other two.
Pick a door at random.
REBOL: Pick a variable at random.
Once picked, one of the doors will be revealed to you, which is guaranteed
to be empty.
REBOL: Search through the variables until an empty one is found, remove it
from the list. Or mark it in some manner.
Offer chance to switch.
REBOL: Always switch, and if percentage chance of receiving prize
("different") of the remaining two variables, print a statement, or even the
simple number which is the percentage chance of receiving the prize.
We have to include the spaces and the "rebol[]_" in our count. Just this
header is 8, since Rebol requires spaces. So use 1 letter variable names.
If you write something "tricky" then simply break it down in your email.
This will both prove that it is a good model, and teach the rest of us more
about the nature of writing good programs, and make yourself a god, all at
the same time!
If you think you have really modeled the problem correctly, and in the LEAST
number of bytes, then append the statement to the Subject line "IN n bytes."
Where n is the actual number you were able to achieve.
Reichart...
[EMAIL PROTECTED]
"Be useful."
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 17, 2001 6:40 AM
To: [EMAIL PROTECTED]
Subject: [REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle
Hi Joel,
> It seems to me that the problem in the original post was persuasion
> and not just computation. That being the case, the text of the
> program itself (or its derivation) should be a compelling argument
> for the right answer.
>
> IOW, if I had trouble understanding/accepting an answer, I would
> not be very persuaded simply by the output of a highly compact
> program that seemed to contain assumptions about the very answer
> I was having trouble with.
I completely agree that a highly compressed program isn't often a great way
to win an argument. But (just to defend myself for a moment) my attempt
embodied all the "rules": I picked a door; Monty picked an empty one of the
other two; I swap to his unopened one. No built-in assumptions there.
i also agree with an earlier post of yours (about Perl and parlor games).
The
best test of a programming language isn't how compact a program it can
write,
but (I would claim) how easy it is to write maintainable programs in it. But
even that tests mainly the design skills and long-term vision of the
programmer.
A good test of all of our (and Perl and Matlab) solutions is how easily can
they be modified as various "real world" changes are required. Almost by
definition, we can't know what our programs will face over there lifetimes,
but here are a few of the sort of things that might beset a Monty simulator:
-- Not three doors, but 10
-- Not 10 but 25 million doors (challenging many language implementations to
handle this as in-store arrays)
-- Monty opens more than one door
--there is more than one door with a car behind it
-- I get to pick more than one originally, but can only open ONE of mine, OR
one of his once Monty has opened the ones on his side
-- I get to pick more than one door, and Monty opens N of mine and M of his.
-- There are several prizes (a Saab and a Mercedes) including some booby
prizes (A tribe and a yugo maybe). Monty will open up to N doors at random;
I
can't win the prize behind an opened door; but I can tell him to stop at
any
moment, and then make my choice.
-- The program running as a CGI is so overwhelming popular that it is
swamping the server: rewrite it to use half the cpu cycles.
-- The government will buy 3,000,000 copies but only after the simulation is
run not 500 times but 500,000,000 times. (Rebol can handle this number, but
for most languages
Wins + 1 = Wins
for a sufficiently large value of Wins. If you exceed that, you need extra
special code).
I can
[REBOL] Re: BNF grammar of REBOL for code "obfuscator"
No need to PARSE it yourself. :)
REBOL knows all this stuff on it's own so let it do the work.
? load
...
REFINEMENTS:
/header -- Includes REBOL header object if present.
/next -- Load the next value only. Return block with value and new position.
/library -- Force file to be a dynamic library. (Command version)
/markup -- Convert HTML and XML to a block of tags and strings.
/all -- Load all values. Does not evaluate REBOL header.
Play around with load/header and load/next. The /all refinement is
recommended if you are working with an unknown script so that no
evaluation will happen.
To remove comments, just let REBOL remove them for you and try:
save %file2.r load %.file.r
I'm sure you'll get some more input on this from others too.
Sterling
> Hello REBOLers,
>
> I would like to write a code "obfuscator" (C-ish intention, isn't it ;-)) ) for
> REBOL. Tha main idea behind is to have a custom loader by
> 'COMPRESSing the program code and 'DECOMPRESS it on load, like this:
> - the "packager" REBOL line:
> write/binary %someprog.bin compress read %someprog.r
> - the shell loader (WinDOS .BAT file):
> rebol.exe -s --noinstall --do "do decompress read/binary %%someprog.bin quit"
>
> To get the unnecessary overhead data out of the script I would like to
> - strip the header to the simplest "REBOL []" form
> - extinct one-line and block comments
> - reduce tabulation and blank lines to single whitespace
>
> My first approach to detect the end of the REBOL header did not work:
> I just cannot keep track of the nested block levels in parse rules :-(
> I also stucked at detecting comment boundaries
> - to detect one-line comments whether they are _real_ comments
> or just ";" characters buried within a string (both "" and {} delimited)
> - detect 'COMMENT blocks (reprise of the previously mentioned
> detection problem for nested blocks)
>
> Do you have an exact BNF notation (or directly 'PARSE rules) of the
> REBOL language ? I searched the library but even %color-code.r is very
> spartanian and does not destructure a REBOL script this way (although
> its syntax coloring purpose might have suggested so).
>
> Thanx for your commitment of ideas!
>
>
> --
> Best regards,
> Geza Lakner MD mailto:[EMAIL PROTECTED]
>
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
[REBOL] BNF grammar of REBOL for code "obfuscator"
Hello REBOLers,
I would like to write a code "obfuscator" (C-ish intention, isn't it ;-)) ) for
REBOL. Tha main idea behind is to have a custom loader by
'COMPRESSing the program code and 'DECOMPRESS it on load, like this:
- the "packager" REBOL line:
write/binary %someprog.bin compress read %someprog.r
- the shell loader (WinDOS .BAT file):
rebol.exe -s --noinstall --do "do decompress read/binary %%someprog.bin quit"
To get the unnecessary overhead data out of the script I would like to
- strip the header to the simplest "REBOL []" form
- extinct one-line and block comments
- reduce tabulation and blank lines to single whitespace
My first approach to detect the end of the REBOL header did not work:
I just cannot keep track of the nested block levels in parse rules :-(
I also stucked at detecting comment boundaries
- to detect one-line comments whether they are _real_ comments
or just ";" characters buried within a string (both "" and {} delimited)
- detect 'COMMENT blocks (reprise of the previously mentioned
detection problem for nested blocks)
Do you have an exact BNF notation (or directly 'PARSE rules) of the
REBOL language ? I searched the library but even %color-code.r is very
spartanian and does not destructure a REBOL script this way (although
its syntax coloring purpose might have suggested so).
Thanx for your commitment of ideas!
--
Best regards,
Geza Lakner MD mailto:[EMAIL PROTECTED]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
[REBOL] Re: Odd behaviour when POSTing forms
Hi,
I'd really appreciate your decode-cgi-thingie, sounds great!
/Mvh Stefan Falk
MyTravel IT Support
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Tim Johnson
> Sent: den 14 december 2001 04:54
> To: [EMAIL PROTECTED]
> Cc: Falk Stefan, ITS-SL
> Subject: [REBOL] Re: Odd behaviour when POSTing forms
>
>
> On Thu, Dec 13, 2001 at 03:33:23PM +0100,
> [EMAIL PROTECTED] wrote:
> > Hi list,
> > been a while since I wrote here, so I thought it was about time.
> >
> > When sending a form with the POST method containing a >
> (a '>' sign but
> > anti-HTML-ized :) Rebol (or the webserver seem to convert
> it to a true '>'
> > sign. No matter what. Here's the code used to get the posted data:
> >
> >
> > get-posted-data: func [{Gets data transferred via the POST method}]
> > [
> > content-length: 20 + load system/options/cgi/content-length
> ; content length
> > with a little to spare
> > read-io system/ports/input data: make string!
> content-length content-length
> > data: make object! decode-cgi data
> > ]
> >
> > Is it the decode-cgi that's converting the character
> perhaps? Anyways,
> Hello Stefan:
> Yes. I would suspect that you are better off hand-rolling your
> own cgi decoding. I also believe that your data object will be
> mangled by decode-cgi if you have data or field names will
> embedded spaces.
> I could send you mine if you wish. Just give me
> a holler if that's what you want. My cgi library anticipates a few
> other gotchas too
> HTH
> Tim
> > 'Piece of cake!' I hear you lot scream, just add a
> replace/all ">" ">" in
> > the script that get the post data. But there's a problem,
> it shouldn't
> > convert the '>' signs in for example ... Why can't I
> just get to keep
> > my > dammit?! ;-)
> >
> > Thanks in advance
> >
> > /Regards Stefan Falk
> > www.amigaextreme.com
> > --
> > To unsubscribe from this list, please send an email to
> > [EMAIL PROTECTED] with "unsubscribe" in the
> > subject, without the quotes.
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
>
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
[REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle
Hi Joel, > It seems to me that the problem in the original post was persuasion > and not just computation. That being the case, the text of the > program itself (or its derivation) should be a compelling argument > for the right answer. > > IOW, if I had trouble understanding/accepting an answer, I would > not be very persuaded simply by the output of a highly compact > program that seemed to contain assumptions about the very answer > I was having trouble with. I completely agree that a highly compressed program isn't often a great way to win an argument. But (just to defend myself for a moment) my attempt embodied all the "rules": I picked a door; Monty picked an empty one of the other two; I swap to his unopened one. No built-in assumptions there. i also agree with an earlier post of yours (about Perl and parlor games). The best test of a programming language isn't how compact a program it can write, but (I would claim) how easy it is to write maintainable programs in it. But even that tests mainly the design skills and long-term vision of the programmer. A good test of all of our (and Perl and Matlab) solutions is how easily can they be modified as various "real world" changes are required. Almost by definition, we can't know what our programs will face over there lifetimes, but here are a few of the sort of things that might beset a Monty simulator: -- Not three doors, but 10 -- Not 10 but 25 million doors (challenging many language implementations to handle this as in-store arrays) -- Monty opens more than one door --there is more than one door with a car behind it -- I get to pick more than one originally, but can only open ONE of mine, OR one of his once Monty has opened the ones on his side -- I get to pick more than one door, and Monty opens N of mine and M of his. -- There are several prizes (a Saab and a Mercedes) including some booby prizes (A tribe and a yugo maybe). Monty will open up to N doors at random; I can't win the prize behind an opened door; but I can tell him to stop at any moment, and then make my choice. -- The program running as a CGI is so overwhelming popular that it is swamping the server: rewrite it to use half the cpu cycles. -- The government will buy 3,000,000 copies but only after the simulation is run not 500 times but 500,000,000 times. (Rebol can handle this number, but for most languages Wins + 1 = Wins for a sufficiently large value of Wins. If you exceed that, you need extra special code). I can see how my solution will naturally extend for some of these; can be bodged into shape for others; and would be scrapped and rewritten for the rest. And that's programming! Sunanda. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Can a script run another script?
Thanks Gregg, for pointing out the 'launch command. I hadn't noticed it before. It works great in simples scripts like ... view layout [button [launch %feedback.r]] But I have a larger script whose relevant contents boils down to this ... output: make object! [ file: %feedback.r ] view layout [ button "Do Script!" [ if script? output/file [ launch output/file ] ] ] The above works as a script unto itself, but within the larger script, I get the following error message... "Launch can only be used by launcher programs" in a REBOL/View Dialog Box. Since 'launch is undocumented, do you know what this error means? -- ___ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup 1 cent a minute calls anywhere in the U.S.! http://www.getpennytalk.com/cgi-bin/adforward.cgi?p_key=RG9853KJ&url=http://www.getpennytalk.com -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: A Rebol Challenge. The Monty Hall Puzzle
On 17-Dec-01, Carl Read wrote: > Not being a statistician, (or having a clue what the above code > does:), my approach to such problems is to simulate them many times > and see if there's a noticable difference in the results. So here's > my code to do that, but it may be bugged as it wasn't giving the > results I was expecting. But then, what's expected is not what we're > supposed to get, right? (: > rebol[]k: s: 0 r: func[n][random n]a: does[p: r 3 c: r 3 p = c] > loop 1 [if a[k: k + 1]if if not a[r 2 = 1][s: s + 1]]print > ["Kept" k "Switched" s] > I especially like the "if if" as it sounds like an accurate > description of my code. (: Anyway, it's 151 bytes long for what it's > worth. I thought the above was bugged, and it was. Here's a fixed version... rebol[]k: s: 0 r: func[n][random n]m: does[p: r 3 c: r 3 p = c] loop 1 [if m[k: k + 1]if not m[s: s + 1]]print ["Kept" k "Switched" s] Nowhere near as short as some of the other posts, but anyway, here's my reasoning behind it... The prize is placed behind one of 3 doors... prize: random 3 You choose one of the doors... chosen: random 3 Now, Monty can see if they're a match - ie, if you've picked a winner... matched?: prize = chosen Which returns true if you've chosen the prize. If you decide to keep this then it's obvious (I hope:) that you had 1 chance in 3 of picking the prize. But what if you accept Monty's offer to switch? Well, there's only two posibilities: 1) You'd chosen the prize, so switching from that means you lose regardless of what Monty does. 2) You hadn't chosen the prize, Monty exposes the other losing door, and so you switch to the winning door. So a switch always means a reversal of your original choice - a winning choice becoming a losing one and vice-versa. So... matched?: not matched? But what happens to the "1 chance in 3 of picking the prize."? Well that also means you had 2 chances in 3 of losing, right? And the switch makes an original loss a win, so switching gives you 2 chances in 3 of winning, thus doubling your chances of a win. Note that I originally (though vaguely) thought switching would improve your chances from 1 in 3 to 1 in 2, but this result is much more fun. (: -- Carl Read -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
