AltME groups: search

Is there some function for switching two values in series? Ie. I 
have [1 2 3 4 5 6] and want to switch second and third element so 
result is [1 3 2 4 5 6].

I'm afraid this will not help very much if I want to switch second 
and fifth element.

SWAP is designed for just this situation, and has been backported 
to R2 as well. Here is the source if you have an old R2 version:
swap: func [
    "Swaps elements of a series. (Modifies)"
    series1 [series!]
    series2 [series!]
][
    unless any [empty? series1 empty? series2] [

        poke series1 1 also pick series2 1 poke series2 1 pick series1 1
    ]
    series1
]

As far as I can tell, the single type restriction is so the implementation 
of the action in the various datatypes can be simplified. I am interested 
to see how well SWAP works for gobs though. Can you test this and 
see if there are bugs?

Does it work between different gobs?

 - no, it doesn't work between two gobs and it doesn't work for one 
 gob (with sub gobs).

I just checked, and all of the functions called by MOVE are compatible 
with gobs. If they behave in a similar way then we can add gob support 
to MOVE.

Hm, I see that gob! now supports CHANGE and POKE, good news.

It looks like the code disconnects from the database and then tries 
to save to it without reconnecting. Beyond that I can't tell without 
knowing at which stage of the code the error is triggered.

There is nothing special there related to the function definition. 
The 'db and 'counter vars are global. It looks like the initial
    db: SQL "select * from customer" 
call is failing, and 'db is set to none. Test for that.

In that error there are only 3 path roots that could be none: db, 
db/:counter and FN. If the db is empty then db/:counter would be 
invalid even in the layout. That leaves FN.

If there are no rows returned then that makes sense. Looks like the 
database access needs some work. And even if the path succeeded, 
the SQL at the end of btn-save would fail because the database is 
disconnected. Plus, the create statement at the beginning just creates 
a database, not a table.

Quick sort is not optimal for cases where the comparison cost is 
expensive.
And with Rebol comparisons have high cost

Apparently the actual algo varies from compiler to compiler, but 
it is a mix of qsort, heapsort and insertion sort depending on which 
is fastest in particular circumstances.

But it is in the C++ standard library, so C code wouldn't be able 
to use it without copying and rewriting.

Yeah, we have options for the most common variants, and the default 
for the most common case. The /compare option is for everything else.

And not well enough documented either. I don't really know how /compare 
works, not completely.

I know, that it is documented somewhere, that the Comparator can 
yield either logic! value or a number, where a negative number means 
"<", zero means "=", and a positive number means ">"

I ran into the problem when I was sorting words in a block and the 
bindings mattered.

I still think that you need to write this stuff in a ticket comment. 
Writing it here will have no effect - the ticket is where the real 
discussion happens, and I don't seem to understand your argument 
well enough in this case to paraphrase you there.

BrianH <And not well enough documented either. I don't really know 
how /compare works, not completely.>

Comparators and the stable-sort trick (-1, 0 +1) are documented here 
in an old change log. It never made it into the dictionary for SORT:
    http://www.rebol.com/docs/changes-2-5.html#section-72

Are we talking R2's sort or R3's sort here? I know for a fact that 
R2's sort is stable. Obviously you can't get a stable sort if you 
use a comparator function and you return a logic! value.

