AltME groups: search

Adrian, the order of arguments are preserved in the spec, but the 
order of types in the typespec for a particular argument are not. 
That is what I meant. Do you also want to search for functions that 
take multiple arguments, by the types of each of those arguments 
(their names don't matter), in the order specified? If so, why?

I'm having a lot of trouble coming up with a use case for that behavior 
in REBOL.

Or a way to specify it that is simple enough for a function that 
is, by its very nature, primarily used by people who don't know what 
they're doing, if only for a moment. I use HELP often, but only when 
I need help.

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

I mean you typically have a clue to the datatypes for particular 
kinds of operations

Any experience in a language with C-like syntax trips you up, for 
instance :)

yeah, I found that I had to make a significant mental shift to grasp 
REBOL - all of a sudden though, it became clear - almost an epiphany 
- I think btiffin had a good list of the various stages of understanding

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.

it's been baking for quite a while - but I can smell the goodness!

I learned a lot about R3 by writing R2-Forward. Perhaps you can learn 
something by reading it.

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

It's not meant to be a quick reference - it's meant to be read thoroughly. 
The code is written for clarity where possible, but also optimized. 
There's about 8K of comments too.

The R3 docs will explain the differences, where necessarr, eventually. 
For now, consider that a function is defined in R2-Forward to be 
evidence that it has changed.

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?

There are some gotchas - I didn't redefine any R2 natives in the 
main module. That is on my todo list for a suplementary module.

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.

what OSGi is or is becoming is a similar environment as IOS, if I 
recall some of the details. With distributed OSGi, the services that 
make up an application can be located anywhere

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.

If you want it all together, post it in Tools/Reb-Services. We already 
have a good handle on the module system, even if it's not done yet.

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

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

I had not noticed the 'pu command, but I guess it would be a public 
message stored in the folder for the user.

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.

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 ...

Somewhere in rebdev. We have a high level GUI thread there. Might 
as well create a low-level one too.

I was thinking about CureCode for a while, as a "wish" requests, 
but not sure if we should "flood" it with such a stuff. Maybe a RebDev 
is better place, but Cyphre might not read it, because of its, well, 
"comfort" :-)

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?

Steve, I'm trying to "capture" the source of LIST-DIR in a separate 
file, but I don't have the syntax quite right.

R3	>> SAVE %listdir.r SOURCE LIST-DIR	<-- donsn't work, I'm not sure 
how to sturcture this command

Try
  mold :list-dir
to get the source in a usable form

:xxxx -- gets you the value of xxx
mold -- makes it a string

it doen't work currently, i think it's a bug, ask Brian before to 
post a new bug

The relevant portion of the LIST-DIR source is this:
    switch type?/word :path [
        unset! []
        file! [change-dir path]
        string! [change-dir to-rebol-file path]
        word! path! [change-dir to-file path]
    ]
You should try SOURCE MORE for a simpler example of this method.

LIST-DIR is one of the console interactive functions, so it is acceptable 
for it to have an optional parameter without a refinement - otherwise 
you should avoid that method. The function you should use inside 
code, rather than interactively, is READ.

