AltME groups: search

Cyphre and I prefer to use timer setup funcs rather than merge them 
within the gob infrastructure.

go cyphre, go :-) The more general way is always better. OTOH why 
not add field here or there - but - not for the purpose of one user, 
but once again, upon the well defined purpose ...

the current version handles multiple 3D view ports and interactive 
dragging of 3d gobs while they are being animated with practically 
no performance loss a part for the 2d gob handling.  I'll check out 
Cyphre's OpenGL tests so see how they can be integrated with CGRs 
so that the complete solution is hardware accelerated.

just make it general please. Cyphre used some other method for acceleration, 
and we should consider various possible available solutions, look 
also at how Flash is doing it, etc. methods ...

Cyphre's systray code could come in useful into making this a systray 
application

Cyphre made this new FORM-DECIMAL function. I've been allowed to 
share it, so it can be tested:

form-decimal: func [
	num cifre
	/local m n o p result
][
	p: ""
	result: either find num: form num #"e" [
		parse num [
			any [copy m to "." skip] copy n to "E" skip o: (
				all [
					not m
					m: n
					n: ""
				]
				if m/1 = #"-" [
					m: copy next m
					p: "-"
				]
				z: (length? m) + to-integer o
				result: to-string reduce either negative? z [
					["0." (head insert/dup copy "" "0" abs z) m n]
				][
					o: join m n
					["" o (head insert/dup copy "" "0" (z - length? o))]
				]
			)
		]
		result
	][
		num
	]
	result: parse result "."
	o: result/1
	o: skip tail result/1 -3
	while [not head? o][insert o #"." o: skip o -3]
	all [
		not result/2
		insert tail result ""
	]
	result/2: copy/part result/2 cifre
	insert/dup tail result/2 "0" cifre - length? result/2
	all [cifre > 0 insert next result ","]
	all [result/1/1 = #"0" p: ""]
	join p result
]

Cyphre: yes, that was one of the options I've considered at the beginning, 
but when I saw that I could have timers working for more than 24 
hours, I've choosed the long waiting timer way, because it was much 
simplier to implement and looked more reliable.

Since it's a read only db, perhaps I could use Cyphre's compiler 
:)

So, we are back online with our AltME world. We mostly recovered 
everything thanks to Cyphre's effort. Now everything is backed up 
in 6h intervalls. Won't happen again.... back to work on R3-GUI stuff.

Note: The code is not yet uploaded and the URL is not correct. Cyphre 
did use the old-company site. I'm going to post an update.

THE CODE IS NOT YET ONLINE FOR DOWNLOAD

RebGUI/Core - Forking: I agree with you. I have talked about this 
with Cyphre too. I think developing a simple but layerable toolkit 
is the way to go. But it's hard, because there are a lot of different 
requirements coming up when doing an appplication.


I think I will provide my RebGUI fork on my web-site and try to document 
all the differences.

Luis, I agree. It just dos not look "right". I uses cyphre's tab 
panel for a few projects and it just has a slicker look to it.

Cyphre has a drag-panel style that allows drag and drop of various 
objects on a window.

Where can I find more info about API changes of RebGUI, which happened 
some time ago? I would like to get Cyphre's grid working, as it is 
many times better than table available, even without column resizing 
....

Cyphre sent me this code and has also placed it into SVN

I am trying to adapt Cyphre's old grid to recent RebGUI requirements. 
I got myself past color adaptation, so actually I can get it displayed, 
internally it returns correctly API function results, but I need 
to adapt to event handling. I am facing two problems:

- editing, double-click etc do not work
- during some actions as resizing I get following error:

** Script Error: action has no refinement called on-click
** Where: set-data
** Near: face/action/on-click face


I looked into: help ctx-rebgui/widgets/grid/action, but those funcs 
are not set. Is there any need to set those function for particular 
widget? I looked at some other styles as e.g. button, but button 
is not using its face/action/on-click either, so I am a bit confused 
....

Cyphre's grid. After Henrik's grid it is simply the most advanced 
REBOL grid and it is really stupid it was not adopted to new standard, 
waste of functionality and money ...

