AltME groups: search

Just a remider that boron is an fully open-source REBOL-like evaluator 
built-in C. It has 23 datatypes and more than 100 "native" functions. 

The Boron homepage is at http://urlan.sourceforge.net/boron/

Surely, it's only a possible problem if you are going to embed Boron 
inside your code?

Maybe it's that you can't look at the source and then work on a comparable 
non-*GPL project?

Java's a special case: It got popular while it was proprietary, but 
open source people wanted to use it too but they couldn't. So they 
cloned Java under a Classpath license, which eventually led to Java 
itself being GPL'ed, which may have led to Sun dying (hard to say, 
but it did kill Java's value to the company). Still, it's mostly 
the proprietary versions of Java that are in use, and the business 
model is mostly based on proprietary restrictions to the use of the 
code.

note, I didn't want to start a licensing discussioh, it was just 
an observation based on my perspective as a "curious outsider"  of 
the Boron project.

As the only comparable projects to boron seem to be REBOL and World 
(both of which are closed source),, I can't see the "not being able 
to look at the source" issue being a problem. I don't think that 
boron's licensing has anything to do with its level of popularity.

Kaj - why should anyone stop using any product? That's a fanatical 
claim.

And if GPL is really like that, it is in fact denying a freedom of 
choice. BSD like licences are the way to go.

Sorry, Peter was wondering why people in the REBOL community didn't 
adopt Boron. Aside from REBOL being good enough, licensing was why. 
I have no reason to not use a *GPL product as a black box - it's 
looking at the source that can be a problem.

Not really. The main way that I learn a programming platform is to 
view the source, though on platforms where the source is not available 
(as for proprietary platforms like Delphi) or too complex to be of 
use (C++ compilers, office suites, most operating systems) then I 
try to go by the docs and experimentation. If I want to contribute, 
I need to see the source. However, if I learn anything by looking 
at the source, I have to be careful about how I apply that knowledge 
elsewhere if I might violate a license by doing so. So I use Linux, 
Java, OpenOffice and GCC like they are black boxes with no sources 
available, only because they are useful enough to be worth using 
without really learning from them. I wish I could contribute to Boron, 
but it might interfere with my ability to contribute to REBOL and 
Red. And I already have a good enough semi-black box in R3.

Boron is a library, so encapping would be writing your own host for 
it, so the LGPL library stays separate

OK, so I could use Boron as a black box if necessary - good to know 
:)

Nope, but I wrote most of the R3 mezzanines and all of the recent 
changes to the R2 ones, and my contributions were either MIT licensed 
or contributed under the condition that they be open sourced under 
a permissive license - no copyright transfer agreed to. And the host 
code is in the open portion of R3 - I haven't seen any closed source.

Brian, your "see the source" fear is silly. Sure, there's a lot of 
copyright terror in the USA, but the idea that the authors of Boron 
would sue you because you wrote similar code elsewere is ridiculous.


Also, copyright covers verbatim text, not ideas. You can use what 
you learn in any way you wish, this is not about patents.

Hi, I am interested into building an maintaining documentation for 
those programming languages based on REBOL.
It would be nice to have a DOCBASE for them.
What I search is:
- Someone ABLE to SETUP the Linux and the Wiki Software
- Someone which would share with me the cost of hosting.
Do you like the idea ?
Write me at [giuseppe-:-chillemi-:-eu]

Hi, I can setup mediawiki (or any other) on my web site: http://www.moldibi.com
which is up for 7-8 years. Its hosted on hostgator. I have unlimited 
storage / MySQL DB / bandwidth etc.

But I only have 1 domain name. If it is ok I can create any number 
of subdomains like world.moldibi.com or red.moldibi.com and give 
you a FTP account if necessary.

I've added a +1 in my version to compensate for that.

Hmm, you've transformed 'from-native, but as the real need was in 
fact to be able to get a binary! representation of a decimal! value, 
I tranformed 'to-native and 'split for that purpose. Has this IEEE 
library is quite rich, the need for the workaround of the intermediary 
string! representation is not needed anymore. Anyway, thanks for 
the update, I'm sure we'll need it at some point for float support.

I'm trying to add a word to each object  in a block of objects with 
a foreach loop above but it's not working.  Can anyone help?

In R2 you can't add words to an existing object, you have to make 
a new object (as you are above) and change the reference in the block 
to that new object. FOREACH gives you the object, but not the block 
holding it. FORALL will work for this. e.g. 

blk: reduce [make object! [ test1: 1 ] make object! [ test1: 1 ]]

forall blk [
    change blk make first blk [test-2: 2]
]

probe blk

So there is a difference, if no type is specified and if any-type! 
is specified. Like in:

>> f: func [v][]
>> f
** Script Error: f is missing its v argument

>> f: func [v [any-type!]][]
>> f

HELP does display it differently. In the first case, it's:

ARGUMENTS:
     v -- (Type: any)

and the second:

ARGUMENTS:
     v -- (Type: any-type)


Subtle differences. And you're correct, Ladislav. Insert and append 
sould take the same kind of argument.

In general, no, as functions need not be bound to a word.

So far I'm using this:
myfunc: func[
	"Defines a user function with given spec and body."
	[catch]

 spec [block!] {Help string (opt) followed by arg words (and opt type 
 and string)}
	body [block!] "The body block of the function"
	/local desc
][
	if parse spec [set desc string! to end][
		insert body reduce ['log desc]
	]
	throw-on-error [make function! spec body]
]

In R2, use the catch-an-error trick

      a-function: func [][print ["i am named " get in disarm  try [0 / 
      0] 'where]]
      a-function
      i am named  a-function

Just remember that a function does not really have a name. Just the 
name, if any, by which you called it:

    b-function: c-function: :a-function   ;; one function, many names

    do reduce [:a-function]                      ;; one function, no 
    name

http://www.synapse-ehr.com/community/threads/rebol-on-windows-7-and-a-network.1424/#post-10560

Anyone?

Interesting. I remember some talk about it in the past, but I thought 
it was fixed, or it was a different issue. I will try tomorrow at 
my work, our share is called "L:" too :-)

Graham, gotta love that Win 7.  I was about to move all my belongings 
to a W7 machine and retire my XP but not now.

GrahamC, thank you for passing this around.  I did get part way to 
a solution, as noted on your site.  Strange as it may seem, I am 
able to get to the network drives if I run a copy of REBOL that I 
download and leave with the name it came with, namely rebol-view-278-3-1. 
 The copy of REBOL that was giving me trouble was the same rebol-view-278-3-1, 
but I had renamed it to rebview to make a desktop shortcut work. 
 I had the name "rebview" in the shortcut so that I would not have 
to change the shortcut if I ever got an upgraded version of REBOL 
with a different name, like maybe rebol-view-279.  So my first problem 
with WIndows 7, REBOL, and network drives seems fixed.  


I still am not to a full solution to my Windows 7 issues.  I have 
some REBOL scripts that use the "call" command to run powershell. 
 Powershell then runs a powershell script to extract stuff from an 
EXCEL spreadsheet, which then is manipulated by the REBOL script. 
 Actually it's a bit messier.  I run a REBOL program launcher on 
the C drive which runs a REBOL script on a network drive.  The script 
on the network drive calls powershell with parameters to make powershell 
run a powershell script.  The powershell script extracts EXCEL data, 
and the calling REBOL script then makes a report of the extracted 
data.  


When I try to do this, the result from powershell is that I am not 
allowed to run scripts on that computer.  I am aware of this feature 
of powershell, and I have done what has worked for Windows XP (set-executionpolicy 
remotesigned).  I can run powershell directly, and execute scripts 
located on a network drive.  When a REBOL script that worked on XP 
calls powershell on WIndows 7, it won't go.  I am not expecting any 
help with this last issue at this time because the "call" does work 
in some cases (call/shell "notepad") (call/console/show "powershell"), 
so I still have several things to try, and if none work I am plotting 
a work-around.

Also try to use the full path. Once I have faced a problem CALL with 
REBOL style file! value. It worked with a windows-style path.

And also have problem with /shell worked on my XP but did not on 
my customers W7.

When I use FIND with CHARSETs it ignores the /TAIL refinement. Is 
this a bug?

;with charset
>> find/tail "abc" charset "b"
== "bc"
>> find "abc" charset "b"
== "bc"

;with string
>> find "abc" "b"
== "bc"
>> find/tail "abc" "b"
== "c"

I think /last and /tail only apply to string values. Perhaps a feature 
that hasn't come to pass yet? :-)

Combination of find/tail and charset looks like a bug to me.

sqlab, a charset is not a string its a bitset, so it will search 
for ALL the characters in the charset at each byte...   also note 
that when using find, charsets are case sensitive (and very fast).
the bug with /tail is pretty surprising, I never noticed it.

Thank you guys. I know the behaviour of charset in FIND. But I expect 
to skip the char that found, if I use /TAIL refinement as in using 
string.
Same for /LAST as Gregg said. It ignored for charsets. 
And also;
>> find/reverse "endo" charset "d"
== none
a bit confusing..

I've got a function that doesn't and I know one of you can explain 
why. 
foo: func [  /dothis anobject ] [
 if dothis [
  dosomething anobject
 ]
]

foo myobject


So the dosomething function does not work with the "anobject".  However, 
If I hardcode the "myobject" into foo like:
foo: func [ /dothis ]
[
 if dothis [ 
 dosomething myobject
 ]
] 


It works. So my questions are: Is it because "anobject" is a pointer? 
And what do I do on the calling/receiving sides to fix that?
Thanks in advance.

OK, figured it out. I had to pass the object as a 'word then "do" 
it in the function to get it to work.

In your example, you didn't spec the /do-this refinement on the call. 
Probably just a glitch in posting here though.

Thanks Graham and Gregg. The object that I was passing was a face 
and I tried different ways to get it to work and that was the only 
way it would work. I guess the question is how does one know when 
he is passing some value if the receiving function sees it as the 
writer is intending it to be seen. Anyway for now I am satisfied 
and have moved on to other issues. I appreciate your input though.

If the func doesn't take a lit-word/get-word argument, it should 
evaluate and pass as an object. Now, if you have a block of words 
that refer to list faces, and you pass that word, that's what you 
get. If your func has types defined for the args, that can help catch 
issues like this.

James, I think you are mixing up the word which refers to an object 
with an object value.  this is confusing in Rebol because words are 
not variables.  

it's happened to me a few times (especially in VID) that I mix this 
up in action blocks and VID dialect builders.

often, I'd build a block to be used and forget to reduce the block 
before appending it to the spec.  so what happens is that you receive 
an unbound word, instead of the data you assumed it should be refering 
to.

Thanks. I wish there was a way to compare words like this so one 
could find out what the difference was. I suppose that is part of 
the bindology world. Glad to hear you are working with Rebol. It 
could be me but I haven't seen you around lately. Probably me because 
I haven't been around much here myself.

I've been working a lot lately, and haven't had a lot of spare time. 
 I'm actually working with REBOL full time at a company which is 
using it to get a significant competitive advantage over the competition.

in my last test I was doing natural language extraction of concepts 
at a rate of 25000 words a second within multi-megabyte text files. 
 :-)

learning parse requires baby steps and at some point, the decision 
to solve a real problem with it and force yourself to learn it.  
I didn't use parse for almost a decade until I started using it more 
and more to a point that currently I do more parse than any other 
coding in REBOL (but that's just because its idealy suited for this).


some little tricks accumulate with experience and eventually, we 
discover pretty wacky things, which allow us to use parse almost 
like a VM.

REBOL parse is a gem, a treasure to follow. Me, the coding lamer, 
did few things using it. Guys coding C++ first came meh, well, interpreter. 
Then  - how is it possible it is faster than C++ app? Later on, they 
came with new requests asking - well, you know, you have that parser, 
we need to do following stuff ...

Guys, with all this said (and I agree), perhaps this is the one things 
that needs to be the focal point for Rebol and eventually the #Not 
Rebol languages.  I know there are some tutorials out there but do 
any of them do justice to parse? I keep going back to the Codeconscious 
one: http://www.codeconscious.com/rebol/parse-tutorial.htmland 
the ones at reboltutorial, but there doesn't seem to be a lot considering 
how much one can do with it.

I learnt parse using the 2.3 rebol core guide...  I thought it did 
a pretty good job of launching one in the good direction.   parse 
HAS evolved since then, but for the basic semantics and principles 
of parsing I think its pretty good.

you can also look at this tutorial by Nick Antonaccio:
http://musiclessonz.com/rebol_tutorial.html#section-9.3


IIRC nick has a good sense of tutoring, so it may be a good first 
step... he also gives links to other parse resources at the end of 
that part of his (short) tutorial

R2.   


since we compile just about all the rules from other datasets and 
simplified user-data, the R3 advantage is much less significant (because 
we can simulate all the R3 improvements by using R2 idoms, though 
its sometimes tricky).


Using R3, it probably would be a few percent faster since some of 
the rules we have would be simpler and those tricks would be managed 
natively by parse rather than by *more* parse rules.

The problem with R3 right now is that it isn't yet compiled in 64-bits 
we still have the 1.6GB RAM limit for a process which is the biggest 
issue right now.   I have blown that limit a few times already, so 
it makes things a bit more complex and it doesn't allow me to fully 
optimize speed by using more pre-generated tables and unfolded state 
rules.

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.

yeah...  I've got a server that has 64GB of RAM  I want to use it 
 !!!   :-)

(btw that 1.6GB limit used to be a real problem when I was doing 
3D stuff...  3D animation apps are memory hogs, and in some cases, 
we could only work 15 minutes before high-end apps would crash.

which is a problem when a 3D scene takes 30 minutes to save to disk 
over the network  ;-)

can anyone explain a single use for this R2 path conversion?

>> to-string first [path/item]
== "pathitem"


I know I can use mold... it's just that I wonder why to-string doesn't 
use the molded string equivalent as well?

I'm not complaining, I just find absolutely no use-case for the default 
  :-D


my question was can anyone give me a reason for the current use of 
to-string?  

can you?  ;-P

O*O*n
  == a typo  :-)

I guess I really meant  something like O(n*n) 


Its the kind of dramatic  linear vs logarithmic scaling difference 
when we unfold our datasets into parse.


but its not exactly that kind of scaling, since the average topology 
of the sort tree will have a lot of impact on the end-result.  for 
example in my system, when I try to index more than the first 5 characters, 
the speed gain is so insignificant that the ratio is quickly skewed, 
when compared to the difference which the first 3 letters give.  


Its 100% related to the actual dataset I use.  in some, going past 
2 is already almost useless, in others I will have to go beyond 5 
for sure.  in some other datasets we unfold them using hand-picked 
algorythms per branch of data, and others its a pure, brute force 
huge RAM gobler.

I always love when I realize that I write things like this in Rebol:

-*&*&*&*-:  "a pretty impossible to guess variable name :-)"

it also looks in the current-dir... but that path will depend of 
how you launched rebol.


use WHAT-DIR just before you try to load your dll  to know where 
the current-dir is at that time and put your dll there.


you can also add a path in the user or system path environment and 
place the dll there.

I'll continue here for now, as /library is now a free part of Core, 
and DLL.SO is not web-public.

My observation is, that if there are one or more dependant DLLs, 
REBOL will load first one, but then the path is somehow not taking 
into account a present directory. Here's few pointns:

- you can't do: do %my-dir/my-dll-script.r
- nor you can do so after: change-dir 


But it works, when you launch REBOL from the directory where those 
DLLs are present.

/library is not a free part of Core only View.

Maybe the question should be put the other way around: Are there 
cases (in real scripts), where it would be a problem, if datatypes 
equals words?

Note that we also have a literal syntax for none! and logic! values 
now, which makes all your finds succeed even without reducing:

>> find [#[true]] true
== [true]

Etc.

Integers are not decimals, but they're both numbers, and we can check 
like:

>> 1 = 1.0
== true

Refinement are not words, but they're both any-words.


Why not let datatypes (and none and logic) be any-words just the 
same? If the benefit from doing so is big, then it could be a good 
idea.

w> /refinement = 'refinement
== true

The question is, if the following would lead to a disaster?

w> integer! = 'integer!
== true

There is a big difference between having datatypes be word values, 
versus having them fall under the any-word pseudotype. The latter 
seems OK, but not the former. If I understand you, it would cause 
things like [datatype? integer!] to fail, because it would return 
word!. That is, we lose them as an identifiable datatype. I use them 
for reflective tools and dialects. While the change wouldn't make 
that impossible, I like them being first class citizens as they are 
today.

No, let me clarify. I want integer! to represent a datatype, like 
1 represents an integer. So datatype? integer! should return true, 
and word? integer! should return false, just like decimal? 1 returns 
false.


I simple suggest equal? to return true, when comparing a datatype 
with a word of the same spelling. Like this is true:

>> equal? 1 1.0
== true

in R3:
>> b: make map! ["a" "b" "b" "c"]
== make map! [
    "a" "b"
    "b" "c"
]

>> select b "b"
== "c"

in R2 I know only:
>> all [tmp: select/skip b "b" 2 first tmp]
== "c"

It's really sad to know, that we cannot expect any improvements in 
a future:/

MAP is an associative (Key <-> Value) data "storage". In R2 a correspoding 
way would be to use the hash! datatype, however, if you want to discern 
keys from values you need to use a separate Keys hash! and a separate 
Values block, otherwise you end up having Keys and Values intermixed. 
Your way of using the /skip refinement and a block is slower, however 
it searches only in Keys as well due to the /skip 2 use. When not 
used, it would search in Values.

(hope it explains it a bit)

I know the theory:/ To have separate hashes for key and values would 
be even more complicated. I would be fine if the select/skip would 
not return a block which is simply stupid... or correct me if there 
is any reason for that. It's sad we cannot have map! in R2.

In my case I will have just a few key-value pairs.. so the speed 
is not a problem, more important is to be safe that the key will 
not be mixed with values.

If I could move time back a few years and I could vote, I would like 
Carl to enhance R2 a little bit instead of starting R3 which he probably 
never finish.

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"]

Oldes: I was just about to write this, I asked is this a bug a few 
months ago, but no, it returns a block when you select with /skip 
because you can select more-than-one value if your skip size is > 
2 , otherwise you cannot get the further values. You select block 
of values when use /skip.

Maybe do somehing like:

>> keys: make hash! ["a" "b"]
== make hash! ["a" "b"]
>> values: ["b" "c"]
== ["b" "c"]
>> pick values index? find keys "a"
== "b"
>> pick values index? find keys "b"
== "c"

The
	pick values index? find keys
could be put in a nice function to call.

Or wrap it in a context:

map: context [
	keys: make hash! ["a" "b"]
	values: ["b" "c"]
	pick: func [value] [
		system/words/pick values index? find keys value
	]
]

>> map/pick "a"
== "b"
>> map/pick "b"
== "c"

A good language is also easy to expand and integrate with other technologies. 
For some projects, it may be a good idea to have the language as 
a dynamic linked library.

Geomol, I already know that you made some technical choices in World 
that I would not have done because I think (maybe I'm wrong) I know 
better ways to do faster VM.

So, to my mind,you already failed in the task to deliver a promising 
clone.

Just to say that your 'needs' , expectations and technical skills 
are probably not the best in each room.
;-)

Copying a cyclic block:

>> blk: [a b c]
== [a b c]
>> insert/only blk blk
== [a b c]
>> blk
== [[...] a b c]
>> copy blk
== [[[...] a b c] a b c]

That's not correct, right?

One question to library wrapping. I have a function, which should 
return a bool from C level, according to if the communication card 
is open, or not. When I am able to open the card, it returns 1 (mapped 
to R2 integer!), if not, it returns  30605312 - does that integer 
make any sence? I mean, does it e.g. translate to some C level slot, 
overflow, or -1 value? Just curious ...

bool is in C since C99, and it's, in fact, *drumroll* a typedef/#define 
for _Bool

The C standard is (as always) very vague and doesn't specify a particular 
storage size. I think it just defines that _Bool must be able to 
hold 0 and 1.

So when encountering a "bool", one really has to ask what kind of 
bool that is. More often than not, it won't be a C99 _Bool and will 
actually be int-sized.

If it is a C99 _Bool, it will typically be char-sized, though.

And I think Pekr really has a different case, because he's trying 
to use a C++ lib. C++ really has a bool, and I think it's char-sized 
(but I don't know whether that's impl-specific in C++ or defined 
in the C++ standard).

If it is a C99 _Bool, it will typically be char-sized, though.
 - hmm, I found explicitly stated that it should be int

when it is int it could be 64bit or 32bit.. depend on the compiler 
and the OS. 

Pekr: So may be the C library returns a 64bit integer: #{0000000001D30000} 
= #{00000000 - 01D30000}, the left part is 0 (=false) the second 
part is just a number from stack.. 
When you get in from R2 it become #{01D30000} = 30605312

Or it's a 16 bit return, and the machine, it's from, is little endian, 
where World is big endian. Then it's the last 4 zeros in the result, 
that is the bool.

{"If it is a C99 _Bool, it will typically be char-sized, though." 
-- hmm, I found explicitly stated that it should be int}

Where?

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

Update!


I'm implementing support for cyclic series in World these days. My 
initial research about freeing memory taken by cyclic series made 
me realize, that it'll hit performance, if every block and paren 
freed is being tested for cyclic references. So I'll implement a 
FREE mezzanine written in World, that can free such structures. This 
lead me to molding such structures, which is only partly implemented 
in current version of World and copying such structures. Those functions 
will be mezzanines too, as it's much easier to write the code in 
World than in C. So some C code will be removed in next release, 
but we'll have some more World code instead.

Btw. COPY is by defauit deep in World (contrary to REBOL), and World 
will support deep copying of cyclic blocks, which gives a stack overflow 
error in REBOL.

The main goal (but surely not the sole goal) to have a formal specification 
of REBOL syntax.

We do not need to be too limited, currently the source is R3 specific, 
but I do intend to put in also R2, and the inclusion of other alternatives 
may be a worthy enterprise as well.

could we add a rule which joins all the higher-order rules into a 
single rule which can ultimately tell if a  script is compliant to 
the whole syntax.r rule?

could we add a rule which joins
 - that rule already exists, can you guess which one it is?

ah.. hehe my browser had an old version of the rules... did a page 
refresh and there it was   ;-)