World: r3wp

doh... sorry... copy/paste error in my code.  selection is working 
fine.  thx

Hi all,


what might be the best way to have a window with a process running

in the background, checking something and if a change occurs, the 
window ist
updated???


I made a GUI and function for the check. Checking and updating the

window via button is working fine. Now i thought about implementing 
a

process with a forever loop and wanted to start it, when the window
opens or at some time before.

First, i cannot find an 'open event. What can i use instead?
Second, is the forever loop the right way to make the process??

Third, is the event the right way to start the process automatically???

Fourth, how can the loop be stopped without closing the window (button???)

Can anybody help me out?

Something like this might work for you.

view/new layout [
	button "start work" [work-to-do?: true]
]

do-work: func [][
	; <- do a chunk of the work here
	work-to-do?: is-there-more-work?
]

forever [
	if work-to-do? [do-work]
	wait [0.02]
]

I am using another way for a file search application. Ask me if the 
above is not sufficient.

for an onOpen event, you can just enclose it inside a 'do block in 
the layout.

view layout [  .. do [ ] ]

Hi Anton, Graham, thanks for your suggestions. I think i will try 
parts of both approaches.

standard text in REBOL is rather ugly.  What are some of the methods 
that some of you are using to improve your interfaces or make better 
text?

I'm just going with the ugly defaults most of the time. :)

Open MS Word (or equivalent) and look for nice fonts   =^_-=

I need some tips on "How to reduce memory" when using 'make face... 
my current application is eating 13 MB of memory with 90 faces...I 
have 80 faces that do actualy the same.. And is it standard that 
view eats this much memory? I compaired it with a using layout but 
the memory is not much different..

Mmmm i checked with some other appilcations and it all seems to eat 
this much .... Still some memory reducing hints are welcome...

view always eats a lot of memory.

AFAICT, basically all the bitmaps residing in main ram add up pretty 
quicky... just the main pane of a large window will eat up more ram 
than you'd first expect (800x600x4 = 2MB)  on top of view itself 
taking 8MB.  thats 10MB to start, but each face takes up its own 
bitmap space.  stylesheets also take up a lot of space, of if you 
use any style or stylize words in your app that also will nudge some 
space.

mmmm.... yes I thought by switching from VID to my own faces I could 
reduce memory, but thats not true I discovered. Im currently in the 
range of using 17 MB memory , thats very close to JAVA memory consumption... 
Why must a GUI must eat this amount of memory? .. As 'view communicates 
on top of the OS layer I would not expect it to eat this much.. The 
executable might be 850 K but executing explodes it... even 'altme 
eats "more" then Firefox ... Oke 'view is very flexible..very flexible 
compared to other GUI's..still with all the nested pointers etc must 
it eat this much?...mmmmm..... That brings be actualy to some other 
facts questions... What commands/functions must people NOT use when 
using faces? I mean regarding speed.. I discovered that 'draw functions 
slow down view and also a 'foreach loop stucks waking trough 80 faces... 
Would be nice if Carl could open-up a little bit more in 'tuning 
faces...;-)

17 MB is very low for a rebol script, I think. :-) I've seen them 
eat up towards 1 GB of memory. View does eat a lot. Why I don't know, 
but it must have something to do with buffered uncompressed bitmaps.

it is related mainly to non oop design. IIRc R3 will carry inheritance 
(classes). It may be related to each function in object to be simply 
once and once again with each new instance of face. According to 
Cyphre memory savings could be 1/3 to 2/3 of memory in some cases. 
But better ask him ...

not sure about that Pekr.

classes wont solve the cached bitmap issues.  which is what really 
consumes memory IMHO.

newer engine will use only AGG which will compute more stuff on the 
fly... and thus would be more memory efficient... but at what cost 
in speed.  I hope that speed will not suffer, when compared to an 
app which does not use AGG.

is this a bug? 
** Script Error: Invalid argument: random
** Where: to-image
** Near: to image! :value
>> q

*** glibc detected *** double free or corruption (out): 0x08540c30 
***

                                                                      Aborted

created when doing -> iface/effect: compose [ draw [pen black fill-pen 
random 100.100.100 box 10 10 8]] , I know it should be (random 100.100.100).. 
still a nice error NOT catched !

posted in rambo...

We are trying to lower memory footprint of view in R3 as much as 
possible. The new GOBs should be much smaller in size than current 
faces. Also the new compositing should eat less memory trying to 
avoid temporary buffers whenever possible. I believe R3/View will 
be much efficient in that way as everyone here wants Rebol running 
on his own Phone/PDA isn't it? ;)

:-)

the nice thing, with phones and JAVA is, that "all" you need is to 
download .jar file ....

My brother has new Sony Erickson K800, nice phone. Not a high end, 
far from that. I looked into ICQ Java version, and it is really very 
nice ...

Most phones run Symbian ?

If platform specific wrapper will be open source, I wonder how long 
it will take someone to map this to JAVA :-) Of course RT would have 
to port rebol library to Java too ... would be probably slow, but 
it would mean - Rebol running everywhere :-)

not sure lower level Sony uses Symbian, but it could be so ....

I guess i'd like to see tablet PC OS support first ...

there will be similar issues with working with ink on mobile devices

the porting effort for RT should be easy - they will keep closed 
source "only" the platform neutral rebol library .... the rest should 
be open source ...

My fear is that the sudden flurry of releases of R2 indicate that 
the R3 is bogging down ...

that was my fear too, and so I objected in blog, that I would not 
add any new functionality to R2, unless it is usable for R3 too. 
Some deep changes might get us into situation, when last R2 releases 
(SDK) will not be stable enough ... Carl confirmed the idea ...

The bad thing on mobile Java developement is that almost every phone 
has own specific bugs due the fact the Java interpreter has been 
implemented by different company(and usually not well tested). Even 
different types of phones from the same vendor have different JavaVM 
with different problems. Not to mention that lot of phones have specific 
additional API(with specific bugs too) so doing a 'crossplatform' 
developement is really a nightmare. I'm glad we have only one source 
of Rebol distribution in this case.

well, my friend sent me ICQ .jar, which runs on Nokia and Sony too, 
so maybe the compatibility is not so bad nowadays?

we will see, we are not there yet. First R3 alpha has to come to 
the light of the day, to see what the architecture is about. So far 
I can't imagine, whould would I download and install Rebol onto my 
Nokia - IIRC I can download only JAVA apps there, but I can be wrong 
(never did any phone related development myself)

Yes, if you don't have phone with some OS(ie. Symbian, Linux, Pocket 
PC etc.)  then you are out of luck.

that's why R4J could be a solution :-) OTOH - R3 will be imo reality 
in deep 2007 (I mean some more stable releases), so by 2008, maybe 
we will see next new generation phones ...

java compatibility: yes, it depends on the luck which phone you have. 
It is also possible that the ICQ app is mature enough so it contains 
patches for different phones. Anyway, try to read official Nokia 
dev forum to see really angry developers flaming Nokia for bug XY 
:)

so - can you imagine R3 being ported to certain OSes? How could it 
happen? Would we have to buy some Symbian dev licence, or so, to 
get development tools, allowing us to port R3 open-sourced components, 
and then ask RT to port Rebol library? How would/could user install 
such app onto his/her phone? Well, my questions are probably very 
preliminary anyway :-)

AFAIK you can create any SymbianOS app just with their SDK(free) 
and C/C++ so if RT decide to support Sybian then Rebol SDK would 
contain Symbian version of  Rebol lib which could be used for creating 
Symbian encapped apps. But as you said these are really very preliminary 
thoughts :)

Between View beta 1.3.61.3.1 and 1.3.2.3.1 the draw dialect parameter 
format for FILL-PEN changed.

The following code produces different output (and no longer matches 
my older labels from < 1.3.2):
[

 fill-pen ("style" 0) ("offset" 225x225) ("start" 0) ("end" 220) ("angle" 
 0) ("scalex" 1.0) ("scaley" 1.0) 
	black gray white 
	circle ("centre" 225x225) ("radius" 200)
]
What is the new format and where can I look that up ?

AFAIK there exist some AGG fixes. Are they part of new View and when 
not, when they will be?

Never mind, I figured it out:

; new FILL-PEN parameters since View 1.3.2.3.1 ("style" changed from 
integer! -> word!)
	[

  fill-pen ("offset" 225x225) ("start" 1) ("end" 10) ("angle" 15) ("scalex" 
  12.0) ("scaley" 8.0) ("style" 'radial) 
		black gray white 
		circle ("centre" 225x225) ("radius" 200)
	]

yes, we have changed most of the integer based parameters to word!s 
from View1.3.2

strange glayout has not suffered and uses linear and radial fills... 
is that possible?  are integers still supported?