AltME groups: search

How about a /native refinement to return files in 'request-file to 
return files in the native file format?

Why not just write a TO-LOCAL-FILES function to do that for all files 
in a block ?

it's a switch to control what is being returned by a function

I don't even have a feeling for assert

I guess it's to do with usage: though it functions like 'case, it 
is more like 'all with a step-by-step fallback.

chris: a trick i have seen:

anyway, assert seems a good name to me.

Gabriele, yes I've used this trick, but it's a little uncomfortable.

Hi, syntax question: 

i want to insert a row into a mysql db:

string-block: [ "value1" "value2"
insert db [  "insert into table values (?,?)" string-block ]


this fails (string-block is not evaluated i guess), but i dont know 
how to generate the following

insert db [  "insert into table values (?,?)" "value1" "value2" ]

(which works) using rejoin, remold, join, .. whatever.

and happy xmas to you! 


this works! how to factor out the "insert into .." string into a 
variable?

stmt: "insert into .."
insert db compose [ stmt (vals) ]

does not work, neither does 

insert db reduce [ stmt vals ]

which puzzles me ...

hm, but:

>> a

== ["abc" "def"]

>> compose [ "abc" (a) ]
== ["abc" "abc" "def"]

>> reduce [ "abc" a ]
== ["abc" ["abc" "def"]]


why is a block returned in reduce, but two strings (which i need) 
in compose. should be the same imho...

a common trick is to do this to unify a series as a block! which 
might also accept a string! :

val: compose [(val)]


this way, if val was originally a block, it stays that way, but if 
it was a string, its then inserted within one.  Note that the above 
actually creates a new block... so that the original val (if it was 
a block) and the new one are not the same

nope, its a special case for compose... and is one of its differentiating 
features.

also note that compose has a /deep refinement  which is very handy

ex:


a-big-view-block:  [ button "press me"  [print rejoin ["You have 
pressed " (val)]]]

val: "the button"

view layout compose/deep a-big-view-block

note that in the above, if you didn't compose the block it would 
still work, since val would be evaluated on the fly... BUT if you 
have several windows opened at the same time and each new window 
displayed a different caption, then the above is necessary... otherwise 
changing the value of val will change ALL windows at the same time 
 :-)   which is a common error we all make at some point.

yeah, i see the difference. but i think the behaviour is a bit weird

one last question:

a: [ "a" "b" ]
how to write/append %to.txt a
so that
a b <- with whitespace inbetween 
gets written?

write/append %to.txt form a

I want to speed up access to a block of objects (unassociated) for 
a search algorithm.
Should I use LIST! or HASH! ?

It's a growing list of visited objects, and I'm searching it each 
time to see if the currently visited object has already been visited.

perhaps the objects could just contain a  visited field

Search term is a word, but I want to support strings as well.

If lookup speed is primary, use hash!, if you're doing a lot of inserts 
and removes, use list! There is overhead to has items for lookup, 
but the speedup is enormous on lookups..

A quick test looks like using a hash didn't help in my case, the 
major work must be somewhere else.

Is it possible to turn off: ** Math Error: Math or number overflow 
?

My gcc compiler here warn me of integer overflow, but I can run the 
C program, and bits are lost. But that can be ok in some cases, for 
example to calculate noise. I'm wondering, if I can do that in a 
fast way with REBOL. Example:
46341 * 46341

will produce an integer overflow. I just want the result with the 
high order bits lost.

Good question. I would like to avoid this error as well. A overflow 
would be OK in most cases.

How do you do this when you have a lot of claculation that use user 
input?

Not sure -- and of course it probably doesn't meet Geomol's request 
for a "fast way"

LOL Wow! That's nice, Gabriele!

Also a fine solution, Sunanda! That might be one of the fastest way 
to do it. Maybe I'll just use RANDOM in my noise generating routine, 
but if that's not good enough, I'll probably use one of these suggestions.

Cool. This trick could be used to implement intervall arithmetic. 
Using a PAIR to store the upper/lower bound of ranges. Than we only 
need special operator implementations for * / to handle all cases.

Question: I have a block that represents several records (fixed size 
number of fields). Now I need to extend each record by one column. 
Inserting a new entry every X entries in the block. IIRC there is 
a special function to deal with fixed size blocks for such thing. 
Like remove-each but more generic.

the simplest way I come up is:
	FORSKIP series record-size [
		APPEND result COPY/PART series
		APPEND result new-value
	]


But this copies the series. Is there a nice inplace extension solution?

parse series[any[ record-size skip p: (p: insert  p new-value) :p 
]]
but that  shifts  a lot.
would use
 insert clear series  result

and for speed there is insert/part to avoid all the small temp blocks.

I have a DELIMIT function that will do it, changing the series in 
place, with the exception of the trailing element. So the final result 
would look like this:

	append delimit/skip series new-value record-size new-value

The basic idea you want is this:

	series: skip series size 
	series: head forskip series size + 1 [insert/only series value]


My DELIMIT func also works with list! and any-string! types correctly, 
which simple code above doesn't account for (the +1 part is simplified).

To move a file, one solution is:
write/binary <destination> read/binary <origin>
delete <origin>

If you leave out the delete, you've got a copying file routine.

If you just need to move a file within the same hard drive, there 
may be some tricks with renaming or calling external commands that 
will likely be faster. Be sure to check those out too.

Given some data which I might load from a file:

	data: [
	
		[code description]
	
		["CC" "Crazy Cuts"]
		["DD" "Dreadful Dingo"]
		
	]

I can process it this way:


 format: data/1 ; get the format block, which is known to be first
	
	use format [
	
		foreach blk next data [ ; skip over the format block
			
			set format blk
			
			if code = "CC" [print description]
		
		]
		
	]

with the disadvantage that I set a word ('FORMAT).
I could put that in another USE context but then I would have
yet another level of nesting in the code. (There is already
one level of nesting more than I want.)

What I would prefer to write is something like:

	USE-FOREACH (data/1) (blk) (next data) [
	
		if code = "CC" [print description]
		
	]
	
Therefore, an implementation is called for.
Any comments before I begin an implementation ?

Anton, you need a BIND there somewhere :)

Chris, sorry it's supposed to be unparenthesized, as a word, to have 
access to the original data.

Mmm... maybe USE-FOREACH better deserves your functionality, and 
USE-FORALL could be a function which steps through the DATA block, 
allowing access to it.

Ladislav, a reference to Brazilian ju-jitsu, which is wrestling.

It uses less words, is easier to understand, but it has a more brittle 
dependency chain via FORALL mezzanine which uses FORSKIP mezzanine 
which uses WHILE native.

Chris' version does not support WORDS argument as a word! - but I 
don't think it's that important to support.

i opt for chris version. its a loop, foreach is faster. but  add 
a version with more lines, for  explanation^^.

Anton, would it add too much to change the 'forall loop to a 'while 
loop?

It's a pity that it uses five more words, but the extra stability 
and simplicity of going direct to a native seems worth it.

(Also, I think adding FRESH-LOCALS is not a good move.)

has anybody used core async dns ? I am trying to resolve domains 
using a port per domain but I get a sequential behaviour. Ideally, 
this should be done with a single port, sending requests and getting 
replies in an async fashion. snippet below

i never used it this way, so i can't say if it can be made to work. 
but by thinking about how this is implemented on unix (a second process 
that calls gethostbyname), i'd guess that it can only do one host 
resolution at a time.

only now I noticed, that:

    even? 0.1 ; == true


my understanding differs slightly, I would more likely expect a test 
like:

    zero? 0.1 // 2

any opinions?

iirc there was a blog post mentioning that it would get added in 
1.3.x . I hope so !  Async networking is a must for decent performance 
apps !

petr, it's not a cheap trick. r3 is going to be better than the async 
core.

Gabriele - I hope so - otoh - what is the expense of threads? I looked 
into my friends code programming server in Delphi - they used exactly 
that - simply new thread for each connection. I would like to know 
what is the overhead - speed, memory etc. I called it "a cheap trick", 
as my friend could not even imagine, how he would do a multiplexed 
scenario ...

let's get on the first reason: why did I say that threading is worse? 
for the reason holger explained a lot of time ago on the mailing 
list. shared memory.

that is, handling concurrency in a threaded app is hard, so they 
just fool you into thinking that threading is easier.

that is, the user does not have to handle concurrency. you just talk 
with other "threads" (tasks would probably be a better term) with 
ports

what you describe above, can be easily obtained by doing the dns 
resolution in one task. what you see is a port, that to you looks 
exactly like an async dns port. except that it is implemented in 
mezz code rather than being native.

Gabriele - we have async dns already, don't we? dns:/// .... but 
what is currently blocking without ability to set timeout is trying 
to establish a connection (SYN) ... or can we make it also a non-blocking?

If there is a way of how to do fully non-blocking communication, 
as for me, I don't need async ... if I need "async" behavior, I might 
use rebol tasks ....

eg. when you make a connection with async:// or atcp:// there is 
no wait involved

the point rather is, than normally, instead of delving into the complexity 
of an asynchronous event based interface, you just make a task and 
use read.

Chord - problem number one, udp:// has bugs that make it inusable 
in async manner. problem number two, it just stopped working after 
a couple minutes, and figuring out why was incredibly difficult. 
(maybe it'd work on 1.3... but i haven't had time to try it)

as for R3 - networking layer is the one ported from 2.x, just plugged 
into tasking/threading model, or is it new implementation? (IIRC 
Carl said port model is going to be a bit reimplemented?)

i would guess it is a new implementation. there are two reasons it 
must be: the os code has to be separate, and the internal model is 
probably very different.

well, udp works, as long as you don't try to use it in a 100% async 
manner.

Joe - yes, that is how I understand it ... now how is rebol trying 
to establish a connection non-blocking? Can I set kind of timeout? 
hmm, maybe I will have to look into async:// protocol ...

there is a great lack of information from RT !  The problem is core 
is still widely propietary and it is imposible to find out how things 
like async DNS work without RT publishing the info. I was interested 
in writing an async DNS using Gabriele's async as a reference but 
I now find that udp has bugs ! Another surprise to discourage me 
!

I don't think if it's too important, if you are making history application, 
you should be awared of such a issues. But error would be probably 
better than this.

it cant handle infinite ints too. Somewhere there  hastobe a  tradeoff^^

IEEE 754 defines formats for representing floating-point numbers 
(including negative zero and denormal numbers) and special values 
(infinities and NaNs) together with a set of floating-point operations 
that operate on these values. http://en.wikipedia.org/wiki/IEEE_floating-point_standard

Given that 1/1/0000 is a base is doesn't seem logical to me to able 
to subtract from it . I'd go with a script error or if that's not 
desirable return the base value ie 1/1/0000

Geomol: originally I felt this might be a viable POV, but I am against 
it, because it means, that some REBOL values are not LOADable/MOLDable 
making REBOL script preprocessing impossible

an integer really is a whole number... substracting 1 from the smallest 
value an integer can hold Must raise an error... in any weird twist. 
 otherwise we end up with scripts which have no meaning...  -100 
- 1 =  100  makes no sense to anyone except the cpu, cause its stupid... 
why should such kind of logic end up in a language which does all 
it can to stray from that kind of logic in the first place.

Thus I second Ladislav's POV... a minimum must  not be substractable... 
it makes no sense.  fix your script, detect the error, create your 
own interpretation of out of bounds values, but don't act as if nothing 
is wrong, when its obvious... the intent of the operation has no 
relation with the meaning of the result.

actually, I can imagine that a result of x - 1 may be a "useful" 
value, example:

    -2147483648x0 - 1x0 == 2147483647x0

, but I strongly object against obtaining an "illegal value"

maybe in C its ok, cause you (should) understand about CPU registers, 
binary calculus in finite space etc... but for a REBOL application.

an int is a number and substracting from a negative value should 
return a negative value, or error if the result is out of bounds. 
  I really think that is the POV of REBOL itself... its meant to 
make programming simple... not complicate thing by re-introducing 
things like overflow causing the carry bit to roll number around, 
like in C...

there is a section on datatypes, but they do not go in depth at the 
limits, the conversion, the "expected" behaviours, the overall line 
of conduct on "strange events"

this is where objectivity is at loss.  they are equal and not depending 
on what you consider equal, or rather if:
- the evaluated human concept is equal (a space)

- the rebol value can be converted to from two types symbiotically.

- they obey a specified set of guidelines like (if converted to string 
both are equal)

- they must be strictly equal (of same type, but not the actually 
same instance)
- the same (actually two references to the same value)

(but you know that... hehe ... you did a thesis on REBOL equality 
 ;-)

yes, Rebolek, that is a good suggestion solving the issue

Good points here! :-) I now see the problem. It might be best to 
return an error, when subtracting 1 from the lowest value of a date. 
Make sure, you think it through as much as you can, and then be consistent. 
If one datatype return an error in such a situation, another might 
as well.

On the subject of date! and values having meaning. I think that the 
zone refinement needs to be looked at again:

>> dt: 17-Jan-2007/9:52+25:00
== 17-Jan-2007/9:52+25:00

but 

 >> 17-jan-2007/9:55+5:45
** Syntax Error: Invalid date -- 17-jan-2007/9:55+5:45
** Near: (line 1) 17-jan-2007/9:55+5:45


To the best of my knowledge +25:00 is not a valid time zone offset 
but +5:45 is (Nepal).

zone has a resolution of 30 minutes. it is indeed a problem for a 
couple zones (like the one you pointed out).

Not handling the 45 minute zones (I don't think that there are any 
15 minute zones) isn't a big problem. Its the inconsistency that 
bugs me - GMT +25:00  is a less correct value than GMT +5:45.

yep, but rebol is not actually doing sanity checks on zones. the 
45 problem is only due to a limitation of the implemetation.

A day no Mars is 24.6 hours, so I think, we're ok with -16:00 to 
+15:45 timezone.

A day *on*

Although arguments for any 'uses based functions must be contained 
in a block, it does allow for optional arguments with preset values.

Hmm, lost a close bracket in a VNC post...

a part for a little bit of excentricity on your part... do the trailing 
^^ you add on most/all post mean something I have been missing?

A quickie example, but illustrates the flexibility and readability.

And a list of all the current (and a few old ones) at http://en.wikipedia.org/wiki/UTC%2B0

I have a question, I have this code:

>> b: "1234str" ri: func[b /local i][i: copy/part b 4 b: skip b 4 
i] probe ri b probe b
1234
1234str
Why the b string is not "str" ?

Here is the explanation:
>> a: "1234"
== "1234"
>> b: a
== "1234"
>> b: skip b 2
== "34"
>> a
== "1234"
>> b
== "34"
>>

as I said: you cannot change the index of a series, so the only possibility 
is to share the variable

actually the error lies in the fact, that many users think, that 
SKIP changes the index of a series. It actually doesn't:

b: "1234"
index? skip b 2 ; == 3
index? b ; == 1

but than it's quite useless... I wanted to do a function read-integer 
buffer and etc. and make it universal:( 

I know, I can set buffer as global variable (or in the context) and 
do just read-integer etc.

isn't it too many operations to just get a string?
read-str: func[b [word!] /local s nb][
	s: none
	nb: get b
	error? try [
		i: index? nb
		s: copy/part nb i: (index? find nb #{00}) - i
		set b skip nb (i + 1)
	]
	s
]

As a function:

>> b: "1234str"
== "1234str"
>> ri: func[b] [b: remove/part b 4]
>> probe ri b
str
== "str"
>> probe head b
str