World: r3wp

So far I'm using this:
myfunc: func[
	"Defines a user function with given spec and body."
	[catch]

 spec [block!] {Help string (opt) followed by arg words (and opt type 
 and string)}
	body [block!] "The body block of the function"
	/local desc
][
	if parse spec [set desc string! to end][
		insert body reduce ['log desc]
	]
	throw-on-error [make function! spec body]
]

However, In R3, you can use the stack inspection native STACK for 
an approximation:
>> foo: func [] [print stack/word 1]
>> foo
foo
>> bar: :foo
>> bar
bar

Hm... that would be enough, but I'm in R2 now.

In R2, use the catch-an-error trick

      a-function: func [][print ["i am named " get in disarm  try [0 / 
      0] 'where]]
      a-function
      i am named  a-function

ah.. good one:)

cool :)

Just remember that a function does not really have a name. Just the 
name, if any, by which you called it:

    b-function: c-function: :a-function   ;; one function, many names

    do reduce [:a-function]                      ;; one function, no 
    name

http://www.synapse-ehr.com/community/threads/rebol-on-windows-7-and-a-network.1424/#post-10560

Anyone?

Interesting. I remember some talk about it in the past, but I thought 
it was fixed, or it was a different issue. I will try tomorrow at 
my work, our share is called "L:" too :-)

Graham, gotta love that Win 7.  I was about to move all my belongings 
to a W7 machine and retire my XP but not now.

GrahamC, thank you for passing this around.  I did get part way to 
a solution, as noted on your site.  Strange as it may seem, I am 
able to get to the network drives if I run a copy of REBOL that I 
download and leave with the name it came with, namely rebol-view-278-3-1. 
 The copy of REBOL that was giving me trouble was the same rebol-view-278-3-1, 
but I had renamed it to rebview to make a desktop shortcut work. 
 I had the name "rebview" in the shortcut so that I would not have 
to change the shortcut if I ever got an upgraded version of REBOL 
with a different name, like maybe rebol-view-279.  So my first problem 
with WIndows 7, REBOL, and network drives seems fixed.  


I still am not to a full solution to my Windows 7 issues.  I have 
some REBOL scripts that use the "call" command to run powershell. 
 Powershell then runs a powershell script to extract stuff from an 
EXCEL spreadsheet, which then is manipulated by the REBOL script. 
 Actually it's a bit messier.  I run a REBOL program launcher on 
the C drive which runs a REBOL script on a network drive.  The script 
on the network drive calls powershell with parameters to make powershell 
run a powershell script.  The powershell script extracts EXCEL data, 
and the calling REBOL script then makes a report of the extracted 
data.  


When I try to do this, the result from powershell is that I am not 
allowed to run scripts on that computer.  I am aware of this feature 
of powershell, and I have done what has worked for Windows XP (set-executionpolicy 
remotesigned).  I can run powershell directly, and execute scripts 
located on a network drive.  When a REBOL script that worked on XP 
calls powershell on WIndows 7, it won't go.  I am not expecting any 
help with this last issue at this time because the "call" does work 
in some cases (call/shell "notepad") (call/console/show "powershell"), 
so I still have several things to try, and if none work I am plotting 
a work-around.

Also try to use the full path. Once I have faced a problem CALL with 
REBOL style file! value. It worked with a windows-style path.

And also have problem with /shell worked on my XP but did not on 
my customers W7.

I just tried:

do to-rebol-file "L:\some\path\here\test.r"


and everything went OK, Win Vista here. Console is being launched 
form the shortcut on start bar, pointing to renamed to rebol.exe

note: the reason I used to-rebol-path was, that directory names contained 
spaces ....

Ok, I'll suggest this ..

When I use FIND with CHARSETs it ignores the /TAIL refinement. Is 
this a bug?

;with charset
>> find/tail "abc" charset "b"
== "bc"
>> find "abc" charset "b"
== "bc"

;with string
>> find "abc" "b"
== "bc"
>> find/tail "abc" "b"
== "c"

I think /last and /tail only apply to string values. Perhaps a feature 
that hasn't come to pass yet? :-)

be aware, that find with charsets behaves differently in more ways
>> find "abc" charset "db"
== "bc"

Combination of find/tail and charset looks like a bug to me.

sqlab, a charset is not a string its a bitset, so it will search 
for ALL the characters in the charset at each byte...   also note 
that when using find, charsets are case sensitive (and very fast).
the bug with /tail is pretty surprising, I never noticed it.

sorry for the color... It got stuck, I didn't realize I was in yellow 
 ;-)

I know that charsets find the first occurance of any of the chars, 
but maybe Endo knows that too. So I should probably not remind.

