[Bot] email command Bot

[1/13] from: mauro::fontana::speedautomazione::it at: 26-Mar-2004 9:31

Hi all, I have been developing a Bot that can receive emails on a specified email address with a particular format, execute the commands and then answer back the results. I mainly thought it as where I work now I have not access to the web but only to the corporate email address, but I wanted to be able to monitor some things on my computer at home, and eventually, being able to make it send me web pages through email. I have lately seen that someone has uploaded a similar project on the rebol.org library. My code is far from being finished and, most of all, being in a neat form to be made public. Moreover, I am still working (quite slowly, I admit it) on the logging feature that would allow me to create nice reports of all the info about the requests sent to the Bot during time. I would like to know if someone is interested in this project. I am quite happy to send the code to anyone who would like to help me. The code is OOP, that is the bot is a object with methods as is the logger. I would like to add XML logging to it to be able to easily extract data later. [small rant] I am not a Rebol genius, though I have been using it (discontinued) for some time now. There are still many things I have problems to understand, mainly due to its "compactness" in the syntax, which I though it was a thing the language wanted to avoid. See those neat examples in the library to see what I mean. No doubts they are nice pieces of code that run well, but they are quite ermetic (cryptic syntax)and often use some undocumented parts of the language (like the use of internal ports, sub-ports, system objects etc...) which make them quite "mysterious". I think this is the first problem novices meet when starting grasping with the language. The use of forms like :word 'word to-lit-word! to-lit-path! set get etc... can be quite powerful but can also make the code a mess (like doing things in C like c = *(unsinged short *) &value[]). And often they are done just to keep the code short instead of making it clear. Then the fact that there's not exhaustive documentation on the system objects and how to take advantage of them. I have still to understand how the async:// thing works and where are those info about the sub-ports/handlers explained in the docs. This is just an example. Last a request, which may have already been asked, but I have not seen it. Is it not possible to make the interpreter load binary code so that one can "convert" the source code to it and have the interpreter load it not in ASCII form? So, even though the reverse engineering of the binary could be done, only the basic instructions are there and not the entire clear source code. This way the users could create "embedded" applications without having to mess with packages and source code distribution. [/small rant] Thanks for reading. M&F

[2/13] from: maarten:vrijheid at: 26-Mar-2004 11:49

Hi Mauro,

> I have been developing a Bot that can receive emails on a specified email > address with a particular format, execute the commands and then answer

<<quoted lines omitted: 3>>

> some things on my computer at home, and eventually, being able to make it > send me web pages through email.

Sounds cool.

> I have lately seen that someone has uploaded a similar project on the > rebol.org library.

<<quoted lines omitted: 3>>

> feature that would allow me to create nice reports of all the info about > the requests sent to the Bot during time.

I am afraid I am interested in the finished part, if it supports IMAP.

> I would like to know if someone is interested in this project. I am quite > happy to send the code to anyone who would like to help me. The code is

<<quoted lines omitted: 9>>

> parts of the language (like the use of internal ports, sub-ports, system > objects etc...) which make them quite "mysterious".

It's a different problem, really. REBOL allows access to *all* of itself. So you get to see and manipulate *everything*. Some of us have gone down that road, exploring a lots of mechanisms that would be internal to other interpreters. What I am trying to say is that it is not reasonable to expect all parts of REBOL to be documented, simply because some parts are visible but essentially internal. The fact that some gurus have figured them out is a great accomplishment that results in nice libraries, but not something you should necessarily want to do yourself. It's one of the joys of having a fully accessible (reflexive) language.

> I think this is the first problem novices meet when starting grasping with > the language. The use of forms like :word 'word to-lit-word! to-lit-path! > set get etc... can be quite powerful but can also make the code a mess > (like doing things in C like c = *(unsinged short *) &value[]). > And often they are done just to keep the code short instead of making it > clear.

Good point. I agree that published code should be clearer and better documented.

> Then the fact that there's not exhaustive documentation on the system > objects and how to take advantage of them. I have still to understand how > the async:// thing works and where are those info about the > sub-ports/handlers explained in the docs. This is just an example. >

See above.

> Last a request, which may have already been asked, but I have not seen it. > Is it not possible to make the interpreter load binary code so that one

<<quoted lines omitted: 3>>

> source code. This way the users could create "embedded" applications > without having to mess with packages and source code distribution.

Do you know the SDK and the ecnap tools that come with it? Or isn't this what you want.

> [/small rant] > > Thanks for reading.

Keep asking ;-) --Maarten

[3/13] from: mauro:fontana:speedautomazione:it at: 26-Mar-2004 12:36

On Fri, 26 Mar 2004 11:49:29 +0100, Maarten Koopmans <[maarten--vrijheid--net]> wrote:

>> I have lately seen that someone has uploaded a similar project on the >> rebol.org library.

<<quoted lines omitted: 5>>

>> the requests sent to the Bot during time. > I am afraid I am interested in the finished part, if it supports IMAP.

The fact is that the BOT is built so that the user can assign the commands he wants to the BOT in an external command list file. Probably a standard set of basic coomands can be provided (like those to access web pages). I really do not know how to deal with IMAP. But if someone here is able and interested, they could easily go write the command function for my BOT.

>> I would like to know if someone is interested in this project. I am >> quite

<<quoted lines omitted: 25>>

> you should necessarily want to do yourself. > It's one of the joys of having a fully accessible (reflexive) language.

I see. However this "self access" to the interpreter seems a boomerang thing, as it allows to make powerful scripts but also allows for "hacks" that are not that simple to understand. IMHO at long people get discouraged by what they can obtain from the standard "feature" vs those that can be accomplished by the "hacked" ones. You see, Rebol has nothing natively that can provide access to any DB or XML, so it seems to be quite a self contained/isolated world. People have somewhat resolved this problems, but I see that using complex 3rd part scripts to access a DB is somewhat a drawback with respect having it natively integrated/supported. The same goes for XML parsing and building features.

>> Last a request, which may have already been asked, but I have not seen >> it.

<<quoted lines omitted: 7>>

> Do you know the SDK and the ecnap tools that come with it? Or isn't this > what you want.

No, I was speaking about the free Core version, which is the tools I have been using since the beginning. I have not real use of View or Windows only dll access features. M&F

[4/13] from: petr:krenzelok:trz:cz at: 26-Mar-2004 13:34

>>It's a different problem, really. REBOL allows access to *all* of >>itself. So you get to see and manipulate *everything*. Some of us have

<<quoted lines omitted: 15>>

>discouraged by what they can obtain from the standard "feature" vs those >that can be accomplished by the "hacked" ones.

Yes, that is typical, sometimes a BIG problem for Rebol acceptance - I am only average programmer, but sometimes I look at even short script and am not able to understand easily and fast enough what it is supposed to do ....

> You see, Rebol has nothing >natively that can provide access to any DB or XML, so it seems to be quite >a self contained/isolated world. >

People have somewhat resolved this problems, but I see that using complex

>3rd part scripts to access a DB is somewhat a drawback with respect having >it natively integrated/supported. >The same goes for XML parsing and building features. >

but now I have to object. What is si complex about mySQL protocol? 10KB? Yes, it is third party, but excuse me - when in python or perl - aren't their even more general functions in separate modules you have to include/load/call/whatever? I do'nt see anything complex about "do %my-sql.r" at all ;-) /Command version contains direct mySQL access, but maybe DocKimble could compress his mysql.r into binary format, so you would not see its internals and only API would be left for you, which is plain simple - open, insert, copy, close :-) OK, I think I know what you consider being a trouble - such third party tools don't use unified way to certain areas which we try to address. That is why I asked for thing as Uniserve - multi-protocol plug-in architecture, so that ppl would not have to start over and over again building their protocols from scratch. I think Maarten tried to address that by some rebol library - the best scripts put into some toolset, which could be used by many .... other thing may be Maxim's Slim - module system - Robert asked us to try that on AltME world, and I will - maybe it can solve some dependency problems etc. The problem with Rebol community is, that each of us uses some slightly different aproach, and that we can't somehow agree upon some "standard", where others would use it and build upon it ...

>> > >No, I was speaking about the free Core version, which is the tools I have >been using since the beginning. I have not real use of View or Windows >only dll access features. >

Windows only? I may not understand ... under Linux you get access to .so libraries of course. But maybe you mean lack of real virtual machine in rebol for real cross platform code? -pekr-

[5/13] from: mauro:fontana:speedautomazione:it at: 26-Mar-2004 14:59

>> You see, Rebol has nothing >> natively that can provide access to any DB or XML, so it seems to be

<<quoted lines omitted: 16>>

> include/load/call/whatever? I do'nt see anything complex about "do > %my-sql.r" at all ;-)

Yeah, it's a subtle thing, but I would like to see native optimized functions to access DB and do XML parsing/building. 3rd party libraries, how good they can be written, keep getting interpreted which is a disavantage IMHO.

> /Command version contains direct mySQL access, but maybe DocKimble could > compress his mysql.r into binary format, so you would not see its > internals and only API would be left for you, which is plain simple - > open, insert, copy, close :-)

See above. That's whay I would also like to see soon a mod for Apache instead of having to constantly call Rebol interpreter for doing CGI.

> OK, I think I know what you consider being a trouble - such third party > tools don't use unified way to certain areas which we try to address.

<<quoted lines omitted: 19>>

> libraries of course. But maybe you mean lack of real virtual machine in > rebol for real cross platform code?

Yes, that's what I meant. Using external calls as they are now makes the main advantage of rebol (portability) useless. I like to use whatever is provided integrated in the interpreter which I think as optimized in speed/memory usage and is always available. M&F

[6/13] from: maximo:meteorstudios at: 26-Mar-2004 12:24

Hi, some text might be a little hard to follow, I wrote this over the course of several hours.. poking at it here and there... ;-)

> Yeah, it's a subtle thing, but I would like to see native optimized > functions to access DB and do XML parsing/building. 3rd party > libraries, > how good they can be written, keep getting interpreted which is a > disavantage IMHO.

there is a pro version... if you need speed, that is bound to be because you are in a corporate environment or are developing tools as a consultant, then a little investment shouldn't be that big a deal. google is powered by python... and I don't see python's slowness being an issue. they propably link to compiled modules or dlls, which we can easily do in rebol (dll)... in any case, rebol only has few natives... and some things inside rebol aren't absolutely stunning either... i.e. many user tools/patch are better than the RT code (and RT does include a lot of that code into subsequent releases.).

> > /Command version contains direct mySQL access, but maybe > DocKimble could

<<quoted lines omitted: 4>>

> See above. That's whay I would also like to see soon a mod for Apache > instead of having to constantly call Rebol interpreter for doing CGI.

well, there is something called rebol.dll which looks promising :-) I'm sure they will expand into other platforms as soon as they can.

>. other thing may be Maxim's Slim - > > module system - Robert asked us to try that on AltME world,

<<quoted lines omitted: 6>>

> some "standard", > > where others would use it and build upon it ...

rebol's strenght (i.e. "do your own") also makes it hard to WANT to play with others... listen, even though I've done slim and wish it to improve and expand and be widely adopted, I'm the first to admit, that I like to code my tools. The reason I built slim, was not so that a select group would integrate an exclusive rebol object framework. I built it so that everyone can package his code in a "documented" specification and then maybe one day, others will write tools which use that specification and create autodocs, or builds a sandbox which is inserted into slim, or (insert your idea, here). if this happens, everyone which wrote a slim gets access to those tools and can forget about writting his own for such boring things. we can even suspect that other loaders could come to be... as long as they conform to the specification, any slim package can then be used by it and benefit from its particular features/extensions. slim also makes it easier for new commers to accept external tools. in a sense, if you take the time to explicitely package it as a module, then there is better chance that you put more thought into the api, and that you -EXPECT- your tool to play with others... in any case, slim shields you from name conflict and goes a long way into making the process pretty painless. Also remember that many newcommers to rebol expect modules to be a part of rebol and it CAN help them to organize their work environments much more quickly if they have only one module/loading api to understand... and a series of modules which deal with given problems.

> Yes, that's what I meant. Using external calls as they are > now makes the > main advantage of rebol (portability) useless.

but even in python, you have to compile the sources ... for each platform. creating a VP isn't the most trivial of things... but RT COULD port a version of rebol for one of the good VPs out there like TAO, or maybe even java byte code... still its a major undertaking I'm sure.

> I like to use > whatever is > provided integrated in the interpreter which I think as optimized in > speed/memory usage and is always available.

remember that putting "everything in" , like you say, could transform rebol into another "bloat ware" . anything that is added in a default distro can never be removed afterwards. if they decided to put mySQL by default, then what happens if it falls from vogue? we end-up with a huge pile of legacy code that is virtually useless to 99% of us. I'd rather like us to be able to COMPILE natives and link them in by using industry-standard C++ object modules. just like python and others do it. for my part, I'd like an os module to exist, which maps more of the os data into one platform-independent library... things like current user name, environment variables, temp files handling, , threads, directory mappings, etc. there are already many things in rebol which are more transparent than in many other languages (like file! paths :-). But when doing multi-os corporate-wide deployment, it comes to a point where you have to use a (python, tcl, bat, whatever) script to load your rebol app with the system info in arguments... and that's not very pretty ... ;-) my two cents, keep what you like, kill the rest ;-). -MAx

[7/13] from: brett:codeconscious at: 27-Mar-2004 13:38

> [small rant] > I am not a Rebol genius, though I have been using it (discontinued) for

<<quoted lines omitted: 5>>

> parts of the language (like the use of internal ports, sub-ports, system > objects etc...) which make them quite "mysterious".

Could you please list a few of these neat examples you refer to. Without seeing them, I cannot see what you mean. Though, I agree ports/subports are poorly documented.

Yes the word datatypes are a real learning curve. However I think it is important to struggle with them a bit, to find and understand examples where they are used. In short to make a determined effort to learn them because doing so gives far better understanding of REBOL.

> (like doing things in C like c = *(unsinged short *) &value[]). > And often they are done just to keep the code short instead of making it > clear.

I don't doubt there could be instances of this. It would be nice for such examples to be shown and compared with more well written code. However, I have found in my own work that shorter REBOL code often leads to far more flexibility than the original versions. More than this though, just thinking about the consequences of choosing a shorter version may point out new aspects of the problem I had not considered earlier.

Yes documentation is a weakness - especially for ports. Async, is somewhat special because I don't believe RT has finished that area of work. Some members of the community have jumped into fill some of the gaps which is good but confuses this area a bit - esp. for me. :-)

> Last a request, which may have already been asked, but I have not seen it. > Is it not possible to make the interpreter load binary code so that one

<<quoted lines omitted: 3>>

> source code. This way the users could create "embedded" applications > without having to mess with packages and source code distribution.

Compilation of REBOL code has been discussed some time back. I would not hold my breath on that. Brett

[8/13] from: carl:cybercraft at: 27-Mar-2004 15:13

Re: email command Bot

On 26-Mar-04, Mauro Fontana wrote:

> [small rant] > I am not a Rebol genius, though I have been using it (discontinued)

<<quoted lines omitted: 12>>

> *(unsinged short *) &value[]). And often they are done just to keep > the code short instead of making it clear.

I agree that it's often hard to figure out a REBOL script, and doubly so for newcomers. I think the problem is that most programmers don't start a script intending it to be an example. More likely it was written with some purpose in mind and then uploaded to somewhere because the programmer thought it might be of use to others. Ideally they'd go through it first and comment it and change any cryptic words to more meaningful ones, but that might take as long or longer as writing the original script, hence it doesn't get done. As an example, the programmer will know what a particular function does and the types it should be given and so may not bother to make it explicit in the code as their script only every supplies the right types. (Or so the programmer thinks;) The newcomer on the other hand just sees a function they think could be of use, then wonders why it breaks. What would a newcomer make of this for instance...

>> build-url: func [domain file][join domain file]

? It looks pretty self-explainatory, but there's any number of ways it won't work...

>> build-url "www.nowhere.not" "story.txt"

== "www.nowhere.notstory.txt"

>> build-url "http://www.nowhere.not" "story.txt"

== "http://www.nowhere.notstory.txt"

>> build-url http://www.nowhere.not story.txt

** Script Error: story.txt has no value ** Near: build-url http://www.nowhere.not story.txt

>> build-url http://www.nowhere.not http://story.txt

== http://www.nowhere.nothttp://story.txt

>> build-url http://www.nowhere.not %story.txt

== http://www.nowhere.notstory.txt plus a couple that will produce a correct URL...

>> build-url http://www.nowhere.not/ %story.txt

== http://www.nowhere.not/story.txt

>> build-url http://www.nowhere.not/ "story.txt"

== http://www.nowhere.not/story.txt Confusing and discouraging, and HELP's not a lot of help either...

>> help build-url

