AltME groups: search

I see no point in modularisation of current R3. It is still small. 
I just wish that we do plug-ins and interfacing, tasking, in really 
good way = good for concurrency environments ...

Having separated contexts and being able to manage them well is a 
big deal, for security and for ease of programming.

this is a serious flaw in R2... if you want to store encryption keys 
within an application and want to provide some sort of plugin interface, 
you are pretty much fucked... people can rip your application appart, 
and there is nothing you can do about it...


a part creating a dialect, which is complicated as hell if you want 
to provide do-like syntax.

Yup. And you can have bad moments even if you are a good programmer. 
That's what this group is for :)

it would be nice to be able to use the information they contain in 
the resource parts, basically auto-describing the dll themselves...
and use class members... in some way or another.

Altme is still the place to learn about Rebol and undocumented functions!

It would be nice if we ask users to present examples etc in a structured 
format so that we can data mine the information here and publish 
automatically to a knowledgebase.

Years ago I released a program that collected all the mailing list 
into a personal database .. and I allowed users to execute programs 
in the emails if they were enclosed in blocks .. an old Rebol trick.

We can create rules to try and rein in the anarchists

How about putting a Rebol [] header in front of examples?  then a 
parser would at least know to start from there .. until it hit some 
syntax error and would then know the example had terminated.

It also makes it easier to copy-run the examples. If you have a rebol 
[] header in front of your code, you can copy it and do clipboard://

I have been teasing my script into action and not asked any questions 
for hours... now I am off to bed.

And the ability to edit previous messages to correct errors.

Something I have learnt today...

I have been looking again at some of the examples I have been given 
here & now I have a bit more understanding of Rebol I am able to 
reformat the examples into multiple lines and indent them appropiatly 
which makes them more understandable for a noob like me. I needed 
enough understanding to see where one complete statement part ended 
& the next one began before I could do this. What I have learnt is 
that I should have tried harder, sooner to do this & it would have 
speeded up my learning...


I am looking at graphics today & giving parse a break for the rest 
of the weekend.

Is there a document that describes each feature in view and all the 
options etch please?  e.g. for slider

So far I can find tutorials that mention some aspects of slider, 
but nothing complete.

First, there needs to be a distinction between VID and View. View 
is the basic display engine, faces, feel. (lower level). VID is the 
layout dialect, styles, etc. (higher level)

yes and no. it's a VID face, which is a more complicated version 
of a face. You would typically lay it out with VID and you would 
use and manipulate it with View functions.

You could create and manage a layout with View alone, but it would 
be a lot harder, since you have to specify faces manually. That's 
why VID was created.

Then there is also DRAW, which is another engine used in conjunction 
with View. In REBOL 2 it works as a slap-on solution to more complex 
drawing with anti-aliasing, etc. It also has a separate font rendering 
engine, but DRAW is close to useless for layout. It's best for pretty 
drawings, that do very little.


REBOL 2 generally suffers here with multiple overlapping solutions 
for slightly different purposes, so it can be a bit confusing. View 
and VID is probably the most hacked part of REBOL.


In REBOL 3, DRAW is the only engine combined with the concept of 
GOBs: Light weight graphical objects. There are now 3 wholly separate 
parts and that concept is much less confusing.

VID (and slider) is not very well documented.

If you do:

? face


you'll see that a face is a simple object. If you do something like:

f: make face []

view f


It'll display a gray area in the upper left corner of your screen. 
View simply takes that object and converts it into graphics.

That's about as fundamental you can get. Now, a more complex layout 
consists of many faces and this works by grouping them in a tree 
of objects.


In the FACE object, there is an entry called PARENT-FACE, which is 
how faces are grouped together in a tree. PARENT-FACE can be another 
face object or a block of face objects.


This is fundamentally how a typical View layout works, and you can 
build a layout like this by hand, by creating each face, setting 
position and size, color, text, etc. for each face, and put them 
together in a tree and display them with View.

I see the grey square...  and I probed f too to see how the object 
is made..

Click the "local" text and it will connect and allow you to download 
the script.

After this, probably go to Demos and Easy VID, for a simple VID tutorial 
(unfortunately it was never completed, but it has good parts)

Thanks for your help again :-)  I can see I could spend hours looking 
at the tree view alone...

