AltME groups: search

put it into curecode and add the above bug within the report... it 
will add to its relevance (and priority) within the post.

curecode is also for wishes... so if you want R3 to be what you want 
it to, you have to speak... and curecode is that place... many blog 
posts where originated from good curecode reports/suggestions.

And I have had one date related issue fixed.

Graham, the explanation is that dates are not really mutable (or 
more precisely, are always passed by value and not reference). the 
date/anything: is a hack. (I sometimes think that, no matter how 
useful they are, those hacks only hurt a language in the end...)

REDUCE can be used to reduce blocks, and by that evaluate parens 
within blocks:

>> reduce [(1 + 2)]
== [3]

But REDUCE won't evaluate parens themselves:

>> reduce first [(1 + 2)]
== (1 + 2)

Is that a bug? (Same in R3.)

I see no bugs.

REDUCE,  acts on blocks, nothing else.


TO-PAREN and TO-BLOCK on strings, act like LOAD, but don't bound 
the result in any context.


Both of them have well known behavior. It's perhaps a lack of good 
documentation but no bugs.

I'm probably wondering, because parens works in many ways the same 
as blocks, but not when reduced. The same can be said about paths.

and

Parens and paths are default being evaluated (by the scanner/lexical 
analysis), blocks are not. And when you reduce blocks, parens and 
paths within the block are being evaluated. On the other hand reducing 
parens and paths won't evaluate them. I tend to agree, it's not bugs 
but lack of documentation.

No really.....There is Puzzles and Puzzle Answers here, but they 
aren't very web-public.

There have been some nice puzzles on the mailing list:
   http://www.rebol.org/ml-topic-detail.r?l=p&topic=puzzle

The big problem with most code golf puzzles is they only ever play 
one one......It'd be better to have puzzles that are rolled out in 
stages: each stage being a modification to the previous puzzle spec. 
that way, generality and flexibility would be rewarded.

Ubuntu 9.04; rebcore (2.7.6) can     devmem: open/read/binary %/dev/mem
rebview hangs.


Do I need to care?   I don't need View for this little informational 
gathering app, but ...


We are planning for an embedded system BIOS tweak so we can label 
an Asset Tag in the SMBIOS;  REBOL won the race getting the information 
decoded for everyone to see; beat Python development by a few minutes 
(in a highly uncompetitive sharing information back and forth development 
"race")

So, age is displayed as a days for under a week, in weeks for under 
3 months, and as months upto 3 years, and then as years/months after 
that.

I ended up using case .. and just straight subtraction of years etc 
instead of using 'difference which can sometimes lead to numeric 
overflow.

Something similar I've used:
   DayConv: func [Days /local Ret Tip][
      Ret: copy {}
      Tip: false
      foreach Val [[365 y] [31 m] [7 w] [1 d]] [
         if Days >= Val/1 [
            append Ret join to-integer divide Days Val/1 Val/2
            Days: mod Days Val/1
            if Tip [return Ret]
            Tip: true
         ]
      ]
      return Ret
   ]


'Tip was to make it stop at just two time-indicators (So 2 months, 
1 week, and 3 days would display just as 2m1w, omitting the days, 
for example)

(Messy looking implementation is due to being reeaally tired at the 
time, just never felt like fixing it up...)

When you write

d: 'a/:c


d become a path! datatype, and it's not connected to your block, 
a, in any way. If you wanna expand the path, you can do something 
like:

>> join d 'h
== a/:c/h

Is that what you wanna happen?

It seems path! doesn't work like file! but more like block!, which 
is also what Gabriele pointed out, I think.

>> d/a
== :c


And that is also, why d/h fails. h is not found in the d path anywhere.

It is a bit confusing, also because both path! and file! are series, 
so it's easy to think, they should work the same.

>> series? d
== true
>> series? %/a/b/c
== true

A question: can it be justified, that file! is a series?

>> a: %/c
== %/c
>> first a
== #"/"
>> a/1
== %/c/1


Is file! a pseudo-series? What exactly defines a series? It's some 
sort of a sequence of values, that can be picked individually. And 
series can be sorted, right? So the methods (or functions), that 
can be performed on the datatype defines its type. What defines a 
series in REBOL?

hehe I was writting up the EXACT same reply than geomol pointing 
out block and how to use do join x y ... had to for an exam at the 
dentist... I come back and geomol beat me to it  ;-)

Geomol: "What defines a series in REBOL?"


A series has contents, sequence and persistent position. The characters 
that make up a file (contents) are in a specific order (sequence) 
and you can do an offset reference to a later offset in the filename 
(position). If you do FIRST %a it will return #"a" every time (persistent 
position). Being a series doesn't mean that it is sortable, though 
many are. Being sortable means also having the contents be comparable, 
and the series be modifiable.


We were careful to make sure that things that aren't really series-like 
were removed from the series! typeset in R3. R2 is less consistent 
in this regard, so you have some types attempting to act series-like, 
poorly - pots being the worst example.


Some of the functions that act on series also act (differently) on 
non-series, but not all.

I thought that to qualify to be a series, a type also needed to support 
insertion, not only indexing and content.


cause your above definition qualifies tuple! to be a series, but 
they aren't.

Position: HEAD, TAIL, HEAD?, TAIL?, AT, SKIP, NEXT, BACK

Contents: PICK, POKE (for modifiable series), ordinals (FIRST, ..., 
LAST)

Sequence: PICK and POKE can use numbers (used to implement ordinals)

Persistent position and sequence: All of the above are repeatable, 
with no position change side effect.

and INDEX?   ;-)

Bitsets, tuples, objects and maps don't have position. Objects and 
maps don't have sequence either (at least not in theory).

Ports in R3 (or open/direct or command ports in R2) don't have persistent 
position and sequence, or reference position. This makes them streams, 
not series.

yes basically, they are always at position 0 and looking at the data, 
implies you remove it, so ports are like quantum series  ;-)

Well, paths are like blocks, not like filenames. You can't make them 
act like filenames without breaking them *in every other way*. You 
can build path just fine with JOIN and APPEND, you can fully evaluate 
them with DO, and you can partially evaluate them with get-paths 
without ever needing to use GET IN. Functionally, there is no problem 
with R3's current behavior except bugs 396, 861, 1236, 1339, and 
maybe 746 and 803.

Anyone know a simple way to transform a block of sub-blocks into 
a single block while retaining the original type? I have [ [1] [2] 
[3]] and I'd like [ 1 2 3]. I can do with with form and parse but 
it  then I get ["1" "2" "3"].

this should be a native in R3... there are MANY places where this 
is both needed and its always slow.

I've got some gui code which I am loading from a text string, and 
then running it.  I am binding it to some local words which I want 
to use and that works fine.

But I also want to invoke functions in the global context and it 
can't find them.  What to do?

eg. the text is

button "test" [ alert "hello" ]

and I get an error clicking on the button.

'isolate takes a block of words, creates an exclusive context, sets 
words in that context to their value in their current context and 
returns a word bound to that context.

and define a variable/word "pages" in the block like I did .. this 
word changes the global binding probably? which is not very good 
because it might owerride some other binding ... am I correct and 
is there some elegant way to not introduce such negatiev side of 
this otherwise elegant pattern?

Brock: it went okeyish ... otherwise it was great and I did sew some 
pushed out eyes (from few python programmers) towards the end. The 
problem was I had very programmer / code - centric presentation , 
where I was hoping to give (better) coders some clue what and how 
REBOL is different, but when I asked how many of them were programmers 
it was just like 20% or less . So I had somewhat hard time trying 
to show details of code and tons of code examples imagining that 
the most of listeners will have no clue whatsoever about what I'm 
talking ...

I see now that I should just focused my thoughts on those guys who 
were programmers instead of seeing all the nonprogrammers not understanding 
a thing I was saying. Basically I missjudged the audience. And there 
would probably be more programmers if there werent two very interesting 
talks with known names at the same time as mine.

I am not joking about "pushed out eyes" ... I saw 2 that were programmers 
that were towards the end really intenselly looking at code I was 
showing and how I'll explain it.  


the whole thing about read http:// read %file ... open pop:// and 
process it as serries qute impressed one guy 


When I ended a couple of other programmers aproached me and asked 
me how this can be installed and if it's free etc .. and one pythonista 
said that email sending really impressed him, but otherwise he doesn't 
know yet .. there were also questions like "why this and not python" 
and "community size" and I had some explaining to do about code is 
data / data  is code big deal

It makes me think that the process of downloading and installing 
REBOL is a great demo in itself.

Yes, I was thinking of putting the scripts there but then a lot less 
people would see it.. you know how people are .. first and foremost 
LAZY

When I asked how many were programmers and only 4 raised hands I 
almost wanted to stop talking because from that point on almost all 
slides are code and at the end I was trying to look at concrete scripts 
which I was worried also coders won't understand so quickly after 
finding out at rebol

Many scientific talks are divided in two parts: One for the masses 
and one for the experts.

