World: r3wp

Not with the term. Cleaning up R3's modularity is the next thing 
on the todo list, and I will backport it to R2-Forward as much as 
possible. Most of the hard work of the backport has been done already 
by Gabriele in his %module.r. By the way, if you don't use R2-Forward 
as a module, a lot more code doesn't work. The new words are just 
exported from it when loaded as a module - they redefine the global 
words when you just DO it. Those changes to global words can break 
other parts of R2 in unknown ways. If you just import the module, 
only the words in your script are redefined, so only your script 
has to be made compatible.

I'll keep that in mind

This is how I use R2-Forward safely at Qtask without changing the 
rest of the codebase, for instance.

here's an outline of what OSGi is from the horse's mouth, if you 
care to look - http://www.osgi.org/About/WhatIsOSGiand some of the 
benefits - http://www.osgi.org/About/WhyOSGi. I'll try to explain 
where I see REBOL taking advantage of this.

essentially, OSGi is all about modularity and dynamic services

by specifying very clearly the dependencies among modules, different 
versions of the same code can run in the same runtime

pretty much all of the big names in the application server space 
are moving or have moved over to this architecture for their own 
implementation and some are exposing OSGi as an environment in which 
the user applications can run in

what OSGi is or is becoming is a similar environment as IOS, if I 
recall some of the details. With distributed OSGi, the services that 
make up an application can be located anywhere

here is where I think REBOL apps/modules could fit in - if there 
was some sort of binding to an OSGi runtime available

First of all, this is not the place to discuss such things if you 
want them acted on. AltME is too ephemeral, and some of the core 
people don't come here that often, and most of the core people haven't 
been on the mailing list in years.


Post those links in R3 chat. The modularity stuff can go in R3/Language/Modules 
(2165) and the services stuff in Tools/Reb-Services (54). Keep in 
mind that the vast majority of a Java spec like that is dedicated 
to making Java suck less, so the REBOL version will likely be mch 
simpler.

If you want it all together, post it in Tools/Reb-Services. We already 
have a good handle on the module system, even if it's not done yet.

I will move this over to those areas, but I just want to say that 
my whole point here is that REBOL very easily could be a supplier 
of services (and possibly a consumer, though less likely) to applications 
built on OSGi - the fact is that the Java enterprise area is huge 
and getting a foothold in there would really open a lot of eyes to 
what REBOL can bring - a total shift to REBOL, of course :-)

Well, the place for that is Reb-Services. At this point we are focused 
on the Modules and below layers.

it probably wasn't clear from what I was saying that I'm not expecting 
others to work on this area  - rather, I'd like to contribute, if 
possible, but I would want to discuss some of the implications with 
some of the experts to see if anything needs to be kept in mind while 
finishing up R3 so that REBOL can play nicely with Java

anyhow, I got that this is not the place

It does sound interesting. I look forward to the discussions in Reb-Services 
:)

Integrating Reb-Services with web services, .NET Remoting and DBUS 
would be interesting too.

Personally I´m aiming for Syllable messages

integrating reb-services with liquid's internal messaging would be 
fun too   :-)

(and pretty easy methings)

**methinks**

Is it possible to work with images somehow if load doesnt work for 
.jpg yet?

IE exists some other way?

I think you can load an image into R2, mold/all save it as an image! 
and load it into R3 that way.

THX Henrik

I really like new march plan - finally some low level Core stuff 
- rebin, plugins!

yes, looks good

It says no ReBin yet

Yes, no rebin yet, but that it is planned for march, because of low 
dependenices, and because it is needed for host code to be released 
.... ?

I just visited AGG newsgroup after one year, and some interesting 
projects do emerge. Community agreed that any open work will be done 
to BSD version (2.4), which is a good sign (although RT has probably 
no problem obtaining special license).


Dunno why, but there are (apart from Cyphre) another few Czecho-Slovak 
guys, and one of them is doing rather interesting project. AsmJIT 
and BlitJIT libraries, with MIT licence. Author says about it:


Antigrain is great piece of software with great licence, 
but without 
better acceleration it's quite slow.  So blitjit can increase speed 
of 
your applications in way you can't imagine. For example is there
complete 
MMX/SSE2 extension for antigrain ? No, but don't panic, other
libraries 
also have problems with cpu specific features.


The reason why it might be interesting is, that generally there is 
no good 2D HW acceleration out there, and here is what author of 
LibNUI answered to Cyphre:


I'm the author or nui (http://libnui.net) which is a GUI toolkit 
based  
on OpenGL (and now OpenGL ES / Direct3D). This project was 
started  
some 8 or 9 years ago and I've been working on it and with 
it amlist  
daily for that time. My experience is that it's some 
orders of  
magnitude harder to have HW support for those features 
that to add a  
JIT to your engine in order to optimize your bottlenecks 
(I've done  
some of that for pro audio dsp code). The reason is 
that no two chips  
work exactly the same and behaviour even tend 
to change over driver  
releases. To diferent cards, even sometimes 
from diferent vendors,  
will not give you the exact same scan convertion 
or rasterizing, and  
I'm not even touching shaders diferences...


It seems to be x86 only so far, but maybe guys like Cyphre or BrianH 
or Anton or anyone skilled in those areas should keep an eye on those 
guys :-) Here's a link:

http://code.google.com/p/blitjit/

... as for those another AGG based Czech and Slovak projects:
http://www.rw-designer.com/
http://www.crossgl.com/

Shouldn't we get those guys hooked to REBOL? :-)

Can someone see the private message from Ernst on RebDev? He posted 
to admin question why he has so low rank, but I could see the message 
and reply to it.

I don't see it. which number does it have?

it seems the rank of 10 is standard for new users.

Petr, cool links. Yes, I think we should get them into Rebol.

Henrik - 2756, 2757

eh, first one is 2755

I don't see 2755 and 2757.

how do I post private message to Carl?

pp carl

hmm, private messages are folder dependant? What is difference in 
pp vs pu?

they should not be folder dependent.

I had not noticed the 'pu command, but I guess it would be a public 
message stored in the folder for the user.

Hmm, then message is  misledading? I do pp Carl, and the header states: 
"posting private message in #thread-number-here ..."

ok, what if you try 'pu carl?

Enter private message in #8

ok, then pu is for private messages in his folder, while pp is for 
private messages in the current folder.

makes sense ...

Henrik - as there is not much comfort in RebDev chat - not using 
other gob types contradics their purpose, no? I do understand, why 
keeping GUI desing simpler might have advantages, but stating that 
effects are not needed so far, because Draw dialect can serve us 
well for GUI purposes, might also mean, that we could discard effect 
pipeline? :-)

No, it just means that I have not needed effects yet. I think they 
should definitely be possible, but we have to be careful not overexposing 
it. MAKE-GOB could introduce a level of control that we don't want 
in a style, making a single style a big mess with hundreds of lines 
of code, because you have to reference GOBs.

So far GOB management happens in 20-30 lines of code in one specific 
place in the R3 GUI design. It's very tight and controlled and by 
adding an effects GOB there, would make sense in the R3 GUI design.

Maybe it would be best to add 'effect and 'rich-text functionality 
to draw directly, as image is there too anyway. Would make it for 
one combined pipeline. Dunno how it would make low-level implementation 
more complex. Then we could discard other gob types ....