I had a quick look at the view top when I first instaleld it, but 
it was all too advance for me then, and then I forgot that it existed.

I'd say learning to build new styles with the stylesheet system is 
the first big boost in productivity.  this will inevitably leed to 
you wondering how you can change this or that, and then by probing 
the face and looking at its code, you see that some values are being 
reset in the event handler... which is quite annoying.


the seconf big boost is to try and understand the event system.  
the view reference link that henrik gave you earlier is the best 
resource online.

and rebol, as a language is extremely easy to search on the net... 
you start any search on google with the word REBOL  and you'll end 
up with mailing list chats, altme pages, scripts on rebol.org, etc.

this is simple, with gfx and goes over everything, just to get you 
going... Its the only docs we had for years!

This is of course not the way it's meant to be. Unfortunately VID 
development stopped a long time ago, but there are alternatives, 
like RebGUI and GLayout. All energy is now focused on bringing an 
incredibly improved and highly well documented VID to REBOL 3.

Yes, one thing we really need in the Rebol world is for someone to 
site down and create a full example set of what is possible with 
what we have.  I too am pretty weak with VID and View, but it's been 
something I think about every time I see a new Javascript library 
with lots of examples available.

mhinson.  To give you some perspective.  Carl never intended VID 
to be the end-all-be-all graphic system.  He said he built it over 
a couple of days and expected someone to use that as motivation to 
either build their own or enhance what was started.  Ashley Trutter 
created RebGUI, which is more complete that VID.  He also received 
awards at Rebol DevCon's for his efforts.

The space 0x0 and 1x1 should work. Otherwise try space 0 and space 
1.

space works on elements from when SPACE is stated and then the space 
will stay that way for the rest of the layout description or until 
it's changed. If you want specific spacing between elements, PAD 
is used.

yes, that's fine, because that is an action of the button. The action 
is a function with 'face and 'value passed and is regular REBOL code.

ok, i moved the changes to outside the layout block, but this dosnt 
work
	my-sldr3/dragger/color: red 

and this button dosnt redisplay the layout, it just overwrites the 
existing stuff.

 button "Cente" [my-sldr2/size: 100x40 show mmm]  ;; this breaks, 
 but does make a change

I am guessing that the display is not dynamic in the way I am expecting?

When altering a facet of a face, it must be shown before the change 
can be seen.


This is a little complicated to explain: You have chosen to resize 
a slider, which is a face with subfaces. Thus if you resize a slider, 
you need to access its internal resize function, in order for it 
to properly resize the knob as well. if you alter the size of a face 
like above, you are literally only altering the size of the outer 
face of the slider. VID does not know what you are trying to do there.


BUT: Given it's incompleteness, SLIDER does not have an internal 
resize function. :-) This is not intentional, and you've stepped 
into the mud here. This is one of the most lacking parts of VID, 
in that when the layout is set up, it can be laborious to change. 
Fortunately there are unofficial solutions to that, so I suggest 
you don't bother with this and try something else.

Alternatively, try working a bit with RebGUI.

Resizing a slider is on reflection a fairly odd thing to want to 
do, and I was only doing it because "size" was the first thing I 
came across that sounded straight forward to do to test my understanding. 


On reflection, I think that it is unlikely for me to grasp much of 
what can be done with VID until it gets a makeover with the documentation. 
Perhaps I could contribute to the documentation on the Wiki by listing 
all the items that can be changed for slider & then discovering what 
each one does by trial & error.  would this be helpfull, or just 
cause another job for someone to delete it in favor of a master plan?

At this point, I'm not sure it's worth documenting more. Perhaps 
2-3 years ago. 90% of work is currently directed toward VID for REBOL 
3 which is an entirely and far superior GUI system.

I looked at RebGUI and had a play with the demos. Afraid RebGUI looks 
as if it would be even more complicated. I may as well start learning 
about R3 graphics as by the time I have learnt R3 I expect  R4 wll 
be in development.  :-)

R3 is still alpha software and the layout engine is going to be changed, 
since it's not laying out faces correctly many times, but the dialect 
is not likely to change. There are also only Carl's styles available 
in strong colors, and they are not so good looking.

but the underpinnings with GOBs, text and DRAW is fairly stable. 
it's fun to play with.

there is also glayout, which works very out of the box and is built 
over VID.  the api isn't document though.


