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 <mrj...@gmail.com> 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 <doug.cole...@gmail.com>
> 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 <jon.harpe...@gmail.com>
>> 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
>
>
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
