AltME groups: search

Maybe you can use Rebol and  try to implement a curriculum similar 
to HtDP.  

The Structure and Interpretation of the Computer Science Curriculum 
http://www.cs.brown.edu/~sk/Publications/Papers/Published/fffk-htdp-vs-sicp-journal/

My preconception is that adding the graphical layer complicates things 
too much 

 -- A valid concern in many environments, but VID is great, and simple, 
 for simple things.


view layout [button "Show help" [alert "Sorry, I can't help you"]]


No need to manage the event loop, no redraw handlers (until you need 
to get into them of course), just put an action block after a face 
style and it binds to it automatically.

It needs Chat (writte), Talk (Spoken), Video, and several Whiteboards, 
and a way to view somoeone's computer screen.

Tell me what is out there, and I will get this started.

Google Desktop has a plugin that makes GTalk able to make a chatroom, 
and another that allows you to share part of your screen with someone 
on your buddy list.  I don't know how well they work, thouhg

Project 2: Establish a two way connection using tcp/ip and save the 
history on disk.

Also (in general) check
http://rebol.com/docs/core23/rebolcore.html
in particular load and save  and  read  and write commands
http://rebol.com/docs/core23/rebolcore-12.html#section-4

I can read the code. The thing is I have yet to get to a point where 
I can sit down and start thinking code to do things.

REBOL/Core and /View has builtin  help  as well...but it can be terse

Enjoy...REBOL, being light, is pretty deep wide and somewhat 'hidden' 
 :)

I hadn't seen this one. Based on View? I was assuming it to be simpler 
to stick with Rebol/core. Maybe not.  This one seems real good at 
a glance. Tks Brock. And tks btiffin for all the pointers.

view is core for all except gui. + some commands ending with -thru, 
'read-thru and such. they are the same as the short form, but use 
a cache.

Reichart: I'm surprised the tools you are wishing for in order to 
start holding online classes aren't already build in Rebol... From 
what I've seen, all the bits and pieces seem to be there already, 
maybe except for a whiteboard. No?

To everyone:

What characterize a good learning book? Do you prefer thick books 
with deep explanation and many examples, or do you prefer the thin 
book with the essentials? Look at your collection of technical book; 
about computer languages, OSs, databases or what you have. Which 
ones do you like, and which ones is no-good?

and preferably with water proof pages so I can read it in the bath 
:)

I have some big books I like, but my favorites tend to be smaller. 
I love Jon Bentley's books, and anything by Robert Glass (almost 
wrote Philip Glass there :-), Kernighan, and DeMarco and Lister are 
other favorites.

I actually bought some HP tough paper for this purpose.  It's water 
proof and and can be printed upon with laser printers.

and very expensive

I'm a newbie and wanted to ask this question on a simple rebol program. 
 If I have a variable COUNT and I wanted to write this value with 
a literal could I do this:  write OutFile [Count " Total lines"]/append. 
 But the word Count is not evaluated and I get "Count Total lines" 
instead of "8 Total lines".  What do I need to tell rebol to return 
the value of COUNT?

As a newbie, what suggestions do you have for me to debug my rebol 
scripts.  For example, I have a script called "Convert_to_Table" 
that I am just starting to write.  I can execute it -stand alone- 
and see the results of the run, but what I would like to do is be 
able to see what the console has for any values.  In other words, 
when I double click the "Convert_to_Table" I can see the results 
but not ask the console questions like print Count or the like.  
How do you suggest a newbie debug a script?  Should I go into console 
first and then perform a "do Convert_to_Table" and then be able to 
ask questions of console, or is there another way?.

I rarely type into the console and probe everywhere in the code. 
there is also '??, which shows the name of the word too.

?? - it's same as with probe:

>> ?? probe
probe: func [

    {Prints a molded, unevaluated value and returns the same value.}
    value
][
    print mold :value :value
]

it prints value to console and returns that value

you have for example your code:
	append head copy/part trim string ln "something"

and to easy understand what's going on, you can put 'probe after 
'append, 'head, 'copy/part and 'trim to see how the evaluation is 
going on.

Volker: no, ?? gets 'value and probe gets value as input, so they 
return something different.

Ok to sum up: Probe will return only the value to console, ? will 
return the variable along with short text and value, and ?? will 
return var name with value

It's the "pen" icon, press it and you can send messages with CTRL+S

Rebolek, i said  all the time "with variables". Of course it does 
not know what you use as function and what as variable

Ahhh so much to learn and not enough time!!!  Thanks for your patience
Ok, on to another issue.


I have a text file as a printable report that contains several pages 
within it.  Each line can be as large as 132 columns wide (or less).

- The literal  "    Page " will begin in column 115 and that indicates 
the start of a printed page.


I want to write a script that will read this text file one-page-at-a-time, 
so I can do some processing on the page.


How do I write a script to load in a single "page"?  I am guessing 
that I need to open a PORT and have rebol read all the lines until 
I get "....Page." in bype position 115.

Any suggestions?

I need to load in a single page at a time, then "process" that page 
before going on to the next page and processing it.


Are you suggesting that I go ahead and read in all the lines of the 
report and then go through that block to identify a page?

I will check out PARSE and try some examples later.

Thanks for your help.  Will be back later

You could also go for a combination with one little string, that 
you change (by putting in the number) and print.

Hi All,  
Have any Rebolers dealt with UniCode files?


Here is my situation.  I work on an IBM AS400 that can "port" files 
over to the PC.  Notebook opens it up just fine, but Rebol doesn't 
see it the same way.  If I Cut & Paste the contents of the file into 
an empty notebook and save it, Rebol can see it just fine.  Upon 
further study, I noticed at the bottom of the SAVE AS window that 
Encoding was set to UNICODE for the AS400 file, while the cut & paste 
one was set to ANSI.  


Does Rebol want ANSI text files only, or can it read UNICODE files 
too?

Pekr. Believe me Carl is informed by a bunch of us in a private channel. 
The most active proxy and who should receive a lot of praise is Gabriele.

Well, I don't want to be a jerk, so I'm not complaining. Gabriele 
does a great job and even lurks around here when he isn't being vocal. 
We came up with some suggestions and tried reasonable means of getting 
them to the attention of the people concerned. I'm not taking the 
lack of feedback as a bad sign - these are busy people, as are we 
all. If it takes too long to find out whether they have heard us, 
I'll just summarize our suggestions in a post to feedback.

Brian we appreciate your comments, and your summary was posted to 
Carl. You will know soon enough what gets adopted.

Petr: I guess that there were not enough questions for this wednesday 
so Carl skipped it. (Just one, from you, and you always ask questions 
anyway. ;)

so we have Doc Friday and Questions Wednesday now? :-)

But the assembler knows this values internally and could be extended?

All that would be required would be that here directive, probably 
renamed to offset, and some code to perform the label-word-to-offset 
switch.

Maybe we could access the label-table of the last definiton? And 
preparing own tables? could be blocks. then

That won't work. Every rebcode block gets its own label table, which 
is just a block, not a context, and is thrown away after the label 
fixups. These offsets need to be constant - a label table could be 
modified by the calling code. Really, it's easier to do the fixups 
in the fixup phase - that's what it's there for.

Actually, I pored over every line of code, tested most of the opcodes 
too. I've been taking this rebcode development very seriously, making 
suggestions, finding bugs. Trying to keep from making too much of 
a jerk of myself. I expect that I'll be using and generating a lot 
of rebcode in the future so I want it to be the best that it can 
be.

I agree. For small byte-crunchers its high-level enough. Maybe  it 
should integrate with parse too, that would be great for dialects 
(replacing chars and such).

and features to write specialized loops, like remove-each .

ANd some1 (Gabriele) suggested parse can compete with rebcode in 
its area, its a vm too.

It would be interesting to have a parse opcode, but keep in mind 
that this kind of speedup would likely be implemented in the JIT, 
when we get that. And however fast parse is, its overhead dwarfs 
that of a function call. And remember, using apply would be significantly 
faster than calling a function in the do dialect because there isn't 
any evaluator overhead.

No, it really can't. You could in theory build a compiler for a static 
subset of parse, but parse rules can change at runtime, even while 
they are running. They are passed by reference, remember. The reason 
you can JIT rebcode is because every code block must be supplied 
as an immediate literal and so can be considered static. If you do 
runtime modifications of the code blocks, code-as-data stuff or other 
REBOL-like tricks a JIT wouldn't really work, and certainly provide 
any speedup. Keep in mind that rebcode is a compilable subset of 
REBOL - the rest of REBOL mostly isn't compilable.

It can switch from native code back to bytecode if the mathod is 
changed. and from bytecode to native once something is compiled.

All you need is tracking references to a parse-rule, and signal such 
references to fall back to interpreter if rule is changed.

there was an example with a main which contained only a loop. it 
startd with bytecode, after a while it was compiled, and that loop 
was faster. without re-entering that method.

But we would not need that, only a change-check when entering sub-blocks. 
and doing that block by interpreter. then.

Back to parse, you could in theory statically translate the rules 
to an internal rebcode-like form for a different VM, and then JIT 
that. You wouldn't get as much of a speedup as you think though. 
The existing parse engine spends most of its time actually doing 
the parsing with the native code in the engine - a JIT would only 
speed up the reading of the parse rules, something it doesn't spend 
as much time doing in comparison.

