AltME groups: search

your post in RAMBO? you can't. I'll have to change it for you, or 
we can dismiss the old ticket and create a new one.

HIDE minimizes window faces up to View 1.2.8.     Does nothing (that 
I can see) in View 1.2.10 and all subsequent versions.

Anton: I still don't see why that should be done for paths, and not 
for blocks.

because pathes are often used for filenames. dir/file.r . and this 
datatype-exceptions slip easily through attention. and then we think 
"hu?".

Volker, yes exactly. Gabriele, it's the path behaviour I feel the 
user really expects. After so long using rebol, I am not glad to 
find out this underlying relationship between blocks and paths affects 
the allowed path notation.

that could be solvable: convert the part to a string (or file). block 
then has a string. if you do to-path block, you get dir/"042", but 
that should be ok (with new pathes). its not more "buggy" than making 
42 from 042 IMHO. would be nice to get this, and pathes ending with 
"/" :)

i think that paths were and are not intended for file paths. that's 
what file! is about.

Their purpose is to simplify the referencing of values and since 
files are just values that are stored on disk then I'm sure it was 
intended to work that way. ;-)

IIRC in the bbs-project Carl prefered [data-file: dir/file] over 
[data-file: join dir file]. i prefer that too, but currently no "/", 
so [data-dir: dirize dir/file], ugly IMHO.. And now comes changing 
file-names when they are numbers. thats a bit risky to me.

Well, I'm sticking to my guns - I have some supporters, and the opposition 
is weak :) so I'm making a rambo ticket.

I guess I'm just pointing out the difference between THIRD and MOLD 
again.

and it should not crash either.

How safe is catch?
	

I have some rebol applications serving message communication (around 
1000 to 2000 messages per day mostly) running for more than half 
a year on Windows2000 Server without interruption since the last 
update of the OS for security reasons.

Recently I had to add some message splitting:
one-message -->  [message-part-1 message-part-2 message-part-3]

I used a construct similar to this

forever [
	until [new-messages-available]
	foreach message new-messages [
		catch [
			if not important [throw]

   do-some-heavy-message-processing-and data-completion-using-odbc
			if some-tests [throw]
			message-parts: split-messages message
			until [
				catch [
					message: first message-parts
					do-more-conversions
					if other-tests [throw]
					deliver message
					emtpy? message-parts: next message-parts
				]
			]
		]
	]
]

Now I saw two crashes in one day.
I was somehow able to reproduce the crash 
Invalid data type during recycle
 

by playing again the history of one to two weeks. But the crash happened 
always processing another message.

As I had seen in the past instable behaviour with constructs like 
this
foreach ... [
	catch [
		..
		data: any [
			a
			b
			throw
		]
		..
		..
	]
]

I replaced the inner catch with statements like this
		if not other-tests [
			deliver message
		] 
and the crash went away.


Now I am curious if someone else encountered the same behaviour too?

playing again the history of one to two weeks

 means I process all messages of that period in the same order and 
 send them to a dummy receiver.

Of course, there is some non reproducibility regarding the time axis, 
as this takes around three to four hours compared with two weeks 
in reality and more processes running at the same time on the production 
server.

On the production server the crash happened in reality with less 
messages two times during a period of  around two hours.


The crash happens not always at the same message. This can depend 
of the time behaviour or that the data, that are retrieved from the 
ODBC source is from a live DB, with many inserts, updates and deletes.

Without ODBC the crash did not happen.

And just do some minimal ODBC activity to see if that still triggers 
it.

So, in the creation of your object o2, 'b and 'c are found to have 
been previously bound to o and o1, respectively. Setting them does 
not modify the binding. 'd was found not to be bound to anything 
so it was set in the global context. (people use this last trick 
to "export" functions or values from a context).

Imagine context as a "colour" of a word (btw would be nice to see 
in an ide).

Then, in your example, the first context function changes the colour 
of all the a,b and o1 words to "red" say.

Then the next inside context function changes a,c, and o2 to green.

And finally the inmost context function doesn't get to change anything 
because there are no set-words to process - if there were they would 
have been made blue of course ;-)

By my analogy, the b, c, d of the inmost block would have the colours 
red, green and black - black being the global context.

Normally, all words start as black when they are loaded into REBOL.
Colourful analogy don't u think?

Yes, but you're using a set-word! which doesn't properly demonstrate 
what we are talking about.  Change [a: 'blue] to [set a 'blue] and 
then you have it. ;-)

and for demo my first example was right. trying again:

loading: all 'a in [red: context[a: 'red blue: context[a: 'blue]] 
] are colored global

creating outer context: all 'a in [a: 'red blue: context[a: 'blue]] 
are colored red
creating inner context: all 'a in [a: 'blue] are colored blue.
now all 'a have their right colors :)

Jaime, yes I agree that rebol implements context internally. You 
mention the idea of a lookup chain or initialisation chain, if you 
mean that such a chain maintains some relationship between your ancestor 
and descendent objects then no I don't think so.  Once the context 
function has finished being evaluated then the idea of ancestor and 
descendent is finished. The two objects stand equally at the same 
level, no relationship between them exists even internally, except 
that you might consider them to be associated because they share 
some function value or other values.


As Anton has said, words know their context. I tried to put it visually 
by saying they have a colour and that colour identifies their context.

I guess what I'm saying is that the idea of a lookup chain is not 
needed to understand rebol. We only need to know that a rebol word 
is a member of some context and that association between a word and 
its context can be changed by functions like Context, Bind, Func 
and Use when they are evaluated.

Ammon. On your point 3 above. "If the word exists in that context 
then it is set there, if not then it grabs that context's parent 
until it has made it to the global or top level."  No, it doesn't 
work this way. There does not need to be runtime searching.

It is more like this...

Look at my nested context example, and focus just on the 'name words.

(1) When the first context function is encounted during evaluation, 
it has a single argument a block - which happens to contain 5 values. 
A set-word, a string, a set-word a word and a block.

(2) Now when this first context function is evaluated it creates 
a new context, and binds to this context the all 'name words it can 
find in the block and nested blocks. To visualise this imagine all 
the 'name words including within the nested blocks have just changed 
Red.

(3) After this colouring of the words, the block is evaluated (as 
in DO) so that at some point the second reference to the Context 
function is evaluated.

(4) Like the first, it colours the name words in its block and nested 
blocks - let's say to green.
(5) The final level is blue of course.

(6) By the time all evaluation is finished the 'name words have the 
appropriate bindings (colours). Conceptually, maybe even actually, 
the innermost 'name word has had its binding (colour) changed three 
times, the second level one twice, and the highest once.


In this way there does not need to be any runtime searching for "parent" 
contexts, because the words themselves maintain the references to 
the appropriate contexts. The Set function does not need to search 
it can see the binding (colour) already.

Ammon: "1. It has to be happening during runtime there is no compiling."
load-time and loop-time then? ;)

ammon: "3. If you use a set-word in a context then that word becomes 
part of that context.  If you use SET then it reverts to the context's 
 "parent context" or the context in which the context itself is defined."

Thats the important point: there is no reverting :) and so there 
is no need to keep track of parent-contexts.which is quite clever 
:)

I am using core 2.6 under winXP .... and connecting to a Linux server 
is working OK.

Actually, I don't know what you have in mind exactly so I shouldn't 
comment. But I and a few others have systems of our own, so feel 
free to ask how they work.

Isn't what slim does ? Holding paths for code library (scripts) and 
allowing to just slim/load %script-name.r where the file is in one 
of the folder in slim path !!

Note the subtle difference between dehex and to-string

And, if using a beta with AS-STRING, it's kind of a raw cast that's 
fast.

what is the difference anyway between 'dehex and 'to-string  and 
'as-string ?

>> A: [%23%67%68%69]
== [%23ghi]
>> dehex A

** Script Error: dehex expected value argument of type: any-string
** Near: dehex A               ;dehex doesn't work with blocks
>> to-string A

