Calling a module does not work in Raku in Windows - raku

I have two files main.raku and TestMod.rakumod in a directory C:\Users\suman.
TestMod.rakumod
unit module TestMod;
sub add($a, $b) is export {
$a + $b
}
main.raku
use lib $*PROGRAM.dirname;
use TestMod;
say add(8,9)
I want to call some functions in the TestMod module from main script file. When I run the script, I get this error
===SORRY!=== Error while compiling c:\Users\suman\main.raku
read from dirhandle failed: 123
at c:\Users\suman\main.raku:2
This is my OS specific information:
Host Name: SUMANKHANAL
OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.19043 N/A Build 19043
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Workstation
OS Build Type: Multiprocessor Free
Registered Owner: N/A
Registered Organization: N/A
Product ID: 00331-20350-00000-AA867
Original Install Date: 10/19/2020, 3:36:49 PM
System Boot Time: 12/7/2021, 1:00:40 PM
System Manufacturer: Dell Inc.
System Model: Inspiron 5379
System Type: x64-based PC
Processor(s): 1 Processor(s) Installed.
[01]: Intel64 Family 6 Model 142 Stepping 10 GenuineIntel ~1792 Mhz
BIOS Version: Dell Inc. 1.17.0, 8/18/2021
Windows Directory: C:\WINDOWS
System Directory: C:\WINDOWS\system32
Boot Device: \Device\HarddiskVolume1
System Locale: en-us;English (United States)
Input Locale: en-us;English (United States)
Time Zone: (UTC+05:45) Kathmandu
Rakudo specific information (installed from rakudo.org):
Welcome to Rakudo™ v2021.10.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2021.10.
This scenario however works in Linux. See MWE here.
Is it Windows specific issue/bug or am I missing something?