Right now any of those flexible parsing and rule changes are implemented 
in do dialect code in the parens. To make the rules static, you would 
have to compile that code too.

And parse processes a lot of bytes. The parsing is fast. then the 
() are slowing down things.

There have been suggestions for additional parse operations: remove, 
replace and change. I even suggested an if clause that would allow 
the return value paren to direct the parsing flow. Between these, 
that would take care of the vast majority of the operations performed 
in parens, and thus would speed up parse a lot in practice. Even 
more than rebcode would.

I prefer better handling for output. replace and change are quite 
slow (moving the whole tail). instead a fresh string and appending 
there is faster. but tickier to code.

Brian: "By the way, the if clause in Ladislav's compile-rules is 
not like the one I suggested, not even slightly." - the IF clause 
at R.E.P. was proposed by Gabriele and I commented it and tried to 
suggest a "simpler" version. Where is your version described?

A few years ago the list was collecting complaints and suggestions 
about the parse dialect. Robert Muench put up a web page where those 
suggestions were collected for REBOL Tech's benefit, and then it 
went nowhere. His page isn't there anymore, but it used to be http://www.robertmuench.de/parse_ideas.html

I had made two suggestions for clauses that would make parsing better, 
a USE clause and an IF clause. The use clause was meant to deal with 
the difficulty I was having with using variables in recursive parse 
rules. The if clause worked something like this:
    [if (test) rule1 | rule2]


The trick here was that the paren would be evaluated just like a 
normal paren, but the result of that evaluation would act as a match 
or not as far as the parser was concerned. It was an absolute requirement 
that the backtracker be able to backtrack through the if clause's 
paren, and that having it return a false or none would trigger a 
normal backtrack as if the parser had failed to match. Right now, 
normal parse parens won't be bactracked through because of internal 
issues in the engine's implementation.

You can fake this kind of behavior by changing
    if (test) rule1 | rule2
to
    (nextrule: either test [rule1] [rule2]) nextrule

but it shortcircuits the parser's backtracking to check alternatives.

Thanks Graham! According to the internet archive, the page was started 
in March, 2000 and was taken down after Dec, 2003.

The last version of this page is http://web.archive.org/web/20021209120704/www.robertmuench.de/parse_ideas.html

I am referenced twice in this page under different, outdated email 
addresses.

(both USE and IF look worth it, maybe you can have each in its own 
ticket?)

Would it be nice to have the raised to exponent (**) operation in 
rebcode? And with decimal exponent. Maybe we should ask Carl about 
that before the first version is closed? Maybe also root operation? 
(Not just square-root, as we already have.)

and alpha? :-)

Cyphre, use OR instead of ADD and there will be no troubles with 
arithmetic overflow. It'll be faster too.

And REBOL ate all memory

if I lower number of loops to 1 000 000, there's no crash and the 
difference between direct and apply version is not so big, some 5% 
(but still remember, that in the apply version, there's loop inside 
rebcode and it's way faster than rebol's loop, so apply is still 
slowing it down)

Geomol, POWER may seem faster that rebcode version, but this is again 
thanks to apply. From my tests it looks like apply/POWER version 
is cca 5% faster than apply/rebcode version but rebcode version only 
(loop is inside rebcode and no apply) is cca 3.8x faster than apply/rebcode 
version

guys, how well does parse play with rebcode? It was said that parse 
is VM in itself, it is very right, but now we have some discussion 
about zlib support. Let's suppose we have rebol version on rebol.org 
and that we would like to speed it up. We can simple extend the idea 
to any other datatype (= in amiga terms, simply a file format, or 
protocol one). you will surely want to use parse. The question is, 
if you can speed up some things using rebcode?

Correction:
power 0.0 0.0

gives result 0.0. I check for that in my code and give result 1.0. 
With that check before calling POWER, the inline rebcode version 
becomes the fastest, *not* apply/power

With rebcode, optimization suddently becomes science.

(And you need more data structures to hold the results.)

I guess, Pekr's original question was about, if it's reasonable fast 
with rebcode, and I would say, that it is.

you know, when we originally developed high-end astronomy CCD camera, 
it returns you per-pixel value of 1 to 65535, according of how much 
current counts in the individual pixels ... you ten need to convert 
it to image, so you have to get minimu,maximum, and divide it into 
256 zones .... when I did it using plain rebol, it was painfully 
slow. Imagine having lucrative in-camera ethernet + ip, downloading 
image using rebol in 1 sec or so, and then waiting 19 secs tojust 
view the image :-) If we would do this device nowadays, with Rebcode, 
I believe I would not hesistate to use rebol for all operations ....

