AltME groups: search

Cyphre, my goal is to get Canvan RPaint for version 1.0 and work 
the same on Win, OSX and Linux. Then REBOL/View is in a condition, 
I'll call good! :-)

I started using 2.7.6.

It's great to be able to "call" external apps without the dos window 
popping up. I have alot of use for this. 

I noticed, however, that when calling wmplayer in windows the file 
will play in the background which I also find appealing but there 
are times I might want wmplayer to open. Is there a way to force 
this with call?

new refinement to 'call called /show maybe?

There does seem to be a problem with 'call that wasn't there before.

Lots of apps no longer open with call and need call/show or call/shell

regarding your example in R2-Beta - Bugs (Problems that need solving.)

This seems to be a windows behaviour. It works with the complete 
path;
 call "%windir%\explorer.exe C:\"

>> call {C:\Ghostgum\gsview\gsview32.exe}
== 0
>> call/show {C:\Ghostgum\gsview\gsview32.exe}
== 0

The first does not work, the second does.

does call /info refinement really work?  Shouldn't it return the 
PID number for the ID?

How exactly does call/shell differ from just call on windows?

My guess: it calls via the shell (cmd under e.g. WinXP) instead of 
a directly Windows call.

There seems to be a difference in CALL/SHELL (at least under Windows). 
Earlier versions open a shell window, the latest doesn't. I can see 
it, when I run my OpenGL stuff.

Has anyone ever seen the "Call" word not work? I've been trying to 
simply call %/c/rebol/view.exe and it shows up in task manager but 
I never see the application. It's not just that particular app either. 
The funny thing is I was successful doing that at my work computer.

try one of the options like call/show

Q: "Any idea why?" call/show

A: Most of the time call is used to run background processes, and 
REBOL <= 2.7.6 did not give you the option, always flashing that 
shell window. Starting with 2.7.7 the called app (and the shell window) 
is not shown by default.

See posts from the 21-Mar-2008 and we talk about call, call/show 
and call/shell

Sorry, my answer above about call was wrong. It was fixed in 2.7.6.

In prototype-based object languages, you handle code sharing with 
delegation. A "class" is a common object that many similar objects 
delegate to. Since delegation is explicit in REBOL, that means that 
object functions call other object functions or other functions explicitly. 
In the case you mention, you just assign a new function to the word 
in the shared object or global context.

call "C:\Program Files\Windows Media Player\wmplayer.exe"
This line does not work on Rebol2.76 ,but works well on Rebol3
Who can tell me why?

try call/show

call is broken in R2

it's a problem since 2.7.6 ... when 'call was fixed ...

wrt call on rebol 2.76... I've figured one way to solve some bugs... 
you use the /input/output refinements with bogus strings... the input 
string should be something like "^/^/^/^/^"  might not fix all problems, 
but it has for me on some occasions.

Gregg, That looks far more intricate than I need but I will definitly 
keep it in mind.

I used a simple method...

first i used system/version to see what version of rebol is running 
so I can see if its Windows , Mac or Linux.

2nd- If its Windows I use 'Call/output "ver" win_ver' to get the 
windows version. I parse out what I need from the output. I just 
need to know if its vista as it has some file structure differences 
that screw up my "install".

Thanks for hte help...

please remove the .3 seconds delay on call/wait

please, fix this 300ms delay !
  timer [call/wait "echo 1"]
1
;   0:00:00.301731
  timer [call/wait "echo 1"]
1
;   0:00:00.301543

W: I've posted the C source to Call a few times, but no one has ever 
offered any fixes.

:-) I do remember - over 1200 lines of code ... but at least "it 
works", and in R3 'call is almost unusable ...

300 ms is a lot of time in response time when using call/wait or 
call/output in a Cheyenne rsp. Please fix it!

timer [call/wait "print 1"]
1
;   0:00:00.301498

>> timer [call/wait "print 1"]
0:00:00.031

>> t1: now/precise call/wait "print 1" t2: now/precise print difference 
t2 t1
0:00:00.082

fedora>> timer [call/wait "echo 1"]
1
0:00:00.304267

2.7.7 release

Call
dockimbel:

About CALL console window issue, the CreateProcess( ) win32 call 
has flags to hide the window. There just need to be set.

In the STARTUPINFO used by CreateProcess( ), just set in dwFlags, 
the STARTF_USESHOWWINDOW flag and set wShowWindow to SW_HIDE.

maybe add a new refinement and let the users decide when they want 
to see the console window ?
or maybe just /show

Paul:
Run is not enabled

Graham

Is anyone concerned that shell windows opened in Encap do not contain 
the correct window title?
Rambo #3660 ( reported march 2005 )

Brian

For me, the big question is what kind of release we will be doing:

- 2.7.7: Patching glaring bugs in a few natives, VID fixes, and continuing 
the backports and mezzanine fixes.

- 2.8.0: Backporting some of the R3 native changes (function, not 
infrastructre), and the above.

I think that the decision a long time ago was to focus on R3 as a 
priority, and just patch up R2 as necessary.

At the very least, I would want a 2.7.7 to have a version that fixes 
post-2.7.6 mezzanine bugs, and 2.7 series regressions vs. 2.6.3.

Henrik
We also need to implement BrianH's new window resize scheme.

Ashley,Anton, Brian, etc ... VID fixes

Graham
Fixes to prot-http to support put etc.

BrianH

SQL_FLOAT and SQL_REAL are converted the same way, just with different 
sizes. And yet SQL_REAL works and SQL_FLOAT doesn't, at least with 
SQL Native Client (an ODBC 3.5 driver). Perhaps that difference can 
point you in the right direction.

Henrik
view/new make face []
a: open/binary/direct/no-wait tcp://:9000
forever [wait reduce [ a 0.001]]


This produces a 16 byte leak when started. And when I move the window 
and click in it, I get a lot of 64 byte leaks.

Will: in 2.7.7.4.2: 
>> timer [call/wait "echo 1"]
1
0:00:00.037984

Oh, it's like CALL "start"

I'm experimenting with image! as a command agrument and found this 
strange behaviour:
I have:
	img-echo: command [img [image!] ]
In RX_Call I use just:   return RXR_VALUE;

And then when I call the img-echo I get image, but with index at 
the tail so it looks like:
>> i: img-echo img
== make image! [50x20 #{
}]
>> index? i
== 1001

Is this normal? How I can set the index on the C side?

Oldes, AFAIK its normal... in C we always have access to the full 
string.  

we use RL_SERIES to figure out the portion of the string which is 
used by a specific Series reference.

so basically if you call:

a: [1 2 3]
b: next a


and use A or B in the command, you get the same string (logically, 
not physically), but with only the RL_SERIES and RXA_INDEX() which 
are set to different values.

Earlier in the session of the call to the interpreter. When the program 
starts it loads the extensions and modules it needs. If you need 
to load things from specific filenames, do that before you load the 
other code. The module system is designed to help you organize and 
manage the code in a program.

You can use different IMPORT blocks depending on the OS, in the same 
code. The highest-level script is usually a not a module, so you 
can call IMPORT directly. Then your modules can just do their requirements 
by (word) name instead of specifying filenames.

Kaj, you do realize that you won't be able to just load any system 
library, right? Unless that library has an R3 extension API, it can't 
be loaded as an extension. And if you can only load R3 extensions 
anyways, why not name them as R3 extensions? The .so filename suffix 
isn't even portable to all POSIX platforms. If you want your code 
to be portable and load filenames, use a portable filename. That 
is why we have the .rx convention. And we have %rebol.r for anything 
specific to your personal platform - you don't even have to touch 
host code. For that matter, CGI scripts could call a R3 interpreter 
that is in a different directory than the user R3 interpreter so 
they would use different %rebol.r settings.

You'd have to eventually call the OS loader again to unload ir

