ead
> after all.
Frankly, the state of the automatation is pitiful, but we were also
partly laboring from a dearth of API documentation IIRC as well as a
lack of people versed in the respective programming
languages/systems/frameworks.
Lame excuses, I know. At any rate, things on my plate
Werner LEMBERG writes:
>>> However, I'd like to hear from David Kastrup and James Lowe
>>> first. To me, their opposition registered as the strongest.
>>
>> I remain strongly opposed to a CoC.
>
> Hmm. What about simply using the GNU Kind Communication
Han-Wen Nienhuys writes:
> On Sat, Feb 8, 2020 at 4:23 PM David Kastrup wrote:
>
>>
>> > Does this already solve your needs?
>>
>
> I found a way, using pthread_create. Unfortunately, it's doesn't really
> work, because there is no way to dis
Urs Liska writes:
> Am Samstag, den 08.02.2020, 17:31 +0100 schrieb David Kastrup:
>> Thomas Morley writes:
>>
>> > P.S. that 'make test-baseline' failed, I'll need to investigate
>> > after
>> > sending this.
>> >
>> &
think about what to do here.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
x27;s a patch. Review showed there are too many objections. Thus it
>> should be set to 'needs work' or 'waiting'.
>> Otoh, there are suggestions to replace this proposal. Why not focus on
>> those proposals?
>
> Excellent suggestion.
Unsurprisingly I am
abandon the markup macro. Not that I am the least bit fond of it,
but it's almost omnipresent.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
eeds?
> Jonas
It's worth pointing out that almost _all_ of our Scheme-level
allocations are routed through the Smob_core class, so doing the heap
extension _there_ when one passes there next should be workable. While
the code certainly does allocate non-Smob SCM objects a lot as well (by
calling things like scm_cons), the smobbed ones should be worked often
enough that extending the heap then should not cause too much churn.
--
David Kastrup
pened to the SQLite project.
>
> In the spirit of the recent "RFC" posts that explore different future
> directions, I think I could soon propose something for a Code of
> Conduct. (It draws on some centuries-old traditions of community
> conflict resolution.)
>
> How
olution that talks to the user in composer terms, and to the program in
LilyPond terms.
End of pontification. Just something that tends to lurk in the back of
my mind and sometimes might give a different outlook on a problem.
--
David Kastrup
My replies have a tendency to cause friction. To help
7;t touch
> any header file). But what's then the point of using ccache, we can
> just trigger a full build?
Full builds are slower. But I really don't trust our dependencies all
too much, and for example Clang builds don't get a working set of
dependencies anyway (which is sort of curious since it is the modular
Clang that should be able to parse for them easily).
--
David Kastrup
David Kastrup writes:
> David Kastrup writes:
>> Han-Wen Nienhuys writes:
>>
>>> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup wrote:
>>>
>>>> I propose that I am going to pick up the pieces of
>>>> not-actually-formally-reviewed patc
ng, that
would be really a thing. Especially if the translators should get a
chance at picking those up yet.
--
David Kastrup
facets of who I am.
> I'm borderline on the spectrum myself, and yes it can make life
> difficult with people who don't know you ...
But the point is they have to know you, not your medical folder.
--
David Kastrup
My replies have a tendency to cause friction. To help mitig
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup wrote:
>>
>>> I propose that I am going to pick up the pieces of
>>> not-actually-formally-reviewed patches making up the bulk of them and
>>> put the
Karlin High writes:
> On 2/6/2020 2:45 PM, David Kastrup wrote:
>> I am working on an Email signature that might be helping to convey the
>> message.
>
> Nice idea, but sometimes drawing attention to a problem only makes
> things worse. How about focusing on the suc
Han-Wen Nienhuys writes:
> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup wrote:
>
>> I propose that I am going to pick up the pieces of
>> not-actually-formally-reviewed patches making up the bulk of them and
>> put them, Guilev2-guarded (so that they don't affect
Han-Wen Nienhuys writes:
> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup wrote:
>
>> I propose that I am going to pick up the pieces of
>> not-actually-formally-reviewed patches making up the bulk of them and
>> put them, Guilev2-guarded (so that they don't affect
shly but definitely sincerely) an eventually gratifying work/life
balance.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
Han-Wen Nienhuys writes:
> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup wrote:
>
>> I propose that I am going to pick up the pieces of
>> not-actually-formally-reviewed patches making up the bulk of them and
>> put them, Guilev2-guarded (so that they don't affect
cheme-containing data structures
instead of being in a state where only parts are operative.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
already previously turned into non-showstoppers although not necessarily
in the cleanest manner. But it would seem that even if part of them is
likely to eventually be superseded, giving Han-Wen a better starting
place would make him work and plan more effectively.
--
David Kastrup
My replie
desirable end point for Guilev2 migration but a migration
strategy designed for getting back something working as before. Which
is a starting point from which one can then explore the task of getting
to an environment that looks like Unicode rather than bytes from the
Scheme side.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Fri, Feb 7, 2020 at 3:36 PM David Kastrup wrote:
>
>> Han-Wen Nienhuys writes:
>>
>> > n the spirit for providing competing options, I hereby offer a Gerrit
>> > RFC. Note that I'm an obvious fan of Gerrit, but Gitlab se
w if I’m just talking nonsense.
> If not, let me know how I can help make this "fix" a reality.
Well, the problem is that there is no "grace event" but a grace iterator.
Now this this characterization is not entirely true any more since
commit 99a85ca39f3a7a6f717ba06a48ef0b
d a change and often giving extensive
other information like problem images. That's something we cannot
attach to commits (or at least, this has not been attempted so far).
--
David Kastrup
ce the Rietveld part of our
workflow, but not the SourceForge part.
--
David Kastrup
the purpose of self-hosting. That gives an
escape hatch that either users or competing services can pick up in the
case of contingency.
This may seem academical, but even the academical possibility reins in
corporate decision makers from performing wholesale changes on a whim.
--
David Kastrup
requiring maximum permissions and
having pervasive logging. That seems to only make business sense in the
data gathering business, for internal or external use.
Sorry, this is all not much more than banter right now. Basically I
don't see any obvious red flags.
--
David Kastrup
Karlin High writes:
> On 2/6/2020 2:45 PM, David Kastrup wrote:
>> I am working on an Email signature that might be helping to convey the
>> message.
>
> Nice idea, but sometimes drawing attention to a problem only makes
> things worse. How about focusing on the suc
James Lowe writes:
> On 06/02/2020 15:37, David Kastrup wrote:
>> Werner LEMBERG writes:
>>
>>>> I'd like to recommend that everyone argues with him [David K.], if
>>>> you think he is wrong. Otherwise take his posts literal and _not_
>>&g
anting to go ahead…
Hopefully got it right now. Patchy is at it...
--
David Kastrup
Jonas Hahnfeld writes:
> Hi David,
>
> Am Donnerstag, den 06.02.2020, 00:44 +0100 schrieb David Kastrup:
>> Whatever else may be on the plate, the immediate problem to be put
>> behind us right now is the release of 2.20.
>
> fantastic!
>
>> I put specificall
time
until the emotional response aligns with that knowledge.
It's good advice, like "stay away from that trapdoor in the kitchen
leading to the snake pit". But it's still a kitchen layout that may
come unexpected.
--
David Kastrup
the CoC from a different
> angle. We’ll have to wait and see if it works out as I feel it could.
>
> Cheers,
> Kieren.
>
>
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
>
>
--
David Kastrup
the files generated are for
> 2.19.84. Is it normal?
Yes. 2.19.84 is a prerelease to 2.20.0 made from the stable branch. It
is miles behind the unstable branch that is going to see its first
release of 2.21.0 comparatively soonish after 2.20.0 (which will not be
significantly different from 2.19.84) has been released.
--
David Kastrup
gs are not all lilies and roses either, but
addressing that seems to call for a somewhat different angle of attack.
I have no good idea.
--
David Kastrup
ould study to get into the right direction.
See above for some low-level hooks, but the rest will be a bunch of
programming work including juggling contexts and both split and
condensed versions typeset in parallel.
--
David Kastrup
uot;, that's part of the review process which is no job,
> every developer should participate.
Well, we don't really point out helpful resources for that a lot, do we?
> Jonas
--
David Kastrup
ed in their ability to
be a musician by having a day job; LilyPond may help them in their free
time working with music. So it's not unusual for contributors to have
little overall time available. And if the day job is already
emotionally draining, the hobby should probably not do the same.
So I get the problem but am obviously not overly successful at tackling
it.
--
David Kastrup
ll agree that it sends an awful
message to bystanders.
I'll have to sleep over what that means. While your recommendation is
certainly not a bad idea as such, it does not help reducing the impact
on first visitors.
Thanks for that exposition. It was certainly relevant for bringing some
insight to my side of the fence.
--
David Kastrup
you would not judge
me the best suited person for tidying up things, either.
Nevertheless, I feel I am pretty solitary with that kind of aim which I
consider sort of important for bringing a critical mass of contributors
in before they start repelling one another :)
--
David Kastrup
issue, or that lilypond-extra will
get the necessary treatment until we can release 2.20 (hopefully in a
week or so), I can do the required cherry-picking myself.
So let's make sure we get our last ducks in a row for closing that
long-awaited chapter.
--
David Kastrup
dereview.appspot.com/561390043/
>>
Yes, separate issue. Jonas, I think you should push the fix for that
one to staging: from "doesn't work" there cannot be much more of a
regression to be afraid of.
--
David Kastrup
o design and implement such a "safety valve" pretty
> quickly and painlessly.
I am not in the position where I feel I could leave the project in good
conscience without reneging on reasonable expectations of people
supporting me.
--
David Kastrup
David Kastrup writes:
> Yes. Even given better communication by my side. If there are obvious
> recipes to follow to place and extend and use one's own plugin package,
> and if one so desires, submit it in a manner where other users may
> install it on-demand, I hope t
Urs Liska writes:
> Am Mittwoch, den 05.02.2020, 21:21 +0100 schrieb David Kastrup:
>> Urs Liska writes:
>>
>> > I must say that I haven't actually expressed an opinion about it so
>> > far, and I don't know which I have.
>> >
>> >
osed: the native MacOSX SDK licenses just prohibit
execution on a non-Mac computer, regardless of the build environment.
I am cautiously optimistic that we'll be able to get out 2.20.0 soonish
and 2.21.0 afterwards. I am more fuzzy about what that spells for
building 2.20.1 should that become necessary.
--
David Kastrup
f OpenLilyLib likely just
is a better fit for keeping in a separate repository/project since
changes in there do not need tight coordination with changes in
LilyPond.
--
David Kastrup
In short: if you don't want to bother with the messy parts of patch
submission, there is no problem submitting your patches anyway.
All the best
--
David Kastrup
from those individuals.
For better or worse, a substantial part of the discussion is now on
<https://codereview.appspot.com/575620043/> where the original proposal
as an addition to the LilyPond development source tree has been posted.
--
David Kastrup
The
proposal arrived today and you want to have it accepted within hours.
I think that this is not a time frame where other developers as well as
users can be expected to make and voice a qualified decision.
--
David Kastrup
Mike Solomon writes:
>> What does "implement" mean?
>
> Sorry, I wasn't clear. I meant merge the PR.
Uh, words have meanings. There would be no point of putting something
into our documentation that we are not going to follow through with.
--
David Kastrup
roblem of low contribution volume and a
> shrinking pool of developers. I'm also admittedly biased in that I
> don't feel comfortable contributing unless there is a code of conduct
> with clear steps for reporting violations and consequences for repeat
> offenders, so I'm probably not the best person to make the final call.
>
> ~Mike
>
>
--
David Kastrup
s in the end
all we can hope to do, even though there are a lot of times I'd wish I'd
be able to do better. As such I am grateful for people whose first
thought when the results are less than impressive is support and
mitigation rather than punishment.
--
David Kastrup
ettings/import_export.html
> 8:
> https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html
>
--
David Kastrup
s the simplest option is to cherry-pick my updates
> to the news files into staging. I remain a bit uncertain about git
> (and fairly out of practice). Could someone (David?) skilled in the
> art update staging from stable/2.20?
On the way.
--
David Kastrup
"Phil Holmes" writes:
> - Original Message - From: "David Kastrup"
> To: "Phil Holmes"
> Cc: ;
> Sent: Wednesday, February 05, 2020 3:05 PM
> Subject: Re: New build:
>
>
>> David Kastrup writes:
>>
>>> "
ication media in a manner where it would have been
reasonable to assume that they would have wanted to be able to file a
complaint?
> although I agree with you that secrecy and hierarchy should be the
> exception and not the rule. Most communication should be in the open
> and hierarchy free.
>
> Thanks,
> ~Mike
--
David Kastrup
ve a view on the bigger discussion about process - the
> change most likely to help me to contribute would be mentorship rather
> than any process change).
--
David Kastrup
David Kastrup writes:
> "Phil Holmes" writes:
>>
>> The build completed successfully, as did the upload, so anyone looking
>> at the manuals on lilypond.org will see 19.84 information. However,
>> the website has not built, I think because VERSION in
t I find less effective is just name-dropping of either CoC or the
GNU guidelines without referencing a particular passage. Probably more
so with the latter since they do not contain an inherent threat.
--
David Kastrup
so it seems like a reasonable
> experiment. If it proves to be a dud, we can get rid of it.
The preamble and intent is one thing; adding a corrective committee with
the authority to enact punishments based on anonymous reports is
another. It implements hierarchies and institutions exerting
"Phil Holmes" writes:
> - Original Message - From: "David Kastrup"
> To: "Phil Holmes"
> Cc: "Jonas Hahnfeld" ; "Dan Eble" ;
> "Masamichi Hosoda" ; ;
>
> Sent: Tuesday, February 04, 2020 5:34 PM
> Sub
ve
> the thread to a cooler core, so it throttles the clock rate instead.
Heat dependent throttling would explain the rather drastic variation in
performance since it acts with large latencies.
--
David Kastrup
cepting a corrective
committee that has basically proposed itself rather than being the
result of a list-wide election and where just one member has been a
permanent fixture on the lists for a longer amount of time at this
moment.
--
David Kastrup
Thomas Morley writes:
> Am Mi., 5. Feb. 2020 um 00:12 Uhr schrieb David Kastrup :
>>
>> Han-Wen Nienhuys writes:
>>
>> >Rietveld and my local commits are not linked. If I change my commits, I
>> >update my commit message. I have to copy
Thomas Morley writes:
> Am Di., 4. Feb. 2020 um 18:34 Uhr schrieb David Kastrup :
>>
>> "Phil Holmes" writes:
>>
>> > ----- Original Message - From: "David Kastrup"
>> >> Wow. Ok, maybe I'll just apply this patch then (tho
Han-Wen Nienhuys writes:
> On Wed, Feb 5, 2020 at 12:11 AM David Kastrup wrote:
>
>> Where commits do not belong to the same logical issue but are still
>> interdependent, they cannot be logically disentangled even using a
>> Git-specific tool like Gerrit.
>>
>
eing it in broader use.
Let me just use this to point out that our current environment has been
the result of getting stuck in the lurch when Google decided to
discontinue providing Google Code. So going from that experience, it
would make sense to favor tools where we have useful contingency plans
for falling out of support.
--
David Kastrup
by how concrete tools would solve them
> and why others don't. Would it help you if I posted something like
> this?
>
>> if you can only work with concrete proposals, I guess you'll have to
>> wait until the rest of us come to that point.
>
> Okay.
>
> Jonas
>
--
David Kastrup
term maintenance risk, and it should be
>rejected. -
Who are maintainers?
>Coordinated, larger efforts across the code base should start out
>with a discussion. The mailing list could work here, but I find
>discussion in an issue tracker is often easier to manage, because
>it is easier to search, and by its nature, discussion in an issue
>tracker drifts less off-topic. -
>
>We have a patch meister whose job it is to hound the project maintainer
>to look at patches that don’t find traction or otherwise.
That is not their current job description.
--
David Kastrup
"Phil Holmes" writes:
> - Original Message - From: "David Kastrup"
>> Wow. Ok, maybe I'll just apply this patch then (though I'll at
>> least
>> remove the conditioning on Apple here as the problem is rather likely
>&
David Kastrup writes:
> Halving the useful range before overflows is a problem, so I'll stick
> with most of the guards. Though I am skeptical that stuff exceeding I64
> has much of a chance of working well, anyway.
I have pushed a slightly modified version of the patch (removing
Jonas Hahnfeld writes:
> Am Dienstag, den 04.02.2020, 16:57 +0100 schrieb David Kastrup:
>> Dan Eble <
>> d...@faithful.be
>> > writes:
>>
>> > On Feb 4, 2020, at 09:44, Masamichi Hosoda <
>> > truer...@trueroad.jp
>> > > wro
his actually is.
>> >
>> > Jonas
>>
>> And what about size_t to Real? There's some of that in the queue:
>> https://codereview.appspot.com/563460043
>
> Apparently the build goes through. If I see this correctly, both
> clock_t and size_t are "unsigned long".
Wow. Ok, maybe I'll just apply this patch then (though I'll at least
remove the conditioning on Apple here as the problem is rather likely
platform independent) and Phil may have another round.
--
David Kastrup
conditional code really necessary? Why not boil it down to the
> working code and a comment explaining the extra conversion to signed
> numbers?
That would be my impulse as well. It is not like this code appears to
have notable drawbacks for the unafflicted platforms.
--
David Kastrup
::to_double () const
> {
>if (sign_ == -1 || sign_ == 1 || sign_ == 0)
> +// FIXME: workaround: In GUB, g++ 4.9.4 for darwin-x86,
> +// it seems that static cast from `unsigned long long` to `double`
> +// by x86 SSE2 raises an internal compile error.
> +// However, static cast from `signed long long` to `double`
> +// does not raise the error.
> +// So we use it for a workaround.
> +#if defined (__i386__) && defined (__APPLE__) && \
> + defined (__SSE2_MATH__) && __GNUC__ < 5
Wouldn't the same problem occur on Windows? We have 32bit executables
there as well. Or is the compiler version we use there not afflicted?
--
David Kastrup
e,
but have problems convincing LilyPond to do the same. So I cannot help
with debugging this situation yet or even finding out whether it
persists into newer compiler versions.
--
David Kastrup
ArnoldTheresius writes:
> Thomas Morley-2 wrote
>> Am Sa., 1. Feb. 2020 um 16:49 Uhr schrieb David Kastrup <
>
>> dak@
>
>> >:
>> ...
>>
>> Ok, thanks for the explanation.
>>
>> Iiuc, this would make this patch superfluous and i
at is not the problem. The
problem is the values elsewhere, and we use, for example, Moment
elements in the Midi structs which are not SCM values. The Midi data
structures are not scmified at all which would be a good idea for making
the Midi layer a whole lot more user-accessible than it is now. But we
are not there yet, and as long as a Moment is in there, at least with
Guile 1.8 this part of the heap is not marked.
--
David Kastrup
cted others will comment, or when in the
course of larger interdependent changes that cannot be defused by
rebases, the queue is expected to continue stalling for prolonged
amounts of time.
--
David Kastrup
Dan Eble writes:
> I confess, I've not educated myself on how Guile stores int versus
> long, like whether it actually uses more space for scm_from_long(50)
> than for scm_from_int(50);
No difference. Needed size depends on the magnitude of the value, not
its type.
--
David Kastrup
through all warning-silencing casts.
--
David Kastrup
returning to.
In short: your proposed solution would not address your problem if you
took reviews seriously. Instead you would have to rely on ignoring what
people say and go ahead anyway.
That is an approach that does not scale to projects of arbitrary size.
--
David Kastrup
be administered within the code review
> itself, so we don't need to keep tools in sync with each other.
I don't see how this changes the problem of a controversial patch
blocking the progress of dependent patches while the controversy is not
yet resolved.
--
David Kastrup
The file contains two 3-byte UTF-8
sequences above which could be thought to throw off the interpretation
by 4 bytes. But it actually is off by 6 bytes if it is running into the
preceding "ol", as if the special characters/bytes are not seen at all.
--
David Kastrup
hich would include this particular
issue.
I would not have chosen this way if I had not thought it the most
appropriate. It's actually a fairly recent commit, namely
commit cc9f25fa7ad9eecd1d1d9cfc2b3c50d96a847386
Author: David Kastrup
Date: Sat Apr 1 14:54:05 2017 +0200
Issue
" should _only_ run makelsr, not add
any manual prerequisites to doing so successfully. If the tree does not
permit running makelsr successfully, of course the tree does need to get
fixed first. But that needs to be committed in an upfront commit,
before committing _only_ the makelsr action as one commit.
It actually turned out that the actual problem blocking a successful doc
build was yet a different one and I misdiagnosed it. So I was really
lucky to be on the wrong track and be able to find and fix this problem
in the stable branch which otherwise would have kept under the radar and
caused problems later.
--
David Kastrup
changed, may be relevant. It's a very fuzzy indication of
something that might be a problem. If we get large differences even
with no change happening, this hand-wavy indicator (that did manage to
catch a few problems in the past) stops helping at all.
--
David Kastrup
Thomas Morley writes:
> Am Sa., 1. Feb. 2020 um 12:39 Uhr schrieb David Kastrup :
>>
>> Dan Eble writes:
>>
>> > On Feb 1, 2020, at 05:05, David Kastrup wrote:
>> >>
>> >> Frankly, I think that it would be better if our Windows executables
t easy to see which
parameters may be output parameters. But that makes a whole lot more
sense as a conventions for types like int (where passing by pointer
would be unusual) rather than class types which you basically always
want to pass by using a memory reference, whether in the form of a C++
reference or a pointer, regardless of whether they are input-only or
in-out or output-only.
--
David Kastrup
formula.
So I don't think we'd trigger the problems we see now. And math
routines in libguile might not expect the FPU to be in an unconventional
mode.
--
David Kastrup
s since I think the images are
actually contained in the lilypond-extra repository and not compiled
inside of the LilyPond source itself. Is that memory accurate? If so,
what is the proper way to proceed here?
--
David Kastrup
Han-Wen Nienhuys writes:
> On Sat, Feb 1, 2020 at 1:04 PM David Kastrup wrote:
>> >> Of course these are no scientifically hardened results - but they match
>> >> the feeling of excited frenzy visible on this list. However sustainable
>> >> the effe
log --author=hanwen --since 2016 | grep ^commit| wc
> 16 32 768
git shortlog -ns --since 2020-01-15 origin
27 Dan Eble
17 Jonas Hahnfeld
16 Han-Wen Nienhuys
2 David Stephen Grant
1 David Kastrup
1 Werner Lemberg
--
David Kastrup
automation of the process deteriorated significantly after
we had to stop using Google Code because the scripts have not been
adapted to the current situation, and at the current point of time it is
just James who does those tests with considerably more manual effort
than previously.
--
David Kastrup
Dan Eble writes:
> On Feb 1, 2020, at 05:05, David Kastrup wrote:
>>
>> Frankly, I think that it would be better if our Windows executables just
>> moved to 64bit but that seems like the more complicated option yet. And
>> 32bit systems kept around a whole lot l
Han-Wen Nienhuys writes:
> On Sat, Feb 1, 2020 at 11:11 AM David Kastrup wrote:
>> >> Here is an example that shows better how things work, and what might
>> >> be the cause of my problems. Is it right that programmatically set
>> >> contents of "
/.cache/guile/ccache/2.2-LE-8-3.A/home/hanwen/vc/lilypond/ew.scm.go'
>> [hanwen@localhost lilypond]$ GUILE_AUTO_COMPILE=0 guile2.2 ew.scm
>> I-am-called-at-runtime xy
>> Backtrace:
>>6 (apply-smob/1 #)
>> In ice-9/boot-9.scm:
>> 705:2 5 (call-with-prompt ("prompt") # …)
>> In ice-9/eval.scm:
>> 619:8 4 (_ #(#(#)))
>> In ice-9/boot-9.scm:
>>2312:4 3 (save-module-excursion #)
>> 3832:12 2 (_)
>> In ew.scm:
>> 10:10 1 (runtime-call "xy")
>> In unknown file:
>>0 (scm-error misc-error #f "~A ~S ~S ~S" ("No variabl…" …) …)
>>
>> ERROR: In procedure scm-error:
>> No variable named xy in #
>>
But that is not using a local define at all. Can you point out the
actual code that failed for you?
--
David Kastrup
801 - 900 of 6184 matches
Mail list logo
