AltME groups: search

Look at system/port/serial and change it to reflect what you have 
in /dev/
I guess with [ttyc0 ttyc1]
Almost it's what we have to do under Windows.

I just tried hex-editing rebol.exe in Rebol/View 1.3.2.3.1 here on 
windows. I found "com1" and changed it to "COM1". Then when I started 
again system/ports/serial == [COM1 com2]

I've discovered that the GC seems to accelerate as it processes more 
and more of the same data... A 10 million allocated, linked and initalised 
liquid node test is proving this once more, so my guess is that Carl 
put some kind of heuristic detection or what have not, which adapts 
the sizes of the values in the allocation and GC, based on recurring 
tasks.

and the memory foot print of my application stays the same at ~  
300 MB

it must support 100 million allocated and linked nodes for me to 
be happy.

it seems to me, you are building compositing engine, aren't you? 
And if so, yours will be redundant to View one ... will not it be 
slow? Or is liquid kind of being complementary addition to View engine?

pekr always seing behind smoke and glass  ;-)

It must use part of the View system in order to show something in 
a window (faces) and to get events.

That could cause wrinkles.  Hmmn, I searched the library and don't 
see the hex editors...trying to remember where they came from.  I 
think at least one was pretty decent.

eFish - wasn't it in terms of competition? Try ViewTop then, and 
rebol.com competition section ...

doing stress testing, of liquid and inderctly REBOL, I have measured 
that allocating 1million blocks takes up exactly 64MB of ram and 
each block I add to the context adds exactly 64MB.

seems like an empty block should only take 2 bytes...but then that 
is just the ASCII representation...binaries are bigger than their 
source code...I would expect some list links pointing, some datatype 
info...dunno.  Maybe try a small program like REBOL[] probe empty: 
[] and inspect the RAM of it.

would be a good extension of a hex-editor...to just load a memory 
address and peek around and look at things...have REBOL inspect itself.

.... and hackers hack in :-)

I don't have a Lauterbach debugger for x86 ... only for ARM, PPC, 
XSCALE, and some other MCUs...or that WOULD be cool.

for very structured data, when space is a premium, and if it is packed 
tight, you could always do it through a dynamic linked library.

yeah, I intend to recode code liquid as a c module eventually, and 
probably use that natively in python and make a dll for it in rebol.

and can still allocate 20000 nodes a second on my trusty 1.5GHz laptop.

and needs its own block to determine its dependencies.

each cell is a store of associations this cell has with other things 
in the db.  being bi-directional nodes, I can create sets or groups 
of nodes and nodes can backtrack them to query related informations.

the GC and reallocation may complicate things though. but that happens 
on appending too.

I guess it because the alloc engine uses pools, and pre-allocates 
data larger than the empty block?

If you really need to insert at the beginning, you can either use 
list! or think of your block in reverse and consider appends to by 
inserts at the beginning - that is the way stacks are typically implemented.

just for the record, I tried using lists, but in this stress test, 
they were quite memory intensive (compared to blocks) and eventually, 
the GC got slower at a rate quicker  than the speed improvement I 
did notice in the begining.  sooo as always, speed vs flexibility 
vs RAM still applies as always.

Well, the links in the list! type are overhead, and the chunks of 
memory taken up by list nodes are smaller than those taken up by 
blocks, leading to greater memory fragmentation. REBOL doesn't have 
a compacting collector.

I guess it at least impletment bottom and top allocation optimisation, 
based on chunk size?

What I was talking about earlier was the allocation quanta. Blocks 
are allocated with the assumption that you will want to insert stuff 
into them without having to reallocate them every time. So by that 
powers of two to multiples of 128, when you want a block length 10, 
you get 16. When you want 129, you get 256, and so on. On that note, 
when you want 1000000, you would get 1000064.

A list may be twice as big, but if you want memory predictability 
you can't beat it because the allocation quanta is 1 node and the 
insert/delete is O(1). Indexing and length calculations are O(n) 
though.

wouldn't it make sense for SKIP to support hex values? I'm trying 
to locate a specific position in a binary and it's tedious having 
to convert to number! every time.

I just think it's too obvious and useful to leave out