== "23ghi"                ;to-string converted it to a string and 
de-hex only some of the characters.
>> A: {%23%67%68%69}
== "%23%67%68%69"
>> dehex A
== "#ghi"              ;dehex works on all parts of the string

No idea about as-string, dun have that beta.

http://www.rebol.com/core-info25.htmlmentions IMAP and APOP

There is a difference between the IMAP protocol itself (RFC 2060) 
and the imap:// URL scheme (RFC 2192). At this time REBOL only supports 
the imap:// URL scheme, which has a subset of the full IMAP protocol 
functionality. It handles mailbox lists, message lists, retrieving 
and deleting of messages, and message searches, i.e. it is API-compatible 
to pop://, with added support for multiple mailboxes and searches. 
Move/copy/rename and other administrative IMAP functions are not 
specified in RFC 2192 and not supported by REBOL's imap:// scheme 
at this time.

there's a bug in imap as released in the current stable and beta 
versions which Scott and I fixed.

is there reverse to dehex "Documents and settings", simply some 
function to provide it "Documents and settings" and having replaced 
spaces etc.?

I'm writing a greylisting implementation for my smtp server .. and 
I needed to drop the last digits of an ip address to form the triplet

;If you do why not use comparison under mask? 

>> same-subnet?: func [src dst mask][(src and mask) = (dst and mask)]
>> same-subnet? 10.10.10.0 10.10.10.5 255.255.255.0
== true
>> same-subnet? 10.10.10.0 10.10.9.5 255.255.255.0
== false