Graham - it is not true. IIRc I prepared package which I sent to 
you, with primitive initial doc, with included rebgui version, and 
it was working. The bad thing is, that it is some early version I 
paid for, but at that time there were some API changes to RebGUI, 
and I was not able to further contract Cyphre to adapt it ...

I'll try to talk to Cyphre, but not sure how deep the changes would 
have to be. If it would require a rewrite, then I am not ready to 
pay for it once again ...

Not sure it was Gabriele - Cyphre did something upon contract for 
me, and I released it 2 years ago? :-) IIRC Cheyenne uses it too 
...

No, there is Cyphre's grid, but it was not adapted to new API changes 
....

Steeve - your work is quite impressive! Just don't become demotivated 
by possible lack of responses :-) If you find some bugs, or you come 
up with some ideas of how to make View more SVG friendly, write your 
notes down, we can discuss it with Cyphre. I think that we are still 
in rather initial phase, so we can e.g. change the way of how e.g. 
gradient-fills work (I do remember someone reported that you can't 
translate gradient definitions between /draw and SVG)

Hello Cyphre, good work, you've done with gradients.

Cyphre, Maxim has also had some ideas for manipulating draw elements 
directly very quickly. Have you been in contact with him regarding 
those ideas?

Cyphre, posting privately.

cyphre... those are incredible test SVG files!

and what  about the text display / font management issues ... and 
this can be linked to viva-rabol or SVG rendering... Cyphre do you 
plan or have taken  some notes about that area ?

BrainH: I'll point you to one article, wait a min., I need to find 
it. Actually - it was Cyphre who found it IIRC.

I would wait 6-12 months at least with using R3 in production apps, 
particularly if you are betting on advanced high level things like 
GUI. Development could start now, but R3 is not near feature freeze 
yet. Many moving targets and bugs remain. Cyphre is supposed to give 
the graphics engine another overhaul. We are also missing many docs 
for painless porting of R3 to other OS'es.


BTW: Carl has mentioned before that some things are needed for beta. 
I'm not sure the recent blog post is a good indication that R3 is 
anywhere near beta. I read it more like "this is a necessary 3.0 
feature".

re Cyphre - I have trouble reaching him on ICQ, not to mention reaching 
him here. I am really curious, if Cyphre is going to be available 
for "another overhaul", but maybe I am too pessimistic in that regard 
:-(

with extensions all of the View internals can be outside... its basically 
AGG with a set of predefined hooks.  The only detail would be custom 
datatype... which should eventually reach extensions... maybe Carl 
could just build a special (undocumented) extension hook so that 
cyphre has access to more stuff, without the hassle of supporting 
it as a feature for the public.

extensions are the key to liberating REBOL from its platform limits. 
 just like python can focus on its core, all the rest is modular 
and is maintained by other people, not Guido.


once I get the OpenGL extension working to some basic level, RT will 
never need to support it, I am pretty sure, John, Cyphre, Henrik, 
Anton, I and others will be able to give it a life of its own, all 
that RT will have to do is provide a link to it on its own site and 
say that R3 supports OpenGL natively.


same for sqlite and pekr, and many other tools many of us use daily 
and wish we could manage with rebol instead.

Could Cyphre's vconsole help? He did complete console simulation 
(except multiline capability) in VID ...

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

I would like Cyphre to devote 5-10 days to core engine. E.g. transparent 
windows (not absolutly necessary for initial release, just an example) 
is just question of setting particular bit for API call, at least 
under Windows. I would like to see - Unicode, better fonts, cached 
gfx (we don't use bitmap caching yet), eventually switch to AGG compound 
rasterizer, some draw suggestions being implemented - so much for 
a low level ...

I think that Cyphre can't work on View engine because of C code alignment. 
We have to wait, untill Carl isolates kernel and host, and releases 
the code. But then - even few small changes might make some difference 
in the end. I think that View engine deserves few weeks of additional 
developments ...

I am also not sure, GUI will support Unicode from the very beginning, 
altough many expressed it being a priority. There is a difference 
between GUI and VID. Carl worked on VID. Once he is back to it, I 
believe Cyphre is going to be contacted to do some work on View part 
...

My guess is 2-3 weeks for VID itself and 1-2 months for the skin. 
Really lowlevel stuff depends on the availability of Cyphre.

Cyphre is waiting for the C code alignment. He does not have recent 
sources for View. If I understand him correctly, he has to wait for 
the Host code release ...

when it's ready, I hope that Cyphre can at least partially work independently 
from Carl.

Apart from that Shadwolf forgot, that it was not only Carl himself 
working on R3. It was also Ladislav, Cyphre, you (Gabriele), BrianH, 
although not all of you contributed at C level ...

cyphre working on R3 actually ? Cyphre didn't loged to atme since 
july 27 how active is that ?  I don't see many topic poped around 
at same time i see 1 main topic wroked and the related things worked 
at same time that's all. 

Complete architecture change .... hum ? but that's came along the 
flow my brother it wasn't a from the begining statement.

Cyphre is not working on R3 AFAIK.

I think we should ask Cyphre, whether this property can be added.

I suspect BrianH, Maxim and Cyphre wake up when the host code is 
released. That'll be enough for me. :-)

Cyphre, onmy computer  with your mandelbrot-int.r script i get :

rebol 2 VM 2.7.6.31 : 0:00:03.904
rebol 3 (2.100.95a): REBOL Elapsed 0:00:04.354   


my computer in intel core i5  750 , 4Go DDR3 1333MHz Gygabyte P55UD3 
 

so maybe you should upgrade  ( and i'm sur where i lost most of the 
time where in the consol exists)

yeah but i like the  benchmarks based on deprecated harware ... as 
you could see  on a today's computer (and not even to top mark one) 
 the gap betwin R2 and R3 isn't so wide as stated by cyphre...

but Gabriele and Cyphre have been blocked by lack of access to the 
code ... that is a matter of record

Cyphre: "the problem" is, that even 650 USD was not enough for any 
skilled developer to pick-up. Or maybe just - to prioritise it ....

Cyphre - you still use the same attitude I mentioned in the article, 
and that is wrong with me, sorry. The feature is either being put 
on the list, or it is dismissed from the list of available features. 
Carl stating something is complex is not argument for me.

The other thing is that Carl thinks the solution is so obvious that 
he has not told us what to do, because he expects it to be happening 
now on a per-platform basis as part of the hostkit, just as Cyphre 
describes. So while we're arguing here, and no-one is doing anything, 
in a few months time, he'll be surprised that nothing has happened. 
We should probably get him to make a blog post on it for "directions".

cyphre... use this as a basis:


view layout [box 200x200 effect [
    draw [
        push [
            translate 119x119 
            pen none 
            fill-pen black 
            box -50x-30 50x50 
            fill-pen blue 
            pen red 
            line-width 3 
            circle 50x50 25 
            fill-pen red 
            pen blue 
            circle -50x50 25 
            fill-pen blue 
            pen red 
            circle -50x-30 25 
            fill-pen red 
            pen blue 
            circle 50x-30 25
        ]
    ]
]]


adding new black, red, blue, black, circles in betwen colors may 
give very poor results.  sometimes 1 pixel width lines practically 
disapear horizontally!


playing around with the line width will also have a different visual 
impact, since the aliasing will spread the error more or less.


as I said, i know part of the issue is related to the screen's rgb 
sub-pixel channel components but I remember trying some of this in 
other softwares and the effects weren't as image degrading.


to me the main defect is that you will notice a WHITE ringing effect 
between the red and blue on one side and a black ring on the other.


I can understand the black ring, but can't explain the white one, 
which is why I think it coule be related to gamma issues.


also, the black ring seems to be wider than it should &  the effect 
seems the most apparent at ODD line widths, which is a bit strange 
too...


I'm wondering if AGG has an algorithm which is trying to compensate 
for pixel to pixel color defects and gets it wrong.  


maybe it could be enhanced to support subpixel aliasing (or gets 
it wrong if it already does so).

My priorities would be related to graphics:
1. VID3.4 re-implementation according to Carl's specs
2. Cyphre's improvements to View, Draw, fonts, etc.
3. VID3.4 skin

My priorities would be related to graphics:
1. VID3.4 re-implementation according to Carl's specs
2. Cyphre's improvements to View, Draw, fonts, etc.
3. VID3.4 skin
2. Cyphre's improvements to View, Draw, fonts, etc.
1. Concurrency (tasking)

These are my wishes - oups
1. VID3.4 re-implementation according to Carl's specs
2. Cyphre's improvements to View, Draw, fonts, etc.
3. VID3.4 skin
4. Concurrency (tasking)

On View: Cyphre was in charge of all graphics. But, he vanished into 
the Qtask black hole a year ago.


If someone else has guru graphics-system knowledge and wants to move 
it forward, that might be a good thing.

I have daily contact with Cyphre, but don't know how much time he 
has right now. Should an arrangement for some more work be made on 
View?

Cyphre told me that he is waiting for actual sources. So maybe giving 
him the latest host source would be a good start.

Carl: "Cyphre was in charge of all graphics. But, he vanished into 
the Qtask black hole a year ago." More precisely, you stopped updating 
the host code on CVS, and me and him stopped having the ability to 
do anything useful on that front in the little time we had available.

Carl: I have the same feedback from Cyphre - he was mainly waiting 
for the "Go" and synced sources ...

Giuseppe - just don't worry :-) Look at the document Carl posted 
regarding host code release - there are several phases and Cyphre 
is definitely involved. I hope we cooperate for good ...

but yea maxim cyphre, gabriele, steeve, and any other people than 
me would feet the task

Cyphre has reported compiling on code::blocks (don't know what OS)

no problem cyphre ;-)

just to explain: valid until means the bountie offer, not the
creation timeframe. it makes no sense to offer a bountie with
an unlimited timeframe to take.
of course the task can & should be made step by step without
any special due date.

so if someone is interested to do the job he should 'decide' until 
this date.

ah ... well then ... maybe Cyphre know more about custom events ...

host kit will give a bit of parallel work done (Robert, Cyphre, BrianH 
and Maxim are all waiting), but I guess it's up to what motivates 
Carl currently.

host kit will fix remaining graphics issues, which Cyphre is already 
preparing. It will also help prepare for a better console for all 
platforms. Robert and Maxim has done various implementations (OpenGL, 
SQLite) and are doing general tests. BrianH, I can't remember what 
he's doing...

Cyphre: Not necessarily.

but - the way Cyphre wrote his example above, it might be understandable 
... simply put, if you want full slot, you have to padd it from the 
left ... or it is just 32 bit value, and hence should yield -1

Max... I'm curious... how do you know that Core was not designed 
for View to be extracted? Did Carl tell you this or are you guessing? 
Because, you know, Core was developed by Carl and View by Cyphre, 
and Cyphre never had any access to the Core sources.

View was not developed by Cyphre. Original View was developed in-house, 
by Jim Goodnow (Carl's friend from Amiga days (author of Aztek C, 
or something like that). What Cyphre did was adding AGG in there. 
Cyphre often tested AGG functionality in form of a DLL, externally 
then Carl patched it in into View IIRC.

IIRC even for R3, while Cyphre has access to View sources, he does 
not have access to Core sources. So the final integration still has 
to be done by Carl. That is my understanding. That is why Cyphre 
is waiting with some improvements, for Carl to finally externalise 
View, so that we don't have to wait for Carl anymore to patch things 
in ...

:-) I also like Cyphre's rotoobjects demo, or bounce one. Simply 
random draw shapes, with various levels of alpha, flying on the screen 
:-)

still some compiler issues to solve. Cyphre is helping with that.

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

Yes, and? We can create dialects in R3 right now that are processed 
with native code; we've had that ability since the first extension 
model came out. If you want to make an optimized dialect, go right 
ahead. Cyphre is working on one, I have one on my list, others are 
considering working on them too.

Cyphre, Andreas, that's what I was seeing, too. Build as console 
app --> no unicode chars displayed, build as gui app --> unicode 
chars are fine, but you can't run in a console window. I don't know 
what other languages are doing or if there is a way to fix this at 
all. From the information I gathered back then, I'd say, probably 
there isn't.

Cyphre - we are already reusing the console (I mean - Andreas, I 
just do some tests). We can even get czech chars displayed, byt typing 
czech chars firing enter quits R3 ...

Cyphre, this looks like a nice acomplishment. Those aren't exactly 
letters from my native language's alphabet, but your console nicely 
prints  

>> print to string! #{e282acc2aec3a4c59fc691cea3ceaecfae}


when startet in a cmd.exe console reusing that as well as opening 
it's own console if double clicked from desktop.

Cyphre, does it allow you to input "special" characters as well?

Cyphre - I re-tested with all possible special czech alphabet chars, 
and even with default font in console, it worked OK. Or was I just 
lucky, and your note was more general, e.g. that such a font can't 
support all possible chars in different than czech language?

Cyphre, Something never tried before can't be categorized as a bug.
It's a feature :-)

Cyphre - I think that vectore type is still not finished. There were 
also some blogs about conversions, but I don't remember the outcome 
....

Brian Posted a list in the R2 Releases group.


I also hope he included 2 fixes which I got Cyphre to address in 
view which crash or mock-up the quality in AGG.

wait... I retract "working". I've not read the code, but Cyphre has 
done it a few days ago.

I can see that, and I'm not sure when work on threading will start 
or if Carl is studying it behind the scenes. All I can see is that 
many things right now are being handled on RM Asset needs, which 
right now is very focused on bringing certain tools to life. In that, 
there is work on GUI and database connectivity.


The SSL discussion was initially brought up by Cyphre as he talked 
about his prototype (which I now read is in fact done in R2, sorry). 
Carl gladly accepted this and asked for specification on what needs 
to be implemented natively to make it all work.

Cyphre - very good work, and good aproach too imo ...

Cyphre - would it be able to fix receiving of resizing events, during 
the window border is dragged? That is kind of unpleasant effect it 
causes for the rebol apps. Next low level thing which would be nice 
is ctrl+tab for system compatible tab switching ...

Cyphre, thanks for the FreeType code. It's a while ago that I looked 
at the src/os/ files, but they seemed fairly large and complicated. 
I won't have time to start that project until at least after ReBorCon

according to Carl :

The most current graphics library changes have been included. Many 
thanks to Cyphre and the RMA project.
Beforehand, it was better to use the RMA compiled host-kit
I also have seen that some bugs disappeared.

I'm stuck again. To start porting the R3 graphics to Syllable, I 
need A111 with Cyphre's FreeType enhancements. Carl hasn't published 
the A111 host kit, but RMA has. However, unlike the host kit in Git, 
RMA's version has the Linux library compiled for the newer GLibC 
2.11. It doesn't run on Syllable Desktop due to a missing symbol

Cyphre, my fix for the SPLIT bug is above in this thread, which prompted 
the long discussion on it.

focus on one and single project do what RMA wasn't able to do ... 
and if to acheive that you have to make cyphre Robert and the other 
RMA members myserable just do it ! do a freaking r3gui that can hold 
a candle to was rebGUI was and is ! so far you are just fucking sploiled 
child and I hate you  sooooooooooo much .  you were given everything 
I never had, the fame the confidence the spot light  the ears of 
each and everyone and what you do out of that  ????!!!  nothing ! 
 you let carl to totally toy you !

Cyphre, it's not a good approach in R3

To track newly defined words in a context you can check the source 
of the function INTERN.

Its tracking newly "created" words in the user context after a binding. 
It's maybe not what you're trying to do but it was in response to 
Cyphre.

Ok ok, but I just want to have a look on the functions Cyphre pointed 
out :)

ok let me rephrase...  given choice of:
-water gun fights
-arguing with Carl about extensions
-riding tricked 3 layer bicycle
-arguing with Ammon about RIDE
-igniting things so they glow and burn
-arguing with brian about R3 modules

-chilling on someone else's couch under the sun, offering water, 
while counting topless/wet-shirt females
-arguing with Reichart about anything ;-)
-getting a hot girl to rub suntan on me
-arguing with Gab about liquid
-getting a hot girl to rub suntan on me an hour later  ;-)
-arguing with cyphre about R3 view

-tripping under some bizare / insane / gargantuous / dazzling / puzzling 
/ lit-up / babe infested / about to be burned / open-aired  -  party 
dome

I guess rebol is wayyy at the top   ;-D

the source tree format could also be used by Cyphre's jit, an LLVM 
extension, Rebcode, or things like that, as a common target.  so 
we can all share efforts.

cyphre indeed

Have you looked into Cyphre's suggested CTYPES?