When I try to compile the example from the front page of the go language website with the 6g compiler, I get this error:
hello.go:5: syntax error near "<string>"
I search on Google reveals that a few people have experienced this, but I have found no solution. The answer always seems to be: "It's works for me, you must do something wrong".
I've found a description of the problem that dates back 5 months, so I suspect it's not a problem with the particular build of go that I'm using. Besides, I've tried pulling a newer version, and the problem persists.
The source code in question:
package main
import "fmt"
func main() {
fmt.Println("Hello, 世界")
}
Btw, I'm saving the source code as UTF-8 with LFs for newlines. It shouldn't be a text encoding issue. I've also tried with different strings not containing "exotic" characters
Try "which 6g".
You might be picking up an old build.
At least that was my case. I had an old 2009 build in my path.
After fixing the environment it worked.
Your special characters in there might cause conflicts with the compiler. Try to save this code in multiple ways using notepad (ANSI, UTF-8), and see whether the compiler will take any of them.
Problems like this are typical when there's an encoding issue.
If you're on Windows, an editor like Notepad++ can convert between many encoding formats, so I'd suggest converting your source to UTF-8 without BOM and then recompile.
If you're on Linux, there's a guide available showing you how to determine and change a document's encoding.
Related
fmt.Printf("hello") was working great with intellisense
but suddenly in every go file my fmt.P .. suggestion becomes this
and this
I am not getting "fmt.Printf()" suggestions anymore and getting stuck with those "const", "func", "import", "type", & "var".. what is happening? (Though it is not suggesting fmt.Printf() but it's still working). how can I get normal suggestions by intellisense like previous?
I tried disabling GO official extension, then it got fixed but also I lose all autocomplete/suggestion feature. a go file in root directory is working fine but other files inside packages are showing this kinda problems. Please help
After searching a lot I couldn't find exact problem and solution. And somehow I saw some were facing "case-insensitive import collision:" and it was due to upper-case and lower-case mixture usage in filename. I remembered it seeing in my package name (though this error vanishes sometimes and ignored it as code execution was working) and tried renaming my filename from "sequenceUtils.go" to "sequence_utils.go" and boom ..! intellisense started working ..! though my colleague was working with same filename and he wasn't facing problems..
I think the problem should be properly identified..!
Various things are different in 1.0.136, e.g. running code with ctrl-enter has all sorts of strange behavior in an RMarkdown document, running code that has a syntax error somehow leads to all of the code being run in a block above (below?) the wrong code, etc. Sorry for not posting an MWE, but at the moment I just want to know if anyone is aware of these new "features" and if so how they can be turned off or better yet how I can just downgrade to the previous version of RStudio (which I can't currently find on the website).
Yes they changed some default settings that were present in the old interface.
Change the setting in markdown next to the knit button, from:
Chunk Output Inline -> Chunk Output in Console
Pictured here.
You can probably mess with the the Global Setting->Rmarkdowns under Tools to get it back the way it was before, but this was the fastest way for me.
We are using QT 5.5 successfully throughout our VC++ projects in VS2015.
Now, i am adding i18n thereto, using QTs Linguist tools to create my strings 2b translated and the resulting .qm files. I load the files through QTranslator object, the translation itself seems to work, but they get displayed wrongly.
As german is my mother tongue, I have to type several umlauts, beside any other special unicode-characters I definitely want to support.
As en example, I use linguist to translate over to über, and the resulting text in my application reads über. What I can surely recognize as an encoding mismatch.
I already had a look on the i18n example, which displays correctly for all of the provided languages, so I right now do not know what's wrong after I checked all file encodings.
Anyone any ideas? Or even has the same problems? Or had them but solved? Any suggestions were greatly appreciated!
This seems to be a Windows-specific problem.
Instead of using QString.toStdString() (what breaks the correct string), better use QString.toLatin1() at least for the languages to support yet.
How to generate tags file for Go source
In mac, I installed exuberant ctags , and tried the below command in source directory
ctags -f gosource.tags -R `pwd`
But, it doesn't consider *.go files. Do I have to use -h option? But, isn't it only for header files, as per the manual?
Please give me the correct command so that I can use the tags file with vim. I also prefer absolute path so that I can keep the file anywhere
Thanks.
Edit:
I assumed current ctags support Go, seeing http://groups.google.com/group/golang-nuts/browse_thread/thread/3a4848db231b02c9.
but, http://ctags.sourceforge.net/languages.html desn't have go listed.
Add the following to ~/.ctags
--langdef=Go
--langmap=Go:.go
--regex-Go=/func([ \t]+\([^)]+\))?[ \t]+([a-zA-Z0-9_]+)/\2/d,func/
--regex-Go=/var[ \t]+([a-zA-Z_][a-zA-Z0-9_]+)/\1/d,var/
--regex-Go=/type[ \t]+([a-zA-Z_][a-zA-Z0-9_]+)/\1/d,type/
(From http://go-wise.blogspot.com/2011/09/using-ctags-with-go.html)
--langdef=Go
--langmap=Go:.go
--regex-Go=/func([ \t]+\([^)]+\))?[ \t]+([a-zA-Z0-9_]+)/\2/f,func/
--regex-Go=/var[ \t]+([a-zA-Z_][a-zA-Z0-9_]+)/\1/v,var/
--regex-Go=/type[ \t]+([a-zA-Z_][a-zA-Z0-9_]+)/\1/t,type/
Does indeed work with ctags 5.8. One slight change from the previous poster, ctags requires unique 1-char types at the ends of the regex lines. Thus /d,func/ should read /f,func/ intuitively. This allows the ctags to distinguish between and identify types, allowing ctags --go-types=fvt i.e.
I saw your post, bumbled around a bit trying to find a good tool for the job, tried ctags, and ultimately was unsatisfied. I wrote a program 'gotags' in Go that generates a ctags file for Go code. Its better than the current ctags support because, for example, it tags struct field names as well as the struct name itself. You can get it here: https://github.com/necro351/gotags.
Its a nice short simple Go program because it uses the standard library parser and has no extra features other than good Go parsing and tagging. Just check it out (or go get it) and do a go install. Also, if you have any suggestions or ideas about improving it, let me know.
Edit: I am an active Gopher and so will be updating this tool over time and as I use it.
Edit: I am not actively developing Go anymore. But my tool is very short and pretty much works as is so it should "just work" :)
universal-ctags supports Go. It's the successor of exuberant-ctags and works perfectly fine. See here for the man pages.
Check Go Dashborad/Projects, section "Tag Generators". Status of those tools is not known to me.
Edit 2011-11-22: Latest egotags fork announced today (cyclic reference possible ;-)
Ghostscript 9.0 doesn't support validation of the digital signatures in PDF document when doing PDF to image conversion. Instead, there's a question mark on the digital signature, and Ghostscript reports "Sig is not yet implemented". I'm thinking to modify the source code to get rid of the question mark, but I don't have any ideas to where I should modify in thesource code. Could any one give the hints for that? Any response will be appreciated highly, thanks.
Have you already tested the very latest release (which is v9.02)? If so, have you also tested the current 'HEAD' revision of their source code?
If your problem persists with these versions, the preparatory thing to start with is to download the (current, which is v9.02) Ghostscript source code from here or even check it out from their Git repository.
What you are trying to do can only be located in one of the following two modules of the Ghostscript source code:
the (PDF) interpreter
the (image) output devices
So I would first recursively grep the sources for "not yet implemented" or similar expressions, taking into account that there may even be line breaks within the string. (***I doubt the quote you gave in your initial version of the question is accurate, because it contained at least one typo.)
If I didn't find anything in the first step, I'd get into touch with the Ghostscript developers themselves. They usually hang around in IRC on Freenode, channel #ghostscript. In general they are a very friendly and helpful bunch, and they'll surely be able to give you some hints about how to solve your problem if you know how to ask...