AltME groups: search

Javascript *plus extensive frameworks and bug fixes* does a pretty 
decent job of creating GUIs.

and the way you can stop a current animation

Graham - I think noone criticised you.  But honestly - you started 
your description like if R3 GUI plan would need any inspiration in 
JS.  There were many many discussions about it, and also from some 
docs it starts to be apparent, how R3 GUI is flexible ...

I started by saying that I was reading about ujs ... and picked on 
aspect of it knowing full well that most of ujs did not apply

And then I looked for R3G examples and did not see any separation 
there either. So, I asked ...

No need to reopen the discussion, but the thing you wanted was to 
separate gui description (elements and its placing, look) from the 
action code?

So, one person could design the gui, and another could design the 
functionality

And unfinished

The R3 GUI does the separation of form and function better than Delphi 
(or even HTML/CSS/Javascript).

And Carl is currently busy generating R3 documentation.

Carl is doing very good and needed infrastructure thing. I always 
support such things. Both DevBase and Docs are needed.

Kib2: Not my call, though I think chat could use better user management 
functions before we open it up again. We need to be able to *delete* 
users and all of their messages to deal with spammers - not just 
disable. We also need for the admin to be able to rename a user on 
request, to cut down on duplicate user accounts when users change 
their mind about their ID - we already have those.

At present I allow users to write a custom screen in RebGUI that 
loads into a tab.  Of course they can write as much REBOL code there 
as they want.  But it would be safer if they just wrote presentation 
layer stuff .. and let my program allow the appropriate functionality.

Of course I could write my own layout function and disable any Rebol 
actions ..

You can do that by disabling the DO action and just having the other 
actions, which *you* write. Your users will just do layouts, and 
your artist will do the styles.

Yes, badly and slowly, respectively :(

However, most phones in use are years old, and even most of tthe 
Windows Mobile ones aren't up to 6 yet.

Or to buy an iPhone, which I can't use anyway because it has no keyboard 
- I can't use an onscreen keyboard (bad hands). I'm trying to limit 
what I ask Reichart for, and since my phone is representative of 
what the market has it would be good to keep using it.

Both. Phones with good browsers are rare and it would cost many billions 
to change that.

Graham - the thing is, that when I proposed REBOL being ported to 
JAVA VM, to get to platforms where REBOL presence is lacking, the 
idea was dismissed and native port of REBOL proposed for target HW. 
Now just because of some licensing description we are about to port 
REBOL to even slower VM? Screw Apple then. In few months I buy HTC 
Touch Pro or Touch Diamond, Windows Mobile based phone. Then there 
is going to be Android phones (first on market is already here), 
Palm Treo, Linux based (Open Moko) - so, there are some choices out 
there ...

Pekr: Delphi (and Lazarus) most definititely separate the description 
of the GUI and the code. They are described in different, though 
simiiar langauges and saved in separate files; .dfm for the GUI description, 
.dpr (or .pas) for the code.

No Java on iPhone - same license restriction. Mono's there though, 
and (in theory) you could use IKVM.NET to put Java on that.

i copy the script and remove the header

R3 will not be very compatible with R2. You will almost always need 
some kind of porting process, so this is up to the authors of rebdb 
and rebgui, if they want to do that.

Claude and Peter, as I reported here one or two weeks ago, I ported 
my CMS of around two thousand lines

It took a full week to compensate for the changes and bugs. I think 
about half of that could be prevented after fixes and more attention 
to compatibility

I'm running r3-a35 and load-gui is working for me.

there used to be a jpeg loader, but it has been removed for now due 
to changes in LOAD and we're awaiting mediatypes, which would handle 
image loading.

kib2, go to http://curecode.org/rebol3/view-tickets.rsp

and filte by "Recent changes". The gray entries are the changes.

There's an even better way if you are logged in to CureCode:


Select "Change Log" from the menu bar and it lists the tickets fixed 
in the release.


You can look at previous release by using a drop down version selecter.

I just read about 'gather function and would like to ask about its 
area of usage? In the past, in FoxPro DB days, there was common method 
to get all for related data, via function called gather, and the 
reverse was to set a form from an array, via scatter fucntion.  I 
think that if gather takes just one field from objects, we might 
use good name for some limited functionality, whereas it could be 
good name for GUI forms (panels) and gathering of info from all objects 
in one run?

We don't really need scatter/gather for the R3 GUI, as it already 
works with SET-FACE and GET-FACE using panels.

BrianH, no, absolutely not. :-) Pekr asked, as far as I can tell, 
that he wanted to use GATHER for a specific form data collecting 
function and we shouldn't need that.

It should be enough to manipulate forms using SET-FACE and GET-FACE.

Good, because Carl has shifted his priorities for now to helping 
me by fixing errors that are blocking me. He asked me to change all 
of my worst pet peeves in CureCode to urgent last night, and he accepted 
almost all of my recent work in DevBase. GATHER hasn't made it in 
yet though - I am explaining its need to him now.

Specialized functions are faster, simpler to write and easier to 
understand.

I proposed it, because I use it in many places to collapse chunks 
of 20-30 lines of code into one line and it works well in use as 
part of bigger functions.

There are some things I can't understand in the demo : when you click 
on source, you don't get the full source but just a part of it.

Also, I've tried launching this script (from Dragger demo) :

REBOL [ ]

load-gui

view [

doc {
^-^-^-===Drag the boxes

^-^-^-Blue boxes are unbounded.

^-^-^-Red boxes are parent panel bounded.
^-^-}
d1: free-drag
d4: lock-drag red
panel 0 80.200.80.80 [
    d2: free-drag
    d3: lock-drag red
]
]

...and got a parse error : why ?

they are not "hidden". they are just not part of the standard style 
list. and you can't create free-drag or lock-drag items in your layout 
without creating a style.

including the free-drag and lock-drag style.

the style could be extreme complex and consist of other substyles. 
it doesn't make sense to have that code inside the layout.

there is a strong separation between the layout and the style code.

The error that has occurred above is that the "demo-let" that kib2 
looked at is not properly documented. Its script header should declare 
what its dependencies are and in what environment it should be run. 
This is a constant source of time-wasting for everyone, as an undocumented 
script apparently advertises that it has no dependencies and can 
run on its own. So all new-comers to the script will try it in the 
console themselves and see it doesn't work. Now the wondering begins: 
"is it supposed to be working or is it still in development?" etc. 
It's not kib2's fault for not having studied how the R3 GUI works.

Let me just temper that - it just shows that the script is not complete, 
and this is understandable in a system which is in flux.

Actually size of the image does not seem to be the prob as this works: 

SQL reduce [{insert into images values (?,?,?,?,?,?,?,?)} "img/1" 
"img/2" "img/3" "img/4" "img/5" pic "img/7" "img/8"]
where pic is a large 4000x3000 full color photo.
I get no error.

But if I loop 50 and insert the above data 50 times I get an error???

I went through the CureCode tickets and marked the ones fixed in 
alphas 35 through 37, that weren't already marked. You can see the 
changes in the Change Log section of CureCode, and some fixes are 
summarized on the R3 Releases page too.

Josh, the issue is that the chat server is running on R2 right now 
for reliability. R2 can't handle Unicode except as binary, and certainly 
can't do case-sensitive searches for user names in Unicode. The web 
client for mobile is even worse, and is also R2 since R3 can't handle 
CGI yet.


Right now we are focusing on getting R3 stable enough to use on the 
server-side. Hence the changes in the newest alphas.

If you think there were a lot of changes in the last alpha, you should 
see the next one. I have fixed most of the bugs in LOAD and DO :)

R2-Forward has been updated to match alpha 37 as well, though that 
meant adding one more function to the todo list (and 5 more to the 
done list, and 6 more to the improved list) :)

The latest shots of the UI can be seen at http://rebol.hmkdesign.dk/files/r3/gui/
but it is still changing and far from done.

I noticed the GUI demo in R3 is very buggy.  Sometimes it just eats 
CPU and does nothing.

Why are minimum-of and maximum-of being mezzanines now, instead of 
natives as in R2?

Why are minimum-of and maximum-of being mezzanines now, instead of 
natives as in R2?

Because we are cleaning down the core in R3, and those functions 
are rarely used. They are fast enough as mezzanines - the FORSKIP 
loop they call is native in R3.


