[REBOL] Re: [Bot] email command Bot
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 MF -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: [Bot] email command Bot
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 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] 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 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: [Bot] email command Bot
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 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. Sounds cool. 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 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 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. 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 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. 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 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: [Bot] email command Bot
On Fri, 26 Mar 2004 11:49:29 +0100, Maarten Koopmans [EMAIL PROTECTED] wrote: 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 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 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. 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 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. 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. 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. MF -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: [Bot] email command Bot
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 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. 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- MF -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: [Bot] email command Bot
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 ;-) 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. 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? 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. MF -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: [Bot] email command Bot
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 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. 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, 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 ... 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
[REBOL] Re: [Bot] email command Bot
[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. 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. 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 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. 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. 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 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. Compilation of REBOL code has been discussed some time back. I would not hold my breath on that. Brett -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
