AltME groups: search

Nope, as we haven't found someone skilled enough yet to convert the 
Tower of HanoÏ draft into a real logo.

I'd like to know what your development environment for Red/System 
is especially that used by Doc.
In the meantime...
	My development environment:
	OS: Windows 7
	Editor: Notepad++ v5.0.3
	  not the latest version but I prefer this one,

   using "Python" as the language for syntax highlithing and coloring

   (there is not a "REBOL" language) and used mainly for the folding 
   on indentation

   (I can not live without folding, and folding on indentation makes 
   life even easier)

   I have added a menu item with a keybord shortcut to run REBOL with 
   the currently shown file as argument.

   I have added also a menu item with a keybord shortcut to run my modified 
   version of REBOL-Word-Browser

 At the end of the r/s file I add these lines (mostly taken from Bruno 
 Anselme):
		#if OS = '???? [{
		REBOL []
		appname: "myprog"

  rs-dir: %../Red-master-0.3.2_Bruno/red-system                ; locate 
  here your red-system directory
		dest: rejoin [what-dir appname ]
		print [ "------ Compiling" appname "------" ]
		do/args rs-dir/rsc.r rejoin ["-o " dest " " dest %.reds ]

		print [ "Destination file:" dest ]
		call/wait/show/console dest
		halt
		;}]

 This way pressing the shortcut I can run REBOL that compiles the 
 program I am writing and than starts the program.
	Any suggestion is welcomed!

I use Textpad on Win7 for coding. As Textpad does not support Unicode, 
I also use Notepad++ for Red UTF-8 scripts. On Windows, I use PE 
Explorer for reviewing the disassembled code and IDA Pro for debugging 
it (hopefully, this happens rarely). I also use IDA Pro on Linux/IA-32 
and gdb everywhere else. On Mac, I try to use osxdebug, when it's 
not crashing.


I dream about the day when I'll be able to replace all those tools 
with a cross-platform Red[/System] IDE.

I should set up a keyboard shortcut for UltraEdit, but I've been 
focused more on Red Mezz lately, so just have a build script for 
the console, and then I paste things into the console to play. When 
I start doing more real Red compiled work, I will revisit Arnold's 
redcompiler script.

I had the idea of adding a button to it to compile the console and 
1 to launch the console and as such making it more of an IDE/toolbox. 

Pretty busy and going away for a short holiday, no computer.

I did a similar tool a long time ago, for encapping REBOL scripts. 
Maybe we can merge them. 

http://www.rebol.org/view-script.r?script=enlist.r&sid=ghz24nd

4) "It was announced last year that Unicode support was implemented 
in a week. What I found first is that Unicode support is useless, 
and now I've found that only ASCII is really supported." Unicode 
support has been implemented exactly as stated in (will get back 
to that point later):
http://www.red-lang.org/2012/09/plan-for-unicode-support.html

So, currently, only 7-bit ASCII is safe to input in the console. 
This limitation has nothing to do with Red implementation or the 
interpreter, it's a console input issue, so generalizing it to whole 
Red is inaccurate and unfair.

Anyway, as I stated many times, the current runtime lexer is a temporary 
implementation, waiting to be replaced by a proper Unicode lexer. 
It shouldn't have survived more than a few weeks, hopefully, it should 
be soon gone. We'll switch then the console to the Windows Unicode 
API to get rid of the codepages hell. In the meantime, I will correct 
the console banner.

Kaj, it seems to me that you were confused by a few things:
- console script banner wrong statement (my fault)

- internal "Latin-1" naming (like in Python's internals) which might 
be misleading (there's no other closer naming in Unicode for one 
byte representation AFAIK, though some people call it "UCS-1", maybe 
we should adopt that too).

- "Unicode support" seems to imply to you that *all* possible Unicode 
encodings have to be supported (with encoders/decoders). It doesn't, 
having just one encoding supporting the full Unicode range (like 
UCS-4) is enough for claiming "Unicode support".

I have showered Red with praise on many occasions. Why is it such 
a problem to have some criticism, too?

If dyn-lib is around the corner, let's better ask Doc, what is imediatelly 
next focus of implementation. IIRC, it should be objects, needed-by 
and followed by I/O. And if Doc says, that more Unicode stuff comes 
with I/O implementation, what timeframe are we talking about? 2-3 
months? Well, not sure how much you are kept stuck with such a timeframe, 
but maybe even you can wait?

There is as I read this a different issue. Dock want Red to be as 
complete as posible, Kaj wants it to officially useable. Kaj really 
needs UTF-8 (and or Latin-1) character support, for getting this, 
I guess this has to do with the Syllable operating system amongst 
others.

I would like Red to support time and random functions as natives 
and (Gregg is one of your mezz funcs REJOIN ? I want that too) be 
able to connect to a MySQL database so I can dump PHP for some webdevelopment.

Besdies that we all love to see a VID (like) solution for display 
and creating apps. 

We have to be patient agreed 100% amongst everybody? Where the roadmap 
mentions all things to progress Red, above things are not on that 
list. I want Red to have enough to make it useable in production 
and after that expand, imho that is the way to really attrackt more 
funding/enthousiast programmers and make sure current support does 
not fade/ loose interest.

rejoin: func [

 "Returns a new string (or same series type as block/1) made from 
 reduced values."
	block [block!]
	/local op
][
	either empty? block: reduce block [block] [
		op: either series? first block [:copy] [:form]
		append op first block next block
	]
]

Why is it such a problem to have some criticism, too?

 There is no problem with that, and believe me, you can't be more 
 critical on Red that I am myself. But I find it really unfair to 
 paint a bad picture of whole Red because some features that are planned 
 are not yet implemented. 


I can't go faster than the music, to get I/O done with required encoders/decoders, 
I need to setup the ports/devices infrastructure. To do that, I need 
objects support done. Also, as shown by my entries on Red Trello 
page, error! (and typeset!) support and getting a Unicode runtime 
lexer are even more prioritary to make Red "more usable for real-world 
apps". Moreover, when you manage a lot of tasks, some of them marked 
as "important" that keep been postponed because of other more urgent 
ones, will at some point become "urgent" themselves. That is what 
is happening with shared libs support, which is a blocker for getting 
Red on Android and iOS. I'll also probably make a Java bridge prototype 
this week before getting back on other Red features.

Almost forgot about the Trello page. Do you use that page as an interim 
planning for what is actually being worked on? If so, and once you 
have few minutes of spare time (I can imagine you don't :-), maybe 
one sentence reference on the Roadmap page would make it a nice addition:

You can find actual tasks we work on on the following Trello page

 .... it would make feel ppl more dynamic about the project, as Roadmap 
 page is rather static. OTOH we can watch Git commits, twitter, but 
 still if one needs to know, what is an actual priority, and as far 
 as Trello page is being updated, it would make some sense. E.g. "Download" 
 addtion was imo very nic simplification for those starting with Red 
 ...

btw - probably stupid question by me uneducated :-) Reading a Trello 
card, I can see task "Extend ELF emitter to support shared library 
generation" - does it mean linux is not supported? Or is ELF anything 
else, than Linux executables?

Don't want to bother you with primitive questions, but - why in general, 
there is a need for shared library support, on mobile platforms? 
Can we just have - executables? IIRC, R/S code already worked under 
Droid? Well, I know that .apk is some other format (maybe a zip file 
with some files inside?). Is it that in order to have PROPER app 
support (e.g. via GooglePlay), we need to adhere to some rules, and 
one of those is, we need dynamic libraries?

Doc, I keep repeating, I am not "painting a bad picture of whole 
Red", you make that up, blowing the issue out of proportion

I was genuinely disappointed by the lack of Unicode asymetry, and 
had good cause to expect it based on your publications. I made the 
best effort to gain insight into the situation and contribute a fix

I have been digging out this issue with Kaj privately, and it appears 
that several misunderstandings happened a few weeks ago setting up 
a chain of events that resulted in having an unpleasant (for us and 
others) exchange between me and Kaj in this channel.

Kaj raised 
an issue a few weeks ago and asked for information that I failed 
to give. This was my mistake and I'm sorry for that. We've dug out 
the root reasons for that and have set up better rules to avoid, 
as much as possible, such failure in the future. Kaj's dedication 
for Red is obvious to all, from day one, and I'm grateful to him 
for that.

Actually, after setting up this issue, we've come up with 
some interesting new plans and strategies for Red that we will unfold 
in the next weeks...so stay tuned. ;-)