Mezzanines can be better for some purposes too - REBOL is a much 
more powerful language than C for some things, so it is sometimes 
a good idea to write the functions in REBOL instead, particularly 
when it needs to be flexible. This is why LOAD is a mezzanine in 
R3 (which calls native code to parse the REBOL data), and half of 
DO is an intrinsic (a built-in function written in REBOL that is 
called by native code).

Part of the R3 boot-up process is an intrinsic too, as is part of 
the MAKE port! and MAKE module! actions.

BrianH: as for filesharing - can we share also binary files? Is it 
general mechanism, or is RebDev limited to only text files and their 
diffing?

AdrianS: some small helper, but you probably know it. What you can 
do is partial word searches. E.g. try:

help to- ; and it will list every to-* function
help pr ; it will list every function containing "pr"

The typeset! type is a new addition in R3, and emulated in R2-Forward. 
TYPES-OF returns the type spec of a function in both.

Believe me about the awkward: I wrote LOAD, and avoiding the use 
of the ALL function because of LOAD/all was annoying :(

Maybe a /dialect 'name option, with installable dialect help? DELECT-style 
dialects like Draw and VID could have autogen docs too.

I commented the CureCode ticket listed above with the /search option 
variant, and marked it as reviewed.

I just read your comments Brian and I'm not sure what you're suggesting 
allows for the flexibility I was trying to get. It seems to me that 
there are not too many 'components' in a word definition. What I 
see when I get help is USAGE, DESCRIPTION (at the top level and at 
the refinement level), ARGUMENTS (and their type).  What I was after 
was a way to compose the help query to be very specific, but it seems 
to me that what you outlined would follow a certain lookup order. 
Did I misunderstand? With only the components just mentioned, is 
it too much to specify them specifically and in parallel with each 
other?

The sorting order should handle priorities, and the difference between 
word, /word, "word" and word! usage should be enough.

sorry - stepped out for lunch - just digesting it and what you added

and how would the typeset be specified after the /search refinement?

ok, got it - so the order is lost and can't be enforced

so specifying help/search integer! string! would create a typeset! 
of those datatypes, no? I'm just thick and what I was asking above 
is how do you specify a typeset! - in your comment you only show 
help/search integer! (though you mention that the last value could 
be a datatype or typeset)

I suspect there is a misunderstanding here. It seems to me Adrian 
wants to search for functions that take two arguments, one integer! 
and the other string!. It seems to me Brian proposes a /search refinement 
that searchs for functions that have one of the arguments accepting 
integer! or string!. These are two very different things.

Gabriele: Brian explained to me that the order of the arguments in 
the spec is not preserved when a word is defined since the spec args 
are kept in a typeset! which doesn't preserve the order. In the last 
part of the comment to the ticket, he describes how you would specify 
a typeset! in the /search refinement (help/search [integer! string!]). 
This would let you search for definitions where at least two of the 
arguments are integer! and string! - in any order. It's not exactly 
what I was asking for, but it's all that can be done with the metadata 
that is retained from the definition.

Adrian, what Brian is proposing will get you most of what you want, 
but what you are asking for seems to be a bit to specific and from 
my perspective doesn't add enough value to be worth the time to implement. 
 With intuitive sorting you'ld get all of the functions that require 
both an Integer! and a String! first followed by those that require 
an Integer! or a String!.  About 80% of the reason that I actually 
use Help is to see the order in which a function expects it's arguments 
to be in.  Searching for [Integer! String!] will list the functions 
that opperate on a string and require an index to that string at 
the top of the list and I think that's what you're really looking 
for.  Some people think in oppisite directions and want to declare 
the index first and others want to declare the string first.  It's 
just a matter of preference and doesn't change what the function 
does.

as a new user to REBOL, you tend to browse around to discover new 
functionality - least I do. The example I gave before was to answer 
questions like "what can I do with two strings?" or "or "what can 
I do with a block and an integer?". Typically, you tend to have a 
bit of a clue as to the datatypes you're working with, but you often 
can't recall the function names

It's funny, I've found that experience in other languages tends to 
make REBOL more difficult to understand, with some notable exceptions: 
Lisp-family languages, assembler, and Icon :)

REBOL's not going for large-scale adoption. With software-as-a-service 
and the huge programmer population, even a niche language can have 
huge impact and lots of developers. We don't want the mass market 
- that road leads to Java or VB.

