Hello world

[Davidbhodge]

I have a reasonably new version of SBCL and Slime ( both from this year at least).

Loading hh-web is ok.

winning Creating a sample project leads to a symbol conflict with SWANK. hh-web exports a symbol "ID ", also exported by SWANK-TRACE-DIALOG. I select HH-WEB::ID as the symbol .

Attempt to load the "hello world" as advised in the README yields

"SIMPLE-ERROR There is no applicable method for the generic function # when called with arguments (NIL)."

I will let you know what I find later tonight when I get back.

[hargettp]

I tried this today on SBCL 1.1.14 Ubuntu 12.04 LTS (amd64) and an updated Quicklisp. I use the "slime-helper.el" that comes with Quicklsip, so pretty certain SLIME and SWANK are provided through Quicklisp.

Can you provide additional details?

[Davidbhodge]

I used SLIME dated 2014-02-06.

SBCL is 1.1.14 on MacOSX Mavericks

Restarting slime ( i use SLIME FANCY, by the way) . I will go out on a limb and guess that you dont?

gives me the following

USE-PACKAGE #<PACKAGE "HH-WEB"> causes name-conflicts in

<PACKAGE "SWANK-TRACE-DIALOG"> between the following symbols:

HH-WEB:ID, SWANK-TRACE-DIALOG::ID [Condition of type NAME-CONFLICT] See also: Common Lisp Hyperspec, 11.1.1.2.5 [:section]

Restarts: 0: [KEEP-OLD] Keep symbols already accessible SWANK-TRACE-DIALOG (shadowing others). 1: [TAKE-NEW] Make newly exposed symbols accessible in SWANK-TRACE-DIALOG, uninterning old ones. 2: [RESOLVE-CONFLICT] Resolve conflict. 3: [TRY-RECOMPILING] Recompile templates and try loading it again 4: [RETRY] Retry loading FASL for #<CL-SOURCE-FILE "cars" "templates">. 5: [ACCEPT] Continue, treating loading FASL for #<CL-SOURCE-FILE "cars" "templates"> as having been successful. --more--

When loading the skeleton system (in this case called :cars) , starting the hTTP server and navigating to the page I get

SIMPLE-ERROR There is no applicable method for the generic function

when called with arguments (NIL). I think this is a seperate issue to

the above.

The log trace for on the console looks like this [2014-04-01 09:10:52 [WARNING]] The variable HH-WEB::PATTERN is defined but never used. [2014-04-01 09:10:53 [WARNING]] Warning while processing connection: The variable HH-WEB::PATTERN is defined but never used. [2014-04-01 09:10:53 [WARNING]] The variable HH-WEB::PATTERN is defined but never used. [2014-04-01 09:10:53 [WARNING]] Warning while processing connection: The variable HH-WEB::PATTERN is defined but never used. [2014-04-01 09:10:53 [WARNING]] The variable HH-WEB::PATTERN is defined but never used. [2014-04-01 09:10:53 [WARNING]] Warning while processing connection: The variable HH-WEB::PATTERN is defined but never used. [2014-04-01 09:10:53 [WARNING]] The variable HH-WEB::CACHE-ITEM is defined but never used. [2014-04-01 09:10:53 [WARNING]] Warning while processing connection: The variable HH-WEB::CACHE-ITEM is defined but never used. 127.0.0.1 - [2014-04-01 09:10:53] "GET / HTTP/1.1" 200 374 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36"

I have not really had time to look into it as yet - will try later this morning

Phil Hargett mailto:notifications@github.com 31 March 2014 9:27 pm

I tried this today on SBCL 1.1.14 Ubuntu 12.04 LTS (amd64) and an updated Quicklisp. I use the "slime-helper.el" that comes with Quicklsip, so pretty certain SLIME and SWANK are provided through Quicklisp.

Can you provide additional details?

— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/issues/5#issuecomment-39087591.

[hargettp]

Hmmm, actually I believe I am. Since my .emacs has this line, and the slime-helper.el from Quicklisp seems to enable slime-fancy:

(load (expand-file-name "~/quicklisp/slime-helper.el"))

So, hh-web does define the symbol "id," because its an important identifier for HTML: many tags on a page may have an "id" attribute.

I also use SBCL 1.1.14 on Mavericks.

I still wander what we're missing about your execution scenario, as I cannot duplicate this failure, but would like to do so.

You chose to resolve the conflict, then...?

Are you running this in an Emacs REPL, or directly from sbcl in a Console? I've run both, no issues.

?

[hargettp]

Is the SWANK-TRACE-DIALOG::ID symbol conflict issue specific to work you are doing?

I quickly ran (apropos "id') in my REPL (i use sbcl in inferior mode), and no such symbol appeared for me.

It's unclear to me why there would be a conflict, unless a package attempted to import both SWANK-TRACE-DIALOG and HH-WEB?

[Davidbhodge]

Hi,

It's macosx mavericks. Though I doubt it's an OS thing.

With my sbcl I preload Alexandria and a package called repl utilities. I will try this again without them in a plain vanilla sbcl and see if that makes a difference. I will actually remove slime/swank as well. The only other thing that comes to mind is doing a refresh of quick lisp libraries, installing hh-web downloaded a bunch of new libraries, so it's not unreasonable that maybe there is some minor inconsistency with something Already on my machine

The real show stopper is the fact that rendering a page fails somehow.

In the supplied template I can change the page title and that change shows however nothing else. I will let you know the results of my experiments later.

Cheers

Sent from my iPad

On 1 Apr, 2014, at 23:49, Phil Hargett notifications@github.com wrote:

Hmmm, actually I believe I am. Since my .emacs has this line, and the slime-helper.el from Quicklisp seems to enable slime-fancy:

(load (expand-file-name "~/quicklisp/slime-helper.el"))

So, hh-web does define the symbol "id," because its an important identifier for HTML: many tags on a page may have an "id" attribute.

I still wander what we're missing about your execution scenario, as I cannot duplicate this failure, but would like to do so.

Are you on Windows?

— Reply to this email directly or view it on GitHub.

[hargettp]

Interesting! Sorry, I don't have my OS X machine this week, or I could do more to reproduce.

The extra libraries you mention are interesting, so perhaps that is something.

Thank you for your persistence...I will certainly try to isolate the issue once my other machine is back.

:)

On Apr 1, 2014, at 7:51 PM, Davidbhodge notifications@github.com wrote:

Hi,

It's macosx mavericks. Though I doubt it's an OS thing.

With my sbcl I preload Alexandria and a package called repl utilities. I will try this again without them in a plain vanilla sbcl and see if that makes a difference. I will actually remove slime/swank as well. The only other thing that comes to mind is doing a refresh of quick lisp libraries, installing hh-web downloaded a bunch of new libraries, so it's not unreasonable that maybe there is some minor inconsistency with something Already on my machine

The real show stopper is the fact that rendering a page fails somehow.

In the supplied template I can change the page title and that change shows however nothing else. I will let you know the results of my experiments later.

Cheers

Sent from my iPad

On 1 Apr, 2014, at 23:49, Phil Hargett notifications@github.com wrote:

Hmmm, actually I believe I am. Since my .emacs has this line, and the slime-helper.el from Quicklisp seems to enable slime-fancy:

(load (expand-file-name "~/quicklisp/slime-helper.el"))

So, hh-web does define the symbol "id," because its an important identifier for HTML: many tags on a page may have an "id" attribute.

I still wander what we're missing about your execution scenario, as I cannot duplicate this failure, but would like to do so.

Are you on Windows?

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com/hargettp/hh-web/issues/5#issuecomment-39274648 .

[Davidbhodge]

and to check, what version of slime are you running? did you update in February with the new shiny improved slime from github?

Phil Hargett mailto:notifications@github.com 2 April 2014 8:28 am Interesting! Sorry, I don't have my OS X machine this week, or I could do more to reproduce.

The extra libraries you mention are interesting, so perhaps that is something.

Thank you for your persistence...I will certainly try to isolate the issue once my other machine is back.

:)

On Apr 1, 2014, at 7:51 PM, Davidbhodge notifications@github.com wrote:

Hi,

It's macosx mavericks. Though I doubt it's an OS thing.

With my sbcl I preload Alexandria and a package called repl utilities. I will try this again without them in a plain vanilla sbcl and see if that makes a difference. I will actually remove slime/swank as well. The only other thing that comes to mind is doing a refresh of quick lisp libraries, installing hh-web downloaded a bunch of new libraries, so it's not unreasonable that maybe there is some minor inconsistency with something Already on my machine

The real show stopper is the fact that rendering a page fails somehow.

In the supplied template I can change the page title and that change shows however nothing else. I will let you know the results of my experiments later.

Cheers

Sent from my iPad

On 1 Apr, 2014, at 23:49, Phil Hargett notifications@github.com wrote:

Hmmm, actually I believe I am. Since my .emacs has this line, and the slime-helper.el from Quicklisp seems to enable slime-fancy:

(load (expand-file-name "~/quicklisp/slime-helper.el"))

So, hh-web does define the symbol "id," because its an important identifier for HTML: many tags on a page may have an "id" attribute.

I still wander what we're missing about your execution scenario, as I cannot duplicate this failure, but would like to do so.

Are you on Windows?

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com/hargettp/hh-web/issues/5#issuecomment-39274648 .

— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/issues/5#issuecomment-39277049.

[hargettp]

I will double check but I'm fairly certain I use the slime delivered with Quicklisp and I believe I updated in last month or so.

:)

On Apr 1, 2014, at 8:40 PM, Davidbhodge notifications@github.com wrote:

and to check, what version of slime are you running? did you update in February with the new shiny improved slime from github?

Phil Hargett <mailto:notifications@github.com notifications@github.com> 2 April 2014 8:28 am Interesting! Sorry, I don't have my OS X machine this week, or I could do more to reproduce.

The extra libraries you mention are interesting, so perhaps that is something.

Thank you for your persistence...I will certainly try to isolate the issue once my other machine is back.

:)

On Apr 1, 2014, at 7:51 PM, Davidbhodge notifications@github.com wrote:

Hi,

It's macosx mavericks. Though I doubt it's an OS thing.

With my sbcl I preload Alexandria and a package called repl utilities. I will try this again without them in a plain vanilla sbcl and see if that makes a difference. I will actually remove slime/swank as well. The only other thing that comes to mind is doing a refresh of quick lisp libraries, installing hh-web downloaded a bunch of new libraries, so it's not unreasonable that maybe there is some minor inconsistency with something Already on my machine

The real show stopper is the fact that rendering a page fails somehow.

In the supplied template I can change the page title and that change shows however nothing else. I will let you know the results of my experiments later.

Cheers

Sent from my iPad

On 1 Apr, 2014, at 23:49, Phil Hargett notifications@github.com wrote:

Hmmm, actually I believe I am. Since my .emacs has this line, and the slime-helper.el from Quicklisp seems to enable slime-fancy:

(load (expand-file-name "~/quicklisp/slime-helper.el"))

So, hh-web does define the symbol "id," because its an important identifier for HTML: many tags on a page may have an "id" attribute.

I still wander what we're missing about your execution scenario, as I cannot duplicate this failure, but would like to do so.

Are you on Windows?

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com/hargettp/hh-web/issues/5#issuecomment-39274648 .

Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/issues/5#issuecomment-39277049.

Reply to this email directly or view it on GitHubhttps://github.com/hargettp/hh-web/issues/5#issuecomment-39277779 .

[Davidbhodge]

aahhh,

So its old, thats more than a month old usually

That might explain the symbol clash then.

The other issue , well its likely my environment

Cheers

Phil Hargett mailto:notifications@github.com 2 April 2014 8:41 am I will double check but I'm fairly certain I use the slime delivered with Quicklisp and I believe I updated in last month or so.

:)

On Apr 1, 2014, at 8:40 PM, Davidbhodge notifications@github.com wrote:

and to check, what version of slime are you running? did you update in February with the new shiny improved slime from github?

Phil Hargett <mailto:notifications@github.com notifications@github.com> 2 April 2014 8:28 am Interesting! Sorry, I don't have my OS X machine this week, or I could do more to reproduce.

The extra libraries you mention are interesting, so perhaps that is something.

Thank you for your persistence...I will certainly try to isolate the issue once my other machine is back.

:)

On Apr 1, 2014, at 7:51 PM, Davidbhodge notifications@github.com wrote:

Hi,

It's macosx mavericks. Though I doubt it's an OS thing.

With my sbcl I preload Alexandria and a package called repl utilities. I will try this again without them in a plain vanilla sbcl and see if that makes a difference. I will actually remove slime/swank as well. The only other thing that comes to mind is doing a refresh of quick lisp libraries, installing hh-web downloaded a bunch of new libraries, so it's not unreasonable that maybe there is some minor inconsistency with something Already on my machine

The real show stopper is the fact that rendering a page fails somehow.

In the supplied template I can change the page title and that change shows however nothing else. I will let you know the results of my experiments later.

Cheers

Sent from my iPad

On 1 Apr, 2014, at 23:49, Phil Hargett notifications@github.com wrote:

Hmmm, actually I believe I am. Since my .emacs has this line, and the slime-helper.el from Quicklisp seems to enable slime-fancy:

(load (expand-file-name "~/quicklisp/slime-helper.el"))

So, hh-web does define the symbol "id," because its an important identifier for HTML: many tags on a page may have an "id" attribute.

I still wander what we're missing about your execution scenario, as I cannot duplicate this failure, but would like to do so.

Are you on Windows?

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on

GitHubhttps://github.com/hargettp/hh-web/issues/5#issuecomment-39274648 .

Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/issues/5#issuecomment-39277049.

Reply to this email directly or view it on GitHubhttps://github.com/hargettp/hh-web/issues/5#issuecomment-39277779 .

— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/issues/5#issuecomment-39277864.

[hargettp]

Okay, thankfully have my Mac back...

Sadly, I can't reproduce your issue. :(

I updated Quicklisp (which now includes slime 2.4). I ran the initial load of :hh-web, generated the sample project, then restarted my inferior lisp. After that I quickloaded alexandria and repl-utilities, then the sample project and run it.

No issue.

So...

Exporting ID as a symbol is a key part of working with HTML, and thus essential to hh-web's design. So that can't change.

Unless we can identify that the conflict is a result of hh-web conflicting with a package on which it depends (directly or indirectly), then the conflict is not an issue with hh-web. I don't expect swank in the tree of dependencies, so I'd be surprised if hh-web is the cause of that conflict.

As for the stack trace when running the starter project, I can't reproduce that either, but perhaps is either a downstream artifact of the first failure.

If you've pulled Slime from github rather than loading and updating it through Quicklisp, then you may be on your own: the existence of Quicklisp gives us all an excellent baseline for compatibility, so veering off of that means I may not be able to help fix what's broken, as it will be specific to your environment.

If you discover more information that may be related to the issue, please let me know, as I at least now have an environment with which to reproduce them accurately.

[Davidbhodge]

Hi,

Thanks for the note.

What i will do is, temporarily, revert to the older slime in quicklisp and see if that makes a difference.

I guess its a heads up to you though, that when this version of slime hits quicklisp you will face the issue.

I will let you know if anything eventuates.

By the way I get this as well from the web server, I don't know if that is significant or not -

Cheers

127.0.0.1 - [2014-04-03 18:40:15] "GET / HTTP/1.1" 200 370 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36" [2014-04-03 18:46:53 [WARNING]] The variable HH-WEB::CACHE-ITEM is defined but never used. [2014-04-03 18:46:53 [WARNING]] Warning while processing connection: The variable HH-WEB::CACHE-ITEM is defined but never used. 127.0.0.1 - [2014-04-03 18:46:53] "GET / HTTP/1.1" 200 370 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36" [2014-04-03 18:46:53 [WARNING]] The variable HH-WEB::CACHE-ITEM is defined but never used. [2014-04-03 18:46:53 [WARNING]] Warning while processing connection: The variable HH-WEB::CACHE-ITEM is defined but never used.

Phil Hargett mailto:notifications@github.com 3 April 2014 6:56 pm

Okay, thankfully have my Mac back...

Sadly, I can't reproduce your issue. :(

I updated Quicklisp (which now includes slime 2.4). I ran the initial load of :hh-web, generated the sample project, then restarted my inferior lisp. After that I quickloaded alexandria and repl-utilities, then the sample project and run it.

No issue.

So...

Exporting ID as a symbol is a key part of working with HTML, and thus essential to hh-web's design. So that can't change.

Unless we can identify that the conflict is a result of hh-web conflicting with a package on which it depends (directly or indirectly), then the conflict is not an issue with hh-web. I don't expect swank in the tree of dependencies, so I'd be surprised if hh-web is the cause of that conflict.

As for the stack trace when running the starter project, I can't reproduce that either, but perhaps is either a downstream artifact of the first failure.

