How to access unexported functions in the same package but from different file - function

I am trying to build godoc.org source code in my local to make some changes. My working directory is /Users/Dany/go/src/github.com/golang/gddo. In gddo-server package there several files. One of the go file uses a function from another file which is in the same package but unexported. It is throwing Undefined: <function-name> exception.
Folder is structure is,
golang/gddo/
gddo-server
main.go
crawl.go
How do we use unexported function from the same package in a different file? Could anyone help me with this. Also if anyone has any idea about how to build godoc.org code?

Source files of the same package can refer to identifiers defined in any of the source files without any effort. If they are in the same folder and if they have the same package declaration, you can refer all package-level exported and unexported identifiers as if all would have been defined in one file.
See Spec: Packages:
A package in turn is constructed from one or more source files that together declare constants, types, variables and functions belonging to the package and which are accessible in all files of the same package.
And Spec: Package clause:
A set of files sharing the same PackageName form the implementation of a package. An implementation may require that all source files for a package inhabit the same directory.
One thing to note: your example seems to be the special main package. If you want to run it with go run, you have to enumerate all the source files.
To run your example with go run, navigate to the gddo-server folder and type:
go run background.go browse.go client.go crawl.go graph.go main.go play.go template.go
Or simpler if you first build it. Navigate to the gddo-server folder and type:
go build
This will generate a native executable binary in the same folder. To run it type: gddo-server (on Windows) or ./gddo-server (on Linux).
Or you can install it with go install which will place the result executable binary in your $GOPATH/bin folder.

Related

How can I use functions defined in other Code Repository?

