panic: runtime error: index out of range #32
Comments
|
I forgot to point out that most hugo error messages were indeed referring to goorgeous |
|
Can you share a snippet of a panic you get? If your html files are in your output folder those will get overwritten but it won't be overwritten if it's in your content folder. |
|
Also, is your Hugo source a public repo? I'm happy to help debug it so we can help others port or work around it who did the same thing. |
|
Sure,
Below is a snippet.
But, I should emphasize that my .org files have a number of
org-mode
HTML exports, which I wouldn't expect your code to handle.
I'll try a clean setup with no html exports soon, just to be sure
plain
vanilla org works for me.
Thanks.
cress> hugo
Started building sites ...
panic: runtime error: index out of range
goroutine 118 [running]:
github.com/spf13/hugo/vendor/github.com/chaseadamsio/goorgeous.OrgHeaders(0xc4201ee870,
0x31, 0x40, 0xc4204da880, 0xc4203ac978, 0xc4203ac970)
/Users/bep/go/src/github.com/spf13/hugo/vendor/github.com/chaseadamsio/goorgeous/header.go:44
+0x6f8
github.com/spf13/hugo/parser.HandleOrgMetaData(0xc4201ee870, 0x31,
0x40, 0xc4202e9ce0, 0x1011fbd, 0xc4205f71f0, 0x1752287)
/Users/bep/go/src/github.com/spf13/hugo/parser/frontmatter.go:197
+0x3f
github.com/spf13/hugo/parser.(*page).Metadata(0xc4204da840,
0x1752287, 0x1007, 0x1e00, 0x0)
/Users/bep/go/src/github.com/spf13/hugo/parser/page.go:97
+0xbd
github.com/spf13/hugo/hugolib.(*Page).parse(0xc4205f6d80,
0x1a89560, 0xc4204f3470, 0xc420110a00, 0xc4204f4da1)
/Users/bep/go/src/github.com/spf13/hugo/hugolib/page.go:1393
+0x189
github.com/spf13/hugo/hugolib.(*Page).ReadFrom(0xc4205f6d80,
0x1a89560, 0xc4204f3470, 0xc4205f6d80, 0x0, 0x0)
/Users/bep/go/src/github.com/spf13/hugo/hugolib/page.go:737
+0x43
github.com/spf13/hugo/hugolib.basicPageHandler.Read(0x0, 0x0, 0x0,
0xc4204f8280, 0xc420110a00, 0xc4201e8300, 0xc4204f4dbd, 0x3,
0x1006c01)
/Users/bep/go/src/github.com/spf13/hugo/hugolib/handler_page.go:41
+0x8c
github.com/spf13/hugo/hugolib.(*orgHandler).Read(0xc4201e8300,
0xc4204f8280, 0xc420110a00, 0xc4202e9ed8, 0x158bc2f, 0xc4204f4dbd,
0x3)
<autogenerated>:307 +0x6e
github.com/spf13/hugo/hugolib.(*MetaHandle).Read(0xc4205d4a00,
0xc4204f8280, 0xc420110a00, 0xc4203b3740)
/Users/bep/go/src/github.com/spf13/hugo/hugolib/handler_meta.go:51
+0x133
github.com/spf13/hugo/hugolib.readSourceFile(0xc420110a00,
0xc4204f8280, 0xc4203b3740)
/Users/bep/go/src/github.com/spf13/hugo/hugolib/site.go:1239
+0x70
github.com/spf13/hugo/hugolib.sourceReader(0xc420110a00,
0xc4203b37a0, 0xc4203b3740, 0xc4203aca70)
/Users/bep/go/src/github.com/spf13/hugo/hugolib/site.go:1232
+0xa8
created by
github.com/spf13/hugo/hugolib.(*Site).readPagesFromSource
/Users/bep/go/src/github.com/spf13/hugo/hugolib/site.go:1157
+0x24e
cress>
Chase Adams writes:
… Can you share a snippet of a panic you get? If your html files
are in your output folder those will get
overwritten but it won't be overwritten if it's in your content
folder.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the
thread.
--
L. Larrabee Strow
UMBC Physics Department
Email: strow@umbc.edu
Cell: 724-288-6933
|
|
Hi,
I've done some further tests. I can get your org conversion to
"complete" for some simpler files, but there are many many
problems. I
really do appreciate the attempt, but I really hope hugo can be
modified
to not wipe out my web site creation methodology.
I suspect you had to just implement the standard org syntax. Many
details are not working:
1. macros, like below
#+LINK: hpub https://asl.umbc.edu/pub/strow/figs/
2. This next one is a killer. My source code has CR/LF's which
you "respect", while standard orgmode exporter only responds to
blank lines to create a paragraph. This is a killer!
3. Images: [[url for image]] should in-line the image. You
provide
just the link to the image.
4. You don't provide functionality to org keywords, like
#+TOC: headlines 2
etc. etc.
I realize doing what I want would force you to reproduce the
complete
org exporter, I gigantic job.
The org html exporter is very very good, and it's latex exporter
is even
better. The files served up by my website can be translated to
latex
with no change (although I cheat a lot, using directives telling
org to
do one thing for html export, another for latex export, mostly for
figures). But, having a single source is really important.
I'd be happy to just ignore this new hugo functionality, but it
makes it
impossible for me to create my web site as I have done in the
past. Let
me explain:
Present Methodlogy:
Create legal .org files that produce good html and .tex (and from
that
.pdf). Then, and this is key, I export (sitting in content/) the
.org
to html. (I put yaml inbetween begin_export html, end_export).
hugo
then sees the .html file, and does all the right things, including
reading and using the yaml. It works perfect. By the way
exporting for
each .org file is just not a big deal, the keystrokes are:
Ctrl-e Ctrl-b h h
Crtl-e calls the exporter
Ctrl-b tells it to NOT add any orgmode html header crap
h h just says produce an html file (don't try to open it, etc.)
Now, with the new org backend in hugo, I cannot use any of my
earlier
approach, since hugo sees the .org file and wipes out my .html
file I
created from emacs (in org mode).
I suggest the following (and I know nothing about hugo internals,
so I
do not know if these suggestions can work):
1. A config file option (config.toml for ex.) with something like
[org]
invoke = false
*AND*, but not INSTEAD of the above (so I can try out your org
backend)
if hugo sees and .org file, and there is an .html file there as
well
with the same prefix, DO NOTHING. That way if I don't set
"invoke =
false" hugo will process org files that don't have matching html
files.
I'm really sorry, but I have put tons and tons of work into my
website,
have a REALLY FULL FEATURED capability of html and pub quality
latex.
I would like to bring this up to the hugo developers, but since
you are
one, maybe that is not needed.
Maybe someone could do a hugo build with the invoke = false I
could try?
I really don't want to be stuck using an old version of hugo
forever.
Again, I appreciate your efforts!
Larrabee
Chase Adams writes:
… Also, is your Hugo source a public repo? I'm happy to help debug
it so we can help others port or work
around it who did the same thing.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the
thread.
--
L. Larrabee Strow
UMBC Physics Department
Email: strow@umbc.edu
Cell: 724-288-6933
|
|
Are your .org files in your This way you can generate your Anything that goes in the contents directory of a hugo project should be considered a file that is a src file. |
|
Well I guess that would work but would be a real pain for me constantly
moving files. I'd say that is a hack. how hard would it be to just have
an option to ignore your org 2 HTML converter? That will just add a level
of confusion for my group members who already struggle with Hugo and org.
I just think it is wrong to break something that worked fine for years.
Larrabee
On Mon, Mar 13, 2017 at 3:15 AM Chase Adams ***@***.***> wrote:
Are your .org files in your content directory? Since they're not truly
being used by Hugo and you're already doing them by hand, if you put them
in another directory that Hugo doesn't watch, it won't attempt to render
your org files and overwrite your intermediate or your resulting HTML. An
example:
org-content/
-- *.org # files
content/
-- *.html # emacs generated html files
public/
-- *.html # final html file
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#32 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACTPL1nl2y8M29DuBFKlonkLvJJYCOkLks5rlOz6gaJpZM4MW-EY>
.
--
…------------------------------------------
L. Larrabee Strow
UMBC Physics Department
Email: strow@umbc.edu
Phone: 724-288-6933
|
|
If you would like access to my web site repo, I can add
"chaseadamsio"?? as a collaborator to the github version of the
repo (not sure if that is your github identidy). I just ask you
don't publish it. This would show you a lot of legal .org files
that don't render with goorgeous. Mostly look under content/asl/
for files with graphics. This might help you in further
development of goorgeous. Note that most of my web site is hidden
(see static/asl/.*).
Larrabee
Chase Adams writes:
… Are your .org files in your `content` directory? Since they're
not truly being used by Hugo and you're already doing them by
hand, if you put them in another directory that Hugo doesn't
watch, it won't attempt to render your org files and overwrite
your intermediate or your resulting HTML. An example:
```
org-content/
-- *.org # files
content/
-- *.html # emacs generated html files
public/
-- *.html # final html file
```
--
L. Larrabee Strow
UMBC Physics Department
Email: strow@umbc.edu
Cell: 724-288-6933
|
|
Hey Larrabee, So this one thread has had me reconsidering attempting to stay in parity with org mode and instead to work on using Emacs as an exec command. I've got a working branch that I think I can PR in the next few days here: https://github.com/chaseadamsio/hugo/tree/fix-useEmacsForOrg This will allow you to use emacs as a part of Hugo rather than a go Org port, but it won't fix the issue you're having where your .org files are getting overwritten without a config change, so I can work on that. Best case scenario here is that you find that the new Emacs implementation fits your needs and makes it better than the workflow you have now by automating the export dispatcher you're running and potentially removing some friction from those who are struggling with hugo + org in your group. I'd like to help you figure out a good workflow so that if you decide not to use the Emacs route that I end up requesting (I'll cc you on the PR too so you can give any feedback or concerns you have and worst case scenario we remove emacs from master and I'll just maintain my own fork because I don't like doing anything manually). Worst case scenario, with the workflow I'm suggesting, you should only need to move files once: from |
|
Also, if you let me know which release type you install from if you're not comfortable installing from source, I'd be happy to generate the relevant binary/executable and put it in the releases of my hugo fork so you can test it out before I PR. |
|
Wow, looking at this thread via github shows me my mu4e emacs-based emailer is buggering up CR/LF. Oh well. My reaction to using Emacs as an exec is fine, it it works. But that is a tricky integration that is bound to cause issues. I am a strong believer in keeping things as simple as possible. There is nothing easer than what I do now, "C-e C-b h h" in emacs and I am done. Not sexy, but very easy. I'd be very happy to test, though. I'm not sure of this, but updating my html export to path might also be a pain? Don't I have to do that on a directory-by-directory basis (I'm on thin ground here, need to research). This is all great, but wouldn't a simple config to tell hugo to not use your org converter solve everything? 99.9% of users would know about it, just the few (or only) user who has been using hugo with org for years. (FYI, my web site is a lot bigger than it appears, most is hidden.) I usually just download the hugo binary. But, I have brew set up if that is usuable? I could try to install from source (Mac OS sierra with X-code, etc.). I'm slightly competent at UNIX like installs (./configure make, finding missing libs, etc.). |
|
Hi,
We had a discussion a while back with regard to goorgeous breaking my
workflow. (I want the .org files to be in my repo, and create .html
with emacs org-mode, works very well.)
You seemed to hope that the hugo maintainers might introduce a config
file flag that would tell hugo to ignore .org files.
Looks like that has not happened? Any idea if they will do this in the
future?
I was quite taken aback by the attitude that since hugo is not V1.0,
maintainers can do as they please to break the code.
I had such a nice way to use hugo, worked every time with beautiful
html, and now I cannot upgrade.
You were quite considerate of my issues, so just hoping you might be
willing to try to push them to put in this flag?
Thanks in advance,
Larrabee
Chase Adams writes:
… Hey Larrabee,
So this one thread has had me reconsidering attempting to stay in parity with org mode and instead to work on using Emacs as an exec command. I've got a working branch that I think I can PR in the next few days here: https://github.com/chaseadamsio/hugo/tree/fix-useEmacsForOrg
This will allow you to use emacs as a part of Hugo rather than a go Org port, but it _won't_ fix the issue you're having where your .org files are getting overwritten without a config change, so I can work on that.
**Best case scenario here is that you find that the new Emacs implementation fits your needs and makes it better than the workflow you have now** by automating the export dispatcher you're running and potentially removing some friction from those who are struggling with hugo + org in your group.
I'd like to help you figure out a good workflow so that if you decide not to use the Emacs route that I end up requesting (I'll cc you on the PR too so you can give any feedback or concerns you have and worst case scenario we remove emacs from master and I'll just maintain my own fork because I don't like doing anything manually).
Worst case scenario, with the workflow I'm suggesting, you should only need to move files once: from `content` to `org-content` and then update your html export path to export to `content`. Hugo will build your `public` from there, so you shouldn't need to do anything.
--
L. Larrabee Strow
UMBC Physics Department
Email: strow@umbc.edu
Cell: 724-288-6933
|
|
@strow I'll take a stab at it Friday (first PTO in a while) and cc you on the PR. |
|
@strow sorry for the VERY long delay, but I've overhauled Goorgeous to lex > parse > transform and I think you'll find that you won't run into these out of range issues anymore. I'm going to leave this issue open and I'll add another comment once the update is merged into Hugo, maybe you can let me know if it's working for you as it should. |
|
So it turned out that I had a branch I was getting ready to PR into Hugo this week that fixed this, but it looks like @niklasfasching PR'ed a new org parser, so I'm closing all the issues here, deprecating and archiving goorgeous. |
There are probably many good reasons for this error. But I wanted to introduce my use of hugo and ormode so I can understand how to port to goorgeous. I have been using hugo for 2 years with only org-mode source files. How? I just create the .html directly (yes, by hand) in emacs from the .org source file using the orgmode html exporter. It works very well, but, it is a pain in that orgmode has a different concept of "/" than hugo for the underlying filesystem. That forced me to often use absolute rather than relative links for images, etc. My guess is that most of my issues with this error is my use of embedded HTML exports in some org files, I can' imagine goorgeous will parse them. So, I am not really asking for specific help.
What I am wondering, I assume Hugo will now see an .org file and create .html. If the .html already exists (from me exporting it directly from emacs using the orgmode exporter), will hugo overwrite that file? I'm sure I can experiment with that.
I am excited to try goorgeous, and I hope it solves problems I have using ormode with Hugo, but it does make it impossible for me to use V0.19! My punishment for not doing things the "hugo" way.
The text was updated successfully, but these errors were encountered: