AltME groups: search

I like to put the function description on the same line as the function 
name, so it's easy to scan through a program text for them. Having 
the attributes in front of it makes the line too long and hides the 
atrributes in the text

François showed me a few nice demos done with that binding a couple 
of weeks ago when I visited him in Paris. He had some camera-controlling 
and image recognition demos done from Red(/System).

Any chance he'd be willing to share his Red/System code?  I want 
to do something similar, and it would be great if I could see working 
examples!

Added OpenCV to contributions page, François sent me the link for 
the latest version and says that it can be now used in production.

http://www.wuala.com/fjouen/Code/OpenCV/Red/

Leap device: huge potential, C++ drivers (!), only simple demos and 
basic testing tools available currently.

I wonder, what is inside. What exactly measures your fingers in the 
space? It is not camera based, is it? So what kind of sensor does 
it have, and how is that they are so precise? I do own Kinect, but 
it is far from being so precise ...

(Add a 3D API, and maybe Red could find a market in gaming)

Doc - would it work from behind the glass? I mean - in front of Windows, 
projecting image on the window (with some foils like Vikuiti from 
3M). Because the guy at the video has it laying on table. And you 
also said, that it does not work, if you point your fingers up or 
down, which might mean - towards the device?

Adding support for cutting edge hardware, and things like VOIP and 
Videoconferencing - anything that tends to be hard to accomplish 
using other development tools, would really help to set Red ahead 
of others, make it look fantastic, and give new developers concrete 
reasons to WANT to use it.

(Same reasons many of us were initially attracted to using VID and 
other REBOL features that made it so practical).

No one will be impressed with normal GUI, email, database capabilities, 
even if it's 10x more productive, but anything multimedia, video, 
3D, etc. which demonstrates "modern" capabilities, and beats other 
solutions, works on mobile, etc., then they're much more likely to 
go "hmmm".

NickA: there are many domains where Red could shine, actually finding 
the right one, which fits the best, is the hard part. Supporting 
new and innovative hardware is surely a good thing to have anyway.

Preliminary path! and set-path! support added to Red interpreter.

https://github.com/dockimbel/Red/commit/53f87ff81822e81c5ddf56245e68f8e6255c698b


Works only on series! so far, function calls with refinements are 
next on the todo-list.

I'm happy to report that passing functions by reference works, and 
that they can take parameters if you invoke them with the interpreter:

The interpreter is able to detect if a function has been compiled 
to native code and run the native code version, so in the above case, 
the interpreter overhead is very small, and a JIT-ed version wouldn't 
run noticeable faster. The real place where the JIT-compiler will 
make a big difference is for functions created at runtime, that would 
otherwise need to be interpreted.

If you write a script for the interpreter, and it contains function 
references with arguments, it would run in the interpreter, but not 
in the compiler

Actually, we could just make the compiler recognize such case and 
generate a call to the interpreter without you having to specify 
DO. The drawback would be that all subsequent values in that block 
level, would be passed to the interpreter too, as the compiler can't 
determine the expression boundaries. I'm not very fond of such option, 
but it is a possibility.

Actually, this is supposed to be the compiler fallback strategy for 
cases that are not statically solvable. I haven't needed it so far, 
and I'll try to push the compiler as far as possible before implementing 
it.

Just in case Red followers haven't noticed, we now have REDUCE and 
COMPOSE fully implemented in Red (both in compiler and interpreter).

@Pekr: That's one of the things that attracted me to Rebol.  I didn't 
like to have to specify every library file that I wanted to link 
to and have all these dependencies...just one package with everything 
in it.

Or at least like the Rebol SDK where you can easily include the major 
components you want, and the granularity to remove ones you don't 
want, like the View subset.

Any framework that supports more than one image format will have 
its own internal format. That goes for R2, SDL, GDK, ImageMagick 
and any other framework you could bind to

Yeah, I checked and I'm not sure, but it's very entangled

I don't have a lot of experience with C and library bindings, but 
I've done a bit and I can give it a shot when I have a bit of time.

Thanks so much, Doc, for making R3 easy to extend using a Rebol-like 
compiled language!
Thanks so much, Kaj, for your insight and foresight!

There are still various bugs in R3, though. You seem to need the 
latest build from Andreas, and R3 corrupts tuples passed across the 
bridge

On the other hand, weren't you doing this on Raspberry Pi? The Red 
dyn-lib-emitter branch and thus the bridge are currently only available 
for Windows

Function building and evaluation now supported by the interpreter. 
Here's how it looks like from the Red console:

red>> foo: func [a b][a * b]
== func [a b][a * b]
red>> foo 3 4
== 12

The interpreter (DO) is much more capable than the current console 
with its currently limited tokenizer (LOAD). So, e.g., the interpreter 
fully supports paths and refinements while the console don't.

Nobody has proposed me so far to build a R2-level cross-platform 
console for Red, so I will implement one in the next weeks. Before 
that, I will probably work on PIC support for Mach-O and ELF and 
implement object! support.

Bo, you could use the 0MQ bindings to pass the images between Red 
and R3

Sorry Doc, it is hard to get-and-keep up to what you all achieve!! 
(And Kaj too) Even though I myself have less hours at my job I do 
not have as much time to follow it all. (More projects and chores 
in and about the house to do now and less 'spare' time at work for 
a quick review.

I will try to answer the question of how I see possibilities to make 
Red more suitable for funding. And have it get the attention a first 
proper release needs. Everybody else is hereby invited to think along 
how to make this possible.

What I see as a first possible step is have a kind of Red website 
hosting where websites can be hosted using Red (cheyenne server) 
and a database behind it (MySQL or SQLite) and a possibility for 
digital payments (such a module could be additionally payed and kept 
'closed' source). This could obviously generate a modest cashflow.
There would be needed books etc.

Even most of the bindings work, except GTK and 0MQ, because their 
libraries are not compatible with 2000

I need that setup to test, and I may need it to compile binding libraries 
myself

0MQ also doesn't work on XP, so that's more surprising and problematic

Beating the test suite alone is perhaps an unwise quest, so here 
is an as-is state of the Red port for people to tinker with and look 
at.  https://github.com/dockimbel/Red/pull/421

It's impressive and depressing at the same time, because there are 
so many differences between R2 and R3. My CMS was much less work 
to port because I wrote it in very basic REBOL specifically to avoid 
these problems

Thanks, yes, impressive and depressing about sums it up.  :-)

The most annoying parts of course being when obscure bugs in Rebol 
itself lead you on wild goose chases, but that's one of the reasons 
why I think that the largest and most actively developed codebase 
written in Rebol should be stressing R3, not R2, which is dead.

The most optimal path is to shed the legacy of R3, as well, and bootstrap 
straight into Red

Kaj, sometimes an interpreted language is optimal, and other times 
a compiled language is.  I hope both R3 and Red will become fully 
functional released software.

If Rebol were not open source and if there were not Rebol-focused 
designers such as BrianH/etc I would be very much on the "bootstrap 
ASAP and escape this ecology" point of view.

But I think that what we must realize is that Rebol and Red are essentially 
occupying a mostly similar design space, where the design choices 
getting hammered out, correct, and consistent are more important 
than performance...and will be for a while longer.

To me this lends a prioritization balance such that what's good for 
Rebol 3 is good for Red, and bootstrap should be delayed until those 
issues have been solved intelligently and in a way that converges 
the two.

At first Rebol's boring and (to my taste) "shooting from the hip" 
C source code, a relic of another era, got me down a little.  But 
it's very clear.  The boringness is an asset, it plays well with 
others...

Red is going to freak a lot of people out, despite being open source. 
 Having both options gives more growth potential, and the easier 
it is to walk between them the more strength the whole ecology will 
have.

@Fork: Precisely why Carl chose to use C...cross platform compatibility 
and clean coding.  As far as code goes, I'd much prefer "boring" 
to "messy" or "complicated".

Bo, it's done in Red/System. The big advantage is that it has a very 
simple and portable tool-chain, much smaller than C.

What is Red being developed in?


Red compiler is written in R2, the interpreter and whole runtime 
library is written in Red/System.

@DocKimbel, I keep going to red-lang.org to download Red and Red/System, 
but then I remember it isn't there.  Is there any way you could put 
a link on red-lang.org to the binaries?

Maybe along the top, have a "Download" tab where the other tabs are, 
and everything needed to know about downloading it could be there.

Bo: there's no "binaries" (yet) for Red and Red/System, you need 
to go on github and download the sources (using the method that suits 
you the most).

I think that initially, one more section in menu - downloads, would 
do it. Or even simpler - I would rename the Contribution menu item 
to Downloads, and there I would put link to latest github archive, 
plus section below named Contribution ...

here's how you get started

 page" is Github Red page. There you have links for downloading an 
 archive or cloning the repo and all step-by-step instructions to 
 get you started.

Red is certainly not ready for prime time now. What we need now is 
testers and contributors. So just putting a link to source archive 
in a Download section wouldn't help much, as users would have no 
clue what to do with it. Again, there's a "Fork me on Github" button 
on top of all pages on red-lang.org. If users have no clue what Github 
is, then they are probably not ready for contributing. I will add 
a Download section once we have binaries for Red compiler (encapped 
versions of R2 compiler for now).


Once Red gets ready (documented and in beta state), I will open a 
new site that will be fully user-oriented (in contrary to the current 
one which is followers/contributors oriented).


About Red/System: it is meant to be a dialect embedded in Red, however, 
its intrinsic value seems to be high and will be higher as we add 
more feature and optimize it. Maybe it could be a good selling point 
for making some low-level programmers come to Red.  As Red/System 
is much more mature than Red, maybe I should think about opening 
soon a dedicated web site for it (would still need a binary version 
of the compiler)... What do you think?

I think there is value in Red/System outside of Red. Think of the 
primary examples people might use it for, where C might be the first 
choice, and provide examples of what they look like in Red/System. 
I know CGIs are mostly done in high level langs now, but I would 
certainly include one as an example. Implement some performance intensive 
algorithms to show what RedS looks like, compare to C. Or apps that 
need to be small and fast. e.g. a 0MQ broker.

If users have no clue what Github is, then they are probably not 
ready for contributing.

 - Doc, that is so much off ... It is not imo about users contributing. 
 It is about various possible future Red users, who just found out 
 about Red, and want to have their first touch with the language, 
 no matter how complete the language is imo. Ppl's will to give it 
 a try should not be prevented by crappy overcomplicated things like 
 Git imo.

Is that really so much of a problem, to add link to latest zip archive, 
with just one sentence, that it points to kind of "nighty" pre alfa 
builds? Or do you really find R/S and Red not being worth giving 
a try even in an early phase of development?

Git was not designed for humans, AFAICT. It was designed to let loose, 
informal teams manage huge open source projects. Now it has become 
the default hammer, and every software project a nail. I don't mean 
git is bad in any way, and it is successful for a reason. It has 
become friendly enough that a lot of people can use it, but I still 
see notes about how most people don't know how to use it effectively. 


I imagine you could build a great, human-friendly wrapper over git, 
providing 90% of the power with 10% of the effort. It would take 
a git expert and a good designer, but maybe not too much time.

My hope is that people who want a specific platform, and have experience 
on it, would port it because that's what they need. Otherwise we're 
going to overload Doc. :-)

Pekr: Agreed...that was my initial suggestion.  My further suggestion 
is to have instructions right after those links stating how to get 
started with Red/System and also Red.  A simple step-by-step for 
beginners.

True, but it takes too much searching to find.  red-lang.org is the 
place I would expect to go to download the language, and it would 
be super nice if the instructions were right there as well.  If that 
doesn't work, the second best would be a link to the instructions.

that for normal user, in order to just give some tool a try, such 
user should use systems like Fossil or Git?


That's precisely my point, it's not ready yet for "normal users". 
That's what I mean with not ready for prime time.


I really don't  want to have to maintain two copies of the same instruction 
page on both red-lang.org and github site, just because of people 
passing by and not curious enough to click on the very visible "Fork 
me on github" red banner.

I think, that there is many potential supporters out there, who would 
welcome - You can download very experimental version of Red and Red/System 
to test here ....

I obviously, work as a Windows debugger using most of the core Windows 
Debugging tools and Systems Internals so I could contribute along 
those lines until I get knowledge of RED.

It's best to use the MSDOS folder. The Windows folder is less complete 
and compiled as GUI apps, so no command line output

Ok, lot of stuff there. So let me explain how I typically operate 
to make this the easiest way for me to help.  I need ONLY the relevant 
files to install, complete with same instrucitons for installation 
that produced the error.  I need to know specific versions as well. 
 Once I know I can re-create the problem, then I need sources (at 
least any programming sources you have) and any symbol files you 
may have or can generate (pdb) files preferred.

I don't have any older XP in the house so I may have to do it in 
the lab at work or install it via as a VM and see if it reproduces.

Yeah, I spend the days debugging control systems and lots of third 
party stuff.

We talking ARM, and Intel?

Currently we support IA-32 (Pentium 1 being the lowest CPU supported) 
and ARMv5.

In the future, we will target also higher version of ARM, Thumb ARM 
mode, and IA-64.

Put it in a folder with a Fossil executable and just run the script 
with REBOL

If you already had REBOL installed, you can always click on .r files 
and they will be started with REBOL

I'll take a look at what I got so far and figure somethings out and 
setup my testing environment.

Kaj in !RebolBot: "I think that only works in Red, refinements starting 
with a number :-)"


Refinements that start with a number work in R2 and R3 as well. Path 
elements aren't refinements though, they're regular words or other 
values. If you find any basic data syntax differences between Red 
and R3 in datatypes that they have in common, report them: they're 
either a bug in R3 or in Red, or possibly in both.

I didn't test it, but not all differences between Red and R3 are 
bugs

Did a quick profile of play-sdl-wav.exe sample.wav into dependancy 
walker and ran it and can hear the sample play.  It doesnt' play 
however when invoked directly from the command line.

Yes, even though drag and drop should be the same as starting with 
a command line parameter

I didn't test it, but not all differences between Red and R3 are 
bugs

 - where they are in comparable datatypes, they are. Syntax compatibility 
 in the the compatible datatypes is a necessary feature. If they aren't 
 compatible, it's a bug. The only question is whether it's a Red bug 
 or a R3 bug. It could be either.

If they have the same name and server the same role, they are.

For non-comparable datatypes it's not a bug, of course. And semantic 
differences may not be bugs either.

But syntax incompatibility for the same datatypes is a bug. The only 
question is which language needs to change to make it compatible. 
I am not going to constrain Red to match what R3 can do now when 
R3 can change too. They are related languages. Arbitrary incompatibilities 
that aren't related to the differences in semantic models are bugs. 
Of course this is all keeping in mind that LOAD is just a function, 
but that doesn't make arbitrary incompatibilities a good idea. They 
are in the same syntax family. If it's a good idea to do for Red, 
it's a good idea to do for R3 as well. And if it's not a good idea 
to do for R3, then it is likely also not a good idea to do for Red 
for the same reasons. And maybe there is a better idea for both.

It is likely that there will be whole datatypes that are appropriate 
in one and not the other, but I expect many of those to eventually 
cross-propagate in a lot of cases because their system models aren't 
really that different, just their implementation models. Certainly 
I would expect datatypes with literal non-constriction syntax to 
cross-propagate eventually, and those are the only ones where syntax 
compatibility would be something we would even consider to be an 
important factor.

Tell that to Boron and World

Incompatibility is the whole point to Boron and World, and that is 
why they will eventually fail. I want to make Red and Rebol succeed. 
They have the best chance to succeed by cooperating. No merger necessary, 
just cooperation.

Looks like we need to find some simple but efficient online collaboration 
tool to better keep track and organize all the common sub-tasks between 
R3 and Red that keep poping up these days.

I have that bookmarked, but haven't yet looked it over thoroughly. 
I noticed that the last time I tried to determine R3 syntax the effort 
generated a lot of bug tickets. The same would likely happen once 
I get a chance to go over Red syntax, and they may end up being a 
lot of the same bugs. Some syntax issues are an inevitible result 
of being in the same syntactic family, and not realy arbitrary when 
you consider the balance of the entire syntax.

And I was the one who filed the bug report :(

Boron may fail because people just don't seem to be interested in 
it and World already failed because it's closed soirce.

Doc, the Brackets editor is using Trello for the online task tracking/collaboration. 
Looks pretty cool and doesn't cost.
https://trello.com/board/brackets/4f90a6d98f77505d7940ce88

World's value slot size is 256 bits, which only makes sense for big 
data, not for mobile platforms like iOS. Its semantic model is basically 
that of R3 (plus all of the changes that he had requested R3 make 
that were rejected), and that semantic model is not really compatible 
with the iOS App Store review process. So I'm not surprised to see 
him not use World for iOS - its target market is completely different.

Boron is meant to be used by a lot of people, hence the copyleft 
license and actually being released.

I must confess that I have one very big and irrational problem with 
Boron. It has same name as one extremly stupid Czech heavy metal 
band. I just cannot work with it, even if it may be great language.

I met them on one festival where we were playing together and from 
that day I just can't stand Boron.

Having only been exposed (mentally, not physically) to the element 
Boron, I have no prejudice against it's name. And I have a coffee 
cup with an orca on it :)

I know it's pretty stupid but I can't help myself :) That's why I 
was very glad for Red(/System). That and BSD vs. GPL.

That's why I said that incompatibility with R3 was part of the point 
to World. He went out of his way to talk about the deliberately incompatible 
features. The only thing left to distinguish it semantically from 
being something in the same category as R2, R3 and Boron was the 
256-bit value slots. Otherwise it was pretty much the same language 
model.