If I knew  how it would be I would prepare more light talk , with 
some cool stuff , only little code and more visual .. like doing 
a gui to post message on twitter all in few lines and typed in front 
of them . I had demo of this when I was preparing for talk

I will be playing with some erlang soon , did anyone maybe yet work 
anything on the BERT serialisation .. http://bert-rpc.org/(it's 
the binary erlang term serialisation). BERT-RPC based on it also 
is very minimalistic , binary (so you can send over images or anything) 
, and has some really cool features ?

Talks often dont' go as planned Janko. I'm sure you did fine. 


For a less technical audience, I try to focus on how little code 
it takes to do useful things; and how readable that code can be. 
Having some simple GUI examples is important, because normal people 
don't want console apps. For programmers, I emphasize that REBOL 
isn't really a programming language; it's a messaging language. As 
Carl has said "It was designed for the semantic exchange of information 
between people and machines." So it's never REBOL compared to Python, 
or Ruby, but compared to those languages plus XML or JSON.

I haven't seen anything on BERT, but Maarten has done some Erlang 
and may know.

It was ok.. I was not sooo satisfied with situation but I was satisfied 
on how I handeled it and it was ok.

One collegue smalltalker that we meet at previous barcamp wrote me 
on twitter something like "this is bloody usefull :-)" after seeing 
the slides and code examples screencast on internet.

I often find myself thinking about, how to categorize REBOL among 
other programming languages. I think, it's how the language wants 
us to make sentences and not just give commands, one on each line. 
In REBOL, we write:

insert back tail series my-value


and it feels natural. In other languages, you would do something 
like:

int sz = length (series);
Series *ptr = &series[sz - 1];
insert (ptr, my_value);

You could maybe do:

insert ( &series[length (series) - 1], my-value);


but it's just far from being as elegant as in REBOL. So most languages 
are like simple commands all the time, one after each other. With 
REBOL we make sentences. It's like a huge step up from many traditional 
programming languages.

Yes. I think of this aspect as combing the best elements from Forth 
and Lisp/Logo in a natural way. That is, lists (blocks) are the foundation, 
and you build up a vocabulary to do what you want. It also encourages 
us to structure and doc things a little more, compared to Forth; 
but you have the freedom to express things any way you want. It's 
a very different view from Python, where (my opinion), the goal is 
to make all programs look the same, no matter what the problem domain 
is.

I remember from Factor irc where they tried to make smtp compat with 
gmail that gmail does something a little different that with regular 
ssl connections. I think it starts without ssl and initiates it in 
the middle of communications or something like that

This script http://accessories.s3.amazonaws.com/hotmailer.r


uses a secure pop protocol to login to hotmail and download messages, 
and remove attachments.  Should work with gmail.

>> to-decimal "0 "
** Script Error: Invalid argument: 0
** Where: to-decimal
** Near: to decimal! :value


now it seems to me that if you're going to allow string input to 
'to-decimal then the most likely instances of this type of data is 
where it has been parsed in or comes in via a form and so it should 
by default handle whitespaces

Some guy got Arc to run on one of these and setup a web server

hi, i would like to know if R2 and R3 have a scheme for LDAP ?

MikeL: I think that we are at the very beginning of such topics. 
You can read my marketing/strategy related material in Article REBOL 
adoption, and I reduced it to two words - EASY DEPLOYMENT:

http://www.rebol.net/wiki/Marketing_Strategy_Websites

To answer your question in more concrete manner - I think that we 
have to stop and prevent our past ttitude of "you can code it yourself". 
Many ppl who come or will come to REBOL, are seeking a solution, 
they are not interested to do the work themselves. I think that R3/Extensions 
open some door to link to many outer system. But the hard work still 
needs to be done. As we are a small community, I once again propose 
some kind of Bounty system, so that we can sponsor most popular requests. 
This should address one aspect of the problem - REBOL devs not necessarily 
working only for free ...

Steve, I always use CALL these days. Or Gabriele and Doc's async-call. 
By using system/options/boot, you can launch the interpreter you're 
running under.

Alan, I haven't done it from the command line, but a quick search 
makes me think it might be possible using Windows Fax and Scan, if 
your on the right OS. I did a fax interface for Bo a few years back, 
but it used APIs. Graham may have thoughts here as well. He's done 
a lot with Hylafax I believe.

and in so much as rebol runs as a command line client, then it can 
be readily done.

when you use file! call does a to-local-file automatically, and wraps 
it in quotes.

wow, thanks guys, for the "launch buffet"  I was hungry, and you 
gave me to eat.

