AltME groups: search

What about 

>>RED
talk dialects


the >> is a play on the target image used in REBOL where >> is both 
from a console,and also an arrow head?

But in short - Red is going to be compiled language, and it will 
probably get some kind of JIT too, to allow interactive stuff like 
console. Red language compiles down to Red/System, which is kind 
of VM for it. In fact, it is REBOL-like low level wrapper to C, allowing 
some bindings. Red/System apps recently run even on ARM, eg I am 
able to run it on my HTC Sensation. But that's raw ARM Linux, no 
Android API linking yet ....

In Syllable, I repackage Red and Cheyenne in a package with a Unix-like 
structure, such as a separate subdirectory for the executable, but 
it gets cluttered because they find all their other files related 
to that executable. Actually, that's the way we want it to work for 
Syllable Desktop GUI applications, but for a console program that 
needs to be in the system path, you need the Unix structure with 
separate search paths for separate subdirectories

Do you use rsc.r from the REBOL console as well?

Yes, from REBOL console.

No, I mean the source code file ... but not sure it matters. E.g. 
for R3, I had difficulcy running some scripts, unless I re-saved 
the source file to UTF8. Some strange chars appeared in the console 
and apps crashed

I try to keep with the console Git to practice it properly, but it 
may not be easy under Windows. I don't know.

Pekr and Rebolek: could you try to use ProcessMonitor (PM) to see 
if we can get a clue about what is blocking the DLL loading from 
R2?


1) Download it from: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
2) Run it

3) Open a REBOL console and CD to the folder where the DLL is located

4) In PM, drag'n drop the "target" icon to the REBOL console window
5) Type in console: lib: load/library %temp.dll

6) Scroll down in the PM window to look for rebol.exe process entries, 
look for failure reports in Result and Detail columns...

Maybe there is no original screenshot and I remember it wrong, but 
the kernel exists and you can test it. It's Linux 0.00 and the major 
feature is switching between two tasks that print A and B in the 
console:

http://gunkies.org/wiki/Linux_0.00

Works! (was testing in the wrong console)

am I correct that there is no interactive console yet and you need 
to compile source code?

I would very much like to have a console, but it is not doable at 
this point (unless someone has a bright idea?). We'll add one as 
soon as possible.

For those testing Unicode output on Windows, you need to change the 
default raster font of DOS console to Consolas (recommended) or Lucida. 
The default font is unable to print Unicode characters.

(I've put the source of hello.red behind the console window)

font I use is Lucida Console ...

Anyway, we need more people testing Unicode support for Windows console, 
just in case we missed something.

I've just tested it on Windows console (using Consolas font), it 
works fine.

Doc - I can type without any issue, it is just that it does not display 
correctly in my console :-)

Strange observation - if I add another space between two words of 
"Vitej svete", it prints correctly in the console ...

You can just copy/past your console output there.

Maybe it is a font problem with the console then?

as you can see in my output, Chinese is not there, and third greek 
char is not there too ... but when copying from the console and pasting 
into Notepad, it shows the chars ...

yes, my font is Lucida Console. There is only one other option - 
raster ... I can't select any other font in that dialog ...

OK, so now I am back after the reboot, so my default Vista console 
uses nice Consolas font, and it now displays everything (apart from 
Chinese) correctly ...

Console scheme? We will have console? :-)

Of course, as soon as it will be possible to make Red work in a console.

Depend on what you mean by "debug version" and what debugging tools 
you're thinking about. My plan for Red is to deeply integrate it 
with the IDE, so that you'll be able to have advanced debugging capabilities, 
like step-by-step debugging. Such feature could maybe also be ported 
to the console version, so you'll be able to use it even without 
the IDE installed.


Also, I have thought the Red execution architecture to be as reflective 
as possible in order to try to support memory image loading/saving 
and stopping/resuming (think Smalltalk). It's very tricky (not sure 
we'll have it in the end), but if we can achieve it, you'll be able 
to get a snapshot of a running Red program on file, transfer it and 
resume it somewhere else....ideal for reproducing exact bugs occuring 
conditions. EDIT: the right expression for that is "Image-based persistence".


In the meantime, we already have some "debug mode": -d switch for 
Red and -g switch for Red/System (we'll probably adopt -d for both, 
-g will be reserved for gdb support). It's mainly intended for internal 
usage for now, the Red/System one can be useful to locate runtime 
errors in source code (usable, but still needs some fixes though).

hello-unicode in MSDOS: has he switched the DOS console to Consolas 
font?

Yes, MSDOS uses the 'console sub-system, while Windows target uses 
the 'GUI sub-system.

The difference lies in the PE header, the sub-system required to 
run the app needs to be set to either 'console or 'GUI.

But Windows seems to be quite permissive in recent versions, so a 
GUI app can also be started from DOS console.

Yes, it would be cleaner for the day when we will have real GUI apps 
in Red, in addition to console-only ones.

Calling it something like Windows-Console rather than MSDOS might 
be better, since the real MSDOS (or rather clones of it) is still 
a valid target for embedded development. The Windows console environment 
hasn't been MSDOS since the '90s.

Brian: I'm aware of that. The probabilty of someone porting Red to 
old MSDOS (no Unicode, no multitasking, no native TCP/IP) is very 
close to zero. If someone does it anyway, we'll adjust our targets 
ID accordingly. In the meantime, I prefer typing "-t MSDOS" rather 
than "-t Windows-Console" on command-line. Also, it's easier to remember 
for everyone, after all it's just an ID, nothing else.


If you are thinking about FreeDOS, which is probably a more likely 
target than real old MSDOS, I guess we won't have any name collision 
then. ;-)

what about calling it CMD (as is the command, cmd.exe, which you 
have to issue to open that black old console), or CON, as a "console"?

Brian: as I've explained to Kaj earlier, Windows does make a difference 
between apps built with GUI or built for console- only. If it wasn't 
the case, we would only have the "Windows" target.

Another OS for running Windows console binaries (and possibly more): 
http://www.jbox.dk/sanos/

AFAIK, windows consoles only supporting Windows 8-bit codepages or 
UTF16. Red/System can print the full range of UTF-8 characters (as 
can REBOL) but the console can't display them.

You would need to check that the Windows console is set to display 
UTF-16B.


This commit ( https://github.com/dockimbel/Red/commit/be271889ff03e44bdb55af04b60ea2bb280cb18f
) shows how.

Kaj: you can switch the Windows console to an UTF-8 compatible mode 
using _setmode():
http://msdn.microsoft.com/en-us/library/tw4k6df8.aspx


I haven't test it but it should work. Windows uses natively UTF-16LE, 
so you would probably have a speed penalty using that mode.

mandelbrot - just crashes. In console I can see a message "Access 
denied"

NT: I don't see much the connection with console-oriented programs.


Windows 95 support: all current win32 API bindings Red uses might 
not be compatible but Red could easily be made to work on such platform 
though.

Kaj - not sure it will be a console, but something like that, just 
not an interpreter, but more a JIT compiler?

It's available but not documented as it is only used by the compiler 
internally for now. You can add it to any of the target definition 
block in %config.r for testing (or create a %custom-targets.r file 
instead). It will put the compiler in an "incremental" mode (it can 
compile incrementally as many source file as you want). Once compilation 
has finished, no file will be generated and compiler state will not 
be reset. You can then inspect the result of the compilation from 
console using:

>> probe system-dialect/compiler/job
>> probe emitter/symbols
>> probe emitter/code-buf
>> probe emitter/data-buf
>> probe system-dialect/compiler/imports


You can basically get most of these data in logs when compiling using 
-v 9 option.

I am trying to write a test red-system program but it is a pain:

I write it in my editor, then open a Rebol console and do change-dir... 
do/args ... then:

If I open a window console and run the program I can not compile 
it anymore (it is locked by the console?), and if I try to run it 
in Rebol with call/console ... it hangs. Which is the right method?

If I open a window console and run the program I can not compile 
it anymore (it is locked by the console?), and if I try to run it 
in Rebol with call/console ... it hangs. 


I don't get this part...Your program seems to be still running while 
you think it has finished.

Does call/console work under Windows 7?


call/console "ver" causes REBOL to hang on my machine after printing 
"The handle is invalid twice."

Perhaps it is better to use call/output?

>> console-output: make string! 2000
== ""
>> call/output "ver" console-output
== 0
>> console-output
== "^/Microsoft Windows [Version 6.1.7601]^/"

Saphirion's Host-kit has been updated:
-added PNG encoder
-added Core extension module for generic additional commands
-reworked compile/build process
-fixed security flaw in Encap
-fixed bug caused non-functional networking
-improved console output handling logic
-patched ENCODE to not crash on png
-updated LOAD-GUI with currentspahirion link
-recompiled r3.exe, r3core.exe, r3encap.exe and r3ogl.exe

Update on the web-page will be available on the weekend.

Let me announce first achievement of bringing R3 to Android OS based 
devices. I know many of you were waiting for this so long so here 
is the first test version to download:

http://development.saphirion.com/experimental/R3droid.apk


Note this is just first raw port showing the interpreter is working. 
The console input is missing at the moment, but will be probably 
among first things to add so you can have your beloved /Core on your 
mobile/tablet.


If you would like to speed up this developement, donate, sponsor 
or make a bounty for features please crosscheck with Robert/Saphition(he'll 
write more info here as well)

Updated our R3 version. Changes:


- no longer links libstdc++ dynamically but statically. You get an 
error that libstdc++-6.dll is missing from your computer.

- changed startup procedure to support correct stdio redirection 
in console mode (used if you start R3 with a command line argument, 
else GUI mode)

I've added Doc's new Red interpreter REPL console to the Red test 
builds:

So you can now try it immediately. Currently only for Windows, so 
it's in MSDOS\Red\console.exe

I made a version of the Red interpreter console for other platforms 
than Windows. It runs on systems that have the ReadLine library. 
It uses both the libreadline and libhistory libraries, so it provides 
command line editing and history recall

For both, R2 and R3, you can use HELP on a console to get a listing 
of all global values of a certain type. So to see all functions, 
try
>> HELP function!

Only those that work with console. The rest seem to fail, because 
I don't have the appropriate DLLs.

was executing them from a console wrapping cmd.exe - there is a popup 
when executing directly

AdrianS: since Vista, Windows is hiding some runtime errors from 
console, you can check in "Event Viewer" if you think a crash occured.

the regular windows console doesn't block the output, so false alarm

as I can now see it, MSDOS is really pretty bad option for Red. It 
has really zero connection with MSDOS, surely it is normal windows 
probram, maybe just in console mode ...

No, console online at the moment.

yes, networking is not done yet.

You just download a *.r script (or copy on your sdcard in the phone). 
Then you can just clik on the script file and file association requester 
should popup so you can run *.r scripts just by clicking on them 
instead of execution from console.

BTW It would be interesting to see how R3 performs on multiple devices. 
The easier way is just open the R3 console and execute: SPEED?

Robert and Cyphre : As already stated under the Android group I have 
succeessfully tested the new console based R3 for Android under my 
Samsung Galaxy Tab 10.1 tablet - running Android 3.2. works well 
- thanks again a lot for this achievement - I wil shortly follow 
with some donation - simply waiting for my next salary deposit ...

Nice work Kaj. I'm working on Unicode support for the tokenizer, 
so the console should get at least Unicode support for the DevCon. 
I plan to write a real cross-platform console engine as nobody has 
stepped out to build one so far, I guess it should be ready for the 
DevCon.

Graham, the following might work:


http://archives.esperconsultancy.nl/Red-test/raw/MSDOS/Red/console-pro.exe?name=d355eac8e29ced2a6a90e9ce618486c358f02a79

The console-pro is here:

The following might be stable for the "latest" version of e.g. non-pro 
Win32 console:


http://red.esperconsultancy.nl/Red-test/raw/MSDOS/Red/console.exe?name=tip

red>> print "testing"
testing"

The console is just an early version I recall

Kaj: I'm looking at your %console-pro.red script and it's really 
enjoyable for me to see all the pieces of Red programming stack put 
together and working well, at this point of the project. Kudos for 
having add script file loading to the console! :-)

Sqlab, you're probably using the Red console. The interpreter doesn't 
recognise paths yet, so it can't execute functions with refinements

You can run Red as an interpreter, although that's still limited, 
from here, in MSDOS/Red/console:

The example programs are also in there, compiled and ready to run. 
For the console-pro, you need the libraries in the RedSystem folder

MaxV: you might have missed the announce, but Red has an interpreter 
and a console since new year.

You might want to check this: http://static.red-lang.org/console-pro.png

I have the same problems with XP.
The exe does nothing but the url line.

If I try to do or read  the .red from the console-pro, the console 
window closes.

Kai, the behavior that console-pro closes after reading a file is 
still present

Sqlab, I have no problem loading files from the command line into 
console-pro on Windows XP

Are you sure you have downloaded the latest console-pro.exe?

console-pro test.red

sorry wrong group
Kaj, 

the problem, that the console window closed, was caused by my wong 
assumption, that the convention for file names is the same as in 
Rebol.
i.e.
read   -> crash
read %test -- > crash
write %test -- > crash
read "test"   --> works

BTW Carl restarted the "R3 chat" server so you can just type: "chat" 
in the Android console and leave message here.

This is fantastic Doc. I know it's still very early days, but you 
are making great progress and it's very exciting to see it come to 
life. When I copied the commands from the new blog entry, to build 
the console, and it worked the first time, perfectly, it made my 
day. Then, even doing just simple things in the console was fun.

But if you define a routine in a Red script, and then DO it, it will 
work. You can also build a custom console by writing a Red script 
and adding at the end an %include %<path-to>/console.red.

I will do it myself if nobody else steps in, once we get the target 
console implemented (Unicode LOAD, EXIT and RETURN supported,...)

I'm working on console downloads

Thank you BrianH.

My question is, REBOL process (console or encapped app.) doesn't 
automatically detect of the time zone settings change of the PC.
>> now/zone
== 3:00

>> ;I changed my local time zone to +2 GMT or it changed automatically
>> now/zone
== 3:00


Is there a way to "refresh" zone in NOW, without closing and reopening 
the app.

Let's say I get the Windows time zone using a Win32 API. Then something 
like
>> now/zone: 2:00
== 2:00
>> now
== 8-May-2012/23:45:16+3:00 ;doesn't work

I mean - text I need to input into the resulting file (UTF-8) is 
ANSI. I do print to-string read %text-slider.html, and in R3 console, 
Czech text is not correct ....

The console may be broken. How about the actual text, in an editor?

in editor, it's correct. Simply put - I read czech text from an ansi 
file, and it is distorted in console, ditto when writing it back 
to file of course ....

When you cut and paste it from the console, or when you write it 
with REBOL?

Guiseppe: "Could it be written as: ..."
TO ANY doesn't work.
but ANY [TO "..." BREAK | TO "..." BREAK] works.

just be careful using ANY and TO together, because they both don't 
advance the series pointer. So you can easily put the console in 
an infinit loop (escape key also doesn't work)

try this interactive test:

view layout [p: panel [button]]

escape to console and type:

p/pane: get in layout/tight [field 100] 'pane

show p

when escaping to the console, events are no longer processed in the 
window. to continue getting events in the window, type:

do-events

Talking of test, I am trying to write a simple function that checks 
if a data item matches a rebol datatype, so for example:

    print is-it-a? "number?" "12.5"
    == true
    print is-it-a? "number?" "xxx"
    == false
    print is-it-a? "number?" "?"
    == false


Except my function goes bad on that third example -- it prints the 
console help text.


Any thoughts on how to check incoming values without executing them 
as code? Thanks

    is-it-a?: func [
       data-type [string!]
       value [string!]
    ][
      data-type: first load/all data-type  
      error? try [
          value: first load/all value 
          return do reduce [data-type value]
      ]
      false
    ]

Another interesting problem I have: I have a script as follow:
REBOL []
probe system/options/args
halt


I encap this script, no problem, it works as expected, console opens 
and "none" appears:
none
** Press enter to quit...

If I run it with some params like "test.exe --test"
["--test"]
** Press enter to quit... 


But if I run it with some parameters, like -c, --sec, it prints nothing? 
(-c and --sec seems to be special for rebol.exe but it works with 
-s which is special too)
** Press enter to quit...

Why and how PROBE doesn't produce an output?

-c means cgi ==> So not ouput to the console

BrianH: Yes I realized that at least one word is required.

sqlab: I encap a script and run the executable, so I should able 
to use any command line parameter. And I don't encap with cgi option. 
Also -w parameter has no such a problem (which is "no-window option 
for REBOL)

Anything that include "c" char prevents to print/probe to the console.

On the other hand it doesn't prevent opening console window. I see 
"** Press enter to quit" message when program HALTed but PRINTs don't 
output anything.

Somehow indeed I managed to mix up core and view console so sound 
did work afterall. Sorry for the noise :( 
But still a wish for sound in REBOL on other platforms.

I want to change some data in a mysql database from a REBOL (2) program 
using DocKimbel's mysql-portocol.r When I use a .r script from my 
website I can connect to the database. I figured that when I ran 
a script from a console I would be able to quickly test my script 
but somehow I am stopped because the script cannot connect. This 
is the error:
** Access Error: Cannot connect to mysql-01.yourname.nl
** Where: open-proto
** Near:
Any ideas?