AltME groups: search

window: layout [i: image rate 5 load %gtfo.jpg key escape [halt]]

zoom-in: does [i/size: i/size * 5 / 4]
zoom-out: does [i/size: i/size * 4 / 5]
down: false
alt-down: false

insert-event-func [
	probe event/type
	switch/all event/type [
		down [down: true]
		up [down: false]
		time [if down [zoom-in]]		
		alt-down [alt-down: true]
		alt-up [alt-down: false]
		time [if down [zoom-in] if alt-down [zoom-out]]
	]
	center-face i
	show window
	event
]

view/options window [resize]

REBOL []


window: layout [i: image rate 5 load http://rebol.com/graphics/kits.jpg
key escape [halt]]

zoom-in: does [i/size: i/size * 5 / 4]
zoom-out: does [i/size: i/size * 4 / 5]
down: false
alt-down: false

insert-event-func [
	probe event/type
	switch/all event/type [
		down [down: true]
		up [down: false]
		time [if down [zoom-in]]		
		alt-down [alt-down: true]
		alt-up [alt-down: false]
		time [if down [zoom-in] if alt-down [zoom-out]]
	]
	center-face i
	show window
	event
]

view/options window [resize]

I'm finishing attached files management for CureCode with thumbnails 
generation....too bad, you'll have horrible thumbnails...


Once again with REBOL, stuck at 95% of the goal and no (simple) way 
to workaround. That's how I usually loose all the time gained by 
using REBOL instead of another language...Where's that Rant channel? 
:-)

... well, just kidding ... I thought it is a one-time job ....

If Carl have time for including/testing the change then why not. 
I can add the low-level code in a hour or so. But the dialect parser 
change needs to be tested after Carl compile the new r2 exe.

I thought about it but don't have enough free time to implement it 
myself. Btw passing image! datatype through a routine! is quite tricky 
IIRC?

Pekr: I would like to have that feature, but workarounds exists. 
If Carl has to spend time on R2, I prefer him working on fixes for 
long standing native bugs instead.

The first time (when the console pops up) it is set to none, but 
after that it will work alright

VID was a revolution at the time of its invention .. but we hope 
that it will be soon superceded by R3 GUI  and we won't have to worry 
anymore :)

This is not obvious with VID, because you might build such a layout 
in a special setup, but in the VID Extension Kit, you have face constructs. 
A face construct is simply a style that accepts a particular dialect 
as input. The dialect is parsed into VID which then in turn generates 
an internal face tree. This means you can build styles that do something 
like:

view layout [
	paper [
		size a4
		dpi 300
		at 20x20 image bay.jpg
	]
]


The point is that every time you feed the paper new data, using SET-FACE, 
it's re-rendered from scratch using VID.


You can also build very complicated list views that dramatically 
change appearance and number of faces, every time you feed it new 
data.

and because the rate IS NOT triggered when REBOL is busy, it will 
actually send Less events on its own, making the trick scalable in 
real-time.

this is a very serious bug, cause it means that any draw block can 
crash at any time.

then BAM... a crash... so its back to square one... linear fills, 
when clipping, just crash AGG at some indefinite point in time.

ironic enough, the current 1.2.22 AltME which has noticeable behavior 
changes while sending messages, will cause duplicated messages if 
you try a second time to CTRL-S while waiting for it to go out...so 
I am seeing more duplicated messages...just did one in here...  :-\

one easy suggestion for improving "responsiveness" is to ALWAYS put 
UI code at the top of any processing.


it takes us quite a long time to react to a change in the ui, so 
that delay can be used to do the processing.

that was one reason the Amiga felt so fast... the gui wasn't managed 
by the application's task, but by the os... independently of the 
application's business.    For example, even if the application was 
processing, the menu would pop up in real time... cause intuition 
(the gui manager) was at a higher priority than most applications.

Paul, post your method. There wasn't any common dialog for folder 
selection in Windows for a long time, and REBOL still doesn't provide 
direct access to it.

for a long time
? I remember using the folder selection dialog in Win3.1 apps...

using the above tricks you can make system-wide intialisation functions:


here is a cool previous login detection system which fills up your 
whole gui based on stored data in a database.

	

; supply contexts, view controls set into them and the data to set 
into.
setup-all-gui: func [
	spec 
	/local ctx control controls data i
][
	foreach [ctx controls data] spec [
		repeat i length? controls [
			control: get in ctx controls/:i
			set-face control data/:i
		]
	]		
]
	
; reload previous session
either all [

 main-data: get-sql-last-main-data  ; returns [ "project" "module"]

 login-data: get-sql-last-login    ; returns ["user" "encrypted" "server.com"]
][
	setup-all-gui reduce [
		main-gui [proj-fld mod-fld] main-data  
		login-gui [login-fld passwd-fld server-fld] login-data
	]
][

 print "This is the first time you use application, user-setup will 
 now be called."
	setup-user
]

no ... that is my old-time complaint ... ctrl tab is needed to swithc 
between tabs ....

are there known problems with RATE inside a DETECT? when I use it, 
EVENT/TIME is fired constantly, even if I set rate to something like 
0:0:10.

whoops, I meant event/type = 'time, not event/time.

because detect is part of the wake-event system, it gets all the 
events from the input stream, so you end up with all time events.

it was done this way so view can share the same time event among 
many faces, internally.

It took me quite a while to figure out what I called "Time event 
madness"  ;-)

that managed within the do-event of wake-events.


the fact that  detect is called, means do event was called.  whenever 
a detect returns false, it consumes the event and subfaces do not 
get their events (even time IIRC).

IIRC the corrected time event is kept by engage, not detect.

use engage not detect to trap the time event accordingly with the 
rate

seems that engage has no effect. so you are not supposed to be able 
to use engage and detect at the same time in the same face?

yes, it's not easy, however everything is working as expected, except 
for time events and the use of engage.

its possible the window cannot have time events, no matter its rate. 
 try using a master face in which you put everything, using its feel 
instead.


the window is managed differently than other faces by view... it 
has its own events like resize and stuff, so I wouldn't be surprised 
that its time handling is different.

(I meant, support for time events in its engage)

yes - iirc window does handle time differently and you should always 
use a master face

With the above code on Linux I see this:

move 77x78 ; Final move of mouse to a stop, then I wait a short time...
down 77x78 ; <- I click.
up 77x78 ; <- I release, and I wait...
move 77x79 ; I begin moving mouse again.

is there any known way to make rebol spontaneously quit? I've run 
into a case where it just quits, when I focus a field in the VID 
Extension Kit, but I have no clue what does it, although I can reproduce 
it every time.

There is no private grouop for Draw (unless it has an obscure name 
that I do not recognise).
Perhaps time to start a Draw group?

something like this...

insert-event-func 	[
    switch event/type [
        key         	[]  
        time        	[]
        close       	[]  
        offset      	[]  
        resize      	[
		switch event/face [
			X [recalculate pos for face x]
			...
			...
		]
	]  
             scroll-line 	[]  
             scroll-page 	[]  
	up 		[]  
	move 		[] 
	down 		[]  
	active 		[]  
	inactive 	[]  
	alt-down	[]  
	alt-up		[]   
	minimize	[]  
	maximize	[]  
    ]
    event
]

updated the animated vector projection tests script:

-uses the chrono library for more precise time management.

-now has option to prevent clearing the image at each refresh (feedback), 
press enter

-you can also manually increase and decrease max frame-rate on mouse 
drag using arrows.


http://www.pointillistic.com/open-REBOL/moa/files/ptest-preboled.r

on my system, I can easily go up to a 100fps before feeling lag.

Preferably, this would be done at view definition time as shown above.

set-face

 seems to show a way to handle it, but it's clumsier than I would 
 like and doesn't handle the text labels.

Hi JoshF, do you want a style (eg. your 'gint') that is simply replaced 
by two other styles (eg. a TEXT and a FIELD) as if you had simply 
specified them individually yourself, or do you want a panel each 
time (which contains the other faces) ?

stylize/master [
	gint: panel [across label 200 field] with [
		multi: make multi [
			text: func [face blk][ ; <- strings
				if pick blk 1 [
					print ["Text:" mold blk/1]

     ; Do nothing (prevents the default PANEL/MULTI/TEXT from setting 
     the panel's face text).
					;  print mold get in svv/vid-styles/PANEL/multi 'text
				]
			]
			size: func [face blk][ ; <- pairs and integers
				if pick blk 1 [
					if integer? pick blk 1 [
						print ["Integer:" blk/1]
						; Do nothing.

      ; I was going to set the integer field's text to this number directly, 
      but the panel's

      ; subfaces haven't been created (in its PANE) at the time the MULTI 
      functions are processed.

      ; So then I thought I'd use FACE/DATA to store this value and then 
      set the field's text

      ; later in INIT, but thought better of it, since I found it's easier 
      to parse FACETS,

      ; and I don't feel comfortable using the panel's DATA facet to store 
      a value of only
						; one of its subfaces.
						;face/data: blk/1
					]
				]
			]
		]
		append init [
			;?? texts
			;?? facets
			context [
				lbl: pane/1
				fld: pane/2
				foreach val facets [
					case [
						string? val [lbl/text: val]
						integer? val [fld/text: form val]
					]
				]
			]
		]
	]
]
view window: layout [
	gint "Elephants to invite" 481
	gint "Peanuts / elephant" 5000
	btn "Calc"
]

it might be possible to use a callback and allocate our own OS timer 
via library calls, but I think it not worth the hassle.  going past 
32 fps didn't produce noticeably smoother animation, and it allows 
much more time for (slow) math and AGG rendering in REBOL.

Max - interesting achievements. Do you really think, that the draw 
dialect interpretation is the culprit and performance killer? IIRC 
Cyphre said, that time to interpret the draw block dialect is really 
negligible ...

decide on a particle life time... lets say  life: 10

then go over the list, picking up count amount of particles at at 
time with life number of interations.
the life iteration is used to calculate age: life / life-counter

Very cool, Maxim...thanks. 

is this done as an interactive process?

Not sure what you are asking but stage 1 would be to allow these 
fire "objects" to be placed on top of an image via drag and drop 
and allow for some editing such as sizing. (Later versions would 
allow adjusting those other variables you mentioned above). 


Stage 2 would allow for some transitions from one set of settings 
to another so for example the fire can become more intense over time 
or when clicked on or a button is pressed. 


I just had a week of training on a flash based system...its cute 
and does teh job for what we are going to use these "simulations" 
for but I thought it was a little too complicated for your average 
fireman to use if he wanted to create his own sims for drill purposes.


The flash extensions used all those variables you mentioned above 
to allow for a great degree of controll of the effects.

by interactive I mean will this be rendered or running live?


with a rendered system you can crank up the particle count and just 
pregenerate the whole data set as a series of images.  then when 
you need to see it, just cycle the image of a face.


usually, people use a few particles for preview... then generate 
"flipbooks" which are just rendered images and include thousands 
of particles with their alpha channel density reduced to practically 
nothing (like 2% visibility)  this generates very pretty effects, 
but at a cost of rendering time.

interactive? depends on the quality of real time...it does not need 
to be super realistic....I'll play with it...thanks

If my I'm not doing a wrong guess, your WITH function bind its block 
each time it's called. That may be quite slow.

But maybe, it's just a dialect, not something evaluated by Rebol 
in real time...

Oldes, how many particules do you process in real time ?

The problem is, that we have only 40MB for complete game so I cannot 
prerender the smoke effect into sequence of images and I cannot do 
it even during init time as the engine has some problems with premultiplied 
semitransparent images. But I want to do some improvements.. also 
it's possible to make (pregenerate) a classic animation for each 
particle so no AS would be used to traverse the block with positions 
which also slows down a little bit... and no, the engine is not slow 
for that, but you must have the game itself running as well under 
the smoke effect:)

a run-time screen grab while the simulator is running  :-)

A looooong time ago, Carl Read and I did something for TTFs on Windows. 
I can dig it up if you want Chris.

IIRC it doesn't happen all the time... so I've got no clue what the 
problem is.

Andreas, weird, last time I tried .4.3 it would segfault on start 
iirc - now seems to work ok.

yI'd look it up on MSDN there might be extra steps to update the 
transparency in real-time  but it is definitely doable, I've seen 
an animated opengl demo rendering directly over all windows without 
a window of its own.

I was checking the source of course, without it I would not come 
with code like:
	clear second second :load-image


But it was not for the first time when I had the situation with the 
unexpected image. Of course, to use :
	layout compose [image (load %image.jpg)]

is a solution as well. I just have to remember it not be confused 
again with code:
	layout [image %image.jpg]


The problem is, that normal user who want's to just display simple 
view layout does not know that there is the function load-image.

I doubt it .. gestures for letters have been around for a long time

henrik, try typing on a (small) touchscreen when shacking, its even 
worse, this device doesn't need to be precise, which is the point.


now one thing they don't mention is that our brain has an internal 
"rest position" hard-wired, and that is where the center dot is very 
well tought.  whenever you move any part of you body, the moment 
you stop thinking about it, it goes back to its rest position by 
itself.  this is very obvious when you swipe you mouse quickly, you 
hand will go back to its original position by reflex.


so using this in a shacky environment, where I can squeeze the device 
in my hand will, IMHO, be much easier to use quickly.  its obvious 
it takes a little bit of time for your brain to associate the letters 
to direction and rotation amount, but since doing the next letter 
is just a question of going back to the rest position, I feel its 
very fast and easy to get used to.

well, swype does require you to "aim" the letters... 8pen could be 
used by a blind person within a short time.

Yes, I actually saw that in my tests as well. For now this one "wait" 
seems to be doing its job and I just hope it is not system-dependent 
in terms of the time I have set the wait for.

because the face is transparent, and modifying it (not creating new 
images) you have to merge the background... this change occured a 
long time ago (draw V2 IIRC).


in your second example, it works only because you set the face color, 
which is then multiplied. 

first example, fixed:

view layout [
    backdrop effect [gradient 1x1 180.0.0 0.0.100]
    vh2 "Layout Definition:" 200x22 yellow
        effect [ MERGE gradmul 1x0 50.50.50 128.128.128]

    vtext bold italic "Layouts describe graphical user interfaces."
    button "Remember" effect [gradient 0.0.0]
]

yeah, its been like that a long time, its just an edge case which 
people don't hit often.   you probably where using faces with colors 
and you didn't realize it.

No it doesn't change the result.
To test it give a width for the text:

t: join head insert/dup copy "" " " 500 "test"
view layout [text 100x400 t white blue as-is]

test
 is still on the second line.

I tried as-is, line-list: none, I need to use wrap?: yes. Otherwise 
I have to my own wrap function which I don't have time to do.

Ok, I tried different text editors to see the word wrap behaviours, 
they all have different behaviours. Now I see your point.

I thought that it is a bug (and still feel like that) because "it 
doesn't matter how many spaces you insert to the beginning, "test" 
doesn't move after some point" (How it should move? you asked, I 
don't know, but it SHOULD move somehow if I constantly add more spaces)

All the other tools (notepad, notepad++, editplus etc.) behaves different 
than each other. They wrap the line, if you add more spaces after 
some point they move (push) the text down or right or somewhere. 
But they move it anyway. They don't stop somewhere.
Anyway, thank you for your time & responses.

CHOICE style performs a SHOW on top level window when clicked I think, 
and leads problems:

view layout [
	choice "a" "b" "c" [b/rate: 1] ;there is no "show b"
	b: box red rate none
	feel [engage: func [f a e] [if a = 'time [print now]]]
]

time events get fired without "show b"

That concern is on many people's minds, but the question is whether 
you will let that stop you. It does for example not stop me, being 
in a full time job working with REBOL.

True, but I'm not fluent in it, because Carl, the original creator 
of REBOL, was around. I'm fluent in it, because there are many extremely 
talented and helpful users in here, who know just about every single 
advantage and limitation in REBOL and know what type of programs 
can be developed in it.


Should Carl decide to abandon REBOL, there is a legacy in the shape 
of Orca, Red and Topaz and I'm sure there would be even more focus 
on these efforts by then. I stick around, not just because I have 
built my development infrastructure around it, but because I dearly 
love the language and I can be much more productive in it than anything 
else, I've tried, and that won't go away for a long time for me, 
because there is no indication to me that there will be anything 
around anytime soon, that will surpass it.

>> layout [X: button]
>> ? X/doc
X/DOC is an object of value: 
   info            string!   "rectangular, rendered buttons" 
   string          block!    length: 2 
   image           block!    length: 2 
   logic           none!     none 
   integer         string!   "width of button" 
   pair            string!   "width and height of button" 
   tuple           block!    length: 2 
   file            none!     none 
   url             none!     none 
   decimal         none!     none 
   time            none!     none 
   block           block!    length: 2 
   keywords        none!     none 

>> ? X/doc/block

X/DOC/BLOCK is a block of value: ["execute when clicked" "execute 
when alt-clicked"]
>> view layout [button [print "clicked"][print "alt-clicked"]]
clicked
alt-clicked

I think one solution is to add a uniform domain based dictionary 
(one domain for styles, one for VID, one for other dialects), that 
help understands, but it can unfortunately not make dialects themselves 
self documenting. Possibly there would be automated dictionary builders, 
but these take a lot of time to run during startup, so maybe they 
should be some sort of callbacks from help to get just-in-time help 
on a domain.

Then you could use:

>> help/on styles

to get a dictionary on the styles, based on a dictionary builder.

UTF-8 is a strict extention of ASCII, but ASCII is only defined between 
0 and 127. Characters 128+ are not ASCII, they are extensions, and 
their meaning depends on the codepage. The codepage of an 8-bit string 
is unknown, unless you specify it externally (or do a lot of statistical 
calculations). Strings or scripts with characters extended by a codepage 
will have to be translated by a codepage-to-utf-8 function or process 
specific to the particular codepage, ahead of time. Fortunately, 
such a process can be fast and even implemented in a byte-oriented 
language easily.

Is it time for some news/update? A little tickle to stoke the excitement 
 for us on the outside.

I sent Carl an example of the problem some time back via feedback 
but never heard anything more about it

Some news: Maarten has stepped up to become release manager, while 
Carl "retreats" to kernel development. This means that work is under 
way to provide a public alpha release, but no time table is yet known.

Rod: that goes for most of us. The time table is not carved in stone 
yet so I am not going to give a date . But we're making very good 
progress for alpha1

It's pretty simple really, as long as you realize that the closure 
function creates a value of the closure! type. The main difference 
between a closure! and a function! is that a closure! creates a context 
every time it is run and binds the words in its body to that context, 
like USE in REBOL 2. A function! just uses a special context instead 
with stack-local references, which goes away when the function! is 
done - there is no REBOL 2 equivalent to that, but a C function is 
close.

All;  I'm the volunteer for the new VID 3 documentation.  (And don't 
really feel that worthy, but that can't be an excuse to make it complete, 
concise and a nice read ... anyway ...)  It's only just in initial 
draft still (my bad), but it's all to save Gabriele and the rest 
of the core team time so they can get to the important bits.  


If you have anything that needs clarification, discoveries, how-to, 
complaints, well anything; please drop a note to this group, the 
btiffin user chat or please feel free to update the discussions page 
from http://rebol.net/wiki/VID_User_Guideand we'll try and keep 
some of the flotsam and jetsom noise out of Carl, Gabriele, Richard 
and Henrik's way while they finalize the REBOL 3 VID.   (And being 
a wiki, feel free to update the actual doc for that matter; keeping 
in mind that consistent style and tone is also one of the goals.).

Thanks and cheers.

Henrik, you mean rebol2/view right? Would it take much time for Carl 
to build an intel version for osx ?

I've been reading the R3 docs and I can't wait to start working on 
an IDE again.  Unfortunately I don't have enough time to really chase 
that again...  Yet!

Yes, I have LOTS of ideas for an IDE! 


A few months after joining the REBOL community (very soon after IOS 
was released) I actually started a funded IDE project for REBOL. 
 I spent quite a bit of time discussing these ideas with Carl who 
agreed to release it as THE REBOL IDE but unfortunately the funding 
died.  I've tried numerous times to renew the project all to no avail.

I'm not 100% sure about CGI in general but there is no -c cli option.for 
2.99.4.  afaik the only options advertised as ready for prime-time 
are -q and one that controls quit/halt behaviour.  Expect someone 
more in the know to correct what I just said.  I'm not 100%.  (Or 
after a perusal, I may correct myself in a few minutes).

Not at this time. It requires a COM interface IIRC. I can't remember 
if/how it was done in Windows before that.

I would guess that until unicode & modules & tasks are given some 
soak time, many many things are up for change.  Nothing in the area 
of mezzanines would be stamped final yet (imho) as Mr. Hawley hasn't 
optimized away  each and every (while few) stray bit yet  :)  (plus 
DevBase has yet to roll large).   Umm, in details ... I'm pretty 
sure Carl has nailed down most (or all) of the conceptual layers 
and the interfaces won't change as much as internals might.

Well, that was really my point. It may sound blunt, but having an 
idea does not mean that others have time to implement it

But at the same time this does not mean it is a bad idea ;-)

Tell me about it. I've been wanting to integrate REBOL with .NET 
since before the DLR came out, but no time yet :(

It depends on what RT's goal is, who has the time and skills to do 
things, and what's most important. I would like to  see time spent 
on an official systems for packaging, building, IPC, an IDE and other 
tools, a solid OSX build, etc., rather than a .NET/DLR port.

One way to see it is to ask yourself, what you value most: earning 
money or doing something right. Sometimes it's possible to do it 
right AND earn a lot at the same time. Many years ago, I found out, 
that I enjoy most doing things right, so that's my priority one.

Jerry, R2 just had one kind of context (2 if you include the autoexpand 
context used by system/words). Functions, objects and USE all used 
this type of context, and words were bound to this kind of context. 
A function! in R2 is bound to one of these contexts, which gets reused 
when the function is called. When the function is called recursively, 
the value block of the context is pushed on a stack but the context 
is reused - this is the main reason R2 could never be thread-safe. 
The only difference that object! contexts have over function! or 
USE contexts is that the word 'self is added to them.


In R3, there is at least one more context type: stack-relative, which 
is used by the function! type. All of the words bound to a function! 
resolve their bindings relative to the context in the executing stack 
frame, rather than directly. When a function! starts it allocates 
a context on the stack; when it ends it deallocates the context. 
This means that the context of words bound to a function only exists 
when the function is running, so there is no point to referring to 
these words outside of the function. Although this slows down word 
references, it speeds up function! calls and reduces potential memory 
leaks due to word references in functions after they have returned. 
This slowdown in word references is the reason that R2-style rebcode 
doesn't make sense to add to R3 without some changes to its semantic 
model to make up for the difference.


A closure! in R3 is like a USE call in R2 (USE in R3 is implemented 
using closure!). The words are direct-bound to a context (so word 
references are faster), but it creates a new context and bind/copy's 
the code block at the beginning of each closure! call. There is still 
no point to bind a word to a closure's context when the closure isn't 
running, since the next time the closure runs it will create a new 
context, but it does make sense to use a context created by a closure 
call after the closure has returned since it is a regular context 
like a R2 USE context. In general, it is better to use function! 
unless you need to refer to the context after the closure! returns 
- mostly useful for generators, currying and other functional programming 
tricks.


In R3, object! contexts are like the R2 system/words context: they 
can expand, but not shrink; closure! and function! contexts can't 
expand though. There will be further changes to the way object! contexts 
work, and module! contexts will behave the same way.

I'm struggling a bit with the closure! specifics.  I have used closures 
in Ruby (though I'm not clear on the difference between a block using 
yield and a closure at this point) and part of what I thought made 
valuable was the connection to the context they were formed with 
that persists.  I'm probably getting this all wrong but what does 
"next time tthe closure runs it will create a new context" imply 
on that front?

How about wait 0?

I used it a few time just to be sure that an event got really triggered.

On the other hand, there should be nothing stopping you from making 
a pure functional dialect that compiled to imperative REBOL, and 
the result might be faster than all but the best hand-coded REBOL, 
once you get past the compiler overhead. If you can compile ahead 
of time that won't be much of a problem.

can't chat and code at the same time, I think. ;-)

hey, there's even a comment on the wildfire blog entry from Carl 
that says: "Sorry that I do not have time to do more -- too busy 
with work (REBOL Tech)."

suits me well. won't have time for R3 work until July anyway. :-)

I have 75% of a dict:// scheme written.  (First thing I did when 
I got in on the alpha.  Took about 6 hours.  Then I got confused 
on the new I/O completion rules.  Haven't looked at it since.)  Soon. 
 I use the R2 dict-demo all the time now.  Nothing beats using the 
REBOL console as a dictionary/thesaurus.  From using KDE, there are 
all kinds of schemes on the wishlist.

That assumes that the technical ability (of which there is lots) 
and the programmer time (of which there is little) is available.

I don't see how Carl has time with the ham radio hobby and wine making 
and a ranch to run etc... - let alone the day to day running of RT.

Speaking of Graphics - Henrik weren't you the one that inquired one 
time about my text-list modification that had the colored text lists?