well, if you can believe it, I've been "following" REBOL since it's 
beginnings, but never really pursued a deeper understanding of it 
due to various reasons (lack of adoption, closed nature of the language, 
lack of time on my part, etc). I have always, though, felt a very 
strong attraction to it because of all the possibilities hinted at 
- the lightweight nature, the clarity of expression, the built-in 
GUI, dialecting, and so on.

I will use it as an example for sure - I was wondering though - the 
documentation on the diffs are pretty important - it creates essentially 
a hybrid REBOL and without detailed docs explaining the diffs, it 
might make it harder to know what's what - you did mention the release 
notes in the code, but that's not so accessible for quick reference

so, the approach that should be used with R2-forward is - program 
as if you were using R3 and when seeing a difference try see if it's 
due to an R2-forward limitation or a bug, no?

I was thinking about where/how REBOL might hitch a ride on Java's 
success and popularity - being in the server-side Java space for 
quite a while now, some of the trends are pretty obvious to me - 
and some of this touches on some of the unfinished business in REBOL, 
namely modularity - are you familiar at all with OSGi Brian?

Not with the term. Cleaning up R3's modularity is the next thing 
on the todo list, and I will backport it to R2-Forward as much as 
possible. Most of the hard work of the backport has been done already 
by Gabriele in his %module.r. By the way, if you don't use R2-Forward 
as a module, a lot more code doesn't work. The new words are just 
exported from it when loaded as a module - they redefine the global 
words when you just DO it. Those changes to global words can break 
other parts of R2 in unknown ways. If you just import the module, 
only the words in your script are redefined, so only your script 
has to be made compatible.

here's an outline of what OSGi is from the horse's mouth, if you 
care to look - http://www.osgi.org/About/WhatIsOSGiand some of the 
benefits - http://www.osgi.org/About/WhyOSGi. I'll try to explain 
where I see REBOL taking advantage of this.

essentially, OSGi is all about modularity and dynamic services

pretty much all of the big names in the application server space 
are moving or have moved over to this architecture for their own 
implementation and some are exposing OSGi as an environment in which 
the user applications can run in

First of all, this is not the place to discuss such things if you 
want them acted on. AltME is too ephemeral, and some of the core 
people don't come here that often, and most of the core people haven't 
been on the mailing list in years.


Post those links in R3 chat. The modularity stuff can go in R3/Language/Modules 
(2165) and the services stuff in Tools/Reb-Services (54). Keep in 
mind that the vast majority of a Java spec like that is dedicated 
to making Java suck less, so the REBOL version will likely be mch 
simpler.

I will move this over to those areas, but I just want to say that 
my whole point here is that REBOL very easily could be a supplier 
of services (and possibly a consumer, though less likely) to applications 
built on OSGi - the fact is that the Java enterprise area is huge 
and getting a foothold in there would really open a lot of eyes to 
what REBOL can bring - a total shift to REBOL, of course :-)

Well, the place for that is Reb-Services. At this point we are focused 
on the Modules and below layers.

Integrating Reb-Services with web services, .NET Remoting and DBUS 
would be interesting too.

(and pretty easy methings)

I think you can load an image into R2, mold/all save it as an image! 
and load it into R3 that way.

Yes, no rebin yet, but that it is planned for march, because of low 
dependenices, and because it is needed for host code to be released 
.... ?

I just visited AGG newsgroup after one year, and some interesting 
projects do emerge. Community agreed that any open work will be done 
to BSD version (2.4), which is a good sign (although RT has probably 
no problem obtaining special license).


Dunno why, but there are (apart from Cyphre) another few Czecho-Slovak 
guys, and one of them is doing rather interesting project. AsmJIT 
and BlitJIT libraries, with MIT licence. Author says about it:


Antigrain is great piece of software with great licence, 
but without 
better acceleration it's quite slow.  So blitjit can increase speed 
of 
your applications in way you can't imagine. For example is there
complete 
MMX/SSE2 extension for antigrain ? No, but don't panic, other
libraries 
also have problems with cpu specific features.


The reason why it might be interesting is, that generally there is 
no good 2D HW acceleration out there, and here is what author of 
LibNUI answered to Cyphre:


I'm the author or nui (http://libnui.net) which is a GUI toolkit 
based  
on OpenGL (and now OpenGL ES / Direct3D). This project was 
started  
some 8 or 9 years ago and I've been working on it and with 
it amlist  
daily for that time. My experience is that it's some 
orders of  
magnitude harder to have HW support for those features 
that to add a  
JIT to your engine in order to optimize your bottlenecks 
(I've done  
some of that for pro audio dsp code). The reason is 
that no two chips  
work exactly the same and behaviour even tend 
to change over driver  
releases. To diferent cards, even sometimes 
from diferent vendors,  
will not give you the exact same scan convertion 
or rasterizing, and  
I'm not even touching shaders diferences...


It seems to be x86 only so far, but maybe guys like Cyphre or BrianH 
or Anton or anyone skilled in those areas should keep an eye on those 
guys :-) Here's a link:

http://code.google.com/p/blitjit/

... as for those another AGG based Czech and Slovak projects:
http://www.rw-designer.com/
http://www.crossgl.com/

Shouldn't we get those guys hooked to REBOL? :-)

Can someone see the private message from Ernst on RebDev? He posted 
to admin question why he has so low rank, but I could see the message 
and reply to it.

I don't see 2755 and 2757.

Hmm, then message is  misledading? I do pp Carl, and the header states: 
"posting private message in #thread-number-here ..."

No, it just means that I have not needed effects yet. I think they 
should definitely be possible, but we have to be careful not overexposing 
it. MAKE-GOB could introduce a level of control that we don't want 
in a style, making a single style a big mess with hundreds of lines 
of code, because you have to reference GOBs.

So far GOB management happens in 20-30 lines of code in one specific 
place in the R3 GUI design. It's very tight and controlled and by 
adding an effects GOB there, would make sense in the R3 GUI design.

Maybe it would be best to add 'effect and 'rich-text functionality 
to draw directly, as image is there too anyway. Would make it for 
one combined pipeline. Dunno how it would make low-level implementation 
more complex. Then we could discard other gob types ....

Dunno, but I would like to have transitions and wipes available. 
It could be done even nowaday, just look at Jeff Kreiss present.r 
script. IIRC it is available on rebol.org. It contains whole dialect 
for movement, fading, etc. What I worry about is - low speed of REBOL 
for such stuff, at least in REBOL level and without Rebcode, we can 
better forget it. We also need to implement different type of timers 
etc. But generally - dunnof if we can get smooth results without 
real HW acceleration ....

Do you think that gradients could help us with progressive fade effect? 
I mean - not fading whole gob, but because of using a gradient, it 
would look like progressive fading. Well, for real transitions (and 
there are few demos out there), anything REBOL based (e.g. pick/poking 
pixels) is gonna be slow, unless implemented directly as an effect, 
or unless Rebcode in new form is back ...

It would help if GOB alpha was calculated per pixel as an effect 
and then we could do real alpha masks, but it isn't.

Just wanted to look-up some info about ReBin, as it is mentioned 
in recent March R3 plan, and found out following article:

http://www.rebol.com/article/0044.html


Pity it is almost 4.5 year old one. Hopefully we get it in upcoming 
months, as some features were really planned for ... sooooooo long 
;-)

Ah, damn, another big restructure of DocBase? :-) While Docs become 
more readable and graphically nicer, the person doing restructuring 
does not even distinguish Gabriele's GUI to Carl's one, so it really 
becomes an organisational mess and he ruined Carl's initial Docs 
for GUI ...

Question to R3 people:
In R2	>> LIST-DIR %/c	<-- will crash R2.7.6 
In R2	>> X: %/c

 >> LIST-DIR X		<-- will ask a security question to allow, and then 
 return desired results

In R3	>> LIST-DIR %/c	<-- will return desired results (no security 
for alpha R3a.37)
	>> X: %/c

 >> LIST-DIR X 	<-- will give ** Script error: invalid arguement: 
 %X
	>> LIST-DIR :X	<-- will return desired results.

Why do I need to put a : in front of my variable in order for LIST-DIR 
to work properly?  Doesn't seem to be intuitive, does it?

I noticed that under HELP LIST-DIR, the arguments state 

    path -- Accepts %file, :variables, and just words (as dirs) (file! 
    word! path! string! unset!)

I get the first two ie  %/c and  :VAR-DIR, but what about "just words..."
Can anyone give examples of the third type of argument?