[REBOL] Reading Binary data Re:(3)
Hi Jim: That part worked thanks! However, if have not gotten the results that I had hoped for. I had assumed that skip fp 10 would take me to offset 10. It appears that it has not. TestBin.txt contains the characters: "abcdefghijklmnopqrstuvwxyz" The following code : ;=== fp: open/read/direct/binary %TestBin.txt skip fp 10 Use fp: skip fp 10 print to-string buffer: copy/part fp 10 close fp ;=== produces: The result you will be looking for in buffer will be "klmnopqrst" -- Sent through GMX FreeMail - http://www.gmx.net
[REBOL] pesky little questions
pesky little questions howdy guys, I've a few smallish questions that have been pestering me. Like this one: compressing a file is pretty easy. compress read %this.file (right?) How can I get the compressed data into a script so that I can use it there? I guess a gif would be in the same catagory. Here's another one: I've never made a string or block to store stuff in. Like make string! 1. can I maybe get an example and explanation? I can make a string to decompress into, then work on, right? one more for now: extracting stuff from a block. friends: [ [EMAIL PROTECTED] "her" [EMAIL PROTECTED] "him" [EMAIL PROTECTED] "her" ] how can I get a list to choose from, then use the choice? Like, choices: 1. her 2. him 3. her 1 sending to [EMAIL PROTECTED] or something like that. Thanks! -tom
[REBOL] pesky little questions Re:
Hi Tom,
I'm feeling a bit tired, so I'm only going to answer the first one for now
;-)
Cheers,
Allen K
pesky little questions
howdy guys,
I've a few smallish questions that have been pestering me. Like this
one:
compressing a file is pretty easy. compress read %this.file (right?)
How can I get the compressed data into a script so that I can use it
there? I guess a gif would be in the same catagory.
REBOL [
Title: "Image File Compressor"
Purpose: {Creates a file of compressed images from the directory
images for pasting into scripts}
Note: {Modified version of one of Jeffs helpful posts}
]
system/options/binary-base: 64
list: []
foreach file read %. [
if any [
find file ".bmp"
find file ".gif"
find file ".jpg"
find file ".jpeg"
append list join to-string file [
{: load to-binary decompress }
mold compress read/binary file
"^/^/"
]
]
]
write %images.r list
[REBOL] code as data Re:
foreach [condition action] code [ if all condition action ] or.. if any condition action -jeff I want to evaluate a block of code like the following : code: [ [condition1][action1] [condition2] [action2] [condition3] [action3] ] forskip code 2 [if do first code [do second code]] The above works only when [condition] has one value. My actual code is : code: [ [condition1a [condition1b]][action1] [condition2] [action2] [[condition3a] [condtion3b] condition3c] [action3] ] Any idea ? -- [EMAIL PROTECTED] http://perso.worldonline.fr/mutant
[REBOL] where are all the components?
Hi all, Here's a longish rant I originally sent to some friends this weekend about where I see REBOL having a lot of promise in "the big picture." I'm sure I'm not saying anything that RT isn't already thinking of, but considering how long it's taken me to really GET what REBOL may mean for the industry, I hope this might be useful for some readers of this list who are still new to REBOL.. and of course, if I'm way off base in my logic, I'd like to hear about it. :-) I remember reading some very optimistic books by a team of authors (Orfali, Harkey, etc.) extolling the virtues of CORBA, The Distributed Objects Survival Guide being the most typical. In these books, they painted this very compelling image of a wonderful world in the near future where all software would be made out of a bunch of components, and companies and end-users would be free to either write their own or buy (or in the case of open source, download) ready-made and tested components that others had written. They saw CORBA as the horse most likely to win the race of being first to market with a workable component architecture that could bring about the "component revolution." So, where are all the components? Why is it that, outside of things like VBX controls and JavaBeans that have been very successful within very limited domains, we still haven't progressed beyond, essentially, shared libraries?! I take that back: MS has done a good job of implementing new Windows technologies in terms of COM components, but, even on Windows, it doesn't seem like ISV's are embracing COM within their own applications. And, on UNIX and Mac and BeOS, neither COM nor CORBA seems to have taken off, and even though GNOME apps are linking with an ORB now, I really don't see GNOME doing anything with CORBA that it couldn't just as easily have done without it. Long story short, I think one of the answers might just lie with a concept REBOL is pushing, dialects. Think about some of the most highly successful Internet protocols we use today: SMTP, HTTP, FTP, NNTP. While not an "Internet" protocol, let's add SQL to the list. What do they have in common? Instead of using CORBA or COM or some binary packet format, all client/server communication is in the form of domain-specific ASCII text commands! Why can't we take that architecture and apply it to creating components that communicate within a single machine? In some sense, we're already doing it in a very static and primitive way with things like /etc files and command-line arguments. Another piece of the puzzle is the notion of minimizing the number of incompatible namespaces on the system. Plan9 took this to an extreme: everything's a file in Plan9, even more so than UNIX, and so it's easy for shell scripts to do things like act as TCP/IP clients just by manipulating the right magic files. More on this below. So, why dialects? First, I think they're much easier to design and document than object interfaces. They've traditionally been much harder to IMPLEMENT, which is why people don't go that route unless they absolutely have to, but that's where REBOL comes in (as I'll expand on in a bit).. They're also MUCH easier to debug, as you can just open a port and start typing in commands and see what's going on! Think about how many mail problems have been diagnosed by sysadmins telnetting to port 25. Why shouldn't you be able to, say, telnet to a port and type a command to open a window, another one to draw a circle in it, etc., and see all the mouse, keyboard, and other events come back to you as text messages too? In fact, like any good RAD environment, I can picture a very clean design/implement/debug cycle where you add a new command, document it, and debug it, all with quick turn-around time compared to designing a class, implementing all the get/set accessor methods, realizing it still sucks, etc. Dialects are much easier to script, as any random scripting language that has the ability to open the port (which, in Plan9 was done in the same way as opening any other file) can spew stuff to it with print statements, and get responses back with read statements. Of course a language like REBOL makes these two tasks particularly easy, so it helps on both sides of the fence. Finally, dialects are TRIVIAL to extend: unlike binary protocols where it's easy to screw up and not leave yourself room to elegantly add new capabilities, with a dialect, you simply add a new command word! You don't even have to worry about proprietary extensions screwing up clients, because there's natural namespace protection built into a dialect, you simply do something like: X-MyCompany-WeirdCommand: foo and if the server doesn't understand, it gives you an error in a well-established (by the particular dialect) way. Efficiency seems to be the big reason more stuff hasn't gone this way, and to be fair, I'm certainly not proposing that we throw away shared libraries! Things like printf() will always
[REBOL] large-scale REBOL coding?
Hi all, Here's something I've been thinking about since talking to a friend about REBOL and its prospects. He said that just about any scripting language can handle scripts of a few hundred lines, but the real challenge for REBOL will be in whether or not it can handle large-scale programs as well as, for example, Python. Take Zope (www.zope.org), for instance, a Web application server written in Python (with a few native modules). I just downloaded the latest version and ran a quick line count on all the .py files: 83165 lines, plus another 10391 lines for the ZServer HTTP server! That includes comments, but still I'm very impressed that the language can scale up to handle a project of this size. One project I'd like to work on once I'm finished with my current programming contract job would be to look through the source code to Zope and figure out how feasible it would be to do something of that size with REBOL. Correct me if I'm wrong, but it seems that one big limitation of REBOL currently is the lack of solid module support. DO'ing subsidiary scripts doesn't seem like the right approach, especially compared to Python's powerful import facility. I know there are some third-party module managers available (which to be honest, I haven't had time to investigate), but this seems like the type of thing that needs to be built into the language. I would assume that RT is aware of this, and hopefully working on a solution, but are there any other areas where REBOL is currently lacking? I don't want REBOL to be only useful for quick hacks!! -Jake
[REBOL] stdin type? was: impossible email dream Re:
OK, tried this in BSDI: message: import-email stdin: copy system/ports/input and I get: ** Script Error: import-email expected data argument of type: string. ** Where: message: import-email stdin So I did: stdin: copy system/ports/input print type? stdin And it's a block... How did this work for you? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 11, 2000 11:31 PM To: [EMAIL PROTECTED] Subject: [REBOL] impossible email dream Re:(2) Boy, guess I'm a little absent minded these days (too much on the mind): Here's a more correct version of the example mail filter I sent... -jeff #!/path/to/rebol -qws REBOL [ Title: "Mail filter" ] stdin: copy system/ports/input message: import-email stdin foreach [item file][ "REBOL" %rebol-box "Debian" %deb-box "me" %me-box ][ if find item message/content [ write/append file stdin exit ] ] write/append %default-box stdin quit ;-same thru REBOL header ;- saves a step message: import-email stdin: copy system/ports/input foreach [item file][ "REBOL" %rebol-box "Debian" %deb-box "me" %me-box ][ ;- the args to find were backwards if find message/content item [ write/append file stdin QUIT ;- instead of exit (not in function) ] ] write/append %default-box stdin quit
[REBOL] stdin type? was: impossible email dream Re:(2)
message: import-email stdin: copy system/ports/input and I get: ** Script Error: import-email expected data argument of ** type: string. Where: message: import-email stdin So I did: stdin: copy system/ports/input print type? stdin And it's a block... How did this work for you? Sure enough.. you wind up with a block of lines from stdin. try: message: copy "" stdin: copy system/ports/input foreach line stdin [append message append line newline] message: import-email message
[REBOL] where are all the components? Re:
IMO there are a variety of issues involved in the "component revolution" that are related to the entire issue of "code reuse" as promised by all of the "object oriented" technologies. Component interfaces and communication: The various component communication mechanisms are in competition - CORBA, DCOM, XML-RPC, etc. They are not as yet standard. When the components reside on the same system the efficiency hit is substantial. For a single processor we have such things as DLLs which are mostly packaging, and OLE which allows an application to export most of its object model and interface. Using the interfaces: No matter what mechanism is used to interface to a component, there is still an interface to be learned. It may be termed an API, a COM interface, an object model, or whatever. The fact remains that every component provides some object structure and some ability to operate on that structure, all of which requires understanding the nature of the component. This is true whether the interface is a language (or dialect) of some sort, a programming language or set of function calls, or an object model exported by OLE/COM/DCOM/CORBA. XML-RPC attempts to help by providing a DTD that defines the grammar of the interface language and a definition of any particular interface. This is another part of the approach of allowing one component to ask another for its interface. It is really analogous to asking for and receiving a grammar for the interface language and a dictionary for it. Even given this, the programmer still has to understand the interface of the component being used, at least in broad terms. This is independent of any interface communication standards and, to my mind, inescapable. What grammar definitions do help with is changing interface definitions and such things as parameter type validation for remote invocations. If we realized interfaces with dialects, we still need to know what the dialect offers and how it is used. Rebol/View offers several internal dialects, but programming in any of them will always require a knowledge of the dialect. The concept of "little languages" has been used with great success in parts of the Unix communities for years. When these languages are implemented as true grammars, they can be very useful and very powerful, since they allow the programmer to address a problem domain in a language that is suited to the domain. Languages such as REBOL and FORTH make heavy use of this idea - the general concept of a dialect. Indexing reusable components: Another overwhelming problem is indexing and retrieval of components once created. Give a universe of accessible components that you could potentially use, how do you locate those that might be appropriate and how do you find out what they can really do? If you think that a new component it needed, how can you find out whether much (or perhaps all or even better) has already been implemented and is available to build upon? The best current answer that we have is that components of various sorts are advertised or promoted in various ways, discussed in email lists and newsgroups, featured on web sites, and found by accident or by design with a web search engine. Learning the interface is done as it has always been done - the bright ones read the manual and then try things and then ask for help when what the manual seems to say conflicts with their understanding and the behavior that they observe. If the component is one that must be purchased prior to use, the decision it spend the money has to come from the various discussions of benefits and pitfalls of using the tools. Notice that this problem doesn't change whether we are talking about stand-alone applications, programming languages, development tools, or components in any of their various forms. While we as an industry have made some progress on the technical side of reusable and even distributed components, we have hardly the glimmering of an approach to this problem of indexing. We haven't solved it with regard to books and other natural language communications, and we haven't solved it for components. What now?: Having said all that, it is clear that components have a real place in the scheme of things. Being able to describe the structure and format of the actual interface with a grammar as is done with XML-RPC is a good step in generality. The ability to create dialects within a language that allow the use of component / interface features easily is harder but still useful. Whether these "little languages" are small enough to be realized by something like dialects in REBOL or are more appropriately constructed using parser generators so as to produce true compilers or interpreters for the languages would seem to depend on the nature of the component interfaces involved. That REBOL has succeeded with so many of the internet protocols is an indication of the value of the approach. If these protocols had been developed from a perspective of language
[REBOL] Reading Binary data Re:(6)
[EMAIL PROTECTED] wrote:
Hello [EMAIL PROTECTED],
On 17-Jul-00, [EMAIL PROTECTED] wrote:
As per your instructions: Here is the code
fragment with your suggested changes:
;
fp: open/read/binary/direct %TestBin.txt ;
fp: skip fp 10
print to-string buffer: copy/part fp 10
close fp
do %BinFile.r
abcdefghij
This is on Win NT 4.0
What type of machine are you using?
Did it actually work for you.
Thanks for looking at this!
Tim
Unfortunally REBOL seems to have some bugs/inconsistencies in this area.
I've confirmed your results on REBOL 2.3.0.1.1 (Amiga).
For now you could try dropping the /binary statement and use 'read-io instead.
Seem's to work here:
## fp: open/read/direct %testbin.txt
## fp: skip fp 10
## buffer: make binary! 10
== #{}
## read-io fp buffer 10
== 10
## print buffer
#{6B6C6D6E6F7071727374}
## print to-string buffer
klmnopqrst
I've also been having trouble with the skip command on large files. For
example, I'm testing out the ftp restarting code, so I can download a 33
meg file, and if the connection is dropped after 10 megs have been
downloaded, I can just continue on with the remaining 23 megs. But, I
have a couple of problems...
Firstly, using 'write/append/direct/binary %file.bin large-buffer', if
the large-buffer is 1 meg in size (for example), each time I call
write/append, Rebol allocates 1 more meg of memory, which is very
annoying. I could put a 'recycle' after calling write, but I figured I
could just use open and skip.
So I try -
foo: open/binary/direct/write %file.bin
foo: skip foo foo/size
...
which should set the file position to the tail, but it crashes. If I
use 'foo: open/direct/write %file.bin' instead, it doesn't crash, but
the file position is only moved a small distance, like 1 bytes. So
then if I try and write some data, thinking that I'm appending to the
file, I'm just writing over the existing data. There's definitly some
wierd voodoo magic going on :)
Julian Kinraid
