AltME groups: search

I think that many people won't drop their facebook account, so somehow 
there will be an integration between them, in a middle term..

MaxV, fumbling in the dark, but does it also occur, if you click 
the drop down in the upper left corner (where the world name is labeled) 
and select the world you are logged into?

I'd drop any-type!  :-)

Yes, and that should work in all cases, if the b rule is found, complex 
or not. And this will return true, if b is END, because  END is a 
repeatable rule (you can't go past it with SKIP).


NONE is also repeatable, and if you look in the code, I have to take 
care of this too separately. This mean, we can't parse none of datatype 
none! by using the NONE keyword, but we can using a datatype:

>> parse reduce [none] [none] 
== false
>> parse reduce [none] [none!]
== true


So it raises the question, if the NONE keyword should be there? What 
are the consequences, if we drop NONE as a keyword? And are there 
other repeatable rules beside END and NONE? In R2 or R3.

It may be faster to drop the & from the entities and change the rule 
to:

any [thru #"&" [ne | mark: (insert mark "amp;")]

I'm putting LOAD-CSV in the %rebol.r of my dbtools, treating it like 
a mezzanine. That's why I need R2 and R3 versions, because they use 
the same %rebol.r with mostly the same functions. My version is a 
little more forgiving than the RFC above, allowing quotes to appear 
in non-quoted values. I'm making sure that it is exactly as forgiving 
on load as Excel, Access and SQL Server, resulting in exactly the 
same data, spaces and all, because my REBOL scripts at work are drop-in 
replacements for office automation processes. If anything, I don't 
want the loader to do value conversion because those other tools 
have been a bit too presumptuous about that, converting things to 
numbers that weren't meant to be. It's better to do the conversion 
explicitly, based on what you know is supposed to go in that column.

Debugging some live code here .... I wasn't expecting 'parse to drop 
the last space in the second case here:
        parse/all " a" " "
        == ["" "a"]
       parse/all " a " " "
       == ["" "a"]
So after the parse, it seems that " a" = " a "

Any thoughts on a quick work around? Thanks!

Your name in lights......

If you don't appear in this collage of REBOL users, drop Massimiliano 
an email with a photo, and he'll add you:

    http://www.rebol.org/view-script-images.r?script-name=rebolusers.r
    http://www.rebol.org/view-script.r?script=rebolusers.r

I prefer it always runs as standalone console, even at first time. 
If user wants then he/she can INSTALL or starts DESKTOP.

So I can send rebol.exe to anyone and tell him just drag & drop that 
script file onto that exe file.

And just in case: _THANKS_ a million for the new hostkit code drop, 
Carl (and everyone else who helped make it happen)!

I consider the current hostkit drop to be hostkit version A100. The 
next hostkit to be released should (and hopefully will) be A101 or 
later.

The "current hostkit drop" is not a release, it's a prerelease.

I just found Henrik's summary. I think it is the post I had in mind:
---------------------------------------------

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.

Reposting from R3 chat (which seems a bit quiet lately).


I've been looking at the rich text gob! functionality and it seems 
the following dialect commands are supported:

	anti-alias logic!
	bold [off]
	italic [off]
	underline [off]
	size integer!
	left|center|right
	drop integer!
	font object!
	para object!
	caret object!
	scroll pair!
	string!


Are there any I've missed? Any doco on this yet? I havn't figured 
out how to use drop or caret yet. Anyone have any working examples 
for these?


A design question: is there any reason for retaining font and para 
support given that we could move the few remaining unsupported words 
out of those objects and into the dialect itself? (e.g. have the 
dialect directly support font names and valign words).


Also, it would be nice if we had control over the default font name, 
size and alignments [at the very least]. Perhaps a system/view/text 
object?

drop discards the n previous pushed commands in the block stream.

[italic "italic" bold "bold+italic" drop 2 "no-more-bold-italic" 
]

there is something regarding 'drop that may cause crashes. this will 
be fixed, when cyphre gets around to it.

system/dialects/text is handy. Seems the shortcut b, i, u and nl 
words are not yet implemented/working. 'drop is cute, and I note 
that 'drop without an argument defaults to drop 1.

Robert i think 2 years ago the reply from carl was christal clear 
VID3.4 is not what he wanted  drop it he would do VID alone when 
he get the time and in the mean time 2 years 24  month  we lost  
an opportunity to motivate ourselves to get VID 3.4  tuned up

Maybe Lotus notes is looking good now, Maybe.... 

But I had so many bad experiences with that crappy app, in the past.
No respect of the GUI santards. (F5 to quit).
No drag and drop.
Lof of useless confirmation boxes.
Useful actions hidden in deepest menus I ever seen.
etc...
It was a pain in the ass just to write a simple e-mail.

I've got basic pop-up working for the drop-down, but it's not finished 
yet.

From rm-asset.com website - "# R3-GUI Library: Our internal extended 
and enhanced VID. We add a persistent layer so that GUI elements 
can be stored into a database backend. Further we added element-tree 
traversal code to simplify accessing GUI elements. Beside this we 
develop a bunch of GUI styles like TABLE, DROP-LIST, DROP-TREE etc." 


What's persistent state for GUI good for? And also - why the element 
traversal code, if we can use path in gobs and their "panes"?

persistent: If you want to store a form you need to get the relevant 
information from your styles. For example: which ID was selected 
in a drop-down box, sort-order of tables etc.

I know that it is probably preliminary topic, but as for UI skinnability 
- will skin allow to have different metrics to the style? I mean 
- I don't like how e.g. scrollers are big, the same goes for arrow 
for drop-down - they should be something like 80% of what they are. 
So I wonder what will skinning be about - only to differently draw 
inside the style area (container), or will we be able to even change 
metrics (size)?

Robert - I have further questions towards "skinning", inspired by 
short chat to Rebolek .... what if different platform treat fifferently 
style behavioral aspects? I mean - drop-down under OS-X might behave 
differently from drop-down under Windows. So - it is not about having 
different color here or there. It is not about having different metrics 
to style. But it might also involve different reaction to events. 
I think that can't be solved by just "skinning". We would have to 
have differenct, platform specific stylesheets, loaded upon launch 
of the script ...

and more complexity you will add to your engine more unexpected problems 
you will face...


 Like what we experienced in area-tc... suddently our perffectly working 
 engine under wnidows XP shows strong bugs in rendering just by arriving 
 on windows7. After 6 month in searching the why  and not finding 
 any cause to that rendering jam I by chance tryed the ultimate thing 
 no programer does i retro versionned back like 10  version below 
 the rendering engine and there suddently i found that rendering problems 
 disapeared by miracle...


I spend 10 times more time searching why the rendering was defective 
on windows 7 than doing area-tc and viva-rebol.r.  And that's too 
what  completly killed my mood. What else can i do than try to make 
this community know my experience with extensive text processing 
in draw with R2 to not have the same conceptual lacks repeated in 
R3.


And clearly  in R2 the text commands in AGG/draw were not suited 
for docuement rendering... That  doesn't means AGG can't do it ... 
that means at that time the dialect draw wasn't designed to exploit 
 intensivly text rendering. I always said before runnning you have 
to learn to crawl, then to stand up, then to walk. for me the way 
i  saw the realisation of a rendering engine text oriented for draw 
dialect was first step changing the color of  choosen elements in 
the text, then changing the font spécificity anytime anywhere in 
the document then being able to do strong text manipulations like 
moving by drag and drop paragraphs, inserting multimedia content 
in the document, scaling paragraphs etc... 

ROBERT: 

In fact that depends what  the rich text engine aims ... for example 
read only rendering is pretty different of  real time editing wisiwyg 
engine... The complexity betwin both approach is like 1 to 100...

And plese - tell me if you are interested in such hints, as it might 
get you nervous :-) We like pre-releases, but so far my feeling is 
- Gabs VID3 was able to show us Image Lab demo - resizing IIRC, drag 
and drop, alpha channels, changing mouse pointer ... then came the 
VID3.4 from Carl, it felt lightweight, but did 70% of Gabs VID? And 
now we are seing some XY percent of functionality of Carl's VID :-) 
I just hope it' still just work-in-progress, but I really wonder 
if stuff like validation is important now, in a state where there 
is very few usefull styles?

http://94.145.78.91/files/r3/gui/247.png


Tab boxes now support drag and drop. I'll provide a built version 
tomorrow as I found a build problem tonight, so you can try it out.

Drag and drop - nice feature, about tab preview, I am not sure about 
that one. It felt a bit distracting last time I saw it. Can it be 
turned off as a feature?

Yes, absolute positioning. You can't do for example drag'n'drop without 
that.

ok, then appearance wise, it should use identical draw blocks? E.g. 
in Windows apps, arrow is arrow, being it part of drop-down, spinner, 
scrollbar - still the same style?

As for the consistency, and my complaint that the whole gui is not 
build with unifying idea - it has NOTHING to do with the skin. Just 
look at arrows:

- arrow button
- arrow button of scroller
- arrow button of drop-down
- arrow button of text table


Those are all different, and this is exactly the reason why some 
ppl try to do comound styles - to have just one arrow. If you are 
not carefull, you end up with above different arrow representations 
...

Pekr, backdrop is the window back drop. it's automatically added 
to any window to force proper redraw of the entire window frame.

Very short initial report to the new release:


- keyboard area text hilight problem still persists (when hiliting 
from the bottom up, only one line is hilited)

- drop-down shold be closeable by - clicking elsewhere in the gui, 
clicking arrow of drop-down, or hitting ESC

Pekr,

text hilight problem

text highliting is not yet reviewed so it will be probably fixed 
in the next week.

drop-down shold be closeable by

we'll be adding more robust system/user shortcuts system soon so 
all styles controls will be corrected during that round

Just as you don't seem to have the need to drop all strings ...

In fact, this blocking mezz-level CALL is used in worker process 
where it's allowed to wait. Right, WaitForSingleObject is the correct 
way, this CALL was just a quick adaptation of my async version for 
Cheyenne (I needed to pass environments variables to a child process 
for CGI support),  but I think I'll drop it in next Cheyenne revisions 
and use a different approach.

pretend something is more secure than it actually is

 - the biggest security concern of R3 is making sure that outside 
 code can't modify the code of functions.


There are various tricks that can be done in order to make sure that 
doesn't happen (putting calls to function values in parens, APPLY, 
SECURE 'debug). DO of blocks and parens don't need the APPLY or DO 
in a paren tricks in order to make sure they can't modify the calling 
code because they can't take parameters, so you can DO blocks and 
parens without changes to your source code - SECURE 'debug doesn't 
require changes to source code. This means that less effort is needed 
to make DO of blocks or parens more secure than DO of functions that 
can take parameters. The same goes for DO of any non-function type.


If you constrain DO of paths or words with functions assigned to 
them to not be able to take parameters, then they would be exactly 
as secure as DO of blocks or parens, and can be called with the same 
code - no additional code wrappers or screening would be needed. 
This would make DO of words or paths a drop in substitute for DO 
of blocks or parens.

Ladislav: it really does not matter, how accurate is my message or 
your reply. If we want to be 100% correct, than you are of course 
right :-) My message was a general claim meaning, that even in the 
time of active R3 development, there were not many ppl using R3, 
and there was even less ppl using R3 actively under linux imo (which 
is quite logical, as for a long time R3 was primarily developed for 
Windows only). 

Is there any related ticket

 was important part of the message re possible WAIT problem underl 
 Linux. The only possibly related is http://curecode.org/rebol3/ticket.rsp?id=1861&cursor=2


So - before I download R3 for Linux, drop it to my linux server, 
and spend my time experimenting, my question could translate as - 
what should be the mentioned problem with WAIT under Linux all about?

well,  I will use the to-block form and if that errors out drop back 
to flatten

2. I'd drop all makefiles you did not personally test/use, for now. 
I just assume that means only make-gcc will remain. Then either leave 
that in make-gcc/ or move it to the toplevel again.


But I would not fuss about the makefiles much, same thing here: we 
can restructure that later on.

changing my previous suggestion for 3.:
3. drop non make-gcc makefiles for now
4. move the gcc makefiles to sub dirs per platform

additionally i'd suggest the following revisions:
5. remove reb-to.h, pass TO_<target> as compiler flag
6. fix bug#1658: link linux binaries against libdl

Oh, and BREAK/return works in the parens in PARSE rules in R3 - it's 
a drop-in replacement for most uses of RETURN in those same parens.

They're a mess here too, but are more useless because they can't 
be searched as easily once they drop off the history, and the relevant 
people who would make the changes aren't generally here that much.. 
CC is a much better place for this kind of thing.

