How to add alias for extension namespace in wikimedia? - lua

I am trying to create my custom copy of italian wikipedia from the dump.
I encounter the problem with some of extensions.
I have got the error:
Lua error in package.lua at line 80: module 'Modulo:String' not found.
The problem is that there is no 'Modulo:String' in my copy, but there is 'Module:String'.
I have tried to add alias for this namespace in my LocalSettings.php, as I did for categories, but for modules it didn't help.
$wgNamespaceAliases['Categoria'] = NS_CATEGORY; //this helped for categories
$wgNamespaceAliases['Modulo'] = NS_MODULE; //this does not work
Module namespace is part of Scribunto default namespace.
https://www.mediawiki.org/wiki/Extension_default_namespaces
How to solve the Lua error with loading modules?

The actual set of namespace aliases for Italian Wikipedia is (1); Categoria and Modulo are translations. To use them, just set $wgLanguageCode to it.
(I'm not sure why setting Modulo as an alias does not work; in theory it should. But it's not the easy way to set up a mirror.)

Related

Why is F# having a problem with partially overlapping module names?

This one always gets me, and I fail to understand the problem the F# compiler is having here.
I have two files for two modules.
A.fs:
module A
//rest of the module goes here
B.fs
module A.B
//rest of the module goes here
When I build this project, I get:
A.fs(1, 8): [FS0247] A namespace and a module named 'A' both occur in two parts of this assembly
Why? There is nothing else in the project, other than the Program.fs. Am I wrong to assume I can break down modules into multiple files to keep things under control, while using a namespace like naming scheme? (obviously the compiler thinks so).
I want to understand the problem the compiler is having here and why I'm presented an error that refers to namespaces, even though I have no namespace declarations in my code.
Here is an answer to this question, just in case someone encounters the same error and googles their way here.
This bit from the modules documentation explains what is going on:
In the syntax for the top-level module declaration, the optional
qualified-namespace is the sequence of nested namespace names that
contains the module.
By declaring a module as A.B I'm actually declaring a module B in namespace A as per the above description. So I'm ending up with a module named A due to
module A and a namespace A due to module A.B and the compiler is telling me that I now have both a module and a namespace named A in this assembly.
I'll change this answer or un-accept it in case I'm wrong.

importing library modules using a frequent imports approach

Suppose there is a set of frequent imports that I would like not to have to repeat in every module. Is there a way to specify "frequent imports" that could be called instead. For example something like:
module frequentImports =
open System
open System.IO
...
Then instead of having to retype all the imports individually, the frequentImports module could be called instead. Obviously, the above approach doesn't work for me which is why the question.
Thanks.
There is no way to define something like a group of open statements and then just refer to the group. Generally, you just need to have all your open statements once per file.
The fact that you have too many of them that you want to repeat all the time might suggest that your code organisation is not optimal - I would think that if you have code structured by putting logically related things into a single file, then each file would need different imports.
One thing you could do - though I don't think it's all that nice - is that you could define a module with module and type aliases for the things you commonly need.
Say, if I wanted to avoid opening Microsoft.FSharp.Reflection and System.Collections.Generic, I could define a module with aliases for the things I need:
module MyThings =
type Dictionary<'k,'v> = System.Collections.Generic.Dictionary<'k, 'v>
type FSharpType = Microsoft.FSharp.Reflection.FSharpType
type FSharpValue = Microsoft.FSharp.Reflection.FSharpValue
Using open MyThings now gives me access to the three types (and the same would work for modules too). That said, this does not automatically import all definitions and I think it's probably not worth doing this - but it's an option.

Lua Sockets Module cpath

I'm trying to use the sockets module in a script and I keep encountering a issue where the script is unable to find socket.core. Is there anyway for me to point to exactly where the core.dll is? I've tried using cpath and I can never seem to get it to work. I just want to be able to say "C:/folder/folder/folder/core.dll"
package.cpath = 'F:/Folder/Foldertwo/Game/agame/Beta/Scripts/libs/socket/?.dll;' .. package.cpath
#EgorSkriptunoff is correct in his comment: socket.lua (which is a lua module) loads socket.core (which is a dynamic library), so you won't be able to load it from folder/core.dll as the default searcher will be looking for socket/core.dll.
If you really want to load it from folder/core.dll, you may try to load it yourself and assign the returned value to package.preload['socket.core']. This way when socket.lua loads the module, it will get the value to return from package.preload key without loading the module.

function 'Func/Arity' already imported from 'Module'

I defined both area/1 and perim/1 in modules sqaure and circle.
I want to import and use them in another module. Here is my import statements:
-import(square, [area/1, perim/1]).
-import(circle, [area/1, perim/1]).
I got these error messages.
~/test.erl:4: function area/1 already imported from square
~/test.erl:4: function perim/1 already imported from square
I know erlang does not support namespace. But since we can qualify a function call by specifying the module (i.e. square:area vs circle:area), I fail to see how the lack of namespace is the source of the error here.
So, what exactly caused the above error and how can I fix it?
In Erlang, "importing" a function from another module means being able to call it as if it were a local function, without the module prefix. So with this directive:
-import(square, [area/1, perim/1]).
you could write area(42) and it would mean the same as square:area(42).
However, if you include area and perim functions from two modules, it would be ambiguous which one you'd actually call when writing area(42).
As you correctly note, you can always qualify the function call with the name of the module, i.e. square:area(42) and circle:area(42) - so I would suggest doing so consistently and removing both import directives. This is also recommended by rule 6.6 of the Erlang Programming Rules - "Don't use import".

Type provider and static argument in F#

I have a library, Library_1, which compiles correctly and defines a provided type :
type modelforexcel = FSharpx.ExcelFile<#"template.xls", "Brokernet", true>
When I include this library in another project, Library_2, the compiler complains that it can't find any "Brokernet.template.xls", at the root of the new Library_2 project.
Error 4 'C:\Library_2\template.xls' could not be found. Check the spelling of the file name, and verify that the file location is correct.
I would like the type to refer to the original "Brokernet.template.xls", so I am trying to provide the complete path to it, but
type modelforexcel =
FSharpx.ExcelFile<__SOURCE_DIRECTORY__+#"Brokernet.template.xls", "Brokernet", true>
does not work, as I guess it is not a literal (?)
But 'obviously' defining this literal does not work either
[<Literal>]
let a = __SOURCE_DIRECTORY__+#"Brokernet.template.xls"
Are there any way to define such a 'dynamic literal' ?
edit
Interestingly enough, if I define my type inside a module in the first library
module Load =
[<Literal>]
let a = #"Brokernet.template.xls"
type modelforexcel = FSharpx.ExcelFile< a , "Brokernet", true>
Then the type is not 'regenerated' upon using the first library in the second one, and the type provider does not complain about the file being absent of the root of the 2nd library.
This sheds profound insights in the compilation model of F# that are probably best exposed by masters. I'd just say, as a rough man, that "the code is in modules"
PS : I guess thats one more problem which would be solved by a proper staged compilation.
As being shown in the comments, using relative paths e.g. #"..\Library_1\Brokernet.template.xls" solved the problem.

Resources