AltME groups: search

My memory stick that I use did not have enough space for the resulting 
file! Encap, rather than complaining just wrote what it could. After 
making some space, it did its job. I did locate some words that were 
not yet defined so I did a "Search in files" to look for where they 
might be in the sdk/source files. Finding them I "#include"'d the 
source and wow, now it works. 


So Graham you were right. It was missing View. And Anton, next time 
I will check the path; that's a much quicker way to proceed.

It all makes sense now that I'm on the other side of success.

Hi Folks. I'd Like to customize the window title for my rebol encaped 
programs.. not with rebview, but rebcommand.. The program is a cgi 
.exe encapsulated. but the window title, when I run it out of the 
browser appears "Rebol -". Can I change that ?

have to use a windows library call.

is there any way to get an encapped application to send data to normal 
DOS stdout stderr (NOT IN REBOL CONSOLE)... I don't care how kludgy, 
even if it means compiling or using a dll with stdio.h included, 
just to access it...

I can load - parse - save a web page directly from the net in one 
line of rebol...

yet It seems impossible to even do a proper stdout call, so that 
another application can use my app's output ... (on windows).  I 
mean its just the most basic thing in any language.

thanks Volker, I have been trying to get to grips with the SDK.  
Somehow, I am lost when trying to find specific information... many 
times I try subjects, and I either encounter unfinished, incomplete 
or missing docs.   I do find some usefull tidbits here and there.... 
but its a pretty dry ride so far...

so far cgi in the header seems to work like a charm.  THANK YOU volker 
 :-)

I will test using it.  the page talks about a polling loop which 
consumes a lot of cpu... can this be improved (like inserting a wait 
0.01) ?

about fixing cpu busy look :-)  found a working solution.

; wherever you insert the asynch call  to system wait list... you 
also add 0.1 (or any other appropriate value for your app)
; this will obviously quit the event loop immediately.
append system/ports/wait-list clist
append system/ports/wait-list 0.1


then, where you normally call do-events OR at the end of your app, 
if not using do-events manually... you put the following:
forever [
	do-events 
]

and you have a 0% CPU consuming multiple asynch call loop.  I tried 
with the ping demo provided with async-call and it works perfectly 
on all the tests I did.

well, I did a little bit more testing and the above procedure does 
not seem to reduce rebol CPU usage while waiting for calls.  but 
I do have a method which allows you to trade off view interactivity 
for diminished cpu usage.  This obviously also slows down the async 
calls interactivity, but in most cases, this is not a real concern.

here is a new procedure (very effective)

append ports: system/ports/wait-list call-ports-list
append system/ports/wait-list 0.001
forever [
	system/ports/wait-list: []
	wait 0.1
	system/ports/wait-list: ports
	do-events
	if empty? system/view/screen-face/pane [quit]
]

of course i also have a kill-process function to kill the process. 
even on windows. :)

(i didn't believe it, but windows does not have any way to kill a 
process - you must create a new thread in that process with a call 
to ExitProcess... but this only on NT, older wins have no way to 
do this)

you have some work to do... but it should be a good start.

the detective does a lot of calls, and is fine. there are gc bugs 
in older rebols though. the latest sdk should be fine but i haven't 
tested it a lot yet.

doc, iirc the cpu problem you had was with using async-modes: 'write, 
which is a busy loop. am i right?

yep :-)  just a plain drop in replacement to your app.  and can be 
applied to any other app.

i'm just doing a poll every 0.5 secs or so.

but Gabriele might have a better (real) solution

Gab: it's not using 'async-modes at all, it's related to REBOL calling 
automatically 'get-sub-port when port/in/state/inbuffer points to 
a string! value.

handlers really need a network subport, although you can do a lot 
of things without.

The busy loop is generated by REBOL itself, it's a side effect i 
was using in async-call to do busy looping on the pipe while allowing 
other port events to be processed.

yep... that's why i made it a function instead of a port.

i'm using a different trick to implement timers :)

then timers to do polling on the pipes. on linux instead, you just 
get a signal when the command finishes, and read from the pipe - 
no polling needed.

but, if the os doesn't, then it can't. (that's why, as you say, you 
need to provide a current dir)