Thank you guys. I know the behaviour of charset in FIND. But I expect 
to skip the char that found, if I use /TAIL refinement as in using 
string.
Same for /LAST as Gregg said. It ignored for charsets. 
And also;
>> find/reverse "endo" charset "d"
== none
a bit confusing..

Only Carl can say if it's by design or not.

I've got a function that doesn't and I know one of you can explain 
why. 
foo: func [  /dothis anobject ] [
 if dothis [
  dosomething anobject
 ]
]

foo myobject


So the dosomething function does not work with the "anobject".  However, 
If I hardcode the "myobject" into foo like:
foo: func [ /dothis ]
[
 if dothis [ 
 dosomething myobject
 ]
] 


It works. So my questions are: Is it because "anobject" is a pointer? 
And what do I do on the calling/receiving sides to fix that?
Thanks in advance.

=doesn't work.

Hold on. I think I might be testing the wrong thing.

Nope, that wasn't it and I'm back to wondering what's the difference 
between the object and the passed object.

OK, figured it out. I had to pass the object as a 'word then "do" 
it in the function to get it to work.

You can pass functions as parameters, and then omit the 'do

In your example, you didn't spec the /do-this refinement on the call. 
Probably just a glitch in posting here though.

Thanks Graham and Gregg. The object that I was passing was a face 
and I tried different ways to get it to work and that was the only 
way it would work. I guess the question is how does one know when 
he is passing some value if the receiving function sees it as the 
writer is intending it to be seen. Anyway for now I am satisfied 
and have moved on to other issues. I appreciate your input though.

If the func doesn't take a lit-word/get-word argument, it should 
evaluate and pass as an object. Now, if you have a block of words 
that refer to list faces, and you pass that word, that's what you 
get. If your func has types defined for the args, that can help catch 
issues like this.

Gregg, thanks, it could be the func that's getting the arg, the "dosomething" 
in my example. I hadn't look at that though I was wondering still 
what the difference was with the two objects. Unfortunately it always 
seemed right even with the types defined because they were both objects. 
At least that's what type? outputted. Maybe it has something to do 
with the context they were bound to. Anyway, that's for another day. 
Thank you as always.

James, I think you are mixing up the word which refers to an object 
with an object value.  this is confusing in Rebol because words are 
not variables.  

it's happened to me a few times (especially in VID) that I mix this 
up in action blocks and VID dialect builders.

often, I'd build a block to be used and forget to reduce the block 
before appending it to the spec.  so what happens is that you receive 
an unbound word, instead of the data you assumed it should be refering 
to.

Thanks Maxim.

since I've been doing parse compilers for the last 2 months, I can 
say this have happened even more often lately  ;-)

you might also look up the 'COMPOSE word, it's very handy for resolving 
these kinds of issues (considering it's this kid of issue to begin 
with ;-)

Thanks. I wish there was a way to compare words like this so one 
could find out what the difference was. I suppose that is part of 
the bindology world. Glad to hear you are working with Rebol. It 
could be me but I haven't seen you around lately. Probably me because 
I haven't been around much here myself.

I've been working a lot lately, and haven't had a lot of spare time. 
 I'm actually working with REBOL full time at a company which is 
using it to get a significant competitive advantage over the competition.

(eek that was redundant, sorry ;-)

I think people don't realize just how much power lies in parse.  
 Even I'm impressed with it right now.  I've been doing tests with 
really crazy stuff like two-cursor parse rules and run-time auto-recompilation 
of 400MB parse rules. 


 I've been doing things like parsing 100MB word documents and pushing 
 the interpreter to the limit ... reaching the 32-bit 1.6 GB RAM limit, 
 6 hour loop tests, etc. :-)

in my last test I was doing natural language extraction of concepts 
at a rate of 25000 words a second within multi-megabyte text files. 
 :-)

Who is this guy?

hum... either that was sarcasm or you mean, what is the company I 
now work for?

Not sarcasm .. just humor :)

hehe, I wasn't sure  ;-)

That's incredible Maxim. Good work. With what you do with parse, 
is the knowledge available online  in tthe form of the present parse 
documentation, or did you have to discover new techniques? I have 
to admit I just barely use it when I need to. Anyway, thanks for 
sharing your experience. I

learning parse requires baby steps and at some point, the decision 
to solve a real problem with it and force yourself to learn it.  
I didn't use parse for almost a decade until I started using it more 
and more to a point that currently I do more parse than any other 
coding in REBOL (but that's just because its idealy suited for this).


some little tricks accumulate with experience and eventually, we 
discover pretty wacky things, which allow us to use parse almost 
like a VM.

Parse is REBOL's heart... I cannot imagine living without it.