Nah, don't mind. I just drop the /View fix and forward-port the other 
two.

Yes, I did a bad move with my git client and created two branches 
instead of one. Looking in github for a "drop branch" button.

changing currently my serverbackends from rebol to luajit/FFI. what 
a relief and cool experience to just drop some c header inline and 

access the appropiate lib in seconds. the mapping is nice also.  
thought that this feature is quite important for Red.

Otherwise we can just drop the whole attempt at easier integration 
with C and go with a much more sensible storage layout dialect (think 
e.g. Erlang bitstrings).

Now that variable arguments and RTTI are available, I have re-designed 
the basic screen printing functions. I have inserted a _ character 
in front of all PRIN-* functions, as they should not be used anymore 
in the general case (I might drop them completly later if they are 
not useful anymore). 


Before releasing it, I would like to get some feedback first. Now 
only the polymorphic PRINT and PRINT-WS (inserting spaces) functions 
should be needed. LF, CR, TAB, SPACE have been declared, so can be 
freely used in print blocks (or anywhere else). Variadic and typed 
functions have now a relaxed syntax, allowing to pass a single argument 
without enclosing [ ] brackets.

PRINT: print one or several arguments one after each other.

PRINT-WS: print one or several arguments, inserting a space character 
between each arguments.

Here how it looks now:

* printing without newline

    print "hello"
    print 123
    print ["hello" 123 tab "world"]

* printing with newline

    print ["hello" lf]
    print [123 lf]
    print ["hello" 123 tab "world" lf]

* printing with space inserted

    print-ws ["hello" 123 "world"]
    print-ws ["hello" 123 tab "world" lf]

I thought so, so why not drop the callback attribute and let the 
programmer decide whether it is used as a callback or not?

If we drop 'callback attribute, 'stdcall wouldn't be needed, as it 
is the default convention used by Red/System.

This might be the best option currently, as it would just require 
users to change 'callback to 'cdecl in most cases and just drop the 
'callback attribute in other cases.

Is there still GTK on MeeGo, or did they drop it completely for Qt?

Currently we have a way to force (re)compilation (with COMPILE), 
but we don't have a way to drop previous compilation.