World: r4wp

If you bind to LibJPEG directly, you'll have to devise your own internal 
format once you add support for another image type

@Kaj: I'm trying to get the JPG data without having X11 installed. 
 If I were to do something with LibJPEG directly, I would try to 
make it look like the R3 image! datatype.

Are you sure GDK has a dependency on X?

Looks like it

I was pretty sure GDK required X.

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

You could compile GDK on DirectFB instead of X, but it would be a 
lot of work

You could make a binding with SDL-Image to have fewer dependencies

A binding with DirectFB or Enlightenment just for the images would 
also be less massive

Thanks for those ideas, Kaj!  I'm thinking it may be better just 
to wrap libjpeg.

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.

Sometimes, I'm such a dunce!  Something Kaj said in the past hit 
me as I lay awake in bed at 4:45am this morning.  IIRC, he said that 
Red/System could be used to extend R3.  My problem is that I need 
to perform some advanced processing on jpg images.  I wanted to do 
this natively in Red/System, but had issues getting the jpgs loaded 
into bitmap form.  R3 can already load jpgs into bitmap form, so 
why not  call a Red/System compiled executable to do the processing?

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!

If that's your purpose, then yes, that would be a nice combo

Just this week I checked that the Red-R3 bridge works with the updated 
dyn-lib-emitter branch of Red

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

That will be a problem.  Maybe I'll have to pass the data using slower 
semaphores.

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.

Exciting!

That's great Doc!

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

I've never really looked into 0MQ, but I know you did some binding 
work with that.

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.

time is up now sorry.

I'm happy to report that Red works well on stock Windows 2000

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

Perhaps it could be helped by installing newer versions of the Windows 
C library

Arnold: finding good ideas for new revenue streams to fund Red would 
be indeed helpful.

Kaj: interesting finding, but no that surprizing as the interfacing 
of Red with Windows API is currently quite limited.

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

The 0MQ issue may be with newer bulids. I used old versions on XP 
just fine.

Not from Red of course.

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

R2-level cross-platform console for Red
 would be great!! Thanks Doc!

Nice addition indeed. That will differ it from R3 too ....

Thanks for the report, Gregg. It could also be that this XP machine 
doesn't have networking. Perhaps Windows doesn't understand that 
it can use localhost

That's a massive patch, Fork

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.

It is my hope that the R2 legacy can be shed, but clearly it is not 
the time today...maybe a couple of months.  R3 patches must be taken 
in a timely manner. The current situation is untenable, so we are 
going to have to agree on a development branch.

Well, it's not the largest code base. Most active, I don't know

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.