when trying to convert AppGer.gf and AppFre.gf to .Pgf, I am getting out of memory error. Any help would be much appreciated.
Thanks in advance.
Following is the snapshot of the code and error:
$ make AppGer.pgf
mkdir -p ./gfos && gf -s -make -literal=PN,Symb -probs=./app.probs -gfo-dir ./gfos -name=AppGer AppGer.gf
gf: out of memory (requested 1048576 bytes)
Makefile:61: recipe for target 'AppGer.pgf' failed
make: *** [AppGer.pgf] Error 251
GF is Grammatical Framework, a programming language for writing multilingual grammars. GF is implemented in Haskell, but this question has nothing to do with Haskell.
In case someone else with a similar problem has found this question by googling the error message, the issue has been discussed on GitHub: https://github.com/GrammaticalFramework/GF/issues/35. Relevant answers from the issue:
It works but you need a lot of memory.
I have 16GB as well but I can't reproduce the problem. I have seen this problem before. Sometimes French fails to compile but then if I run the make file once more it succeeds. I guess that with the given memory the compiler manages to do part of the compilation and the output is stored in the .gfo files. On the second run it does the rest. I have never had the same problem with German.
Related
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/ ]
I know it can be done, but I'm having trouble getting it working. I'm still finding my feet with Haskell.
I tried using postgresql-typed, but it wouldn't compile. They don't enable the QuasiQuotes extension, so I don't understand how their code would ever compile. It also fails with an error on the useTPGDatabase statement. I cloned the library's source code from Github, but their tests failed to compile using stack with exactly the same errors.
I considered using hasql-th, but it's not on stackage.org, which immediately puts it in the "too hard basket.". I considered switching to nix but that seems like even more effort.
Does somebody have a reliable recipe for getting an environment working that type-checks SQL at compile time in Haskell?
I considered using hasql-th, but it's not on stackage.org, which immediately puts it in the "too hard basket."
All you need to do is add the latest version of hasql-th to the extra-deps section of your stack.yaml file and all other deps that Stack will suggest to you when you build.
In the end your stack.yaml file should look something like this:
resolver: lts-17.9
extra-deps:
- hasql-th-0.4.0.8
- headed-megaparsec-0.1.0.4
- postgresql-syntax-0.3.0.3
Anticipating a question in the spirit of "Why is it not listed on Stackage?" It's just that nobody has gotten to list these packages yet.
My question similar to the one asked here; however, I tried the solutions proposed and I don't know what is the problem.
One of the solution was to use the following command
server_start_command -J-Xm900m
when I tried it I got command not found and I searched how to get it but couldn't find it!
I tried also this solution
jruby -J-Xm900m abc.rb
but I keep getting the same error,
Error: Your application used more memory than the safety cap of 500M.
Specify -J-Xmx####m to increase it (#### = cap size in MB).
Specify -w for full OutOfMemoryError stack trace
What should I do in this case?
There is a typo in your invocation of jruby:
You used jruby -J-Xm900m abc.rb but you should write jruby -J-Xmx900m abc.rb
While reading the Red site, I came across a statement stating that compiling an hello world Red/System program creates..
"...a 162 bytes ELF binary, while a similar C code would
produce a 5-6KB binary using Gcc"
That's amazing. Can someone explain/point me to the techniques making such optimizations possible?
It was achieved by having an almost empty runtime library (just a few syscalls wrappers) and an ELF emitter which would not align sections on 4K page boundaries for optimal loading.
Though, that was true for Red/System 0.1.0, so in its very early days, not true anymore (now it would be similar to other compilers). Though we still have a -r compilation option for compiling Red/System code without any runtime, but as nobody uses it, it might not work anymore (should be easy to fix anyway if someone needs it, just drop by Red's chat and ask for it. ;-))
I'm getting a "Compilation exited with code 134" when attempting to use the "LLVM Optimizing Compiler" switch for release iPhone builds, using MonoTouch 4.0.1.
I don't get much information from build output window at all - just:
"Compilation exited with code 134, command:"
MONO_PATH=(snip)/bin/iPhone/Release/LSiOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot=mtriple=armv7-darwin,nimt-trampolines=2048,full,static,asmonly,nodebug,llvm-path=/Developer/MonoTouch/LLVM/bin/,outfile=/var/folders/03/033pAAGuHgGkIy4CorbVV++++TI/-Tmp-/tmp38107451.tmp/Newtonsoft.Json.MonoTouch.dll.7.s "(snip)/bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll"
Mono Ahead of Time compiler - compiling assembly (snip)/mscorlib.dll
What is odd is that in earlier command lines, there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is the compiling, but in this case it says "mscorlib.dll".
Any thoughts?
I have found a few cases (googling and from bugzilla.xamarin.com) where the error code 134 is related to Mono.Linker being too aggressive (removing something that's needed).
This is easy to confirm by turning off the linker, i.e. "Don't link" in Linker Options. If the build works then you can try isolating the assembly where the linker makes a mistake.
E.g. add a "--linkskip=mscorlib" to the mtouch extra parameters and re-enable linking. This will link everything (Link All) or all SDK (Link SDK assemblies) except the assembly you selected (mscorlib in the example). That's only a workaround and a bug report should be filled so the issue can be fixed properly (and get you all the linker advantages).
However be warned that there are other issues sharing the same error code, like:
http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a
YMMV
mtouch does its native builds in parallel so the logs can be confusing, e.g. you can see a bit of assembly X output followed by some assembly Y output.
Reading the full log might help you (or us) to pinpoint the issue.
I was having the exact same problem Scolestock. My app would build fine until I enabled llvm, then it was "Compilation exited with code 134, command" when trying to build the 7s for the app itself.
I'm elated to say that after 2 days of painstakingly whittling my app down to the core problem, I was able to isolate the issue to the usage of embedded dictionaries such as:
Dictionary<enum, Dictionary<enum, value>>
I was able to fix this by defining a class for the embedded dictionary and using that instead:
public class MyDefinition : Dictionary<enum, value>
{
}
...
public Dictionary<enum, MyDefinition>
Not sure if this will help you, but hopefully it'll help some poor soul who decides to use embedded dictionaries and runs into my same problem.