AltME groups: search

@DideC

Fine suggestion! I use a similar method to stack the names of the 
tags, so I can produce the correct end-tag (like </tag>), when I'm 
at that point in the parsing. But I've found that appending >>to-word 
"["<< and >>to-word "]"<< works very well, so I've solved my problem.

I've not needed a stack so far in REBOL.

In other languages, I usually find myself writing a complete thing 
like Robert has mentioed.

The full works in REBOL would look something like:
  stack/create "xxx"     -- create a new stack called "xxx"
  stack/push "xxx" item  -- push item 
  stack/pop "xxx" item   -- pop item
  stack/peek "xxx"       -- return top item without popping it
  stack/length? "xxx"    -- how many items
  stack/clear "xxx"      -- remove all entries

  stack/discard "xxx"    -- remove all entries and delete the stack

  stack/save "xxx" %file -- write it to a file (may not always be possible)
  stack/read "xxx" %file -- reset to contents of the file

  stack/probe "xxx"      -- return a block of all entries (for debugging)


And, as a stack has  a unique name, an application can be using more 
than one at once.

So, in a large class library, or even a medium size one, how do you 
find all the different method names, and how do you remember them? 
His answer is that you give the methods the same name. In REBOL, 
that would mean using words like Insert, Remove, First, Last, etc. 
That's how REBOL works with all it's built-in datatypes, and we like 
it for that, so I think it's worth keeping in mind.

Thats what series are about. :) And we can make our own using ports 
:)

POP is about the most useful method that isn't built into REBOL. 
It's nice to be able to remove something and have it returned, rather 
than having the series returned.

(and 'pop knows which variables where pushed, so just "pop", not 
"pop[a b]")

pop: partly agreed. but i use the top of stack directly, and poping 
really means "no longer needed.
i don't use   push var  change var   pop var
but   push value   use stack/1   pop

Is there someway to have a function stored as a string, and then 
do it, without triggering the actual function name? ie:

N: {o: func [inpu][print join inpu "ing"]}

so that i get.. 

do N "test"
>> testing

So far I've push'ed and pop'ed stacks (blocks) at the bottom, because 
I presure, it's faster that from the top (because of memory allocation). 
But I haven't actually tested it, and if it's true in all cases. 
Does anyone have experience with that?

stack: Gregg, yes these are true words about using the same name. 
But let's face reality, those data-structure stuff is quite old and 
is learned at university. Most programmers are used to them. And 
from the name of the functions I can implie to the datastructure 
used. Someone not common with Rebol might not "see" that this simulates 
a stack.

So far I've push'ed and pop'ed stacks (blocks) at the bottom, because 
I presure, it's faster that from the top (because of memory allocation)

 -- Yes. For block! values that is very true. For list! values it 
 isn't. For blocks it's a zillion times faster...well, for small blocks 
 it's faster and for big ones it's a *lot* faster. If you're making 
 a million changes to a 10,000 item block, it's a big difference.

http://www.compkarori.com/vanilla/display/peek_and_poke.r

I'm just looking for the function that decodes the text and returns 
text, and not an object

there is a parse-url  but it is burried in an objecr and not public/global

Remember & < and > if you have any of those in the text. 
Shall be replaced by &, < and >.

there were some note on it in Core release notes IIRC, de-hex and 
decode-url

I have a object with - name, street, and country and a database with 
50 records. I would like to store the records into a dynamic object 
array for later reading...

yes, that's it ! running smoth and fast... thank you very much anton.

I think AltMe is escaping some characters... I hope you guys can 
copy it and see the actual problem.

Not really possible without an extra data structure.
Why not simply make the parent the 1st entry in the block?
>> blk: copy []
== []
>> append/only blk blk
== [[...]]
>> append blk "a"
== [[...] "a"]


(One drawback is that this sort of recursive structure cannoy easily 
be molded and later loaded_
>>

Use a block and Push reference to the parent when you go into the 
child. Then Pop the reference when you want to go up one level.

Volker is right! Which one is the parent? Ergo we can't have a parent 
function. And then again, we have to use a trick, where we store 
the block at any level. (You other guys are right too, and I think 
the actual design is the best way, I just have to keep in mind, why 
it is like this.) :-)

DideC, do you have an example?  I've seen the terms 'push and 'pop 
before, but have not seen a comprehensive example of it...

There was a discussion about stack implementation the 27-jan in this 
group. Go up, there is the code from Robert and others

