AltME groups: search

, i.e. you could as well "consult" the %evaluate.r script

It does not, Max.

[thru end] is supposed to mean:

[end | skip]

, i.e. it fails in R2 only because of the faulty implementation

a matching rule, will expand the segment's area, but not its index. 
 rules are stacked based on end-to segments.  if a rule has a segment 
of size 0 (as in the none rule) there is no index change in the next 
rule segment. i.e. it shares its index since its index is previous 
index + 0

Can an R2 parse expert help me with an efficient parse, please?

I've got a set of bbcode-type tags, eg:
    tags: [ "[a]" "[b]" "[cc]" ] 
    

And I've got a data string that includes those (and other) tags, 
eg:

    data: "xxxx[a]aa aa[b]xxxx[a] yyyy[d]yyy[cc]dd[e]ddd[b][A]zz[zz"


What I'd like is the data string split at the designated tags, eg:

    [ "[a]" "aa aa" "[b]" "xxxx" "[a]" " yyyy[d]yyy" "[cc]" "dd[e]ddd" 
    "[b]" "" "[A]" "zz[zz" ]
    
Thanks!

rebol []

=tags=: [ "[a]" | "[b]" | "[cc]" ] 
    
data: "xxxx[a]aa aa[b]xxxx[a] yyyy[d]yyy[cc]dd[e]ddd[b][A]zz[zz"


blk: []
parse/all data [
	start:
	any [
		here: copy tag =tags= there: (
			append blk copy/part start here
			append blk tag
		) start:

		| skip
	]
	(append blk start)
]

?? blk

ask ""

In R2:

>> parse [a b c [d e f] g h i] [to [d e f] mark: (probe mark) to 
end]
[[d e f] g h i]
== true


Here the block after TO isn't a sub-rule, but a value to search for 
(a block of words). Doing the same in R3:

>> parse [a b c [d e f] g h i] [to [d e f] mark: (probe mark) to 
end]    
** Script error: PARSE - invalid rule or usage of rule: e


Is the block a sub-rule here? I've tried to search the docs, but 
haven't found an explanation.

I think that there is no direct equivalent in R3 to R2's TO/THRU 
inline block. R3's TO/THRU inline block treats the block as its sub-dialect 
for TO/THRU multi, and that doesn't allow complex values or more 
than one value in a single alternate. The direct R3 equivalent of 
what you are requesting would be this, but it doesn't work:

>> parse [a b c [d e f] g h i] [to [[d e f]] mark: (probe mark) to 
end]
** Script error: PARSE - invalid rule or usage of rule: [d e f]

Instead you have to do a trick with to block! in a loop and then 
match the block to quote [d e f] explicitly, keeping looking if it 
doesn't match. It's annoying.

as stated in the "Idioms" section, I think, that

    a: [set b c]

shall be equivalent to:

    f: [(set/any [b] if lesser? index? e index? d [e])]
    a: [and [c d:] e: f :d]

I need CHANGE too, and the full version with the value you're changing 
to be an expression in a paren

 - this changing during parsing is known to be O(n), i.e. highly inefficient. 
 For any serious code it is a disaster

>> d
** Script Error: d has no value
** Where: halt-view
** Near: d
>> e
** Script Error: e has no value
** Where: halt-view
** Near: e

>> test: funct [ ][ parse [ "abcd" ] [ set d string! end ] e: "abcd"]
>> test
== "abcd"
>> d
== "abcd"
>> e
** Script Error: e has no value
** Where: halt-view
** Near: e

like this

test: funct [ ][d: none  parse [ "abcd" ] [set d string! end ] e: 
"abcd"]

Or like this:

test: funct [/local d ][parse [ "abcd" ] [set d string! end ] e: 
"abcd"]

OK, now that we have 2.7.7 released (even though there is more work 
to do, i.e. platforms and the SDK), it is time to look ahead to 2.7.8 
- which is scheduled for release in one month on February 1. The 
primary goal of this release is to migrate to REBOL's new development 
infrastructure. This means:

- Migrating the RAMBO database to a new CureCode project and retiring 
RAMBO.

- Using Carl's generation code for the manual to regenerate the R2 
manual, so we can start to get to work updating it.

- Porting the chat client to R2 using the new functions and building 
a CHAT function into R2 similar to the R3 version.