is there anything I can do to let XP supply a path when it resolves 
it using the PATH env?

it should get the dos prompt path, but if the program is not there, 
it will fail. i don't know the details, maybe there's just a bug 
in the code.

i have had issues because of this too, so i'll remember to talk about 
it to carl when we get to a r3 sdk :)

(so either argv[0] is a full path, or it must resolve relative to 
current dir)

in R3 the app should actually be compiled from a module stored in 
heap or something... linked on the fly and linked within a rebol.o 
as a string in heap.

i.e. basically storing a mini linker within the encap.exe and storing 
rebol.o and the supplied code as a source.o and linking them directly, 
so that the output would look like it was within rebol mezz code.

Can't the script be stored in a resource?

I do not know how resources are used or done, but afaict, encap does 
not really compile anything.  It just appends encrypted source code 
to the binary, which is read back directly like a file (probably 
using a preset skip value).

The resources are a data store in the exe or dll where they put stuff 
like the icons, version info, bitmaps and such. You can put arbitrary 
data in resources, including encrypted binary data like that which 
encap turns scripts into before appending onto the interpreter. It 
would be just as easy to put the script in a resource, and then the 
program could always find it without needing the full pathname to 
the program file.

The suggestion about DLLs in resources was more for the proposed 
plugin architecture. The approach used by BackOrifice would work 
quite well here. Just because some people used the program as a hacking 
tool, doesn't mean that it didn't do some things well.

but that would need RT to actually link module code to a loader... 
which they don't do AFAIK.  basically making encap a real linker. 
 I'd rather just have a rebol.o module and perform encapping myself 
using a linker from whatever language I use (even python ;-).  Obviously 
if RT supplied a simple to use encap-like mini compiler/linker. then 
I'd surely use it out of the box.. until iI encountered issue like 
all of those I am having  with current toolset.

right now, it seems as if  all encap does is: 


save %your-script.exe append  Load/binary enface.exe compress load/binary 
your-script.r 


preprocessing just really adds more lines to your-script.r itself.. 
it adds nothing to the binary side of things like the resources which 
you describe.


My guess is that the main() of the enface checks to see if its file 
size is larger than it should and in such a case does:

do to-string decompress skip load/binary argv[0]  base-encap-size


other wise handling the args, finding a script to load, and letting 
extra args flow through to the loaded script.


this way the same binary works for both encapped and core SDK  binaries.

I think we are talking about different OSes here - you are clearly 
talking about Linux and I am talking about Windows. Linux likely 
may have something similar to resources in their executables, and 
I think it has a way to determine the (or at least a) location of 
the running executable, so there should be a platform-specific solution 
there too.

but for that, the encapped app has to be linked by a real linker 
no?

Nope, just a resource editor, and those just call Windows APIs that 
Encap can call.

ok, so Encap would need a new main() which loads from the resources...

I mean, if its a one hour job from within... Carl and friends might 
say "bah, why not..."

Carl did promise a 1.3.3 release before R3

maybe that could get pushed in too.  it seems to me like a very easy 
fix...

Hey, they're doing all sorts of stuff for R3, this sounds like a 
good idea too

The resource APIs should make it easy, but you can also work against 
PE (Protable Executable) format files directly, editing resource 
tables and such. I wrote a resource compiler in VB a long time ago, 
and did quite a bit of research when writing a resource browser for 
PE files as well.

so, basically you should always do:


print " " to make sure you have a rebol console window up (or print 
to stdout if using cgi option in view or SDK) otherwise, call hangs 
indefinitely, occupying 100% of your cpu!

really? that is a very old bug, i had to do that in view 1.2.10, 
but i thought it was fixed in the newer sdk.

there is a similar post, I'll add my specificity and refer to the 
other within mine.

As far as I know the SDK is a version or two behind -- so no round 
(or maybe you have an out of date SDK)
Technically: all you need to do is copy
  source round
  source mod
from a later version of REBOL to your application
Licensing: is that permissable? You may need to ask RTmod: func [
    "Compute a nonnegative remainder of A divided by B."
    [catch]
    a [number! money! time!]
    b [number! money! time!] "Must be nonzero."
    /local r
][
    all [negative? r: a // b r: r + b]
    a: abs a
    either all [a + r = (a + b) positive? r + r - b] [r - b] [r]
]

Encap/Face 1.2.0 is a little old - current is 1.3.2, just like with 
View. This is part of the 2.6.2 SDK, available for download for a 
while now.

I also have 2.6.2, but I'm working on a script written several years 
ago, using 1.2.0.3.1, and it won't encap with 2.6.2.

Oldes, the script is a double-entry fund accounting package. The 
problem is 2.6.2 dies trying to encap it.

Sunanda, that is what I was afraid of.  Without such a list I doubt 
that I could convert.  I'll just have keep and use my old version 
of the SDKI for encapping this script.

It just lies down on its back, vomits out some meaningless error 
messages (perhaps confessing past sins), then quits breathing. Doesn't 
even blink an eye.  Then I click a button and it completely disappears, 
buried somewhere on my hard drive.  I dig it up and try to revive 
it, but it is hopeless....at least for now. :>) I'm trying to get 
over it, but it is hard.

Sunanda: well, porting the Detective (which is 700k of uncompressed 
rebol code) from view 1.2 to 1.3 required only removing a patch for 
a bug in 1.2. everything else works without any change.

Louis: it's hard to say without having the source. Using the new 
SDK with the old SDK sources will probably not work. I think your 
problem is probably a change in VID (the latter error you report 
is from LAYOUT parsing values), so you should probably check your 
layout blocks (and related code). Try to run them from View and see 
what could be wrong.

Is there a better way to do this:

comment {
    ;do %/c/sdk/source/view.r
    do %/c/sdk-2-6-2/source/view.r
    do %t-db-functions.r
    do %request-date.r
}

    #include %/c/sdk/source/view.r ;NOTE: THIS IS THE OLD SDK. WON'T 
    WORK WITH NEW SDK.
    #include %t-db-functions.r
    #include %request-date.r


So that I don't have to comment out  lines when I switch from interpreter 
to encap and back.

First question: Have you considered using the preprocessor yourself 
to generate a script to interpret? See %prebol.r and %prerebol.r 
in the SDK. Second question: Try the -s parameter to the interpreter, 
it will turn security off.

The common approach with INCLUDE is to have a "launcher" script  
that builds a complete script, as you would use PREREBOL; then you 
just DO that output script. Another way you can do it is to check 
a known word from the script with VALUE? and only DO the script if 
VALUE? returns false for a word you know is set in the script. That's 
also easy to put into a loop, with word and script pairs.

I can only view output if I execute my command with a pipe to more 
like so:

> test.exe | more

I think we've all hit this at one time or another. REBOL won't write 
to the Windows console. I was just trying a test to use the API to 
do it, and can't get that to work either, so it's still piping or 
nothing.

is there a better pipe output than more available? one which wont 
stop at every screen full?

Now I can either create a wrapper program that can do this and runs 
my rebol program in the background, or ask my users to use 'more

but the more serious limitation is not being able to ask a question 
on the command-line   ;-(

Yes, but in my particular case, that is not a problem

I thought the API approach would at least work, but I don't know 
if doing it inside a process that has already opened the console 
in a non-shared mode would cause the issues I saw or not. And I would 
think that CGI mode would work too.

Max: Perhaps you could come up with a nomore for clients. I came 
up with one in JScript (as it is pre-installed on all Windows 98 
& NT 5.0 onwards).

Usage:
test.exe. | cscript\\Nologo nomore.js

Script:
var si = WScript.StdIn;
var so = WScript.StdOut;
var line;
while (!si.AtEndOfStream)
  {so.WriteLine(line = si.ReadLine());}

Here's a quicker one that buffers all the output:
var si = WScript.StdIn;
var so = WScript.StdOut;
so.Write(si.ReadAll());

and could wrap my app in a little batch file... to make it invisible 
...

type doesn't seem to work for me  :-(  it expect a file name as an 
argument...

when not in view:  (on windows)  Graham posted this a while back:

win-lib: make object! [
	
	user-lib: load/library %user32.dll

	SetWindowText: make routine! [
		handle			[integer!]
		Title			[string!]
		return:			[integer!]
	] user-lib "SetWindowTextA"
	
	set 'WindowTitle func [
		Title [string!] 
	] [
		SetWindowText get-modes system/ports/system 'window Title
	]	
]

for view windows,  there is a title field in the encap part of the 
rebol header

rebol [
	encap: [title "NOT REBOL"]
]

are there ways to extract version information about an encapped binary 
from REBOL? I'm building a software update tool and want to read 
the version information about a specific binary.

I guess it would be possible to do a checksum and correlate that 
against a version list.

yes, the app and updates come from me and so I'll know which version 
it is if I just have a checksum on the executable.

what is a tint effect  ?

I try to insert  a tint effect in the image widget but it does works 
...

I setup a allways shown system for the splitter it slow down the 
perfs

I rewoked the update-table when a line is picked algorythm no better 
performance ...

without a a line picked I get 0.047 seconds with a line selected 
I get 0.157 seconds ...

I see now you can not collapse a column to zero width as before

showing a order symbol for the non adecate column is not a good thing 
...

So how to best handle data now? For example I want to handle a todo 
list, where I need to change position of the todos in the list. Does 
the widget works with copy of the data best, or can I link it directly 
with the data block that the other functions work with too?

Latest build available at: http://www.dobeash.com/files/RebGUI-022.zip

Highlights include:

	- Added drop-list, edit-list and auto-fill widgets
	- New splash function added (run %tour.r to see it in action)

 - Window management logic improved (disallows duplicate windows and 
 "sticks" child windows to first)
	- Couple of minor fixes and cosmetic improvements
	- %tour.r has an additional "List" tab

 - Prototype table widget added (run %table-002.r to see it in action)

Known issues

	- spinner and auto-fill widgets need more work
	- edit-feel needs to handle highlight, cut & paste
	- scroller needs more work (resizeable dragger)
	- table needs row selection logic added
	- edit-list needs auto-fill logic added

In progress

	- Improved tab-panel
	- Menu
	- tabbing
	- field input validation (field input masks, etc)
	- list-view (shadwolf)


With regards to "lists", I envision 5 types we need. They are (in 
ascending order of complexity):


 drop-list	- non-editable, single sorted column with single value 
 selection [optimized for < 100 values]

 edit-list	- derived from drop-list but editable with an auto-fill 
 field

 table		- multi-column representation of a DB table; used to create 
 something like a GUI SQL client with single-row selection [< 100,000 
 rows]

 list-view	- multi-column multi-media content (supports images, URL's, 
 etc); used to create something like a file explorer with single perhaps 
 multi-row selection [<10,000 rows]

 grid		- cell-level addressing and editing supporting simple spreadsheet 
 formulas and formatting [< 1,000 rows]

Every time the quality of RebGUI increase. Every new version is a 
must one.  Good job every one ;)

What about a single column text-list? IMO this one is needed too.

third, keep a user-reference in the row, where user can refer back 
to the real data.

Could you make the drop-list - with the auto-fill too? even if it's 
not editable.  Would make easier to find a value.

Could you make the drop-list - with the auto-fill too? even if it's 
not editable.  Would make easier to find a value.
 I think he is really talking about drop-list not edit-list ...

What hits my eye a bit though is LED design - too boxy/narrow in 
comparison to check-boxes, radio-buttons etc. The color is a bit 
obtrusive and maybe not all their area needs to be filled with particular 
color? But that is just very cosmetic detail ...

the event system does that - after a while, some megs, it should 
be garbage collected

A 'recycle was done by RebGUI in earlier versions (patched 'show 
function)

the problem of a recycle into show is tha it's performance consumer 
...

maybe we need to talk to carl about this point in order for him to 
make a more efficient way to garbage collect ...

and ofcourse conserving a good process speed :)

maybe it could be preferable to desalocate a content automatically 
when the content change ....

when you do a: 123 then a: "fdsbfsdjbh" it would be interresting 
to detect if the a word yet exist and then trash the interger (123) 
content of this word and then allocate to the word a the string! 
new content.. this will be an internal  totally transparent way to 
handle memory allocation /deallocation