Marc Hohl <m...@hohlart.de> writes: > Am 30.09.2012 22:03, schrieb d...@gnu.org: >> On 2012/09/30 19:44:49, marc wrote: >>> Am 30.09.2012 11:02, schrieb d...@gnu.org: >>> > [...] >>> > First, the define-public is asking for trouble. You are exposing an >>> > internal Scheme data structure to users and make it overwritable by >> the >>> > user. If the user follows this invitation, the effects will bleed >> over >>> > from session to session. Never do that. >>> Ok. >> >> No, it's not ok. Hold your horses, this is another case too stupid for >> documenting and walking people through. Give me two days, and then you >> replace your define-public for the alists with define-session, and >> that's it. The rest of the code stays as it is. > Hi David, > > I just saw that define-session is available now. > > I replaced the definition of the empty alists in my patch with > define-session-public, > but when I compile input/regression/bar-line-define-bar-glyph.ly, I > still get the > Parsed object should be dead error messages. > > Do I use the define-session-public commands in the right way? > > As I understand, define-session-public works as define-public, but for > the current session > only, define-session is the per-session equivalent to define.
Correct. I did not really do a review of the barline code, just pointed out things that struck me as wrong while glancing over it. The "parsed objects should be dead" message implies that objects with data _types_ that should not exist at the start of a session have survived beyond the end of a session. So the absence of such messages does not imply that your sessions are clean, just that there are no blunders that can be detected from the _types_ of the surviving objects alone. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