I find this a bit strange and problematic:

>> blk: [/]
== [/]
>> type? blk/1
== word!
>> parse blk [/]
== false

How do I parse a slash within a block?

I always wanted a way to dump all contexts a word is defined in: 
like "dump-context myword" and get a list of named and unnamed contexts. 
Anamonitor can do this.

and yes Robert,  i do not like split-path behaviour in many cases 
(see RAMBO discussions about this), but i do not think that your 
request is good, from my pov 
	%a/b/
should give
	%a/   %b/              = the dir b inside the dir a
or
	%a/b/   %./	     = the current dir inside the dir %a/b/

this is inconsistent with:

	>> split-path %./ ; == [%./ none]

but i think the last behavior should change in this

	%./    %./

Well, maybe split-path is not so useful sometimes, but at least it 
says what it is doing :) I think what we want most of the time is 
the dir-part and the file-part of a path (actually these are functions 
I use). I think they are more useful in general. The problem is in 
coming up with a good name to describe this behaviour..... maybe: 
   to-dir-file-parts %my/path  ;== [%my/ %path]    ?

The top-level of the spec block is scanned for set-words; in this 
case, there are three ( a:  b:  o1: ). These three words are added 
to the newly forming object. The spec block is now scanned *deeply* 
and where one of those three words ( a b o1 ) is found, they are 
bound to the object.

Thanks for the answers to some of my questions! In summary:

- The set-word notation for setting variables doesn't seem to work 
any more, and the reason for the change to the set* opcodes is increased 
speed.

- BRAW is computed goto, but it is yet unclear what the value of 
the word is supposed to be. I'll test.

After testing and some guesses I figured out that the rebcode dialect 
is statement-based, although it can be converted from expression-based 
by the aforementioned rewrite rules. Also, the | in the declaration 
of opcode syntax refers to alternate data types, so that:
    skip: [word! integer! | word!]

means that skip takes a word! as its first argument and an integer! 
or a word! in its second argument.

There may still be ways to crash the VM using semantic errors (type 
mismatch and such). Testing...

A couple questions:

- Are the exit and return opcodes still implemented with setjump/longjump 
?

- Is there still a plan to enable rebcode procedures to call other 
rebcode procedures, other functions? Or do we just use the do opcode 
for that?

Just poking around, and found a hint of things to come. There are 
more new (not working yet) data types in addition to rebcode! and 
vector!: percent! and unicode! are there as well. This should be 
fun!

:-) do you mean struct in Core? It seems to me that RT is now working 
really fast and working on new nice things ...

Brian: i think exit and return are implemented internally by wrapping 
a TRY around rebcode calls. About calling subroutines, that is planned.

And if you ever have to use rebcode, make sure you wear protective 
glasses. ;)

I just ran Cyphre's Dotflowers at 1600x1200 and it ran pretty good. 
 it ate 75-99% of my CPU but it worked.  While it was running though 
it messed up the OS's window layering somehow.  When I click on a 
window in the background it does become the active window but is 
not brought to the top of the window stack.

Uhm.  The window layering problem has nothing to do with how much 
the script was slowing down my computer because I killed the script 
and windows still isn't layering my windows properly.

Petr, yes I mean struct! in /Core. I keep on having situations that 
could use struct! when I don't need libraries. For instance, conversions 
from external binary data encodings to internal REBOL values, say 
for file formats, network protocols, and so on. Now rebcode has added 
other forms of strong typing like the type-specific opcodes and the 
vectors. Having structs, their constrained field types, their specific 
data layouts, would be a perfect match for the low level operations 
of rebcode. They would be helpful later when implementing your own 
data types as well.

but then I want tasking maybe and mixing it with timers here :-) 
well, just watching Carl's speach - did he mention plug-ins (language 
plugins)? And IIRC Reichart mentioned modularity ... hmm, hmm, looking 
at RebCode, watching the devcon videos, I think good times are ahead 
:-)

Actually, when I think about it, the flexible function call syntax 
of REBOL would be a bit of a slowdown to implement directly in rebcode. 
All of the operations now are fixed in arity and known ahead of time. 
One way to get that same predictable behavior in rebcode is to put 
the call in a block and assign the result - coincidentally this is 
the syntax of the do opcode.


