[REBOL] Over 70 REBOL Experimental Binaries Available Re:(2)
Still lookin' for the BeOS /View binary. 8-) >Hi Carl, > >just two comments: > >1) Hope Windoze version will be up anytime soon too :-) >2) I would also like to hope you will solve "what's new, what's got >fixed, known bugs" descriptions - it would be very handy ... > >Cool system anyway ... > >-pekr- > > > >
[REBOL] Over 70 REBOL Experimental Binaries Available Re:
Hi Carl, just two comments: 1) Hope Windoze version will be up anytime soon too :-) 2) I would also like to hope you will solve "what's new, what's got fixed, known bugs" descriptions - it would be very handy ... Cool system anyway ... -pekr-
[REBOL] REBOL Article from O'reilly
New REBOL article to check out: "Mining the Web with REBOL" http://www.oreillynet.com/pub/a/network/2000/07/21/querying.html
[REBOL] Words, Bindings and Contexts. (7) Re:(2)
>l> I see, that the fact, that my series didn't explain the >l> behaviour of functions WRT Recursion and Binding is a flaw. l> Here is >the continuation (a model of the behaviour): [...] > >I just want to say that I agree with this model. This is the closest >representation of REBOL's function context handling IMHO. > >OTOH, I'd like to understand why Carl considers the current behaviour a >bug, while I was convinced this was by design. Me too... I rather like the current behavior and have been writing scripts that will probably break if it is changed. I feel that the current STATIC binding is an excellent feature, and even if it was a bug, it should be kept and documented. - Cal ([EMAIL PROTECTED]) -><- Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
[REBOL] Over 70 REBOL Experimental Binaries Available Re:
Hey!! This is really exciting Carl! And and I can just barely imagine how much work this must be to set this all up. Here's a thought something that programmers might pay some money for... The ability to compile Rebol binaries into C, C++ etc. It would extend legacy code with all of rebols features. I'd sure like to be able to do that with either Windows or Linux Platforms. I could foresee testing code with the interpreter, with all of those advantages, then compiling it into an executable, with those advantages. Best of both worlds, y'think? Keep up the good work! Regards Tim At 05:48 PM 7/26/00 -0700, you wrote: >Over 70 REBOL Experimental Binaries Available > >Hello all: > >We are proud to announce the launching of the REBOL >experimental build process. > >In order to improve our testing process, we have >developed (using REBOL of course) a fully automated >build and release pipeline that allows us to put out >software more often. With the press of a key we are now >able to rebuild and upload experimental versions of >REBOL that contain the latest bug fixes and enhancements. >You benefit from more frequent releases. We benefit >from the testing and feedback that you provide. > >At this time, over 70 separate REBOL binaries are being >made available from our automated build system, and you >can download these binaries directly from our web site. > >However, in order to achieve this more rapid software >release process, some sacrifices are required: > >The experimental builds have only received rudimentary >testing before being published. Also, at this time we >have not enacted an automated process to track the >changes evident in these versions of REBOL, so the >features of the build may not be immediately apparent. > >Additionally, some of the builds may not be equivalent >in some features to others. Some of the experimental >REBOL/command builds do not all have database >connectivity, and the type of database connectivity may >differ across platforms. > >The experimental builds contain bug fixes for some >commonly reported problems. Please submit bug >reports for all problems you encounter using the >experimental builds. > >All files are provided under license of our end user >license agreement and beta test agreements. Currently, >our experimental builds have 30 day beta expiration >periods. > >The list of experimental builds can be found at: > > http://www.rebol.com/xpers/xpers.html > >We don't expect these experimental builds to be >Frankensteins or anything. They're likely to be as >stable as the last release of REBOL, but with anything >experimental: use at your own risk. > >REBOL team > >
[REBOL] Over 70 REBOL Experimental Binaries Available Re:
YESS! Bless you for the BDSI releases! --Ralph >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, July 26, 2000 8:49 PM >To: [EMAIL PROTECTED] >Subject: [REBOL] Over 70 REBOL Experimental Binaries Available > > >Over 70 REBOL Experimental Binaries Available > >Hello all: > >We are proud to announce the launching of the REBOL >experimental build process. > >In order to improve our testing process, we have >developed (using REBOL of course) a fully automated >build and release pipeline that allows us to put out >software more often. With the press of a key we are now >able to rebuild and upload experimental versions of >REBOL that contain the latest bug fixes and enhancements. >You benefit from more frequent releases. We benefit >from the testing and feedback that you provide. > >At this time, over 70 separate REBOL binaries are being >made available from our automated build system, and you >can download these binaries directly from our web site. > >However, in order to achieve this more rapid software >release process, some sacrifices are required: > >The experimental builds have only received rudimentary >testing before being published. Also, at this time we >have not enacted an automated process to track the >changes evident in these versions of REBOL, so the >features of the build may not be immediately apparent. > >Additionally, some of the builds may not be equivalent >in some features to others. Some of the experimental >REBOL/command builds do not all have database >connectivity, and the type of database connectivity may >differ across platforms. > >The experimental builds contain bug fixes for some >commonly reported problems. Please submit bug >reports for all problems you encounter using the >experimental builds. > >All files are provided under license of our end user >license agreement and beta test agreements. Currently, >our experimental builds have 30 day beta expiration >periods. > >The list of experimental builds can be found at: > > http://www.rebol.com/xpers/xpers.html > >We don't expect these experimental builds to be >Frankensteins or anything. They're likely to be as >stable as the last release of REBOL, but with anything >experimental: use at your own risk. > >REBOL team >
[REBOL] Over 70 REBOL Experimental Binaries Available
Over 70 REBOL Experimental Binaries Available Hello all: We are proud to announce the launching of the REBOL experimental build process. In order to improve our testing process, we have developed (using REBOL of course) a fully automated build and release pipeline that allows us to put out software more often. With the press of a key we are now able to rebuild and upload experimental versions of REBOL that contain the latest bug fixes and enhancements. You benefit from more frequent releases. We benefit from the testing and feedback that you provide. At this time, over 70 separate REBOL binaries are being made available from our automated build system, and you can download these binaries directly from our web site. However, in order to achieve this more rapid software release process, some sacrifices are required: The experimental builds have only received rudimentary testing before being published. Also, at this time we have not enacted an automated process to track the changes evident in these versions of REBOL, so the features of the build may not be immediately apparent. Additionally, some of the builds may not be equivalent in some features to others. Some of the experimental REBOL/command builds do not all have database connectivity, and the type of database connectivity may differ across platforms. The experimental builds contain bug fixes for some commonly reported problems. Please submit bug reports for all problems you encounter using the experimental builds. All files are provided under license of our end user license agreement and beta test agreements. Currently, our experimental builds have 30 day beta expiration periods. The list of experimental builds can be found at: http://www.rebol.com/xpers/xpers.html We don't expect these experimental builds to be Frankensteins or anything. They're likely to be as stable as the last release of REBOL, but with anything experimental: use at your own risk. REBOL team
[REBOL] RT Convention/conference. Re:
- Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 27, 2000 5:06 AM Subject: [REBOL] RT Convention/conference. > Hello, > > I think it's about time that RT organised a convention/conference and > brought together in one place, all the talented people that are actively > involved in promoting REBOL. > > It would be wonderful to see and hear people like Elan, Gabriele, Julian, > Allen, Brett, Volker, Pekr, Ladislav, Brian, Larry, ... (my apologies for > any ommissions) discussing REBOL, together with all the great folks from > RT. > > Just a thought. > > Mike. > > Pay for my ticket and I'm there :-) Cheers, Allen K
[REBOL] Words, Bindings and Contexts. (7) Re:(2)
Hi, > HI Ladislav > > Very cool! Use of simulated behavior (implemented in REBOL) is a concise > and precise way of expressing one's thoughts about the workings of REBOL > functions. I find it much more informative than lengthy attempts to > describe in ordinary language how functions work. > > I have followed your Words, Bindings, and Contexts posts with great > interest. I have learned a lot from your discussions and hope to see more. > Just a couple of quick questions: > > Can you say more about Dangerous Contexts? For instance: > >> f: func [x][return x] > >> first :f > == [x] > >> type? first first :f > == word! > >>value? first first :f;REBOL crashes on any attempt to examine the > words in first :f > > Isn't this just a bug in REBOL? Why does it not return an error instead of > crash? > > How about a modifying to sim-func to allow handling of /local and > refinements? Then it would be a more complete model of func. > > Thank you again for sharing this excellent material. > > -Larry > > 1) I think, that every Rebol Context becomes Dangerous after being Garbage Collected while still accessible, ie. Dangerous Contexts may be just "Ghost Contexts" of once normal Rebol Contexts... 2) My intent was to describe the Rebol Context Handling and the refinements would complicate the code beyond the limit I considered acceptable. (BTW, if you consider Sim-function/spec as containing all Function Context's Words ie. Arguments, Refinements, Words specified as /local, everything holds, the things that should be added are the examination of a call-path used, a code to supply None as the value for respective Function Context's Words, a code for spec parsing and the type checking code.) .
[REBOL] Bug in 'use? Re:(12)
Hi, Gabriele: > >Then the BIND function is called to bind > Elan: > Metaphorically speaking? I have never seen the bind function called during > the construction of a function. If you source func and function, you will > find that neither of these mezzanine functions call bind. They both use > make function! ... and I have no access to the code that is executed when > make function! is called. You have never seen just because you didn't try. See the following: code-block: [ f: func [f-arg] [ g: func [g-arg] [ print [g-arg f-arg global-word] ] g "This is g's argument." ] ] do code-block f-body: second :f f-body-f-arg: probe second second fourth f-body f-body-template: fourth code-block bound-f-body-template: bind/copy f-body-template f-body-f-arg same? first bound-f-body-template first f-body same? second bound-f-body-template second f-body same? first third bound-f-body-template first third f-body same? first fourth bound-f-body-template first fourth f-body same? first second fourth bound-f-body-template first second fourth f-body same? second second fourth bound-f-body-template second second fourth f-body But: same? second second fourth f-body-template second second fourth f-body Ladislav
[REBOL] RT Convention/conference. Re:
Will RT have a booth at any upcoming conventions? > Hello, > > I think it's about time that RT organised a convention/conference and > brought together in one place, all the talented people that are actively > involved in promoting REBOL. > > It would be wonderful to see and hear people like Elan, Gabriele, Julian, > Allen, Brett, Volker, Pekr, Ladislav, Brian, Larry, ... (my apologies for > any ommissions) discussing REBOL, together with all the great folks from > RT. > > Just a thought. > > Mike. > > > >
[REBOL] RT Convention/conference.
Hello, I think it's about time that RT organised a convention/conference and brought together in one place, all the talented people that are actively involved in promoting REBOL. It would be wonderful to see and hear people like Elan, Gabriele, Julian, Allen, Brett, Volker, Pekr, Ladislav, Brian, Larry, ... (my apologies for any ommissions) discussing REBOL, together with all the great folks from RT. Just a thought. Mike.
[REBOL] Extracting Data From Eudora Re:(2)
Thanks!! Just what I needed :) Tim At 02:12 PM 7/26/00 -0400, you wrote: > >try http://www.rebol.com/library/script-text.html (the fourth item down) >or try http://www.rebol.com/library/html/mbxsubjects.html > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, July 26, 2000 1:05 PM >To: [EMAIL PROTECTED] >Subject: [REBOL] Extracting Data From Eudora > > >Hello: >I seem to recall that there is a script to >parse data from a Eudora Mailbox. Does any >one know of such a script and/or it's location? >Thanks >Tim > >
[REBOL] cgi and normal scripts Re:
If you send me input-cgi.r, I'll take a look at it and offer some suggestions if you like. I do a bit of CGI. -Tim At 10:09 AM 7/26/00 +0100, you wrote: >Hey list, > >I have a cgi question for you. If you want to use cgi with REBOL, >do you have to start out with that intention, or can you cgi-ize >a regular script? more specifically, I want to use the various >fields of a form as input for a "normal" script. "input-cgi.r" seems perfect. > >can someone spare some tips? >-- > >Turn your computer off. Go outside. >-tom > >
[REBOL] Anyone doing something with LDAP? Re:(5)
Actually, now I wnloaded both books. One is about 400 pages (zipped - PDF) The other is over 500 pages (zipped - PDF) That is about $60.00 - $80.00 worth of books about ASN.1 for FREE. This morning, all I wanted was LDAP.r Now I have the vision for ber.r, der.r, per.r and xer.r Hey jeff, carl, team - this is good stuff, if you a need some good literature on ASN.1 Protocol implementation is what will make rebol community grow! -Original Message- From: Vos, Doug Sent: Wednesday, July 26, 2000 2:26 PM To: [EMAIL PROTECTED] Subject: [REBOL] Anyone doing something with LDAP? Re:(4) I found an excellent 500 page book on ASN.1 which is the basis for LDAP and SNMP, etc. http://www.oss.com/asn1/booksintro.html There are actually 2 full length books on ASN.1 for any REBOL LDAP, SNMP guru-wann-be's out there. -Original Message- From: Vos, Doug Sent: Wednesday, July 26, 2000 8:44 AM To: [EMAIL PROTECTED] Subject: [REBOL] Anyone doing something with LDAP? Re:(3) OK, I also found the BER modules in perl. Looks like it won't be too much trouble to' implement in rebol. Do you have any more pointers on BER, ASN.1, and TLV.? A good RFC, web-page-url, etc -- about BER? Then it sounds like I should write the BER.r script first and next make the LDAP.r Or maybe I should do it in REBOL/command -- when will that be shipping? 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] Extracting Data From Eudora Re:
There are 3 scripts in the Script Library relating to Eudora. They can be found using the "Search Script Library" under the "For Developers" section of www.rebol.com. Mike.
[REBOL] cgi and normal scripts Re:(2)
Ooops .. should have been When the server runs the script, it sets a bunch of environment variables, and can also send user variables to the script via standard input. *** REPLY SEPARATOR *** On 7/26/2000 at 2:10 PM [EMAIL PROTECTED] wrote: A CGI script is a script that is run by the Web server, in response to a request from a Web page - either from a form or from a hyperlink. When the server runs the script, it sends a bunch of environment variables to the script via standard input. It also directs anything the scripts sends back via standard output to the browser (rather than the consol). This is the Common Gateway Interface, or CGI. A CGI-aware scripting language, like REBOL, can read the environment variables the Web server sets, and use them in the script. So to CGI-ize a script, you "just" need to write it so it takes input from the CGI variables, and writes to standard output the same way a server would send back a Web page. (For example, a simple header to identify the document type, and then straight HTML). It's otherwise a normal script, running as the user who started the HTTP service. -Ted. *** REPLY SEPARATOR *** On 7/26/2000 at 10:09 AM [EMAIL PROTECTED] wrote: Hey list, I have a cgi question for you. If you want to use cgi with REBOL, do you have to start out with that intention, or can you cgi-ize a regular script? more specifically, I want to use the various fields of a form as input for a "normal" script. "input-cgi.r" seems perfect. can someone spare some tips? -- Turn your computer off. Go outside. -tom
[REBOL] Words, Bindings and Contexts. (7) Re:
HI Ladislav Very cool! Use of simulated behavior (implemented in REBOL) is a concise and precise way of expressing one's thoughts about the workings of REBOL functions. I find it much more informative than lengthy attempts to describe in ordinary language how functions work. I have followed your Words, Bindings, and Contexts posts with great interest. I have learned a lot from your discussions and hope to see more. Just a couple of quick questions: Can you say more about Dangerous Contexts? For instance: >> f: func [x][return x] >> first :f == [x] >> type? first first :f == word! >>value? first first :f;REBOL crashes on any attempt to examine the words in first :f Isn't this just a bug in REBOL? Why does it not return an error instead of crash? How about a modifying to sim-func to allow handling of /local and refinements? Then it would be a more complete model of func. Thank you again for sharing this excellent material. -Larry - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 25, 2000 1:37 PM Subject: [REBOL] Words, Bindings and Contexts. (7) > I see, that the fact, that my series didn't explain the behaviour > of functions WRT Recursion and Binding is a flaw. Here is the > continuation (a model of the behaviour): > > ; Model of Rebol function: > ; snip--
[REBOL] Anyone doing something with LDAP? Re:(4)
I found an excellent 500 page book on ASN.1 which is the basis for LDAP and SNMP, etc. http://www.oss.com/asn1/booksintro.html There are actually 2 full length books on ASN.1 for any REBOL LDAP, SNMP guru-wann-be's out there. -Original Message- From: Vos, Doug Sent: Wednesday, July 26, 2000 8:44 AM To: [EMAIL PROTECTED] Subject: [REBOL] Anyone doing something with LDAP? Re:(3) OK, I also found the BER modules in perl. Looks like it won't be too much trouble to' implement in rebol. Do you have any more pointers on BER, ASN.1, and TLV.? A good RFC, web-page-url, etc -- about BER? Then it sounds like I should write the BER.r script first and next make the LDAP.r Or maybe I should do it in REBOL/command -- when will that be shipping? 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] Bug in 'use? Re:(12)
Hi, The discussed code: f: func [f-arg] [ g: func [g-arg] [ print [g-arg f-arg global-word] ] g "This is g's argument." ] Gabriele: > >So when F is created > >the block: > > > > [ > >print [g-arg f-arg global-word] > > ] > > > >gets bound to F's context; more precisely, > >the word "f-arg" gets > >bound to F's context, while "print", "g-arg" and "global-word" > >aren't changed (so they're still bound to the global context). > Elan: > I think this is a conceptual problem. There is no g-arg defined in the > global context. Accordingly "g-arg" was never bound to the global context. > Therefore "g-arg" cannot "still" be bound to the global context. Here is a proof: >> global? probe first second fourth second :f g-arg == true Regards Ladislav
[REBOL] Extracting Data From Eudora Re:
try http://www.rebol.com/library/script-text.html (the fourth item down) or try http://www.rebol.com/library/html/mbxsubjects.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 26, 2000 1:05 PM To: [EMAIL PROTECTED] Subject: [REBOL] Extracting Data From Eudora Hello: I seem to recall that there is a script to parse data from a Eudora Mailbox. Does any one know of such a script and/or it's location? Thanks Tim
[REBOL] cgi and normal scripts Re:
A CGI script is a script that is run by the Web server, in response to a request from a Web page - either from a form or from a hyperlink. When the server runs the script, it sends a bunch of environment variables to the script via standard input. It also directs anything the scripts sends back via standard output to the browser (rather than the consol). This is the Common Gateway Interface, or CGI. A CGI-aware scripting language, like REBOL, can read the environment variables the Web server sets, and use them in the script. So to CGI-ize a script, you "just" need to write it so it takes input from the CGI variables, and writes to standard output the same way a server would send back a Web page. (For example, a simple header to identify the document type, and then straight HTML). It's otherwise a normal script, running as the user who started the HTTP service. -Ted. *** REPLY SEPARATOR *** On 7/26/2000 at 10:09 AM [EMAIL PROTECTED] wrote: Hey list, I have a cgi question for you. If you want to use cgi with REBOL, do you have to start out with that intention, or can you cgi-ize a regular script? more specifically, I want to use the various fields of a form as input for a "normal" script. "input-cgi.r" seems perfect. can someone spare some tips? -- Turn your computer off. Go outside. -tom
[REBOL] Re: Bug in 'use? Re:(11)
Hello [EMAIL PROTECTED]! On 26-Lug-00, you wrote: r> I've set up a mailing list on my Web server for the book (for r> bug fixes and clarifications and ongoing discussions). Good. I think I'll subscribe eventually. :-) Anyway, I'm quite sure it'll be very difficult to find bugs in your book. :-) r> After reading your email carefully, my impression is that our r> main discrepancy has to do with perspective. I view REBOL as a r> programming language, and I think about REBOL in terms of r> concepts, principles that lend themselves to describe how r> REBOL acts as a language. r> In contrast, you apparently think about REBOL as an r> interpreter implementation. You tend to speculate about how r> the REBOL interpreter is likely to implement some language r> feature. This is likely to be right. OTOH, the presence or not of a hierarchy of contexts might make some differences if you're using BIND in your script; also, the fact that the binding is static makes it possible to mix words from different contexts in the same block and run that block "outside" of those contexts. This is rarely done currently only because of the (in)famous GC bug. r> Carl commented on a similar example you provided while binding r> a block to an embedded object, and declared the bind behavior r> you demonstrated to be a bug. He didn't clarify, and I will r> rely on his response Yup, and this really confuses me. If you think about it, the current behaviour makes sense, and the model proposed by me, Ladislav and Brian greatly simplifys the runtime environment of the interpreter as opposed to a dynamic lookup and a hierarchy of contexts. [...] r> Hierarchic context table inheritance r> is REBOL's intended behavior. But well, it never worked this way since 2.0. It really seems very strange to me that Carl didn't notice before; I really hope he'll clarify on this. r f-arg: "Global f-arg!" r>> == "Global f-arg!" r print bind [g-arg f-arg global-word] g's-context-word r>> This is g's argument. Global f-arg! This is the global word. r>> r>> So, how does it work when calling F? When F is created, a new r>> context table is created. r> Thank you. I went to pains to demonstrate that. I never meant to negate this. I'm sorry if I seemed to. You know, I'd still need some English lessons. :-) r>> Then the BIND function is called to bind r> Metaphorically speaking? I have never seen the bind function r> called during the construction of a function. If you source r> func and function, you will find that neither of these r> mezzanine functions call bind. They both use make function! r> ... and I have no access to the code that is executed when r> make function! is called. I mean that MAKE FUNCTION! internally calls the same C routine called by the native BIND function. r> I think this is a conceptual problem. There is no g-arg r> defined in the global context. Accordingly "g-arg" was never r> bound to the global context. Therefore "g-arg" cannot "still" r> be bound to the global context. This is wrong. Look: >> f: func [f-arg] [ [ g: func [g-arg] [ [print [g-arg f-arg global-word] [ ] [ g "This is g's argument." [] >> print mold first system/words [end! ... f f-arg g g-arg global-word] ; snipped for brevity There's a global g-arg, and its value is: >> type? get/any 'g-arg == unset! r>> When F is executed, the function G is created, and thus the r>> block above gets bound to G's context. Again, only the word r>> "g-arg" is affected, while "print" and "global-word" are left r>> bound to the global context and "f-arg" to F's context. r> Thank you. Note what you are saying here. You are looking at r> this from a different perspective, an implementation r> perspective, - nevertheless - you are formulating a mechanism r> that exactly results in context inheritance. Indeed, what I said before is that "context inheritance" is just a side effect in the current implementation, not the result of a memory structure that can be identified as a "Context Hierarchy". You're absolutely right that mine is an implementation perspective, but there's a huge difference between a model based on dynamic word lookups and a model based on static word bindings. r> Your r> implementation view (though speculative, but reasonable) r> supports my conceptual representation, don't you think? Yes. But you get different results when you're using BIND manually. r> Now "No hierarchy NEEDED" has become the "same" as proving r> "there's no hierarchy here:"? After describing a speculative r> process (albeit a reasonable one) that brings about a r> behavior, which can be described - with precision - as a r> context table hierarchy, you have lowered your attack from "I r> can prove that there is no context hierarchy" to "no hierarchy r> needed"? Oh, don't be so picky. :-) I cannot know what REBOL actually does, I'm just proposing the most reasonable model. And that model
[REBOL] Re: Words, Bindings and Contexts. (7)
Hello [EMAIL PROTECTED]! On 25-Lug-00, you wrote: l> I see, that the fact, that my series didn't explain the l> behaviour of functions WRT Recursion and Binding is a flaw. l> Here is the continuation (a model of the behaviour): [...] I just want to say that I agree with this model. This is the closest representation of REBOL's function context handling IMHO. OTOH, I'd like to understand why Carl considers the current behaviour a bug, while I was convinced this was by design. Still losing messages, Gabriele. -- Gabriele Santilli <[EMAIL PROTECTED]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[REBOL] Bug in 'use? Re:(12)
Hi Elan, you wrote: > (...) > I conclude from Carl's comment that > bind's intended behavior is to bind the block such that all words that > occur in the block behave as they would, if the block had been defined in > the context it is being bound to. > > I.e. if print [g-arg f-arg global-word] evaluated in the g function's > context were to generate > > This is g's argument. This is f's argument. This is the global word. > > then > > print bind [g-arg f-arg global-word] g's-context-word > > should generate the same result. If it doesn't, then it is - in Carl's > words - a bug. Hierarchic context table inheritance is REBOL's intended > behavior. > I think, that here is the main difference between your "Mental Model Approach" and our approach: We, not having the official description, are writing the description of Rebol behaviour, while you are trying to describe the "Intended Behaviour", that surely differs. Problem with your approach is, that you neither know the Rebol "Intended Behaviour" not being its creator, nor are able to correctly describe the actual behaviour, because you don't even try to do it. Regards Ladislav > >>> f-arg: "Global f-arg!" > >== "Global f-arg!" > >>> print bind [g-arg f-arg global-word] g's-context-word > >This is g's argument. Global f-arg! This is the global word. > > > >So, how does it work when calling F? When F is created, a new > >context table is created. > > Thank you. I went to pains to demonstrate that. > > >Then the BIND function is called to bind > > Metaphorically speaking? I have never seen the bind function called during > the construction of a function. If you source func and function, you will > find that neither of these mezzanine functions call bind. They both use > make function! ... and I have no access to the code that is executed when > make function! is called. > > >the body block to that context table (this means binding each word > >in the block and the blocks (any-block!s actually) it contains, > >but only if present in the context table). > >So when F is created > >the block: > > > > [ > >print [g-arg f-arg global-word] > > ] > > > >gets bound to F's context; more precisely, > >the word "f-arg" gets > >bound to F's context, while "print", "g-arg" and "global-word" > >aren't changed (so they're still bound to the global context). > > I think this is a conceptual problem. There is no g-arg defined in the > global context. Accordingly "g-arg" was never bound to the global context. > Therefore "g-arg" cannot "still" be bound to the global context. > > > > >When F is executed, the function G is created, and thus the block > >above gets bound to G's context. Again, only the word "g-arg" is > >affected, while "print" and "global-word" are left bound to the > >global context and "f-arg" to F's context. > > Thank you. Note what you are saying here. You are looking at this from a > different perspective, an implementation perspective, - nevertheless - you > are formulating a mechanism that exactly results in context inheritance. > > You may dislike the term "context (table) inheritance", but I think it > expresses the fact quite well that words used - but not defined - in an > embedded function, are interpreted in the context of their parent function > - provided they are defined in that function. Or in their immediate > parent's parent function ... until the global context is reached. Your > implementation view (though speculative, but reasonable) supports my > conceptual representation, don't you think? > > > > >The result is what you expect, with "f-arg" bound to F's context, > >"g-arg" bound to G's context and "global-word" bound to the global > >context, but this is only a (wanted) side effect of REBOL static > >binding. > > > > r> Example 2 for Context Hierarchy: > > > >[...] > > > >The same goes here. No hierarchy needed. > > No hierarchy "needed"? Did you not begin by claiming in your previous email > > >Anyway, I can prove that there is no context hierarchy: > > then continue by saying in this email > > >So, let's prove there's no hierarchy here: > > Now "No hierarchy NEEDED" has become the "same" as proving "there's no > hierarchy here:"? After describing a speculative process (albeit a > reasonable one) that brings about a behavior, which can be described - with > precision - as a context table hierarchy, you have lowered your attack from > "I can prove that there is no context hierarchy" to "no hierarchy needed"? > > Perhaps having thought through a process through which REBOL's hierarchical > context behavior may be implemented, your opposition to this concept has > become weaker, from proving "there's no hierarchy" to avoiding the > hierarchy use of the word hierarchy, "no hierarchy needed"? > > Your speculation regarding the binding of words during the function's > construction is only reasonable, because we know already, that the > construction will eventually have to lead to a behavior that is consistent > with the observable hi
[REBOL] APL'ish operations Re:(5)
Hi, > I was thinking in terms of function projection. Take a > binary function (like + ), fix one of the arguments > (5) and create a monadic (?) function that can be > applied to say a vector. Sorry if all this seems like > elementary stuff, I'm just starting with REBOL and > exploring the possibilities. > It is not that elementary, but with a help of http://www.rebol.org/advanced/highfun.r you can do: block-add-5: mapper (do curry :add 1 5) >> block-add-5 [1 2 3] == [6 7 8] Regards Ladislav > --- [EMAIL PROTECTED] wrote: > > > Perfect. Just what I needed. Wish there was a way > > to > > > make simple one-off functions in a block like [ + > > 5] > > > etc. > > > > > > > I think you can. Again according to what you need. > > This is where Rebol > > shines. Rebol gives you the ability to interpret > > blocks (and strings) in way > > other than the default provided by Rebol. That is, > > according to your own > > grammar. Rebol calls this a dialect. Admittedly this > > is not straight-forward > > when you're beginning with Rebol. On the other-hand > > once you have done this > > a few times, you will see opportunities for it > > everywhere and discover that > > it really is not as complex as it sounds. > > > > One way to achieve this is to interpret a block by > > stepping through it and > > checking types then doing something. Another way is > > to use the parse > > function of rebol. Parse takes a string or a block > > as input plus a grammar > > specification that will interpret your input > > according to rules. > > > > So to your example. > > What would [+ 5] actually do and how would it be > > used? > > > > Brett. > > > > > > > = > > > __ > Do You Yahoo!? > Get Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ > >
[REBOL] Extracting Data From Eudora
Hello: I seem to recall that there is a script to parse data from a Eudora Mailbox. Does any one know of such a script and/or it's location? Thanks Tim
[REBOL] Bug in 'use? Re:(3)
The following has been written: > > Hi Ladislav, 15-Jul-2000 you wrote: > > > > >you are right, the problem is caused by a context > manipulation - > > >Use unsets your Middle every time it gets executed. My > suggestion > > >is to not use Use in recursive functions, while this problem > > >doesn't get corrected. > > > > Judging from the nature of recursiveness, that's a little hard, > isn't it? ;-) > > > > Do you know if this problem has already been reported to > feedback? > > > > Kind regards, > > -- > > Ole Friis <[EMAIL PROTECTED]> > > here is a pretty simple example showing the problem: temporary: "global temporary" recfun: func [level] [ use [temporary] [ if level < 1 [ temporary: "temporary" recfun level + 1 print ["Temporary:" temporary] ] ] ] recfun 0 ; The result: ** Script Error: temporary has no value. ** Where: temporary ; let's define a function r-use like this: r-use: func [ "Defines words local to a block." words [block!] "Local word(s) to the block" body [block!] "Block to evaluate" ] [ do function [] words body ] ; and now use R-use instead of native Use temporary: "global temporary" recfun: func [level] [ r-use [temporary] [ if level < 1 [ temporary: "temporary" recfun level + 1 print ["Temporary:" temporary] ] ] ] recfun 0 ; The result: Temporary: temporary Ladislav
[REBOL] Re: highfun.r
Hi Brett, the script can be found at http://www.rebol.org/advanced/highfun.r Regards Ladislav > Hi Ladislav, > > I cannot seem to find the script highfun.r in either www.rebol.com or > www.rebol.org > I have a copy and find it very useful. I suspect others would too. So just > wondering if you would not mind posting up to one of these sites? > > Brett. > >
[REBOL] cgi and normal scripts Re:
You could either append input-cgi.r with your "normal" script and run it all together -or- you could 'do other scripts from input-cgi.r > Hey list, > > I have a cgi question for you. If you want to use cgi with REBOL, > do you have to start out with that intention, or can you cgi-ize > a regular script? more specifically, I want to use the various > fields of a form as input for a "normal" script. "input-cgi.r" seems > perfect. > > can someone spare some tips? > -- > > Turn your computer off. Go outside. > -tom >
[REBOL] cgi and normal scripts
Hey list, I have a cgi question for you. If you want to use cgi with REBOL, do you have to start out with that intention, or can you cgi-ize a regular script? more specifically, I want to use the various fields of a form as input for a "normal" script. "input-cgi.r" seems perfect. can someone spare some tips? -- Turn your computer off. Go outside. -tom
[REBOL] Easy to use Database function Re:
I use a system which may not be the best solution but it works in my head space. On my news Web site, the common denominator is the news article, including the headline, byline, body copy, etc. This then is the basic value to be stored. Each news article is saved in a text file as an object expression so that the values can be loaded and objects can be created on the fly. Each object expression has a "reference-id" which matches the name of the file. The "reference-id" is based on the time the file was created in digits (e.g. 27251762). Since file creation is automated, this assures there will never be a file or object of the same name (wait 1 is used to keep it incremental.) Articles can be commented on. Comments are saved in the same fashion, with their own reference-ids which match the name of the file containing the comments in an object expression. The comments relate to a specific article by being saved in a directory with the same name as the article that the comments reference. Of course, the comments directories are saved in an alternate directory separate from the path where the articles are saved. This creates a database using the file system, directories and files as the "cells" where data is stored. Like I said, I don't know if it is the best solution, but since data is kept in separate files, individual articles can be deleted from the "database" quite easily and there is no single, large file that must be loaded into memory each time the database is accessed. Data is sought out by simply reading a directory and looking for a reference ID. -Ryan > >I am building a web application server with rebol, and have had no reall >problems up until >now, that i want to implement a function I call pageid that is , a >form can have a page id >which is like A23-C0399 , the page id i then want to be the reference value , >and i want to >use a database type system to store the values. , is there a good function >that anyone has written >that allows easy adding, removal, modfication and retrieval of data from a >rebol type db . > >this would be handy in the fact that i could > >- use a form with a pageid to add a pageid >- use the function to easily add it to the database >- use the database to update the list page >- use the database to retreive if a pageid is present and if so retrive the >pageid's details. > >the information the db needs to hold should be anything, especially one line >sentences and >strings. > >any help would be muchly appreciated, > >aden > > > > >> > > > > > > > >I am building a web application server with rebol, and have >had no reall problems up until >now, that i want to implement a function I call >pageid that is , a form can have a page id> >which is like A23-C0399 , the page id i then want to be the >reference value , and i want to >use a database type system to store the values. , is there >a >good function that anyone has written >that allows easy adding, removal, modfication and retrieval >of >data from a rebol type db . > >this would be handy in the fact that i could > >- use a form with a pageid to add a >pageid >- use the function to easily add it to the >database >- use the database to update the list page >- use the database to retreive if a pageid is present >and >if so retrive the pageid's details. > >the information the db needs to hold should be anything, >especially one line sentences and >strings. > >any help would be muchly appreciated, > >aden > > > > >>
[REBOL] Anyone doing something with LDAP? Re:(3)
OK, I also found the BER modules in perl. Looks like it won't be too much trouble to' implement in rebol. Do you have any more pointers on BER, ASN.1, and TLV.? A good RFC, web-page-url, etc -- about BER? Then it sounds like I should write the BER.r script first and next make the LDAP.r Or maybe I should do it in REBOL/command -- when will that be shipping? 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] AW: Standard input hangs rebol? Re:
> *** REPLY SEPARATOR ***
>
> On 00-07-24 at 19:19 [EMAIL PROTECTED] wrote:
>
> >Hello, rebol community!
> >
> >I have the following rebol-script:
> >-
> >REBOL[]
> >probe "hello, world!"
> >-
> >
> >when I say at command prompt "rebol/rebol -q hello-world.r" it works of
> >course. But when I say "echo 12345|rebol/rebol -q hello-world.r" it
hangs!
> >
> >Could somebody be so kind as to explain what happens?
> >I have REBOL/Core 2.3.0.4.2 under Linux.
> >
> >Petr
>
> Try "echo 12345|rebol/rebol -qc hello-world.r"
> Mark
>
Though I don't use Linux myself, I have an idea:
You use the pipe ( | ). So the Shell first executes "echo 12345" and stores
the output of the console (here: 12345).
Then it executes the second command in the pipeline ("rebol/rebol -q
hello-world.r") and attaches the previously stored value (12345) as an
command line argument. So de factto the shell does the following:
rebol/rebol -q hello-world.r 12345
There might be an error in this call. Rebol stops executing the script
without quitting the interpreter ("hangs"). But you don't see the error msg
as you started the interpreter with the quiet option set. Try and start
Rebol without -q.
Jean
[REBOL] Standard input hangs rebol? Re:
*** REPLY SEPARATOR *** On 00-07-24 at 19:19 [EMAIL PROTECTED] wrote: >Hello, rebol community! > >I have the following rebol-script: >- >REBOL[] >probe "hello, world!" >- > >when I say at command prompt "rebol/rebol -q hello-world.r" it works of >course. But when I say "echo 12345|rebol/rebol -q hello-world.r" it hangs! > >Could somebody be so kind as to explain what happens? >I have REBOL/Core 2.3.0.4.2 under Linux. > >Petr Try "echo 12345|rebol/rebol -qc hello-world.r" Mark Marek "Juha" Pia³ucha mailto:[EMAIL PROTECTED] - http://www.tnet.pl/~marek phone: +48502837282 - IRC: #miedzyrzec
[REBOL] APL'ish operations Re:(4)
I was thinking in terms of function projection. Take a binary function (like + ), fix one of the arguments (5) and create a monadic (?) function that can be applied to say a vector. Sorry if all this seems like elementary stuff, I'm just starting with REBOL and exploring the possibilities. --- [EMAIL PROTECTED] wrote: > > Perfect. Just what I needed. Wish there was a way > to > > make simple one-off functions in a block like [ + > 5] > > etc. > > > > I think you can. Again according to what you need. > This is where Rebol > shines. Rebol gives you the ability to interpret > blocks (and strings) in way > other than the default provided by Rebol. That is, > according to your own > grammar. Rebol calls this a dialect. Admittedly this > is not straight-forward > when you're beginning with Rebol. On the other-hand > once you have done this > a few times, you will see opportunities for it > everywhere and discover that > it really is not as complex as it sounds. > > One way to achieve this is to interpret a block by > stepping through it and > checking types then doing something. Another way is > to use the parse > function of rebol. Parse takes a string or a block > as input plus a grammar > specification that will interpret your input > according to rules. > > So to your example. > What would [+ 5] actually do and how would it be > used? > > Brett. > > = __ Do You Yahoo!? Get Yahoo! Mail Free email you can access from anywhere! http://mail.yahoo.com/
[REBOL] Easy to use Database function
I am building a web application server with rebol, and have had no reall problems up until now, that i want to implement a function I call pageid that is , a form can have a page id which is like A23-C0399 , the page id i then want to be the reference value , and i want to use a database type system to store the values. , is there a good function that anyone has written that allows easy adding, removal, modfication and retrieval of data from a rebol type db . this would be handy in the fact that i could - use a form with a pageid to add a pageid - use the function to easily add it to the database - use the database to update the list page - use the database to retreive if a pageid is present and if so retrive the pageid's details. the information the db needs to hold should be anything, especially one line sentences and strings. any help would be muchly appreciated, aden
[REBOL] Bug in 'use? Re:(11)
Hi Gabriele, you wrote: >I'm glad to talk with you too; I hope to get your book soon, too, >so I'll be able to send you some bug report. ;^) I've set up a mailing list on my Web server for the book (for bug fixes and clarifications and ongoing discussions). You can join the mailing list at my Website: http://www.TechScribe.com After reading your email carefully, my impression is that our main discrepancy has to do with perspective. I view REBOL as a programming language, and I think about REBOL in terms of concepts, principles that lend themselves to describe how REBOL acts as a language. In contrast, you apparently think about REBOL as an interpreter implementation. You tend to speculate about how the REBOL interpreter is likely to implement some language feature. [snip] >So, let's prove there's no hierarchy here: > >>> f "This is f's argument" >This is g's argument. This is f's argument This is the global word. >>> code: second :g >== [ >print [g-arg f-arg global-word] >] >>> g's-context-word: code/2/1 >== g-arg >>> print code/2 >This is g's argument. This is f's argument This is the global word. >>> print bind [g-arg f-arg global-word] g's-context-word >** Script Error: f-arg has no value. >** Where: f-arg global-word Carl commented on a similar example you provided while binding a block to an embedded object, and declared the bind behavior you demonstrated to be a bug. He didn't clarify, and I will rely on his response (see Carl's message in this thread. Date: Mon, 24 Jul 2000 15:40:32 -0700 Subject: [REBOL] Bug in 'use? Re:(9)) with respect to this behavior as well. I conclude from Carl's comment that bind's intended behavior is to bind the block such that all words that occur in the block behave as they would, if the block had been defined in the context it is being bound to. I.e. if print [g-arg f-arg global-word] evaluated in the g function's context were to generate This is g's argument. This is f's argument. This is the global word. then print bind [g-arg f-arg global-word] g's-context-word should generate the same result. If it doesn't, then it is - in Carl's words - a bug. Hierarchic context table inheritance is REBOL's intended behavior. >>> f-arg: "Global f-arg!" >== "Global f-arg!" >>> print bind [g-arg f-arg global-word] g's-context-word >This is g's argument. Global f-arg! This is the global word. > >So, how does it work when calling F? When F is created, a new >context table is created. Thank you. I went to pains to demonstrate that. >Then the BIND function is called to bind Metaphorically speaking? I have never seen the bind function called during the construction of a function. If you source func and function, you will find that neither of these mezzanine functions call bind. They both use make function! ... and I have no access to the code that is executed when make function! is called. >the body block to that context table (this means binding each word >in the block and the blocks (any-block!s actually) it contains, >but only if present in the context table). >So when F is created >the block: > > [ >print [g-arg f-arg global-word] > ] > >gets bound to F's context; more precisely, >the word "f-arg" gets >bound to F's context, while "print", "g-arg" and "global-word" >aren't changed (so they're still bound to the global context). I think this is a conceptual problem. There is no g-arg defined in the global context. Accordingly "g-arg" was never bound to the global context. Therefore "g-arg" cannot "still" be bound to the global context. > >When F is executed, the function G is created, and thus the block >above gets bound to G's context. Again, only the word "g-arg" is >affected, while "print" and "global-word" are left bound to the >global context and "f-arg" to F's context. Thank you. Note what you are saying here. You are looking at this from a different perspective, an implementation perspective, - nevertheless - you are formulating a mechanism that exactly results in context inheritance. You may dislike the term "context (table) inheritance", but I think it expresses the fact quite well that words used - but not defined - in an embedded function, are interpreted in the context of their parent function - provided they are defined in that function. Or in their immediate parent's parent function ... until the global context is reached. Your implementation view (though speculative, but reasonable) supports my conceptual representation, don't you think? > >The result is what you expect, with "f-arg" bound to F's context, >"g-arg" bound to G's context and "global-word" bound to the global >context, but this is only a (wanted) side effect of REBOL static >binding. > > r> Example 2 for Context Hierarchy: > >[...] > >The same goes here. No hierarchy needed. No hierarchy "needed"? Did you not begin by claiming in your previous email >Anyway, I can prove that there is no context hierarchy: then continue by saying in this email >So, let's prove
[REBOL] input a bunch? Re:
Um.. Read it from a file? Read it from an url? Read it from a Tcp/ip port?! If you mean you want a better user interface, then you could set a mini-webserver /cgi/ and HTML page for input :) or use Rebol/View and construct an interface with it. If you were using /view you could also read from the clipboard as well. Brett. - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 26, 2000 8:37 AM Subject: [REBOL] input a bunch? > hey list guys, > > I have something like this: > > print "type something" > input: somthingtyped > > this works like a champ when I type stuff in at the console. but I'd > prefer to get it in some other way, and pasting mucks stuff up. > how can I get, say, a paragraph into input? I'm typing in stuff that > I don't know beforehand... > > thanks, > > -- > > Spend less time composing sigs. > -tom >
[REBOL] code that crashes Re:
Hi, I have reported a similar bug with whois scheme - the close function crashes REBOL. close insert open whois://rs.internic.net "rebol" As Carl writes in the new networking document, the whois protocol is almost trivial, so this might be a bug in the default network handler. -- Michal Kracik [EMAIL PROTECTED] wrote: > > Hey list, > > two things... > > I have a pretty big html file with a bunch of same-page links, that > goes something like this: > > link > link > link > > #linktarget > .. > > I want to rebolize the page so I can generate additions to the page > (make a "rebol" db).. how might I best accomplish this? > > also, tell me if there is anything wrong with this line: > > close insert (find (open ftp://user:pass@site) "these words") (code) > > it works on opening local files, but, like that, crashes rebol. > > any ideas? > thanks. > -- > > Turn your computer off. Go outside. > -tom
