I am building an application package in Mathematica. The application contains multiple packages and refers to other application packages
To set everything up, I have used and followed the application packages instructions of the help section of workbench which is also available at:http://reference.wolfram.com/workbench/index.jsp?topic=/com.wolfram.eclipse.help/html/tasks/applications/introduction.html under the Packages and Applications subsection but...
I have implemented and tested single package application packages and the all seem to work fine.
My Multiple packages and application is not working fine at this moment because of the following identified problems:
a) the main package of the application calls functions implemented in the extra packages, but these function seem not to be recognized there. I have tried even to explicitly call them in the main package using the Needs command at the beginning of the package with no avail. *What am I doing wrong?*The extra packages are all in the application folder as the help directs to do.
More specifically:
The main package and the application are named OptMainFuncAll` so the main package OptMainFuncAll.m begins with
BeginPackage["OptMainFuncAll`"]
The extra packages IntermFunct.m and VolCandExt.m begin with:
BeginPackage[ "OptMainFuncAll`IntermFunct`"]
BeginPackage[ "QuadOptMainFuncAll`VolCandExt`"]
Yet functions defined in IntermFunct.m and VolCandExt.m are are unknown when called for in
OptMainFuncAll.m -- What am I doing wrong?
Ihave even tried explicitly declaring
Needs[ "OptMainFuncAll`IntermFunct`"]
Needs[ "QuadOptMainFuncAll`VolCandExt`"]
at the beginning of OptMainFuncAll.m and it has not solved my problem
In addition I have made a reference to a second application package (BasicSym )and workbench shows it as referenced, but its functions also seem unknown in OptMainFuncAll.m .
I have also tried beginning OptMainFuncAll.m with
BeginPackage[{OptMainFuncAll`, BasicSym`}]
and it did not work; the console at run times returns the message:
BeginPackage::cxt: Invalid context
specified at position 1 in
BeginPackage[{OptMainFuncAll,
BasicSym}]. A context must consist of
valid symbol names separated by and
ending with `. EndPackage::noctx: No
previous context defined.
I am sure I am making some stupid application package developer mistake, but I can't seem to put my hand on it.
If you can just tell me the exact package declarations in BeginPackage[?] for the main package, the extra packages and the referenced packages with the names I provided here for everything to work smoothly, i'd greatly appreciate.
Please Try:
BeginPackage["OptMainFuncAll`",
{"BasicSym`",
"OptMainFuncAll`IntermFunct`",
"QuadOptMainFuncAll`VolCandExt`"}
]
The current package name is the first argument, while the second argument is a list of package names (contexts) that it will depend upon.
Related
I am starting to learn Go following this Microsoft tutorial. The program runs and displays the result as in the tutorial, but the two problems that it is marking me cause me concern. I do not want to continue without understanding what this detail is due to, someone who has also happened to it, or who helps me to know what it is due to, I will be very grateful.
package main
import (
"fmt"
"github.com/x0z38/calculator"
"rsc.io/quote"
)
func main(){
total := calculator.Sum(3, 5)
fmt.Println(total)
fmt.Println("Version: ", calculator.Version)
fmt.Println(quote.Hello())
}
I leave you the image where the error is marked in red lines in the editor:
I leave the image of the two problems:
According to what I understood is that it does not find those files in any of the mentioned paths, but both files if I have them inside this path: C:\Projects\Go\src.
My GOPATH environment variable is: C:\Projects\Go
Golang has two ways to manage dependencies: old and new. Switching between them is usually done automatically.
Visual Sudio Code tries to check for dependencies using the old way. But I see you have go.mod and go.sum files which means you are using the new way (the Golang module system).
The environment variable GO111MODULE is used to switch between dependency control modes. It has 3 values: auto, on, off. The default is auto.
What you see is just a syntax highlighting problem and not a compilation or execution error.
What I have learned is that you want VS Code (or gopls) to correctly identify a multi-module project. Please refer to this (your are using Go1.18).
And more about go modules.
And go workspace.
Hope those can help you.
Ok this is what I did:
First: Run go mod tidy as suggested by Mushroomator in my root project, and it didn't work
Second: remove the GOPATH environment variable, since as JimB commented it is no longer used, and it didn't work either.
Now, this is where I feel a bit confused, because maybe I did what they asked me to do but I don't know how to explain it.
So, it works and no longer shows a syntax error. Delete the GOPATH environment variable, SET GOMODULE111=on, and take out the Projects/Go directory where I have all the files and put it on the desktop and mark this syntax error:
Google
Todo
Imágenes
Noticias
Shopping
Vídeos
Más
Herramientas
Cerca de 1,260,000,000 resultados (0.39 segundos)
Español
Inglés
Now, as you can see, I open VS Code directly in the helloworld directory, and the syntax error disappears, but I wanted to have it open directly from the src directory to see everything I've learned so far:
I have written a BPF program that I can install using gobpf, i.e. using their bcc tooling. While this works alright from a main package, this breaks as soon as I move it into a package for importing it as a module.
To clarify: It works with all code in package main, but as soon as I rename the package and move the main() to cmd/command.go it stops working with go run complaining that it can't find an included lib (bcc/proto.h). Incidentally, this is the same error as I always got when running gcc on my .c file without any indication I want to use BPF (the part that gobpf did for me, until I moved its invocation to a module...).
I realize this is question very specific and sits in a weird place between Go, CGo, the way C and C++ handle includes, BPF, and bcc, but I am at a loss here.
You can check out my code here https://github.com/bwNetFlow/bpfdump if that helps. It needs bcc installed in addition to go run doing its thing. Basically:
HEAD is the modularized version that does not work (go run cmd/dump.go)
HEAD~ is my initial experiment that does work (go run bpfdump.go) (you'll get an permission error as user, which is fine as it has compiled anyways).
PS: I think it might have to do with this (rather creative?) construction of bcc/proto.h: https://github.com/iovisor/bcc/blob/master/src/cc/exported_files.cc
I'm developing a tiny project that has a single package main. AFAIK, best-practice for small Golang binary projects is to have all code in a single (main) namespace, so that's what I've done.
Just curious, within a package main, is it best practice to keep functions/constants/variables exported (MyFunction) or unexported (myFunction)?
Really it doesn't matter. main packages can't be imported so whether you export them or not doesn't matter in that regard.
However if you do export them then tools like golint will encourage you to document them so maybe that's a good reason to go ahead an export them.
The most important thing is to be consistent. I prefer to name un-exported items in package main starting with lowercase even though they can't be exported. This is because it's an additional hint that these entities aren't used outside their containing package. You don't need to know that the declaration is in main to know that the thing being declared is not used externally.
I am using a class module in my project. I made an EXE of the project. But this EXE gives error when I run this on another PC... even in mine PC, if run from another folder.
I get following error - 5 - Invalid procedure call or argument.
Can somebody guide me how to use the Class module while making EXE..?
A class module is analogous to a form module or a standard module (which is called just "module") in VB6. Basically, anything that has its own code window is a module. Class modules are saved with a .cls extension.
The probable reason for your error is that you can't see the class at the point you're attempting to use it.
Your question could mean several different things. Please give me a list of all the projects (maybe you have just one, but you could have more), all the forms, all the standard modules (just called "modules"), and all the class modules you are using. That will help me understand better how to answer your question.
I want to add my own project type based on IronStudio. So,
I downloaded the source for and compiled the latest version of IronPython, then
I created a new Visual Studio Package.
I added the Templates\Projects\MyProject folders, and added a file to it, and set its property "Include in VSIX" to true.
Then modified the main Package class to be derived from IronStudio's PythonProjectPackage instead, and set the ProvideProjectFactory property:
[ProvideProjectFactory(
typeof(PythonProjectFactory),
"Django Project",
"Django Project Files (*.myproj);*.myproj",
"myproj", "myproj",
#"Templates\Projects\MyProject",
LanguageVsTemplate="MyProject")]
public sealed class MyPackage : PythonProjectPackage
And ran it. But MyProject isn't showing up in the project templates. Why not?
The generated .pkgdef file looks like this:
[$RootKey$\InstalledProducts\VSPackage3Package]
#="#110"
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"PID"="1.0"
"ProductDetails"="#112"
"LogoID"="#400"
[$RootKey$\Packages\{5cd7435c-7461-459f-80bc-c0c79e9d462f}]
#="Microsoft.VSPackage3.VSPackage3Package, VSPackage3, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a4f1577d825253f8"
"InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"
"Class"="Microsoft.VSPackage3.VSPackage3Package"
"CodeBase"="$PackageFolder$\VSPackage3.dll"
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}]
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\Extensions]
"py"=dword:00000020
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\LogicalViews]
"{7651a701-06e5-11d1-8ebd-00a0c90f26ea}"=""
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\LogicalViews]
"{7651a702-06e5-11d1-8ebd-00a0c90f26ea}"=""
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\LogicalViews]
"{7651a703-06e5-11d1-8ebd-00a0c90f26ea}"=""
[$RootKey$\CLSID\{888888fd-3c4a-40da-aefb-5ac10f5e8b30}]
#="Microsoft.IronPythonTools.Project.PythonGeneralPropertyPage"
"InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"
"Class"="Microsoft.IronPythonTools.Project.PythonGeneralPropertyPage"
"CodeBase"="$PackageFolder$\VSPackage3.dll"
"ThreadingModel"="Both"
[$RootKey$\Projects\{888888a0-9f3d-457c-b088-3a5042f75d52}]
#="PythonProjectFactory"
"DisplayName"="My Project"
"DisplayProjectFileExtensions"="My Project Files (*.myproj);*.myproj"
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"DefaultProjectExtension"="myproj"
"PossibleProjectExtensions"="myproj"
"ProjectTemplatesDir"="$PackageFolder$\Templates\Projects\MyProject"
"Language(VsTemplate)"="MyProject"
[$RootKey$\NewProjectTemplates\TemplateDirs\{5cd7435c-7461-459f-80bc-c0c79e9d462f}\/1]
#="My Project"
"SortPriority"=dword:00000064
"TemplatesDir"="$PackageFolder$\Templates\Projects\MyProject"
[$RootKey$\Projects\{888888a0-9f3d-457c-b088-3a5042f75d52}]
#="PythonProjectFactory"
"DisplayName"="IronPython"
"DisplayProjectFileExtensions"="IronPython Project Files (*.pyproj);*.pyproj"
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"DefaultProjectExtension"="pyproj"
"PossibleProjectExtensions"="pyproj"
"ProjectTemplatesDir"="$PackageFolder$\.\NullPath"
"Language(VsTemplate)"="IronPython"
[$RootKey$\NewProjectTemplates\TemplateDirs\{5cd7435c-7461-459f-80bc-c0c79e9d462f}\/1]
#="IronPython"
"SortPriority"=dword:00000064
"TemplatesDir"="$PackageFolder$\.\NullPath"
[$RootKey$\Services\{b98e41c4-581e-3532-beee-06829b683d39}]
#="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"Name"="IPythonStarter"
I just want to get the bare bones up and running so I can start overriding some functionality (like the Add New Item dialog).
Update:
Reading my initial analysis once again increases my impression that some of the required components are missing (e.g. a dedicated ProjectFactory) and/or wired up incorrectly - from the MSDN documentation of the ProvideProjectFactoryAttribute Class:
ProvideProjectFactoryAttribute declares that a package provides a project factory.
And further:
If a VSPackage declares that it provides a project factory, it should create the factory and offer it to Visual Studio in the Initialize method of the Package-derived class.
You package is declaring to provide PythonProjectFactory, but (likely) doesn't offer it to VS, rather it is offered by the IronPython package. In turn you are providing arguments within the ProvideProjectFactory attribute list which PythonProjectFactory won't know about when asked for by VS.
Consequently you should at least provide a dedicated ProjectFactory yourself as per the walkthrough, wire up the classes accordingly and see how this turns out regarding the issues outlined below.
Initial analysis:
There appear to be several issues here at first sight - have you followed any tutorial on how to do this? In case, please note that some of those easily discoverable via search engines are outdated still. Either way I'd try working through and/or comparing your result with Walkthrough: Part 1 - Creating a Basic Project System from the MSDN documentation for VS 2010; please note that even this one is claimed to be outdated a bit according to the Community Content section on the bottom of the page.
Here is what I'd look into myself given the code you present, comparing with the walkthrough on the fly for more insights:
You realized already that the duplicate fragment starting with the GUID above PythonProjectFactory doesn't make sense - this is essentially trying to register two packages at once, which, even if allowed at all syntactically (which I doubt), can't possibly work like so due to both being registered with the same GUID [cross checking with the sample file in section Examining the Template Registration confirms this suspicion, as expected there is only one such fragment].
Please note that the GUID in question is the one identifying PythonProjectFactory (as per the respective source code), see below for more on this.
[Guid(PythonConstants.ProjectFactoryGuid)]
public class PythonProjectFactory : ProjectFactory {
Given .pkgdef is a generated file the next question is where this duplication/violation stems from. When two generated artifacts end up with the same GUID the respective definition in the sources is most likely messed up somehow, usually due to copy&paste duplication. Consequently you should verify whether {5cd7435c-7461-459f-80bc-c0c79e9d462f} is defined and referenced as intended, though here might be one or two other causes as well for this, see below.
A Package class needs to be identified by a GUID and the VS wizard generates some already in Guids.cs and references it accordingly on the class definition, however, the following is missing in your fragment [cross checking with the sample fragment in section To register the project template confirms this omission as well]:
[Guid(GuidList.guidMyPackagePkgString)]
public sealed class MyPackage : Package
Likewise it appears incorrect to derive MyPackage from PythonProjectPackage but reference PythonProjectFactory still rather than providing MyFactory as well (including a dedicated GUID), because the latter tells Visual Studio the location of your project template folder [see section Creating a Skeletal Project Factory]:
While it might well be possible to simply reuse all functionality from the base class PythonProjectFactory, inheriting is likely required simply because the factory must have a dedicated GUID too (as outlined in the walkthrough) in order to properly wire up the attribute specified data.
Likely unrelated, but still suspicious is that your two code blocks don't relate, as the Package class definition specifies Django Project Files (*.myproj);*.myproj, yet the result shows My Project Files (*.myproj);*.myproj.
Have you by chance mixed this from different builds or is this really a result of a clean one?
Good luck!
This stackoverflow posting might be helpful: VS2010: VSIX installation doesn't deploy item templates inside it
If this is not what you're looking for, try to see if you're missing something around the creation of custom project templates, I believe that's where the "missing link" is:
For VS 2008:
http://blogs.msdn.com/b/webdevelopertips/archive/2008/12/02/tip-32-did-you-know-how-to-easily-create-your-own-project-templates.aspx
For VS 2010:
http://blog.reybango.com/2010/09/21/how-to-create-html5-website-and-page-templates-for-visual-studio-2010/
and on MSDN:
http://msdn.microsoft.com/en-us/library/s365byhx.aspx
and here is how to create a project
template manually:
http://msdn.microsoft.com/en-us/library/ms185291.aspx
and here is how to create a new item template in VS 2010: http://msdn.microsoft.com/en-us/library/ms247113.aspx
Hope this helps
$PackageFolder$.\NullPath may have something to do with it.