Another way to do this would be to add something like an APPLY opcode 
with three parameters: A result param (word!), a function param (word! 
| path!) and an arguments param (word! | block!). This opcode would 
pass the arguments to the function (perhaps with refinements) and 
assign the result to the word provided. This would allow the higher 
order programming that would otherwise be awkward - the do opcode 
could be used for traditional function calls. If necessary, the operation 
could be split into two opcodes: APPLY for function values assigned 
to a word, and APPLYP for a path literal or value assigned to a word 
- whether to do this would depend on which was faster.


Another awkward thing to do in rebcode is getting and setting values 
through indirection, like the get and set natives do. Those seem 
like a really basic operations that should have opcodes assigned 
to them rather than having to resort to do blocks. I'm just thinking 
of the basic get/set word assigned to word scenario, not the more 
advanced object/block stuff.

BUG (possibly): The SETI and SETD opcodes don't work unless the variable 
has already been set to a value of the appropriate data type.

REQUEST: I would like the LOG-2 opcode to be added to the existing 
LOG-10 and LOG-E. Log-2 is the only one of those I actually use regularly 
:)

APPLY is just what is in the works :) and... some kind of GET and 
SET for indirection is being discussed too.

SETI and SETD: that's intended. they only work on initialized variables... 
but they are faster than normal SET (SET has to copy 16 bytes, SETI 
only 32 bits for example)

if you have either or if or while or something like that in your 
production, you'll need /deep, and you'll be screaming if you don't 
have it ;)

only RV is used as a temp var... and it's always the same rv.

if you can find an example where this would not work... please let 
me know; i guess you will, since this compiler is just a quick test, 
and i didn't expect it to work this well ;)

Well finding an example is simple: Just convert to stack code and 
figure out when the stack would be used more than one deep between 
ops. That means more than one temp var. What we get for going to 
a register machine in a stack language :)


This would all be solved by a built-in USE directive with literal 
blocks that acts like USE in REBOL except only binding at rebcode 
creation time. It could be implemented as a built-in rewrite rule, 
changing the temporary variables to local variables, renaming if 
necessary. This rewrite would be done after the user-defined rewrites 
were done, but before the binding to the opcodes.


Let me think about how this could be implemented - I am late for 
a class.

thanks ... the docs will be pretty comples - soooo many opcodes in-there 
:-) I just wonder, if Gabriele does only some wrappers or even C 
internal coding? :-) And if he is so good at it and RT is working 
on a low-level stuff for a while - there were few wishes to improve 
library interface and callback support. Imo it is still in versio 
like Jeff did it initially and some update which would make wrapping 
easier would be handy :-)

imo callback  support is weak, dunno if other languages have such 
a limit as 16 possible callbacks ... well, there is many indications 
in dll.so group. It surely will not be a priority for RT right now, 
as it simply works as a solution, but I just thought that those two 
things (dll C interface and VM assembler) could be related somehow 
...

besides that, yesterday I played part of Carl's speech, and in QA 
part I noticed something like a mention of interfacing via plug-ins, 
but I could easily misunderstood because of my "ability" to distinguish 
natively spoken English :-))

but, since custom datatypes and plugins are somewhat related, i might 
be wrong.

and plug-ins are planned anytime soon? :-)

how can I write in rebcode: x ** y , where both x and y are decimal! 
?

Seeing as I am the programmer :) ...

I gave it some thought, and realized that any solution like Gabriele's 
(paraphrased)

    use [tmp] [rebcode-define ['blah #==> ('tmp) blah]]


would not be recursion-safe. Any word you added would not have its 
context fixed by the interpreter on recursion, and so would get reused 
and trashed. This was also the case for my idea of a built-in USE 
rewrite rule that would be applied in the assembler after the userdef 
rules were done. Unless you can hack the rebcode function context 
after rewrite to enable variables added to said context during rewrite 
we are out of luck.


So, to do this kind of advanced rewriting we would have to do it 
before the rebcode function is made, rewriting the original body. 
Darn.

Oh and Gabriele, I am writing a real compiler.

I should also comment:

These rebcode releases are intended to focus on the VM and opcodes 
themselves, plus the lower level expressions ("assembly code") necessary 
to make that happen.   We are not focusing on higher level expression 
methods (e.g. compiler) at this time.  We assume that many such things 
will happen (from many sources), but for now, we need the base VM 
to be solid first.

Also note: To see the current valid opcodes and their arguments, 
type this:
      print system/internal/rebcodes

This object is actually used by the assembler.  And, many opcodes 
include comments to explain what they do.  A good reference.