why not write a converter and then
  skip bin &h #c4d9

Is hex notation something we should propose for R3? I'd bet money 
Carl thought about it long and hard in the original design, and may 
even have left some lexical wiggle-room to add it later.

REBOL is very high level, and you tend to use hex notation more in 
low level scenarios, but it's *so* handy to have it there when you 
need it.

yess the kind of thing you need when you are doing projects and the 
specs are not your own.  on the other hand, HTTP 1.1 uses hex values 
for chunk sizes (stupid design if there is one)... so they are still 
used.

When I first started in REBOL, I also aliased it as &H (as a func 
name), since that's the hex notation prefix in BASIC and can be used 
as a func name, unlike "0x"

You bet. Outline the domain and we can cook up a killer dialect.

it predates the block-parser, and that shows.

and that means actually calling the VID parser many many times...

but that's usually harder than the dialect itself, and there are 
no ways to ensure that this door, won't corrupt your dialect itself..

And that are often 3-liner, which are then 5-liner
parse/any files[
  file!(..) | url! (..)
]

Ugly. parse/any looks nicer. And its a bit slower? But does the job.

and its an extra definition in every short script (i never use %user.r 
for libs..)

Well, post it as a wish then. I haven't needed it, and I'm concerned 
that the dual meaning of ANY in the context of PARSE might be confusing, 
but Carl has the final say.

Most scripting languages (like Ruby) and even some programming languages 
(like Java) support the string-concatenation operator "+".

>> "a" + "b" 
== "ab"


I know that we can use the JOIN function, but a + operator for string 
would be nice too. Why doesn't REBOL do so?

:) (and reads well to).

Yes, I find all those interspersed concatenation operators tiresome 
and ugly.

to try to patch ubuntu REBOL/Core today for serial ports, I did:
reb-orig: read/binary %rebol
replace/case reb-orig "ttyC0" "ttyc0"
write/binary %rebol-patched reb-orig


...but when I try to run the patched binary it gives some crazy line 
errors.   I differenced the two executibles in REBOL and got some 
crazy differences more than just what I thought I was changing.

If anyone has hex-edit.r and could post to library...or link...it 
would be appreciated.  I didn't plan to have my computers down.  
It is IOS/Developer/Users/Ryan-Cole/Utilities ... IIRC

Hi Jerry, "I know that we can use the JOIN function, but a + operator 
for string would be nice too. Why doesn't REBOL do so?"


Do you think it would be nice because it's more readable, or because 
it's familiar to people coming from languages that have it?


I came to REBOL with a long BASIC history, and it didn't take me 
long before I didn't miss + for concatenation at all. + is really 
a math op; I like REBOL's consistency, and I like the way REBOL concat 
code reads.

ttyc0 is actually there, and ttyC0 is not (in the /dev directory) 
and I have tried root  and normal passwords.

I tried logged on as root and as normal user, both give the same 
error.

Linux uses ttySx and Cygwin uses comx.

and avoid dubplicating the storage code in every context, or write 
stub-functions that reference the storage stuff.

Is it possible to bind the storage functions dynamically to the context 
that should be saved and switch this binding in the app depending 
on which context should be stored?

A function! is a more complex value, which contains a spec and a 
body.

And it will keep it's link to the original function spec?

Ok, thanks a lot. That's stuff I'm really going nuts by. I think 
I will collect all kind of examples and publish them.

I actually think that your best bet here is to pass the context you 
will be saving to the saving function as a parameter, like your original 
example  storage/save-record context-to-save  or if you really want 
to delegate you can assign the function as a member of context-to-save 
and call it like  context-to-save/save-record context-to-save , but 
then you are changing the context you are saving wih saving overhead. 
REBOL does direct delegation by default, rather than mixin delegation 
like Delphi, because REBOL doesn't pass the object reference as a 
hidden parameter like object-oriented languages do. Rebinding your 
function body every time would be time-consuming and either non-recursion-safe 
(bind) or consume a lot of memory (bind/copy) - just passing the 
context as a parameter would be quicker.

Also, you could have some conflict with names in both the storage 
context and context-to-save that could cause the block you are rebinding 
to accidently lose its meaning in unexpected ways.

I might fall back to the parameter solution. My goal is, that with 
BIND the code becomes much more natural to read and maintain. Because 
teh storage context needs some knowledge about the context to save, 
as I'm using a dynamic field-mapping method. Hence I only need to 
alter the context-to-save (add / remove words) and the storage context 
can handle it automatically. I have to deal with scheme evolution 
and versioning.

In that case, try the stub functions to hide the parameter passing. 
It will use less space, be more efficient and safer.

Logically though, you do have an object that is providing the storage 
infrastructure and is acting on other objects. The objects aren't 
storing themselves and their storage isn't their primary function. 
They are delegating that function to another object. So, other than 
the data that the storage engine needs, you don't really need to 
be distributing the code for storage throughout the data to be stored, 
unless these objects need per-object-specific serialization and versioning 
algorithms.


All the dynamic context manipulations cal be done by your storage 
engine working on the objects to be stored as data - they really 
are anyways.

So, back to setting the storage-context and than all functions work 
on this context.

that is, b: [] append b block   and b: copy block   are basically 
the same thing

insert copies words *and* their binding of course

No, and it caused me grief. But there is help at hand !  I patched 
make-dir to support FTP.

A URL path is _supposed_ to map to the file system path _if_ the 
scheme is ftp://
/
 has no assumed hierachical meaning in other URL schemes.
Hence the confusion at times.

I think REBOL is playing safe in not assuming the mapping. And, given 
how badly many FTP clients are written, that is probably for the 
best.

then you can query the smtp directly.
Try 

insert smtp "HELO Louis-here"
probe copy smtp
and you should see a response

>> smtp: open/lines tcp://bible-way.org:26
>> insert smtp "HELO Louis.com"
>> pick smtp 1

== {220-box61.bluehost.com ESMTP Exim 4.52 #1 Mon, 08 May 2006 22:02:46 
-0600 }
>> pick smtp 1

== {220-We do not authorize the use of this system to transport unsolicited, 
}
>> pick smtp 1
== "220 and/or bulk e-mail."
>> pick smtp 1

== {250 box61.bluehost.com Hello 203-79-92-225.cable.paradise.net.nz 
[203.79.92.225]}

What agravates me is that this script worked fine until we changed 
hosting service. Now this and other scripts are broken.

Well, I can't find anything wrong with the script, and trace/net 
gives no error messages.

Now I am getting:

Net-log: ["Opening" "tcp" "for" "esmtp"]
Net-log: [none "220"]

Net-log: {220-box61.bluehost.com ESMTP Exim 4.52 #1 Tue, 09 May 2006 
05:01:25 -0600 }

Net-log: {220-We do not authorize the use of this system to transport 
unsolicited, }
Net-log: "220 and/or bulk e-mail."
Net-log: [["HELO" system/network/host] "250"]

Net-log: {250 box61.bluehost.com Hello ip68-97-225-211.ok.ok.cox.net 
[68.97.225.211]}
Net-log: ["AUTH CRAM-MD5" "334"]
Net-log: ["WARNING! Using plain authentication."]

Net-log: [{AUTH PLAIN bGF0dXJrQGJpYmxlLXdheS5vcmcAbGF0dXJrQGJpYmxlLXdheS5vcmcAaXN0cmkx}
    "235"
]

Hmm.. I don't know the correct terminology, so I can't explain what 
I mean very well...

>> smtp: open/lines tcp://bible-way.org:26
>> insert smtp "HELO Louis-here"
>> probe copy smtp
** Access Error: Network timeout
** Near: probe copy smtp


SMTP ports stay open while data is transferred back and forth.  Copy 
doesn't return until the port is closed - so in the above line, copy 
is waiting until the server closes SMTP, and the server is waiting 
for a command from the client.


It's the reason why (as I understand it) Grahams "pick smtp 1" worked, 
but copy did not - SMTP was still open, even though there was data 
for the client to read.  (I was stuck on that myself for a long time 
 ;-)

Thanks, Tomc and Allen. And Allen, I didn't realize that. Thanks 
for the warning!

We need to yell at Dan, and get him to post the source to FTPGadget. 
 It has examples of just about everything for FTP.