If you've pulled Slime from github rather than loading and updating it through Quicklisp, then you may be on your own: the existence of Quicklisp gives us all an excellent baseline for compatibility, so veering off of that means I may not be able to help fix what's broken, as it will be specific to your environment.

If you discover more information that may be related to the issue, please let me know, as I at least now have an environment with which to reproduce them accurately.

— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/issues/5#issuecomment-39438017.

[hargettp]

Re slime: certainly sounds like there could be breakage in the future. Thanks for heads up! I know many times when a maintainer updates a package in Quicklisp, there are often notes to one another advising each other of what broke and why. I'll cross my fingers that happens again. :)

Hah, yes, there are still tons of warnings, unfortunately. Some of the code in there is the oldest Lisp code I've written, so tidying up isn't out of the question.

Most of those warnings, though, are really an artifact of "context" that gets set up for all these tags....but not all tags need to use them. I really just need to sprinkle some more ignores in here so that if they are not used SBCL stays silent.

Sorry I can't be of more help!

On Apr 3, 2014, at 7:08 AM, Davidbhodge notifications@github.com wrote:

Hi,

Thanks for the note.

What i will do is, temporarily, revert to the older slime in quicklisp and see if that makes a difference.

I guess its a heads up to you though, that when this version of slime hits quicklisp you will face the issue.

I will let you know if anything eventuates.

By the way I get this as well from the web server, I don't know if that is significant or not -

Cheers

127.0.0.1 - [2014-04-03 18:40:15] "GET / HTTP/1.1" 200 370 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36" [2014-04-03 18:46:53 [WARNING]] The variable HH-WEB::CACHE-ITEM is defined but never used. [2014-04-03 18:46:53 [WARNING]] Warning while processing connection: The variable HH-WEB::CACHE-ITEM is defined but never used. 127.0.0.1 - [2014-04-03 18:46:53] "GET / HTTP/1.1" 200 370 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36" [2014-04-03 18:46:53 [WARNING]] The variable HH-WEB::CACHE-ITEM is defined but never used. [2014-04-03 18:46:53 [WARNING]] Warning while processing connection: The variable HH-WEB::CACHE-ITEM is defined but never used.

Phil Hargett mailto:notifications@github.com 3 April 2014 6:56 pm

Okay, thankfully have my Mac back...

Sadly, I can't reproduce your issue. :(

I updated Quicklisp (which now includes slime 2.4). I ran the initial load of :hh-web, generated the sample project, then restarted my inferior lisp. After that I quickloaded alexandria and repl-utilities, then the sample project and run it.

No issue.

So...

Exporting ID as a symbol is a key part of working with HTML, and thus essential to hh-web's design. So that can't change.

Unless we can identify that the conflict is a result of hh-web conflicting with a package on which it depends (directly or indirectly), then the conflict is not an issue with hh-web. I don't expect swank in the tree of dependencies, so I'd be surprised if hh-web is the cause of that conflict.

As for the stack trace when running the starter project, I can't reproduce that either, but perhaps is either a downstream artifact of the first failure.

If you've pulled Slime from github rather than loading and updating it through Quicklisp, then you may be on your own: the existence of Quicklisp gives us all an excellent baseline for compatibility, so veering off of that means I may not be able to help fix what's broken, as it will be specific to your environment.

If you discover more information that may be related to the issue, please let me know, as I at least now have an environment with which to reproduce them accurately.

— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/issues/5#issuecomment-39438017.

— Reply to this email directly or view it on GitHub.

[hargettp]

Second person encountered the duplicate symbol issue. See #6. Will try to get to a root cause on this issue instead.

[hargettp]

Heh...you may be happy to know I can reproduce the issue now. :)

[Davidbhodge]

Ah. Well that's interesting.

I have downgraded my slime, removed all fasls, recompiled everything and still have the issue I am afraid.

Sent from my iPad

On 7 Apr, 2014, at 1:21, Phil Hargett notifications@github.com wrote:

Heh...you may be happy to know I can reproduce the issue now. :)

— Reply to this email directly or view it on GitHub.

[hargettp]

Intriguing...I can only reproduce this when running in Emacs, when of course Slime is involved. Running SBCL 1.1.14 from a console, I cannot. The sample loads and executes fine.

