World: r3wp

But why doesn't it coerce to decimal automatically, as it does for 
larger numbers? 

Wondering why I've never seen this.

Thanks Geomol. That makes perfect sense. Should I be using decimal! 
instead?

Becuase of 32-bit.
>> to-integer #7fffffff
== 2147483647
>> to-integer #80000000
== -2147483648

If you use decimals, you can have larger numbers, before you loose 
precision.

Up near
>> 2 ** 49
== 562949953421312.0
>> 2 ** 50
== 1.12589990684262E+15

Why was I sure REBOL coerced the result in this case? Hmmm.

I don't know. :-)

I often forget the math rules in REBOL too and just have to check.

I just tried "1134903170 [decimal!] + 1836311903 [decimal!] and that 
didn't work either... how can I get througth the "addition" barrier?

People use integer! rather than decimal! because they don't want 
to lose precision at all, rather than eventually.

Matt, do this:
    (to-decimal 1134903170) + (to-decimal 1836311903)
or this:
    1134903170.0 + 1836311903.0

Thanks, now my script should work perfectly.

If you write a number without a decimal point, it's an integer datatype. 
With a decimal point, it's a decimal datatype. You can use either 
in many functions:

>> for i 1 2 1 [print i] 
1
2
>> for i 1.0 2.0 1.0 [print i]
1.0
2.0

Rebol[]

fibonacci: func [{Makes a list of fibonacci numbers and stores them
	to a block called fibonacci-block.} loops [integer!] {Number of 
	iterations to run}
	] [
	fibonacci-block: [0.0 1.0]
	count: 0
	loop loops [
		addend-1: index? back back tail fibonacci-block
		addend-2: index? back tail fibonacci-block
		new: fibonacci-block/(addend-1) + fibonacci-block/(addend-2)
		append fibonacci-block new
		count: count + 1
		print count
		print new
		]
	Print fibonacci-block
	write %fibonacci.txt fibonacci-block
	unset fibonacci-block
	halt
	]
Print "Type fibonacci [# of loops] to make fibonacci-block."
halt

Thanks to all all of you my script works perfectly now. :-)

:-)

In the DocBase page for GUI_Panels, Carl wrote


A group has no backdrop or border and arranges horizontally by default.


I feel this is ambiguous; do groups have no backdrop or border ever 
or only by default?


I'd like to edit the wiki to make this more clear but I can't tell 
 from the rest of the page whether a panel can have backdrops and 
borders. Can anybody with access to R3 clarify this?

By the way it looks a lot like a Java GridBag.

I'd imagine that's the distinction between Panels and Groups?

So you think that a Panel is an invisible container?

I think adding integers used to produce a decimal, when it overflowed. 
There were problems caused by this, and discussions followed, so 
it was changed to the current system.

Peter, I also think that, as Chris suggests, borders are designed 
to be invisible, while panels can be seen.  I don't see any reason 
why a border couldn't be restyled to be visible, though. It will 
be one of the first things I'll want to do - hacking if I have to.

From re-reading the Docbase page, it seems that both panels and groups 
may be visible as they have styles:


Panels are implemented with the panel and group styles. You will 
use these two styles together to create a wide range of layouts.


I don't think that I'll try to clarify the DocBase entry just yet 
though.

They /are/ styles, both.

Henrik, so far this looks exactly just like VID3, except that there 
is no separation between look and feel.

Gregg, I think what you remember about coercing to decimal is that 
if you type a number greater than maxint it gets loaded as decimal.

>> type? 2147483647
== integer!
>> type? 2147483648
== decimal!

Gabriele - your desing used and combined multiple gobs. What we can 
see so far is the one gob design, plus gob style face being placed 
upon it. If we use only one draw block for various states, I wonder 
how do we do conditional drawing in one single draw blog - e.g. focused, 
vs normal state.

IMO instead of adding additional styles, we should be sure, that 
we can easily express such things as focusing, display of accelerator 
keys, etc.

Is it really one gob with a gob style face placed upon it? Isn't 
even something as simple as :
panel [
  button "Start"
  button "End"
]

at least 5 gobs?

Peter - I am talking about one single style, not multiple styles 
being one gob.

From Henrik's code above, it seems we have only one draw block and 
various states (e.g. button up, down, over) are being handled only 
by parametrising via facets, but still one draw block. But is imo 
nicely simplified concept, BUT - it may not work for more complex 
styles. What if I conditionally want to draw (or not), if the style 
is focused, disabled, etc. Not everything can be imo expressed in 
one single draw block. That is why so far the removal of frames concept 
(having different draw blocks for various situations) was imo preliminary, 
but we will see ....

My guess is that the worst case would be that you have to use different 
styles and unhide and hide them as needed.

Currently, PANEL produces a background along with a border. That's 
why there are a lot of rounded borders in the first screenshots. 
Due to a bug (?) in the layout engine, PANEL must have a draw block 
assigned that fills out the background with a neutral color.

GROUP behaves as follows:

- No background

- When not specifying elements in a group block, they layout vertically.

- When specifying elements in a group block, they layout horizontally.

- When specifying a number for the group block, each element lays 
out horizontally until the number is reached and then a new row is 
started.

Differences from VID3:


- There is no concept of rows and columns. Elements of uneven sizes 
will uncritically be laid out right next to eachother. I've not yet 
discussed with Carl whether this goes in or if there is a different 
solution. I've observed code for grid management in both GROUP and 
PANEL and a facet reading "grid: true", but it seems not to be working.

are you the only person testing AltVid?

no

Just the only one talking :)

So far :-)

A couple of articles I found interesting about the future of interpreted 
programming languages. 

http://weblog.infoworld.com/fatalexception/archives/2008/10/virtual_machine.html

http://weblog.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/08/10/13/42TC-dynamic-futures_1.html

VM, JIT and access to other programming languages libraries is the 
future...
Maybe Rebol 4 ?

There is no concept of rows and columns.
 <--- this was a bug and has been fixed.

Petr, most of the styles in VID3 use just one draw block. Also when 
using multiple gobs, eg. in a scroller, they have one draw block 
each too, and state is just changing the value of some words. Carl's 
version just limits this to a single draw block, without automatic 
resizing. Which, you're forced to do if you remove the distinction 
between feel and look (you're stuck with whatever gob structure was 
in the original style anyway without that distinction).

Henrik - it seems your button design does not work for darker button 
variants, does it?

It's very difficult to produce anything useful with a darker color.

maybe changing button text color to white will be needed in such 
cases, or white 1px outline of text, but not sure how would it turn 
out ...

That would complicate the code a bit too much. We can only recommend 
that people don't use dark buttons. :-) It's easy for the user to 
adjust anyway.

Henrik - you latest screenshot simply shows, that 'label should be 
antialiased imo ....

Carl's now describing a bit sizin model in following chapter - http://www.rebol.net/wiki/GUI_Panels

New VID related blog posted - http://www.rebol.net/r3blogs/0152.html
- GUI: Thin skins, thick skins, and in-between

That Panels doc is a work in process.

Color picker example - http://www.rebol.net/r3blogs/0153.html- I 
gues now with Carl's frequent enough blogging, there is no point 
in posting such links?

I mostly find links to Carl's blog these days by first going here. 
So it's good from my point of view.