AltME groups: search

To the tune of "Battle Hymn of the Republic".. 

So, it has come time for us to shift into high gear. It's time to 
unite our community, power up the REBOL 3.0 laser, and burn a hole 
in those weaker approaches. It's time to lead the way. The REBOL 
way. Vive la REBOLution!

And here I thought you guys only had time for Rebol ;)

Louis, if you use now/precise instead of now/time/precise, and then 
difference end-time start-time instead of end-time - start-time, 
it will also work across midnight.

What's the less time interval you can get? I have record 0:00:00.031:-)

It's harvest time in Ukiah.

Well, all styles which use scroller obviously inherit the behaviour. 
I just tested my scroll-area and scroll-table styles (- it's so cool. 
I didn't think it would have this effect on me after all this time.)

Brock, yes, however it will be a while before I will have time to 
work on it.

liquid makes the real time management of this easier, because of 
all of the implicit processing going on.. but the actual technology 
behind it is quite sneaky  ;-)

not even  :-)  that would make it less than real time.

ok i ll be there ... if any need for beta testers i m ok, i got time

I don't think the gradient is a problem. There was a time when I 
shunned the extra complication.

Ok, TOOLBAR is based on VID-FACE, so let's first check if it has 
a words dialect.
	>> print mold svv/vid-styles/face/words
	none
Good, so we can set our own without breaking anything.
	toolbar: FACE with [
		; define DATA function in the style-specific dialect

  words: compose [data (func [new args][new/data: args/2 next args])]
	]

All this does is allow a slightly easier spec. Your example from 
the blog:
	view layout [button-bar with [data: [ok-btn cancel-btn]]] 
can now be:
	view layout [button-bar data:[ok-btn cancel-btn]]

Ok, it doesn't save you much in this one example, but over time, 
it will.

Ah. Thanks.

Too much communication channel to check, I have dropped ML a long 
time ago.

Did you do that ?

I had an attempt to do one, in the time where it was lived in Rebol.net 
as HTML. But parsing HTML is not funny, so drop it without going 
too far.

Haven't spent much time, but not even close so far. My brain messes 
with the key mapping, which I guess is part of the point.

ICarii: Rebtower is eating 100% CPU while waiting for player's actions 
(WinXP). Is this a time-limit game feature : beat your opponent before 
your CPU melts ? ;-)

The fix is working well. Time to wipe out that tower masking my view 
of the mountains ! ;-)

It's not, but most of the time (at least, here in France), corporates 
allow only HTTP/HTTPs traffic (and sometimes FTP).

Thanks. Just one chapter to go. I hope that it can be published in 
two to three weeks time (the basic translation is finished but needs 
editing).. The complete book should be ready about three to four 
weeks after that.

I haven't got a physical copy of the book yet, they take a long time 
to get ot my part of the workd.. I have a copy of another booked 
printed by Lulu.com, the binding seems no different from most books 
oyu buy in a bookstore. 

Does anybody else have any experience with Lulu.com books?

yep... all done, simple but gives an initial idea.  I am just finishing 
the module download requestors part and it will be online in very 
short time. (under an hour)

I have grown elixir to 6000 nodes.  and it was still reacting in 
real time with less than 100 of ram useage... most of which is gfx 
data from the AGG gui.

Time's up MAx ;-)

3:49 am completion time in Montreal.  I guess the kids kept you busy 
during the day, and you got on a roll during the night.  Good stuff 
Max.

I will publish at some time... earlier if someone is interested.

;-- working example
lay: layout [
	size 500x200
	button "Change Title" [
		lay/text: join "Time: " now
		lay/changes: 'text
		show lay
	]
]

view lay

Does anyone here use later betas on an ongoing basis

 REBOL/View 1.2.10.3.1 30-May-2003, as it's a good match for the latest 
 [working] SDK  (REBOL/Encap 1.2.0.3.1). It is frustrating how REBOL 
 has become more and more "write once, test everywhere" over time 
 - hopefully /Platform will provide a unified base so we don't have 
 as many of these "which version(s) of View does this work" on type 
 issues in the future.

By the way, the words in a face object are not "facets", as I fell 
into believing some time ago. Facets are a style's dialect words 
which follow the style word in the layout block. eg. layout [BUTTON 
"hello" red [print "pressed"] ]    BUTTON is the style word, the 
rest that follow are the facets. These may or may not translate nicely 
into attributes in the new face object created for this button. A 
single facet could affect several attributes inside the button face.

for the CHANGES facet, there is the TEXT flag too. It's for changing 
a window title without unview-ing the window. ie (from %analog-clock.r):
l/text: mold now/time 
l/changes: 'text 
show l

Vincent I yet do it on resize event completion but it's during the 
completion of the resize event I need to have the refreshing to polish 
the UI eatch time the mouse pointeur is moved ..

VID is great for prototyping, and for apps where saving a little 
memory and speed aren't critical. So, I think VID is still a valid 
prototyping tool because you don't know what you want to build the 
first time out (in many cases) and it allows you to play around more, 
with less effort. Now, there's no good reason you couldn't use the 
VID dialect, limit yourself to what REBGui can do, and use the VID 
spec to generate REBGui code. Best of both worlds.

Hello, Long time no talk. Is there a way to tell the request-file 
to open up in a specific directory?

I have a text-list in a layout and I have a simple log-function:
log: func [message [string! block!]][
	append log-list/data rejoin [now/date "/" now/time " " message]
	show log-list
]

If MESSAGE is longer than the width of the text-list MESSAGE isn't 
shown. Why this? The first two parts NOW/DATE and NOW/TIME are shown.

is was searching for that one for a long time...

Or do i need to create an event per face ? actualy i want to Roam 
over the main face an select the face i am moving over ta that time...uable 
to comply  currently ;-)

has anyone already submitted bug to RAMBO, where View apps crash 
each time you change your desktop resolution?

I can see that Gateway demo took time ...

Actually, Gateway demo GUI took no time at all.

If an editor lags all the time, just by typing simple code, it almost 
makes me knock the monitor off the table

personally I would prefer the AGG doc to be release in the mean time 
of the VM.

fovsz: 450x450

layout compose [starfield: image (fovsz) black]

starfield: to-image starfield

loop 1000 [
	col: random 255
	starcol: to-tuple reduce [col col col]
	poke starfield random fovsz/x * fovsz/y starcol
]

view/new layout compose [
	b: image starfield
]

hvector: func [x y v][

 (fovsz/x / fov) * (fov / 2 + either zero? pos/2 - y [90][arctangent 
 (pos/1 - x) / (pos/2 - y)])
]

vvector: func [y z v][

 (fovsz/y / fov) * (fov / 4 + either zero? pos/2 - y [90][arctangent 
 (pos/3 - z) / (pos/2 - y)])
]

map: [
	"A New Beginning"
	""
	"Rebol HQ, led by their jedi leader,"
	"Carl Sassenrath, has begun"
	"preparations to strike back against"
	"Darth Gates at the Redmond system"
	"during a time of growing unrest"
	"among the netizens of the Empire."
	""
	"As the Empire works to complete"
	"construction of their hailed"
	"planetary domination device, code"
	{named "Longhorn Death Star", small}
	"centers of resistance continue to"
	"gain support among the"
	"oppressed masses."
	""
	"Even with mounting support, only"
	"One is powerful enough to overcome"
	"the dark side of the Force --"
	""
	"Rebol/View 1.3"
]

mapimg: copy []

foreach line map [

 b1: layout/origin compose/deep [text (line) 840 center font-size 
 48 sky black (either any [line = map/1 line = last map]['bold][])] 
 0x0
	append mapimg to-image b1
]

pos: [0 30 20]
dir: [0 0]

fov: 45

for l pos/2 200 .1 [
	agg: copy []
	x: 0 y: 0
	foreach item mapimg [
		y: y + 5
		if y < pos/2 [
			append agg compose [
				image (item)
				(to-pair reduce [hvector x + 15 y dir/1 vvector y 0 dir/2])
				(to-pair reduce [hvector x - 15 y dir/1 vvector y 0 dir/2])

    (to-pair reduce [hvector x - 15 y + 5 dir/1 vvector y + 5 0 dir/2])

    (to-pair reduce [hvector x + 15 y + 5 dir/1 vvector y + 5 0 dir/2])
				black
			]
		]
	]
	b/effect: compose/deep [draw [(agg)]]

	show b

	pos/2: l
]

Bo, I sent you a version which updates on time events.

I'm still waiting dor an answer to my matrix problem ... In the mean 
time I rewriting the whole code to make it recusrsif ans easier to 
understand and upgrade

Cyphre Great !!!! I'm happy to have found a difficult bug regarding 
MATRIX in AGG/DRAW :) I hope this will be solved as soon as possible. 
I all cases tahnk you to have take the time to scout my problems 
:)

It's 1:04AM here, not a time for serious work, so I'm fiddling little 
bit with some eye-candies in new DRAW and I must say it's SO powerful. 
I'm just starting to see the potential...whooo! Thanks

I found it being really excellent ... but - it is based upon old-good 
'parse itself of course :-) anyway - way much more usefull than xml-parse, 
which is imo absolutly insufficient for real work - but it is long 
time I looked into it ...

Okay! :-) I'll contact you privately. I got some questions, if you 
have a little time.

Regarding the gradients: Thanks for the examples. Anyway, I've already 
known that you are missing the gradient color ratios so it is just 
a matter of time and priorities when this will be added so please 
be patient ;-)

direct rendering modes were promissed some time ago, who knows when 
we get those :-)

it's probably depending on the graphics driver, but it doesn't really 
matter what I do, whether its rebcode, AGG or VID, things slow down 
to a crawl when going full screen. I did some time profiling which 
showed that SHOW takes up probably more than 75-90% of a drawing 
cycle, much depending on resolution. removing that obstacle or making 
SHOW more intelligent will speed animation up a lot.

Ask your leader to leave you some time to play outside the task. 
;-)

Most of the time that info is put in a ReadMe file or an About dialog, 
but since View has that info online, online docs are where it needs 
to be. And the online docs related to Draw do mention AGG (I think). 
That clause is less restrictive than you think.

The following code demonstrates this. Comment / uncomment the draw 
effect line to see the difference a simple draw command makes.

count: 100

do-test: func [label info /local img-size start end] [
	img-size: to-pair label/text
	img: to image! layout [

  origin 0 box img-size blue reform ["Testing" img-size ". . ."] font 
  [size: 24]
	]
	view/new/options center-face layout [
		origin 0 i: image img img/size
		;effect [draw [circle 100x100 100]]
	] [no-title no-border]
	;	test loop
	start: now/time/precise
	loop count [show i]
	end: now/time/precise
	;	display result
	info/text: form to-integer count / (to-decimal end - start)
	show info
	unview
]

view layout [
	title "Resolutions"
	across la: label 100 "800x600" ia: info 100 center
	return lb: label 100 "1024x768" ib: info 100 center
	return lc: label 100 "1280x1024" ic: info 100 center
	return btn "Run" [do-test la ia do-test lb ib do-test lc ic]
]

Shadwolf -> Drunk Coder .....  hum not all the  time but this time 
yes  ..

i have looked long time ago at rebconsole code ... but without understanding 
it mutch ...

If you don't need it in realtime the why not ;) Those HQ filters 
are much more time consuming.

a workaround is to blur the image a few times before scaling it down. 
A little time consuming, but if you need HQ thumbnails right now... 
:-)

Then we need an action-script-<rebol converter. Which is javascript 
at the same time. And thanks to google we can then run java in rebol. 
hehe :)

Cyphre - can you talk about new View internals? Gabriele sheds some 
light on some topics here from time to time, but very little was 
said about View. The only thing we know from blog is, that even system 
was replaced ....

Nick, it's exactly what's supposed to be there :) It's a personal 
server and has no main page. There's only a picture that cahnges 
from time to time.

I have another site where I can host it, but not so much time to 
move it now.

Unfortunately at this moment I don't have much free time available. 
It depends when you would like it to happen.

I don't have much time for my /flash dialect itself. And there is 
still many things to improve.

The site is outdated for a long time... I had not time to make any 
docs and don't have it now as well.. I hope I will have some this 
year :/
But you I can build the above example with this version:

>> do http://rebol.desajn.net/rswf_latest.r

>> make-swf http://box.lebeda.ws/~hmm/rswf/examples/swf4/swf-button.rswf
== #{
46575304AC01000070000C80000096000028010043026400003F0C0E00000001
00100005417269616C000002007F09220000000200680011300000B4000D...

Ah, what wonders a few hours of rest can work.  I just need to produce 
a plug that takes a series of inputs and converts it into an object. 
 I was overcomplicating things (again...)  When I get back from work 
I'll take another shot at it and this time I think I'll go with a 
dialected approach.

pekr:  yes using liquid interactively is one of its mandates.  the 
liquid editor, will be used in this way, changes will be viewable 
in real-time, so the first set of nodes that are going to be integreated 
are globs, which allows a graphic package to be built within a day.

Liquid rocks!  I'm getting very close to my goal here and when I 
run into a bug 90% of the time it's because I didn't plug everything 
together properly.  It's pretty sweet.

I turn round and round and wonder why nothing is being printed on 
the console...  then after a very long time... hehe I realised I 
never asked it to perform its  task... hahaha

it already is  :-)  its run-time switcheable... and its how I always 
find my stuff.  its even indented

also note that it was the first time I tried to do this using liquid. 
 its not like an old code sample I refurbished...

I also use liquid to build vast networks of AGG graphics for real-time 
interface creation... we are talking several thousand lines of AGG 
commands.

btw, the reason liquid-vid is taking some time, is that the whole 
layout is built using dataflow !  :-)

I looked at it a long time ago, but realised that its basically easier 
to start from scratch... cause if you remove the processing aspect 
of nano-sheets... there's not much left.

also, liquid-vid project has been dropped, officialy, in favor of 
putting time on GLASS and GLOB v2 instead.

most of the time was spent with non liquid related things... like 
vid.

most of the time will be spent by me cursing after view trying to 
get the list to work.

we have tried to run liquid within R3 an it crashes rebol...  but 
I didn't have time to figure out why, its a pretty complex object. 
 but I will have to look at in sometime this summer... the simple 
10X speed gain of AGG is enough to make it worth, especially since 
gobs provide internally of what paint simulates in R2.

now if Carl is interested in working with me on making this a reality, 
I will definitely give some time to the effort.  even if we only 
use liquid for some part of VID it would make a lot of stufff SOOOO 
much simpler to write afterwards in application, and lazy programming 
really pays off in terms of economies of processing.  in my application, 
rendering 1 graphic or 100 cause no more processing in most circumstances! 
 only the AGG aspect of things slow down.

liquid is so low-level, that it could replace the basic datatypes 
themselves, I we could code accessors like in python.  using python, 
I can build a liquid which replaces the core datatypes and makes 
it completely invisible.  this is not possible in R2 and I'm not 
sure accessors will be as open as they could in R3, time will tell... 
 at least brian seems to be on the same page as me wrt this.

The engine will use liquid's flexible interpreted messaging overlayed 
on the other graph engine which I will use for scalability in sheer 
volume of connections and nodes I can allocate.  just a portion of 
the tree usually needs to be in RAM at any given time, and in fact, 
parts of processing tree can now reside on different computers since 
the graph engine is refered to... it should be quite fun to use.


this will be tied in to the OpenGL and scream core scene-description 
engine as one cohesive toolset.


in this system, the binary nodes will actually be optional and should 
be invisible when used from the rebol application's point of view.

Well, I would need to be able to work on more than one project at 
the same time so I can copy tickets that apply to more than one product, 
like R2 and R3. The advantage for using CureCode would hopefully 
be to reduce work.

the use of the external tables can probably be replaced by some SQL, 
but for some reason I find it simpler to let mysql handle autoincrementing 
and retreiving last insert id, it seems easier to support when many 
threads are inserting at the same time on the same table.

I think a new bug type or severity which indicates a ticket being 
reference for documentation could be usefull.  some tickets start 
out as bugs and become examples of use or help in detailing non-obvious 
cases of some features.


setting a ticket as dismissed and not a bug, clearly means that it 
will be ignored in the long run, and rememebering what tickets are 
usefull and can be included in reference documentation when such 
a time occurs would be usefull... it could even allow us to search 
the bug database directly for strange reactions we might consider 
bugs but were pointed out as features or gotchas.


the "not a bug" severity  is similar, but doesn't relate if the post 
is usefull or not.


bug#928 is an example where this could be applied.  I am sure there 
are others.

I miss very simple graph on the main page, exactly the one showing 
what RT's blog shows - showing completed, opened and waiting tickets. 
Current graphs are nice, but it takes longer time for me to understand 
it. E.g. why are not dismissed tickets part of completed tickets? 
I know that it would mean double categorisation, but then I propose 
dividing table into 3 sections, waiting, opened, closed, or at least 
two sections - opened, closed ... and part of the closed would be 
- complete, dismissed, tested, and their subtotal. What do you think?

Thanks to the new CSS, the look is now consistent across Chrome / 
FF / IE7, but I gave up on trying to hack the CSS to make IE8 render 
pages as the others. The time spent in making all browser render 
the same way is quite insane.

I didn't had the time yet to update the picture.

the captcha appears not to be working, but there is no DRAW error 
this time.

Try with an absolute path for root-dir. I remember having hit the 
same issue once a long time ago, but can't remember the fix.

BTW, I spotted another error with the captcha:

URL  = /bugs/captcha.rsp
        File = /home/henrikmk/serve/www/bugs/captcha.rsp

        ** Access Error : Port none not open
        ** Where: confirm
        ** Near:  [save/png img: make binary! 25000]


At that time I noticed the image was not displayed in the browser, 
but it only happened once.

no difference. it still reports tcp error. it must be coming some 
time before that function.

I had a lot of trouble with comments in CureCode today being hex-decoded, 
when I was just trying to refer to a filename %bar.r. I had to write 
it as %25bar.r, every time, even during revisions. Comments shouldn't 
be hex-decoded.

Looks like Cheyenne is trying to create a new form of ASCII art :-). 
First time I see that on Cheyenne. Will reset the server at once.

seems there is a copy "" missing somewhere... I could see the last 
page viewed on cheyenne.org just above the curecode page last time 
I visited it.

Upgrading also PHP to v5.2.11 on the same server...takes a bit more 
time.

It's amazing how much time it takes to compile PHP...

The gap between CureCode and solutions like Remedy is huge in terms 
of features. Trying to compete with them would require a large funding 
and a lot of time that I both lack.

There was several accounts not activated, I've switched them all 
on. I guess that the activation email didn't make it (using an old 
extension of SEND mezz command). It's time to upgrade CC to the new 
builtin email support API and MTA...

Doc, we'll need a RAMBO migration to a new CureCode project some 
time next month, after the new R2 release. Open tickets only should 
be fine. Afaict we won't need to delay the first R2 release until 
the migration happens. The first release should be emergencies (like 
installation) and low-hanging fruit only.

Didn't have time yet to upgrade CC for that. I'm planning to do that 
this week with other improvements to CC.