Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

potential bugs when using sc::functions outside of sc #76

Open
Leon-Focker opened this issue Feb 21, 2024 · 3 comments
Open

potential bugs when using sc::functions outside of sc #76

Leon-Focker opened this issue Feb 21, 2024 · 3 comments

Comments

@Leon-Focker
Copy link
Collaborator

Yesterday I caught a bug that caused an error when trying to use #'write-xml with events, that were not created within the slippery-chicken package. I'm posting this here because the same issue might apply to other places that I haven't found yet. The issue was, that #'write-xml compares a symbol from within slippery-chicken with a symbol from the event. If the event was not created in :sc, its symbols are not interned in :sc and the comparison will never be true. I solved this by using (intern (string 'symbol) :sc)

#940ad05

Maybe there is a stragety to find other bugs caused by this or another solution to it that I'm not aware of.

@mdedwards
Copy link
Owner

Hello Leon, first of all I would hesitate before calling this a bug, as I can't imagine there are many Lisp packages out there that intern all symbols at every call of the eq function. Be that as it may I see your issue in general, but I'm confused about what you mean by events. I have the feeling you're not talking about (sc) event objects. Do you have any code to illustrate this problem? Now that you've fixed the bug of course, the code will no longer trigger the error, but I would just like to see the kind of thing that you've been dealing with.

By the way, does the package from within which you call write-xml have (:use :sc) in its defpackage statement?

On a related matter, I would caution against using xml-related sc methods to write your own music XML files, as I think it might cause far more headaches than solutions. Of course, go for it if you think there is mileage to be gained, but in the slippery-chicken context, creating bars and importing these into an object via bars-to-sc , then writing a music XML file from that, is a much easier route in general, especially if you do at some point need to have metrical bars, which is the case in 99% of music scores.

Best, Michael

@Leon-Focker
Copy link
Collaborator Author

Leon-Focker commented Feb 21, 2024

Hey Michael,
true, interning every symbol does not seem right. Yet, the error message you get in this case is very confusing if you don't know it's about (not) interned symbols.

I do actually talk about sc::events and yes, my package has (:use :sc) in the defpackage statement. To replicate the error I could have generated any slippery-chicken object in my package and tried to use #'write-xml on it. To give a specific example, you could use this code: How can I 'roll my own' slippery chicken?
The only thing you needed to change for the error to occur is changing the (in-package) statement. (in my case I used layers.) And of course change the (lp-display sc) to (write-xml sc :file "...").

And don't worry, I stumbled over this bug and this specific example because I am using that method exactly! Just in my own package...

@mdedwards
Copy link
Owner

Aha, OK, interesting. A quick look at all the eq tests in the src directory reveals a lot more candidates:

grep "(eq " *.lsp

Feel free to poke at them if you like, or consider switching to the sc package for blocks of your code--that's what I do in parts of CLM that deal heavily with the CMN or CM package.

@Leon-Focker Leon-Focker removed the bug label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants