AltME groups: search

is this a bug? (occurs in all core and view versions I have tried). 
 to-binary 23  returns the same as to-binary "23"  This is VERY non 
intuitive behaviour.

this started happening  .between 1225031 and 1226031 is the exact 
change

There was a discussion of this somewhere ......REBOL or REBOL2 worlds? 
And a solutiion found. I forget what it was.

The library version of Rebocalc has not been changed for several 
years:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/script-history.r?script-name=rebocalc.r
So the issue is a change in behaviour in REBOL/View

anton: the behavior I was expecting is as follows:

to-binary integer! value -> binary of smallest possible byte size.
Example:
n: between 0 and 255
to-binary n -> single byte binary #{XX}
n: between 256 and 65535
to-binary n -> 2 byte binary #{XXXX}
n: between 65536 and 16777215
to-binary n -> 3 byte binary #{XXXXXX}
etc.

to-binary treats its input as a string -- not a number -- and converts 
each byte to it's hex ASCII respresentation  -- not ar all an intuitive 
meaning for to-binary.
Even worse, perhaps is
>> enbase/base "23" 2
== "0011001000110011"

which appears to have converted to binary. But, again, it's the ASCII 
for "2" and "3" not the binary for 23.

and if you need it in the platform's endianess, then you can just 
use a struct!

I've tried the recent linux alpha on Fedora Core 2 (redhat) and it 
works great - seems to be a debian base issue - has anyone tried 
it on a sarge build?  I've tested an old woody build and a new woody 
build with the same hang result.

could you try an STRACE on both Debian and Fedora to see what's really 
different?

brk(0)                                  = 0x81d5000
brk(0x81f6000)                          = 0x81f6000
; and more writes

actually, ['return:] should be marked as a bug, because you are trying 
to create a "cross" between lit- and set-word

If you want something to be reduced and not others, you can use compose.

the rebol parser could be more relaxed (what it is not an integer, 
an url, a file and so on) must be a word!, but so you will never 
see an error! for invalid integer! invalid url! and so on, and the 
parser would be also more slow

View 1.2.57.3.1c  completed successfully three times in different 
sessions, and three times in the same session.
View 1.2.58.3.1e  completed successfully twice.

#3626 - path-thru - I'm using "_query_" instead of #"?" char in the 
path and "_atport_" to recognize different port of the url

this is a different version which use parse and is > 4X  on my system

rebol[
	Author: "Romano Paolo Tenca"
	Date: 10/02/2005
]
split-path-3: func [

 "Splits a file or URL pos. Returns a block containing path and target."
    target [file! url!]
	/local dir pos
][
	parse/all target [
		[#"/" | 1 2 #"." opt #"/"] end (dir: dirize target) |
		pos: any [thru #"/" [end | pos:]] (

   all [empty? dir: copy/part target at target index? pos dir: %./]
			all [find [%. %..] pos: to file! pos insert tail pos #"/"]
		)
	]
	reduce [dir pos]
]

I guess you can't, unless you know more. I just leapt at that idea 
because I thought it would reduce the amount of repetition in path 
and filenames.

No such problem on Win98   -- tried it with the live and latest betas.

I'm on Win/XP and got this with Core 2.5.6

>> print read %rebol.r
REBOL[
    Title:   "REBOL Extended Definitions"
]

feedback: func [
    "Send REBOL feedback."
][

    print "Go to http://www.rebol.com/feedback.htmlto send feedback."
]

Actually, this looks like a WindowsXP or NTFS problem, not a problem 
of rebol at all, because I can "Run D:\Anton\Dev\Rebol\View\rebol.r...." 
and my text editor (associated with .R files) pops up to edit rebol.r

When I tried the same with Rebol 2.5.8 which is just sitting on my 
desktop and got 

>> print read %rebol.r

** Access Error: Cannot open /C/Documents and Settings/Peter/Desktop/rebol.r
** Near: print read %rebol.r

And "what-dir" ???

I'll stop promoting IOS here, if that issue is not resolved! I would 
not hesitate to push my client to use some correction script, but 
it does not work always :-( ..... I need proved solution and full 
resync is not that ...

It's a wierd problem, and RT don't seem able to fix it/
reset-dates.r is a sort of symptom suppressant.


I've had to do full reysncs a couple of times.....Not a good thing 
to ask **everyone** to do.

About #3626  Quick PATH-THRU patch to handle CGI query strings

I am not sure anymore. :-/ I think the current implementation is 
the most "perfect" one, and it should be left up to developers to 
patch for particular cases.

Also, for the record, I have mainly reversed my position on "polarity" 
of alpha channel values. (ie. is 255 full transparency or solidity 
?) :-/

I feel guilty, because I argued strongly for it. I mainly changed 
when I realised the mathematical simplicity of it, and learning the 
standard.

and a few tests:

I'll write the refinement to REMOVE and submit it RAMBO if you like 
the idea...

DIR?  -  This function, useful as it is, is confusing, because it 
is not obvious that it goes to the filesystem or network to check. 
Perhaps it should be called EXISTS-DIR?

I also feel the lack of a function just to see if a file or url ends 
with a slash. If you work with the filesystem at all you quickly 
find yourself checking for final slashes all the time. Here is my 
latest way of detecting that:
#"/" = pick tail file -1

That sure is ugly to put into code all the time, and I keep wishing 
this is what DIR? would do.

I understand that there is probably a huge body of code that would 
be adversely affected by this renaming, so I am looking for a nice 
short name. So far I thought of DIR-SPEC?  (ie. "does this file have 
the specification of a dir ?") but....

Anton, that are the results of standard split-path that i replicated.The 
only difference is in %"" which gives an error on split-path and 
that result on split-path-3. I have some problems on how path are 
splitted by split-path in some cases, but to change them is a problematic 
thing, because all handlers knows how split-path works and get their 
decisions on it. I am not sure that the better result is [%./ none] 
in the %"" example, because the starting path (%"") is a file of 
name "" like in the %"a" example, where the starting path is a file 
of name "a". In the other 2 examples (%/ %.) the starting path is 
a DIR not a file (and the file is "exactly" none).

Someone posted this to the ML...

I can Encap: [ title 
program 1.0" ]
I gives an error of memory management. is this a bug ?"


I know I ran into this as well but I don't remember what the work 
around is and I can't seem to find it.  This bug doesn't appear to 
be in RAMBO...

The url in the "Include" line is wrong : there is "anton" and upper, 
there is "antonR"

And I have modified it and put back in the library.

DideC, I moved site. You must update. Do this, then try again:

load-thru/update http://www.reboltech.com/index.r[folder "Anton"]

(and sorry about that - one day soon, all this will not be necessary)

About incompatibility between versions of Rebol;  I think Rebol could 
benefit, as I have gleaned from other projects out there, from a 
strict cycle of 1/ feature additions,  2/ bug fixes,  and maybe 3/ 
a final category for "difficult" additions or changes (causing incompatibility 
with prior versions).

more precision, and they remember the decimal point. and throw away 
the littlest digits.

Sorry Romano, I meant it to be negative. -2147483648 becomes a decimal! 
too. This is a problem for code that deals with flags etc. I have 
some code for FMOD and one of the flags uses the highest bit, but 
it gets loaded to a decimal! :-/  I do not wish to make a special 
test for that case. I wonder if this behaviour is really necessary, 
so I would like to make a wish report.

Anton you can use bitsets and to-binary bitset! to handle flags it 
should make your life easier.

Gabriele: mmm, it is not stated quite the same. Romano's bug report 
#3646 asks for an overflow error (and I agree), but I want that when 
-2147483648 is loaded it should remain an integer!  (It looks that 
Romano agrees with me.) Could that be added to the report ?

hmm, yes, and there's #3520 which is about the same issue but not 
exactly worded as you wish. well, let's just make a new ticket and 
reference #3646 and #3520 in it.

My bug about -2147483648 is more old, is 3099 and is set as "Done" 
also if it is not done or it is done in the wrong way.

Yes, I think #3099 was misunderstood, and this is the report that 
agrees most with me. It should be changed from "Done" to "Issue"/"Bug".

couple of obvious and annoying ones in makedoc2.r. ahh... seems like 
I can

You should usually search the rambo database to see if it hasn't 
been submitted already, and also check here before submitting, unless 
you are really pressed for time.

And the first ?

Not see it under REBOL.
But is sounds like you have an older (or newer!) copy of MFC42.

Or you may have both in different folders, and the wrong one is first 
in the path.

Either way, the first step usually is to get the appropriate version 
to execute.

And when will SDK be final?

Carl sounds like 1.3 is new base for everything. so i hope IOS and 
SDK will follow quickly.

I *think* that the goal is to upgarde View, Core and also the SDK.

Once that is done work will start on the new async core and Rebservices.

Should most probably be more a question to RT directly, but I'd like 
to know the same. Actually if in the future everything is to be based 
on LNS, Rebol/Platform and so on, will people with the SDK, Command 
have to buy new versions, as it sounded that everything will change 
more or less, so the productline isn't the same anymore ?!

PhilB, I asked the question a year and a half ago and the answer 
was positive. I bought SDK a month and a half ago and I hope they 
will keep their word...

/Pro and /Command too. Base and Pro are part of the SDK.

I wish. Betas of it have been freely distributed, but there is not 
yet any place that you can download a release version of Pro, Base 
or Face seperate from the SDK. It was suggested to Carl that Base 
be ported to more platforms (particularly WinCE) and he seemed to 
think it was a good idea.

I'm sure we'll see when the SDK is released, and I hope that Base 
is released seperately, and for every platform that has Core since 
it is basically a subset of that. It would help immensely on WinCE, 
and there must be other platforms that have memory requirements almost 
as low, such as embedded Linux.

I still don't own one and I'm not sure if upgrading will be free?

The SDK license is a pretty kewl one last time I looked at it.  You 
get the version that is currently available and free upgrades for 
12 months...

Hence the joke, and why it is bad :)

I have a problem, if I in a DOS-prompt under windows try to run a 
REBOL program built with REBOL/SDK into a .exe file, and the program 
is not in current directory, but has to be found along the PATH. 
I get the error
Program error: invalid encapsulated data


I've tried under Windows2000 and WinXP. Can others confirm this error? 
(Just make a simple REBOL-script with e.g. a print and try it.)

The problem (bug) can also be verified with altme.exe. Just setup 
path in the DOS-prompt to where, altme is located, and type: altme

It works, if you place yourself in the same directory as the .exe 
file and don't give full path. It also works, if you place yourself 
anywhere and give full or relative path. As I see it, the error is 
only, if you're not in the same directory as the .exe file, and the 
system finds it along the PATH environment variable. Maybe I should 
report it in RAMBO!?

From the builds page: "A Beta test version of the SDK with the 1.3.1 
fixes and changes is now available for current SDK developers. Contact 
REBOL via feedback or email Cindy if you would like to try it."

and it says its for win32

A Beta test version of the SDK with the 1.3.1 fixes and changes is 
now available for current SDK developers. Contact REBOL via feedback 
or email Cindy if you would like to try it.

I have recently started testing with Rebol/View 1.3, and decided 
to

purchase Rebol/SDK.  I have a function in one of my scripts that 
was
working in View during testing, but as soon I start using the SDK
binaries it no longer... um... functions.


In the function, I am trying to set a value in an array using an 
index
variable.

In view, I could do:
   values/:index: value
But in the SDK, I get:
   ** Syntax Error: Invalid word -- :index:

Again, any help would be appreciated.

Thank you,
robert w. dumond

But the subdirectory is not mentioned by sunanda, and not linked 
public.

Base is a little smaller (~250K), but that's close enough. If you 
need GUI stuff, it will be around ~550K minimum (using rebface) or 
~650K using all of view and VID..

Good place to discuss a remote encapping service? The idea would 
be for RT to provide a service that would allow you to encap source 
code without the SDK. RT encaps your files and provides you with 
an executable that works for 5 minutes. If you pay a fee (5$?), you'll 
get no time limitation.


This could be for people who can't afford the SDK, want to use the 
encap facility to see what it's all about or simply only need to 
encap a single application.

and you got /Command for $5.

petr: exactly, licensing forbids it, and that why you can't have 
an automatic encap service where anyone can submit a script and you 
hand back an exe.

well, that's not really what I would want... all I would need would 
be proper encapping of my small Rebol/View scripts so that friends 
can run them with a single click, which is one of the major gripes 
I have when I need to distribute hobby scripts. They don't want to 
mess with the console or the viewtop (believe me, I tried).


If I were to use functions in my scripts that are /command only, 
the service should not allow encapping of source that contains /command 
functions. This way you'd need to own /command and/or the SDK to 
make /command capable exe's.

Henrik - there are two versions of SDK - /Command and "normal" (without 
command features, just pro ones available), which is cheaper ...

pekr, I thought the difference was /Command and /Pro functions...

...and I agree with you, that sometimes ppl don't want to install 
something ... the worst thing is, that in many cases, ppl are behind 
the firewall/proxy, and rebol fails here - blocking like mad....

if you're just distributing a script to friends, then what about 
just a zip file with view, the script, and a windows link that starts 
view with the script?

inability to freely encap ppl's work (and /Pro key is for nothing 
- you can develop features non pro users can't use ;-) is big obstacle 
imo. That is why I think plug-in might be important product - it 
is about deployment - with plug-in aproach ppl just think that things 
work in one click :-)

henrik, you don't get any R icon on the desktop the way i described. 
and, as petr says, there are programs around that make the process 
of unzipping and running automatic, so the user only sees one exe.

The #if and #either commands will put the results of their blocks 
into the output file. For example:
    version: #if [new-version] [2.3.4] [1.2.3]
will result in:
    version: 2.3.4

Now if you put your code dafely in a lot of [] and evaluate that?

not sure if I am not mistakenly inspired by some solution posted 
to ml few weeks ago? IIRC someone did self-extracting executable 
(archive), where there was rebol and scripts .... I just don't remember, 
if when you create such archive, you can instruct it to start some 
app ...

I don't think this would be a good idea as the SDK lets you choose 
what mezz code you wish to include, and things like console help 
and desktop are excluded by default.

Difficult, as trying to map:


 "I'll take base and not include any of the networking mezz source"

to:


 "Encap using latest rebview but exclude all the graphics and networking 
 code *I* know I'm not going to need"

doesn't sound too easy to me.

Most of the GUI work I do does not use VID or networking, so enface 
without any of the view-* or prot-* scripts is what I want. I do 
not want to use a loader front-end based on rebview that includes 
all this code. The cost in executable size may be small (less than 
100Kb), but it's the start-up time and memory cost that I like to 
get as lean as possible. This will become more of an issue if and 
when REBOL is ported to small memory footprint devices.

Petr: one thing is official SDK releases, which need to be stable 
and secure (Rebcode is not secure yet); another thing is beta/alpha 
releases for developers brave enough to play with features like Rebcode. 
I guess the latter can be done as often as View betas. we should 
probably talk to Carl about this.

OK, if that is doable, then yes, Gabriele. I just fear (judging according 
to my past experience), that SDK will lag. And it feels pretty arcane 
to "throw away" rebcode now in its current state ... just my feeling.

Well.. a new sdk has been finally released!  And that includes Command. 
 Thank you RT!!!!

That was in the last beta too and Gregg said no. And i am not sure 
about "with any REBOL Technologies products". Gregg said no, but 
IMHO if anyone can download, makes that sense?

; You are free to use, modify, and distribute this software with 
any

 ; REBOL Technologies products as long as the above header, copyright,

 ; and this comment remain intact. This software is provided "as is"

 ; and without warranties of any kind. In no event shall the owners 
 or

 ; contributors be liable for any damages of any kind, even if advised

 ; of the possibility of such damage. See license for more information.

license ??  can't find it.

If you have an up-to-date SDK license, you can download the new distribution 
from: www.rebol.net/builds/sdk If you do not have an SDK or command 
license, we encourage you to buy one and help support REBOL development.

Would like  more clear statements in the headers. With Greggs no 
i go with old-style-patching, and less than i would do otherwise.

Anyway, it's very good news to finally get a new sdk - and for command 
- before Xmas.

I will try if fast-cgi is fixed for Windows, and if not, then that 
is the exact reason why I want components ...

I would look for uniserv anyway, if i can run demons and need speed.

time to sleep, 0:41 here and I don't believe rebol has already fixed 
timezone problem, so actually who knows what is the correct time 
:-)

and windows now stay infront as supposed to.

And just for Pekr .. a button to disable auto-connect on start up!

and as for strange colors, Geomol, I thought I have modified my monitor 
settings, but I do remember bubbles in demo were of slightly different 
colors

pekr, I saw the rebcode test, and yes, the version in 1.3.2 is extremely 
fast compared to that one...

makes you think a bit. :-) still, I did a gauss blur convolve in 
plain rebol code vs. rebcode and the rebol version would have taken 
a full minute to process the image, so rebcode is much better than 
nothing :-)

yes, I noticed it, as I played with original rebcode versin a bit 
.... I thought for a little while - cool, they speed up rebcode, 
maybe kind of compiler inside? :-) and then I realised I am running 
official release, without rebcode inside :-)