In R3, have we a function to replace a list of values by anorther 
one currently ?
(don't remember)

in a string

Can someone enlighten me: Will we have the Wiki and Carl's R3 docs 
side-by-side? Isn't that a double effort? I don't get it.

About LIST-DIR:

R3 have some UNIX kinda commands, like ls. I think, Carl was tired 
of typing:
list-dir %script
and just wanted to type:
ls script


But it doesn't work with /c, because it's seen as a refinement datatype, 
and ls doesn't allow that. It's a mistake, as I see it. You can do 
it by:

myls: func ['path] [ls (form path)]
myls /c

Geomol, refinement support sounds like a good idea, but it was left 
out on purpose because /c would work but /c/d would not. It is better 
to get people out of the habit now than it is to have to explain 
why /c/d doesn't work, over and over again.

Steeve, try REWORD - it is not a modifier though, it builds a new 
string.

There is a plan to add this as an option to REPLACE as well, and 
that is a modifier.

Robert, the R3 docs are a manual, while the wiki is community-generated 
articles and such. Not the same thing.

Like I said, there are plans to make a modifier version of REWORD 
as an option of REPLACE. The escape character makes sense for template 
word substitution use, the main purpose of REWORD - it was Carl's 
idea.

Steeve, one of the problems with multiple value replace is that there 
are basically two ways to do it:

- One value/replacement pair at a time (like your FOREACH loop above).

- In order using either an inner loop of FIND/match calls, or PARSE 
rules and alternation.

Neither of those are very efficient, but the PARSE rules tends to 
be more so, at the expense of building the rules. REWORD uses the 
compiled PARSE rules method. Most of its overhead is working around 
bugs in map! or going away with new REBOL features. If we do an inplace 
replacement, we'll have the same overhead. The only solution is to 
optimize the runtime, or hand-write the PARSE rules.

i make a proposal:

Most of the times, we use the same rules several times on different 
data.
reword should be able to not reconstruct the rules if so.

I used the similiar tricks in some scripts, for example:

map-chars: func [
	{replace/all pair chars in a string}
	data [string!] values [block!]
	/local chars pos
][

 ;** if the first value in values is a bitset, do not reconstruct 
 the bitset
	unless bitset? chars: first values [
		chars: make bitset! 256
		forskip array 2 [append chars array/1]
		insert values chars
	]
	pos: data
	values: next values

 while [pos: find pos chars][pos: change/part pos select/skip values 
 first pos 2 1]
	data
]

data: "Hello You"
map-chars copy data values: [#"s" "SS" #"t" #"T"] 
;** the second call is faster
map-chars copy data values

Cool Steeve.  You should be a way bigger part of the REBOL team.

Replacing single characters is all you need? That isn't general enough 
to make it into REBOL, but it might be a good library function.

In your case, it could be an object or a parsing rules instead of 
a bitset

yes or a funtion :)

Docs/Wiki: I know the difference. How much content is overlapping? 
I see a problem if we maintain two lanes of documentation regarding 
concepts etc.


It's again the fragmentation problem that makes it so hard to get 
R2 details collected and structured.


IMO the Wiki is one of the best things that happend to Rebol. Finally 
most information in one place.

Cool John.  I favor a glosser look myself.

http://hmkdesign.dk/r512.png

An old icon I did a few years ago.

I like John's R a bit better.

Geomol, I made a very primitive SVG importer for R3. it can only 
handle one shape in one color, but it's nice if you need to draw 
it by hand. If you need it for complex shapes, let me know.

WTF .... while sitting in a pub, having my 3rd good Czech beer, I 
plugged my USB pen in, started R3 and run Demo. I looked at what 
it does so many times, but never looked at the source. While VID 
3.4 contains only basic styles, when looking at various panels, I 
always thought - the code for this screen has to be some 5 pages 
long. WTFonce again - 10 - 15 lines of code with such a functionality? 
Awesome .... I think I will become even more REBOL fanatic ;-) ... 
Cheers :-)

... but really, looking at SharePoint portal sources last week, and 
now into VID source, is quite a difference. I think that most of 
the systems out there, especially the big glory web and JS - are 
just - crap.

PatrickP61, that is a known bug: http://curecode.org/rebol3/ticket.rsp?id=615

add eyes to do a smiley inside the R  :)

Thanks, I'm not 100% satisfied with the bottom. It looks like it's 
bending outward. A dark line or something would make it better.

It's really a mess. Some from Gabrieles example. It's split in 2 
scripts to make the table mirror effect. But you can have it, if 
you want?

----  Cross-posting from DevBase -----

window: view [t: text ""]


window is set to a gob which is useless to me.  t is totally lost 
and I can't modify it.  What to do?!?

Ammon, you can pass 't to a function used inside the layout, if you 
want. I'm genuinely not sure where in the system the face would be 
stored as I've not encountered a situation yet where that would be 
needed.

Oh yes, looks like Ammon's right, actually. Each Face has a reference 
to its associated Gob, but the Gob does not have a reference to the 
Face. So if you only have the gob, you can't get to the face, where 
the variables like 't can be found.
Just reading the source - correct me if I'm wrong.

I'm not sure it does. It's not meant to be poked and hacked like 
VID can be. You go through proper channels, because the proper channels 
are actually there now. :-) Also the built in debugging functions 
can provide a lot of information.

Anton, the style actors, reactors SET-FACE, GET-FACE, SET-FACET and 
GET-FACET are there to affect the given face in the way it is intended 
to be, encapsulating the functionality in the right places, so no 
hacking is needed. You just create a new style with altered functionality, 
if you need it.

(It's obvious to me, anyway. I haven't done that much except a few 
experiments and reading here and there.)

I have, and the actors provide everything you need and you can be 
as elaborate as you need to be, process any events anywhere you like. 
There are even specific functions to override actors, in case you 
need to make a small addition to a big actor, when creating a derivative 
style. You can also create new actors. This is not much different 
from what VID3 had, except it's easier to program.

(in that, there may be a different, but just as good a method to 
do it)

but other than that, enabling debugging lets you see the inner workings 
of a face

Anton, ah, it can't do that from a text label with nothing in it, 
of course. Try something like BUTTON instead.

I have a style that displays its current size inside the View window 
at all times. Perhaps this can be added as a debugging feature.

Modifying the style code could be quite uncomfortable, when you just 
want some information quickly. I don't want to have to mess with 
files just to print a bit of custom debug info.
More debug outputs could alleviate this discomfort somewhat.

I think it's possible to create a debug function that returns a facet 
for a given face when a given event happens, like:

get-debug 'my-face 'text-body 'on-make

Gobs that are the top gob for a face have a reference to the face 
in something like gob/data, as I recall.

I want to get to 't because I'm trying to hack together a GUI for 
DevBase because the console client is painful to use and I thought 
this might be a good way to introduce myself to some of the internal 
workings of the new GUI.  I want to redefine "say" in the chat.r 
to update ''t with the text it would normally print.