I bitched at Cal and Dan.  I think there is nothing holding them 
up.  At one point it was that the code only ran on 1.2.5, so they 
should post this in the next few days.

graham, I looked at printf and it seems to require a DLL interface?

http://www.sunmanagers.org/pipermail/summaries/2002-December/002817.html
and there's an awk script on the same page

looking at send source, /show just clears the header to field, so 
it works when you send to multiple recipients and each one doesn't 
see who else received the email. When a message is sent to a single 
recipient the client shows the message is directed to you anyway. 
The trouble is this is not bcc

Sorry, the above to posts refer to the Core 2.3 docs. I have trouble 
with the "similar to bcc" If someone can provide some hints on how 
I should handle BCC then I will modify send source. To me this is 
a bug (i submitted to RAMBO) and I don't see what's the point of 
having BCC field in the standard header if this field is ignored

Hi Brock, this is how I fixed the bcc issue. I set up the right headers 
in o-h and then send the to message and afterwards the bcc message

the BCC header field is a field used by mail clients to let users 
type addresses that will *not* be included in the header. it is, 
basically, a user interface. back at the time mail clients did not 
have a gui, and just processed mail from a file or by letting you 
type them on the terminal

so what a mail client does, is reading the mail, collecting the addresses 
from to, cc, and bcc, removing the bcc lines, and then sending the 
message to the collected addresses.

what send does (and should do!) is sending the specified message 
to the specified list of addresses. send does *not* collect the addresses 
from the mail header.

this header is sent as-is, except for a couple things such as setting 
To if you haven't set it (this is so you can have a header template 
and send many messages with it easily)

what send does *not* do and *should not* do is remove or change other 
header lines. in particular it will not remove any bcc: lines. the 
reason is, that you should *not* pass them at all, because it makes 
no sense.

now, since this is a very common error among users, it may be useful 
to let send remove bcc. personally, i will vote against this, because 
i prefer educating users (documentation) rather than keeping them 
stupid and happy. ;) even in the case we do it, send is still *not* 
collecting the addresses from bcc anyway - so we're just wasting 
time removing something that someone wasted time adding.

so what you need to do now to send a message is - just send/header 
[list of addresses] msg header, with header being composed correctly 
- to should have what you want your recipients to see in to, from 
should have what you want your recipients to see in from, and so 
on; there should *not* be any bcc lines.

graham: that's a good idea and the desktop already has something 
like that, a gui that lets you type to subject and message. we could 
just add bcc and cc

IMHO that are to much internals. I would add bcc to send. First, 
if you use bcc, its almost 100% a privacy issue. So at least no bcc. 
Second, users read "email", they know email and email has bcc. What 
happens inside the mail-client they have no clue. So bcc should also 
be added to the header-list IMHO. At least as option, send/bcc or 
such. Should not be much parsing and things works a lot more right. 
As this discussion proves.

To pass recipients in the bcc too, parse that.
  send/header [x-:-y] text [bcc: "[a-:-b]"]
-> mail goes to [x-:-y] and [a-:-b]

and bcc is cleared.

doesn't make sense - it should parse to: too in that case, and the 
address list would just be discarded?

And yes, if i put 'to in the header in my client, i expect it works 
in send/header too.

we need refererence manuals like python has.  which explicitely state 
every limit and all intended useages of any and all words and refinements.

we keep guessing many things and not many of us use things like 'source 
to figure things out (when its even possible)

No, we need compatibility with common uses. Python maybe not, python 
has no "email!" AFAIK. But rebol has, creates an illusion and breaks 
it on the next possibility, leading to this bcc-thing.

send  is just the example of what the word does SOME things more 
than it should, but not all, and does not fully explain everything. 
 We are used to a lot of consistency in rebol. and if a word makes 
email shortcuts but not all of them... I understand the frustration 
which can come from a mistake, when you can't really know how -REBOL's- 
mail handling is performed... no matter what are the standards.

But, how about dropping 'send and switching to 'email completely 
in R3? 'send is a nice word for rebservices etc. IIRC Carl noted 
that somewhere.

Then in case of email 'send could be stupid without *any* headers, 
and 'email the dialected smart version.