World: r3wp

There is no definition of what constitutes a R3 beta

Nevertheless, I do not doubt Pekr will be proven wrong.

...even without a definition

Pekr, what part of "optional" means "non-standard"? It just means 
that it isn't loaded and taking up resources if you don't need it.

It's a plus for a lot of platforms to be able to build on a minimal 
base. For instance, I would have loved /Base on WinCE.

Everyone has different needs. I defined "my" needs for R3 beta in 
related document (wiki). The only thing I meant is, that I regard 
tasking/ipc being last "big" missing component. I have no problem 
being corrected or proven wrong ...

Is it that hard for you to realize, that your needs do not define 
what is R3 beta?

in must act on pekr's defence here.    his is just summarizing years 
of user expectations.

part of why pekr keeps insisting is that if you just look at the 
many changes the Extension/host kit has undergone since its first 
release, it can be expected that tasks will have as much side-effects 
in its own way.

modules, callbacks, memory leaks in the GC, memory exceptions, IPC 
and API for inter-thread data shareing, the potential list is long.

R3 is currently undergoing open-heart surgery, with Carl deep in 
system and architecture mode... with all of the stuff fresh in his 
mind.


I think its the perfect time to overhaul the task! system and finally 
make a real architecture/API and identify,  solve,  or decide on 
the potential issues "hard issues".

what is "years of user expectations"? if you speak for you and Pekr 
saying, that R3 beta is what "your needs" are, then you are patently 
wrong, no matter you are two now

I am talking about 15 years of use of REBOL by the whole community.

its always been a thorn in the side of the language.  if you don't 
need multi-threading, then cool... but I've lost contracts just because 
of this.

this is not a discussion about to beta or not to beta.   if we go 
to beta ... yay.. then in 6 months- a year... a design change required 
by tasks, forces Carl to either do a half-assed solution or go back 
to breaking R3.  what's the point of even going to beta.

Please be so kind and do not speak for me ("whole REBOL community")

Lad... why are you irritated about the need to address the task! 
issue?

do you think labeling "beta" on REBOL will change something?

But we each have different things that are important to us. I might 
say that robust and professional integration with SQL server is key 
as I know that's stopped a number of people from using REBOL in their 
companies. I could use that as a selling point, but I don't want 
to use SQL Server myself. :-)


Other things are more important to me, but only Carl knows what he 
thinks is important for him and for REBOL.

if the task! datatype is to be part of R3... which it currently is... 
and is laden with bugs, many unknowns and limitations... either we 
rip out the concept of tasking in R3 and limit the language's appeal 
or we fix the datatype and its api.

Gregg the difference is that Tasks operate at the core level and 
imply possible GC hacks, inter extension mem management, hard to 
track stack stuff...


all things which inherently *might* force changes in core level apis 
like devices, extensions, etc.

adding support for libraries, that is effectively something that 
uses the core... not defines it.


adding a standard SQL connector in REBOL would be sweet, but it won't 
change the core... its using it.

Guys, the thing is pretty simple.

I can't speak for Ladislav, but where I disagree about limiting the 
language's appeal is that we don't know who it's supposed to appeal 
to. It may not be you, me, and Petr at all.

There are zillions of things we want to see. Ok, and everyone wants 
something different.

We don't need a R3, that is in development mode until dawn before 
we can make use of it.

Hence, we are working on getting incremental steps done, that are 
useful. Maybe not for everyone but a lot can be done with R3 now.

And we will keep the high pace of new releases. Each one delivering 
more stuff.

Maybe something breaks existing code than. Yes, not to nice and takes 
some work but it's not killing us.

While R3 moves forward, we will use it for all our projects. Add, 
what's missing on the way and move forward.

In this stream tasks will come. I just don't know yet, if next week, 
month or in 6 months at the moment.

But Carl has put it onto the roadmap, so it's already in the near 
range radar.

But tasks is not just about "want".... its about something that has 
the *potential* (we don't know) to break other R3 components down 
the road.


so My point is not that I want it now.... I just want R3 to stay 
"freed from locking" until tasks are revised by carl.

The message that's important to all (including Lad here ;-)) is that 
R3 is useable for quite some stuff and should be used. Maybe not 
for everything yet. But you can start to use it today.

I agree... its very nice already.  I will be looking into the A 105 
release next week.

If tasks break things, yeah, than that's how it is. I take the risk, 
we adopt our code once and that's it.

I'm not afraid of it. I know that I take a high risk here to break 
some code.

And if a good task implementation takes 6 months... than it takes 
6 months and is of good quality than.

one question for you Robert... is the A105 view/agg code stabilized 
wrt what I was reading for A104?

What part do you mean with stabilized?

low-level use of AGG... not the R3GUI

A105 is the first one to integrate our AGG code line. So, bringing 
Carls work and our work much more in sync with less hassels for new 
releases.

I think with A105 the AGG externalization is done. There are some 
quirks left, to be fixed. But we can now do this on our own.

And yes, it's stable WRT AGG. I don't expect major architecture changes.

ok, that's what I meant...  thanks.  I'll probably be delving more 
deeply into the whole graphics structure next week.

the only thing I have been wondering is how the gob type interfaces 
with the AGG... isn't gob! part of the core?

for example, could I build a gob! which uses another rendering package?

I'm not yet an expert, but I think that the GOB! get's converted 
to the AGG world. Hence, you can take the GOB! from Rebol and however 
you bring it on screen, just do it.

ok I'll try to figure out the Architecture from the code (its a pretty 
big codebase... a bit daunting, I admit)

the codebase is really rather small. src/os/, the hostkit "core", 
has ~9k lines (wc -l).