• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[!REBOL3] General discussion about REBOL 3

BrianH
26-Dec-2012
[334x3]
Pekr, R2's console was GUI on Windows, not a real console app. Carl 
had wanted to make an R3 console like R2's but better, in the R3 
GUI. We just never got around to it.
Some of the rest of us (me particularly) had missed the Linux/OSX-style 
real console for R2, and saw the advantage of having that as an option 
in R3. We never really got that because R3 opened another window 
instead of operating in the console it was called from, which turned 
out to be the worst of both worlds.
Carl's blog was about the inline text-mode problem, trying to solve 
the open-a-window bug. That wasn't about the planned GUI, it was 
about fixing the existing console.
Pekr
26-Dec-2012
[337]
brian, iirc, it was about inability to have view exe being used as 
real fonsole. Carl did not find a way of how to do it ...
BrianH
26-Dec-2012
[338x2]
If you are talking about the existing R3 console, the problem was 
that he couldn't make a real console-mode R3 program without losing 
functionality that he only knew how to support in GUI-mode programs, 
and he couldn't make a GUI-mode app use the Windows console without 
allocating its own console window, which lost all of the advantages. 
It's not to say that this can't be done, just that noone who had 
the interest and ability to do this had made the effort, because 
it was low-priority for the contributors at the time. With more contributors 
now, perhaps this will get fixed.
If R3 is able to use the real Windows console instead of its own 
console window, you could solve the color scheme issue by using an 
alternate console - there are many - or changing your settings. It's 
up to you. However, if it allocates its own console window then you 
can't use any of the alternate console managers.
AdrianS
26-Dec-2012
[340]
Hmm, maybe the author of ConEmu should be approached about this - 
maybe he'd be interested in order to get a scripting language included.

http://code.google.com/p/conemu-maximus5/
BrianH
26-Dec-2012
[341]
Stuff like that is what we had in mind as an advantage of supporting 
the regular Windows console, Adrian. That and remote console or powershell 
use.
Andreas
26-Dec-2012
[342x2]
You can fix the "own console popping up" for Win32 R3 right away, 
if you have MSVC installed: 
$ editbin /subsystem:console r3.exe
Then r3.exe will use the "real" Windows console, when launched from 
one.
BrianH
26-Dec-2012
[344]
That's the console-mode app thing. This supposedly caused problems, 
which Carl asked about in the blog.
Andreas
26-Dec-2012
[345]
That's responsible for r3.exe having to pop up it's own console and 
not being able to reuse the parent console, if present.
BrianH
26-Dec-2012
[346x2]
Right. But supposedly changing the app to console-mode like that 
caused other problems, which I don't remember because I don't have 
a link to the blog in question.
Also, is it possible to just compile it that way in the first place? 
And is it possible for such an app to bring up a GUI, say so that 
it can run console scripts and GUI scripts?
Andreas
26-Dec-2012
[348x4]
The other problems need to be ironed out :)
Such an app can bring up a GUI, yes.


However, it will always pop up a console window (which can be closed 
immediately, but this will result in the "console flashing" effect 
some dislike).
Yes, we should built it that way in the first place. We only recently 
added building in GUI mode, to avoid a crash with console mode binaries 
when launched from shells other than cmd.exe. (Another bug that needs 
fixing).
But note that most (all?) official RT R3 alpha builds have been GUI 
mode binaries.
Kaj
26-Dec-2012
[352]
Brian, I build the Red examples in both modes, so you can try out 
the effect if you want. MSDOS/console programs can open a window, 
but Windows/GUI apps don't seem to be capable of using stdout, at 
least not to a console they're started from
BrianH
26-Dec-2012
[353x2]
OK, but I really want to reserve the term "MSDOS" for programs that 
actually run on MSDOS, a still-common embedded systems OS.
Not commonly by MS, but as DOS-compatible platforms.
Kaj
26-Dec-2012
[355]
We know that, but when giving you pointers I have to go by existing 
paths
Gerard
26-Dec-2012
[356x2]
And my "remerciements" have to go to every direct and indirect contributor 
too (Carl S, KaJ, Peter, Andreas, Ladislav, BrianH, Nick, Maxim, 
Pekr,  Jerry, many guys of the French and other international communities 
too ... name them - there's too much to name all of them without 
leaving someone behind). My best wishes to you all Gang- you're forming 
an exceptionally tight and prosperous team. Your tools are the best 
I saw for being productive and easyness of use. Let's the Red/Red-System 
combination, to be the future C language replacement as the new World's 
low/high level language mix of choice.  Not to be without mentioning 
the REBOL and its loyal followers too (many of the same Red contributors 
but many more like Robert, Cyphre, Henrik ... and many others which 
have found their way while we were waiting for R3 to become open 
source, like Gabriele, Geomol ... - without which we would never 
be here now.
Sorry it was intended for the Red group first but as you see I am 
thinking about every one of you all - keep up the good work everybody 
!
Pekr
27-Dec-2012
[358]
BrianH: just for the reference - here's the console related blog 
and comments - http://www.rebol.net/cgi-bin/r3blog.r?view=0282#comments
BrianH
27-Dec-2012
[359]
Thanks.
Mchean
28-Dec-2012
[360]
wow impressed with the forward motion.
Andreas
29-Dec-2012
[361]
First baby steps towards R3 64-bit builds:
https://github.com/rebol/r3/issues/45#issuecomment-11746288


TL;DR: We are slowly getting to a foundation for more serious 64-bit 
work.
GrahamC
29-Dec-2012
[362]
64 bit slower than 32 bit?
Andreas
29-Dec-2012
[363x2]
Yes, but that's not really any useful "user level" metric.
(At the moment.)
BrianH
29-Dec-2012
[365]
It would be slower, it would have to push more memory.
Andreas
29-Dec-2012
[366]
The 64-bit builds are not in any way real 64-bit ports. It's just 
getting 32b R3 to build natively. The R3 data structures are tuned 
for 32b architectures. Nothing of that sort is yet done for the 64 
bit builds.
GrahamC
29-Dec-2012
[367x2]
I remember 32 bit windows slower than 16 bit
Oh well, back to the CBM64 8 bit days
Andreas
29-Dec-2012
[369]
My guess for the current timing difference would be that it's mostly 
attributable to misalignment exceptions.
BrianH
29-Dec-2012
[370]
They would have to be larger anyways, just to fit the larger pointers. 
Not yet optimized, but larger.
GrahamC
29-Dec-2012
[371]
Anyway, great progress ... looking forward to accessing large memory
Andreas
29-Dec-2012
[372x5]
I also have tested on a CPU where misalignment penalties are quite 
heavy. Trying this on different CPUs might lead to quite different 
results.
(I'll just delete the timinig remark for now, to avoid unnecessary 
confusion.)
Well, the explanation performance difference is even simpler. It 
comes just from disabling compiler optimisations.
Running on a misalignment-tolerant machine, the unoptimised 64b binary 
is actually slightly faster than the unoptimised 32b binary.
Still a useless "user level" metric, at the moment :)
Pekr
30-Dec-2012
[377]
now, as the situation has changes, some minor topic, but maybe better 
to open it sooner than later - some ppl adopted .r3 extension for 
R3. When working with console, I constantly forget to type .r3 and 
type .r instead. I know, that we want to distinguish R2 to R3 scripts, 
but as R2 is most probably not going to be opensourced, and although 
it will serve us well for quite some time, what about once again 
get back to .r extension even for R3?
Ladislav
30-Dec-2012
[378]
...we want to distinguish R2 to R3 scripts...

 - it depends. I found out it was much easier to maintain %include.r 
 running in both R2 and R3 than to have two separate versions needing 
 the same care twice.
BrianH
30-Dec-2012
[379x3]
I use .r for scripts that are expected to run in R2 or R3, .r2 for 
R2-only scripts and .r3 for R3-only scripts. However, a lot of my 
scripts are .cmd and call themselves with the appropriate Rebol.
In general, it is rare for me to use .r for scripts other than rebol.r, 
and I use the same one with R2 and R3.
I use .cmd instead of .bat because the tricks you use to call Rebol 
safely require cmd.exe (in NT-based Windows) and won't work with 
command.com (in Win9x/Me). It's not necessary to use .cmd for this, 
but it's a good reminder.
Robert
30-Dec-2012
[382]
.r = both
.r2 = R2 only
.r3 = R3 only
GrahamC
1-Jan-2013
[383]
Didn't help take you to a web page on www.rebol.com once?