Scripting Client

Could this based on the same way yab do it?

Hey, you’re right, hey doesn’t pass on extra values for direct Get commands, only Set ones, kind of makes the Get Folder useless if you can’t specify the folder (program authors should use the Get with a Name format rather than passing it in as an extra parameter, to avoid hey problems). It looks like the “to” keyword only works for Set, definitely not Get or Create.

I was able to get Tracker’s Create command working by using this hey syntax :

./hey Tracker create Folder with "data=file /boot/home/Junk"
Send BMessage(B_CREATE_PROPERTY):
   "specifiers" (B_MESSAGE_TYPE) : what=B_DIRECT_SPECIFIER
       "property" (B_STRING_TYPE) : "Folder"
   "refs" (B_REF_TYPE) : /boot/home/Junk
   "data" (B_REF_TYPE) : /boot/home/Junk
Reply BMessage(B_REPLY):

By the way, I rebuilt hey with the debugging #define turned on in the hey.cpp source code to get that output. For reference, here’s how you compile it, after getting the Haiku source code into a directory called “haiku”. Note that it seems to build half the operating system before actually compiling hey:

cd haiku/
mkdir generated
cd generated/
../configure 
cd ..
cd src/bin/
vi hey.cpp 
jam -q -da hey
cd ~/haiku/generated/objects/haiku/x86_gcc2/release/bin/
./hey

Hey, that’s a good idea. If we had automatic conversion between JSON and BMessages (and vice versa) then that could make application scripting easier.

Yep. I actually peeked into the hey code last night, and he only looks for a value argument specifically for SET and LOAD commands. Any supplied argument is ignored everywhere else.

In my brief look, I’m not sure that other commands can be added to the “add_data” function easily. The parameter is mandatory for SET andf LOAD, but I think for other commands it’s optional – certainly for GET. Not sure if his code will handle that.

Hah. Thanks.

I did it a little more simply… :grinning: I copied the source and rdef into a work folder and set up a quick makefile. Worked fine.

./hey Tracker create Folder with “data=file /boot/home/Junk”

works for me, too, but:

./hey Tracker do Folder with “data=file /boot/home/Junk”

– which according to the suites should open a window – doesn’t!

Created message is completely different:

hey Tracker do Folder with “data=file /boot/home/TEMP”
Send BMessage(B_EXECUTE_PROPERTY):
“specifiers” (B_MESSAGE_TYPE) : what=B_NAME_SPECIFIER
“property” (B_STRING_TYPE) : “Folder”
“name” (B_STRING_TYPE) : “with”
“specifiers” (B_MESSAGE_TYPE) : what=B_DIRECT_SPECIFIER
“property” (B_STRING_TYPE) : “data=file /boot/home/TEMP”

Didn’t understand the specifier(s) (error 0x80002008)

Alll seems pretty messy to me. Think I’d rather make a fresh start.

:grinning:
That reminds me though of Willy Langeveld… (who I just now see seems to be responsible for BRexx!) We were at the meeting where Be announced their scripting scheme, and afterwards he fulminated fairly hard that “they did it all wrong!” At the time I didn’t feel ready to argue pro or con, but now I’m beginning to see his point!

I have to admit that somehow I had an aversion to AREXX – can’t remember why now, but I think I didn’t like RexxPorts much as I thought they “didn’t do it right” (I had another AmigaIPC protocol that was safe…).

I guess I should take a look at BeBRexx (which I didn’t know about). I found it on your GitHub. Are you responsible for it now?

I guess I am. I just made some fixes to get it building and running because I needed it when porting ACE from MorphOS.
But let’s see if we can bring it somewhere :slight_smile:

That’s really confusing. Hey thought “with” was the name of the Folder object, and then stuck in a second operation with the data string literally as the type of thing to operate on. Which means find the Folder named “with” then do the “data=file /boot/home/TEMP” operation on it.

Just noticed code updates to launch_roster command line program to add logging (though the program’s general help doesn’t mention the new “log” keyword). It controls launch_daemon, which (re)starts and stops other programs as needed to get to certain levels of system operation and when things happen, like new disks being mounted.

That whole thing could have been done as application scripting to launch_daemon. Strangely enough, if you look under the hood at https://git.haiku-os.org/haiku/tree/src/bin/launch_roster.cpp you’ll see that it communicates with launch_daemon using BMessages, but with custom arguments. There’s a whole LaunchRoster class https://git.haiku-os.org/haiku/tree/src/kits/app/LaunchRoster.cpp that just converts back and forth between function arguments and BMessages. If it had been done with application scripting then you wouldn’t need to learn and use an intermediate program and glue classes to use the launch daemon. Missed opportunity in my opinion, unless there’s some technical reason for it that I didn’t notice.

Definitely! I grabbed it yesterday, and had it compiled and running in about 20 minutes. (Not actually installed. Put everything in a test folder and ran from there.) Seems darned solid. (Only silly glitch, probably an easy fix: I tried, like a new user might, “rx --help” or just “rx -h” and it crashes! Strangely, other invalid single-char options don’t crash.) It should be an available choice of language.

I see that Willy has enabled both BeOS scripting and his own scheme. (I was amused that in the docs his tone in describing BeOS scripting is pretty much as I remember from the meeting! :grinning:) At a brief glance, I think his scheme looks good for extended scripting actions. The necessary components are pretty small (and not dependent on REXX), so maybe they should be part of the base distribution, like hey. Nobody would incorporate that scheme into their apps unless it was.

There is a BeBREXX package, which means if you want to use this in an app, all you need is a “requires:bebrexx” in the package.
But still, we should start thinking about what to include in the beta1 cd.

I haven’t found any hpkg yet(?). In any case the scripting components only consume about 46kB, as opposed to ~360kB for a complete binary set. (Not that much I suppose, but then there’s docs and examples…)

~> pkgman search bebrexx
Status  Name              Description                                                            
-------------------------------------------------------------------------------------------------
S       brexx             A REXX interpreter with Haiku scripting integration                    
        brexx_devel       A REXX interpreter with Haiku scripting integration (development files)
        brexx_source      A REXX interpreter with Haiku scripting integration (source files)     
S       brexx_x86         A REXX interpreter with Haiku scripting integration                    
        brexx_x86_devel   A REXX interpreter with Haiku scripting integration (development files)
        brexx_x86_source  A REXX interpreter with Haiku scripting integration (source files)     

When I try:

>pkgman search bebrexx
No matching packages found.

A bit confusing anyway. I’m not sure why Willy added the “Be”; I thought the “B” was the distinction. But then the packages are called brexx! (And of course the actual executable is “rx”!)

Actually the B predates BeOS, BREXX was originally written for DOS and UNIX (https://github.com/vlachoudis/brexx) and I guess the B is there to differenciate it from AREXX, which is the implementation usually used on Amiga.

BeBREXX adds the scripting support for BeOS and all the nice native things.