you can look at the glayout-demo app on rebol.org so have an idea 
of all it can do.  it layout engine is very complete, and seems like 
the basis for how R3 was implemented... they use the same philosophy.


glayout handles ALL resizing automatically, and it even includes 
real scrollpanes, which react to content, as it changes (scrollbars 
resize automatically, for example)

Thanks Henrik, now I have some things that work to play with.. I 
also want to study Glayout...  AND Maxim's SSH-tool project sounds 
very interesting... Off to bed now, back to parsing tommrow I think.

I am reading about these mezzaines 3 times per day here and I still 
don't have any clue what they are... I googled but found nothing 
either.. .so what are mezzaines?

In the Rebol console, look at the help for, for example, Foreach 
and Forall.


Under the description of Foreach, it says "FOREACH is a native value" 
- this means it is implemented directly in C in the interpreter. 
 FORALL says "FORALL is a function value" - it is written using other 
Rebol commands, and you can see the source of it using "source forall". 
 Mezzanine refers to this second type.

and staying small enough, i think

Hi, I am puzzling over this and would really appreciate some pointers 
please.  How do I get from this:
d1: "random1"
d2: "data2"

;;to this?
b1: [random1 ["data2"]]

so I can reference the data2 by its association with random1 e.g.
b1/random1/1

I was hoping to get something like this working with the data structure 
Henric helped me with above.
foreach bb b1 [ print b1/:bb/1]

but the foreach itterates all the vlaues, not just the words.

I have been thinking about this for a week or so, but dont really 
know how to get any further with it.


I suspect that if I had the right structure I could use it to store 
my data, then add additional details when I find some more, and finaly 
export the whole lot, grouped together by the key value (that I will 
only know when the script is running).


Im aproaching this in the right sort of way?  Or is there a recognised 
way to create these sort of structures please?

I don't get what you want to do. Perhaps some sample data and the 
desired output?

You can specify ip addresses directly, as data of the tuple! type. 
Or you could have the data be doubles of strings and type flags.

Or if you would have at most one of each type, you could name the 
potential fields and have the data be name value pairs.

Or you could go positional for the different types of data, instead 
of including the flags and ips words all of the time.
dat: [key [["flag1" "flag2"] ["127.0.0.1" "192.168.1.1"]]]
foreach [key val] dat [set [flags ips] val  ...]

You suspect well, but you suspect too much.

It would be better if you knew all the data types in Rebol and their 
usages.

Currently you're only trying to "guess"  how to programm with Rebol, 
not to learn it.


I don't think it's always a good method to "give" the answer directly, 
especially when they are obvious.
It' gives some bad habits to the newcommers.
Sorry.

ok, I will continue to read the documentation. I think you are right 
Steeve, but it is hard to learn with no current programing skills. 
Perhaps I am just trying to find out how to solve my problems. 

Some of the data types seem quite straight forward, but some seem 
to need to be used before I can appreciate what they are exactly.. 
I try not to ask questions that are too trivial, and never before 
I have tried to research an answer for myself.  You maybe just misunderstand 
how stupid I am. ;-)

Mhinson, i think we all enjoy to answer to people like you.
Especially because you're a nice and psersistent personn.


But after some weeks, there are questions, we don't want to see comming 
from you.anymmore ;-)

My advices for a very efficient learning of R2.

1/ Go on Rebol.com and read all the documentation published (it's 
your bible).

2/ Go on Rebol.org and download all the scripts published.  Test 
thoses you can, read their sources and try to figure how they work 
and what technics are used.

3/ When you have questions, At first , check on Rebol.org (the mailing 
list archive) most of the time your answer is there.

Thanks Steeve, I will try not to post here any more unless I am invited. 
 I have enjoyed trying to learn Rebol & will continue, but I do understand 
