Curtis Yarvin
2015-10-07 17:40:16 UTC
It's actually my bug at a language level, in that it's really easy to make
the compiler go into an infinite loop with wet gates. This will always be
true at a certain level, but it's way too easy at present.
Basically, don't use |* or its cousins unless you're building a generic
subsystem that has a very clear use for them.
Normally, an infinite loop in the compiler isn't a terrible problem -- you
just hit ^C and the location of your error is in the log. But this is
considerably trickier with remote development for obvious reasons. At some
point we'd like to get "network ^C" to happen, but it involves some complex
out-of-band signaling. The simpler solution is a default timeout.
But in the present %ames, an infinite loop triggered over the network is
somewhat unstoppable, because the packet timeout isn't turned on and the
packet fail logic (which should cause a failed request at the message
layer) is disabled. For this reason, I'm afraid ~matfeb-sablud and
~wacwep-ripwes have to be considered sunk. I still could recover them with
extreme maintenance but I don't think it's necessary in this case.
the compiler go into an infinite loop with wet gates. This will always be
true at a certain level, but it's way too easy at present.
Basically, don't use |* or its cousins unless you're building a generic
subsystem that has a very clear use for them.
Normally, an infinite loop in the compiler isn't a terrible problem -- you
just hit ^C and the location of your error is in the log. But this is
considerably trickier with remote development for obvious reasons. At some
point we'd like to get "network ^C" to happen, but it involves some complex
out-of-band signaling. The simpler solution is a default timeout.
But in the present %ames, an infinite loop triggered over the network is
somewhat unstoppable, because the packet timeout isn't turned on and the
packet fail logic (which should cause a failed request at the message
layer) is disabled. For this reason, I'm afraid ~matfeb-sablud and
~wacwep-ripwes have to be considered sunk. I still could recover them with
extreme maintenance but I don't think it's necessary in this case.
Aha, I think we are closing in on this interesting problem. I believe it
to be Anton's bug :-)
to be Anton's bug :-)
http://busfactor1.ca/wacwep-ripwes.tar.bz2
On Wed, Oct 7, 2015 at 10:29 AM, Burton Samograd <
On Wed, Oct 7, 2015 at 10:29 AM, Burton Samograd <
1) Log into sole in the browser (I'm using firefox btw, maybe that's the
problem?)
3) Hang
That's all I did to reproduce it today. I can get you ~wacwep-ripwes as
well since it's more fresh.
--
Burton
problem?)
3) Hang
That's all I did to reproduce it today. I can get you ~wacwep-ripwes as
well since it's more fresh.
--
Burton
It's clearly an infinite event loop, which is relatively hard to debug
when I can't see what the events are. You're also at 286,000 events and
there's a kernel reboot in there, I believe, which makes some of my usual
techniques very difficult.
Any chance you've found a more reliable way to debug this? Actually I
could use the corpse of your other planet, a brain transplant would be much
simpler. But a repro case would be ideal.
On Wed, Oct 7, 2015 at 8:56 AM, Burton Samograd <
when I can't see what the events are. You're also at 286,000 events and
there's a kernel reboot in there, I believe, which makes some of my usual
techniques very difficult.
Any chance you've found a more reliable way to debug this? Actually I
could use the corpse of your other planet, a brain transplant would be much
simpler. But a repro case would be ideal.
On Wed, Oct 7, 2015 at 8:56 AM, Burton Samograd <
I mean from a terminal command line rather than the web command line,
sole. I just have a feeling the problem might be due to sole rather than
what I'm typing...
sole. I just have a feeling the problem might be due to sole rather than
what I'm typing...
From the regular command line? Not sure what you mean. Yes, I'm
typing it at the dojo prompt.
Looking at your corpse now...
On Wed, Oct 7, 2015 at 8:39 AM, Burton Samograd <
typing it at the dojo prompt.
Looking at your corpse now...
On Wed, Oct 7, 2015 at 8:39 AM, Burton Samograd <
I think I killed another planet doing the exact same thing as the
last one (typing that code at the dojo prompt in sole). When you're
testing it out are you using sole to enter the code or working from the
regular command line?
last one (typing that code at the dojo prompt in sole). When you're
testing it out are you using sole to enter the code or working from the
regular command line?
I'd start a new planet, you never know. I'm reconfiguring some
stuff to make moons work better through their planets, anyway.
On Tue, Oct 6, 2015 at 5:12 PM, Burton Samograd <
stuff to make moons work better through their planets, anyway.
On Tue, Oct 6, 2015 at 5:12 PM, Burton Samograd <
No problem. So now that I have an orphaned moon, is it ok to keep
using it or should I start a new setup?
--
Burton
using it or should I start a new setup?
--
Burton
Ok downloaded. Please don't try to operate it until/unless I
send it back :-)
On Tue, Oct 6, 2015 at 4:58 PM, Burton Samograd <
send it back :-)
On Tue, Oct 6, 2015 at 4:58 PM, Burton Samograd <
http://busfactor1.ca/matfeb-sablud.tar.bz2
--
Burton
--
Burton
And yes, probably best to send the entire tree to avoid
confusing unix.c.
On Tue, Oct 6, 2015 at 3:24 PM, Burton Samograd <
confusing unix.c.
On Tue, Oct 6, 2015 at 3:24 PM, Burton Samograd <
Last night I was playing around with sole, and I typed the
Hit enter, typed 10 at the prompt and it just hung up. I was
using webtalk and sole at the time and other than that I wasn't really
doing anything else. I think that's the correct implementation of dec,
but then I thought I might have screwed it up and got into an infinite
loop. After that I shut down matfeb, restarted and it just hung; took the
advice and waited...oops out of loom. Tried again a few times, still the
same. Put it in a while loop today to see if it would work itself out and
it's still down so I'm assuming it's just in a hang/crash loop.
I have a couple more planets that Galen sent me so I'm good.
I'll tar up the system and get it to you; do you just need the .urb
directory or should i tar up all of matfeb-salud/ with mounted directories
as well?
--
Burton
Hit enter, typed 10 at the prompt and it just hung up. I was
using webtalk and sole at the time and other than that I wasn't really
doing anything else. I think that's the correct implementation of dec,
but then I thought I might have screwed it up and got into an infinite
loop. After that I shut down matfeb, restarted and it just hung; took the
advice and waited...oops out of loom. Tried again a few times, still the
same. Put it in a while loop today to see if it would work itself out and
it's still down so I'm assuming it's just in a hang/crash loop.
I have a couple more planets that Galen sent me so I'm good.
I'll tar up the system and get it to you; do you just need the .urb
directory or should i tar up all of matfeb-salud/ with mounted directories
as well?
--
Burton
Yes, definitely. What happened? Any log you can paste?
Also, do you need another planet?
On Tue, Oct 6, 2015 at 2:53 PM, Burton Samograd <
Also, do you need another planet?
On Tue, Oct 6, 2015 at 2:53 PM, Burton Samograd <
I think I've lost matfeb for good, but I'll check when I get
home. Would you like it for science? If so, what's the best way to get it
to you, just tar it up and put it under my http server?
--
Burton
On Tue, Oct 6, 2015 at 3:39 PM, Curtis Yarvin <
home. Would you like it for science? If so, what's the best way to get it
to you, just tar it up and put it under my http server?
--
Burton
On Tue, Oct 6, 2015 at 3:39 PM, Curtis Yarvin <
I think my answer to the macro question is more or less the
same as the stock Haskell answer, which is that if you can't do it by
composing functions, you probably shouldn't do it. Generalizing functions
into cores also helps a good bit. There are a lot of techniques I've
developed for using nested cores, which I can't even really imagine
duplicating in a non-Hoon language. You still probably encounter
repetitive patterns which your Lisp mind wants to make macros out of,
though, and Hoon could use a few more built-in macros - especially in the
areas of list and unit comprehensions.
I like the phrase "Chinese Lisp."
Most of the "warts" I think of as bugs which I can and will
go back and fix, but are not high enough priority right now, or missing
features. There are some issues with name binding in wet gates, etc.
Error messages could be way improved. The language could actively help you
do inheritance. There's even a bug which lets you evade the type system.
Etc. But the world doesn't need Hoon 2.0 quite yet. As for unfixable
warts -- well, I just (in the doc anyway) changed some of the glyph names.
It was a struggle to do this now and it'll never be doable again, so
hopefully the bindings are right.
It's been really fun and valuable having a piece of your
spare time and hopefully it'll continue...
On Tue, Oct 6, 2015 at 11:22 AM, Burton Samograd <
same as the stock Haskell answer, which is that if you can't do it by
composing functions, you probably shouldn't do it. Generalizing functions
into cores also helps a good bit. There are a lot of techniques I've
developed for using nested cores, which I can't even really imagine
duplicating in a non-Hoon language. You still probably encounter
repetitive patterns which your Lisp mind wants to make macros out of,
though, and Hoon could use a few more built-in macros - especially in the
areas of list and unit comprehensions.
I like the phrase "Chinese Lisp."
Most of the "warts" I think of as bugs which I can and will
go back and fix, but are not high enough priority right now, or missing
features. There are some issues with name binding in wet gates, etc.
Error messages could be way improved. The language could actively help you
do inheritance. There's even a bug which lets you evade the type system.
Etc. But the world doesn't need Hoon 2.0 quite yet. As for unfixable
warts -- well, I just (in the doc anyway) changed some of the glyph names.
It was a struggle to do this now and it'll never be doable again, so
hopefully the bindings are right.
It's been really fun and valuable having a piece of your
spare time and hopefully it'll continue...
On Tue, Oct 6, 2015 at 11:22 AM, Burton Samograd <
Well I'm still getting to grokking the meaning and
semantics of the runes but so far it's been pretty straightforward. The
main issue is the renaming of concepts (gate, tile, etc) and my brain can
only absorb so many new things a day, so I keep re-reading hidduc's and
your tutorials to try and solidify the new (well, renamed) concepts in my
head.
There's a learning curve with regards to syntax (double
spaces and irregular forms), but I really like the idea of a typed lisp. I
do clearly see how it is a 'chinese lisp' beneath the 'ascii shredding' :)
I'll be able to let you know more once I get more of the lisp problems
completed, but so far it's been pretty much a 1 for 1 translation of how I
would do them in lisp (whether or not that's correct hoon style is another
thing).
I do like the idea of tall form and I'm finding the lack
of parens quite nice actually. I like how you solved the problem of user
macros ('everyone uses the same squiggles') but I'm curious how they have
been replaced (if they were; maybe that's the difference between wet and
dry gates?).
As a programming language it does feel quite correct. I
don't mind learning curves; I realize they're important for a language with
depth and I've been studying and using Lisp for almost a decade now and I
still learn something new every time I use it. Sometimes I find I get lost
in macro-ology, but that's where the depth comes in that I find I search
for after this many years of programming.
Regarding Urbit, I love the idea of a typed shell and once
you get used to it, it not letting you type incorrect statements is pretty
awesome.
Regarding the renaming of concepts, I find it very
refreshing. There was a good comment on hacker news about how renaming
things is sometimes necessary to move forward, leaving the baggage behind,
and with that being your goal with Urbit/Hoon I'm very much for it. It
does create the idea of the 'initiated', but once your start understanding
the new language, everything becomes quite clear. Personally, I think
you're a creative genius and I look forward to working with you further.
I had a question for you about Hoon. Knowing it best by
being the creator, do you see or know of any warts so far that you were
unable to avoid during its design?
--
Burton
On Tue, Oct 6, 2015 at 10:46 AM, Curtis Yarvin <
semantics of the runes but so far it's been pretty straightforward. The
main issue is the renaming of concepts (gate, tile, etc) and my brain can
only absorb so many new things a day, so I keep re-reading hidduc's and
your tutorials to try and solidify the new (well, renamed) concepts in my
head.
There's a learning curve with regards to syntax (double
spaces and irregular forms), but I really like the idea of a typed lisp. I
do clearly see how it is a 'chinese lisp' beneath the 'ascii shredding' :)
I'll be able to let you know more once I get more of the lisp problems
completed, but so far it's been pretty much a 1 for 1 translation of how I
would do them in lisp (whether or not that's correct hoon style is another
thing).
I do like the idea of tall form and I'm finding the lack
of parens quite nice actually. I like how you solved the problem of user
macros ('everyone uses the same squiggles') but I'm curious how they have
been replaced (if they were; maybe that's the difference between wet and
dry gates?).
As a programming language it does feel quite correct. I
don't mind learning curves; I realize they're important for a language with
depth and I've been studying and using Lisp for almost a decade now and I
still learn something new every time I use it. Sometimes I find I get lost
in macro-ology, but that's where the depth comes in that I find I search
for after this many years of programming.
Regarding Urbit, I love the idea of a typed shell and once
you get used to it, it not letting you type incorrect statements is pretty
awesome.
Regarding the renaming of concepts, I find it very
refreshing. There was a good comment on hacker news about how renaming
things is sometimes necessary to move forward, leaving the baggage behind,
and with that being your goal with Urbit/Hoon I'm very much for it. It
does create the idea of the 'initiated', but once your start understanding
the new language, everything becomes quite clear. Personally, I think
you're a creative genius and I look forward to working with you further.
I had a question for you about Hoon. Knowing it best by
being the creator, do you see or know of any warts so far that you were
unable to avoid during its design?
--
Burton
On Tue, Oct 6, 2015 at 10:46 AM, Curtis Yarvin <
Much appreciated. I guess what I'm really most curious
about is how Hoon feels to someone with a lot of Lisp experience...
On Tue, Oct 6, 2015 at 9:42 AM, Burton Samograd <
about is how Hoon feels to someone with a lot of Lisp experience...
On Tue, Oct 6, 2015 at 9:42 AM, Burton Samograd <
No worries, just letting you know I saw the request.
Burton
On Tue, Oct 6, 2015 at 10:41 AM, Curtis Yarvin <
Burton
On Tue, Oct 6, 2015 at 10:41 AM, Curtis Yarvin <
Doh! I fell asleep right after putting my kids to
bed. Maybe tonight...
On Mon, Oct 5, 2015 at 9:26 PM, Burton Samograd <
bed. Maybe tonight...
On Mon, Oct 5, 2015 at 9:26 PM, Burton Samograd <
Hi Curtis,
You mentioned you wanted to pick my (matfeb-sablud's)
brain about my experience with Urbit in +talk. Ask away if you have
anything specific.
Burton
You mentioned you wanted to pick my (matfeb-sablud's)
brain about my experience with Urbit in +talk. Ask away if you have
anything specific.
Burton
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to urbit-dev+***@googlegroups.com.
To post to this group, send email to urbit-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to urbit-dev+***@googlegroups.com.
To post to this group, send email to urbit-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.