You can distinguish R3 modules from scripts with LOAD/header or some 
such. But you can call R3 scripts anything you like. Scripts are 
just a kind of module in R3 anyways (one of 3 or 5, depending on 
how you count it).

If you want to call your modules .rm or .r3m or whatever, go for 
it. We don't have a standard suffix for scripts, but feel free to 
make one. Actually, the default suffix for R3 module files is .reb 
:)

I think that there are ways to call .NET APIs from C/C++ using COM 
interop and other methods. MSDN should have the details.

It would be useful to have a general .NET wrapper extension that 
uses Reflection, ActiveX or something to call arbitrary .NET code.

The command call process does a lot of marshalling to get the values 
into the native code. You only have limited access to the original 
values in REBOL memory.

Has anyone done some code using the RL_words_of_object, RL_Get_Field, 
RL_Set_Field for extensions? I would like to take a look at the code 
how to best use this stuff.


And, is it faster to seperate words & values on the C-side or to 
call an extension function just with two blocks: words, values?

// call R3 callback
	RXA_COUNT(cbi) 		= 1;

/*
	RXA_TYPE(cbi, 1) 	= RXT_INTEGER;
	RXA_INT64(cbi, 1) = 123;
*/

	RXA_TYPE(cbi, 1) = RXT_STRING;
	RXA_SERIES(cbi,1) = RL_Make_String(message);;
	RXA_INDEX(cbi,1) = 0;

	int cb_error = RL_CALLBACK(cbi);

I don't expect multiple threads call the function. But will cross-check. 
I could lock the string in the GC. Keeping the last reference from 
the C side.

Is there a simple way to call a function in the context of an other 
thread from the same process?

Well, to get this code started I need to call it from R3, but than 
I can't return to R3 otherwise I get a new thread dealing with it. 
So this is not possible.

i assume you currently have roughly the following flow:
- R3 calls into extension (via RX_Call)

- extension calls into library, passing an extension-internal "activity" 
handler along
- the library calls the extension's activity handler
- the extension activity handler initiates a callback into R3

- R3 call init-lib

- init-lib installs a listener, setups a C-level callback handler 
(CBH) and returns
- the listener is sometimes triggered, calls the CBH (new thread)

- CBH prepares Rebol callback, calls Rebol callback (and here it 
crashes with string!, not with integer!), continues and ends

To complete the sequence from above:

- Rebol exectues the rebol side callback function, which make a synchronous 
call to the lib, getting all buffered messages and continues to process 
them

Btw, here's my variation of a header generator script:
https://github.com/earl/r3-zmq/blob/master/make-ext-header.r3


It has the nice advantage that it automatically generates a dispatch 
table for your commands, enabling a clean and concise RX_Call like:
https://github.com/earl/r3-zmq/blob/master/zmqext.c#L31-35

Cyphre tried to call him, but no response.

Really? E.g. think about buttons. I think that all buttons will share 
those values, no? But anyway - this is just speculation on my part, 
and call for "premature optimisations". In fact I don't know how 
to measure memory consumption (even if we have stats function) of 
an object, which has two more fields (slots) plus values. Then you 
can count average number of instances your app has, and you can guess, 
how much more memory your app is going to use. I expect it being 
just KBs ....

Ladisla - thank, that was it. I mean - break-after fixed it.  With 
above - columns, to simply reproduce it, just view child, close the 
window, and call view child once again ... it breaks to console after 
a while with stack overflow. Well, now I know that 'columns is not 
used anymore, but you might try to look at it, if you have time, 
to see why it causes stack overflow ...

eh, excuse me, couldn't following code be causing an infinite loop? 
:-)

show-native: :show
show: funct [gob][
;	print "SHOW>>>>"
;	set 'gcnt 0
;	t: now/time/precise
	update-subgobs gob
;	print ["updated:" gcnt "GOB(s) in " now/time/precise - t]
;	t: now/time/precise
	show-native gob	
;	print [now/time/precise "SHOW call in" now/time/precise - t]
;	gob
]