the first line is redundant, and the second line can be changed to 
a parse ...


   if parse headers/content-type  [ thru "boundary=" opt {"} [ copy 
   boundary to {"} to end | copy boundary to end ]][
        ;remove back tail boundary
        print ["Boundary string:" boundary]
   ]

which I think fixes it.

Just testing my script that logs into hotmail with gmail instead 
.. to download new email, and detach any attachments.  Seems to be 
working now.

I'm debugging some code here and found that the ARRAY mezzanine has 
at some point been rewritten during R2 versions. Does anyone know 
when this happened?

looks like the change was made between 2.7.5 and 2.7.6.

most smtp servers do ip filtering on the input.  this allows them 
to know who is sending the email to them and will only allow ips 
they serve to connect.


since your hosting account is probably on a remote server, it won't 
be allowed to send data via your home smtp server account.

Sorry for the redundant posts.  Altme was updating and msg board 
wasn't being updated at the time. I thought I was losing the info.

SMTP Relay lets you send email messages through your email account 
using your existing email service. For example, you can continue 
to use Microsoft Outlook to compose, receive, and send email messages, 
but the actual email messages are processed through our SMTP relaying 
services. This lets you bypass ISP restrictions on your outbound 
email messages and allows you to use your professional looking "[sales-:-coolexample-:-com]" 
email address rather than a general “[sales-:-ispname]” address.

set-net is the rebol networking setup function. it is usually run 
on install and is stored in your user.r

and if you're not on your ISP ... it probably won't even let you 
send the email

I've supplied all necessary info in set-net, which includes username 
and password.

make it a cgi script and see what is written to %log.txt

Wow, that's it! :-)  I've spent almost 10 hours trying to resolve 
this and I had the wrong smtp relay, duh me!  I really appreciate 
your help!

and who said we coudn't make profit by reboling  ;-)

Graham, you mentioned that I should encode the password.   Is this 
in case someone hacks into my host?  If I use the encloak function, 
couldn't someone also find my readable key in the script and then 
decloak my password using Rebol?

would there be instances where write/lines/append would write a quarter 
or half a line? I'm logging tests of several script instances into 
the same file and write/lines/append sometimes produces only half 
a line in the log.

but when things are in the millions, sometimes using a disk-based 
on-demand caching algorithm is fastest... it really depends on the 
application.


cause think of it this way.  every byte used by each element becomes 
a MB  so adds up quickly.


5 million pairs of (10 byte) strings and pairs... is just about 350MB 
!

 >> b: make block! 5000010
>> m: stats
== 84172417

>> loop 5000000 [append b copy random "1234567890" append b random 
10000000]

== ["5862713409" 4765171 "2546013987" 2726704 "9528013746" 3565380 
"4591302786" ...
>>  stats - m
== 348435008

(oops  'strings and pairs'  >  'string and *integers*' )

aha, I see that it depends .. I increased the length of string and 
block increased in size while hash stayed the same

Transfering memory based hash! (map! in R3) datatype into disk based 
shema automatically keeping the hash table computation and lookup 
hidden from user gives you a RIF. Holly grail of all rebollers :) 
long long time promissed, still waiting to be done. Anyway hash tables 
are always usually unsorted, when necessary to search in usually 
some type of additional index is used (B-tree for example), for simple 
information if the key is in the set, bitmap vectors are used with 
advantage, when the set is really big (and bitmap vector doesn fit 
into memory) comressed bitmap may be used and usually bitwise operations 
on those vectors are much quicker than on uncompressed. 

Thisi is why it should be used for bitset! datatype anyway. The number 
of byte aligned (BBC,Packbit,RLE)od word aligned (WAH) schemes exists. 
 It is used in very large datasets when index also resides in disk 
file. Once again bitwise operation may be much quickier even in memory 
on those schemes.

when map! will added to extensions, you might be able implement an 
example for us and Carl might consider adding your code directly 
in the host or r3lib if you agree to it.   :-)

I will be rebuilding the callback example with a much better/simpler 
design. but they work very well, basically I have mapped the Reb_Do_String() 
and Reb_Print() functions so that they can be called from within 
any extension.

this way we can create rebol code directly from strings and native 
data very easily.


there is currently a size limit on executed strings, its a simple 
question of optimisation.  this means we can't use the wiredf function 
for creating large datasets via strings (for now).

but I'm already doing stuff like:


wiredf("rogl-event-handler make wr-event [new-size: %p]", win-w, 
win-h);


calls rebol's do with %p replaced by a pair, using 2 ints.  this 
is a varargs function.

i was just thinking again about the idea of IF (etc.) keeping a reference 
to the condition argument for you, that is, so that instead of writing:

    if x: select block value [do-something-with x]

you can write:

    if select block value [do-something-with it]


The reason people say it's not worth it is usually that of having 
to bind/copy the block - you don't want that in every IF call and 
probably not even in the ones where it would be useful (and, there's 
really no other name you could use for the function).

so, I thought, can we avoid the bind/copy in any way?


actually, i think we can. some people would run in horror maybe, 
and Brian will complain about it not being thread safe (we still 
have no threads though), but what about the native was changed to 
do something like:

    func [condition block /local it*] [
        set/any 'it* get/any 'it
        it: :condition
        also
            if :condition block
            set/any 'it get/any 'it*
    ]

IT could be a function that returns the thread-local top of the stack 
of implied subject values. IF would then push a value on that stack, 
and pop the value off when it returns. Might be tricky to make error-throw-safe, 
but easy to make thread-safe :)