>> cidr-as-mask: func[prefix /local mask][
[        mask: make string! 34

[        repeat i 32 [insert tail mask either prefix >= i [1][0]] 
[        to-tuple load rejoin ["2#{" mask "}"]
[    ]  
>> 
>> same-subnet?: func [src dst mask [tuple! integer!]][
[        if integer! = type? mask [mask: cidr-as-mask mask]
[        (src and mask) = (dst and mask)
[    ]
>> same-subnet? 10.10.10.0 10.10.10.5 255.255.255.0
== true
>> same-subnet? 10.10.10.0 10.10.10.5 24           
== true
>> same-subnet? 10.10.10.0 10.10.9.5 255.255.255.0
== false
>> same-subnet? 10.10.10.0 10.10.9.5 24           
== false

I need to construct what is called a "triplet".  The triplet in greylisting 
parlance is a unique set of three facts about an email.
These are IP-address+smtp envelope from+smtp envelope to

The idea is that you construct a database of triplets from smtp clients. 
 If you have never seen such a triplet before, you send a smtp delay 
back to the client.  Most well constructed MTA's honor the delay 
and try again.  You set a block period .. from 10 seconds to 1 hour 
during which you do not accept any mail from that triplet.  Spamming 
engines generally ignore this delay, and just give up.  It's too 
expensive for them to log such delays and retry again.

Shouldn't parse and checksum be able to work directly on files? The 
only current option is to bring the files to memory either in chunks 
or completely, which can be very expensive in memory resources.

http://www.jwz.org/doc/mid.html
	

 In summary, one possible approach to generating a Message-ID would 
 be:

    * Append "<".


    * Get the current (wall-clock) time in the highest resolution to 
    which you have access 

    (most systems can give it to you in milliseconds, but seconds will 
    do);


    * Generate 64 bits of randomness from a good, well-seeded random 
    number generator;


    * Convert these two numbers to base 36 (0-9 and A-Z) and append the 
    first number, 

    a ".", the second number, and an "@". This makes the left hand side 
    of the message ID be only about 21 characters long.


    * Append the FQDN of the local host, or the host name in the user's 
    return address.

    * Append ">".

a 64 bit number has 64 digits in base 2, and 12-13 digits in base 
36

you could randomize the message itself and then checksum it, too

get some (long) text to randomize and then checksum

I changed function 'test-result to function 'test-result-summary 
and everything is golden again.

You can keep your current set up with the redefined 'test-result 
but you will need to run 'compose on the spec block being passed 
to 'test-case-test and enclose 'test-result in a paren

I think I'll avoid 'compose for now, and leave it for when I'm done 
with the basic stuff in the test book.

and besides that, it works here ...

I want to get in a Rebol script what I print on a standard windows 
printer.

I use Redmon (part of ghostview) to redirect what the printer get 
to my rebol script
RedMon : http://www.cs.wisc.edu/~ghost/redmon/index.htm
I'm under Windows.

How can I get data from the standard input ?

I have tried "copy system/standard/input" and also "input", but get 
nothing !!
plis help ;-)

Ah, this looks like a cgi-stype call. i would try --cgi then. it 
should do this "call and get data from stdin".

also you have both server and client in the same process? this 'partner? 
i write such things using two consoles, one for client, one for server.

i understand from the webpage that redmon launches the program and 
send it input, just as a webserver does with cgi. then try it from 
the real program, not from the console. i don't know about xp, but 
in win9x console-pipes are pretty broken.

...numbers (and probably tuples too)

It used to be just strings that were hashed. Other data types were 
just sitting there, and had to be found with a linear search like 
with other blocks.

Does one say what is the syntax to specify parity on a serial port 
?

I saw "parity: none" on docs, but what does it mean, even or odd 
? And so what is the other syntax (odd or even) "parity: ????"

I am not sure if rebol serial ports do work without that. I wanted 
simply my rebol tool to find our device on whatever port (autoscan) 
and it imo hangeg the app, even if I used open/direct/no-wait

WRT RegEx's -- I did a simple wildcard matcher (emulates VB's Like 
operator), and looked at hooking up PCRE, but it had a funky interface 
to it and I didn't get it working in the limited time I spent on 
it.

I am writing this file/directory replication tool, and I want to 
preserve the dates on the newly created directories

file! is an any-string and thus sourced. probe to-block %"1 + 2"

How about not using ftp and try Coyote :)

Hmm, and I was thinking of a refinement to 'reduce.  'Get makes more 
sense...

I'd just compare X and Y values separately...

Are you trying to compare area?  -- greater-pair?: func [p1 p2 /local 
ps][ps: reduce [p1 p2] pick ps (p1/x * p1/y) > (p2/x * p2/y)] -- 
which can be tweaked for when p1 and p2 are equal...

Yep, I'm resigned to that.  (and I'll word my queries a little better 
next time :^)

I also need to add extend Draw dialect with a new command: text-box. 
It's an improved version of 'text that allow you to define a bouding 
box, align the text horizontally and vertically and auto-wrap text.

For R3 you might look into the rich text support. I am less familiar 
with R2's Draw (and that's saying a lot).

DocKimbel, you'll find that R2 Draw has kerning problems. Or at least 
that's what it had the last time I looked. That makes it difficult 
to center and right align text. This is not an issue in R3.

I had a quick look at XPS API, but it looked more complicated and 
required more work than GDI API. There was also the compatibility 
issue, I needed a solution that would work with any printer. I'll 
gave a deeper look at XPS latter.

It might have had problems, but it would have been a much better 
starting point, had Microsoft embraced postscript from the start. 
There would have been a common starting point and a much larger incentive 
for building hardware postscript printers at the time. If that had 
been done, printer drivers would not be necessary under any platform 
today, or they would be limited to being postscript rasterizers.

Remember that the procedural model of Postscript meant that a Postscript 
printer was a computer, and definitely a more powerful and more expensive 
computer than most people could afford. Even faking Postscript support 
required a computer of at least the same scale.

Well, I still think postscript should have become more widespread 
than it ended up being. And you can't change my opinion on that. 
:-) I crave standardization. OK, so if postscript was too hardware 
hungry, then a lighter version could have helped, which is why I 
wonder why PDF came so late.

And I think it sucks that Microsoft choose to invent yet another 
printer driver mess, rather than converge with existing systems.

It wouldn't be the wrapping of the Windows API that would help Linux 
users, it would be his initial work on making a Draw-like printing 
dialect. Defining the dialect is a large part of the process of supporting 
printing in REBOL. There will be non-Windows-specific parts of Doc's 
implementation that can be adapted to a general printing model for 
REBOL, one that can have multiple implementations with different 
backends. For that matter, there would need to be at least 3 backends: 
GDI (for Windows), Postscript (for Ghostscript) and PDF (for Mac 
Quartz), with a possible XPS backend as a minor variation on the 
PDF one.

I'm very interested in this for both REBOL and Syllable

No docs for now, look at the sample %test-page.r script and at the 
scheme implementation. Input dialect is a subset of Draw dialect.

There's still some glitches and it needs some fine-tuning before 
providing real WYSIWYG results when compared to Draw rendering.

But Draw dialect is really too level for a daily use. A higher level 
dialect with relative positionning and higher level constructs (e.g. 
tables support), like VID or HTML is needed.

Btw, the printer dialect use milimeters as unit for positioning and 
size.

Thanks but this isn't really such a great piece of code (Windows 
API is doing the real job), even if it fills a gap in REBOL (at least 
for Windows). Btw, in my company, we're using Gab's pdf-maker for 
years now to generate and print all our documents. I made this library 
only because I needed a direct printing solution for a customer and 
I must admit it was a fun work to do.