I am just wondering - it will cause a stack overflow at each show 
call. I wonder - show is not called the first time? How is that it 
crashes the second time?

When i close window, and call my %test.r3 again, I get stack overflow 
we discussed earlier ... Dunno, why I did not get it running the 
first time ...

It works. But it was not enough to just change the view-show.r3 code, 
and call it after do %r3-gui.r3, as the initial redirection will 
remain. A bit tricky, as there is no script to build new r3-gui.r3 
from sources, and sources are collapsed, but I managed it to change 
:-)

How is now R2's face/pane, and earlier face/faces replaced? I can't 
see it in the structure. Is that a gob!?

>> help main-pan
MAIN-PAN is an object of value:
   style           word!     vpanel

   facets          object!   [init-size min-size max-size align valign 
   res...
   state           object!   [mode over value]
   gob             gob!      offset: 3x46 size: 572x503
   options         object!   [content]
   tags            map!      make map! [ panel true ]
   draw-result     block!    length: 45
   intern          none!     none
   name            word!     main-pan
   names           object!   [t1]


I really miss the simple aproach of R2 guys. I wish I had a /pane, 
a simple block of stored subelements, accessible via normal rebol 
series functions, so no need for me to investigate the special purpose 
functions. That's what I call simplicity.

exactly. But the tricky part is as follows - I like having 'options 
in the dialect level, and I am kind of used to have to call style 
attributes a 'facets ..... I would have to think for a while, if 
we can accept following convetions:


- options - used to set style properties, either in the style itself, 
or in the layout dialect

- facets - special purpose properties, which can be used inline in 
the layout level


I think that it would work for me, and that we would have it aligned 
nicely that way. I am just not sure Carl or other guys are ready 
to give-up on facets name being a general attribute/property of the 
style :-)

I would simply call on-click for that particular button

Why does following does not work? I try to set the panel to the 'plain 
mode, but calling 'show crashes the code:


>> view [p: hpanel 200x200 [button do [set-facet p 'draw-mode 'plain 
show p]]]


So - how do I refresh/redraw the panel? Should I somehow call the 
'on-update actor?

What is the correct way to call an actor? do-style face 'on-update?

Robert - I can't see any subsystems ready, other than proper resizing 
(which is really nice), and focusing system. How can you say 2-3 
styles are enough to judge the design? I would not call non-working 
styles being an eye-candy :-) This is all about architecture -  when 
porting demo, I meet the case when I am able to easily change e.g. 
color of the scroller with Carl's GUI, which does not seems to be 
a case with RMA's GUI, or I just don't know how to do it. As I did 
not want to bether you here with such simple stupid thing, I tried 
to study material-system myself. But - I can tell one thing - if 
those things are not simple on the surface, it is either - missing 
docs, or very wrong architecture.


You should really remember, why Carl decided to rework the GUI - 
to be the pleasure to use, kind like of Amiga AMOS Basic, yet still 
allowing more complicated designs. If that aspect will not be pursued, 
ppl will not like the GUI. And what is the system good for, if not 
liked to be used by ppl?


OK, at this point, with 2-3 styles in focus, I might postpone port 
of the demo, no? As the demo is surely done with more than 2-3 styles 
:-) I will soon finish it to the state, when clicking the left side 
list items will not crash the demo. Non working stuff will be commented 
out. Then others might try to get more complicated set-ups running 
...

So much questions, great :)

I want freaking to change the color of the scroller
 - If not possible right now, it's bug and will be fixed.

How do I 
destylize" panel for e.g.?" - use material NONE

What is the correct way to call an actor?

 -  do-style FACE [object!] ACTOR [word!] DATA [any-type!] ; for example: 
 do-style face 'on-update none


how can I recognise, what arguments particular actors should obtain

 - good question. I have some ideas how to solve it, but right now 
 you should ask or study source :)