that my constant questions are an anoyance, and I dont want to be 
banned from this very usefull forum. :-(

Steeve, I've been holding off in saying this but you have been pretty 
rude to a few people here over the past couple of months with some 
people.  Because you are such an expert, you are putting others down 
for both their efforts and questions.

The one thing that Rebol has that is somewhat unique, is a nice community, 
with varied talents, interests and programming experience both with 
Rebol and other languages.  I feel your sharp answers can be detrimental 
to those lurking, and push people away, such as myself and mhinson. 
 Your tolerance would be appreciated.

... and that's all I will say on the topic.

I've been programming (scripting) with Rebol for many years, on a 
casual basis, and I can't answer mhinson's question without sitting 
down and looking at it and fumbling through some of this.

My problem is I jump in for a few weeks, then jump out for a month 
or two.  I never get past the previous level and don't stretch the 
boundaries or delve into new areas.  I will always be a newbie.

I make newbie errors every once in a while too, and there are some 
areas where I am a newbie full time (like GUI and networking).

when mhinson won't feel like a newbie, he will start answering questions 
naturally, like we all do... this is what is so great about the community... 
everyone gets the help he needs and feels like he ows something back 
a bit.

I understand Brock's view here.  I wouldn't want to see this community 
break down and become what you find on USENET or IRC.

Some of us like to answer questions, and learn by doing so. This 
group is like a REBOL-specific version of the Puzzles group :)

Brian it was not my words. 

I never said to not respond (strange it's not your habit to perform 
false denouncements) 
And i gave a Hint.
Anyone else could have completed it at this time.


But it seems some of you guys ,like to bash for nothing using false 
reasons.
And that , it's certainly more offtopic than anyting else.

But i gave the index lit-word! in TFM, so it was not so mean.
And i gave him my reasons.

Mike, by all means keep asking questions here, this is absolutely 
the right place to do so.


Conversing in plain text can be tough, and the rate at which people 
can respond here--as opposed to email--can contribute to misundertandings, 
with posts coming fast and furious. And we all interact in slightly 
different ways.

mhinson has just not yet learned, how to learn a programming language. 
I've noticed that by his stumbling on every little bit of basics, 
such as lit-path and why it doesn't make sense to him, because he 
can't extrapolate how it works inside a function.

mhinson,


REBOL, like any other programming language, is a system. It's a design 
with intentions, methods and patterns and it's designer has spent 
about 25 years thinking out how REBOL should work, in order for you 
to see the elegance and simplicity of the system.


A good programmer can predict what happens in a programming language 
with a specific piece of code, not by remembering what every little 
single thing does, but by knowing how the system behaves. If you 
study the works of Ladislav (such as Bindology), you'll see how much 
time he spends on figuring out the system of REBOL. REBOL wasn't 
put together randomly. Figure out the system of REBOL and programming 
becomes way, way easier. This goes for any programming language.


It helps to, when you get to a problem, to try to figure out why 
REBOL does this and that, while you're trying to figure out how to 
solve the problem. Why do you have to pass a lit-path to a function 
for it to be understood as a path in the function?

You are right Henrik, even the programming I have done years ago 
was based on learning a set of tricks that worked in the context 
I needed, then sticking to those tricks for everything.  I can see 
that Rebol demands to be taken more seriously & I also appreciate 
the potential for "elegance and simplicity". I ride a unicycle & 
part of the appeal there is also the enjoyment of minimalism, no 
chain, no gears, no freewheel etc.


My understanding of "the system of REBOL" is about 5% I think & I 
feel like I haven't grasped enough of it yet to make my understanding 
move forward efficiently. I am just at the start of passing data 
to functions & because REBOL seems to automatically typecast a lot 
of data, it has not been in my mind that I may have to do it manually 
in some cases, but now I know that, I still can't predict which cases 
yet. 


With the lit-path! and path! data passing I understand that the invalid 
path I want to test must not be evaluated before it gets into the 
ATTEMPT section of the code, so I would expect to need to pass the 
data in a literal form I suppose (or as a string perhaps). One of 
the conclusions I am drawing from the example given is that I can 
pass this thing called a literal (I don't fully grasp what that is 
yet) but receive it in the function as a path! so it would seem that 
the passing of data to the function is also doing a type conversion.. 
At that point I don't know how the path! is not evaluated enough 
to cause an error.  If I search the core manual for "type conversion" 
it has only one mention, & not in this context. This is the sort 
of thing I do a lot to try & understand without asking too many questions, 
but my techniques must be flawed as I often fail to find anything 
relevant. (This isn't intended to be a question, just a picture of 
the muddle inside my mind).


Now I will read Bindology & hope that my understanding will be transformed. 
 Thanks again for all the help.

There are two types that get evaluated to get the value ther refer 
to and DO them: word! a and path! a/b.


