r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 GUI]

TomBon
17-Dec-2011
[7353]
ok, organigram... thought something like this -> http://www.mathworks.com/matlabcentral/fx_files/24253/1/heatmap.png
Robert
17-Dec-2011
[7354x2]
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.
TomBon
17-Dec-2011
[7356]
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.
Pekr
17-Dec-2011
[7357]
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?
Henrik
17-Dec-2011
[7358]
It'll be a while, before I'm available to do any skinning work.
Pekr
17-Dec-2011
[7359]
well, skinning work is also dependant upon material systsem, etc., 
which was not done, last time I checked? Is it still so?
Robert
17-Dec-2011
[7360]
Yep. We do it in an non-intrusive way, so the things are decoupled 
from style development.
GrahamC
30-Jan-2012
[7361x2]
Robert says not spending time on R3GUI .. so is it now dead?
Or, waiting to see if Carl can fix show stoppers?
Henrik
30-Jan-2012
[7363x2]
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.
GrahamC
30-Jan-2012
[7365]
What are the things blocking progress?
Henrik
30-Jan-2012
[7366]
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" []]]
GrahamC
30-Jan-2012
[7367]
And the error lies in ... ?
Rebolek
31-Jan-2012
[7368]
R3GUI is not abandonned, but only required bugfixes will be done. 
If the situanion with R3 will improve, development will continue.
Henrik
31-Jan-2012
[7369]
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.
Pekr
31-Jan-2012
[7370]
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 ....
Cyphre
31-Jan-2012
[7371]
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).
Oldes
31-Jan-2012
[7372]
I can confirm I've seen such a strange crash as well without any 
graphic involved.
PeterWood
31-Jan-2012
[7373]
Does it still crash with trace set on ?
Oldes
31-Jan-2012
[7374]
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.
PeterWood
31-Jan-2012
[7375]
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.
Oldes
31-Jan-2012
[7376]
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.
PeterWood
31-Jan-2012
[7377]
Sadly, it doesn't help with debugging.
Oldes
31-Jan-2012
[7378]
Sadly, debugging does not help if nobody is interested.
PeterWood
31-Jan-2012
[7379]
True.
Andreas
31-Jan-2012
[7380x2]
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.
Jerry
31-Jan-2012
[7382]
I can assure you that there is a bug in Resolve.
Pekr
31-Jan-2012
[7383]
We should probably buy a radio, and contact Carl on Mendoradio :-)
BrianH
31-Jan-2012
[7384]
The module system can be fixed to not use RESOLVE/extend/only, and 
a few months ago I submitted such a fix to Saphiron for them to include 
in their next host code release, along with other mezzanine fixes. 
I'm just waiting for them to post another release. In the meanwhile, 
in my own module code that does exports I do the exports explicitly 
in the module code itself instead of using the EXPORT keyword or 
the Exports header.
Andreas
31-Jan-2012
[7385]
Afaik, we (the community, that includes Saphirion) cannot build binaries 
incorporating mezzanine changes with the current hostkit.
BrianH
31-Jan-2012
[7386]
Nope, you just can't build a single binary with a statically linked 
r3lib. You can build a host kit exe with a dynamically linked r3lib 
with any mezz changes you want.
Andreas
31-Jan-2012
[7387]
Nope, the current hostkit build does not take mezz changes into account 
in any way.
BrianH
31-Jan-2012
[7388]
Interesting. I thought that the mezzanines were loaded by the host, 
not built into r3lib.
Andreas
31-Jan-2012
[7389x2]
Some of them are (mostly the bundled extension related ones), most 
of them are not.
(See %src/tools/make-host-{init,ext}.r for details.)
BrianH
31-Jan-2012
[7391x2]
If I make a patch file that fixes the mezz problems, including the 
module-related ones, will that work? For now (when the module list 
isn't really protected yet) this is doable...
We can't hot-patch functions in R3 for security reasons, but we can 
replace them completely with fixed versions.
Andreas
31-Jan-2012
[7393x3]
When would you load that patch file?
I think you mentioned somewhere, that replacing affected functions 
from user.r is not possible.
(For this particular RESOLVE issue.)
BrianH
31-Jan-2012
[7396x2]
I load a patch file in %rebol.r right now, for my work use of R3. 
If I was doing my own host builds then I would put a reference to 
the patch file early on in the host-init code.
%rebol.r still works, and it loads pretty early on in the boot process. 
The host init loads earlier.
Andreas
31-Jan-2012
[7398x2]
I don't have the loading intricacies in enough detail in my head 
right now to reason about this sensibly.
But I guess we could at least try, if you have a particular hotfix 
in mind.
BrianH
31-Jan-2012
[7400x2]
I have a list of fixes and improvements in mind, so I'll see if there's 
some time by the end of this week to put together a patch file. I'm 
sorry that I haven't documented the module system well enough to 
make it practical for anyone other than me to patch it at runtime. 
Improving its documentation is on my todo list, though I've been 
a bit busy at work lately.
Hopefully this patch file will serve as an example for others who 
want to do similar patching.
Cyphre
31-Jan-2012
[7402:last]
I succesfully 'overloaded' some mezz functions in R3 in the RMA hostkit. 
See the inclusion of %rma-patches.r file in src\tools\make-host-init.r 
in the RMA host-kit release. So it is possible to do some fixes that 
way.(of course not every part can be tweaked such way)