Great, I mention that ADDD and the like can take integer arguments 
in the second parameter but the syntax doesn't allow it in version 
10 (and request a change in declaration), and now in version 11 the 
opcodes don't take integer parameters any more. I hope that change 
resulted in a good speedup - it would certainly be easier to JIT.

Relative offset seems to be the least useful for use with computed 
goto. With absolute offset in the block you could have each label 
word be assigned their offset as a value, and then assign those values 
to other words to be branched to later. If the offset is relative 
then you have to recompute the offset for every branch statement. 
This is quite awkward for more than one branch statement.

I've seen computed gotos used by threaded interpreters and that ProtoThreads 
package among other circumstances, so I'm quite interested in their 
use here.

They can be a great way to speed up state machines, implement switch 
statements and such.

I've been using it to calculate IP subnets and the like.

Actually, there is a lot of things I have to remember and adding 
long numeric constants to the list would be a problem. That isn't 
sufficient justification (to me) to add another opcode. Greater efficiency 
would be, as would making the log-* set as complete as REBOL's natives 
are to save on silly questions like mine in the future :)

and log2 does help with it? Just asking - most of the time I dunno 
what you are talking about here :-)

So your example would be (log-2 x) = (log-e x) * (1 / (log-e 2))

especially since e isn't defined as a constant in REBOL, and log-2 
isn't a rebcode opcode so we can't use it here.

I suppose those "constants" could be calculated ahead of time and 
just inserted in the code as local variables. Well, that solves the 
functionality and memory (mine) problems. Still, it seems like C 
libraries and such must have a better way of doing this - it seems 
a bit inefficient.

On a binary machine, wouldn't log-e and log-10 be implemented on 
a lower level on top of log-2, instead of the other way around?

On a binary machine, wouldn't log-e and log-10 be implemented on 
a lower level on top of log-2, instead of the other way around?
 not exactly, it is a kind of a "mix" AFAICT

log-2 (and 8, 16, etc) should just be bit shifting and "bit-tabling" 
since 2 is a "natural number" in computers....no "Math" needed...;-)

Steve: but you need a loop! so, unless you have that in hardware 
(and it still doesn't seem doable to me for floating point), log-e 
will be easier to compute (see wikipedia article)

Gabriele - thanks for the idea with parse and the note about it being 
a VM of some kind .... now I get it a little bit better :-)

See, even BRA is converted from an absolute offset to a relative 
offset at assembly time. Having BRAW be relative would mean making 
that conversion at runtime every time you want to make the jump, 
and then rewriting that computation every time you make a minor adjustment 
to your code, recounting instructions by hand and subtracting the 
new constant.

I suppose a new opcode BRAWA could be added as a rewrite rule to 
a calculation and a BRAW, but that kind of rewrite rule adds a temporary 
variable and so isn't recursion-safe or safe for use by multiple 
rebcode functions without some tricks.

HAve not looked close in rebcode. But maybe switch-statements? There 
you know where the branch is, and can calculate the right table. 
another switch could be implemented by reserving enough space for 
each branch, say 8 opcodes. and then simply shift the switch-argument 
by 3 (= *8) and braw.

Watch out, I have been giving this some thought and have a big message 
coming :)

(Thinking out loud) It occurs to me that computed branches would 
be a lot easier if you could reference the target values in your 
code, so that you have something to compute with. If the offsets 
were absolute you could just assign them to the label words (something 
that could be done in the first pass of the assembler rewrite of 
the branch statements). Relative offsets could be calculated pretty 
easily if you had something like a HERE opcode that would assign 
the current position to a variable that could be used soon afterwards 
to calculate the relative offset. For that matter, the HERE opcode 
could perform the assignment of the original label as well, and even 
be accomplished by a rewrite rule in the branch fixup pass of the 
assembler.


Here's my proposal for a HERE assembler directive. No native opcodes 
would need to be added - this would be another directive like label. 
This directive could be used to set the target values to words for 
later computation. Assuming BRAW stays relative and no absolute computed 
branch is added, it could also be used in computations to convert 
from absolute to relative offsets. This would be sufficient to make 
computed branches practical.


- A new directive HERE, taking two arguments, a word and a literal 
integer.

It would set the word to the position of the HERE directive, plus 
an offset specified in the second parameter. The offset would need 
to be a literal because the calculation would be performed ahead 
of time by the assembler - 0 would mean no offset. If you don't want 
to reset the position every time you branch to the word use an offset 
of 3. Resetting the word after every branch would allow its use as 
a temporary in absolute-to-relative calculations, but that would 
only be an advantage until the JIT or optimizer is implemented - 
the choice would be up to the developer. Having a mandatory second 
argument is necessary for reasons that will become clear later.