TL;DR A nanswer that might help you towards an answer.
What do I know?
Not a lot. I haven't used Windows for dev in years. I've not seen this error before.
I just decided to see what I could find. I found a couple things, read between the lines, and... ended up with this nanswer.
read from dirhandle failed: 123
A google for "read from dirhandle failed: 123" listed two matches for me.
One was this SO. I'm not sure that's especially helpful, though we are trying! 😊
The other match was:
githubmemoryhttps://githubmemory.com › ... · Translate this page ⋮
ohmycloud Profile - githubmemory
When I clicked it it did not include the error message I'd searched for.
But clicking the ⋮ showed an About this result popup, and a cache button at the bottom of that popup linked to an earlier version of the page that the search had matched. (This is a general trick to know about when a search result appears not to contain something you'd just searched for.)
And that page (which I can see with this URL; YMMV) contained this match:
when execute above script as Administrator, failed with read from dirhandle failed: 123
But it wasn't conclusive. Hmmm.
githubmemory.com is just a copy of GH. So I figured out it's a copy of this issue. And that is more conclusive. That is to say, the issue opener, ohmycloud, closes it with the conclusion:
It's actually a access deny error
Hmmm. Really?
Please consider investigating that angle, and perhaps editing your question to summarize your conclusions. But please read on first, because there are reasons to doubt it's an access error, as follows.
Windows System Error 123
My next research angle was determining exactly what the error code means.
I figured out the read from dirhandle failed: was from MoarVM, and that showed the error code was from GetLastError(), and I figured out that is from the Windows API, and I arrived at this reference entry:
The filename, directory name, or volume label syntax is incorrect.
Hmm. Why did ohmycloud talk about an access error?
We should probably try to investigate whether it is "just" invalid syntax rather than something else like an access error.
Please try the following, and consider whether it's worth pasting some of your results, at least one of them, into your question:
say $*PROGRAM.dirname.raku;
chdir $*PROGRAM.dirname;
say $*PROGRAM.dirname.IO.raku;
A last chance long odds dark horse?
While googling a tad more widely (dropping the 123) I found another match that might be of interest.
(It actually does have the same error, so I don't understand why it wasn't listed by the first google I tried, but whatever.)
It's this 2016 comment by nick cygx on the #moarvm channel
eventually dies with a SORRY: read from dirhandle failed: 123
This is also on Windows. One can tell that due to the error message but it's also confirmed later that same day on the IRC channel:
that "read from dirhandle failed" thing happens inside a windows ifdefed block
Afaict, cygx is saying they got the error message for the test case in the bug Class fails to smartmatch against role defined in module.
jnthn's response to this failure was:
That...makes no sense o.O
(Which is a pretty good summary of your SO.)
jnthn's said one other thing about cygx's error:
I've put off fixing up hyper/race for months already. :)
So, perhaps, or more lyrically as a last chance long shot dark horse, maybe there's some hyper/race related problem within MoarVM's guts that manifests on Windows in relation to module loading?
It would be helpful if you could try the "Minimal testcase​" in the bug report. Do you get the 123 error?
If you do, then perhaps (even longer shot) it's worth someone trying to get in touch with cygx? Unfortunately the nick cygx last appeared on #moarvm in 2019. So I did a google for cygx raku. I found an 8 month old comment about Raku under that nick from 8 months ago. (Which I see I replied to ineptly. Sorry, cygx.)
#ugexe's comments
Their first comment is:
Pointing a use lib ... at [a directory containing] files your current user doesn't have access to isn't a good idea.
That suggests you would best make sure the directory you're pointing lib at is not a directory such as C:\Users\suman because, in the general case, that may include files your Rakudo compiler can't access. (Whether this is the case depends on your system setup and what files you have, but the simple solution is to make sure you only point lib at a directory dedicated to Raku code.)
Their last comment (below this answer) is a link to a gist with lines like this:
C:\Users\ugexe>raku --ll-exception -e "use lib '.'; use Test;"
read from dirhandle failed: 123
at SETTING::src/core.c/Rakudo/Internals.pm6:1345 (C:\Users\ugexe\.rakudobrew\moar-2021.10\install\share\perl6\runtime/CORE.c.setting.moarvm:next)
from SETTING::src/core.c/Rakudo/Internals.pm6:1374
.
.
.
I don't know how to interpret this gist, but I can see that their gist:
Shows them producing the same Windows System Error (123) with nothing but a use Test;;
Shows paths that, if passed to Windows, would presumably be syntactically invalid (C:\Users\ugexe\.rakudobrew\moar-2021.10\install\share\perl6\runtime/CORE.c.setting.moarvm:next). My guess is that they're not passed to Windows, but instead just constructed that way as part of displaying the error. But that is just a guess.

Moving .rakumod files to a separate folder within C:\Users\suman and importing with use lib "<separate folder>" from main script works.
In my case, when I move TestMod.rakumod to C:\Users\suman\rakulib and modify main script as follows:
use lib "rakulib";
use TestMod;
say add(8,9)
it works.
Also moving both files to Desktop also works.
But I find it weird! Because two python files similar to my question works fine without any issues even when both of them are in the folder C:\Users\suman.
file1.py
def add(a,b):
return a + b
file2.py
from file1 import add
print(add(8,9))
So I was expecting the same with raku. Unfortunately it's not the case.
read from dirhandle failed seems like access deny error as pointed by many rakoons. I am interested to know how can we fix this from within raku.
Acknowledgement: The ideas suggested by #jubilatious1 and #chenyf works. So I combine them here.

It's ok on my desktop:
raku .\main.raku
17
OS Version: Windows 11 professional(21H2)
Raku Version: 2021.10

Despite what I've said in my comment, it's entirely likely that dirname is behaving according to spec; only it's not in that spec to return a platform-specific name. So it would be interesting to investigate what $*PROGRAM.dirname returns. If it's a Linux-formatted path, that might be part of the problem.
This is raiph's answer points at: wrong syntax.
If that's the case, we need to get to the "right" syntax. That is why in the first version of this answer I pointed at using IO::Path::Win32 to create that syntax. Other option might be to simply put the directory name by hand. Finally, a bug can't be excluded.

It may be a problem with read permission: read from dirhandle failed

Move the module code into its own folder such as (for example) rakulib, one level down from your main (calling) script. Then call the module from the main script with:
Main Script: "Suman_main.p6":
use lib "rakulib";
use SumanTestMod;
say add(8,9);
Module Code: "SumanTestMod.pm6":
unit module SumanTestMod;
sub add ( $a, $b) is export {
$a + $b
}
[ Answer adapted from code found in Arne Sommer's "Beginning Raku" book, see: https://arnesom.github.io/ ]

Related

How can I resolve labview 1386 error with thorlabs VI?

I'm trying to use LabView to operate a ThorLab CS235CU camera. However, so far I haven't had any success using LabView to operate it, despite searching the provided thorlabs and national instruments documentation and google for an answer all week. I started by trying ThorLab's VIs that came with their software, but anytime I run a script it returns the following error:
Error 1386 has occurred at Invoke Node. In the provided "simple image aquisition" VI, this error occurs at 3 locations (steps 2, 3, and 4) before deleting the rest of the script, if run with execution highlighted. National Instruments has 3 suggested fixes on their website: unblocking DLLs manually, which seems unrealistic given I don't know what is causing this error; running LabView as an administrator, which I had been doing from the beginning and didn't help the issue; and creating a configuration file, which I tried but did not work. I put it in C:\ProgramFiles\National Instruments\LabView 2020 as well as C:\ProgramFiles(x86)\National Instruments\LabView 2020, but the error still occurs. I'm very new to using LabView and couldn't begin to explain why this error is occurring, so anyone that can or knows how to help, please do.
It seems that you didn't set up the ThorLabs driver properly one way or another. Often it is the manufacturer's installer that must be run first (with LabVIEW turned off) and eventually you'll find the according driver/dll wrapper VIs (also referred to as LabVIEW-Driver) in some arcane subdirectory like <Program Files>\ThorLabs\<Product>\Drivers\Labview\...
It might make sense to copy that directory to your myProject\drivers\ Folder and the simple image acquisition.vi to something like myProject\examples and work your way from there. Also make sure you're using LabVIEW 32bit since few third-party drivers come in 64bit.

.NET Dir$ Function on Network Path

I have a network path that contains hundred of thousands .wav files. When I do the following:
FileBuffer = Dir$("\\MEDIASERVER\*.wav", FileAttribute.Archive)
The line freezes forever. I have literally let it run a day, and it never returns with execution. I then decided to test the symptom with a dir command in DOS. Same symptom.
I then wondered if I would get the same symptom if I added a prefix to the search pattern narrowing my results. I did this in DOS:
DIR 0009*.wav
Worked like a charm. So, armed with this knowledge, I went back to my VB.NET project and applied a similar solution:
FileBuffer = Dir$("\\MEDIASERVER\0009*.wav", FileAttribute.Archive)
Doesn't get stuck, actually does the search. But I was surprised by the first result:
FileBuffer came back with the following value:
003925034541228334146804222014065036AM005020MIF.wav
This does not match the pattern I asked for. Can someone tell me what I am doing wrong? Is there a known bug with DIR$? Is there a way to achieve what I want without enumerating 100% of the files in the network share?
Additional Information if it's relevant:
Developement Machine: Windows 7 Pro, VS 2013 Pro
Network Server: Linux Centos 5.0 (I have the same issue with a network drive running Windows 7 Pro).
Thanks in advance.
Sorry for just posting the question, and already getting the answer. The question about whether or not it worked properly in DOS helped narrow my troubleshooting. I came across a couple of pages on the net stating that DIR will come back with unexpected results. They state that it's because of the 8.3 naming convention. I then decided to see if there was any other constraints I could add to my program. I changed the pattern to:
DIR \\MEDIASERVER\0009*MIF.wav
And now I am getting the expected results. This cannot be because of the 8.3 Naming convention though. It's something else, but at least I got this working.
Thanks for your time.

Load error building COBOL batch - "cob32api" not found

Could somebody please explain what cob32api does?
I have the task of migrating a batch cobol system from 32 bit Windows to 64 bit Linux. A large number of programs call 'cob32api' which belongs to Net Express. The Linux equivalent to Net Express is Server Express, but I'm not at all clear on what this particular call actually does. There don't appear to be any parameters required. Sadly, there are also no comments explaining what it's for.
Naturally I get an error when I try to build:
Load error : file 'cob32api'
error code: 173, pc=0, call=1, seg=0 173
Called program file not found in drive/directory
Can anybody help me out here?
Thanks in advance.
OK, I tracked down a colleague who has worked on this stuff and knew what it meant. The call to cob32api is required so that the cobol program in question, as well as any sub-modules, can call Windows APIs. This explains why the corresponding library (cob32api.dll) has no Linux equivalent.
The simple solution to my problem: Remove the call altogether.
I hope this helps anybody who runs into a similar problem.
Thanks for the comments.
Additional information:
The removal of the "cob32api" call had consequences for the sub-modules I mentioned. Ther were a number of calls of the form
CALL WINAPI "windows-function-name" ...
These resulted in later compile errors and therefore needed to be replaced.

Debugging interpreter in VM when changing vm primitives

Context
As a university project we want to change the the pharo vm to use an object-table and see what happens.
We use a pharo-vm clone from github and VMMaker. Building the VM works fine.
To get started we added a primitive that returns an incremented Integer:
InterpreterPrimitives>>primitiveIntegerIncrement
"increments an integer"
self pushInteger: self popInteger + 1 .
and modified StackInterpreter class>>initializePrimitiveTable accordingly
MaxPrimitiveIndex := 576.
"... and so on ..."
(575 primitiveFail)
(576 primitiveIntegerIncrement))
And it works.
Problem
When we make changes to the VM we want to test-run already in the SmalltalkImage so we do not need to compile and see it did not work.
Something like:
StackInterpreter test: '1 inc'
And then I can debug if the primitive is wrong or an error occurs. Of course there needs to be done much more but how can I achieve this?
What we tried
category VMMaker-InterpreterSimulation class StackInterpreterSimulator. Trying the code in the comments
DoIt
^ (StackInterpreterSimulator new openOn: Smalltalk imageName) test
errors:
displayForm := 'Display has not yet been installed' asDisplayText form.
the ByteString does not understand asDisplayText
(CogVMSimulator new openOn: Smalltalk imageName) test
(InterpreterSimulator new openOn: Smalltalk imageName) test
error:
PrimitiveFailed: primitive #basicNew: in Array class failed
I also found this screen cast but it only debugs the VM from outside using gbd: http://vimeo.com/22485382#
Our project is hosted here: http://smalltalkhub.com/#!/~kirstin/PharoObjectTable
Current Status
We started implementing an object table. The lookup of attributes can go throught the object table. Full object table support and no usage of direct pointes is very tricky since pointers are expected everywhere. So we use pointers into the object table to identify when a lookup should go through the OT. We also found all object creation primitives and add new objects to the table.
How long is your project and how many people are you ? To me what you try to do is quite some work. Do you have good knowledge about low level behavior ?
To answer your question, the main problem here is that the cog simulator is not maintained in the pharo vm fork. This is because no one in the pharo crew use the simulator. We only use external debugging from gdb. In fact the pharo folks work mostly on VM plugins, the core of the VM is mainly maintained and developed by Eliot Miranda which works on Squeak. Therefore we report to him when there's a bug in the VM core.
For your project you would have to split it in at least 2 steps:
step 1: make the object table work with the stack VM
step 2: make the JIT work with your object table
Note that for step 2 I would recommend not to change the way an object access its header, therefore having a VW-like object table where you have the fixed size header on the one in the the object table, and the fields of the objects (and maybe header extensions) in the heap.
So use the StackVMSimulator and build the StackVM first. When everything will work (including context), you can think about hacking the JIT. Recently Guillermo Polito ported the Stack VM to the build process (see PharoSVMBuilder instead of PharoVMBuilder), a guy reported problems with this builder but you could hack it a bit to make it work.
Now to make the simulator work on Pharo 2.0 (which is the Pharo version of the generator image you have), you have to open the monticello browser and merge from Eliot's branch the Cog package (repo MCHttpRepository location: 'http: //source. squeak. org/VMMaker'), but not the latest Cog, the one at around the same date as the current VMMaker package of pharo-vm because the latest Cog and VMMaker of Eliot's branch are not stable.
The alternative being to start from Eliot's build image and merge things from the pharo branch. Here are infos about how to build the squeak development image (http://www.mirandabanda.org/cogblog/build-image/).
Then Eliot gave me this script once:
| cos |
cos := CogVMSimulator newWithOptions: #(Cogit SistaStackToRegisterMappingCogit).
cos desiredNumStackPages: 8.
cos openOn: 'my/favourite.image'.
cos openAsMorph; toggleTranscript; halt; run
You don't need the SistaStackToRegisterMappingCogit option. I guess some similar script with the StackVMSimulator should work.
Lastly there are some documentation about the simulator but it is only for the CogSimulator (these documentations expects you already knows how the StackSimulator works, and just give you hints about how to use it with the JIT):
http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/
and in one of the video named "Cog VM (part x)", x being from 1 to 6, Eliot shows how he uses the simulator to disassemble x86, print the stack and inspect the heap.
Another tip, ask your questions on the pharo mailing list (pharo users or pharo dev), because here no one may notice your question (fortunately someone pointed me out your question this time).
And tell on the pharo mailing list if you managed to run the simulator in Pharo 2.0, some people (as me) are very interested in it. I was planning to do it at some point.
Good luck ! Nice project anyway.
The last time I tried to use the simulator is roughly a year ago, and I did not make it work.
However, there are a few patches, which I assume never got integrated that might be of help:
https://code.google.com/p/cog/issues/detail?id=106
https://code.google.com/p/cog/issues/detail?id=107
https://code.google.com/p/cog/issues/detail?id=108
Issue 107 includes a patch for your asDisplayText issue.

How to make specific changes to a closed source DLL

I was recently reading an article on the Windows Metafile vulnerability (http://en.wikipedia.org/wiki/Windows_Metafile_vulnerability#Third-party_patch) and I was interested by one of the points made.
A third party patch[9] was released by Ilfak Guilfanov on 31 December 2005 to temporarily disable the vulnerable function call in gdi32.dll.
So this got me thinking as to how Ilfak Guilfanov actually went about disabling the function in gdi32.dll.
My theory got as far as opening dependency walker and finding the function entry point and then analysing that in a Hex editor, however Hex isn't my native language unfortunately.
So would you require some form of expensive software to achieve something like this or would it be a case of a lot of trial and error ?
Note: This isn't intended as a hacking question, but more to understand what I see as a very interesting and clever process
You could open up the dll with your favorite (dis)assembler, find the entrypoint of the function and put a ret assembler instruction to directly return from the function without doing anything else.