Yay! Thanks for posting that Doc. I was having a hard time choosing 
which of you to keep as a friend.

As an aside, I needed a break last night, and looked at some Red 
mezz bits again. I realized that REMOVE-EACH was one of the missing 
natives I had written off for a while, assuming you would get to 
it. But I got impatient and wrote a quick mezz version. Fun stuff.

I was looking to take cover just in case a battle of the wizards 
was going to happen!  Glad to hear it has been avoided.

I used to be a Dragon-Wizard level 37 in CircleMUD back when Internet 
was mainly text-only, so this could have become nasty indeed. ;-)

Got a reply from Avira, they have processed my report and the fix 
should be soon available: 

https://analysis.avira.com/en/status?uniqueid=KwPWqW429CmT1fNpbHWQgDxQ8ryDHO4T&incidentid=1412216

Added new #call compilation directive to enable calling Red functions 
from Red/System.

Syntax:
    #call [<red-fun-name> <arg1> <arg2> ...]

Notes:
- it can be used only in routines body or #system body block.

- only function! value can be invoked (refinements not supported).

- arguments are either literal values or Red/System global/local 
variables.

- type casting (to a Red internal datatype) is allowed in arguments 
(avoids wasting an extra variable).

I think it is worth stressing that this is a feature of the Red compiler 
and is not available to Red/System programs compiled with the Red/System 
compiler.

The #call directive invokes a Red function, it has nothing to do 
with Rebol's CALL native.

R is a compiled Red app. RS and RS2 are compiled Red/System apps. 
From RS2, I can #call into R, but not RS, correct?

Because it invokes a Red function.

Ah, I see my confusion. I thought this was some tricky IPC thing, 
but it's just a callback def in Red, correct?

Petr, in the currently available code, the GTK binding can't function 
without a callback from Red/System into Red; as Doc says, to pass 
GTK events into the Red GUI dialect engine. So far I constructed 
the callback the ugly way, but there's official support now

I guess it is still deep voodoo, just a different kind. :-)

Actually, it's fairly simple, think about a GUI app that sends a 
click event to your Red/System binding, how do you pass the event 
to Red code if you can't call it from Red/System. ;-)

For a callback with two arguments

It just pushes the Red/System arguments on a new Red stack frame 
and invokes the Red function. No black magic required. ;)

Actually, it is related a bit, because in both cases, you are making 
an "external" call.

A Red/System logic! is stored as integer!, right, not byte!?

Refinements: these are a matter of cost vs added value. It costs 
significantly to add refinements support to routines and #call, and 
the added value is small. So, it is possible to add them, but it 
falls in the "nice to have" feature list, not "must to have", so 
they are very low priority.

Does Red attempt to answer Carl's old question of passing big options? 
Carl wrote a document on this once, but I can't find it.

Essentially it was the idea of doing something else, when a function 
grows to have too many refinements, as this is both not very user 
friendly and reduces performance.

There's also the special /options (IIRC) refinement in Topaz that 
allows use to pass a block with set-words/value for each arguments 
(including refinements). That should be also a solution to consider.

I've sometimes thought /WITH would be a good name for the arg block 
idea, though it would conflict with a few existing cases.