To have changed what VIEW returns such that I can't actually get 
to the face produced is unbelievably confusing.  There must be a 
good reason for it though, what is it? 


You do realize that if I have no way creating a pointer to a face 
then I can't use get-face, set-face, etc. on it don't you???

I'm familiar with the fact that set-words are being defined in parent-face/faces 
which is why I used window: view [...]  I thought I was going to 
be looking in window/faces to get to t but View is giving me a gob 
instead of the face that I need.

I need a solution to a problem and that solution very well may be 
a paradigm shift on my side.  I just need to know how to interact 
with the GUI from outside the GUI code OR I need an explanation of 
why the ability to do has been removed in the latest release of R3's 
GUI.

The truth is, I can hack this 1.6 billion different ways.  I DON"T 
WANT TO HACK IT!!!!!  I want to use the system how it was designed 
to be used.  Simply example hack...


view [t: text "this is a test" button "Mwahahaha!" do [set 'txt t]]

The fact I can use the set trick in a reactor means I could prolly 
do the same thing in an actor, on-make, for instance.  It's not an 
issue of not being able to hack it.  I'm not looking for a hack. 
 I can hack just fine.  I want to know how the system is SUPPOSED 
to be used.

Something I did in my code all the time with VID 2 is window: layout 
[ ... ]  then go ahead and connect/modify/abuse the window in any 
number of ways and then show it later.  I'd often set up panels this 
way so that I can have the faces built ready to switch out at the 
click of a button and this would allow me to easily keep different 
areas of the GUI in sync easily but now that Layout is gone I can't 
do it this way.  The real question here is why is view returning 
the gob instead of the face?  Seems on how I actually have the GUI 
source code sitting on my machine, I can hack this to give me what 
I want the problem is, it would be a hack which means that I can't 
hack it to give me what I want because what I want is not a hack. 
 Get it? ;-)

Noted.  I'll put together a shorter, sweeter post for RebDev.

Is there a place that teaches people how to post to RebDev in the 
first place?

I'm actually not seeing anything in the new GUI that allows you to 
find a given face's parent.  It's really very frustrating me...

Well...  WTF do you know?  

window: view/no-wait [t: text "this is a test"] 
set-face window/data/faces/1/names/t "Mwahahahah"
show window
do-events

I posted my reaction to rebdev chat too. I am missing some aproach 
to easily traverse gui:


- there is bog/pane, but not face/pane. There is face/faces e.g. 
for panel style. If it is the same concept, why name it differently?
- there is no face/parent-face to traverse backwards

- face/gob contains just one gob. It also seems to me, that it is 
not even a pointer to the gob, but not sure. Not sure if it would 
be usefull, but currently face can't be built from multiple unrelated 
gobs. You have to have one gob, and other ones in gob/pane

Yup. I read it.  You did a very good job of describing what's been 
annoying the hell out of me for the past 4 hours.  Hopefully we'll 
get some straight answrs to all of that.

I post here what I posted elsewhere. I refuse to use RebDev - another 
non-web UI for "supporting development".  With nice features, no 
serious back end (imagine real user amounts like, a few thousands 
using this...) and no UI. And to have to move yet AGAIN....

Maarten, a few thousand? Not likely to happen right now and as Carl 
said, he would add features as needed, and there's no need to support 
a few thousand users right now. Right now the next step is a proper 
GUI.

Henrik, my point is that you never get to a few thousand this way, 
let alone serious world domination. I'll probably check on R3 when 
it  "surfaces".

Maarten - I did agree with your POV and told Carl, that RebDev kills 
Altme. But - his reply made sense to me. We should not see it as 
a threat to Altme/web (yet), so let's suppose current RebDev is nothing 
more than CVS with ability to chat to whatever topic or file ...

I'm updating DocBase GUI docs.


1. Changing the links at the bottom of each of the pages to point 
to a single template so that they are automically updated across 
all pages by changing one document.
2. Adding [[Category:GUI]] to each of them.

3. If I have time I'll start working on a VID2 to 3 document that 
describes what changed.  Things like face/parent-face is now parent-face? 
face.

Yup, Paul, that's a known bug.

Someone, BrianH I think, posted a link to this group (I think) to 
a document on DocBase that talks about the performance differences 
with some of the loop functions in R3.  I can't seem to find it though. 
 This is why MediaWiki bothers me.  It search sucks.

I would like to see such a document as well. I know that the loop 
functions in R3 are faster since they are all native, but I don't 
know how much faster. Clearly if I was the one who posted it I forgot 
where it was too :(

Paul, yes, this is due to one text area trying to load the source 
code for the original version of the demo, which doesn't exist anymore. 
However it throws a different bug than it should, so it's lucky that 
it came up.

Ammon, BrianH, it's search sucks: Which is why such a document should 
be a cookbook recipe. Easier to find.

anyone has tested size-text on a gob ?

is there a problem?

i get  a wrong size/x