Section 3.1 requires us to “Load f1 database to remote process (port=5099), save handle to variable called hdbH”. I know that the proper command to save the connection handle to port 5099 is:
hdbH:hopen `::5099
but the verbiage “Load f1 database” seems to be throwing me off. I’ve tried hdbH"\l ." but this attempt was futile. Any hint or resource would be greatly appreciated.
For section 3.3, if anyone could point me to a place where I could find the syntax necessary to pass a table to a handle, it would also be greatly appreciated. I’ve been looking through the advdev1 modules.
Use the Remote Scratchpad to connect to the remote process and load the HDB as you have been doing for other sections;
Send a system command to the remote process using sync/async to load the HDB (similar to above)
Note, the “remote” process is on the same system as your primary workspace process. Using system “l .” might not work as this is a relative path - you need to use the full path.
For section 3.3, you need to set the table. Pseudo logic would be neg[hdbH] ({function};data), where you need to set the data in the function executed on the remote process.
Hi David (and anyone else who might be reading this)
David- Thank you for this. It was very helpful and thoroughly appreciated. I actually have all quizzes working except for 3.3 now. I’ve clearly loaded the .perm.users table to my remote process on port 5099, and I know this because the functionality for some of the other quizzes requires .perm.users to exist on this process, and those quizzes are all passing. However, when I go to my remote scratchpad (port 5099), and run “tables”, .perm.users does not show up, hence why I am failing quiz 3.3. When I define a simple table (t:( a: 1 2 3; b: 4 56) on my remote scratchpad, it appears when I run tables. My best guess is that .perm.users is a namespace variable, and that there must be a special method used to load it into the remote scratchpad working directory. I’ve toyed around with “set” to no avail. I hope this was all clear. Please let me know what you think, and if I need to clarify anything.
Hi David. Thanks for replying. I really appreciate your patience with this. I’ve used that pseudo logic (modified to be working kdb logic) to pass functions and data across to my remote process.
The logic I used to pass the data for the .perm.users table across to the remote process is:
In the line just before 3.3 you will define .perm.users on your local HDB process. In 3.3 you should send this entire table across the handle to the remote process, instead of defining and adding each user to it.
I’m not sure of the test case implementation but I think it’s comparing the local and remote .perm.user tables.
Tip - you can complete 3.3 in a single async call; i.e. send the entire .perm.users table from local to remote and set.
I am just wondering if you resolved your issue for 3.3, as I am failing it for the same reason. When I set the table on the remote process and run “tables” or “tables`.perm” the table does not seem to exist, however when I manually create the table on the remote process the table exists but the test for 3.3 still fails.
feature exercise3.3 before .test.randomHandle:hopen `::5099:twilson:letmewinonce; should .perm.users should exist on HDB process expect .perm.users~.test.randomHandle".perm.users"
I defined the table on the remote process in a similar way to what you had done above when manually creating the table. Then instead of adding each user, I passed the table created on the local process to the remote process and assigned the values to the table created on the remote process in a single async call. That way the table seems to be populated correctly and recognised in the test for 3.3.