[Davidbhodge]

That is interesting and I am kicking myself for not trying it!

Same result here, it loads and executes fine outside of slime.

My previous opinion about these being separate issues is clearly suspect :)

Sent from my iPad

On 7 Apr, 2014, at 6:21, Phil Hargett notifications@github.com wrote:

Intriguing...I can only reproduce this when running in Emacs, when of course Slime is involved. Running SBCL 1.1.14 from a console, I cannot. The sample loads and executes fine.

— Reply to this email directly or view it on GitHub.

[hargettp]

Yeah, I'm pretty sure something has changed in Slime. I know that sounds obvious, given what you found earlier, but I am seeing new behavior in my own code that wasn't there before. Specifically, I am seeing that when the generated "home_page.lisp" is being loaded, the package special variable should be set to a package specific to the template...but in this case, it's set to the swank-trace-dialog package, which explains why we are all seeing the restart.

I'll keep digging. :)

[hargettp]

I've narrowed it down to lines 117-119 of taglibraries.lisp. I'm expecting to have the package special set to 'cl-user, but we seem to be getting 'swank-trace-dialog instead. That's why see the restart that we do.

[hargettp]

Found a workaround...

It turns out that Slime now uses std as nickname for its swank-trace-dialog package. My hh-web package (as well as samples that it generates) creates a tag library and gives it a package name of std...and that's why we get a conflict. So, a simple workaround (for now) is to drop that nickname so that it can be reused.

Before loading your sample package (or, potentially any package based on hh-web), run this:

(rename-package (find-package :std) 'swank-trace-dialog)

And, actually, my earlier comment about where the issue is was not precise: it turns out the issue happens at line 286 of taglibraries.lisp, where the std tag library is being read in. Because std has already been used to name a package, the definitions in that library get read into package swank-trace-dialog.

[Davidbhodge]

Yup.

Works for me.

At least now I can look seriously into the package. I like what i see so far and have a definite project in mind

Thanks a bunch.

Let me know when you devise a fix

Phil Hargett mailto:notifications@github.com 7 April 2014 8:25 am

Found a workaround...

It turns out that Slime now uses |std| as nickname for its |swank-trace-dialog| package. My hh-web package (as well as samples that it generates) creates a tag library and gives it a package name of |std|...and that's why we get a conflict. So, a simple workaround (for now) is to drop that nickname so that it can be reused.

Before loading your sample package (or, potentially any package based on uh-web), run this:

(rename-package (find-package :std) 'swank-trace-dialog)

And, actually, my earlier comment about where the issue is was not precise: it turns out the issue happens at line 286 of taglibraries.lisp, where the |std| tag library is being read in. Because |std| has already been used to name a package, the definitions in that library get read into package |swank-trace-dialog|.

— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/issues/5#issuecomment-39688182.

[hargettp]

Worth a shot, eh? :)

There are several options, and I'm open to suggestions. For example:

• I could have the generated skeleton projects apply this hack when they start up the Hunchentoot server, because the workaround just needs to be done before loading any template/tag library in the project.
• I could rename my std tag libraries to have a different name. I didn't want to type out standard but I of course could.
• Leave names as is, but change tag library package creation to avoid conflicts with any existing packages. This would mean sample projects would break when run under Slime, but with a perhaps better error, although they would work fine when run without Slime.

[Davidbhodge]

Call it hh-std and i am sold.

I tend to name things with a project prefix for this reason.

Thanks for your help and for the package. I was going to use bootstrap for a small project for a friend but was dreading the whole javascript thing. It will be nice to stay in lisp if i can

On 7 Apr, 2014, at 8:47 am, Phil Hargett notifications@github.com wrote:

Worth a shot, eh? :)

There are several options, and I'm open to suggestions. For example:

I could have the generated skeleton projects apply this hack when they start up the Hunchentoot server, because the workaround just needs to be done before loading any template/tag library in the project.

I could rename my std tag libraries to have a different name. I didn't want to type out standard but I of course could.

Leave names as is, but change tag library package creation to avoid conflicts with any existing packages. This would mean sample projects would break when run under Slime, but with a perhaps better error, although they would work fine when run without Slime. — Reply to this email directly or view it on GitHub.

[hargettp]

See bb7f765ca7cee6e1053f1220e0162e922be64ba6. I think I got it.