If you want to just get the referred to value and not DO it you use 
get-word! :a, and in R3 get-path! :a/b, or in R2 a more complex expression 
that depends on the type of what a refers to.


If you want to set a new value you use a set-word! a: or a set-path! 
a/b: - this will evaluate as a SET expression.


If you want a literal word or path, you use a lit-word! 'a or a lit-path! 
'a/b. When a lit-word! 'a evaluates, it returns the corresponding 
word! a, not the value assigned to a. You can then pass the resulting 
word! value around, assign it to stuff, and maybe DO it later.


That lit-word! 'paf formal parameter in the first version of ATT 
that I posted blocks evaluation of the actual argument. It is treating 
the actual argument path! as a value, rather than evaluating it. 
In the second version of ATT the formal parameter is specified  with 
a regular word! paf, so the actual argument is evaluated normally. 
In order to get a path! value you have to use a lit-path! 'a/b and 
let it evaluate to get the corresponding path! a/b.

The evaluation rules follow a pretty consistent pattern, and even 
more consistent in R3. Once you get the pattern you can answer most 
of your questions yourself with a little experimentation. Don't let 
that dissuade you from asking here though :)

mhinson, BIND is all about contexts. A word is usually bound to a 
specific context (or object if you will), giving it a specific value 
that exists in that context. You can have:

a: make object! [
	b: 7
]

c: make object! [
	b: 9
]


'b is a word, but for 'c, it has one value and is bound to 'c's context. 
'a is a different context where 'b has different value.

mhinson, when I made Tretbase 1.0 engine, I used Bind quite a lot. 
 The only time I really like to use 'bind is when I have iterations 
where performance is an issue.   That way I could write a block of 
code and then just bind it into a logic based loop.  This way I didn't 
have to record additional loops to meet the logic.

Something more basic, that you may have skipped or forgotten: Contexts 
are just objects. They are just a clumped together set of words with 
values.

The big secret is revealed here:

>> source context
context: func [
    "Defines a unique (underived) object."
    blk [block!] "Object variables and values."
][
    make object! blk
]


So when you make a new object, you make a new context. The definition 
block (shown as blk in the source for context) is then bound to this 
new context. You can run ordinary REBOL code inside the object definition 
block. You are not restricted to the obvious syntax of set-word! 
and value pairs:

d: make object! [
	b: "hello"
	reverse b
]
d/b
== "olleh"


Of course after the definition block has been parsed to become an 
object, only the key/value pairs remain.

Remember that and you can get very far with contexts.

I see the bind function can do both the things I noticed above.  
I have stalled with reading Ladislav's Bindology paper at section 

9.1 I dont understand what a-word has become, and why.  I dont understand 
how 'a might be referenced in   bind 'a a-word   as it has no mention 
in the example, so I dont understand what is being demonstrated.

words: [a b c]					;**  words, a, b, and c belong to the global context.

