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:ya:hoo 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::yahoo 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:y:ahoo 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:ya:hoo 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:ya:hoo 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:ya:hoo 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:y:ahoo 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