Thanks Peter. Could you please add a message like "Wish moved to 
v2 wish list on wiki" to each related tickets and close them?

A lot of that needs to go through Red/System, so it's hard setting 
priorities

Quite a few are youre Kaj :-)

Yes, but it's important to have them in a more structured form

Right, having a more formal specification like Python's PEP would 
be nice.

Pekr: it's for Red/System 2.0, so it's not a short-term task.

No rejected items yet, looking good! Point 5 and 17 both have a wish 
for a BREAK.

Having an array type is probably not as useful as you might think. 
The only real advantage I see is the ability to add optional bound-checking, 
which should protect from a whole class of errors.

Array syntax is a little more "average" programmer friendly than 
allocating memory and user pointers though :-)

But only just a little! :D


@Doc I guessed that! It looks other way for outsider(s) (undecided)

For other purposes arrays are not a replacement for pointers. But 
for the majority of small uses of arrays they take away the need 
for the administration overhead. It is handy and easy.

Is there a Red/System page that states its goals? e.g., Is Red/System 
meant to be bare bones, or do you see adding some higher level elements, 
like D. I ask because D has various array types, and didn't know 
if you planned to implment a few core elements at the lowest level, 
so they can be used in Red/System, and then just exposed to Red.

Red/System is supposed to remain small in order to be usable as a 
Red dialect for low-level programming. I don't have any plans to 
add higher-level features, because they will overlap or collide with 
Red's own features.

Re #7, while I understand the reasoning behind the op names, I prefer 
remove/append/take/insert. I'm OK with other terms, though REBOL's 
choices are nice. I used to write OO stuff with ops named based on 
the data structure, e.g. push/pop for stacks, but Bertrand Meyer's 
argument for Linnaean naming conventions swayed me a long time ago.

@arrayproposal: I really like the index to run from 1 to 10 and not 
from 0 to 9. I suspect this is because I happen to be a human-being 
not a computer. Maybe I could live with this different in Red (1 
- 10) and Red/System (0 - 9), because Red is higher level and Red/System 
being low level, but that might be confusing too.

I/O for Red/System is likely to be a library rather than in the language 
itself. If I remember correctly Kaj's C lib provides I/O support.

(Though I suspect that my initial wish is very much a "wish to far").

This really is a mega-wish list. It is very possible that adds far 
too much bulk to Red/System to be added in the language.


At least the list could be the basis for the spec for a Red/System 
lib to provide much of the functionality.

My first impressions on your proposition:


1) arr[i] is a useless syntactic addition as we already have indexed 
accesses: arr/i


2) #7 and #8 are going way too far from the Red/System application 
domain, it's basically  a series abstraction. Red internal API already 
provides series (the internal API is not yet completed nor formalized 
though), so this is both unneeded and overlapping with Red standard 
library.


What you might not realize is that you already have array-like capabilities 
with Red/System pointers (including structs and c-strings). If you 
want automatic memory management in Red/System, you won't have it, 
low-level programming requires a manual management of memory for 
accuracy and avoiding unnecessary burdens.


The only array-like part that Red/System is really missing right 
now is the literal array-like declarations, which can be achieved 
without a new formal array! type. As I said earlier, adding a array! 
type would only add bound-checking abilities (which is a nice feature 
to have) and provide you with #5 as a side-effect (not very useful 
anyway, as array would be fixed-size).

One of Red/System DSL goals is to be as close as possible to the 
hardware, not as far as possible. This implies that no arbitrary 
abstraction layers will be ever added to Red/System that can't be 
more or less directly mapped onto some hardware features. 


Exceptions exist when some targets do not provide a basic feature 
that others are providing. For example, ARMv5 family do not have 
integer division, nor modulo support, so I had to implement it manually 
in the ARM emitter in assembler:

https://github.com/dockimbel/Red/blob/master/red-system/targets/ARM.r#L372


Another one is the runtime exception system recently added (THROW) 
to Red/System, which also required a specific assembler routine:

https://github.com/dockimbel/Red/blob/master/red-system/targets/ARM.r#L2008

Thanks for the clarificaiton, it's helpful. I keep thinking of Red/System 
as a standalone langauge (because I like it so much).

Being able to do whatever C does without its outdated syntax and 
bloated toolchains is a dream coming true. ;-)

With the new shared library code, I have been able to compile a shared 
library on Linux for the first time

I can compile a Red/System extension with the R3 bridge and load 
it into R3. However, only two of the COMMAND examples work:

Andreas: thanks a lot for this new contribution! Now that shared 
lib generation support is unlocked for Linux, we'll be able to finally 
start working on the Android full support (amongs other new targets).

The main effect is that Red/System init code is not run when the 
shared lib is loaded, this affects floating point exceptions flags 
and runtime error catching routines. Not a problem for now.

@Peter I took the liberty of commenting the document here https://github.com/dockimbel/Red/wiki/Ideal-array-capabilities
We could add Nenad's comment on it too. 
It is a giant wishlist indeed :)

@Nenad, "Being able to do whatever C does without its outdated syntax 
and bloated toolchains is a dream coming true. ;-)" it is :)

Peter, you should add an "Author:" field in the wiki page header, 
so that it's not being misinterpreted as being a Red official page.

@Kaj do you have a url that takes me directly to these files?

You wanted a direct file link

It's a binary repository. The examples are in the source repositories

If you have time, a blog/tutorial on how this works would be great

I'll be setting up a website for them later

got a red example?

Did you run it from a terminal?

PRINT has been standard in REBOL languages for a decade and a half, 
and half a century in other software...

And in View brings up a console to print to

CGI is possible indeed. I did a small tutorial a while ago: http://arnoldvanhofwegen.com/blog/simple-red-cgi-scripting-possible/

Very much so and connecting it to my MySQL database as well! But 
that is not yet possible at this time. I do not see a use for a form 
if I cannot save information from it.

R2 has all these possibilities, on rebol.org are various examples 
of scripts. For Red we might train our patience muscle of finance 
Nenad in the 'right' direction.

This is a low-level interface suitable for Red/System. Red will have 
a higher-level abstraction layer for interacting with Java.

do/args %rsc.r "%bridge/java/JNIdemo.reds -o %bridge/java/JNIdemo" 
... there's a typo, should be %bridges/

Andreas, does it work on Linux for you? It seems there's a library 
path access issue there.

Hmm, the above classes don't run for me with a Java 6 JRE. So ignore 
them, if you don't have Java 7 already.

open a command prompt, change to the directory the .class is stored 
in, and run `java JNIdemo`

Get a "problematic frame" crash as well (Linux, 6.0_26-b03).

Will try on a 64-bit too...

I tried it on a 32b OS.

Andreas: reproduced a crash on Linux 32-bit with Java 1.6.0_27.

Found the cause of the error, will push a fix in a few minutes.

The window closing is generating a Java exception on OSX, I will 
improve the code to make a more JVM-friendly exit.

(checking if you're using a 64-bit VM)

hmm, now tried to delete .class files and regenerate, I obtained 
following:


Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\!rebol\!Red\Red\re

d-system\bridges\java\JNIdemo.dll: Can't load IA 32-bit .dll on a 
AMD 64-bit pla
tform

        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary1(Unknown Source)
        at java.lang.ClassLoader.loadLibrary0(Unknown Source)
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at JNIdemo.<clinit>(JNIdemo.java:9)

Yes: Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\!rebol\!Red\Red\re

d-system\bridges\java\JNIdemo.dll: Can't load IA 32-bit .dll on a 
AMD 64-bit pla
tform

Pekr, I'm afraid you'll need to install a 32-bit JVM to make it work 
with Red.

Looks like -d32 option is working on OSX only, so a 32-bit JVM is 
required on other platforms.

(My .class files where generated on a 64-bit machine, but that does 
not matter.)