World: r3wp

it's not easy to do stress testing, due to a specific bug not yet 
fixed by Carl, which prevents the creation of complex layouts without 
crashes.

Has Carl promised to fix it?

he has not responded on the bug at all.

Must be very frustrating ... and dangerous to base a business on 
such a situation

Saphirion's main app is built in R2, and is a very large project, 
so the issue is currently "just" frustrating. Some R3 apps are being 
built, though.

do you have any such issues as i experience?

no, the app we build has about 12-15 windows, and we are using a 
different branch of RebGUI with our own fixes.

You wouldn't see issues with so few windows

if you have that many, it's probably a good idea to build each screen 
on the fly, rather than keeping them all in memory.

most of them are ...

do you destroy one when leaving it?

just close them ... and let rebol do GC on them

You may try to put each windows into separate objects to make all 
the set-words are local. Then set them none manually when the window 
closed then call recycle. This may work?

the problem is that i may not see any benefit until I swtich a few 
100 windows across

jsut a short update: We build our first real-life R3-GUI based tool. 
It's a little thing but needed in a lot of companies. It's a tool 
you can interactively create things like heat-maps with. Heat-maps 
for how your IT system landscape looks like, organizational things 
etc. It's a nested layout created with color-mapping for visualization.

robert, can you post a screenshot from a sample headmap?

nested layout means you are arranging small gobs as grid and color 
them or is it a pixelbased image created on the fly?

We will, screenshot mode not yet working. It's a nested container 
structure and each container either layouts left-right or top-down 
in 1,2,3, ... lines / rows.

It generates pictures like this: http://www.mindtree.com/node/657

ahh, ok grid/cell approach. how many containers in avarage do you 
create for a big headmap?
running fluent?

ok, organigram... thought something like this -> http://www.mathworks.com/matlabcentral/fx_files/24253/1/heatmap.png

The number of levels depend on the stuff you want to visualize. IMO 
for quite complex real-life situations you have about 7 levels.

Than you can color, vary line thick-ness etc. to indicate different 
information.

looking for solution to create a very fine grained heapmap (500X100) 
elements. the only solution for this resolution I have tested is 
pixelbased so far.

a gob apprach would have many advantages but think it's will overload 
R3.

Screenshot of the UI? Your last Twitter message towards the gui was 
related to creating new skin? I expect it was not high priority on 
your list though?

It'll be a while, before I'm available to do any skinning work.

well, skinning work is also dependant upon material systsem, etc., 
which was not done, last time I checked? Is it still so?

Yep. We do it in an non-intrusive way, so the things are decoupled 
from style development.

Robert says not spending time on R3GUI .. so is it now dead?

Or, waiting to see if Carl can fix show stoppers?

That didn't come out quite right. The R3GUI is needed for an inventory 
application, so development will continue for it.

But it sure would help, if Carl just started again.

What are the things blocking progress?

I had mentioned earlier that it would crash due to complex layouts, 
but this is not the case. The layouts can be very simple. For example 
this one:

1. run graphical version of r3.exe

2. load following R3GUI release from web:

do http://www.rm-asset.com/code/downloads/files/r3-gui.r3

3. execute  this simple layout example:


view [tab-box ["tab1" [] "tab2" [] "tab3" [] "tab4" [] "tab5" []]]

And the error lies in ... ?

R3GUI is not abandonned, but only required bugfixes will be done. 
If the situanion with R3 will improve, development will continue.

GrahamC, I think the issue here is that the bug can't be found unless 
Carl provides a debugging version of R3, so we can find where the 
bug occurs, whether it's in the host kit or the core. I can't be 
sure as it's something that was discussed last over 6 months ago.

Graham - there simply might be errors related to R3 Core, not View 
core, which are fixable only by Carl. I think that Carl could at 
least fix those eventual show stoppers, to allow others to continue 
with R3 usage ....

There is definitely 'something' in the R3 Core that crashes the interpreter. 
At the moment it is very hard to track it without the access to the 
sources or having the debug release of the R3 library. (ie. I was 
able to trace the crash using the debug release of hostkit exe but 
the trace ended in the 'hidden' dll part so the hostkit code seems 
to be most probably out of the game here)

 IMO it has nothing to with the graphics part(unless there are 2 separate 
 bugs ;)) as I was able to crash R3 when writing non graphical script 
 as well. The crash is very hard to reproduce as it occurs only with 
 specific form of the executed script. If you change some line or 
 even order of words etc. the script works just fine.

It looks to me  either some GC or other memory allocation leak issue 
and have suspicion it have something to do with the map! datatype 
(but this is just my feeling).

I can confirm I've seen such a strange crash as well without any 
graphic involved.

Does it still crash with trace set on ?

I don't know... it was after some heavy real job made in console. 
I'm using R2 instead.. it's a little bit slower, but stable.

I had a couple of crashes that went away when I set trace on ...they 
were both on OS X and I think are related to memory issues. They 
are still open in CureCode.

I'm quite used to have several consoles opened which I use for multiple 
purposes and do not close them after each finished script. So I'm 
more affected by these possible GC bugs in R3.

Sadly, it doesn't help with debugging.

Sadly, debugging does not help if nobody is interested.

True.

One nasty crash seems to be located in RESOLVE (cc#1865), which basically 
makes almost all module-system related stuff unstable/crashy.

Basically, everywhere you use IMPORT you could be affected by this 
bug.

I can assure you that there is a bug in Resolve.

We should probably buy a radio, and contact Carl on Mendoradio :-)