How can I properly attach scroller to progress bar?

 - In your case it should be auto-attached and 'attach shouldn't be 
 needed. Maybe 'attach doesn't work at the moment as the auto-attaching 
 of scrollers is actually a very bad thing that brings more problems 
 than it solves.So ATTACH is going to be reviewed and fixed when necessary.

I really wonder, if R3 GUI sees ANY regular development?

 - It does, but the developement does occur in areas you're probably 
 not interested in (GUI internals, TEXT-TABLE...)


Recent R3 GUI status is, that it is not usable for more than simple 
dialog box
 - Typical Pekrovina ;)

This is part of Carl's original design and I imagine that he made 
the idea of "slots" as you call it, so there is a simple way to map 
grouped areas of code to faces, when they are created. Note in the 
source, the definition of a style and a face are right next to eachother. 
So it becomes "how do I create a face from a model of a face, as 
quickly and easily as possible?"

I also have that. If you launch directly %demoJC.r3, you don't have 
the problem (there is a call to r3-gui.r3 inside demoJC.r3). It seems 
that if you call it two times, it crashes.

If something does not work, it is just because what you call "Carl's 
GUI" is the old version, while the newer version of the code are 
(somewhat improperly) called "RMA GUI". Nevertheless, everybody crying 
for it, can easily take it and update everything that he sees fit.

Danger, Will Robinson! Better not call Arab countries rare

yes they use. Ok, we can make *PANEL borderless and call current 
panel for example *FRAME

why ID, when you can call face directly? And of course there's tree 
of gobs, that's how gobs works.

Henrik - you see? I just wanted to have a "button" inside of view, 
and by change of stylize parameter, to change some aspect of the 
button. But I might be mixing few things together. In your above 
example, my-button is a class. So your saying that in R3 GUI, classess 
are not usefull, is an incorrect statement, as we already do have 
classes? Or what you would call your 'my-button then?

So your saying that in R3 GUI, classess are not usefull, is an incorrect 
statement, as we already do have classes? Or what you would call 
your 'my-button then?

 - A style is not a class in the HTML sense, where you can apply a 
 particular class to any tag.

What I can see though, is a kind of syndrome of a developers, who 
live behind the closed door, and then wonder if another point of 
view is presented. It very often ends with statements like "you can 
take Carl's code, and do your own GUI". And I am far from alone receiving 
such a reply. And THIS is what I call as an insult, to ppl expressing 
different pov on the direction taken.

The behaviour is recursive in that if I call UPDATE-FACE, then all 
parent panels up to the main window are updated.

So if I have a vpanel which contains two hpanels and call UPDATE-FACE/CONTENT(S) 
will the contents of the hpanels be re-sized?

Two notes:

- update is not resize, but can provoke a resize as well

- if I call UPDATE-FACE/CONTENTS on a hpanel, then the hpanel is 
updated (row and column sizes are recalculated, the total panel size 
is recalculated), but the panels contained are not

As opposed to that, when I call UPDATE-FACE on the same hpanel, the 
row and column sizes are not recalculated, since there is no reason 
for that

Some time ago Pekr suggested to rename the DO-STYLE function to DO-ACTOR. 
The proposal seems to have attracted the attention now, so, one of 
the last opportunities to express your preferences. To not be just 
abstract, In this example we call the ON-KEY actor for a certain 
given FACE, supplying it a certain ARG. Variants:

1) at present, the actor call looks as follows:

    do-style face arg

2) the variant proposed by Pekr is:

    do-actor face arg

3) is there any other variant you prefer more?

The main problem at the moment is (and I hope I hit it correctly, 
otherwise Lad etc. will correct me) that it's not clear which ACTORs 
call which REACTORS. And if all REACTORS are executed or not. So, 
there is not logical relation between an ON-KEY event and an ON-KEY 
handler. Further, one sometimes need to first call the user-code 
event handler, than the style handler, or the other way, or in between.

There was ATTACH IIRC - it was used for scrollers mainly. In more 
abstract pov it might just call attached style's on-attach or on-set, 
I don't remember anymore. But - I also remember guys here said, that 
areas will not be done that way anyway (attaching just separate scroller 
style) ....

Also - DO is an implicit REACTOR, but still one of reactors. So - 
what will happen to DO itself? Will we call it just another KEYWORD?

it won't be necessary with actions (I hope). you simply call actors 
directly. About chaining them, how does it make sense to chain an 
on-click and on-hover actor? They are separate actions. What you 
need is the ability to stack the action code for actors, so that 
if an actor is already defined for a style, then the new action code 
could be appended to the original code. I use a similar design in 
my private version of the VID Extension Kit, but am also forced to 
use the traditional actions as they are part of the standard face.

A terminology problem related to the ATTACH keyword. Every face should 
have an attribute listing the items attached to it, and an attribute 
listing the items to which it was attached. One (let's call it 'extra 
long') alternative might be ITEMS-ATTACHED-TO-THIS and ITEMS-TO-WHICH-THIS-IS-ATTACHED. 
To show you an example, let's have faces A and B, and suppose, that 
the user attached B to A. Then:

1) for A, the ITEMS-ATTACHED-TO-THIS list shall contain B
2) for B, the ITEMS-TO-WHICH-THIS-WAS-ATTACHED shall contain A


The problem is, that the above two attribute names probably aren't 
the best possible (or, are they?). Any "ideal" attribute names you 
prefer?

With 3. you can simulate 1. The advantage of 3. is, that I can decide 
at what place the parent actor is called.


Which leads me to a question: Is 3. a call the parent actor, which 
returns, or do I just let the event flow and it will never return 
to my handler?

Rebolek, also I'm afraid in case of #1....since you can call any 
actor of any style/face from the style code, we would propbably check 
all such DO-ACTOR calls in the code to make sure they are not called 
on style/face that doesn't have the specific actor defined othervise 
the propagation would be triggered.

You may try to put each windows into separate objects to make all 
the set-words are local. Then set them none manually when the window 
closed then call recycle. This may work?

Oldes..don't search for any problem in this. When call the show on 
each mouse move I'm able to geterate more than 90 SHOW events per 
second without any 'wait' so it is understandable that such heavy 
forced rate on CPU calculated code steals lot of CPU time.

in case of 'text selection' you can call SHOW only when the selection 
really changes..this is not for every mouse event

this is the easiest way to know if a data element can be traversed 
via pick without having to first know if the datatype can be traversed.


the issue is that many types have indexed content but are not series 
(i.e. no "current" index).  so we can get the value or deny listing 
in one function call.

ex:

print-tree: funct  [data][
	i: 0
	either len: length? :data [
		repeat i len [print-tree pick :data i]
	][
		print mold/all :data
	]
]

another proposal:


have info? support more datatypes.  it would be very nice for a single 
function to return information about any datatype in a single call.

ex:
>> a: make string! 1000
>> a: next append a "12345678"

== make object! [length: 7 index: 2 size: 8 buffer: 1000 references: 
1]

You can time when you call it...

I didn't even know there was a newline bit, though it seems obvious 
in retrospect. It would be lost in the transfer of the value to the 
stack frame for the function call I bet, because stack frames and 
value slots of contexts don't keep track of newlines. You'd have 
to pass in a reference to the block the value is stored in, I'm guessing.

INSERT, CLEAR and UNIQUE are already native, so the actual time-consuming 
portions are already optimized. The only overhead you would be reducing 
by making DEDUPLICATE native is constant per function call, and freeing 
the memory immediately just takes a little pressure off the GC at 
collection time. You don't get as much benefit as adding /into to 
REDUCE and COMPOSE gave, but it might be worth adding as a /no-copy 
option, or just as useful to add as a library function.

Please check if an object can be used by extension code to resolve 
the case aliases. I don't really see how they could if the words 
are translated to numbers at command call time, but that might be 
a limit of my imagination.

you don't rewrite sum, you rewrite your call of sum