AltME groups: search

Well, a GUI a nice, but the working out network details seems a little 
more basic :)

The source is there already in case you need to use it before the 
next version comes out. The R3 version is:
move: func [
	"Move a value or span of values in a series."
	source [series!] "Source series"
	offset [integer!] "Offset to move by, or index to move to"
	/part "Move part of a series"
	length [integer!] "The length of the part to move"

 /skip "Treat the series as records of fixed size" ;; SKIP redefined
	size [integer!] "Size of each record"

 /to "Move to an index relative to the head of the series" ;; TO redefined
][
	unless length [length: 1]
	if skip [
		if 1 > size [cause-error 'script 'out-of-range size]
		offset: either to [offset - 1 * size + 1] [offset * size]
		length: length * size
	]
	part: take/part source length
	insert either to [at head source offset] [
		system/contexts/exports/skip source offset
	] part
]

I have meet ROBERT a couple of years ago and his work is pulling 
string to people. He is paid for this and seems to be very good in 
this role. Companies pay a lot of money to Robert and we have his 
work here for free. (Note: also other people here are working for 
free).

Graphics extension loads:

http://rebol.hmkdesign.dk/files/r3/gui/217.png

List of graphics functions:

http://rebol.hmkdesign.dk/files/r3/gui/218.png


There was a small demo to display a random collection of gobs, but 
a bug in the host kit prevents me from taking a screenshot.

I've found that VirtualBox is a really bad testing platform. It slows 
down in places by a factor of at least 10, so I can't do any benchmarks.

btw - will DELECT still remain? New COMMAND type seems to remove 
the ability to have random order of parameters. And quite honestly 
- I don't like it. It might be good for very fast low level engines, 
where speed matters, but I still want the flexibility of random parameters. 
So - will DELECT remain for dielact builders, or will we have to 
fall-back to full parse in such a case?

DELECT could be used to convert a dialect block with unordered and/or 
parameters to commands into a command block with ordered, mandatory 
arguments. It does it already; all that would be necessary is to 
have if generate its results in a flat block rather than nested blocks. 
There would be no need to remove it - just change the output format.

IMO it's more critical to use to get a good GUI up & running with 
a broad set of styles.


I agree Robert. Even if the set of styles is not broad, if we have 
a few good examples of how to write styles (and maybe some docs, 
which I am willing to help with), we can turn the community loose.

We should also have a list of styles, and if a core GUI team member 
sketched out rough designs or inheritance/composition thoughts and 
prototypes, we stand a better chance of our work being used.

And, at this time I will drive it cooridnated with everyone wanting 
to help via a SCRUM process.

And, I'm pretty sure it takes a couple of months and all the baseline 
stuff is lighyears ahead.

Is that not the time to reveal some sources. I'll like to have a 
look.

Sounds like the latest hostkit is just a few months away from release.

You want to be acclimatised and not get a sudden culture shock!

why ? Is that a secret ?

Is there a suite of tests for Database protocols ?  I presume there 
was something for R2 ... can RT release those so we can use for testing?

note to Carl .. add a tweet button on Altme

There are still some questions to answer and quite a lot of little 
things to do. But IMO it's a big step ahead that the host-kit now 
builds.

Internal release made of hostkit for A99. Still some work to do before 
a public release can be made.

one trivial but important question: 


OK rebol is a programing language that get most of its interest when 
used in the internet area.

So for example i use my brand new software made in rebol  it connects 
to internet and check for version update.

Updating a software from the software itself is a common feature 
now in day.


But with rebol how do we do that mechanics ? ok i can log to the 
webserver where are stored the release i can do a CRC comparasoin 
betwin 

my software and the  one on the distant server repository. So i get 
to know if the repository is different from the version installed 
on my computer.

Once my local copy is aware the distant repository evolved i can 
download the new copy.

And that's where the poblems appears ... I can't make the new version 
downloaded from the server to be subtituated like all the other software 

made in c, C++ etc... does. What i mean is i can do 97% of the update 
from the webtask but the automatic stop the current app and launch 
the new version is 
not possible...


if you want to better understand what i mean think about your firefox 
update for example

 at your firefox start it performs a version check then download the 
 new version
then close the current running firefox and launch the new one.

Does rebol 3 will introduce that kind of mecanics ?

in fact that i current software download the new version install 
software then starts the new version install software and curent 
version is terminated  install software then doeas the substitution 
process then starts the new software version.


But this means the software can launch a sub process which will not 
be terminated when the current process is terminated with an quit 
call for example.

and since rebol script are  most of the time very tiny in size  i 
don't see the interest of having an updated scheme looking like what 
is done on the other laguages. I htink it should be a cool thing 
to be able somehow to substitute anytime the file on my computer 
and then  autoreload it in memory without having to restart the application 
and if i could trash out  from memory of the VM the previous script 
that wuld be even nicer ....

Script autoreloading is not a simple task because scripts are primarily 
run to cause side-effects, even if those side effects are only in 
memory sometimes. So reloading a script means upgrading a script. 
The R3 module system was designed to allow modules to be upgraded 
in place, by making the previous module state available to the initialization 
block of the new module. This allows the new module to migrate the 
data of its old version.

Be careful though, you have to design your modules for this on purpose, 
you can't just count on it happening automatically. Module state 
migration is not difficult, but it is a different process every time 
since it depends on what state you need to migrate. The R3 module 
system can make it possible, but your module needs to do the actual 
work.

yeah in fact i could do this check the version then download the 
new version from server maning the file .TMP then create from my 
script a install-app.r  and call it then close the current app

and have that temporary script install-app.r to rename the .TMP file 
to my main script and then start the app. It could display popup 
message like "Configuring the new version please be patient..."

but it's lot of work for a thing i will be the only one to use ... 
and that's not the meaning of my ask ...

There is a solution using RENAME, at least I think that a version 
using RENAME works, did you try it?

the function doing update could work as follows:

update: func [
    {updates the current application}
    application-file [file!] {the current application}
    tmp-file [file!] {a temporary file}
    source {updates from this source}
] [
    if exists? tmp-file [delete tmp-file]

    ; now we can rename the application-file, since the tmp-file does 
    not exist

    rename application-file tmp-file ; I guess, that this works, even 
    if the application is running?
    write/binary application-file read/binary source
    call application-file
    quit
]

renaming won't work if there is a file lock on it

So, the point is that you can't delete the running binary, and you 
can't delete it even if you rename it first, but you can rename and 
write a new binary in its place

just noted that rebol3 conversion to binary! always results in a 
network byte order (big endian) binary!, irrespective of host endianness; 
which is nice

and a round/half-ceiling is not good ?

Currently, I think for sizing we must define and document it.  To 
me, there is no perfect answer, but perhaps just doing a simple round 
is best, as long as everyone knows that rule.

if I'm forced to use rounding on the rebol side very often, I think 
I'd rather have a tiny overhead in the native datatype that tries 
to stay integer until a result forces it. 

exactly like integer math which returns decimals when it must:

>> 4 / 2
== 2
>> 4 / 2.0
== 2.0
>>

and a new float-pair! datatype is complicated to support in addition 
to an integer pair?

it would really be nice if the datatype had a little state which 
allowed it to be integer or float and call appropriate math based 
on this... 

but I have no idea how this math is managed internally, so cannot 
easily grasp how complex or how this would affect speed.

perhaps just doing a simple round is best, as long as everyone knows 
that rule.


That sounds good to me. The ky point being that we know the rules. 
Simple ROUND may not be the best choice for graphics, but I'll defer 
to those with more experience in that area.

Update: The go.r test code is now running properly in A101 with the 
fully converted PAIR datatype and changes to the AGG API to accept 
both pairs and gobs using float values.


It turns out that because AGG wants floats for most spatial values 
anyway, the PAIR change makes the code smaller and faster.


Certainly more can be done to minimize the interface to AGG now (removing 
the double trampoline within the API) but that's a project for Cyphre 
when he returns from the islands ;)

For example, a pair may have a value that is *almost* zero, but not 
*really* zero.  "You know the drill."

Thanks Carl.
Though for AGG, I don't expect a lot (in term of speed gain).

IMHO, the main overhead comes from the involved arithmetic using 
floating point decimals.
Matrix computations are costly with floating numbers.

But The final rasterization uses fixed point decimals and floats 
could have been avoided, i guess.
So maybe there is a major room improvement here.

Carl you have a point there ... pair! are used mostly related to 
VID ....  and as pairs in fact represents a pixel matrix you have 
dot something  numbers

CARL ONE ASK CAN AGG   BE MERGED WITH AMD/ATI OPEN CL Technology 
? ( some thing like a background application that would detect what 
hardware you have and use multi hardware CPUs GPUs to run those expensive 
task. Once again  what in rebol can be an very expensive task .... 
answer a state of art webbrowser rendering engine with flash silverlight 
support....  IF we can bring rebol to that state i think no one will 
look at it as a toy ... then the question is way doing a webbrowser 
in rebol ?  REply is because i love rebol :). But on a ground level 
if you want to enter in competition with the other languages and 
prove the interrest of the rebol method then you have to be able 
to do what the others can do )


This open CL adition can too benefits non graphical applications 
i don't know how but  why not saying look rbeol is not dead it's 
the futur and as the futur it provides the best way to use the futurs 
technology. And that's a field none of hte interpreted languages 
now in day have done ...

Steeve Matrix are costly in computations only if you do it with a 
CPU not designed on purpose to do those kind of tasks.... But with 
a GPU it's EASY CAKE ...Question is can we be hardware ignorant or 
not ?

graham i can use a software grow lens  too  .... BUT the better way 
is to have the font in 14 px like in any civilised software :)

since then a lot have been done altme could use a agg rendering method 
insteas of a VID face concatenation etc...

viva-rebol.r is a R2 project isn't it?

when you have a rebol 2005 below alte me the message is  ---> ALTME 
wasn't enhanced since at least 5 years i'm a very buzy man and anyway 
i don't give a damn if people use it or not ...

graham yes but viva-rebol would be such a nice kid with his brand 
new open CL powers :)

Altme has been enhanced a few times recently

i see what a pixel is  i don't see what half a pixel could be ... 
and the reason is be able to see  those half pixels i would need 
a screen that can display when and eyes that can render them to my 
brain wich will never ever be the case in this life ... So personnally 
Carl i wouldn't be sad is matrix are rounded.

CPU are not feated with matrix computations because the industry 
decided that matrix area was such a big thing that they needed a 
spécific library and a specific hadware extensivly optimised to perform 
those computations. and so the GPU accellerated enhanced for opengl 
and DirectX is born.... Now in day the industry use most likely the 
DirectX because  well 90% of the personal computers are windows and 
that 100% of them support DX so 100% of the sold PC games are done 
that way... And that allow to cut cost when another company like 
unreal tech for example make a game engine you buy it and you save 
alot of time and monney the only thing you will have to do then is 
to create the specific IHM for your game and all the visual /audio 
content. then your project  time spent is shorted by 2 or 3 years...

AGG is not the best place to put OpenCL support. OpenCL is not very 
useful for accelerating graphics, and that is what AGG would need. 
A standalone OpenCL dialect would be more useful. Graphics acceleration 
uses other APIs, like OpenGL or Direct2D. AGG isn't 3D, so using 
OpenGL or Direct3D would be equivalent to reimplementing Direct2D 
on platforms that don't support it.

Brianh hum actually when i we display things using agg the cu is 
used only and if we want to do extensive computing visual effects 
like zoom spining things etc ... hten the cpu will be extensively 
used ... and since rebol doesn"t take advantage of  multi CPU  or 
CPU <- to ->GPU communication then the extensive computation loops 
are not enhanced. Problem is now in day NVIDIA is so expensiv no 
one buy it  10 ATi cards are sold for 1 nvidia card and in a very 
near future AMD CPU will be mixed with ATI GPU  into a single chip 
(APU fusion). This is the tendency of the computing area so if you 
have to support 1 paralelle design i would go for the AMD /ATI  couple 
instead of  betting on a close to death horse...

As for seeing a partial pixel, the writer of AGG demonstrated (in 
an unrelated post) using anti-aliasing to do 1/256 horizontal pixel 
positioning.

but yes brianh you got the point when you relay on hardware then 
you have to choose what technology you support i know rebol main 
target is to be hardware / OS / driver abstracted .. but then you 
have a toy language anyone laught about that  can't bring anyway 
the same thing on every OS computer a part some very basic features 
like networking, encryption etc...

The semantics for a GPGPU dialect in REBOL would likely be pretty 
high-level, and could be translatable to different GPUs by using 
different compiler backends. It's not necessarily a good idea to 
bet it all on one horse when you can support them all just by being 
a bit general. We wouldn't have to do major tweaking for a specific 
GPU architecture, since the level of speedup would be great for even 
a half-assed translation.

It's not a toy language, it's a high-level language. The compiler 
would handle the details. That is like calling C a toy language.

BrianH probleme is  rebol doesn"t tends to relay on a spécific thing 
or another it's phylosophy is to be an easy way to do easyly easy 
things ... when you want to get your self out of that scope you are 
 facing hella difficulties  why should i code 99% of a project in 
C and then do a  dialect to do the last 1% of rebol action code

that's only usefull if your are sure this extension will be extensively 
used. What interrest me is doing rebol and ways to bring into rebol 
the now in day possibilities .. remember that rebol was designed 
around 1998 at that time processors where mono cores GPU  where a 
joke.(GPU 100MHz with 64Mo do GRAM and CPU 433Mhz SDRAM 133 MHz)

One of the things that the modern multi-core language research has 
discovered is that shared-memory multithreading is often a bad idea, 
and that multiprocessing with asynchronous IPC is more reliable and 
scales better. And cooincidently enough, multiprocessing is the method 
REBOL uses. Now all we have to do is get the processes smaller and 
the IPC (/Services) more efficient.

i think now in day hardware capabilities are introducing alot of 
 problems in software parallelisation strategies (wich had been always 
the case) that's a field i think rebol should explore and propose 
it's originality  to solve that increasing difficulty.

hum yeah but that  solution apears to the rest of the world like 
a joke .. face it ... we are less than a thousand people really caring 
about rebol's futur ...

The strength that REBOL has is that it is relatively easy to create 
a dialect with different semantics, because we have so many good 
tools to help with the implementation, more all the time. So REBOL 
becomes a good platform on which to do those experiments. And we 
always have the old-school single-process DO dialect to fall back 
on.

try to talk asynchronous processing with a guy doing java threads 
programing all day long that's interesting ...

Yeah, we could probably boost all view stuffs by isolating the rendering 
engine in a distinct process.

asynchronous have a weak point the data flow processed should not 
be to much ..  so for example if you want to put cheyenne on his 
needs you make it relay a webradio streaming for example

Threads was considered to be the solution last decade. And that is 
why we have a multi-core crisis now, because threads are not a good 
solution. That is why the main research not is in active objects 
and green processes.

that's why intel/ nvidia  APPLE (in a lower extends all smartphone) 
and AMD/ATI are doing or announcing he merge of the Memory controller 
the CPU and the GPU  into a single unit

Um, that is not the multi-core crisis. The real crisis is that it 
is very difficult to break a program into threads, and even more 
difficult to manage shared state. This is why there are so many issues 
with locking and such.

It's a programming problem, not a hardware problem.

the A1 chip in the ipad for example already is a allin one chip  
and the preformances are better because the software is better too 
but because the hardware is specificly designed to feat it

that's a thing only a closed disgn 100% controled  like the apple 
one can offer

and yes writing programs on those computers means a specific knowledge 
.... Problem is the industry said to the code continu to code the 
way you did so fare the hardware will optimise it

Yes, but those mega-utlre computers are just a sign of where things 
are going. On the bitty computers you can still party like it's 1979, 
but on servers you are starting to see cores in the hundreds.

And only on the manyi-core computers is multitasking a real problem 
that needs new language semantics. On the old or bitty systems REBOL-as-it-is 
will do fine.

well problem is when you have several chips then you have to design 
alot of bus wich enhance alot the price of the computer imagine those 
computer have over a hundred or a thousand processor

ich individual processor is weak  but all together with a well coded 
software they are blasting

game industry is a 90 billon dollars market ...  if rebol can be 
used to solve most ot the coding problems there i would say why not 
?

I don't design hardware, I design software, or tools to build software. 
And different hardware sometimes demands different semantic constraints 
on the tools to build the software. The multi-core crisis isn't affecting 
hardware as much as it is a crisis of development tools that need 
to write software for that hardware.

ok the software can be optimised and R3 and  R2 differencies in software 
design and rendering potential already shown a big improvement

But GPGPU tools are a separate issue, really, even if they run on 
the same hardware. The workloads are semarate and have different 
semantics.

every time carl share a benchmarking with us on altme i come with 
a benchmark 70% percent (minimum) under this benchmark ... for non 
graphical computing  so this deferency exist in rebol in fact

but  when you enter the graphical area it like a normalised dimension 
where any hardware produce the same rendering

i don't even know how to use parse lol ... doing a dialect maybe 
next life ...

OK then :) It's all well and good to complain about stuff, but getting 
stuff done requires contributions, either of effort, money or in 
some cases research. If you can write a good enough spec, it makes 
it easier for someone to implement it. Short of that, it gets a little 
tiring to hear that REBOL isn't good for this or that workload, when 
it is already good for other workloads. If you think that REBOL has 
a weakness that can be resolved in some way, help resolve it. Otherwise, 
use another tool :)

For instance, I remember some guy named shadwolf helping resolve 
the lack of a rich text editor in REBOL :)

and redering a text only document is not the same as rendering a 
web page for example ... we are one step closer to that goal when 
i proposed a AGG only engine people told me it's impossible and steeve 
made that vision come true ...

Brianh you need to abstract yourself from syntax and semantic rules 
that's easy you type on your keyboard a like a drunken guy and that's 
it :)

you don't imagine all the task it takes me to do a single line of 
rebol rebol can understaand without errors :)

That is a question for Advocacy. Here, we build stuff :)

k so buld me a R3 that will make java looks like a toy thank you 
in advance ... i sware on my grave i would had it writed with  "i 
made my life a rebol" :)

be we all knows that i won"t die i will fade away progressively than 
disapear without a trace :)

Java already seems like a throwback to the last century to me, like 
a steam engine. Steam engines can still be useful at times though.

maybe a good comparation is my netbook ...  ok on my netbook i have 
3 os i have mister windows 7 starter edition  wich use so much mu 
cpu that the bettery life is cut by 2

then i have mister ubuntu netbook 10.04 wild thing animal thing dot 
thing then faster to start good perf extensible with thousand of 
applications just with a single click then i have android fast starting 
no apps and a web browser so slow that i can go take a coffee before 
the page gets full rendered. android is a close poratage without 
access to android market  so it comes wth some apps and that's all 
you can get but it boots in 5 secs ... sooooooooooo what do i use 
?

As I have shown it's fairly trivial to load up a 3D library in R3

but i want you to build me a R3 with nice graphics that are using 
lot all  my hardware   :(

hum ?? ok so i can speak here if i do an opencl extension and its 
dialect and then do the port of cheyenne to it and a demo called 
that's my web server running on my ATI 5670 ?

We have the !REBOL3 GUI and !REBOL3 Extensions groups to handle that 
request. It's a work in process. What else?

With limited man power it makes sense to work on the most blocking 
aspects of R3 development.  I don't know if anyone has created such 
a list ... and whether it would be adhered to anyway, as development 
is being driven by politics and money.

And that's not necessarily a bad thing because without money, we 
would be stuck with 0 progress.