Right. I once talked with an astronomer working in Lund, Sweden. 
He told me about the software, they use. It's mostly based in code 
written in the 70'ies (in FORTH, if I remember correctly). It's good, 
well-tested software of course, but the user interfaces are terrible, 
often just a command-line. It could be interesting doing modern versions 
of some of that software using REBOL. But the scientists have to 
be 100% sure, the output is correct and the same as they get from 
the software, they use now. If the right function libraries were 
developed in REBOL (rebcode), I think scientists could be a good 
user-base (developer-base) for the REBOL language.

I live in command line with Rebol and I'm happy:)

even big SBIG used parallel port back in the time we used ethernet. 
The sad thing is - no money, no music ... 4 ppl working part-time 
can't beat 80 full-time workers. But we did, for ourselves - I have 
our camera in my table ;-) And we build quite a few telescopes - 
REBOL is COOL for astronomy - dialects etc. wow ... the thing is, 
if it would be adopted ....

pekr, did i understand that u were using rebol 4 astronomy? could 
show me/us some of ur worx? a collegue of mine - whom i really want 
to b converted from php to rebol - is an amateur astronomist and 
such a stuff can give him the final pulse to start learning&using 
rebol

It also makes their typed nature explicit, and establishes the convention 
of <opcode>i for integer-specific opcodes, which will come in handy 
later when we add more (like picki/pokei).

Maybe it makes it sense to have generic math too, then we could add, 
sub etc too. Not sure, but if interaction with rebol is closer and 
we deal with rebol-created blocks?

Yes, but a typecheck and a branch and a conversin even more.

i write support for rebol, and so it should be easy to pass data.

If change is done to add the "i" on add and others, it will also 
be the case on comparison operators.
eqi, gti, ...

Did you see that idea in Rebol Enhancements about picki and pokei 
for bytewise access to integers?

I get generic add by doing this:
    to-dec a
    to-dec b
    addd a b

You can skip one or both conversions if you can trace the type flow 
and be sure of the data types of the arguments.

Your opinion is require.


Some opcodes exist in double due to specific integer or decimal value 
handling.

What would be your preference on opcode naming ?

Choice are :

1) INTEGER add mul div min eq gt gte ... / DECIMAL addd muld divd 
mind eqd gtd gted ...

2) INTEGER addi muli divi mini eqi gti gtei ... / DECIMAL addd muld 
divd mind eqd gtd gted ...

3) INTEGER add.i mul.i div.i min.i eq.i gt.i gte.i ... / DECIMAL 
add.d mul.d div.d min.d eq.d gt.d gte.d ...

(Today rebcode is 1)

It concern math, logic and comparison opcode.

The second is brief and consistent. The first is just brief, half 
the time, and confusing.

The third makes the typing distinct from the opcode, and that could 
be an advantage when future opcodes are added later.

3) come from asm68k that looks like that.

And rebcode, as a byte-code, is near ASM (even if more powerfull, 
ie: block!)

Paths are much bigger to store, meaning memory and lookup overhead. 
They are blocks you know, with different syntax.

dot looks like a space and spaces are veryimportant in rebol-layout. 
i would not use that.

I know also that performance depends on needed volume. both processing 
steps and codeamount are small.

You can change path opcodes to dots with rewrite rules if you prefer. 
Opcodes are supposed to be static. The whole interpreter would have 
to be changed to make opcodes paths, and it would be much slower 
after the change.

sure, but i can change the other way. why start with a bad opcode 
and replace it with a bad, when i can have it the other way around?

REPLY TO URGENT NOTICE:  i propose i.add, i.mult, i.div etc... this 
way we include to rebcode a some object like stuctrure but only applayable 
on fonctions /operation names 

this allow us to not mistake betwin rebol/core  funtions and rebcode 
ones. As type take a  !  in rebol syntax we can use i!add i!mult 
i!div i!sub etc... I think this syntaxe would be really attractive 
for coders abit to object language. I.add or i!add is directly understable 
i -> interger add -> the operation applyed to integer! args ...

lol and i->add lol

I prefer 1, as it is now. Keep it short. I think of the decimal variations 
like the normal ones, but with some extra (decimal has better precision 
and gives you decimals, so it's something extra than integer). It 
also take up more bits -> more bits, longer name. That's the way, 
I think. Also reminds me of C, where 10 is a short integer, and 10L 
is a long integer. (Not the same, but kind of the same thoughts.)

and addi minimizalkeystrokes too. :) and since Carl has choosen that 
way, but before he had addd etc, i opt for the smallest adjustion.

i clash with seti and such. then we should make everything integer, 
and have a setv for any-value.

hum and for decimal! value 1) gives addd
.... not clear enought i think

About previous Alert (rebcode), and to filter noise, please vote 
in the "Opcode naming survey" checklist.

Add 2 to your prefer naming convention
Add 1 to your second choice