I've looked at the cross-platform aspects of printing. I think that 
it could be possible to add support for PS and PDF generators for 
Unix and OSX printing support. So we could have the same dialect 
to draw on screen and on printers (on all majors platforms).

For information, I've successfully tested direct printing in Linux 
and OS X using PostScript format documents and CUPS as backend. I'm 
currently trying to implement a Draw dialect compiler targeting PS. 
Unix and OS X support wasn't needed for my project, but I couldn't 
resist to give it a try ;-).

Update on the work-in-progress : http://softinnov.org/tmp/test-page.zip


Both files are printed from the same Draw dialect source, using my 
printer:// scheme. The PDF file is printed through Bullzip PDF Virtual 
printer. The PS file is directly generated by the printer scheme 
(for UNIX/Cups direct printing).


Most of the PostScript support is done (see %test-page.ps), but there's 
still a lot of details to enhance/fix/add: 

o Add center/right alignement support

o Add underline style for fonts

o Fine-tune positionning and bold level.

o Fix minor differences with the GDI version.

Scaling, auto-fit are also currently missing in the PS version. Landscape 
mode is also missing in both GDI and PS modes.

I found a justification routine (doing also alignement). I need to 
study it to see if it fit my needs : align and line-wrap at the same 
time.

That shouldn't be hard to code in PS. Anyway, now I just need to 
code it in Draw, and let the printer:// scheme do the work.

I hoped to have time Doc, but I don't have a need, and I seem to 
have *no* spare time for playing right now. :-(

and not use pair! for specifying X Y scaling values but decimal! 
values.

you use commands like 'start-page/end-page to control paging and 
'insert port [...draw dialect...] to draw content.

So, how are you doing it ? multiple pages and text flow?

What I am doing now is printing the text to a virtual draw page, 
and then when it reaches the bottom of the text box, it then flows 
to the next text box.

if the next text box is above the current text box, it assumes a 
page break and so starts a new page.

and if I run out of text boxes, it just keeps reusing the last text 
box ... for all subsequent pages

yes, to make it easier to convert to postscript  and to draw.

but it handles rotations and translations poorly

gonzo is a postscript utility to do micro justification and other 
goodies

and apologies for the poor formatting ....

Thanks for the food for thought, I think that I could reuse several 
routines from gonzo. But PS is just a low-level layer for my printer 
dialect, doing too sophisticated things at PS level is not an option 
for me. All the calculation and fancy things (like good justification) 
have to be done in Draw dialect, so that WYSIWYG can be achieved.

I have multipage preview working ... some time ... I have a block 
of draw blocks and I am supposed to switch between them to page thru 
the different pages.

When printing, the user can often choose to have extra info printed 
with: who ordered the print, date and time, etc. What's the english 
name for this part of the print? The danish word for it translate 
to "receipt", but I feel, there's another english word.