fun: func [a b c][print bind words 'a]		;** 'it is asked to change 
the context of the words comprise in the block "words".

      ;** After that, they are not belonging to the global context anymore, 
      but to the context of the function.

Thanks Steeve.  so I use 
creature: reduce[to-word animal reduce['named reduce[breed]]]

and I have to make sure I need the reduce at every level..  In that 
case why is there no reduce option to reduce all nested blocks? Am 
I doing somthing odd that would make me want that?

the alternative is compose which offers a /deep refinement:

creature: compose/deep [(to-word animal) [(named) [(breed)]]]


and all parts you wish to compose in the block must be wrapped in 
()'s.

That is very cool...  And I feel happy that I predicted there might 
be a thing that did that too... it is much more elegant than lots 
of reduce statements everywhere.  Thanks.

;Thanks Izkata, I predicted the outcome correctly. I went on to try 
this:
D: [{bar}]                                        ;; global D
foo1: func [D][D: [] print mold append D {d}]     ;; 
foo2: func [D][D: [] print mold append D {d}]     ;; 
foo1 D  ;; value of global D passed to function (but not used)

foo1 D  ;; function references its own local value of [] to which 
it keep appending {d}
foo2 D  ;; same as foo1 but references its own [] ?pointer? thing
D       ;; still references un changed global D

foo1: func [D][D: [] print mold append D {d}]   ;; rewriting foo1 

foo1 D                                          ;; new foo1 function 
has new [] pointer

foo3: func [][D: [] print mold append D {d}]    ;; D is not passed 
to the function

Foo3          ;; now we are changing global D and making it reference 
foo3 [] pointer 
D             ;; proof global D has changed

;; I think the bit that was making it hard for me to understand was 
that 

;; referencing the same empty block in a function means the actual 
exact function, 

;; a second copy of it even with the same name, sets up a new local 
pointer. And also the unexpected localness confused me.


;; Question, do my comments show that my understanding is now correct 
please?

it is like that because I have a bunch of lines that will become 
a function & I am comparing them in some cases, and excludeing them 
in other cases to debug my code.

and you only need a single ;

Opps -- one line of code, and 100% of it is in error:-(
  doc: does [do clipboard://]

I hace CC to write clipboard://, and load-clip and read-clip as well. 
Very handy.

And sometimes it can make sense to split things up into multiple 
operations (just food for thought).

func1: func [o1] [append QQ o1  repend/only QQ [get :o1]]

I have no problems with multiple REBOL copies.. I have all REBOL 
exe files in one directory. The latest version named like rebol.exe, 
core.exe and older which I sometimes need as rebview1361031.exe for 
example

and you can't set manual paths in shortcuts, only select "installed" 
applications.  >-:(

maybe not if you are used to playing in it, but finding and properly 
setting the registry items for rebol isn't really obvious (especially 
if you add the -qs) options.

XP was designed for dumb users... vista went a step further and added 
that pre-requisite to its analysts.

I try to design software thinking people are smart, but with the 
idea that you have to learn & understand it first.  Learning curve 
has to be exponential, but start flat. 

Misunderstanding and being dumb are different.  MS doesn't get that.

Everyone is dumb sometimes, and the more generally smart even more 
often. As long as the software doesn't get in the way of doing the 
smart thing, and perhaps even enables it, that's good. If it discourages 
dumb behavior, better.

Unfortunately, the installer hasn't worked at all in the 2.7 series. 
In the 2.6 series it was broken, and in prior releases even more 
so.

In addition to what Sunanda said, if the code does something useful, 
people are more inclined to look at it, and make suggestions for 
improvements.

Hi, I have written this function and would be glad of any comments 
please.  I know it is only simple stuff but I want to try any learn 
to write code well, not just hack stuff together that just about 
works.  Thanks. 
;; Generate all IPv4 dotted decimal masks
AllMasks: has [a b c d allMasks][
	allMasks: []
	if (allMasks = []) [
		for count 0 7 1 [ 
			i: to-integer power 2 (count)	
			a: 255.255.255.255 - to-tuple rejoin ["0.0.0." (i - 1) ""]
			b: 255.255.255.255 - to-tuple rejoin ["0.0." (i - 1) ".255"]
			c: 255.255.255.255 - to-tuple rejoin ["0." (i - 1) ".255.255"]

   d: 255.255.255.255 - to-tuple rejoin ["" (i - 1) ".255.255.255"]
			insert allMasks  reduce [a b c d]
		] 
		sort/all/reverse allMasks
		insert tail allMasks 0.0.0.0
		print "Created all IPv4 masks"  ;; debug
	] return allMasks
]

Another tip while I'm here.  If you ever use the series pickers such 
as first, second etc.., then try to use them as the last item in 
logic functions.  For example:
series: [1 2 3]
if first series = 1 [true]
if 1 = first series [true]


The first logical expression will give you an error and the second 
will work correctly.

Another thought -- you may be able to avoid the block and to-tuple 
stuff by modifying a tuple:
    t: 255.255.255.255
    == 255.255.255.255
    t: poke t 4 t/4 - 1
    == 255.255.255.254

I wouldn't call it a bad example of storing series data, exactly, 
just unusual.  Look at this:
>> foo: func [/local bar][
[    bar: []
[    if empty? bar [
[        print {Generating..}
[        insert bar 1
[        ]
[    return bar
[    ]
>> foo
Generating..
== [1]
>> foo
== [1]

If the function needs to be called multiple times, the data is stored 
and doesn't need to be re-created each call, getting a pretty good 
speedup.  This is what foo now looks like:
>> source foo
foo: func [/local bar][
    bar: [1] 
    if empty? bar [
        print "Generating.." 
        insert bar 1
    ] 
    return bar
]