Re: [Factor-talk] Finding helpful messages in stage 2 bootstrap
Hi Jack,
Can you post the full log somewhere on the internet?
Jon
Le mar. 5 févr. 2019 à 01:05, Jack Lucas via Factor-talk <
factor-talk@lists.sourceforge.net> a écrit :
> Hello all. I'm trying to rekludge together freebsd support for factor.
> This has mostly involved trying to integrate some of the older commits that
> have it and using Kernigh's OpenBSD factor fork as a guideline.
>
> I don't know if it'll be good enough for a pull request but it has been
> very helpful for a focused tour of the factor source code. One issue I'm
> struggling with right now is trying to fix a problem that keeps popping up
> in the stage 2 bootstrapping. It compiles everything seemingly fine until
> it reaches the "*io*" component. Then it gets to loading the "
> *basis/unix/utilities/utilities.factor*" before loading "*bootstrap-error*"
> and throwing the "*die*" word.
>
> Now I'm not asking for anyone to take time out of their busy day to fix
> the issue for me, but I am wondering how the general process should go.
> In the data stack from this crash the only issue I can see in my novice
> eyes is a "*source-files.errors:source-file-error T{
> generic.single:no-method f
> io.backend.unix.multiplexers:remove-input-callbacks }*"
>
> But then why is failing at "*utilities.factor*" which doesn't include a
> reference to that word? The method is definitely defined in
> *multiplexers.factor
> *so my first thought is the specialization of it in the freebsd
> *multiplexers/kqueue.factor* is what's screwing up.
>
> My question seems to be thus, if *utilities.factor* is the last file it
> has to load for the *io* group then it must be doing some computation
> after it loads all these files that's causing it to fail. Is there any way
> to see what it does with these files? And likewise is there anyway to
> tell if a file somehow silently failed to load but the bootstrap kept going
> anyway; mostly just for the sake of trying to figure out how to get more
> helpful information out of this process.
>
>
>
> If these questions seem to strike you as the ramblings of a feeble newbie
> than please don't waste any time in passing this by; I'll keep bashing my
> head against the keyboard until I "get it". :P
>
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Finding helpful messages in stage 2 bootstrap
Sure thing.
https://pastebin.com/sWL9P3ex
This includes all 3 stacks. Factor VM was compiled in debug mode if it helps.
Jack
‐‐‐ Original Message ‐‐‐
On Tuesday, February 5, 2019 3:55 AM, Jon Harper wrote:
> Hi Jack,
> Can you post the full log somewhere on the internet?
> Jon
>
> Le mar. 5 févr. 2019 à 01:05, Jack Lucas via Factor-talk
> a écrit :
>
>> Hello all. I'm trying to rekludge together freebsd support for factor.
>> This has mostly involved trying to integrate some of the older commits that
>> have it and using Kernigh's OpenBSD factor fork as a guideline.
>>
>> I don't know if it'll be good enough for a pull request but it has been very
>> helpful for a focused tour of the factor source code. One issue I'm
>> struggling with right now is trying to fix a problem that keeps popping up
>> in the stage 2 bootstrapping. It compiles everything seemingly fine until
>> it reaches the "io" component. Then it gets to loading the
>> "basis/unix/utilities/utilities.factor" before loading "bootstrap-error" and
>> throwing the "die" word.
>>
>> Now I'm not asking for anyone to take time out of their busy day to fix the
>> issue for me, but I am wondering how the general process should go. In the
>> data stack from this crash the only issue I can see in my novice eyes is a
>> "source-files.errors:source-file-error T{ generic.single:no-method f
>> io.backend.unix.multiplexers:remove-input-callbacks }"
>>
>> But then why is failing at "utilities.factor" which doesn't include a
>> reference to that word? The method is definitely defined in
>> multiplexers.factor so my first thought is the specialization of it in the
>> freebsd multiplexers/kqueue.factor is what's screwing up.
>>
>> My question seems to be thus, if utilities.factor is the last file it has
>> to load for the io group then it must be doing some computation after it
>> loads all these files that's causing it to fail. Is there any way to see
>> what it does with these files? And likewise is there anyway to tell if a
>> file somehow silently failed to load but the bootstrap kept going anyway;
>> mostly just for the sake of trying to figure out how to get more helpful
>> information out of this process.
>>
>> If these questions seem to strike you as the ramblings of a feeble newbie
>> than please don't waste any time in passing this by; I'll keep bashing my
>> head against the keyboard until I "get it". :P
>>
>> ___
>> Factor-talk mailing list
>> Factor-talk@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/factor-talk___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Finding helpful messages in stage 2 bootstrap
Hi Jack,
You can try a more minimal bootstrap like this:
./factor -i=boot.unix-x86.64.image -include=math
./factor -i=boot.unix-x86.64.image -include="math compiler"
./factor -i=boot.unix-x86.64.image -exclude="io"
After a quicker bootstrap you can do:
rlwrap ./factor
"io" require
The code at work lives here:
! basis/bootstrap/stage2.factor
: load-component ( name -- )
dup "* Loading the " write write " component" print
"bootstrap." prepend require ;
: load-components ( -- )
"include" "exclude" [ get-global " " split harvest ] bi@ diff
[ load-component ] each ;
That might help you debug it yourself. I'm not sure what is happening
besides obviously not having an implementation for that
``remove-input-callbacks``. You might check which io-backend is set:
io-backend get .
macosx
You can also set one with ``set-io-backend``.
The io-backend in the vm is ``c-io-backend``. You might need to make a
``unix-io-backend`` or something...maybe see how the old freebsd port did
it?
http://downloads.factorcode.org/freebsd-x86-64/
I hope this helps a bit,
Doug
On Tue, Feb 5, 2019 at 7:35 AM Jack Lucas via Factor-talk <
factor-talk@lists.sourceforge.net> wrote:
> Sure thing.
>
> https://pastebin.com/sWL9P3ex
>
> This includes all 3 stacks. Factor VM was compiled in debug mode if it
> helps.
>
> Jack
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, February 5, 2019 3:55 AM, Jon Harper
> wrote:
>
> Hi Jack,
> Can you post the full log somewhere on the internet?
> Jon
>
> Le mar. 5 févr. 2019 à 01:05, Jack Lucas via Factor-talk <
> factor-talk@lists.sourceforge.net> a écrit :
>
>> Hello all. I'm trying to rekludge together freebsd support for factor.
>> This has mostly involved trying to integrate some of the older commits that
>> have it and using Kernigh's OpenBSD factor fork as a guideline.
>>
>> I don't know if it'll be good enough for a pull request but it has been
>> very helpful for a focused tour of the factor source code. One issue I'm
>> struggling with right now is trying to fix a problem that keeps popping up
>> in the stage 2 bootstrapping. It compiles everything seemingly fine until
>> it reaches the "*io*" component. Then it gets to loading the "
>> *basis/unix/utilities/utilities.factor*" before loading "
>> *bootstrap-error*" and throwing the "*die*" word.
>>
>> Now I'm not asking for anyone to take time out of their busy day to fix
>> the issue for me, but I am wondering how the general process should go.
>> In the data stack from this crash the only issue I can see in my novice
>> eyes is a "*source-files.errors:source-file-error T{
>> generic.single:no-method f
>> io.backend.unix.multiplexers:remove-input-callbacks }*"
>>
>> But then why is failing at "*utilities.factor*" which doesn't include a
>> reference to that word? The method is definitely defined in
>> *multiplexers.factor
>> *so my first thought is the specialization of it in the freebsd
>> *multiplexers/kqueue.factor* is what's screwing up.
>>
>> My question seems to be thus, if *utilities.factor* is the last file it
>> has to load for the *io* group then it must be doing some computation
>> after it loads all these files that's causing it to fail. Is there any way
>> to see what it does with these files? And likewise is there anyway to
>> tell if a file somehow silently failed to load but the bootstrap kept going
>> anyway; mostly just for the sake of trying to figure out how to get more
>> helpful information out of this process.
>>
>>
>>
>> If these questions seem to strike you as the ramblings of a feeble newbie
>> than please don't waste any time in passing this by; I'll keep bashing my
>> head against the keyboard until I "get it". :P
>>
>>
>> ___
>> Factor-talk mailing list
>> Factor-talk@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Finding helpful messages in stage 2 bootstrap
That’s perfect. I think this’ll set me back on track. Thanks Doug!
Jack
On Tue, Feb 5, 2019 at 9:37 AM, Doug Coleman wrote:
> Hi Jack,
>
> You can try a more minimal bootstrap like this:
>
> ./factor -i=boot.unix-x86.64.image -include=math
> ./factor -i=boot.unix-x86.64.image -include="math compiler"
> ./factor -i=boot.unix-x86.64.image -exclude="io"
>
> After a quicker bootstrap you can do:
> rlwrap ./factor
> "io" require
>
> The code at work lives here:
>
> ! basis/bootstrap/stage2.factor
> : load-component ( name -- )
> dup "* Loading the " write write " component" print
> "bootstrap." prepend require ;
>
> : load-components ( -- )
> "include" "exclude" [ get-global " " split harvest ] bi@ diff
> [ load-component ] each ;
>
> That might help you debug it yourself. I'm not sure what is happening besides
> obviously not having an implementation for that ``remove-input-callbacks``.
> You might check which io-backend is set:
>
> io-backend get .
> macosx
>
> You can also set one with ``set-io-backend``.
>
> The io-backend in the vm is ``c-io-backend``. You might need to make a
> ``unix-io-backend`` or something...maybe see how the old freebsd port did it?
>
> http://downloads.factorcode.org/freebsd-x86-64/
>
> I hope this helps a bit,
> Doug
>
> On Tue, Feb 5, 2019 at 7:35 AM Jack Lucas via Factor-talk
> wrote:
>
>> Sure thing.
>>
>> https://pastebin.com/sWL9P3ex
>>
>> This includes all 3 stacks. Factor VM was compiled in debug mode if it
>> helps.
>>
>> Jack
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Tuesday, February 5, 2019 3:55 AM, Jon Harper
>> wrote:
>>
>>> Hi Jack,
>>> Can you post the full log somewhere on the internet?
>>> Jon
>>>
>>> Le mar. 5 févr. 2019 à 01:05, Jack Lucas via Factor-talk
>>> a écrit :
>>>
Hello all. I'm trying to rekludge together freebsd support for factor.
This has mostly involved trying to integrate some of the older commits
that have it and using Kernigh's OpenBSD factor fork as a guideline.
I don't know if it'll be good enough for a pull request but it has been
very helpful for a focused tour of the factor source code. One issue I'm
struggling with right now is trying to fix a problem that keeps popping up
in the stage 2 bootstrapping. It compiles everything seemingly fine until
it reaches the "io" component. Then it gets to loading the
"basis/unix/utilities/utilities.factor" before loading "bootstrap-error"
and throwing the "die" word.
Now I'm not asking for anyone to take time out of their busy day to fix
the issue for me, but I am wondering how the general process should go.
In the data stack from this crash the only issue I can see in my novice
eyes is a "source-files.errors:source-file-error T{
generic.single:no-method f
io.backend.unix.multiplexers:remove-input-callbacks }"
But then why is failing at "utilities.factor" which doesn't include a
reference to that word? The method is definitely defined in
multiplexers.factor so my first thought is the specialization of it in the
freebsd multiplexers/kqueue.factor is what's screwing up.
My question seems to be thus, if utilities.factor is the last file it has
to load for the io group then it must be doing some computation after it
loads all these files that's causing it to fail. Is there any way to see
what it does with these files? And likewise is there anyway to tell if a
file somehow silently failed to load but the bootstrap kept going anyway;
mostly just for the sake of trying to figure out how to get more helpful
information out of this process.
If these questions seem to strike you as the ramblings of a feeble newbie
than please don't waste any time in passing this by; I'll keep bashing my
head against the keyboard until I "get it". :P
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
>> ___
>> Factor-talk mailing list
>> Factor-talk@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/factor-talk___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Finding helpful messages in stage 2 bootstrap
You might also find this informative:
https://github.com/factor/factor/commit/8cf18d1a82f08d1e9edf20f38b42eb1699ca0e67
> On Feb 5, 2019, at 7:28 AM, Jack Lucas via Factor-talk
> wrote:
>
> That’s perfect. I think this’ll set me back on track. Thanks Doug!
>
> Jack
>
>
>> On Tue, Feb 5, 2019 at 9:37 AM, Doug Coleman wrote:
>> Hi Jack,
>>
>> You can try a more minimal bootstrap like this:
>>
>> ./factor -i=boot.unix-x86.64.image -include=math
>> ./factor -i=boot.unix-x86.64.image -include="math compiler"
>> ./factor -i=boot.unix-x86.64.image -exclude="io"
>>
>> After a quicker bootstrap you can do:
>> rlwrap ./factor
>> "io" require
>>
>> The code at work lives here:
>>
>> ! basis/bootstrap/stage2.factor
>> : load-component ( name -- )
>> dup "* Loading the " write write " component" print
>> "bootstrap." prepend require ;
>>
>> : load-components ( -- )
>> "include" "exclude" [ get-global " " split harvest ] bi@ diff
>> [ load-component ] each ;
>>
>>
>> That might help you debug it yourself. I'm not sure what is happening
>> besides obviously not having an implementation for that
>> ``remove-input-callbacks``. You might check which io-backend is set:
>>
>> io-backend get .
>> macosx
>>
>> You can also set one with ``set-io-backend``.
>>
>> The io-backend in the vm is ``c-io-backend``. You might need to make a
>> ``unix-io-backend`` or something...maybe see how the old freebsd port did it?
>>
>> http://downloads.factorcode.org/freebsd-x86-64/
>>
>> I hope this helps a bit,
>> Doug
>>
>>> On Tue, Feb 5, 2019 at 7:35 AM Jack Lucas via Factor-talk
>>> wrote:
>>> Sure thing.
>>>
>>> https://pastebin.com/sWL9P3ex
>>>
>>> This includes all 3 stacks. Factor VM was compiled in debug mode if it
>>> helps.
>>>
>>> Jack
>>>
>>>
>>>
>>> ‐‐‐ Original Message ‐‐‐
On Tuesday, February 5, 2019 3:55 AM, Jon Harper
wrote:
Hi Jack,
Can you post the full log somewhere on the internet?
Jon
> Le mar. 5 févr. 2019 à 01:05, Jack Lucas via Factor-talk
> a écrit :
> Hello all. I'm trying to rekludge together freebsd support for factor.
> This has mostly involved trying to integrate some of the older commits
> that have it and using Kernigh's OpenBSD factor fork as a guideline.
>
> I don't know if it'll be good enough for a pull request but it has been
> very helpful for a focused tour of the factor source code. One issue I'm
> struggling with right now is trying to fix a problem that keeps popping
> up in the stage 2 bootstrapping. It compiles everything seemingly fine
> until it reaches the "io" component. Then it gets to loading the
> "basis/unix/utilities/utilities.factor" before loading "bootstrap-error"
> and throwing the "die" word.
>
> Now I'm not asking for anyone to take time out of their busy day to fix
> the issue for me, but I am wondering how the general process should go.
> In the data stack from this crash the only issue I can see in my novice
> eyes is a "source-files.errors:source-file-error T{
> generic.single:no-method f
> io.backend.unix.multiplexers:remove-input-callbacks }"
>
> But then why is failing at "utilities.factor" which doesn't include a
> reference to that word? The method is definitely defined in
> multiplexers.factor so my first thought is the specialization of it in
> the freebsd multiplexers/kqueue.factor is what's screwing up.
>
> My question seems to be thus, if utilities.factor is the last file it
> has to load for the io group then it must be doing some computation after
> it loads all these files that's causing it to fail. Is there any way to
> see what it does with these files? And likewise is there anyway to tell
> if a file somehow silently failed to load but the bootstrap kept going
> anyway; mostly just for the sake of trying to figure out how to get more
> helpful information out of this process.
>
>
>
> If these questions seem to strike you as the ramblings of a feeble newbie
> than please don't waste any time in passing this by; I'll keep bashing
> my head against the keyboard until I "get it". :P
>
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>
>>> ___
>>> Factor-talk mailing list
>>> Factor-talk@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.ne
Re: [Factor-talk] Finding helpful messages in stage 2 bootstrap
Right! ``{free,open,net}bsd`` can be bsd io-backend again.
I don't mind setting up test machines for freebsd and openbsd if someone
else does most of the work getting Factor them ported again.
Doug
On Tue, Feb 5, 2019 at 10:46 AM John Benediktsson wrote:
> You might also find this informative:
>
>
> https://github.com/factor/factor/commit/8cf18d1a82f08d1e9edf20f38b42eb1699ca0e67
>
> On Feb 5, 2019, at 7:28 AM, Jack Lucas via Factor-talk <
> factor-talk@lists.sourceforge.net> wrote:
>
> That’s perfect. I think this’ll set me back on track. Thanks Doug!
>
> Jack
>
>
> On Tue, Feb 5, 2019 at 9:37 AM, Doug Coleman
> wrote:
>
> Hi Jack,
>
> You can try a more minimal bootstrap like this:
>
> ./factor -i=boot.unix-x86.64.image -include=math
> ./factor -i=boot.unix-x86.64.image -include="math compiler"
> ./factor -i=boot.unix-x86.64.image -exclude="io"
>
> After a quicker bootstrap you can do:
> rlwrap ./factor
> "io" require
>
> The code at work lives here:
>
> ! basis/bootstrap/stage2.factor
> : load-component ( name -- )
> dup "* Loading the " write write " component" print
> "bootstrap." prepend require ;
>
> : load-components ( -- )
> "include" "exclude" [ get-global " " split harvest ] bi@ diff
> [ load-component ] each ;
>
>
> That might help you debug it yourself. I'm not sure what is happening
> besides obviously not having an implementation for that
> ``remove-input-callbacks``. You might check which io-backend is set:
>
> io-backend get .
> macosx
>
> You can also set one with ``set-io-backend``.
>
> The io-backend in the vm is ``c-io-backend``. You might need to make a
> ``unix-io-backend`` or something...maybe see how the old freebsd port did
> it?
>
> http://downloads.factorcode.org/freebsd-x86-64/
>
> I hope this helps a bit,
> Doug
>
> On Tue, Feb 5, 2019 at 7:35 AM Jack Lucas via Factor-talk <
> factor-talk@lists.sourceforge.net> wrote:
>
>> Sure thing.
>>
>> https://pastebin.com/sWL9P3ex
>>
>> This includes all 3 stacks. Factor VM was compiled in debug mode if it
>> helps.
>>
>> Jack
>>
>>
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Tuesday, February 5, 2019 3:55 AM, Jon Harper
>> wrote:
>>
>> Hi Jack,
>> Can you post the full log somewhere on the internet?
>> Jon
>>
>> Le mar. 5 févr. 2019 à 01:05, Jack Lucas via Factor-talk <
>> factor-talk@lists.sourceforge.net> a écrit :
>>
>>> Hello all. I'm trying to rekludge together freebsd support for factor.
>>> This has mostly involved trying to integrate some of the older commits that
>>> have it and using Kernigh's OpenBSD factor fork as a guideline.
>>>
>>> I don't know if it'll be good enough for a pull request but it has been
>>> very helpful for a focused tour of the factor source code. One issue I'm
>>> struggling with right now is trying to fix a problem that keeps popping up
>>> in the stage 2 bootstrapping. It compiles everything seemingly fine until
>>> it reaches the "*io*" component. Then it gets to loading the "
>>> *basis/unix/utilities/utilities.factor*" before loading "
>>> *bootstrap-error*" and throwing the "*die*" word.
>>>
>>> Now I'm not asking for anyone to take time out of their busy day to fix
>>> the issue for me, but I am wondering how the general process should go.
>>> In the data stack from this crash the only issue I can see in my novice
>>> eyes is a "*source-files.errors:source-file-error T{
>>> generic.single:no-method f
>>> io.backend.unix.multiplexers:remove-input-callbacks }*"
>>>
>>> But then why is failing at "*utilities.factor*" which doesn't include a
>>> reference to that word? The method is definitely defined in
>>> *multiplexers.factor
>>> *so my first thought is the specialization of it in the freebsd
>>> *multiplexers/kqueue.factor* is what's screwing up.
>>>
>>> My question seems to be thus, if *utilities.factor* is the last file
>>> it has to load for the *io* group then it must be doing some
>>> computation after it loads all these files that's causing it to fail. Is
>>> there any way to see what it does with these files? And likewise is there
>>> anyway to tell if a file somehow silently failed to load but the bootstrap
>>> kept going anyway; mostly just for the sake of trying to figure out how to
>>> get more helpful information out of this process.
>>>
>>>
>>>
>>> If these questions seem to strike you as the ramblings of a feeble
>>> newbie than please don't waste any time in passing this by; I'll keep
>>> bashing my head against the keyboard until I "get it". :P
>>>
>>>
>>> ___
>>> Factor-talk mailing list
>>> Factor-talk@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>
>>
>> ___
>> Factor-talk mailing list
>> Factor-talk@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
>
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.s
Re: [Factor-talk] Finding helpful messages in stage 2 bootstrap
Hey Doug,
Once I get FreeBSD working I don’t mind doing most of the grunt work in getting
net and openbsd back in and updated. Then maybe someone who knows the factor
far better can review it. I’m trying to move off Linux to BSD but I really
want to take factor with me.
Jack
On Tue, Feb 5, 2019 at 11:10 AM, Doug Coleman wrote:
> Right! ``{free,open,net}bsd`` can be bsd io-backend again.
>
> I don't mind setting up test machines for freebsd and openbsd if someone else
> does most of the work getting Factor them ported again.
>
> Doug
>
> On Tue, Feb 5, 2019 at 10:46 AM John Benediktsson wrote:
>
>> You might also find this informative:
>>
>> https://github.com/factor/factor/commit/8cf18d1a82f08d1e9edf20f38b42eb1699ca0e67
>>
>> On Feb 5, 2019, at 7:28 AM, Jack Lucas via Factor-talk
>> wrote:
>>
>>> That’s perfect. I think this’ll set me back on track. Thanks Doug!
>>>
>>> Jack
>>>
>>> On Tue, Feb 5, 2019 at 9:37 AM, Doug Coleman wrote:
>>>
Hi Jack,
You can try a more minimal bootstrap like this:
./factor -i=boot.unix-x86.64.image -include=math
./factor -i=boot.unix-x86.64.image -include="math compiler"
./factor -i=boot.unix-x86.64.image -exclude="io"
After a quicker bootstrap you can do:
rlwrap ./factor
"io" require
The code at work lives here:
! basis/bootstrap/stage2.factor
: load-component ( name -- )
dup "* Loading the " write write " component" print
"bootstrap." prepend require ;
: load-components ( -- )
"include" "exclude" [ get-global " " split harvest ] bi@ diff
[ load-component ] each ;
That might help you debug it yourself. I'm not sure what is happening
besides obviously not having an implementation for that
``remove-input-callbacks``. You might check which io-backend is set:
io-backend get .
macosx
You can also set one with ``set-io-backend``.
The io-backend in the vm is ``c-io-backend``. You might need to make a
``unix-io-backend`` or something...maybe see how the old freebsd port did
it?
http://downloads.factorcode.org/freebsd-x86-64/
I hope this helps a bit,
Doug
On Tue, Feb 5, 2019 at 7:35 AM Jack Lucas via Factor-talk
wrote:
> Sure thing.
>
> https://pastebin.com/sWL9P3ex
>
> This includes all 3 stacks. Factor VM was compiled in debug mode if it
> helps.
>
> Jack
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, February 5, 2019 3:55 AM, Jon Harper
> wrote:
>
>> Hi Jack,
>> Can you post the full log somewhere on the internet?
>> Jon
>>
>> Le mar. 5 févr. 2019 à 01:05, Jack Lucas via Factor-talk
>> a écrit :
>>
>>> Hello all. I'm trying to rekludge together freebsd support for factor.
>>> This has mostly involved trying to integrate some of the older commits
>>> that have it and using Kernigh's OpenBSD factor fork as a guideline.
>>>
>>> I don't know if it'll be good enough for a pull request but it has been
>>> very helpful for a focused tour of the factor source code. One issue
>>> I'm struggling with right now is trying to fix a problem that keeps
>>> popping up in the stage 2 bootstrapping. It compiles everything
>>> seemingly fine until it reaches the "io" component. Then it gets to
>>> loading the "basis/unix/utilities/utilities.factor" before loading
>>> "bootstrap-error" and throwing the "die" word.
>>>
>>> Now I'm not asking for anyone to take time out of their busy day to fix
>>> the issue for me, but I am wondering how the general process should
>>> go. In the data stack from this crash the only issue I can see in my
>>> novice eyes is a "source-files.errors:source-file-error T{
>>> generic.single:no-method f
>>> io.backend.unix.multiplexers:remove-input-callbacks }"
>>>
>>> But then why is failing at "utilities.factor" which doesn't include a
>>> reference to that word? The method is definitely defined in
>>> multiplexers.factor so my first thought is the specialization of it in
>>> the freebsd multiplexers/kqueue.factor is what's screwing up.
>>>
>>> My question seems to be thus, if utilities.factor is the last file it
>>> has to load for the io group then it must be doing some computation
>>> after it loads all these files that's causing it to fail. Is there any
>>> way to see what it does with these files? And likewise is there
>>> anyway to tell if a file somehow silently failed to load but the
>>> bootstrap kept going anyway; mostly just for the sake of trying to
>>> figure out how to get more helpful information out of this process.
>>>
>>> If these questions seem to strike you as the ramblings of a feeble
>>> newbie than please don't waste any time in passing this
Re: [Factor-talk] How to use local variable
Hi, Thank you for your advice! It was very beneficial. -- KUSUMOTO Norio > 2019/02/04 22:19、Philip Dexter のメール: > > Hi, > > Check out the "Mutable bindings" example here: > https://docs.factorcode.org/content/article-locals-examples.html > > Note the use of the bang (!) when initially binding the variable and > then again when mutating the variable. > > Hope that helps! > > > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] How to use local variable
Hi, Thanks a lot! I understand how to use lexical variables because of your advice. -- KUSUMOTO Norio > 2019/02/05 2:50、Alexander Ilin のメール: > > This will work as you expected: > > USE: locals > :: fnc ( -- ) 0 :> i! 3 [ i 1 + i! i . ] times ; > fnc > > 1 > 2 > 3 > > > 04.02.2019, 09:17, "KUSUMOTO, Norio" : >> Hello to all, >> >> I’m writing a hierarchical finite state machine library as my first Factor >> program. >> It seems to me that It works for once now! But, there are some questions in >> my mind. >> >> I could not handle local variables well, so I tried below words in a >> listener. >> >> USE: locals >> :: fnc ( -- ) 0 :> i 3 [ i 1 + :> i i . ] times ; >> fnc >> >> These words returned: >> 1 >> 1 >> 1 >> >> Originally, I wanted to know that why the below words didn’t perform as >> expected. >> >> USE: locals >> :: fnc2 ( -- ) 0 :> i [ i 3 < ] [ i 1 + :> i i . ] while ; >> >> It will perform as a infinite loop. >> >> In these cases, how should I write them? >> >> -- >> KUSUMOTO Norio >> >> ___ >> Factor-talk mailing list >> Factor-talk@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/factor-talk > > ---=--- > Александр > > > > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