USAGE: BUILD-URL domain file DESCRIPTION: (undocumented) ARGUMENTS: domain -- (Type: any) file -- (Type: any) So much better if they'd written the function thus... build-url: func [ "Builds an URL by joining a domain-name's URL to a file-path." domain [url!] "Domain-name. Trailing slash required." file [file! string!] "File-path." ][ join domain file ] Much clearer and more errors will now show up (at the right place - when the function's used) and be more explicit...

>> build-url "www.nowhere.not" "story.txt"

** Script Error: build-url expected domain argument of type: url ** Near: build-url "www.nowhere.not" "story.txt"

>> build-url "http://www.nowhere.not" "story.txt"

** Script Error: build-url expected domain argument of type: url ** Near: build-url "http://www.nowhere.not" "story.txt"

>> build-url http://www.nowhere.not http://story.txt

** Script Error: build-url expected file argument of type: file string ** Near: build-url http://www.nowhere.not http://story.txt Plus HELP now becomes useful too...

>> help build-url

USAGE: BUILD-URL domain file DESCRIPTION: Builds an URL by joining a domain-name's URL to a file-path. BUILD-URL is a function value. ARGUMENTS: domain -- Domain-name. Trailing slash required. (Type: url) file -- File-path. (Type: file string) Perhaps functions in example code should all be this descriptive, but the downside would be scripts that are quite a bit longer and at first glance more complicated. Which takes longer for a human to parse - the one-line function above or the fully fleashed-out version? I'd say the one-liner. That said, the one REBOL refresher-course us long-time users should take every now and then is to re-read its style-guide... http://www.rebol.com/docs/core23/rebolcore-5.html#section-5 -- Carl Read

[9/13] from: carl::cybercraft::co::nz at: 28-Mar-2004 0:24

[snip]

> build-url: func [domain file][join domain file]

[snip]

>That said, the one REBOL refresher-course us long-time users should >take every now and then is to re-read its style-guide... > >http://www.rebol.com/docs/core23/rebolcore-5.html#section-5

And where, ahem, you'll find they say this... There are standard names in REBOL that should be used for similar types of operations. For instance: make-blub ;creating something new free-blub ;releasing resources of something copy-blub ;copying the contents of something to-blub ;converting to it insert-blub ;inserting something remove-blub ;removing something clear-blub ;clearing something Thus my BUILD-URL should really be MAKE-URL... :-) -- Carl Read

[10/13] from: atruter:labyrinth:au at: 27-Mar-2004 23:46

> Thus my BUILD-URL should really be MAKE-URL... :-)

Or should it?

>> help "build"

Found these words: build-attach-body function! Return an email body with attached files. build-markup function! Return markup text replacing <%tags%> with their e... build-tag function! Generates a tag from a composed block.

>> help "make"

Found these words: dh-make-key native! Creates a key object for DH. dsa-make-key native! Creates a key object for DSA dsa-make-signature native! Creates a DSA signature make action! Constructs and returns a new value. make-dir function! Creates the specified directory. No error if alrea... make-face function! Make a face from a given style name or example fac... rsa-make-key native! Creates a key object for RSA Make seems to create "atomic" things such as a face, key, dir, etc ... while build uses a number of values to create a "meta-value", or at least that's my [probably flawed] take on it! ;) Regards, Ashley

[11/13] from: rotenca:telvia:it at: 28-Mar-2004 15:29

Re: [Bot] email command Bot

Hi Brett,

> Yes documentation is a weakness - especially for ports. Async, is somewhat > special because I don't believe RT has finished that area of work. Some > members of the community have jumped into fill some of the gaps which is > good but confuses this area a bit - esp. for me. :-)

I do not think is unfinished in the sense that it is not working. It simply has not a good interface. Else i think that neither IOS neither Altme could exist. --- Ciao Romano

[12/13] from: mauro:fontana:speedautomazione:it at: 30-Mar-2004 15:05

Thanks for the answers, expecially about my [small ranting]. Though none has shown any interest in the project 8). So, where do you think is the best place to upload/publish the unifinished code? Thanks again M&F

[13/13] from: greggirwin:mindspring at: 30-Mar-2004 8:58

Hi Mauro, MF> Though none has shown any interest in the project 8). Yeah, that happens sometimes. We all get busy with other things. MF> So, where do you think is the best place to upload/publish the unifinished MF> code? REBOL.org is a great place to put it, even if it's unfinished. Just make note of that so people know what state it's in. -- Gregg

Notes

Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted