AltME groups: search

Steve, here you can download my contribution to the Spreadsheet Contest:
http://www.rebol.cz/~cyphre/cyphres.sht
(hope I win :-))

VERY COOL, Cyphre.  That is way-out-of-the-box.

Nice Cyphre.  Imaging what it could do with AGG. The first vector 
graphic spreadsheets

your menu design is new, or Cyphre menu based?

Actually I *tried* understanding what Cyphre did, but ...

No, that's not my league, so based on Cyphre's script I tried my 
own. Actually, no single line left from the inspiration source.

ChristianE: Cyphre solved even following case - ability of menu to 
display on left or on right, depending if menu can fit the window 
or no. Ability to react for resizing (not sure about that one), but 
he used the same engine for context menu (right mouse button click). 
Otherwise - VERY good work. No problem with speed here. I will try 
tomorrow on P650, 256MB, W95 machine ...

As for resizing: I'd like to leave that untouched until some standard 
resizing schemes available for REBOL. Currently there are the two 
approaches of Romano and Cyphre, I'm a little bit in favor of Romano's 
one, but that isn't finished work, it doesn't run with newer rebols.

Context menus: The same. I'm uncertain how Cyphre's screen regions 
approach handles nested, resizable layouts ...

I by myself about 3 month later make a port of the cyphre menu for 
rebgui so we can now that AGG is officially involve Cyphre into an 
optimization process to achive in short code a as flexible and advanced 
menu in term of design ;)

DideC: look at Cyphre's styles. Simply put - are without scrollers 
does NOT make any sense from functionality pov. And why should programmer 
care about providing scrollers and doing recalculations?

The iPod would certainly get students' attention.  But the Imagination 
and Cyphre demos posted there might throw them off..

Iztaka: "Cyphre" demo is only 2kB so you cannot expect miracles. 
In more space is posible to do more things and 32kB is really HUGE 
script.  http://krutek.info/rebol/demonica-player.r

Today I had chance to show to my Lotus Notes fried small app. I took 
LN phone list, imported it into rebdb, used View 1.3 and Cyphre's 
grid and produced small cute tool ....

Two new bugs discovered originally by Cyphre posted:

	load {#object! [...]} bug

and

    VALUE? crashes the interpreter

Cyphre has noticed that too.

Cyphre said it's fixed, but not release yet (if I understand correctly)

Yes, I think I reported that bug to Cyphre during work on Compo demo. 
I hope there will be upgrade to View to fix this and other bugs, 
but I'm afraid that with R3 behind the door (you now, in just couple 
of days we're going to see the roadmap ;-), bugfixes for current 
View will be late.

Ashley - I think it is like I described it now ... Cyphre is making 
new sublay face ... and original sublay can contain xy elements, 
e.g. field with some filled-in info, so he imo iterates thru its 
pane and recreates it ....

Sounds like a good idea. Especially to better support data-form like 
GUIs. Together with Cyphre I have made such a dialect. We could take 
some ideas from it.

Benjamin -- There is no native way to change cursors in REBOL. Cyphre 
has done some experiments with it, and the APIs should be easy enough 
to call if you have /pro. Can't remember if I ever mapped those or 
not.

Hi ashley !! I see your MD2IDE it seems you have open the competition 
with my MDP-GUI hahahaha. Well I like the redering window on right 
of the Window. The bad point is that the previsualisation of the 
texte is not updated until the save action. Updating it dynamicaly 
could be a good thing. There is no button to short cut the insertion 
of the balise like in MDP GUI (feel free to retake from MDP-GUI evry 
thing you need). Personnally Im waiting for the new rebol/view version 
that will speed the drawing engine and be able to use AGG based styles 
like Cyphre showed us to do. what about integrating to your product 
MD2IDE the net releasing support (for example to update quickly a 
blog based   on carl's REBOL script)

French community is "strange" - it is very cool and active, yet it 
creates barrier for rebol adoption a bit - many of good materials 
are not in english. We help short talk about it with Cyphre - if 
rebol.cz should be czech only, or something like rebolforces, so 
in english ... (or both :-)

Final off topic;  Now I'm slowly replacing all my computer heroes...Names 
like Kernighan, Pike, Moore, Griswold, Lovelace... are now Sassenrath, 
DocKimbel, Anton, Cyphre, Graham, Maxim, Ladislav, Henrik, Oldes...et 
al.  Thanks guys.  You are making my world a better place.

i was surprised nobody was shouting for Draw/AGG ! This clearly opens 
the door to many possibilities. Cyphre, could you pls give us a brief 
update of where the project is going and your opinions on the different 
possibilities ?

Cyphre, you had posted this in REBOL/Zine 30 months ago. I imagine 
all of this is not an issue anymore, right ?

I want to thank Cyphre for all his test scripts in REBOL/View/tests/. 
Very a good good source of inspiration  and a perfect show room for 
the AGG capabilities ...

ashley: IIRC, Cyphre has a SVG parser that outputs a draw block. 
but i think it was unfinished.

Cyphre, or others - I am curious. I just read latest blogs about 
Mozilla technology - they will switch rendering to Cairo open source 
library. It will handle svg as well as the rest of rendering too. 
IIRC Cairo was already mentioned here. I wonder how AGG compares?

I see a little problem into the starwars scrolling text effect make 
by Cyphre when playing it to 1.3 the text is oriented to the left

Cyphre sure but at last you can share with us you knowledge and experience 
on the topic and this is yet a precious thing ;)

Pekr: the SVG Demo is just a quick and dirty prototype. I'm just 
going to get it to the stage where it can display simple SVG icons 
(for RebGUI). If someone else wants to write an SVG viewer that is 
fully SVG 1.1 (with 1.2 around the corner) compatible then good luck 
... I'm *not* going to be doing that! ;)


yeksoon: see above comments. I'm tweaking the SVG Demo code on an 
SVG icon by icon basis. As long as it works for the icons I use (or 
intend to use) I'm happy - I don't guarantee the code will work with 
anything other than the specific SVG files I have tested it on.


Cyphre: SVG is such a "flexible" standard isn't it? :) One question; 
how did you map SVG "path d" commands (e.g. <path style=... d="M 
10 10 C 20 20 ... z") where there is no "z" command to close the 
"shape" (i.e. the AGG shape command closes by default).


shadwolf: Having our own SVG icons is a good idea as we don't have 
to worry about licence / distribution issues and we can tweak the 
generation to make it as AGG compatible as possible. To do that we 
need to settle on *one* tool so as we generate consistent SVG code, 
and we should generate SVG that uses a single unit of measure, preferably 
pixels, as it's a real pain trying to handle multiple units of measure 
within the same file. I'll continue this discussion in the RebGUI 
group.

Cyphre, how would you achieve the same effect with a less "drastic" 
method?

ok, so I assume Cyphre is on to it already.

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 
:)

Cyphre have you an idea when the bug with matrix will be solved ?

Cyphre thank you for your answer You need more infos on Gradient 
here is the official webpage on the topic hopes it  could help you 
to make a svg gradient complying fonction in draw  ...:)

Cyphre there is no missing thing in AGG  gradient the coordinate 
datas given by SVG gradient data block is different. To make it short 
and simple SVG work with area pourcentage of filling (what ever the 
 size of the area to colorize is you will allways have red 20% blue 
40% black  40% if red blue black are your 3 colors that are used 
to make the gradient effect) Then we have a vectorial information 
that  give the orrientation of the gradient effect. SVG gradeint 
are linear, circular or parterned (in most case linear is applyed 
...). REbol AGG gradient use area offset you have a start offset 
a end offset and the  colors are degraded along this vector  nothing 
more nothing less you have no area coloring infos. This is if  my 
recalls are good the differencies betwin AGG gradient and SVG gradient.

Pekr and the solution proposed by Cyphre  was to insert to agg in 
built fonction complying with SVG datas ...

yes, that should be enoug, no? If Cyphre can use AGG internals to 
simply make it working, so he will, no?

I am not talking about adaptation in rebol level code, but directly 
in rebol AGG layer = C code - that should not be slow, no? Cyphre 
would then expose it via e.g. gradient-svg new command ...

cyphre :

here you have a tiny example of gradient representation taken from 
the webpage http://www.w3.org/TR/SVG/pservers.htmlwitch explain 
the gradient format for SVG 
Simple linear gradient commented by me  ^^
<g>
    <defs>
# LinearGradient definitions 
        <linearGradient id="MyGradient">
#first color using 5% of the space to color
            <stop offset="5%" stop-color="#F60" />
# second color using 95% of the space to color
            <stop offset="95%" stop-color="#FF6" />
     </linearGradient>
  </defs>

# HERE you have the rect definition using the LinearGradient witch 
id is MyGradient

   <rect fill="url(#MyGradient)" stroke="black" stroke-width="5" x="100" 
   y="100"  width="600" height="200" />  
</g>    

So as you can see the color pourcentages

Cyphre, do you have any news about, when we'll see your different 
fixes in a release?

Cyphre, speak, please - what cool things?

Cyphre, when you say "Rebol with Rebcode is faster", do you mean 
the AGG library?

In answer to Cyphre's question, my opinion is that changes that prevent 
(or make difficult) SVG rendering are not desirable. So if the proposed 
change(s) don't hinder SVG rendering them I'm all for them.

Cyphre question :  i think the same ..  gradient is good the way 
it is for pure draw coders (i you have to make an SVG to DRAW translator 
(my case) you only need gradients that take in charge other kind 
of values nothing more...)

Cyphre: if your question is "should we create a FILL-PEN-PERCENT 
command to not overload FILL-PEN with percent values?" I say YES. 
(but the name is here as an example)

But overwhise I don't really understand what you mean.

I think cyphre have some simple examples how to do this but... it 
should be in Rebol internally:)

Rebolek's AGG demo called "Cyphre" reminds me a bit of Tempest 2000 
- anyone planning on a Tempest 2000 clone ?? :)

iirc Cyphre said some fixes will be mady ... such features are not 
fixes though, so we can only hope ...

josh hum does it work with sp: -2 ? ( joking lol ) Cyphre thank you 
very mutch  and carl too for your hard work i'm a little far those 
last month from rebol ... but  i still have lot of  wants i will 
restart to work on the SVG rederer once all will be set /fixe if 
you have suggestions  about the svg engine make them to me i ill 
try to  add them too. ( a less 1000 lines SVG engines this will be 
very nice and flexible ...)

9-Dec 9:53 Cyphre "I'll post resume of AGG fixes/improvement very 
soon in this group so you are informed." Please, Cyphre, can you 
post it before competition's dead line so everyone can made use of 
it? :)

IIRC, when Cyphre did some game for Java enabled cell phone, he created 
small engine emulating faces

use the cookie-enabled http protocols on rebol.org (by Cyphre IIRC)

It is my pleasure to announce, that Cyphre was contracted to bring 
what I regard latest limiting factor for RebGUI database experience 
- a grid. The grid should support following features - visible/non-visible 
columns, both vertical/horizontal scrolling, keyboard support, programmable 
navigation, tri-state columns sorting, possibility to put other styles 
in cells. Expect it being in the middle of capabilities of RebGUI 
table, and Henrik's grid. The grid should be also easily portable 
to VID. The license - BSD.


Other things Cyphre will look into with regards to Rebgui is, how 
to make RebGUI a bit more pretty, centralising other things or simply 
allowing gradients for tabs etc. That is subject to change.


On non RebGUI front, we should have better sys-tray support under 
Windows, probably via .dll ....

The time-frame is three weeks from today. Stay tuned!

Very good!   Also, if Cyphre can work with us on R2 update, we can 
add those systray features native.

Cyphre: do you plan to release it in open source? Is your implementation 
client-side, server-side or both? It would be a great addition to 
Cheyenne to support SSL natively.

ok, you can get it here: https://github.com/cyphre/tls-prototype

Thanks Cyphre, _much_ appreciated.

Cyphre did one, that was quite good.

Robert problem is that Cyphre code is based on VID compositing ...

I don't know how Cyphre did it with his menu, maybe he really changed 
pop-up function, even if expensive. Once again - imo ppl can stand 
different look of UI, but not different behavior on certain platform 
- it is a big mistake to think that they can. Other thing is we don't 
have rich-text, so we can't display accelerator keys. Dunno even 
if alt key works ...

this one is perfect well my port of cyphre menu was good too ;)

I'm thinking for example of transparent popupmenu in menu style of 
Cyphre this is an other example of how we could use draw/AGG to enhance 
RebGUI global interaction

exactly ... so it must be because of Cyphre, who did not have enough 
time to produce his dream authoring tool for Rebol :-)

Ashley mentioned he has something small. And Cyphre has too, but 
commercially closed.

Cyphre can't use his code .. but that doesn't mean he can't take 
the knowledge and apply it

Pekr: I know that Cyphre has put a few large city maps into DRAW, 
and they looked pretty good. We just need to get him to tell us more 
about it.

as cyphre connect once per week it's not easy for me to advance

... simply ability to display data is essential for most apps :-) 
He tried Cyphre's grid, and although it is the most complete style 
we saw yet, it does not allow things as keyboard navigation, display 
of only selected columns without rebuilding data-block ....

From my experience with Cyphre's table style, it makes sense to use 
a name/value block for the data. With this you can throw a block 
in any order and even one, that has more fields than being displayed. 
The latter makes a lot of sense if you just want to get back an internal 
ID.

I think, that Cyphre will be able to give you an advice on that

Cyphre: "How to use AGG to forget Flash" :-)

Cyphre suggested there will be some nice announcements, but professionally 
refused to give me any hints. So I asked Carl and he told me they 
will announce some new developments, but could not say more few weeks 
ago ...

It could be probably in Rebol as well. It depends how far is Cyphre 
with the Flash plugin integration into Rebol's face and if Pekr's 
friend will give the rights for Rebol community to use it.

As Cyphre said: because dot looks more like assembler ;)

I remember some talk between Cyphre and Carl about "subpixel accuracy" 
in regards to AGG, but dunno if related. Carl was thinking if he 
should allow decimals for pairs IIRC.

As I'm interested only in pure vectors, REBOL speed is succifient 
for me :)) But yes, REBOL can probably be linked to some external 
library (as Cyphre did with OpenGL) or SDL maybe? But I don't think 
it should be high on priority list, other things are more important.

Continuing from SDK group: I noticed that cyphre thinks pixel writing 
and reading can be a bottleneck in the current rebcode implementation, 
which is why the native convolve functions in rebol/view 1.3.2 are 
much faster than the rebcode version demonstrated earlier.

By providing ways to read and write RGBA information directly without 
needing to extract and combine them first, rebcode could be faster 
at per-pixel operations.

Any thoughts on how to do this?

looks like they used Cyphre or Gabriele's background generator ;-)

The power in Rebol is different. I think Rebol is good for KISS, 
where simple things are simple, hard things are hard. Like adding 
co-routines. We added this feature to BEER. It works but they require 
careful programming of your routines. Otherwise you get blocking. 
The solutions is R3 tasks. Similarly situation has happend with other 
features, like the FastCGI request that I see sometimes, or callbacks 
for C routines which was dormant inside the interpreter for years 
until discover by cyphre and later released.

ah, but that is ONLY problem of style itself, not of the aproach 
taken? Well then, Cyphre added arrows to scroll tabs to his style 
in 1 day ;-)

oh, I am glad I tried it. It is 10times slower, than Cyphre's SWISS 
REBOL based desktop demo. We really need that plug-in thingy to show 
the world, their browser based aproaches are utter crap, what else 
can be said about it?

... now my question is - where is my R3, and where are our planned 
View kernel advancements? Cyphre did not touch View kernel for more 
than one year  ....

IIRC Cyphre had some old comparisons, and AGG was the fastest one. 
There is still some place to optimise stuff. E.g. bitmap/image node 
caching is not done in View yet ...

Of course, even Cyphre's menu has bad metrics and looks "cheap". 
But is it really a problem to design it correctly?

The current library interface is servicable, but could be improved.

For example, char arrays in C structs are a real pain to deal with,

there is redundancy if you're importing a number of routines, from 

the same library, and extra work is required to deal with pointers
to values.

The biggest issue for me seems to be that I have to use COMPOSE 

heavily to get the results I want, or there's a lot of duplication
in struct and routine defs.

--- Easier Routine Declarations

The only thing I've addressed in my lib interface dialect is
making it easier to declare routines. I posted it to REBOl.org
for discussion:


http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=lib-dialect.r

--- Pointers


This is maybe a bit of an extreme example, but I had to do it, so 
it's not purely theoretical.

    LPINT-def: [value [integer!]] none

    LPINT: make struct! LPINT-def none

This struct shows where a nested struct is needed.

    _FAX_JOB_PARAM-def: compose/deep/only [

        SizeOfStruct    [integer!]      ; DWORD structure size, in bytes

        RecipientNumber [string!]       ; LPCTSTR   pointer to recipient's 
        fax number

        RecipientName   [string!]       ; LPCTSTR   pointer to recipient's 
        name

        Tsid            [string!]       ; LPCTSTR   pointer to transmitting 
        station identifier

        SenderName      [string!]       ; LPCTSTR   pointer to sender's name

        ;SenderName      [struct! [value [string!]]]       ; LPCTSTR   pointer 
        to sender's name

        SenderCompany   [string!]       ; LPCTSTR   pointer to sender's company

        SenderDept      [string!]       ; LPCTSTR   pointer to sender's department

        BillingCode     [string!]       ; LPCTSTR   pointer to billing code

        ScheduleAction  [integer!]      ; DWORD job scheduling action code

        ;ScheduleTime    [struct! (SYSTEMTIME-def)]        ; SYSTEMTIME  
          time to send fax
            wYear       [short]
            wMonth      [short]
            wDayOfWeek  [short]
            wDay        [short]
            wHour       [short]
            wMinute     [short]
            wSecond     [short]
            wMilliseconds [short]

        DeliveryReportType  [integer!]      ; DWORD e-mail delivery report 
        type

        DeliveryReportAddress [string!]     ; LPCTSTR   pointer to e-mail 
        address

        DocumentName        [string!]       ; LPCTSTR   pointer to document 
        name to display
        CallHandle          [integer!]      ; HCALL reserved
        ;_PTR   Reserved[3]  [integer!]      ; DWORD must be zero
        _PTR-0  [integer!]      ; DWORD must be zero
        _PTR-1  [integer!]      ; DWORD must be zero
        _PTR-2  [integer!]      ; DWORD must be zero
        _PTR-3  [integer!]      ; DWORD must be zero
    ]
    _FAX_JOB_PARAM: make struct! _FAX_JOB_PARAM-def none
    _FAX_JOB_PARAM/SizeOfStruct: length? third _FAX_JOB_PARAM

    fax-complete-job-params: make routine! compose/deep/only [

        JobParams     [struct! (LPINT-def)] ; ptr to job information struct

        CoverPageInfo [struct! (LPINT-def)] ; ptr to cover page struct
        return:       [integer!]
    ] winfax.dll "FaxCompleteJobParamsA"

So, the API call returns pointers to structs containing the 
data we want; to get it we need to dereference the pointers
after the call.

    complete-job-params: func [
        /local
            params-ptr cover-ptr    ; API return pointers

            params cover            ; REBOL structs with data from API
    ][
        ; allocate return pointer structs for API call
        params-ptr: make-LPINT
        cover-ptr: make-LPINT

        ; make the API call

        reduce either 0 <> fax-complete-job-params params-ptr cover-ptr [

            ; get data from pointers returned by the API

            params: get-dereferenced-data params-ptr _FAX_JOB_PARAM-def

            cover:  get-dereferenced-data cover-ptr  _FAX_COVERPAGE_INFO-def
        ...



Getting the de-ref'd data is the real pain, and seems like it might
be unsafe in the way I did it, though it worked.

    get-dereferenced-data: func [

        {Given a pointer to memory, copy the target data into a REBOL struct.}

        pointer [struct!]   "LPINT structure whose /value is the data pointer"

        struct-def [block!] "The struct you want returned with data"
        /local struct data orig-pointer result
    ] [

        struct: make struct! compose/deep/only [ ; make wrapper struct
            sub [struct! (struct-def)]
        ] none

        orig-pointer: third struct              ; store original inner pointer

        change third struct third pointer       ; change inner pointer to 
        ref'd data

        data: copy third struct/sub             ; copy data from the inner 
        struct

        change third struct orig-pointer        ; restore inner pointer

        result: make struct! struct-def none    ; make result struct

        change third result data                ; change data in result struct
        struct: data: orig-pointer: none
        result
    ]


--- char arrays in structs, or as routine parameters

You can't just declare a fixed size block or string to do this, 
you have to (AFAIK), have individual elements for each item.
That's a huge pain if you have a 128 element array, so I end
up generating them dynamically. I think that was Cyphre's idea
originally, but I don't have notes on it.

    make-elements: func [name count type /local result][
        if not word? type [type: type?/word type]
        result: copy "^/"
        repeat i count [
            append result join name [i " [" type "]" newline]
        ]
        to block! result
    ]

    GUID: make struct! GUID-def: compose [
        Data1   [integer!]  ; unsigned long
        Data2   [short]     ; unsigned short
        Data3   [short]     ; unsigned short
        (make-elements 'Data4 8 #"@")  ; unsigned char
    ] none


--- MAKE-ing structs

How do other people make structs from prototypes? 

    make-struct: func [prototype /copy /with data] [
        make struct! prototype either copy
            [second prototype]
            [either with [reduce [data]][none]]
    ]


--- BSTR type

I've only needed it for one project, but it might be worth 
finding out if it would be worth adding BSTR support for
Windows, as a routine datatype.

guys, then try to involve Cyphre into discussions of what you gurus 
need new View kernel should do under the hood. I think that work 
on new View engine started ...

Cyphre .. how feasible would a PS renderer be in R3?

Cyphre, it's not just the coordinate system, it's rotation, scaling 
and transformations.

ah, yes, of course ... yesterday's talk here with Cyphre ...

Henrik - from what I know from Cyphre, new View will use full AGG 
compositing (AGG contains compositing engine), so maybe so ...

Does anyone know if Ryan Cole's raycasting games are still available 
anywhere? ( previously at http://www.sonic.net/~gaia/games/wanderer/wanderer.r
 and ../see.r )  I've also just begun to look at cyphre's raycasting 
example - is anyone familiar with it?  (in it's default state, it 
crashes).

http://www.rebol.cz/~cyphre/raycasting.r

I read about raycasting in Olivier's book, newly translated by Peter. 
 It was so simple to understand - just 30 or so lines of REBOL code 
(REBOL has enabled me to explore every development curiousity in 
which I've ever had an interest).  Digging in to Cyphre's code is 
a bit of a challenge - always is - but I'm looking forward to understanding 
it better.   Does anyone know what techniques have superceded raycasting? 
 I'd like to pursue that interest more.  I was so amazed by Brian 
Hoadley's R3d scripts last year - thought they should've won the 
contest.  Was he ever an active part of this community?  Having brilliant 
code like that donated to the community is the biggest reason that 
I hope for stronger REBOL promotion in future.  We need more people!

Somebody on the ML is looking for the "Rebol theBeast" game which 
was based on Cyphre's Arcadia. Cyphre (or anybody else) is it still 
available?

I think it was just a demo. I don't know where a public link is, 
unless available from Cyphre's Viewtop site.

however - Cyphre's rebsite was placed on my server. I did mistake 
during server reinstall, I forgot to back-up his content. Cyphre 
would have to make it available again ...

I can imagine using Cyphre's JIT compiler to speed it up :-)