I have a set of functions defined in a Code Repository (A). Code Repository A has the following structure with my class objectController defined in 'objectController.ts' :
src
index.ts
objectController.ts
How can I use the functions defined in objectController.ts in another Code Repository (B)?
I would actually recommend working within the same Code Repository where possible, but this may in some cases be unavoidable
Steps for setting up the source repository:
Modify package.json to publish the package properly.
Set a new name field to define what the package name should be in other repos. It might make sense to prefix this with something use case specific to avoid conflicts.
Update the main field to "dist/Functions.bundle.js" and the types field to "src/dist/index.d.ts".
(Optional) Set a description.
Commit the package.json changes and publish a tag on this repository.
Validate that the checks pass.
Steps in the destination repository:
Import your source repository.
Go to Settings > Artifacts.
Click + Add
Select your source repository and import it as a backing repository.
Go to package.json. Under dependencies, add the package name you set in the Source repository above (step 1.1), and set the version to the tag that you published (step 2).
Import any exported classes from your package and use them in your code as normal.
Note : You'll have to restart Code Assist after step (2) above in order to have the newly added package show up properly.
Caveats
All code must live in index.ts in the source repository for this to work.
Unit tests in the destination repository that use the imported package will fail. (This may actually be fixable, but I didn't get it to work)
You need to ensure that you have imported all Ontology objects and relations that the source repository relies on into the destination repository.
I also ran into a typing issues in my destination repository.
Error Message:
Errors:
src/index.ts(6,21): error TS7016: Could not find a declaration file for module '{module_name}'. '{redacted}/repo/functions-typescript/node_modules/{module_name}/dist/Functions.bundle.js' implicitly has an 'any' type.
Try `npm install #types/{module_name}` if it exists or add a new declaration (.d.ts) file containing `declare module '{module_name}';`
Solution:
Create a folder called typings.
Create a file within typings called index.d.ts.
Declare the module as shown below in the file created in (2) index.d.ts.
declare module '{module_name}';
Add the path to the file created in (2)index.d.ts in tsconfig.json under the typeRoots element.
"typeRoots": [
"./typings",
"./node_modules/#types/"
]

Difference between tsconfig.json and tsconfig.app.json files in Angular

I'm a newbie in Angular. I used angular-cli to learn about angular and I found the files tsconfig.json and tsconfig.app.json. Both of these are typescript related and I found this link useful.
But why two such files has been used? Why can't the configurations in these two files be combined in one file? Please help me figure this out.
there is nothing that prevents you from getting rid of the tsconfig.app.json. it's just an additional config file that allows you to adjust your configuration on an app basis. this is e.g. useful when you have multiple apps in the same angular-cli workspace.
you could have the root folder with the tsconfig.json and then a sub folder app-a with a tsconfig.app.json file and another app in the sub-folder app-b with it's own tsconfig.app.json, which contains a variation of the global configuration.
the difference in configuration could e.g. be the output directory outDir or the includes or excludes used.
The difference is that tsconfig.app.json is a file that is related to the Angular App in particular, while tsconfig.json is a more general file that contains general typescript configuration. It's especially useful when you have a micro frontends system, where there are multiple Angular subprojects, each of them with its own tsconfig.app.json configuration. But if you want you could perfectly merge these two files into one, actually you surely noticed that tsconfig.app.json contains the line:
"extends": "./tsconfig.json"
which means that the whole App uses the configuration stated in tsconfig.app.json plus the configuration in tsconfig.json
Just want to add one more point.
It seems the tsconfig.app.json(App specific one) will override the tsconfig.json(global one).
My issue was with the types declaration from node not in scope of my Angular project and I was getting compile errors saying Buffer is not found.
I first added the types declaration in tsconfig.json thinking it will take effect in every app.
But I had to add it to my app-specific tsconfig.app.json file for it to take effect on my app.

The connection "C:\\<path>\\*.txt" is not found. This error is thrown by Connections collection when the specific conn element is not found

I developed a SSIS package that creates several .txt files. These files are zipped and then the .txt files need to be removed. Using a foreach file enumerator, I loop through all the .txt files for a specific folder. The folder is retrieved from a variable in configuration and looks something like: C:\Folder\
The foreach loop uses: *.txt to gather all .txt files, does not traverse subfolder and uses the full qualified name.
In the Variable Mappings the "FileName" variable gets filled with the 0 index.
Within the foreachloop I use a File system task.
This task removes the .txt files which are generated before, using the FileName variable that is filled in the loop.
On the development machine this runs like a charm. All greens, no problem at all. Now I copy the package and the configuration file to the test environment. A basic version without the file removing was running perfectly fine here. I replaced the package. Nothing big.
Now I run the SQl Server Agent Job and it starts running. I can see all the text files appearing, and disappearing after it created the zipfiles. However, when all files are removed the package results with errors. Namely the error shown above in the title.
I tried looking for the connectionmanager that might have been removed
Looked for connection managers named in the config that don't exist in the package.
No such thing found. Annoying part is that the package is fully functioning, but still results with the error.
EDIT: I noticed that if I run the package using the execute package utility with the dev. config it gives the same errors.
Hopefully someone is able to help me out.
Thanks in advance!
I managed to "fix" the issue. Remove the File System Component responsible for deleting the files. Then add it again and configure it again.
I think this happens if you accidentally change General parameters before changing the Operation parameter. It holds the metadata to irrelevant parameters and upon execution says: "Wait, you defined this parameter but I don't need it, but I'm checking for it anyway, and it's not there!"
It's a bug for sure

How can I import JSON data from a REST API into BIRT?

I want to use BIRT to generate reports against data that comes from a JSON based REST API. How can I import this data?
The process for doing this is described at http://developer.actuate.com/community/forum/?app=blog&blogid=45&showentry=471, but it turns out that there are a few important steps missing. I'll fill in a few blanks here.
The original instructions describe creating a Scripted Data Source, with an "open" script that makes use of the com.actuate.json.JSONParser class. First, it is important to realise that this class is not part of BIRT, and needs to be manually added (along with any dependencies).
The download provided by the original instructions provides the com.actuate.json.JSONParser class, but leaves it up to you to source the dependencies. To make things easier I have reimplemented the JSONParser library in Maven, which will then download and package the dependencies for you. It also includes some bug fixes and enhancements like GZIP compression support. You can get the Maven project from https://github.com/mcasperson/birt-jsonparser, and to build the JSONParser library and package the dependencies, run the command
mvn clean package dependency:copy-dependencies
This will result in the birt-jsonparser-0.0.1-SNAPSHOT.jar file being created in the target directory, and all the dependencies copied into the target\dependency directory. Copy all of these JAR files into the {BIRT_INSTALL}/plugins/org.eclipse.birt.report.viewer_{BIRT_VIEWER_VERSION}/birt/scriptlib directory to allow the JSONParser class to be accessed from within your BIRT report.
If you want to debug your report, these JAR files will also have to be referenced in the Debug profile.

Zip the contents of a folder in SSIS

I am trying to zip the contents of a Folder in SSIS, there are files and folders in the source folder and I need to zip them all individually. I can get the files to zip fine my problem is the folders.
I have to use 7.zip to create the zipped packages.
Can anyone point me to a good tutorial. I haven't been able to implement any of the samples that I have found.
Thanks
This is how I have configured it.
Its easy to configure but the trick is in constructing the Arguments. Though you see the Arguments as static in the screenshot, its actually coming from a variable and that variable is set in the Arguments expression of Execute Process Task.
I presume you will have this Execute Process task in a For Each File Ennumerator with Traverse SubFolders checked.
Once you have this basic setup in place, all you need to do is work on building the arguments to do the zipping, how you want them. A good place to find all the command line arguments is here.
Finally, the only issue I ran into was not providing a working directory in the command line arguments for 7zip. The package used to run fine on my dev environment but used to fail when running on the server via a SQL job. This was because 7zip didn't have access to the 'Temp' folder on the SQL Server, which it uses by default as the 'working directory'. I got round this problem by specifying the 'working directory as follows at the end of the command line arguments, using the -ws switch:
For e.g:
a -t7z DestinationFile.7z SourceFile -wS:YourTempDirectoryToWhichTheSQLAgentHasRights