It is mostly used in combination with ANY and ALL for control flow.

For complex control flow rules, i rather prefer CASE.

Most of the time, combitations of ALL ANY, can be replaced by a CASE 
structure (which is faster and more readable)

I prefer CASE too, and have rewritten many mezzanines to use it :)

It doesn't always apply to the task at hand though. The IF and UNLESS 
return values have been applied to the general R3 control flow model, 
as have the changes to the ordinal return values, map! behavior, 
...

The advantage to this approach is that it would be error-throw-safe, 
as well as thread-safe, and require no changes to IF or UNLESS :)

I like Gabriele's idea.  I am one of those that has been using the 
if/unless return value for years, and quite often.

Re: IT - the problem in looking up the stack is knowing which argument 
to look it up. I guess the first would work and be useful enough, 
though.

Isn't something like this code already built-in in REBOL and I'm 
just missing it:

copy-to: func [series [series!] arg /local cpd d][
    cpd: make type? series 10
    foreach item series [
        either not-equal? arg item [insert tail cpd item][break]
    ]
    cpd
]

This function returns a copy of everything until it finds the value 
specified and then it breaks.

If it was possible, the 'IT function could be emulated like this:

IT: does [push pop]   ; pop the and repush the last stacked value 
(just to read it without modifying the stack).

Oh, and suffix-map is used by the codec system, afaik.

Sorry Bolek, I should have been more specific. I meant Steeve's POP 
proposal and the CONCAT example wouldn't work (for reason's stated 
above). Gabriele's IT proposal and Steeve's sample implementation 
of it would work a little, but would need modification.

and, how many of them do something like:   var: unless ...

I was reading http://www.chalicegames.com/swym/SwymWebIntro.html
and some concepts were interesting to me(especially ETC), so I made 
REBOL equivalents:

http://box.lebeda.ws/~rebolek/rebol/swyv.r


There's a documentation in the script, so just few examples of what 
it can do:

SERIE:


>> serie [etc 1 2 4 .. 20 cycle [1 2 3] length 5 iterate [x: x + 
10] from 10 5]

== [1 2 4 8 16 1 2 3 1 2 10 20 30 40 50]

COMPARE:

a: [1 2 3 4 5 6 7 8 9]
b: [2 4 6]
>> compare a b [some a > every b]

== true


>> compare a b [one a > every b] 

== false

FILTER:

>> filter serie [iterate [x: x + 1] 10 ] [[x > 2] [x < 5]]

== [3 4]

>> filter etc [3 6 9] 100 [x > 250]

== [252 255 258 261 264 267 270 273 276 279 282 285 288 291 294 297 
300]

>> filter serie [1 .. 10] [[x > 5][zero? x // 2]]
== [6 8 10]


It's written in R3 but should also work in R2 (not tested). It's 
not optimized so if you're interested in it, feel free to do whatever 
you want to improve it (more patterns that ETC can recognize...).

Rebolek: thanks for the link, lots of good food for thought here. 
That would be great to support it at native level (using a R3 extension). 
I also wonder how much of it could be implemented efficiently using 
'map-each and 'apply. Anyway, this could be a really great addition 
to R3 (or even R2). Keep up the good work.

Well it's interesting as a study dialect. But to be honest guys, 
i don't see the interest  to have them in Rebol.

Because we can do much of the use cases rebolek showed us  with one 
or two lines of rebol code.

And i don't need to say that it will got lightning speed by comparison

But anyway, It's lot of fun to do such things with Rebol.