This repository has been archived by the owner on Aug 14, 2019. It is now read-only.
[RC] Changes to zuse not propagated into userspace #796
Comments
|
This is a bug, but not a new bug. Our update logic (kiln) could use a tuneup...
…Sent from my iPhone
On Aug 30, 2018, at 6:46 AM, Fang ***@***.***> wrote:
On the release-candidate branch, updating zuse reloads the vanes, but not userspace.
Say you add the following arm into top-level zuse:
++ ohno 5
This builds fine, but then trying to do ohno in dojo gives a -find error. Similarly, modifying an existing arm in zuse still gives the old value when inspected from dojo.
Also, when trying to run tests (ie :test [%cores /]) after modifying zuse causes those changes not te be taken into account, resulting in errors if a library uses, say, the newly added ++ohno.
I did work on jael earlier (#795) that touched zuse, and didn't notice this at all. It's obvious vanes are getting rebuilt properly, but userspace applications continue running on old zuse. Probably not intended behavior?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
*Userspace applications* not reloading is an old bug; fresh ford requests
however, as you get from dojo expressions or :test, would totally see the
new pit
…On Thursday, 30 August 2018, cgyarvin ***@***.***> wrote:
This is a bug, but not a new bug. Our update logic (kiln) could use a
tuneup...
Sent from my iPhone
> On Aug 30, 2018, at 6:46 AM, Fang ***@***.***> wrote:
>
> On the release-candidate branch, updating zuse reloads the vanes, but
not userspace.
>
> Say you add the following arm into top-level zuse:
>
> ++ ohno 5
> This builds fine, but then trying to do ohno in dojo gives a -find
error. Similarly, modifying an existing arm in zuse still gives the old
value when inspected from dojo.
> Also, when trying to run tests (ie :test [%cores /]) after modifying
zuse causes those changes not te be taken into account, resulting in errors
if a library uses, say, the newly added ++ohno.
>
> I did work on jael earlier (#795) that touched zuse, and didn't notice
this at all. It's obvious vanes are getting rebuilt properly, but userspace
applications continue running on old zuse. Probably not intended behavior?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#796 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABxXhpqK1PkYLrryMXHmmBT9WZgYkN3cks5uV_blgaJpZM4WTglt>
.
|
|
To work around this, try echoing a newline into the dojo source. That
should cause a recompilation against new zuse.
@eglaysher I would think new Ford would rebuild all of its nontrivial live
builds when Zuse updates, though, since even using the %reef short-circuit
logic, they should still have live dependencies on Zuse.
—
~rovnys-ricfer
https://urbit.org
On Thu, Aug 30, 2018 at 8:48 AM, Anton Dyudin <notifications@github.com>
wrote:
… *Userspace applications* not reloading is an old bug; fresh ford requests
however, as you get from dojo expressions or :test, would totally see the
new pit
On Thursday, 30 August 2018, cgyarvin ***@***.***> wrote:
> This is a bug, but not a new bug. Our update logic (kiln) could use a
> tuneup...
>
> Sent from my iPhone
>
> > On Aug 30, 2018, at 6:46 AM, Fang ***@***.***> wrote:
> >
> > On the release-candidate branch, updating zuse reloads the vanes, but
> not userspace.
> >
> > Say you add the following arm into top-level zuse:
> >
> > ++ ohno 5
> > This builds fine, but then trying to do ohno in dojo gives a -find
> error. Similarly, modifying an existing arm in zuse still gives the old
> value when inspected from dojo.
> > Also, when trying to run tests (ie :test [%cores /]) after modifying
> zuse causes those changes not te be taken into account, resulting in
errors
> if a library uses, say, the newly added ++ohno.
> >
> > I did work on jael earlier (#795) that touched zuse, and didn't notice
> this at all. It's obvious vanes are getting rebuilt properly, but
userspace
> applications continue running on old zuse. Probably not intended
behavior?
> >
> > —
> > You are receiving this because you are subscribed to this thread.
> > Reply to this email directly, view it on GitHub, or mute the thread.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#796 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/
ABxXhpqK1PkYLrryMXHmmBT9WZgYkN3cks5uV_blgaJpZM4WTglt>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#796 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA1Y9Y-NLrX-iekTnmtsdgv9xiFKYtEMks5uWAk1gaJpZM4WTglt>
.
|
|
This is talking about dojo expressions, right? Those are run against [%plan
he-rail ~ `scaffold`[he-rail zuse sur lib ~ ~], where he-rail is now
and zuse is iirc a non-binding version number.
…On Thursday, 30 August 2018, Ted Blackman ***@***.***> wrote:
To work around this, try echoing a newline into the dojo source. That
should cause a recompilation against new zuse.
@eglaysher I would think new Ford would rebuild all of its nontrivial live
builds when Zuse updates, though, since even using the %reef short-circuit
logic, they should still have live dependencies on Zuse.
—
~rovnys-ricfer
https://urbit.org
On Thu, Aug 30, 2018 at 8:48 AM, Anton Dyudin ***@***.***>
wrote:
> *Userspace applications* not reloading is an old bug; fresh ford requests
> however, as you get from dojo expressions or :test, would totally see the
> new pit
>
> On Thursday, 30 August 2018, cgyarvin ***@***.***> wrote:
>
> > This is a bug, but not a new bug. Our update logic (kiln) could use a
> > tuneup...
> >
> > Sent from my iPhone
> >
> > > On Aug 30, 2018, at 6:46 AM, Fang ***@***.***> wrote:
> > >
> > > On the release-candidate branch, updating zuse reloads the vanes, but
> > not userspace.
> > >
> > > Say you add the following arm into top-level zuse:
> > >
> > > ++ ohno 5
> > > This builds fine, but then trying to do ohno in dojo gives a -find
> > error. Similarly, modifying an existing arm in zuse still gives the old
> > value when inspected from dojo.
> > > Also, when trying to run tests (ie :test [%cores /]) after modifying
> > zuse causes those changes not te be taken into account, resulting in
> errors
> > if a library uses, say, the newly added ++ohno.
> > >
> > > I did work on jael earlier (#795) that touched zuse, and didn't
notice
> > this at all. It's obvious vanes are getting rebuilt properly, but
> userspace
> > applications continue running on old zuse. Probably not intended
> behavior?
> > >
> > > —
> > > You are receiving this because you are subscribed to this thread.
> > > Reply to this email directly, view it on GitHub, or mute the thread.
> >
> > —
> > You are receiving this because you are subscribed to this thread.
> > Reply to this email directly, view it on GitHub
> > <#796 (comment)>, or
> mute
> > the thread
> > <https://github.com/notifications/unsubscribe-auth/
> ABxXhpqK1PkYLrryMXHmmBT9WZgYkN3cks5uV_blgaJpZM4WTglt>
> > .
>
> >
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#796 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AA1Y9Y-NLrX-
iekTnmtsdgv9xiFKYtEMks5uWAk1gaJpZM4WTglt>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#796 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABxXhl6ic5PLdchCigwcwDMb4p41iRmlks5uWCFPgaJpZM4WTglt>
.
|
|
(Which should in fact reduce to %reef among other things)
…On Thursday, 30 August 2018, Anton Dyudin ***@***.***> wrote:
This is talking about dojo expressions, right? Those are run against
[%plan he-rail ~ `scaffold`[he-rail zuse sur lib ~ ~], where he-rail is
now and zuse is iirc a non-binding version number.
On Thursday, 30 August 2018, Ted Blackman ***@***.***>
wrote:
> To work around this, try echoing a newline into the dojo source. That
> should cause a recompilation against new zuse.
>
> @eglaysher I would think new Ford would rebuild all of its nontrivial live
> builds when Zuse updates, though, since even using the %reef short-circuit
> logic, they should still have live dependencies on Zuse.
>
>
> —
> ~rovnys-ricfer
> https://urbit.org
>
> On Thu, Aug 30, 2018 at 8:48 AM, Anton Dyudin ***@***.***>
> wrote:
>
> > *Userspace applications* not reloading is an old bug; fresh ford
> requests
> > however, as you get from dojo expressions or :test, would totally see
> the
> > new pit
> >
> > On Thursday, 30 August 2018, cgyarvin ***@***.***> wrote:
> >
> > > This is a bug, but not a new bug. Our update logic (kiln) could use a
> > > tuneup...
> > >
> > > Sent from my iPhone
> > >
> > > > On Aug 30, 2018, at 6:46 AM, Fang ***@***.***> wrote:
> > > >
> > > > On the release-candidate branch, updating zuse reloads the vanes,
> but
> > > not userspace.
> > > >
> > > > Say you add the following arm into top-level zuse:
> > > >
> > > > ++ ohno 5
> > > > This builds fine, but then trying to do ohno in dojo gives a -find
> > > error. Similarly, modifying an existing arm in zuse still gives the
> old
> > > value when inspected from dojo.
> > > > Also, when trying to run tests (ie :test [%cores /]) after modifying
> > > zuse causes those changes not te be taken into account, resulting in
> > errors
> > > if a library uses, say, the newly added ++ohno.
> > > >
> > > > I did work on jael earlier (#795) that touched zuse, and didn't
> notice
> > > this at all. It's obvious vanes are getting rebuilt properly, but
> > userspace
> > > applications continue running on old zuse. Probably not intended
> > behavior?
> > > >
> > > > —
> > > > You are receiving this because you are subscribed to this thread.
> > > > Reply to this email directly, view it on GitHub, or mute the thread.
> > >
> > > —
> > > You are receiving this because you are subscribed to this thread.
> > > Reply to this email directly, view it on GitHub
> > > <#796 (comment)>, or
> > mute
> > > the thread
> > > <https://github.com/notifications/unsubscribe-auth/
> > ABxXhpqK1PkYLrryMXHmmBT9WZgYkN3cks5uV_blgaJpZM4WTglt>
> > > .
> >
> > >
> >
> > —
> > You are receiving this because you are subscribed to this thread.
> > Reply to this email directly, view it on GitHub
> > <#796 (comment)>, or
> mute
> > the thread
> > <https://github.com/notifications/unsubscribe-auth/AA1Y9Y-
> NLrX-iekTnmtsdgv9xiFKYtEMks5uWAk1gaJpZM4WTglt>
> > .
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#796 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/ABxXhl6ic5PLdchCigwcwDMb4p41iRmlks5uWCFPgaJpZM4WTglt>
> .
>
|
|
New Ford only uses the Zuse version number as an assertion. It builds the
reef based on beak. Ford will "short-circuit" a %reef build by using the
pit if the build is at the current date on the %home or %base desks. This
arrangement is designed to maintain referential transparency unless you
turn off |autoload.
Looks like Ford lost some code in the merge. @eglaysher had added code to
+make-reef to ensure we register dependencies on hoon, arvo, and zuse even
if we short-circuit using the pit. That code is now gone ... We'll dig that
up and reinstate it, and then maybe apps will reload. I just looked through
the reload and autoload code in helm and kiln, and I don't see how any of
that logic could cause this issue.
If fixing this in Ford doesn't fix the bug, then I suspect the ultimate
cause of the bug might be Clay not sending a notification about updates to
system files. I had thought maybe Gall's +load arm could be the culprit,
but it just keeps the old state wholesale, so I don't think that's it.
On Thu, Aug 30, 2018 at 10:47 AM Anton Dyudin <notifications@github.com>
wrote:
… (Which should in fact reduce to %reef among other things)
On Thursday, 30 August 2018, Anton Dyudin ***@***.***> wrote:
> This is talking about dojo expressions, right? Those are run against
> [%plan he-rail ~ `scaffold`[he-rail zuse sur lib ~ ~], where he-rail is
> now and zuse is iirc a non-binding version number.
>
> On Thursday, 30 August 2018, Ted Blackman ***@***.***>
> wrote:
>
>> To work around this, try echoing a newline into the dojo source. That
>> should cause a recompilation against new zuse.
>>
>> @eglaysher I would think new Ford would rebuild all of its nontrivial
live
>> builds when Zuse updates, though, since even using the %reef
short-circuit
>> logic, they should still have live dependencies on Zuse.
>>
>>
>> —
>> ~rovnys-ricfer
>> https://urbit.org
>>
>> On Thu, Aug 30, 2018 at 8:48 AM, Anton Dyudin ***@***.***
>
>> wrote:
>>
>> > *Userspace applications* not reloading is an old bug; fresh ford
>> requests
>> > however, as you get from dojo expressions or :test, would totally see
>> the
>> > new pit
>> >
>> > On Thursday, 30 August 2018, cgyarvin ***@***.***>
wrote:
>> >
>> > > This is a bug, but not a new bug. Our update logic (kiln) could use
a
>> > > tuneup...
>> > >
>> > > Sent from my iPhone
>> > >
>> > > > On Aug 30, 2018, at 6:46 AM, Fang ***@***.***>
wrote:
>> > > >
>> > > > On the release-candidate branch, updating zuse reloads the vanes,
>> but
>> > > not userspace.
>> > > >
>> > > > Say you add the following arm into top-level zuse:
>> > > >
>> > > > ++ ohno 5
>> > > > This builds fine, but then trying to do ohno in dojo gives a -find
>> > > error. Similarly, modifying an existing arm in zuse still gives the
>> old
>> > > value when inspected from dojo.
>> > > > Also, when trying to run tests (ie :test [%cores /]) after
modifying
>> > > zuse causes those changes not te be taken into account, resulting in
>> > errors
>> > > if a library uses, say, the newly added ++ohno.
>> > > >
>> > > > I did work on jael earlier (#795) that touched zuse, and didn't
>> notice
>> > > this at all. It's obvious vanes are getting rebuilt properly, but
>> > userspace
>> > > applications continue running on old zuse. Probably not intended
>> > behavior?
>> > > >
>> > > > —
>> > > > You are receiving this because you are subscribed to this thread.
>> > > > Reply to this email directly, view it on GitHub, or mute the
thread.
>> > >
>> > > —
>> > > You are receiving this because you are subscribed to this thread.
>> > > Reply to this email directly, view it on GitHub
>> > > <#796 (comment)>,
or
>> > mute
>> > > the thread
>> > > <https://github.com/notifications/unsubscribe-auth/
>> > ABxXhpqK1PkYLrryMXHmmBT9WZgYkN3cks5uV_blgaJpZM4WTglt>
>> > > .
>> >
>> > >
>> >
>> > —
>> > You are receiving this because you are subscribed to this thread.
>> > Reply to this email directly, view it on GitHub
>> > <#796 (comment)>, or
>> mute
>> > the thread
>> > <https://github.com/notifications/unsubscribe-auth/AA1Y9Y-
>> NLrX-iekTnmtsdgv9xiFKYtEMks5uWAk1gaJpZM4WTglt>
>> > .
>> >
>>
>> —
>> You are receiving this because you commented.
>> Reply to this email directly, view it on GitHub
>> <#796 (comment)>, or
mute
>> the thread
>> <https://github.com/notifications/unsubscribe-auth/
ABxXhl6ic5PLdchCigwcwDMb4p41iRmlks5uWCFPgaJpZM4WTglt>
>> .
>>
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#796 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA1Y9enAV6lKMyBu3YfKfRKXxFeFAO3cks5uWCUdgaJpZM4WTglt>
.
|
|
On Thursday, 30 August 2018, Ted Blackman ***@***.***> wrote:
New Ford only uses the Zuse version number as an assertion. It builds the
reef based on beak. Ford will "short-circuit" a %reef build by using the
pit if the build is at the current date on the %home or %base desks. This
arrangement is designed to maintain referential transparency unless you
turn off |autoload.
+1, this is also how I remember old ford working, which is why the bug is
likely new.
Looks like Ford lost some code in the merge. @eglaysher had added code to
+make-reef to ensure we register dependencies on hoon, arvo, and zuse even
if we short-circuit using the pit. That code is now gone ... We'll dig that
up and reinstate it, and then maybe apps will reload. I just looked through
the reload and autoload code in helm and kiln, and I don't see how any of
that logic could cause this issue.
esp since you seem to have found a plausible mechanism, nice!
…
If fixing this in Ford doesn't fix the bug, then I suspect the ultimate
cause of the bug might be Clay not sending a notification about updates to
system files. I had thought maybe Gall's +load arm could be the culprit,
but it just keeps the old state wholesale, so I don't think that's it.
On Thu, Aug 30, 2018 at 10:47 AM Anton Dyudin ***@***.***>
wrote:
> (Which should in fact reduce to %reef among other things)
>
> On Thursday, 30 August 2018, Anton Dyudin ***@***.***> wrote:
>
> > This is talking about dojo expressions, right? Those are run against
> > [%plan he-rail ~ `scaffold`[he-rail zuse sur lib ~ ~], where he-rail is
> > now and zuse is iirc a non-binding version number.
> >
> > On Thursday, 30 August 2018, Ted Blackman ***@***.***>
> > wrote:
> >
> >> To work around this, try echoing a newline into the dojo source. That
> >> should cause a recompilation against new zuse.
> >>
> >> @eglaysher I would think new Ford would rebuild all of its nontrivial
> live
> >> builds when Zuse updates, though, since even using the %reef
> short-circuit
> >> logic, they should still have live dependencies on Zuse.
> >>
> >>
> >> —
> >> ~rovnys-ricfer
> >> https://urbit.org
> >>
> >> On Thu, Aug 30, 2018 at 8:48 AM, Anton Dyudin <
***@***.***
> >
> >> wrote:
> >>
> >> > *Userspace applications* not reloading is an old bug; fresh ford
> >> requests
> >> > however, as you get from dojo expressions or :test, would totally
see
> >> the
> >> > new pit
> >> >
> >> > On Thursday, 30 August 2018, cgyarvin ***@***.***>
> wrote:
> >> >
> >> > > This is a bug, but not a new bug. Our update logic (kiln) could
use
> a
> >> > > tuneup...
> >> > >
> >> > > Sent from my iPhone
> >> > >
> >> > > > On Aug 30, 2018, at 6:46 AM, Fang ***@***.***>
> wrote:
> >> > > >
> >> > > > On the release-candidate branch, updating zuse reloads the
vanes,
> >> but
> >> > > not userspace.
> >> > > >
> >> > > > Say you add the following arm into top-level zuse:
> >> > > >
> >> > > > ++ ohno 5
> >> > > > This builds fine, but then trying to do ohno in dojo gives a
-find
> >> > > error. Similarly, modifying an existing arm in zuse still gives
the
> >> old
> >> > > value when inspected from dojo.
> >> > > > Also, when trying to run tests (ie :test [%cores /]) after
> modifying
> >> > > zuse causes those changes not te be taken into account, resulting
in
> >> > errors
> >> > > if a library uses, say, the newly added ++ohno.
> >> > > >
> >> > > > I did work on jael earlier (#795) that touched zuse, and didn't
> >> notice
> >> > > this at all. It's obvious vanes are getting rebuilt properly, but
> >> > userspace
> >> > > applications continue running on old zuse. Probably not intended
> >> > behavior?
> >> > > >
> >> > > > —
> >> > > > You are receiving this because you are subscribed to this
thread.
> >> > > > Reply to this email directly, view it on GitHub, or mute the
> thread.
> >> > >
> >> > > —
> >> > > You are receiving this because you are subscribed to this thread.
> >> > > Reply to this email directly, view it on GitHub
> >> > > <#796 (comment)
>,
> or
> >> > mute
> >> > > the thread
> >> > > <https://github.com/notifications/unsubscribe-auth/
> >> > ABxXhpqK1PkYLrryMXHmmBT9WZgYkN3cks5uV_blgaJpZM4WTglt>
> >> > > .
> >> >
> >> > >
> >> >
> >> > —
> >> > You are receiving this because you are subscribed to this thread.
> >> > Reply to this email directly, view it on GitHub
> >> > <#796 (comment)>,
or
> >> mute
> >> > the thread
> >> > <https://github.com/notifications/unsubscribe-auth/AA1Y9Y-
> >> NLrX-iekTnmtsdgv9xiFKYtEMks5uWAk1gaJpZM4WTglt>
> >> > .
> >> >
> >>
> >> —
> >> You are receiving this because you commented.
> >> Reply to this email directly, view it on GitHub
> >> <#796 (comment)>, or
> mute
> >> the thread
> >> <https://github.com/notifications/unsubscribe-auth/
> ABxXhl6ic5PLdchCigwcwDMb4p41iRmlks5uWCFPgaJpZM4WTglt>
> >> .
> >>
> >
>
> —
> You are receiving this because you commented.
>
>
> Reply to this email directly, view it on GitHub
> <#796 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/
AA1Y9enAV6lKMyBu3YfKfRKXxFeFAO3cks5uWCUdgaJpZM4WTglt>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#796 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABxXhtM4XpI2qOdFFCuUY1UDl36XI61qks5uWC85gaJpZM4WTglt>
.
|
|
For the record, the code in |
This was referenced Aug 30, 2018
|
This appears to be fixed by #800. Closing. |
|
@belisarius222 this doesn't actually seem to be fixed? Running off a pill that includes both #800 and #802. Adding an arbitrary arm into zuse still doesn't make it accessible in dojo/userspace without booting from a new pill. |
|
Oh ... I guess I didn't conduct my test properly. I'll look into it. |
|
Well, I'll look into this after fixing the Clay referential transparency bug. |
|
I'm not able to reproduce this bug on latest release-candidate. When I sync in new arms to zuse, they're immediately available in the dojo. |
|
Also no longer able to reproduce. This seems fixed! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
On the release-candidate branch, updating zuse reloads the vanes, but not userspace.
Say you add the following arm into top-level zuse:
This builds fine, but then trying to do
ohnoin dojo gives a-finderror. Similarly, modifying an existing arm in zuse still gives the old value when inspected from dojo.Also, when trying to run tests (ie
:test [%cores /]) after modifying zuse causes those changes not te be taken into account, resulting in errors if a library uses, say, the newly added++ohno.I did work on jael earlier (#795) that touched zuse, and didn't notice this at all. It's obvious vanes are getting rebuilt properly, but userspace applications continue running on old zuse. Probably not intended behavior?
The text was updated successfully, but these errors were encountered: