newbie - How to

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?"

> Windows does not have a console itself, > windows has a window which is a dos-shell, thats the > confusion here...

>rebol -w hello.r

>rebol -w hello.r

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

> 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:

Heavens this is frustrating!

>rebol -w -q hello.r | more

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

Issac:

> 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" ?

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.

Thanks for the information guys.

> (Basicly this is a lack of feature > in Windows not rebol.)

> Is that a critical issue for what you > want to accomplish?

> you may need to wean your user into > looking at the REBOL console output > instead of the DOS console.

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).

> -> Which is what I wanted except piping through more adds > -> an extra newline and overhead.

> Hello Isaac, > (Basicly this is a lack of feature in Windows not rebol.) > [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.

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

* 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.

> > Is that a critical issue for what you > > want to accomplish? > I don't think so! > I need to use Lua or Python or...

Hi isaac, On Saturday, June 21, 2003, 3:16:51 PM, you wrote:

>> (Basicly this is a lack of feature >> in Windows not rebol.)

>> print "Hello world!"

--- Gabriele Santilli wrote:

> 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.

* Daril Ng <[ishtahara--yahoo--com]> [030621 13:12]:

> --- Gabriele Santilli wrote: > > Don't play what? Window's console is non- > 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.

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

> Window's console is non-existant, so REBOL has > its own, ... on any other platform.

> You fire up the interpreter, and... > Easier than that?

> The code to do a 'hello world' in python > or perl or rebol is virtually the same

--- 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

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

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

Hi Gabriele,

> I'm around here since /Core 1.0.2 or so, but I'm not yet > approaching the bottom it seems.) >

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

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

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