Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

newbie - How to

 [1/25] from: Rebolinth::nodep::dds::nl at: 20-Jun-2003 22:54


Hello Isaac, Windows does not have a console itself, windows has a window which is a dos-shell, thats the confusion here... write %file.r { rebol [] print "first entry" wait 0:0:10 } that executes but in the rebol window... Unices and other have only the shell as console so that the differance... yuo could use /view like: view layout [ text "first try" ] ...dont get addicted though... (R)egards, Norman. -- Conversation/lunch: "How do you Eat your Rebol in the Morning?"

 [2/25] from: igouy:y:ahoo at: 20-Jun-2003 14:28


> Windows does not have a console itself, > windows has a window which is a dos-shell, thats the > confusion here...
Let me rephrase my question ;-) On Windows XP, I'd like to run a Rebol script from a Command Prompt window, like so:
>rebol -w hello.r
I'd like the script to put some characters on whatever Rebol thinks is the equivalent of stdout, so that it shows up like this:
>rebol -w hello.r
hello world
Is that something I can do on Windows XP using Rebol/Core or Rebol/View ?

 [3/25] from: greggirwin:mindspring at: 20-Jun-2003 16:27


Hi Isaac, ig> On Windows XP, I'd like to run a Rebol script from a ig> Command Prompt window, like so: ... ig> I'd like the script to put some characters on whatever ig> Rebol thinks is the equivalent of stdout, so that it ig> shows up like this: ... ig> Is that something I can do on Windows XP using ig> Rebol/Core or Rebol/View ? Not that I know of. I don't recall what the exact issue is, but I think REBOL redirects to its own console window. You can redirect the data out to a file though. So you should be able to do what you want indirectly. -- Gregg

 [4/25] from: brett:codeconscious at: 21-Jun-2003 13:42


> I'd like the script to put some characters on whatever > Rebol thinks is the equivalent of stdout, so that it > shows up like this:
This sort of thing works for me on NT 4.0: c:\rebol.exe -w -q script.r>out.txt Regards, Brett.

 [5/25] from: igouy:y:ahoo at: 20-Jun-2003 22:10


Heavens this is frustrating!
>rebol -w -q hello.r | more
hello world
Which is what I wanted except piping through more adds an extra newline and overhead. If the rebol script output gets to "|more" why doesn't it appear in the window without "|more" ?

 [6/25] from: greggirwin:mindspring at: 21-Jun-2003 0:57


Hi Isaac, ig> Which is what I wanted except piping through more adds ig> an extra newline and overhead. Is that a critical issue for what you want to accomplish? ig> If the rebol script output gets to "|more" why doesn't ig> it appear in the window without "|more" ? Again, I don't know the exact reason, or if RT is even addressing it, though I hope they do. For now, that's the way it is. You could send them a feedback about it. I know they know, but this doesn't come up very often so it would remind them about it. I don't think there's anything to help in this case, but you might check out http://www.rebol.com/docs/shell.html for future reference about other redirection related behavior. -- Gregg

 [7/25] from: SunandaDH:aol at: 21-Jun-2003 3:36


Issac:
> Which is what I wanted except piping through more adds > an extra newline and overhead.
Well, you are getting close! You could try replacing the last 'print with a 'prin -- that might solve the extra newline issue. I'm not sure what you mean by "overhead" but piping to more is always going to have a couple of drawbacks: an intermediate file, and no output appearing until program termination. If these are problems, you may need to wean your user into looking at the REBOL console output instead of the DOS console.
> If the rebol script output gets to "|more" why doesn't > it appear in the window without "|more" ?
That's a mystery. |more doesn't work at all on my set-up -- I just get a DOS redirection error. You could avoid using |More, and perhaps gain a little more control over what you are trying to do like this: --------hello.r-------- REBOL [ Title: "Hello World"] echo %temp.txt print "hello world" -------- Then execute it with a bat file: ---------hello.bat------- @echo off rebol -sq hello.r type temp.txt -------- (Note the -sq to remove any "script wants permissions" popups) This gives me just three lines of output on the DOS console: c:\temp>runhello Hello world C:\temp> Sunanda.

 [8/25] from: Rebolinth:nodep:dds:nl at: 21-Jun-2003 11:53


