World: r3wp

do http://www.ross-gill.com/r/altxml.r

r3tweets: load-xml/dom http://twitter.com/statuses/user_timeline/45953552.rss
                     
foreach tweet r3tweets/get-by-tag <item> [
	print ""
	print tweet/get <pubDate>
	print tweet/get <title>
]

That is 'Rebol3 Twitter', not 'Rebol3 client'...

Hi all. A percent! datatype question. What are your preferences with 
respect to the full IEEE754 64-bit range?


1) Current state: the whole range is used for percent, except for 
the fact, that LOAD and MOLD cause error when encountering results 
such as: 10% + 10% + 10% - 30% (not exactly zero)

2) Use the complete range and correct both LOAD and MOLD to be able 
to show any value from the range - this means, that the E notation, 
like 1E-15%, or 1E20% may be needed.

3) Change the %arithmetic limiting it to a subrange of IEEE754 (may 
be complicated - every operation needs bound checking and slow)

What I hated about R2 was EEE format usage, especially when you needed 
to mold/print into something user-friendly. If R3 has some form/format 
function, which will handle that, then I don't mind using IEEE notation 
in console. I am not able to answer 1) - would it make any possible 
harm to our code, its reflectivity or ability to save/load molded 
values and getting exactly the same results?

LOAD MOLD - Carl took care of that (seen twitter?)

heh ... must be total coincidence ... I showed how easy it was to 
post to twitter from Rebol, and now Carl is tweeting!  But oddly, 
not from Rebol.

he is asking for an R3 twitter client though.

and the problem is ???

is there a problem? He's just sleeping now, so he hasn't received 
the solutions yet.

I would prefer GUI version. We should also create priority list - 
what should happen after the plugins are released? Release first 
host code, examples? Then what? Move onto parse? Unicode? (still 
things like collation, sorting not supported)? GUI?

R3 could be kind of successfull on devices like my 4 days old HTC 
TouchPro2 :-) There is e.g. special GUI version for YouTube, wrapping 
the service, hence no need to go via browser. I think that we could 
wrap some such services, especially the ones having APIs, as Google 
ones. That would be good showcase for ReBrowser :-)

My percent! preference is the same as for other decimal values: always 
be correct. :-)


In that regard, what are the chances, and ramifications, of percent! 
using the new bignum internals that money! uses? 

Please don't make it use scientific (E) notation.

scientific notation should be banned !   ;-)

And therefore should Planck's constant always be written as:
0.000000000000000000000000000000000662606896
;-)

maybe it makes you respect the number more :-)

Please don't make it use scientific (E) notation.
 - so, what do you want to get from:
10% + 10% + 10% - 30%

(in the previous version the expression caused a mold error)

(exactly since the E notation was banned)

aha, you want to use the money! datatype! yes, that is an alternative, 
but does not ban the E notation anyway

I don't want to ban E notation entirely, but using it should be by 
choice if at all possible.


It's always struck me as odd that anyone would *ever* choose FP, 
assuming they want correct results. :-)

its a question of speed...

display and value are two different things.  I understand the need 
for scientific notation to represent the value, only that there are 
no easy ways within core to deal and show the result below at a given 
decimal point without having to convert it to a string and always 
check the scientific notation in uneeded cases.

how much time to get a gui in rebol3 linux and other ?

rebol3 gui for windows is not yet finished !!!! could we have an 
upgrade of gui demo ?

I wouldn't rely on any kind of Gui expectations for a while in R3. 
 AFAIK, a lot to do still.

but i read in rebol.com that a gui for rebol chat will be proposed 
!!! normaly in february 2009 "Resume work on the R3 GUI. The primary 
focus needs to be on styles for lists and tables." (carryover)."

and for MARCH 20009 "The R3 GUI has been running for several months, 
but it needs a few more key components. For example, we can ask why 
the new DevBase (RebDev chat) runs in the console, not in the GUI. 
The reason is simple: the GUI does not yet have an efficient table 
display style. So, although it does have dozens of other widgets, 
a way to display and scroll large message lists is really the key 
here. I will be happy if this can be accomplished this month, and 
we can begin using the R3 GUI for an actual application."

in April Gui must wait for decode and encode for image support !!!!

focus changed to plugins AFAIK, since that will allow Other people 
to start working on tools for REBOL 3 while Carl addresses the core 
stuff.  

I, for one, will start porting OpenGL natively to REBOL, once the 
plugin architecture is functional.

a native port of image magic would also allow rebol to load/save 
a few hundred different file formats directly... even some movie 
formats are supported.

now this done - that why i ask for an upgrade of gui-load and demo 
and to do it also for other version like linux.

image magic also supports floating point image manipulation and has 
a lot of built-in high-quality filters (real time 200 pixel gaussian 
blur anyone ? :-) and more than 10 image filtering functions IIRC.

oki we will wait for it -   thank you

I guess once the plugin architecture is done, the GUI will get priority 
again.

Next time the GUI will be touched, will be a redesign of the layout 
engine, which performs poorly right now.

Then style development will continue, hopefully sometime in July 
or August depending on the GUI situation.

might want to get me in the loop when that happens (layout work)... 
by then I should be delving into R3, so I'd be able to contribute 
experience... not just theory ;-) ... 

I've been designing and evaluating many (I mean dozens) of auto layout 
engines thru the years...

The layout engine specs are already in place, just need them to be 
implemented.

a general question for those of you actively testing using REBOL3. 
 Is it stable, a part from the known bugs or function differences.... 


Once a rebol3 source works... can it be expected to run for a long 
time or are there still many internal bugs which will inevitably 
cause the app to crash (gc instability for example).

I don't think there are many known GC bugs. The largest scripts run 
yet are those of VID3.4 (around 50-100 kb) and they are fairly stable. 
No leaks have been found yet, but we aren't yet looking very hard 
for those.

Isn't R3 chat server running on R3?

yeah... but its close to god so does that count ?  ;-)

The problem is that most of the code written in R3 has been written 
by people who have a good idea of the internals, who know what is 
optimal and what is not. This means that the code tends to more heavily 
represent good code techniques and practices - thus, those code patterns 
are more thoroughly tested and stable. What hasn't been as tested 
as much is bad or erroneous code: Some of that can still crash R3 
at this point.


Fortunately, new users have been joining the fray, and many of them 
are not aware of the internals or best practices. Or in Ladislav's 
case, exhaustively thorough in their testing coverage. Because of 
this R3 is much more stable than it was a month ago :)

If you search curecode.org for [gc] or [garbage collection[ there 
are very few bug reports.

Maybe it is time for someone to step up and try some serious stress 
tests.

hehehe  I think I`m going to give A56 a real run for its money  :-)

Go for it, Maxim!

I'm going to try to port liquid to R3 tonight.... just for fun.

I'll be using modules if possible.   an earlier version of R3 just 
crashed when trying to allocate a single node... we'll see.

is there a page which explains various optimisations one can do to 
R2 code to allow it to take advantage of newer and faster functions 
in R3?

Maxim, try to look through the cookbooks section in the wiki at http://rebol.net/wiki/Cookbooks

There are a few things. Not much yet.

I tried porting one small script (not even an application) earlier 
today.
Good news -- it worked in most cases.

Bad news -- some of the sanity validations failed because the nature 
of strings have changed.


Lots of R3 is native where R2 was mezz......That often speeds things 
up.