We must focus on algos which are doing the fewer comarisons and are 
fast with data almost sorted (it's our common case).

in that sense, Timsort would be a good choice because it's unsing 
a combination of merge sort + insertion sort
merge sort = fewer comparisons.

insertion sort = the faster one on data already sorted and small 
subsets of data

Ladislav, I corrected the issue with :less-or-equal?
And made some optimizations (I hope so).
On large serie

Searching for an optimal (small and fast) implementation of the following 
pattern.
* Swap two subsets inside a serie.

input 
	block:  [4  5  6   1 2] (5 values)
	Starting index of the 2nd subset inside the block: 4

Output:
	[ 1 2    4  5  6] 

Easy to do in plain Rebol right ?

But here's the trouble, It must be memory safe. You're not allowed 
to do any memory allocation.

You're can only swap values inside the block. And the number of swaps 
should be optimal.
(no sort, no parse, no copy/make/insert/append/change)

Just for starters.....This does it with 12 XORs (three per swap).

But the tricky bit may be pre-computing the from-list and to-list 
mapping

;; function to do the swap

swap-items: func [
   data [block!]
   from-list [block!]
   to-list [block!]
   /local
    ind1
    ind2
 ][
 for n 1 length? from-list 1 [
     ind1: from-list/:n
     ind2: to-list/:n
 
     data/:ind1: xor data/:ind1 data/:ind2
     data/:ind2: xor data/:ind1 data/:ind2
     data/:ind1: xor data/:ind1 data/:ind2
     ]
     return data
    ]

;; Sample run    
     block: [4 5 6 1 2]
     probe swap-items block [1 2  1 1] [3 4 5 2]
    [1 2 4 5 6]

I've written some very clunky code that I'd be ashamed to post as 
a solution.

But I can offer you an algorithm that acheives the effect in N-1 
swaps at most where 
N is the sum of the lengths of the two sequences.
It's the more-or-less same algorithm used by Andreas.

Here's how it works. Given these two sequences:
       a b c    1 2 3 4 5 6 7

Step1: cyclically rotate the longer sequence M times, where M is 
the difference in length of the sequences. So in this case, we rotate 
3 (7 - 4) times:
       a b c    4 5 6 7    1 2 3


Step2: swap the elements of the shorter sequence with the tail of 
the longer one:
       1 2 3    4 5 6 7    a b c
And it's done.


The cycling in place is the tricky part. It can be done, but my code 
is just too ugly to share :(

Andreas's bubble-to-front is an elegant approach to doing the cycling, 
but is not optimed to reduce the number of steps.

It's a managable sub-problem that is a challenge to solve, so I am 
sure someone can do better than me :)

; helper function:
swap-first: func [
	{swap the first elements of A and B}
	a [series!]
	b [series!]
	/local t
][
	set/any 't first a
	change/only a first b
	change/only b get/any 't
]

swap-sub: func [
	{swap the subseries using the SWAP-FIRST function}
	a [series!]
	b [integer!]
	/local la lb pa pb
][
	pa: a
	la: b - 1
	pb: skip a la
	lb: (length? a) - la
	while [all [la > 0 lb > 0]][
		either la <= lb [
			swap-n pa pb la
			pa: pb
			pb: skip pa la
			lb: lb - la
		][
			swap-n skip pa la - lb pb lb
			la: la - lb
			pb: skip pa la
		]
	]
	a
]

swap-first: func [
	{swap the first elements of A and B}
	a [series!]
	b [series!]
	/local t
][
	k: k + 1
	set/any 't first a
	change/only a first b
	change/only b get/any 't
]

k: 0
swap-sub [1 2 3 4 5 6 7 8 9] 7
k ; == 6

If the two series lengths are L1 and L2, I get L1+L2-1 swaps -- at 
most. But there are exceptions, eg:
    [a b c d   1 2]

Needs only 4 swaps....An any [{L1 // L2) = 0 (L2 // L1) = 0] test 
triggers a shortcut.


However .....I also have some edge-case bugs in my code -- so you 
win!!

That looks good steeve -- short, neat code, looks optimal on the 
swap numbers.
And a completely different algorithm to mine.

Steeve, good fun. I came to a swap-sub using modulo as well, but 
it only worked for some series lengths, and I had to sleep before 
figuring out which lengths they were, but they surely included prime 
numbers.

(I used only a single loop). I thought maybe I could detect which 
series lengths could be processed using only a single loop, and other 
cases could be processed using another algorithm.

Ladislav, does not POKE DATA parameter already accept argument of 
any type ?  ( I checked only Rebol3 alpha 76 (not most recent) and 
Rebol2.7.7).

Steeve, 

What might be interesting (and possibly even ... useful) is to generalise 
to be able to swap (rotate) any number of sub-series, eg.
for three sub-series in a series [... AAA ... BBBB ... CC ...]
AAA moves to where BBBB is currently,
BBBB moves to where CC is currently, and finally
CC moves to where AAA is currently.

anyone did anything with Rebol and JVM (Java) integr/cooper-ation. 
I need functionality of some big java lib ("server side") in rebol. 
What would you do or use?

I was thinking of APPEND and CHANGE too - they both also allow any-type!.

In my opinion, there are certain simple and useful states, that we 
can choose from. One of the states might be, that #[unset!] is not 
a Rebol value at all. That approach was chosen for the #[end!] value 
as far as I can tell. Moreover, that approach was chosen even for 
#[unset!] for R1, but, for some reason, Carl declined from it, choosing 
a different approach.

So, instead of the R1 approach, Carl 'introduced' #[unset!] into:

*results of Rebol expressions
*values you can set Rebol words to using SET/ANY
*values you can "store" to and "retrieve" from Rebol series

, etc.

In my opinion, to 'allow' INSERT, APPEND and CHANGE handle #[unset!] 
makes 'disallowing' POKE to do the same uncomfortable.

This came up in a CC ticket for another series function once, and 
the reasons for the choice made there apply here as well. There are 
two main reasons that you would want series functions to be able 
to handle unset!:

- This gives the error context, so when it is triggered you can get 
an idea of what the conditions were that caused it.

- Your code might be structured to handle errors on output from the 
series instead of input to it.

Does R2/Forward contain fixes to TO-LOCAL-FILE? There are some rather 
significant differences in functionality between the R2 and R3 version.

As a rule, R2/Forward hasn't had any changes to native functions 
in R2, mostly for performance and compatibility reasons. It is intended 
to have an extended version later that attempts to backport as many 
native changes as possible, but that won't be the default because 
it would break a lot of the same R2 code that R3 breaks.

However, TO-LOCAL-FILE? and TO-REBOL-FILE? aren't really that fundamental, 
and were originally written in REBOL, so it might be OK to change 
them if it can be done without breaking code. What are the specific 
differences you have found between the R3 and R2 versions?

Oh, nice. Yes, that's worth doing, and fits within the rules. For 
that matter, it's worth adding to the R2 bug list.

I agree on POKE supporting unset! to match CHANGE and INSERT.

You can go through the steps with the data manually, and with different 
R2 versions. Anything unexpected will be a clue.

It shouldn't be to hard to use 2.7.8 in our setup and switch back 
and forth between both. We can take a look at it tomorrow.

I'm still stuck by binding thing sometimes !

Given the following code, how can I load the object and get back 
the correct binding ?

Try by replacing SAVE/ALL by SAVE and LOAD FILE by DO LOAD FILE.

Using SAVE ensures that you have a list of symbols in unevaluated 
form more suitable for object reconstruction and proper binding.

Anyway, binding information is lost during serialization (MOLD or 
MOLD/ALL), so if you want to get back bindings from serialized code, 
you need to manually ensure that the binding will be reconstructed 
as expected. That's achieved easily in your simple example using 
the SAVE / DO combination, but it can get much more complex in other 
cases and could require a lot of additional code.

do load

 does not work with the serialized form (I tried it)?" I'm not sure 
 to understand what you mean there. SAVE/ALL uses MOLD/ALL to serialize 
 values, so binding information is not preserved. If you want to restore 
 correct binding in a object! serialized using /ALL format, you need 
 to write some code to walk through object's functions body blocks 
 and bind object's words explicitely using BIND.

This would be similar to what MAKE does on an object's spec block! 
but a bit smarter as you need to dive into function! values (MAKE 
doesn't do that AFAICT). You need to see the distinction between 
"unevaluated code" (source form) and "evaluated code" (reduced form) 
to get a clear picture on this issue.

Nested bindings are faked using a procedural process in REBOL. Serialized 
syntax is declarative, and there isn't a reference to the bindings 
in that syntax. It would be possible to make a serialized syntax 
that includes binding references, and the proposal to do that is 
called Rebin.

If you want SORT to be stable, return -1, 0, 1 instead of just TRUE 
and FALSE.

This does a null sort in R2 and R3.....but it requires the func to 
know the name of the block being sorted:

    sort/compare block func [a b /local c] [c: [] if 0 = length? c [append 
    c block]  block: copy c 0]

Argh! Does one remember how to convert integer! to its binary equivalent 
and the opposite, in R2 and in R3 (it's different IIRC) ?

I need to make some binary mask with some integer value like :
	var: random 99999999
	res: var and #{00ff0000}

OK. Find a solution.

to-integer #{00ff0000} give me an integer, so I will make some "constant" 
values from the binary I need and will make the AND between integers.

Does anyone know why modifeid? and info? return a date without the 
time when accessing a file through ftp lon a windows ftp server? 
 Is this a limitation of windows, the ftp scheme, the ftp server, 
or the version of Rebol (I'm using the latest 2.7 - activated ODBC 
connection all dll access)?  Are there any known fixes to this - 
a quick google didn't find anything?

it should return the time, I've got ftp synching routines which use 
info? and use date/time.   so I'd bet its a limitation on the server, 
or its using a non-standard date string in its LIST command.

You might also try connecting with the FTP server with a command 
line client like NcFTP and looking at the listings directly.

Afaik, binaries don't keep the info about how they were laid out 
on the page like blocks do. The whitespace won't be preserved when 
they are printed out. And there is no whitespace internally in the 
binary, just binary data.

the best would be if I could store just 3A189256 and then reform 
ist back to a binary.
is this in general possible brian?

I could reverse the string and then parse it using a charset .. but 
that seems crude ( any reason why the parse direction can not be 
made an option ? )

Here's a working version:

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

I'm studying the RIP archive format and am wondering:


Why does LOAD allow binary "junk" at the end of a file, if it has 
a REBOL [] header, while it does not, when the header is omitted?

Yes, I am using xml-parse and then xml-object. My question is something 
that I have dealing with for a long time actually. So is there a 
limit to how far something is reduced in terms of nesting?

And how do you do that? do reduce blk

Sorry, about these delays. I was on on an online session.
So When I  use parse-xml+  on my xml string, I get the following:
[document [version none
        encoding none
        standalone none
        doctype none
        pubid none
        sysid none
        subset none

    ] [["TTL_Status" none ["^/^-" ["INPUT_TTLS" none ["^/^-^-" ["TTL_IN" 
    ["value" "0"] [{

^-^-^-} ["status" ["value" "1"] none] "^/^-^-"]] "^/^-^-" ["TTL_IN" 
["value" "1"] [{

^-^-^-} ["status" ["value" "1"] none] "^/^-^-"]] "^/^-"]] "^/^-" 
["OUTPUT_TTLS" none ["^/^-^-" ["TTL_OUT" ["value" "0"] [{

^-^-^-} ["status" ["value" "0"] none] "^/^-^-"]] "^/^-"]] "^/"]]]]

I know it's not that readable...

Then I run xml-to-object on that block and get:

o: xml-to-object  blk
where block is the output of parse-xml+ above.

probe o


[document: make object! [TTL_Status: make object! [INPUT_TTLS: make 
object! [TTL_IN: make block! reduce [

                    make object! [status: make object! [value?: "" value: "1"] value: 
                    "0"] make object! [status: make object! [value?: "" value
: "1"] value: "1"]

                ]] OUTPUT_TTLS: make object! [TTL_OUT: make object! [status: make 
                object! [value?: "" value: "0"] value: "0"]]] version: none
        encoding: none
        standalone: none
        doctype: none
        pubid: none
        sysid: none
        subset: none
    ]]


So this is where my ignorance leaves me. How do I make "o" into a 
an object where all the nested objects become real objects and don't 
remain as blocks?

I think this is a Graham question. I've been trying to communicate 
with this video encoder. It uses .xml and .cgi files to talk to it:
tmp: http-tools http://192.168.1.62/user/GetTTLStatus.xml[]
and this works fine.


The problem is with he .cgi files. They aren't POST files but they 
only return 

 a: http-tools http://192.168.1.62/user/StorageMediaFiles.cgi[] probe 
 a
make object! [
    HTTP-Response: "<?xml version='1.0' encoding='ISO-8859-1' ?>"
    Date: none
    Server: none
    Last-Modified: none
    Accept-Ranges: none
    Content-Encoding: none
    Content-Type: none
    Content-Length: none
    Location: none
    Expires: none
    Referer: none
    Connection: none
    Set-Cookie: none
]
When you place the url in a browser it works as expected. 
Any ideas on how to get this to work?

And you're right, there is probably something else going on. I am 
at least getting part of the message. A successful .xml call looks 
like this:

a: http-tools http://192.168.1.62/user/StorageEventMode.xml[] probe 
a
make object! [
    HTTP-Response: "HTTP/1.1 200 OK"
    Date: none
    Server: "Mango DSP - HTTP Server (v2.34)"
    Last-Modified: none
    Accept-Ranges: none
    Content-Encoding: none
    Content-Type: "text/xml"
    Content-Length: "270"
    Location: none
    Expires: none
    Referer: none
    Connection: none
    Set-Cookie: none
    Cache-Control: "no-store"
    content: {<?xml version="1.0" encoding="ISO-8859-1" ?>
<?xml-stylesheet type="text/xsl" href="StorageEventMode.xsl"?>
<StorageEventMode>
^-<RecOnNetworkFailure id="RecOnNetworkFailure" checked="true"/>
^-<PreEventBufferTime id="PreEventBufferTime" value="20"/>
</StorageEventMode>
}
]

Problem almost solved. The http-tools'  http-port-private buffer 
is not being read to the end so all along the data was there. Thanks 
Graham and Sunanda...I am learning a lot from you.

So what's happening is that the server is not returning an LF/CR 
to separate the contents from response fields so when it gets to 
 parse-header, that function does not know there is any contents. 
In stead of getthing something like:

HTTP-Response: HTTP/1.1 200 OK
Server: Mango DSP - HTTP Server (v2.34)
Content-Type: 
text/xml
Content-Length: 270
Cache-Control: no-store

<?xml version=
1.0" encoding="ISO-8859-1" ?>"

I am getting:

HTTP-Response: <?xml version='1.0' encoding='ISO-8859-1' ?>
<?xml-stylesheet type='text/xsl' href='StorageMediaFiles.xsl'?>
<StorageMediaFiles>
<MediaFile ..."


Placing a LF between the first and second lines fixes it. I am going 
to kludge it for now since I know what routines work and don't.

I mean this:


>> dt [loop 1000 [c: copy [] append/only c 'sine/radians append c 
0.5 do c]]  
== 0:00:00.002512


>> dt [loop 1000 [c: copy [] append/only c load "sine/radians" append 
c 0.5 do c]]
== 0:00:00.035299


In second case, to convert from string! to path!, string must be 
loaded first and as you can see it's about 14x slower in this rough 
test.

/only -- Appends any block value as a single value only (not the 
contents)


Is that good enough english to probably suggest it for R3 in curecode 
and R2 rambo?

And the claim is false because of the workaround with the direct 
function value references, which I came up with later. Only the words 
are rebound.

We actually need that option for both function! and closure! types, 
because of their different contexts. It is easier to add this as 
an option than as different types.

No, it would need two added function types, not just one. And names 
for those types, and names for the wrapper functions that create 
those types, and so on. An option is easier.

Yeah, and as I did not suggest new datatypes, I was wondering where 
that came from.

One of the goals of the native changes in R3 is to cut down on the 
need for arcane workarounds in regular REBOL code. For every arcane 
workaround that you might see in a mezzanine, you will see the same 
workaround need to be done over and over again in user code. Usually 
badly. There have been a host of native changes to make regular REBOL 
code easier to write and read and cleaner to look at. We even got 
more of these in the last 3 releases.

Btw, Ladislav, thanks again for the CLOSURE constructor. If you hadn't 
come up with that great a solution then R2 likely wouldn't have gotten 
closures at all, and none of the other fake datatypes would have 
made it in either, which would have been a real tragedy if we missed 
out on the typeset! stuff.

As an additional advantage, the meaning and expected behavior of 
'''return''' and '''exit''' from code blocks is clear with dynamic 
return, since dynamic return is defined in relation to the flow of 
calls to functions rather than in terms of lexical scoping.

That is highly debatable.

Especially if already using lexical scoping terminology, there's 
nothing that makes dynamic scoping instrinsically more clear than 
lexical scoping. And even when limiting this discussion to REBOL, 
where lexical scope is only faked, that does not make the concept 
in any way less "clear" than it's non-faked dynamically scoped counterpart.

It is clear *once you accept the idea of dynamic scope*, which is 
an inherent part of the semantics of all dynamic escape functions. 
And that limitation is listed as a disadvantage in the same model.

Just got done with the style makeover and rewording of some of the 
models based on the misunderstandings above.

I prefer the "Definitional return with an option to not redefine 
RETURN and EXIT, dynamic return as a fallback" model because it is 
the most useful. But I would be willing to accept the "Definitional 
return with an option to not redefine RETURN and EXIT, no dynamic 
return" model if it becomes the community consensus - it would mean 
fewer bug reports, at least from users unfamiliar with REBOL, particularly 
R2.

There are real learning and semantic advantages to just going with 
one return model. We just need to make the limitations of whatever 
model we choose easy for regular programmers to workaround if necessary, 
and pick the defaults well so the workarounds won't need to be specified 
as often. The last model satisfies all of those at the expense of 
losing the benefits of dynamic return, and the next to last doesn't 
even lose those, though it does lose some simplicity. Given that 
the remaining benefits of dynamic return can be restored by keeping 
THROW dynamic and fixing the THROW/name bugs, I'm willing to part 
with dynamic return and get back the simplicity.

Removed all superfluous "and exit" references from the doc.

And the misleading


Making definitional return optional means that this option would 
need to be specified in the code that calls the functions that would 
benefit from it, rather than necessarily in the functions themselves.

comment is still in there.

If you write a USE using the definitional return option it is transparent 
to both dynamic and (foreign) definitional returns. The caller of 
USE can therefore decide freely whether to use dynamic or definitional 
return in a code block passed to USE.

You need to move and reword that statement, not remove it. Most of 
it still applies, and all of it applies to the other variant of that 
model.

And of course, requiring cooperating from the caller makes the whole 
endeavour useless.

And in the other models, callers need care even less. Particularly 
the first one and the last two - pure definitional is not much better.

I am talking about models 3 and 4 if you number them from the top.

Right. So 1, 5 and 6 are the easiest to use, 2 is the simplest, 3 
is the most confusing, and 4 adds being useless to being confusing.

4 being useless and as confusing as 3 of course makes 4 the most 
confusing.

All of the ones that have two return models are confusing, but at 
least 5 has an option that is useful and consistent. But 6 would 
be preferred to 5 just because it's simpler.

3 would be less confusing if it didn't use the return: option to 
specify definitional return. The conflated option with return type 
is part of what makes it confusing, and the rest comes from bad option 
naming and having the interactions between the two semantic models 
be less clear. 4 is a little less confusing because RETURN is more 
consistent, but it is also less useful for the same reason.

4 adds nothing to the discussion (and at least one advantage is wrong, 
which is irrelevant as 4 is irrelevant itself).