Hello Isaac, -> Which is what I wanted except piping through more adds -> an extra newline and overhead. Thats not possible because REBOL outputs to its own stdout (the console) and not the command.com of windows. (Which is not a console). (Basicly this is a lack of feature in Windows not rebol.) The only way is to output your IO to a port (file/network/serial) which then is evaluated by a shell command like "more". Regards, Norman.

 [9/25] from: igouy::yahoo at: 21-Jun-2003 6:16


Thanks for the information guys.
> (Basicly this is a lack of feature > in Windows not rebol.)
Errr, languages that don't play tend to go away.
> Is that a critical issue for what you > want to accomplish?
Yes and no. More importantly it was the very first thing I tried to do (hello world, there's a suprise) and couldn't figure out if it was possible with the version of Rebol I downloaded.
> you may need to wean your user into > looking at the REBOL console output > instead of the DOS console.
I don't think so! I need to use Lua or Python or... best wishes, Isaac

 [10/25] from: tim:johnsons-web at: 21-Jun-2003 8:15


Howdy: I have deleted the original posting on this, but I believe that the Isaac is using Win XP
> Thats not possible because REBOL outputs to its own stdout (the console) and > not the command.com of windows. (Which is not a console).
I believe the command interpeter for XP is cmd.exe..
> -> Which is what I wanted except piping through more adds > -> an extra newline and overhead.
Isaac, I don't know if this would work for you, but I've done some things for clients on Windows in which I directed output to CGI. CGI isn't just for remote servers after all. It's a great way to manage output for a desktop without much overhead - and if you are familiar with HTML and JavaScript, you can harness them through good ol' stdout piped through the browser.. tim * Rebolinth <[Rebolinth--nodep--dds--nl]> [030621 02:20]:
> Hello Isaac, > (Basicly this is a lack of feature in Windows not rebol.)
<<quoted lines omitted: 5>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com http://www.johnsons-web.com

 [11/25] from: greggirwin:mindspring at: 21-Jun-2003 10:21


Hi Isaac, ig> Errr, languages that don't play tend to go away. Actually, *most* languages go away, whether they play or not. :) ig> More importantly it was the very first thing I tried ig> to do (hello world, there's a suprise) and couldn't ig> figure out if it was possible with the version of ig> Rebol I downloaded. Yup, that's always an issue when you try something new. If it doesn't work well for the first thing you throw at it, it's easy to write it off. If this particular issue is the bread and butter of what you write then, yes, REBOL probably isn't going to help you much. If it's an edge case though, think about what issues *are* really important to you in a language overall and evaluate REBOL in that context. ig> I need to use Lua or Python or... Best of luck with whatever you choose! -- Gregg

 [12/25] from: tim:johnsons-web at: 21-Jun-2003 10:12


* isaac gouy <[igouy--yahoo--com]> [030621 05:45]:
> Thanks for the information guys. > > > (Basicly this is a lack of feature > > in Windows not rebol.) > > Errr, languages that don't play tend to go away.
Isaac, I had a terrible time learning rebol at first. But I got a 'full-court' press in terms of support from folks on this list. Let them help you and follow their advice. Rebol 'plays' all right. I've built some very large websites with rebol and it has paid many of my bills. I have programmed or do program in: Cobol, Basic, Pascal, Assembler, dBaseIII, C,C++, Object Pascal, perl, python, tcl, expect, css, html, javascript, DOS commands, and linux shell script. (At least). Rebol is the most productive of all of those above.
> > Is that a critical issue for what you > > want to accomplish?
<<quoted lines omitted: 8>>
> I don't think so! > I need to use Lua or Python or...
I am currently working on a project in which I am literally coding in rebol and python at the same time. Python has much to recommend it, I wouldn't use it other wise, but I do less typing with rebol. Every language that I have programmed in has it's strength and weaknesses. The code to do a 'hello world' in python or perl or rebol is virtually the same. -- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com http://www.johnsons-web.com

 [13/25] from: g:santilli:tiscalinet:it at: 21-Jun-2003 20:48


Hi isaac, On Saturday, June 21, 2003, 3:16:51 PM, you wrote:
>> (Basicly this is a lack of feature >> in Windows not rebol.)
ig> Errr, languages that don't play tend to go away. Don't play what? Window's console is non-existant, so REBOL has its own, so that there is no difference if your scripts run on Windows or on Linux or on any other platform. ig> More importantly it was the very first thing I tried ig> to do (hello world, there's a suprise) and couldn't ig> figure out if it was possible with the version of ig> Rebol I downloaded. You fire up the interpreter, and...
>> print "Hello world!"
Hello world! Easier than that? Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [14/25] from: ishtahara:y:ahoo at: 21-Jun-2003 13:42


--- Gabriele Santilli wrote:
> Don't play what? Window's console is non- > existant, so REBOL has its own
Respecfully I don think this is accurate. No flames please.
> so that there is no difference if your scripts > run on Windows or on Linux or on any other platform.
If a tool fails the requirements of a problem, no-one will pursue the tool further. Running on many platforms still means failure. REBOL is really good when your main challenge are to get code to work on numerous platforms and you obsessed with small codebase and footprint (disk not memory). But REBOL appears a tragedy if you need to integrate with OS features, hardware, or applications. This limits some important uses in Windows, Mac and other environments. All tools have strengths and weaknesses, so what's new? More than other languages, REBOL is a king of convenience, so I continue to invest my time. ~D

 [15/25] from: tim:johnsons-web at: 21-Jun-2003 14:05


* Daril Ng <[ishtahara--yahoo--com]> [030621 13:12]:
> --- Gabriele Santilli wrote: > > Don't play what? Window's console is non-
<<quoted lines omitted: 14>>
> limits some important uses in Windows, Mac and other > environments.
Yes. However, there are times with such integration or the possibility of such integeration is *not* desirable. Weaknesses can be strengths...
> All tools have strengths and weaknesses, so what's > new? More than other languages, REBOL is a king of > convenience, so I continue to invest my time.
Definitely, REBOL *is* a king of convenience. One of my brothers is a engineer and project chief for Motorola. They use Perl for regex searchs, rebol for socket connections and parsing. Exploiting the individual language strengths. tj -- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com http://www.johnsons-web.com

 [16/25] from: greggirwin:mindspring at: 21-Jun-2003 16:14


Hi Daril, DN> No flames please. I've never seen Gabriele, or really anyone here, flame. We may have loud, impassioned discussions from time to time though. :) DN> If a tool fails the requirements of a problem, no-one DN> will pursue the tool further. Running on many DN> platforms still means failure. Agreed 100%. DN> REBOL is really good when your main challenge are to DN> get code to work on numerous platforms and you DN> obsessed with small codebase and footprint (disk not DN> memory). The multi-platform aspect is important given REBOL's intended use. If you change "get code to work on" to "exchange data across", it fits better with REBOL's goal. That said, yeah, we generally use it to write code, much as we would other languages, at this point in time so it's a valid perspective. "Obsessed" is a pretty strong word though; I'm more concerned with elegance, stability, maintainability, extensibility, and clarity. You wouldn't know it to look at some of my code, but it's true. :) DN> But REBOL appears a tragedy if you need to integrate DN> with OS features, hardware, or applications. This DN> limits some important uses in Windows, Mac and other DN> environments. Hmmm, "tragedy" is another pretty strong term (maybe I'm reading too much into it :). I've successfully mapped a number of API functions, as have others here, and integrated with other apps by sending them Windows messages and keystrokes. What OS features (excepting the current console issue under Windows) are tragically unavailable in your view? (printing is on of *my* personal issues) No flame intended here. I'm always glad to find out what problems other people see, or what they think is missing in REBOL. I think we all benefit, including RT, from identifying specific issues that prevent people from using REBOL effectively. -- Gregg

 [17/25] from: igouy:y:ahoo at: 21-Jun-2003 19:14


> Window's console is non-existant, so REBOL has > its own, ... on any other platform.
I'm very familiar with languages that provide their own "console" (Smalltalk, Oberon 2) and I appreciate the benefits. I also appreciate that sometimes output is required to appear on the OS shell.
> You fire up the interpreter, and... > Easier than that?
I think I explained that wasn't what was required. best wishes, Isaac

 [18/25] from: igouy:yah:oo at: 21-Jun-2003 19:20


> The code to do a 'hello world' in python > or perl or rebol is virtually the same
I'm sure - which is why it was so frustrating not be able to get the output to appear where it was needed. Someone mentioned this was a Windows problem, does that mean it isn't a problem using Cygwin? (I don't have Cygwin installed) best wishes, Isaac

 [19/25] from: ishtahara::yahoo at: 21-Jun-2003 19:55


--- Gregg Irwin wrote: GI> Hi Daril, Hello Gregg GI> I've never seen Gabriele, or really anyone here, GI> flame. Yes, this seems like a nice mailing list. I need to adjust. GI> If you change "get code to work on" to GI> "exchange data across", it fits better GI> with REBOL's goal. Thank you for this explanation. I think of XML for data exchange and in practice I decouple data over-the-wire from client processing. What will be more accepted: Client apps that have unique platform richness and process a universal data format (XML) Or A universal client (REBOL) that uses powerful yet non-standard data format and has integration limits. GI> "Obsessed" is a pretty strong word though; My english isn't strong, but I mean that smallness seems a very high design philosophy in REBOL. REBOL compares to FORTH very much in this aspect, and yet the formula does not appear potent historically. GI> Hmmm, "tragedy" is another pretty strong term I mean that REBOL offers powerful features very easily, but hit hard limits with integration or GUI features. APIs are better abstracted by non-REBOL tools, so it is easier to use them. In my first weeks with REBOL I found limits in areas where I never once considered. I now know better when to use REBOL and when not. However, Isaac Gouy found limits in his first 5 minutes so he may not recover. It is bitter message if he can't solve his problem simply because the problem itself is not platform independent. ~D

 [20/25] from: g:santilli:tiscalinet:it at: 22-Jun-2003 12:25


Hi Daril, On Sunday, June 22, 2003, 4:55:51 AM, you wrote: DN> However, Isaac Gouy found DN> limits in his first 5 minutes so he may not recover. It's these limits I don't understand. What do you need "console printing" for? Piping to another process? That seems to work, and when it doesn't, you can write to a temp file and then read it back (old versions of Win are doing that anyway when using pipes, so I don't see it as a workaround, but as the only way to do it in that environments). Sending output to a file via redirection? I think that works too, and you can do that so easily in REBOL itself that it is not point anyway. CGI? It works. Prompting the user? REBOL's console is much better than Windows', so just use that. Anything else? Of course, Isaac is free of using whatever language he wishes, and I suggest him doing so. However, I think REBOL deserves better explorations than just HelloWorld. ;-) And I know for sure that REBOL is too easily underestimated, and that's too bad, really. (As Carl often says, REBOL is like a lake: at first you only see the surface, but only later on you can discover how deep it is. I'm around here since /Core 1.0.2 or so, but I'm not yet approaching the bottom it seems.) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [21/25] from: g:santilli:tiscalinet:it at: 22-Jun-2003 12:12


Hi Daril, On Saturday, June 21, 2003, 10:42:40 PM, you wrote: DN> Respecfully I don think this is accurate. No flames DN> please. No flames here, and I don't want to mean rude. DN> If a tool fails the requirements of a problem, no-one DN> will pursue the tool further. Running on many DN> platforms still means failure. Exactly, but the point here was the requirement. I do not understand what it is. If you want to write HelloWorld.r, it's just print "Hello World!" and it works across all versions of REBOL. Now, REBOL probably has a lot of problems, but I really don't see HelloWorld as being one of them. DN> But REBOL appears a tragedy if you need to integrate DN> with OS features, hardware, or applications. This DN> limits some important uses in Windows, Mac and other DN> environments. It really depends; you can do that, you just have to pay for it. I don't want to discuss if this is good or bad, this is just how it is right now (and it could change in the near future). Also, why do you need REBOL if you are writing something that can be written more easily in another language? You don't. I need REBOL because what I write in it would require 2x the time in most other languages (10x on some of them). Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [22/25] from: maarten:koopmans:surfnet:nl at: 22-Jun-2003 13:08


Hi Gabriele,
> I'm around here since /Core 1.0.2 or so, but I'm not yet > approaching the bottom it seems.) >
Don't be modest ;-) --Maarten

 [23/25] from: greggirwin:mindspring at: 22-Jun-2003 0:59


Hi Daril, DN> What will be more accepted: ... DN> A universal client (REBOL) that uses powerful yet DN> non-standard data format and has integration limits. I can't speak for anyone else here (or anywhere else for that matter :), but I'm not very fond of XML (to put it mildly). It doesn't matter to me if REBOL's native format is widely accepted, but for those who adopt it, I think there are major benefits to be had. DN> My english isn't strong, but I mean that smallness DN> seems a very high design philosophy in REBOL. REBOL DN> compares to FORTH very much in this aspect, and yet DN> the formula does not appear potent historically. Well, your English is good enough that I didn't know it wasn't native for you! It's *very* good. And yes, you're absolutely correct that is seems smallness is a priority, but I think they (at RT), and we, strive more for simplicity and elegance; the size reduction is a happy side effect, not an end to itself. DN> I mean that REBOL offers powerful features very DN> easily, but hit hard limits with integration or GUI DN> features. I have a few limits I've hit with REBOL, but really *very* few. Of course there are things each of us want (don't get started now Pekr! ;) but there aren't any technical showstoppers keeping me from using REBOL. What I *have* done is changed my perceptions at times. When I first started with REBOL, I wanted to mold it into what I was familiar with, and that often didn't work well. I would write functions to change the behavior of things that were built in, but that caused things not to fit together well with the rest of REBOL. So, I started looking at the big picture and the long view. When I wanted to change something, because I thought it was wrong, I would stop and think about it; try to see how it fit into the grand scheme of things; and try to decide honestly if my way was better. So far, there aren't too many things that I'm still not sure of as far as basic design choices. Carl and the team seem to think long and hard about what they do. We may not always know why things work a certain way, but I've become very confident that not much in REBOL works the way it does by accident. :) DN> APIs are better abstracted by non-REBOL tools, so it is easier to DN> use them. The GUI issue is always interesting to me (I specialized in VB for 11 years) and I did a lot of work against the API from VB. There are a lot of things about VID that could be better, to be sure, but you have to admit that it gives us a lot of bang for the buck. It can be work to research things out when you need to go beyond the basics, but if you've ever written an ActiveX control that needed to do subclassing or anything out of the ordinary, how does REBOL compare? What really excites me is not how good VID is, but that it's just an *example* of what can be done with REBOL. There's no reason (especially since you can see the source) that you can't cook up your own UI dialect that blows VID away. They've given us the springboard, all we have to do is jump. :) On the API side, the easier it is to use them, the more people will use them, and the more scripts will become Windows-centric. Given my background, penchant for writing code generators, and REBOL, it shouldn't be *too* hard to write a tool that will take API declarations and create REBOL-friendly versions. I haven't done it though, by conscious choice. I think it would hurt more than it helps. DN> In my first weeks with REBOL I found limits in areas DN> where I never once considered. I now know better when DN> to use REBOL and when not. However, Isaac Gouy found DN> limits in his first 5 minutes so he may not recover. DN> It is bitter message if he can't solve his problem DN> simply because the problem itself is not platform DN> independent. There are indeed limits, as with all things. If there is a specific thing you need to do, and REBOL doesn't do it, there's not much to say. Other than that, I'm thankful for the people on this list who have helped me over hurdles when I thought I hit a limit in REBOL. There are still a few of course, but these are clever folks. ;) Sorry I got so long winded. Sometimes I start talking and forget to stop. :) -- Gregg

 [24/25] from: maximo:meteorstudios at: 23-Jun-2003 11:58


Ye hah !! a little comment from a newbie and the list gets all heated up :-) I've been programming for 20 years now (I'm 28 tomorrow ;-) and I've been through many different concepts, ... anyone remember logo, tape disks, zaxxon ;-) I love talking evangelisation, but come on, we are here to help anyone. If someone doesn't look through the skin of a banana, let him throw it away... We all know how good the fruit is... let him miss out on it, who cares! It would be fun for rebol to print in a shell... If everyone says windows has no shell, then why does python and many other applications print right in the command prompt they are run from? why couldnt reboltech simply add some winshell:// port or what have you...? I hate calling commands and having one dos window pop-up everytime. I feel his pain. btw someone said rebol wasn't really good at hardware and whatever... may I say that I used rebol to program a SCSI mounted Digital Disk Recorder in hardware, through the aspi.dll and had real time feed back when sliding a view scrollbar!? yep it works... It would just be cool if someone wrote a dialect to import .h files and package .dlls without having to peruse and transcribe the includes and headers by hand... someday, I guess... -MAx

 [25/25] from: tomc:darkwing:uoregon at: 24-Jun-2003 13:09


it is not a problem on solaris you get the behavior you expect. On Sat, 21 Jun 2003, isaac gouy wrote:

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