The R2 chat client might be limited to the ASCII character set, though 
support for the Latin-1 character set might be possible. Still text 
mode for now, though if anyone wants to write a GUI client (Henrik?) 
we can put it on the official RT reb site accessible from the View 
desktop. The server is accessed through a simple RPC protocol and 
is designed to be easily scriptable.


It turns out that Carl already rewrote the installer for 2.7.something, 
but it was turned off because of a couple minor bugs that we were 
able to fix in 2.7.7. With any luck, only minor fixes to the registry 
usage will be needed and we'll be good to go.


As for the rest, it's up to you. Graham seems to have a good tweak 
to the http protocol, and others may want to contribute their fixes.

No :)


We need a place, page, website, (i.e. the original purpose of REBOLCentral) 
where a new person can come, and in a really nice layout EVERYTHING 
REBOL is there.

It points a person to everything else.


The Library,  the blogs, the knoweldge of this place, a REBOL "ReadMeFirst.txt" 
if you will.

28/02/11 16.02.48	[0x0-0xab49b3f].boron-gl[79567]	Boron-GL 0.1.11 
(Feb 24 2011)

28/02/11 16.02.48	[0x0-0xab49b3f].boron-gl[79567]	Usage: /Users/henrikmk/Downloads/Applications/boron-gl.app/Contents/MacOS/boron-gl 
[options] [script] [arguments]
28/02/11 16.02.48	[0x0-0xab49b3f].boron-gl[79567]	Options:

28/02/11 16.02.48	[0x0-0xab49b3f].boron-gl[79567]	  -audio  Disable 
audio

28/02/11 16.02.48	[0x0-0xab49b3f].boron-gl[79567]	  -e exp  Evaluate 
expression

28/02/11 16.02.48	[0x0-0xab49b3f].boron-gl[79567]	  -h      Show 
this help and exit

28/02/11 16.02.48	[0x0-0xab49b3f].boron-gl[79567]	  -s      Disable 
security

>> map-each e [] [e]
** Throw Error: Return or exit not in function
** Where: map-each
** Near: return any [output make block! 0]


is it a known bug? im new to cure code. i don't even know where to 
look for it. can some one help? (it works in r3)

if the parse rule is given as a parameter, vars within the rule will 
not be bound to the function.  the binding is static, i.e. it occurs 
only once, when the function is created.  the word in the parse, 
already is bound (or not).

its a remove-each e spec-of fn [find type? e [string! block!]]

By dialected, I mean the arg to the func is a dialect. When discussed 
before, one question was whether to make the block a separate arg.

a: [a b c d e]
b: [1 2 3 4 5]
new-lines [
    all on in a
    on in b every other item
]


Ladislav is right on naming, that it violates the verb-first convention.

/skip return records
i.e.  
>> select/skip [1 2 3 4 5 6] 4 3
== [5 6]

Considering the fact, that any REBOL code is loaded first (in the 
computer, but your brain should follow a similar procedure when reading 
it), i.e. handled as the "Data exchange dialect"/"Load dialect" (pick 
the one you prefer) before being (eventually, but not necessarily) 
submitted to any other interpreting function (like DO, etc.), the 
specially escaped format is useful, since it increases the expressivity 
of the "Data exchange dialect"/"Load dialect" (pick your preferred 
one).

On the other hand, the behaviour of self-modifying code is not as 
terribly complicated as you are trying to suggest, since:


* Taking into account the modifying properties of the MAKE OBJECT! 
[...] expression I wanted to write a relatively simple example to 
show what bug you may run into when ignoring the modifications.

* I succeeded immediately without actually running into such a case 
in practice, i.e. I did not have to hit my head to the wall first 
to run into this.

* It sufficed to think of a case when the modification would twist 
the block behaviour relatively to what you might find simple.

* Since I did it without actually running into it, I am fully entitled 
to saying, that the behaviour is actually transparent to me.

We all know you can make REBOL do just about anything. We also know 
there are a few things that trip people up (e.g. copying series values 
defined in funcs). My questions for John are: 


1) Has this behavior ever been behind a bug in any of your REBOL 
code? If so, what was the context and what was the impact (e.g., 
how did you work around it)?


2) If you got your wish, what would the consequences be? i.e., how 
would it change REBOL?

The second question was:


2) If you got your wish, what would the consequences be? i.e., how 
would it change REBOL?


When making an object in REBOL, I think of it as making a context. 
When making a function, I also assiciate this with making a context. 
If the rules were somehow similar regarding the two different contexts, 
it would be easier or more "simple", as I see it.


If your question was about binding, that I suggest blocks should 
define the binding and not each word, then that's a change, I find 
interesting but can't see the full consequences of. I think, it would 
work, and work well.

Composing a lit-path:

>> f: [b d e f]
== [b d e f]
>> i: 2
== 2

It would be nice that instead of this:

>> compose 'f/(i)
== f/(i)

you would get:

== f/2

>> f: [b d e f]
== [b d e f]

>> i: 2
== 2

>> my-path: rejoin [to path! [] 'f i]
== f/2

The COMMENT directive really looks general enough, so it is meaningful 
to make it standard. Funnily enough, its spelling is:

    COMMENT


, i.e. it is the old word, Robert just wanted to be able to strip-out 
the COMMENTs from the code, that is why I made it an INCLUDE directive 
as well. This shows, that currently you can make anything an INCLUDE 
directive, not just issues.

aha, so you are suggesting to just accept word as yet another type 
of argument, i.e. to support NEXT 'A

As for the documentation, i.e. where exactly it is mentioned that 
this approach is not recommeded. Unfortunately, I forgot, where exactly 
it was. Nevertheless, the reasons are clear, I hope.

another example, which does not work:

type? load form [1] ; == integer! (i.e. not block!)

type? load form [1] ; == integer! (i.e. not block!)


Yeah, that's a pity, I think. I would prefer LOAD to always return 
a block, so the result from LOAD could always be sent to e.g. PARSE. 
I guess, it's made this way to kinda let LOAD and SAVE reflect each 
other. But that doesn't quite make sense, as we can't save to a string. 
And LOAD can load an empty file giving an empty block, while we can't 
save an empty file with SAVE, afaik.

<Other uses of bitsets>
One use is conformity validation. eg:
    allowed-letters: charset [#"a" - #"e"]
    find allowed-letters "aaadddeeebbb"
    == true
    find allowed-letters "aaadddeeebbbx"
    == none

I want to share with you an "interoperability problem" I encountered. 
In Windows (at least in not too old versions) there are two versions 
of string-handling functions:

- ANSI (in fact using a codepage for latin charset)
- widechar (in fact UNICODE, restricted to 16 bits, I think)


It looks, that Apple OS X "prefers" to use decomposed UNICODE, also 
known as UTF-8MAC, I guess. That means, that it e.g. for a Robert's 
file it generates a filename looking (in a transcription) as follows:

%"Mu^(combining-umlaut)nch.r"

As far as the UNICODE goes, this is canonically equivalent to

%"M^(u-with-umlaut)nch.r"

, but:


- Windows don't consider these file names equivalent, i.e. you can 
have both in one directory

- When using the former, the ANSI versions of Windows system functions 
"translate" the name to: %"Mu^(umlaut)nch.r"

-- the %"Mu^(umlaut)nch.r" is a third file name, distinct from both 
of the above, so, if the R2 reads it in a directory, it is unable 
to open it

I have uploaded my latest EXIF-parser version at github - https://github.com/Oldes/rs/blob/master/projects/exif-parser/latest/exif-parser.r

To sort files you can use for example:

dir: %/e/DCIM/100CANON/
t: now/time/precise
result: copy []
foreach file read dir [
	error? try [
		ctx-exif/parse-file dir/:file
		exifdate: ctx-exif/get-tag-value 306
		repend result [exifdate dir/:file]
	]
]

sort/skip result 2

print ["sorted" (length? result) / 2 "files in" now/time/precise 
- t]
result

;>>sorted 120 files in 0:00:00.153

Anyone knows of a simple way to get to the binary encoding of a decimal! 
using just REBOL/Core (i.e. no struct!, no /library)?

Has the esmtp code in rebol core been completely debugged?  Is there 
some documentation somewhere that discusses how to overcome problems 
is sending e-mail? A script that worked for years can no longer send 
e-mail, and I have no idea what the problem is. We are using a bluehost 
server.  trace/net on is not revealing the problem.

Our datasets are huge and we optimise for performance by unfolding 
and indexing a lot of stuff into rules... for example instead of 
parsing by a list of words, I parse by a hierarchical tree of characters. 
 its much faster since the speed is linear to the length of the word 
instead of to the number of items in the table. i.e.  the typical 
 O*n   vs.   O*O*n  type of scenario .  just switching to parse already 
was 10 times faster than using  hash! tables and using find on them.... 


In the end, we had a 100 time speed improvement from before parse 
to compiled parse datasets.  this means going from 30 minutes to 
less than 20 seconds....but this comes at a huge cost in RAM... a 
400MB Overhead to be precise.

Hm.. the reason for the additional block with the /skip is thi sone:
>> b: ["a" "b" "c" "d"   "b" "c" "d" "e"] select/skip b "b" 4
== ["c" "d" "e"]

A slightly better test would be:

#include <stdio.h>

int main(int argc, char *argv[]) {printf("%ld\n", sizeof(_Bool)); 
return 0;}


And then compile that in C99 mode (i.e. -std=c99 for GCC; but C89/90 
compilers will bark on the unknown _Bool keyword anyway).


Better, because there exist(ed) a few stdbool.h versions prior to 
the final C99 standard which used e.g. unsigned integers for bools. 
Should be gone/fixed by now, but one never knows :)

another example, but this time applied to the index? function.
		
get-item: func [data][
	either i: index? data [
		pick data i
	][data]
]


note that this can be done differently, but I think this is the easiest 
to read because its almost like an algorithm.


i.e. "if this has an index, get its item at that index, otherwise 
just return the value."

Or, to make it even easier, just use an "in place deduplicate" written 
in Rebol, divide the time to deduplicate a 300 element series by 
30, and compare to the time Unique takes (Unique uses aux data, i.e. 
a more efficient algorithm)

Doc, have you ever coded in AMIGA language E ?

I remember reading E docs, but not coding...maybe I just did a HelloWorld 
app.

there might be some ideas to rip out of that compiler.    my favorite 
low-level feature was that all types where natively the same size 
in ram and where all aligned to that size.     in E all datatypes 
where 32 bits in RAM


so for example, chars actually had 4 bytes which you could dump bytes 
into, making them ideal for many purposes which strings and numbers 
are commonly used instead.  you coud compare chars with LONGS as 
though they where both integers, etc.

[[kaj-:-syllable]:~/Red]readelf -l empty

                                                                                                                                                                                                        
Elf file type is EXEC (Executable file)
Entry point 0x8048074
There are 2 program headers, starting at offset 52

                                                                                                                                                                                                        
Program Headers:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg 
  Align

  LOAD           0x000000 0x08048000 0x08048000 0x00184 0x00184 R E 
  0x1000

  LOAD           0x000184 0x08048184 0x08048184 0x00032 0x00032 RW 
   0x1000
[[kaj-:-syllable]:~/Red]

Ok it seems it relies on section headers rather than program headers: 

if ( sElfHdr.e_nSecHdrSize != sizeof( Elf32_SectionHeader_s ) )
{

    printk( "Error: load_image() Invalid section size %d, expected %d\n", 
    sElfHdr.e_nSecHdrSize, sizeof( Elf32_SectionHeader_s ) );
    nError = -EINVAL;
    goto error;
}

It's an incomplete list too. Here is a complete list of the control 
characters (not including the keywords or hex in parens):

>> print mold collect [for x 0 255 1 [if 4 < length? mold to-char 
x [keep to-char x]]]

[#"^@" #"^A" #"^B" #"^C" #"^D" #"^E" #"^F" #"^G" #"^H" #"^-" #"^/" 
#"^K" #"^L" #"^M" #"^N" #"^O" #"^P" #"^Q" #"^R" #"^S" #"^T" #"^U" 
#"^V" #"^W" #"^X" #"^Y" #"^Z" #"^[" #"^\" #"^]" #"^!" #"^_" #"^"" 
#"^^" #"^~"]

I.e. while you can get rid of pointer! and just use &[integer!], 
that is fine. But if you specify integer! as always being a 32-bit 
integer, you lose out in hiding cross-platform quirks.

I'd have the &[] syntax to always mean "pointer to", i.e. a reference 
type.
And as far as I understand the current spec,
  a: &[integer! 0]

means "a pointer to an integer!, with the pointee's address being 
0"

I.E: the rebol's VM size is small, that's an adventage if I work 
on a computer with 1.44Mo flopydisk as main support, it's just stupid 
if I have 1Tera e sata hard drive. Or rebol vm runs everywhere your 
script the same, you take area-tc and surprise it doesn't work on 
windows seven on linux and macOS X.  Or it's easy to do networking 
with rebol. If you do TCP or UDP yes if you do something else you 
are unable to proceed ... see that's always double side half truth 
in rebol and that's really what I don't want to see in Red this is 
not a big contribution but it's important enough for me to be said.

shift funcs are useful f.e. for checksums, securtity funcs etc. I 
thought the shift funcs will be produced using shift machine codes 
(i e single operation). Is there some kind of optimalization for 
multiply/delete by pow of 2? Also consider not to implement overflow 
for << (true shifting)

Another function is the math EXP function. It just raises the number 
e to some power (the argument). A language like C (and probably most 
others languages) has this function (in the math library though). 
Probably to make code faster, but it can easily be defined as a REBOL 
function, right?

>> exp 1
== 2.71828182845905
>> myexp: func [v] [2.71828182845905 ** v]
>> myexp 32
== 78962960182685.1
>> exp 32
== 78962960182680.6

So we might need more digits for e.

With e defined, the hyperbolic cos, sin, tan, etc. are easy (REBOL 
doesn't have these), and maybe also normal cos, sin, tan!? At least 
for complex numbers, but not so sure about reals. Maybe a better 
mathematician can tell us that? Ladislav?

i.e. if your struct fits in two machine words, some (x86) compilers 
use eax and edx to return it

though in rebol not having type for vars and () for function arg 
submition, make difficult to identify var content  distinguish var 
from function ... Maybe then  a syntaxique item like th e $ in php 
for vars or the @ in ruby for tables would be an interesting point... 
Sorry I try to think about rebol syntaxe structure like someone seing 
it for the first time

SWITCH native implemented in Red/System, here is an example of supported 
features:

a: 5
ret: switch a [
	0 	[print "0" 0]
	1 #"^E" [print "1" 1]
	2 6 	[print "2" 2]
	3 	[print "3" 3]
	default [print "no match" -1]
]

print [lf ret lf]

Gabriele used this model instead for Topaz:
ret: switch a [
	0 	[print "0" 0]
	1 #"^E" [print "1" 1]
	2 6 	[print "2" 2]
	3 	[print "3" 3]
] [
	print "no match" -1
]

REBOL itself is incompatible between R2 and R3
 - counterexamples:


- my INCLUDE is a complicated script that is working in both environments, 
i.e., the compatibility surely isn't "incidental" in your own words

- the core-tests suite is working in both environments as well, containing 
more than 3000 interpreter tests

I also find myself using PRIN regularly (i.e. much more than 1% of 
the time I _don't_ want to print a newline right away).

depends on the definitions of  foo and other tokens. I.e. on context

on the other hand, i'm certain that you can model Red/System's syntactical 
structure with a context-free grammar. it's just that the CST/AST 
would look quite different from other languages (i.e. in that it 
does not explicitly model function call structures)

i.e. you won't get a "funcall" node in the AST

I.e. after each #define and after it the #include, we would need 
to recompile the included file. That's enourmous lossage of time 
and resources.

Its given as example for #enum directive, but it cannot be compiled.

#enum [a: 1 b c d: e: 10]   ;<--- missing <name>
print-wide [a b c d e]

#enum colors [A B C D E]   ;<--- redeclaration
print-wide [A E]

As for Topaz, it's the experimental one. Red is supposed to be more 
REBOL-like, to facilitate easier conversion of REBOL code, but Red 
is Gabriele's experiment with language design. He's already proposing 
to do things differently - i.e. function optional arguments - so 
it will likely end up quite different :)

Teaser 7: The range datatype

w> type? 2-5
== range!
w> block: [a b c d e f g]
== [a b c d e f g]
w> block/2-5
== [b c d e]
w> block/4-4
== [d]
w> block/4-3
== [c]
w> block/4-1

But they also provide a set of ready-built binaries which work as 
a nice AOT compiler for C/C++/ObjC. I.e. just like GCC or MSVC or 
ICC or ...

I.e. as INSERT is able to _reset_ compiled state, so should be the 
user.

my only suggestion for structures...  make it so the semantics are 
exactly the same as C.    
i.e. you take a C header file, and do:

replace/all header-string "{" "["  
replace/all header-string "}" "]"  
replace/all header-string "char *" "pointer"
...


and basically you've got your simplest World version of the spec 
 ;-)

but you need to have [disarm] when used with R3.
I use this defintion:
>> unless value? 'disarm [disarm: func[e][:e]]

I figure that we should look at the email formatting standard, then 
subtract support for any syntax that would conflict with something 
else in REBOL, especially if that doesn't commonly show up in actual 
email addresses. We've already made some tradeoffs in favor of email 
(i.e. no @ in issues or words), maybe we want to make more.