- The HERE directive would be rewritten away in the fix-bl function 
of the assembler like this:

REBOL []  ; So I could use SciTE to write this message

fix-bl: func [block /local labels here label] [
    labels: make block! 16
    block-action: :fix-bl
    if debug? [print "=== Fixing binding and labels... ==="]
    parse block [
        some [
            here:
            subblock-rule (here/1: bind here/1 words)
            |

            'label word! (here/1: bind here/1 words insert insert tail labels 
            here/2 index? here)
            |  ; Beginning of the added code
            'here word! integer! (

                here/1: bind 'set words  ; This is why HERE needs two arguments

                here/3: here/3 + index? here  ; Offset from position of this directive
                if (here/3 < 1) or (here/3 > 1 + length? block) [
                    error/with here "Offset out of bounds:"
                ]
            )  ; End of the added code
            |
            opcode-rule (here/1: bind here/1 words)
            |
            skip (error here)
        ]
    ]
    parse block [
        some [
            here:
            ['bra word! | 'brat word! | 'braf word!] (

                if not label: select labels here/2 [error/with here "Missing label:"]
                here/2: label - index? here
            )
            |
            opcode-rule
            |
            skip (error here)
        ]
    ]
]

In case you missed it in the code, the trick is to have the assembler 
calculate the offset and then convert the HERE directive to a SET.

Once you have something like this directive, a branch can be done 
with the addition of just two operations, a SET and a SUB, to the 
relative BRAW. The SET would be a converted HERE.

maybe LABEL can serve both purposes, and set the label word to the 
absolute position.

The whole reason I came up with this was because BRAW was relative. 
If you changed BRAW to absolute and wanted to do a computed relative 
branch, you could do so with the same two added instructions. If 
you can come up with an occasion to do a computed relative branch 
please tell me, because I can't. All of my examples either require 
absolute or are better with it.

i.e. you have a "table" of APPLY instructions and jump to the one 
you want.

For example, there are two ways that ProtoThreads is implemented. 
One way uses switch statements, using a variation of Duff's device. 
The other uses computed branches on compilers that support them. 
The computed branch version is faster, and branches to an absolute 
address. Computed branches to absolute addresses are used in threaded 
interpreters as well.

Maybe we can split the difference and have another opcode for absolute 
computed branches?

Why not do both? Change

    'label word! (here/1: bind here/1 words insert insert tail labels 
    here/2 index? here)
to
    'label word! (
        here/1: bind here/1 words
        set here/2 index? here
        insert insert tail labels here/2 index? here
    )


No, since it wouldn't be set at runtime, it wouldn't be recursion-safe. 
The only safe way to do that would be to replace every reference 
to a label other than the label directive and the literal branches 
with  a constant value of its absolute offset, the one in the labels 
block. Doable, but awkward.

(what is available on docu? i have to scroll a lot and can find it.)

Volker, so you would add one branch instead of an assignment to a 
temp variable and a subtraction. Sounds good, but branch prediction 
hardware would fall over if you JITed this kind of code :(

As for docu, there is the original blog, the succession of notes 
in the releases and the source. And our experimentation.

I guess till jit some things change anyway. and the branch to the 
branch would be absolute, so branch prediction should handle that.

system/internals, rebcode-define and rebcode* for now.

A JIT with a peepcode optimizer would be able to recognize the pattern 
of an assignment to a temporary, subtraction from an address and 
branch relative indirect (3 instructions on x86, more on RISC) and 
convert it to a branch absolute (one instruction on x86, two on RISC) 
with no difficulty.

And vice-versa as well.

Volker, not secret, but changing so rapidly that I wouldn't suggest 
counting on it yet. Rebcode 10 and 11 came out within a day.

Should ifs pass the true-flag? So that this works like and:

rc-and: rebcode[f1 f2 /r ] [
 sett f1  ift[ sett f2 ]
 gett r  return r   
]

and a syntax-suggestion to make multiple statements in a line more 
readable:

rc-and: rebcode[f1 f2 /r ] [
 :sett f1 :ift[ :sett f2 ]
 :gett r :return r   
]

Volker, the first could be written as
rc-and: rebcode [fi f2] [
    and f1 f2
    return f1
]

Yes, but its more complex. i need a real shortcut-and.