Re: [Factor-talk] Any way of making sense of what's in the boot image?
: pic-tail-reg ( -- reg ) EDX ;
//stack pointer // ?: stack-reg ( -- reg ) ESP ;
// stack frame pointer: frame-reg ( -- reg ) EBP ;
// virtual machine object base: vm-reg ( -- reg ) EBX ;
: ctx-reg ( -- reg ) EBP ;
// non-volatile registers -- these would be registers needing to be preserved
(and that callers can count on being preserved)?: nv-regs ( -- seq ) { ESI EDI
EBX } ;
// volatile registers -- these would be registers one is free to use (and that
callers cannot count on being preserved)?: volatile-regs ( -- seq ) { EAX ECX
EDX } ;
// ?: nv-reg ( -- reg ) ESI ;
// ?: ds-reg ( -- reg ) ESI ;
// ?: rs-reg ( -- reg ) EDI ;
// ?: link-reg ( -- reg ) EBX ; Would anybody be able to validate
assumptions articulated above and fill in missing pieces. This is good
foundational knowledge to operate in general with.
From: mclag...@hotmail.com
Date: Thu, 16 Aug 2012 13:15:48 -0400
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Great, thanks.
Sent from my iPhone
On Aug 16, 2012, at 1:11 PM, John Benediktsson mrj...@gmail.com wrote:
So then, John, does that mean that in the [ 4 slot { array} declare ], that
I'm getting the slot named array which is at offset 4 (and then declaring
that to be an array, so as to disable some of the type safety checks)?
Yes, the hashtable code is written at a bit lower level and thus maybe a little
harder to read than one might normally write in Factor since it is one of the
building blocks that everything is built upon. It is also possible that some
of the compiler optimizations that have been written in the last couple of
years make some of those declarations unnecessary, although I'd have to look
into it more to know for sure.
Also, due to the bootstrapping mechanism, some of the higher level language
constructs like locals and fry quotations are not available yet. That is
something we hope to fix at some future point.
Here it says slot takes two incoming values: an obj and a non-negative
fixnum, which is the nth slot. In the hashtable slot-specs you list below
there are only three slots listed, but it does say that the slot named array
is at offset 4. Is it this offset number that is being specified by the m
parameter? And thus is the array I am seeing in my original description the
contents of the array slot of the hashtable that was originally on the stack?
That makes sense to me. And the fact that the array is 128 slots long
(allowing flattened representation of 64 key-value pairs) just means that the
underlying array in the hashtable has 64 buckets. Is this a correct
interpretation. If it is, it makes sense that the actual 26 values stored in
the hash table would be dispersed throught the 64 buckets, because this is what
a hashtable does.
Yes, exactly! The slot-spec tuple provides a generic description of what is
to be found in this case at offset 4.
Best,
John.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include
Re: [Factor-talk] Any way of making sense of what's in the boot image?
A few more: // ?: shift-arg ( -- reg ) ECX ;
// ?: div-arg ( -- reg ) EAX ;
// ?: mod-arg ( -- reg ) EDX ;
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 17 Aug 2012 14:03:30 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
// ?
: pic-tail-reg ( -- reg ) EDX ;
// stack pointer
: stack-reg ( -- reg ) ESP ;
// stack frame pointer
: frame-reg ( -- reg ) EBP ;
// virtual machine object base
: vm-reg ( -- reg ) EBX ;
: ctx-reg ( -- reg ) EBP ;
// non-volatile registers -- these would be registers needing to be preserved
(and that callers can count on being preserved)?
: nv-regs ( -- seq ) { ESI EDI EBX } ;
// volatile registers -- these would be registers one is free to use (and that
callers cannot count on being preserved)?
: volatile-regs ( -- seq ) { EAX ECX EDX } ;
// ?
: nv-reg ( -- reg ) ESI ;
// ?
: ds-reg ( -- reg ) ESI ;
// ?
: rs-reg ( -- reg ) EDI ;
// ?
: link-reg ( -- reg ) EBX ;
Would anybody be able to validate assumptions articulated above and fill in
missing pieces. This is good foundational knowledge to operate in general with.
From: mclag...@hotmail.com
Date: Thu, 16 Aug 2012 13:15:48 -0400
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Great, thanks.
Sent from my iPhone
On Aug 16, 2012, at 1:11 PM, John Benediktsson mrj...@gmail.com wrote:
So then, John, does that mean that in the [ 4 slot { array} declare ], that
I'm getting the slot named array which is at offset 4 (and then declaring
that to be an array, so as to disable some of the type safety checks)?
Yes, the hashtable code is written at a bit lower level and thus maybe a little
harder to read than one might normally write in Factor since it is one of the
building blocks that everything is built upon. It is also possible that some
of the compiler optimizations that have been written in the last couple of
years make some of those declarations unnecessary, although I'd have to look
into it more to know for sure.
Also, due to the bootstrapping mechanism, some of the higher level language
constructs like locals and fry quotations are not available yet. That is
something we hope to fix at some future point.
Here it says slot takes two incoming values: an obj and a non-negative
fixnum, which is the nth slot. In the hashtable slot-specs you list below
there are only three slots listed, but it does say that the slot named array
is at offset 4. Is it this offset number that is being specified by the m
parameter? And thus is the array I am seeing in my original description the
contents of the array slot of the hashtable that was originally on the stack?
That makes sense to me. And the fact that the array is 128 slots long
(allowing flattened representation of 64 key-value pairs) just means that the
underlying array in the hashtable has 64 buckets. Is this a correct
interpretation. If it is, it makes sense that the actual 26 values stored in
the hash table would be dispersed throught the 64 buckets, because this is what
a hashtable does.
Yes, exactly! The slot-spec tuple provides a generic description of what is
to be found in this case at offset 4.
Best,
John.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
Re: [Factor-talk] Any way of making sense of what's in the boot image?
pic-tail-reg = polymorphic inline cache tail call register
ds-reg = data stack register
rs-reg = retain stack register
nv-reg: might help to see
https://github.com/slavapestov/factor/blob/master/basis/cpu/x86/bootstrap.factor#L14
link-reg: only place it seems to be used is
https://github.com/slavapestov/factor/blob/master/basis/cpu/x86/bootstrap.factor#L49
shift-arg, div-arg, mod-arg: seem to be used in x86 bootstrapping for holding
arithmetic arguments; e.g.,
https://github.com/slavapestov/factor/blob/master/basis/cpu/x86/bootstrap.factor#L561
That's as much as I can gather from a glance,
--Alex Vondrak
From: Michael Clagett [mclag...@hotmail.com]
Sent: Friday, August 17, 2012 7:08 AM
To: Factor-Talk
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
A few more:
// ?
: shift-arg ( -- reg ) ECX ;
// ?
: div-arg ( -- reg ) EAX ;
// ?
: mod-arg ( -- reg ) EDX ;
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 17 Aug 2012 14:03:30 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
// ?
: pic-tail-reg ( -- reg ) EDX ;
// stack pointer
: stack-reg ( -- reg ) ESP ;
// stack frame pointer
: frame-reg ( -- reg ) EBP ;
// virtual machine object base
: vm-reg ( -- reg ) EBX ;
: ctx-reg ( -- reg ) EBP ;
// non-volatile registers -- these would be registers needing to be preserved
(and that callers can count on being preserved)?
: nv-regs ( -- seq ) { ESI EDI EBX } ;
// volatile registers -- these would be registers one is free to use (and that
callers cannot count on being preserved)?
: volatile-regs ( -- seq ) { EAX ECX EDX } ;
// ?
: nv-reg ( -- reg ) ESI ;
// ?
: ds-reg ( -- reg ) ESI ;
// ?
: rs-reg ( -- reg ) EDI ;
// ?
: link-reg ( -- reg ) EBX ;
Would anybody be able to validate assumptions articulated above and fill in
missing pieces. This is good foundational knowledge to operate in general with.
From: mclag...@hotmail.com
Date: Thu, 16 Aug 2012 13:15:48 -0400
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
Great, thanks.
Sent from my iPhone
On Aug 16, 2012, at 1:11 PM, John Benediktsson
mrj...@gmail.commailto:mrj...@gmail.com wrote:
So then, John, does that mean that in the [ 4 slot { array} declare ], that I'm
getting the slot named array which is at offset 4 (and then declaring that to
be an array, so as to disable some of the type safety checks)?
Yes, the hashtable code is written at a bit lower level and thus maybe a little
harder to read than one might normally write in Factor since it is one of the
building blocks that everything is built upon. It is also possible that some
of the compiler optimizations that have been written in the last couple of
years make some of those declarations unnecessary, although I'd have to look
into it more to know for sure.
Also, due to the bootstrapping mechanism, some of the higher level language
constructs like locals and fry quotations are not available yet. That is
something we hope to fix at some future point.
Here it says slot takes two incoming values: an obj and a non-negative fixnum,
which is the nth slot. In the hashtable slot-specs you list below there are
only three slots listed, but it does say that the slot named array is at
offset 4. Is it this offset number that is being specified by the m
parameter? And thus is the array I am seeing in my original description the
contents of the array slot of the hashtable that was originally on the stack?
That makes sense to me. And the fact that the array is 128 slots long
(allowing flattened representation of 64 key-value pairs) just means that the
underlying array in the hashtable has 64 buckets. Is this a correct
interpretation. If it is, it makes sense that the actual 26 values stored in
the hash table would be dispersed throught the 64 buckets, because this is what
a hashtable does.
Yes, exactly! The slot-spec tuple provides a generic description of what is
to be found in this case at offset 4.
Best,
John.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.netmailto:Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference Exclusive live event will cover
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thank you Alex. Seeing the polymorphic inline caching reference makes me
realize that I really need to go back and reread Slava's (et. al) various blogs
that have been produced through the years. I read them all once, but that was
a couple years ago -- not knowing what I know now. This should help me not
revisit ground in this forum that has already been documented elsewhere. A
bit more patience, everybody please, while I work out an effective (and
self-sufficient) internals exploration strategy.
From: ajvond...@csupomona.edu
To: factor-talk@lists.sourceforge.net
Date: Fri, 17 Aug 2012 08:46:46 -0700
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
pic-tail-reg = polymorphic inline cache tail call register
ds-reg = data stack register
rs-reg = retain stack register
nv-reg: might help to see
https://github.com/slavapestov/factor/blob/master/basis/cpu/x86/bootstrap.factor#L14
link-reg: only place it seems to be used is
https://github.com/slavapestov/factor/blob/master/basis/cpu/x86/bootstrap.factor#L49
shift-arg, div-arg, mod-arg: seem to be used in x86 bootstrapping for holding
arithmetic arguments; e.g.,
https://github.com/slavapestov/factor/blob/master/basis/cpu/x86/bootstrap.factor#L561
That's as much as I can gather from a glance,
--Alex Vondrak
From: Michael Clagett [mclag...@hotmail.com]
Sent: Friday, August 17, 2012 7:08 AM
To: Factor-Talk
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
A few more:
// ?
: shift-arg ( -- reg ) ECX ;
// ?
: div-arg ( -- reg ) EAX ;
// ?
: mod-arg ( -- reg ) EDX ;
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 17 Aug 2012 14:03:30 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
// ?
: pic-tail-reg ( -- reg ) EDX ;
// stack pointer
: stack-reg ( -- reg ) ESP ;
// stack frame pointer
: frame-reg ( -- reg ) EBP ;
// virtual machine object base
: vm-reg ( -- reg ) EBX ;
: ctx-reg ( -- reg ) EBP ;
// non-volatile registers -- these would be registers needing to be
preserved (and that callers can count on being preserved)?
: nv-regs ( -- seq ) { ESI EDI EBX } ;
// volatile registers -- these would be registers one is free to use (and
that callers cannot count on being preserved)?
: volatile-regs ( -- seq ) { EAX ECX EDX } ;
// ?
: nv-reg ( -- reg ) ESI ;
// ?
: ds-reg ( -- reg ) ESI ;
// ?
: rs-reg ( -- reg ) EDI ;
// ?
: link-reg ( -- reg ) EBX ;
Would anybody be able to validate assumptions articulated above and fill in
missing pieces. This is good foundational knowledge to operate in general
with.
From: mclag...@hotmail.com
Date: Thu, 16 Aug 2012 13:15:48 -0400
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Great, thanks.
Sent from my iPhone
On Aug 16, 2012, at 1:11 PM, John Benediktsson
mrj...@gmail.commailto:mrj...@gmail.com wrote:
So then, John, does that mean that in the [ 4 slot { array} declare ], that
I'm getting the slot named array which is at offset 4 (and then declaring
that to be an array, so as to disable some of the type safety checks)?
Yes, the hashtable code is written at a bit lower level and thus maybe a
little harder to read than one might normally write in Factor since it is one
of the building blocks that everything is built upon. It is also possible
that some of the compiler optimizations that have been written in the last
couple of years make some of those declarations unnecessary, although I'd
have to look into it more to know for sure.
Also, due to the bootstrapping mechanism, some of the higher level language
constructs like locals and fry quotations are not available yet. That is
something we hope to fix at some future point.
Here it says slot takes two incoming values: an obj and a non-negative
fixnum, which is the nth slot. In the hashtable slot-specs you list below
there are only three slots listed, but it does say that the slot named
array is at offset 4. Is it this offset number that is being specified by
the m parameter? And thus is the array I am seeing in my original
description the contents of the array slot of the hashtable that was
originally on the stack? That makes sense to me. And the fact that the
array is 128 slots long (allowing flattened representation of 64 key-value
pairs) just means that the underlying array in the hashtable has 64 buckets.
Is this a correct interpretation. If it is, it makes sense that the actual
26 values stored in the hash table would be dispersed throught the 64
buckets, because this is what a hashtable does.
Yes, exactly! The slot-spec tuple
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Hi -- Okay. I'm going to ask for my first lifeline. :) I'm tracing through
some arcane stuff indeed. Everything is going along swimmingly. I get to the
word new-key@, which at its start wants to execute [ array 2dup hash@ 0 f
(new-key@) ] with the keep combinator. All good so far. array resolves
to [ 4 slot { array } declare ], which I believe should mean get the 4th slot
of the object on top of stack and declare to Factor that you know for sure it
is an array. The object on the top of the stack, according to the Inspector,
is a 26-slot hash table that includes such keys as architecture, auto-use?,
bootstrap-syntax, bootsrapping?, etc. Now comes the part that baffles me.
When I get to executing slot (whether I try to step past it or descend into
it), the Walker simply moves me all the way to the end of the qotation (past
declare) and I see the hash-table and index from the top of the data stack
replaced with a 128-element array that has the 26 key-value pairs from the
former hash table spread out through the array interspersed by tombstone
objects; each of these key-value pairs that appear occupy two adjacent array
slots. But I'm completely mystified as to how the contents of the hash-table
got mapped to the array slots they now occupy (there doesn't seem to be any
rhyme or reason). And I have little insight into the code that accomplished
this. Moreover I apparently can't see the 4th slot of the original object in
the Inspector, as it only shows me three slots on the data stack trace, but
organizes them alphabetically when I double-click to open the Inspector window.
Don't know if any of this was intelligble. But maybe one of you compiler guys
can give me a clue as to how I can understand this. I'm having to reverse
engineer my understanding of all of this, so a break in the logical chain
presents difficulties.Sorry for the long post. Regards, Mike
Date: Wed, 15 Aug 2012 08:30:10 -0700
From: doug.cole...@gmail.com
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
1) Factor loads a ~/.factor-rc file every time it starts. You can put
things there:
USE: tools.scaffold
scaffold-factor-rc
Click it, edit it and add:
USING: prettyprint.config namespaces ;
16 number-base set-global
2) Alternately, there's a boot rc file that gets loaded after bootstrap:
USE: tools.scaffold
scaffold-factor-boot-rc
Click it, edit it and add:
USING: prettyprint.config namespaces ;
16 number-base set-global
To load it without bootstrapping, call 'run-bootstrap-init' and then
'save' your image.
Doug
On Wed, Aug 15, 2012 at 8:22 AM, Michael Clagett mclag...@hotmail.com wrote:
Thanks. I knew it had to be something like that. And if I want it to be
the default every time I load the Listener, I'm sure there must be a way to
set that up?
Sent from my iPhone
On Aug 15, 2012, at 11:01 AM, John Benediktsson mrj...@gmail.com wrote:
If you want all numbers to print in hex, the easiest way is:
```
IN: scratchpad 16 number-base set-global
```
On Wed, Aug 15, 2012 at 4:04 AM, Michael Clagett mclag...@hotmail.com
wrote:
Quick question. Any way of having the data and retain stack panes of the
Walker display values in hex?
Date: Mon, 13 Aug 2012 12:21:52 -0400
From: arc...@gmail.com
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett mclag...@hotmail.com
wrote:
Here's an obscure question that is of interest to me in my current
quest,
but probably not to anyone else. So if there is a better forum for me
to
ask such things, I would love to be instructed; until I hear
otherwise,
however, I will continue to use this list.
Is there any place where I can penetrate the meaning of the following
constants:
CONSTANT: rt-dlsym 0
CONSTANT: rt-entry-point 1
CONSTANT: rt-entry-point-pic 2
CONSTANT: rt-entry-point-pic-tail 3
CONSTANT: rt-here 4
CONSTANT: rt-this 5
CONSTANT: rt-literal 6
CONSTANT: rt-untagged 7
CONSTANT: rt-megamorphic-cache-hits 8
CONSTANT: rt-vm 9
CONSTANT: rt-cards-offset 10
CONSTANT: rt-decks-offset 11
CONSTANT: rt-exception-handler 12
CONSTANT: rt-dlsym-toc 13
CONSTANT: rt-inline-cache-miss 14
CONSTANT: rt-safepoint 15
So far I've only encountered rt-here and I've only seen it encoded
into a
relocation entry and not really used anywhere yet. But this strikes me
as
the kind of thing it would be useful to know as I am slogging through
this
stuff.
Not a hugely pressing question, as I'm sure I'll muddle through it.
But if
anyone has a moment to illuminate, it would be nice.
Those are relocation record types. When the compiler generates code
Re: [Factor-talk] Any way of making sense of what's in the boot image?
In the listener, if you run this code:
IN: scratchpad clear
IN: scratchpad value key associate
Then step over to [ set-at ] keep
If at this point you just keep stepping into things, you should do a deep
dive into all the parts, including the 4 slot { array } declare which
should give you something like {
~tombstone~ ~tombstone~ ~tombstone~ ~tombstone~ } (an array full of
tombstone elements which indicate no key or value is present). A
hashtable with deleted elements will have ~empty~. A hashtable with
key/value will have { key value } at some point in the array. The
array is flattened key/value pairs, so a 4 bucket hashtable will have an 8
element array storing key/value side-by-side starting at the even indices.
I'm not sure what the 26-slot hash table is that you are looking at, so I
put a clear in the code above to make sure your data stack is empty before
walking. It is also possible that you are tracing some code which is
traversing the namespaces (a vector of hashtables containing symbolic
variables used in parts of the code, with names like the ones you mention).
A hashtable has 3 slots (the 0 slot is a numeric value), see:
```
IN: scratchpad \ hashtable slots word-prop .
{
T{ slot-spec
{ name count }
{ offset 2 }
{ class array-capacity }
{ initial 0 }
}
T{ slot-spec
{ name deleted }
{ offset 3 }
{ class array-capacity }
{ initial 0 }
}
T{ slot-spec
{ name array }
{ offset 4 }
{ class array }
{ initial { } }
}
}
```
You might also like to try describe, and poke around at the various word
properties (see props below):
```
IN: scratchpad \ hashtable describe
IN: hashtables SYMBOL: hashtable
hashcode 251442479911733628
name hashtable
vocabularyhashtables
def [ \ hashtable ]
props H{ { help-parent hashtables } { slots ~array~ } { ...
pic-def f
pic-tail-def f
sub-primitive f
```
On Thu, Aug 16, 2012 at 6:01 AM, Michael Clagett mclag...@hotmail.comwrote:
Hi --
Okay. I'm going to ask for my first lifeline. :) I'm tracing through
some arcane stuff indeed. Everything is going along swimmingly. I get to
the word new-key@, which at its start wants to execute [ array 2dup
hash@ 0 f (new-key@) ] with the keep combinator. All good so far.
array resolves to [ 4 slot { array } declare ], which I believe should
mean get the 4th slot of the object on top of stack and declare to Factor
that you know for sure it is an array. The object on the top of the
stack, according to the Inspector, is a 26-slot hash table that includes
such keys as architecture, auto-use?, bootstrap-syntax,
bootsrapping?, etc.
Now comes the part that baffles me. When I get to executing slot
(whether I try to step past it or descend into it), the Walker simply moves
me all the way to the end of the qotation (past declare) and I see the
hash-table and index from the top of the data stack replaced with a
128-element array that has the 26 key-value pairs from the former hash
table spread out through the array interspersed by tombstone objects; each
of these key-value pairs that appear occupy two adjacent array slots. But
I'm completely mystified as to how the contents of the hash-table got
mapped to the array slots they now occupy (there doesn't seem to be any
rhyme or reason). And I have little insight into the code that
accomplished this. Moreover I apparently can't see the 4th slot of the
original object in the Inspector, as it only shows me three slots on the
data stack trace, but organizes them alphabetically when I double-click to
open the Inspector window.
Don't know if any of this was intelligble. But maybe one of you compiler
guys can give me a clue as to how I can understand this. I'm having to
reverse engineer my understanding of all of this, so a break in the logical
chain presents difficulties.
Sorry for the long post.
Regards,
Mike
Date: Wed, 15 Aug 2012 08:30:10 -0700
From: doug.cole...@gmail.com
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
1) Factor loads a ~/.factor-rc file every time it starts. You can put
things there:
USE: tools.scaffold
scaffold-factor-rc
Click it, edit it and add:
USING: prettyprint.config namespaces ;
16 number-base set-global
2) Alternately, there's a boot rc file that gets loaded after bootstrap:
USE: tools.scaffold
scaffold-factor-boot-rc
Click it, edit it and add:
USING: prettyprint.config namespaces ;
16 number-base set-global
To load it without bootstrapping, call 'run-bootstrap-init' and then
'save' your image.
Doug
On Wed, Aug 15, 2012 at 8:22 AM, Michael Clagett mclag...@hotmail.com
wrote:
Thanks. I knew it had to be something like that. And if I want it to be
the default every time I load the Listener, I'm sure there
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Wow. Great, John! Thanks. This should keep me at bay for a good while.
From: mrj...@gmail.com
Date: Thu, 16 Aug 2012 08:10:31 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
In the listener, if you run this code:
IN: scratchpad clearIN: scratchpad value key associate
Then step over to [ set-at ] keep
If at this point you just keep stepping into things, you should do a deep
dive into all the parts, including the 4 slot { array } declare which should
give you something like { ~tombstone~ ~tombstone~ ~tombstone~ ~tombstone~ } (an
array full of tombstone elements which indicate no key or value is present).
A hashtable with deleted elements will have ~empty~. A hashtable with
key/value will have { key value } at some point in the array. The array is
flattened key/value pairs, so a 4 bucket hashtable will have an 8 element array
storing key/value side-by-side starting at the even indices.
I'm not sure what the 26-slot hash table is that you are looking at, so I put a
clear in the code above to make sure your data stack is empty before walking.
It is also possible that you are tracing some code which is traversing the
namespaces (a vector of hashtables containing symbolic variables used in parts
of the code, with names like the ones you mention).
A hashtable has 3 slots (the 0 slot is a numeric value), see:
```IN: scratchpad \ hashtable slots word-prop .{T{ slot-spec
{ name count }{ offset 2 }{ class array-capacity }
{ initial 0 }}T{ slot-spec{ name deleted }
{ offset 3 }{ class array-capacity }{ initial 0 }}
T{ slot-spec{ name array }{ offset 4 }
{ class array }{ initial { } }}}```
You might also like to try describe, and poke around at the various word
properties (see props below):
```IN: scratchpad \ hashtable describeIN: hashtables SYMBOL: hashtablehashcode
251442479911733628name hashtablevocabularyhashtables
def [ \ hashtable ]props H{ { help-parent hashtables } {
slots ~array~ } { ...pic-def fpic-tail-def fsub-primitive f
```
On Thu, Aug 16, 2012 at 6:01 AM, Michael Clagett mclag...@hotmail.com wrote:
Hi --
Okay. I'm going to ask for my first lifeline. :) I'm tracing through some
arcane stuff indeed. Everything is going along swimmingly. I get to the word
new-key@, which at its start wants to execute [ array 2dup hash@ 0 f
(new-key@) ] with the keep combinator. All good so far. array resolves
to [ 4 slot { array } declare ], which I believe should mean get the 4th slot
of the object on top of stack and declare to Factor that you know for sure it
is an array. The object on the top of the stack, according to the Inspector,
is a 26-slot hash table that includes such keys as architecture, auto-use?,
bootstrap-syntax, bootsrapping?, etc.
Now comes the part that baffles me. When I get to executing slot (whether I
try to step past it or descend into it), the Walker simply moves me all the way
to the end of the qotation (past declare) and I see the hash-table and index
from the top of the data stack replaced with a 128-element array that has the
26 key-value pairs from the former hash table spread out through the array
interspersed by tombstone objects; each of these key-value pairs that appear
occupy two adjacent array slots. But I'm completely mystified as to how the
contents of the hash-table got mapped to the array slots they now occupy (there
doesn't seem to be any rhyme or reason). And I have little insight into the
code that accomplished this. Moreover I apparently can't see the 4th slot of
the original object in the Inspector, as it only shows me three slots on the
data stack trace, but organizes them alphabetically when I double-click to open
the Inspector window.
Don't know if any of this was intelligble. But maybe one of you compiler guys
can give me a clue as to how I can understand this. I'm having to reverse
engineer my understanding of all of this, so a break in the logical chain
presents difficulties.
Sorry for the long post.
Regards,
Mike
Date: Wed, 15 Aug 2012 08:30:10 -0700
From: doug.cole...@gmail.com
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
1) Factor loads a ~/.factor-rc file every time it starts. You can put
things there:
USE: tools.scaffold
scaffold-factor-rc
Click it, edit it and add:
USING: prettyprint.config namespaces ;
16 number-base set-global
2) Alternately, there's a boot rc file that gets loaded after bootstrap:
USE: tools.scaffold
scaffold-factor-boot-rc
Click it, edit it and add:
USING: prettyprint.config namespaces ;
16 number-base set-global
To load it without bootstrapping, call 'run-bootstrap-init'
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Btw, you might be wondering why you can't step into the slot word:
If you look at it, it's a primitive, meaning implemented in the VM C++ code
or a compiler intrinsic:
```
IN: scratchpad \ slot see
IN: slots.private
PRIMITIVE: slot ( obj m -- value ) flushable
```
In this case, I believe it is emitted by 'cpu.x86.bootstrap`:
```
[
! load slot number
temp0 ds-reg [] MOV
! adjust stack pointer
ds-reg bootstrap-cell SUB
! load object
temp1 ds-reg [] MOV
! turn slot number into offset
fixnumslot@
! mask off tag
temp1 tag-bits get SHR
temp1 tag-bits get SHL
! load slot value
temp0 temp1 temp0 [+] MOV
! push to stack
ds-reg [] temp0 MOV
] \ slot define-sub-primitive
```
There are compiler intrinsics you can look at in compiler.cfg.intrinsics if
that interests you.
An example of a primitive VM word might be something like bignum-gcd, which
is defined in vm/math.cpp, pops two bignums from the stack and then
computes their GCD in C++ code and then pushes the result back onto the
stack.
```
void factor_vm::primitive_bignum_gcd()
{
POP_BIGNUMS(x,y);
ctx-push(tagbignum(bignum_gcd(x,y)));
}
```
The mapping is defined in core/bootstrap/primitives.factor
```
{
...
{ bignum-gcd math.private primitive_bignum_gcd ( x y -- z ) }
...
}
[ first4 make-primitive ] each
```
On Thu, Aug 16, 2012 at 8:18 AM, Michael Clagett mclag...@hotmail.comwrote:
Wow. Great, John! Thanks. This should keep me at bay for a good while.
--
From: mrj...@gmail.com
Date: Thu, 16 Aug 2012 08:10:31 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
In the listener, if you run this code:
IN: scratchpad clear
IN: scratchpad value key associate
Then step over to [ set-at ] keep
If at this point you just keep stepping into things, you should do a
deep dive into all the parts, including the 4 slot { array } declare which
should give you something like {
~tombstone~ ~tombstone~ ~tombstone~ ~tombstone~ } (an array full of
tombstone elements which indicate no key or value is present). A
hashtable with deleted elements will have ~empty~. A hashtable with
key/value will have { key value } at some point in the array. The
array is flattened key/value pairs, so a 4 bucket hashtable will have an 8
element array storing key/value side-by-side starting at the even indices.
I'm not sure what the 26-slot hash table is that you are looking at, so I
put a clear in the code above to make sure your data stack is empty before
walking. It is also possible that you are tracing some code which is
traversing the namespaces (a vector of hashtables containing symbolic
variables used in parts of the code, with names like the ones you mention).
A hashtable has 3 slots (the 0 slot is a numeric value), see:
```
IN: scratchpad \ hashtable slots word-prop .
{
T{ slot-spec
{ name count }
{ offset 2 }
{ class array-capacity }
{ initial 0 }
}
T{ slot-spec
{ name deleted }
{ offset 3 }
{ class array-capacity }
{ initial 0 }
}
T{ slot-spec
{ name array }
{ offset 4 }
{ class array }
{ initial { } }
}
}
```
You might also like to try describe, and poke around at the various word
properties (see props below):
```
IN: scratchpad \ hashtable describe
IN: hashtables SYMBOL: hashtable
hashcode 251442479911733628
name hashtable
vocabularyhashtables
def [ \ hashtable ]
props H{ { help-parent hashtables } { slots ~array~ } { ...
pic-def f
pic-tail-def f
sub-primitive f
```
On Thu, Aug 16, 2012 at 6:01 AM, Michael Clagett mclag...@hotmail.comwrote:
Hi --
Okay. I'm going to ask for my first lifeline. :) I'm tracing through
some arcane stuff indeed. Everything is going along swimmingly. I get to
the word new-key@, which at its start wants to execute [ array 2dup
hash@ 0 f (new-key@) ] with the keep combinator. All good so far.
array resolves to [ 4 slot { array } declare ], which I believe should
mean get the 4th slot of the object on top of stack and declare to Factor
that you know for sure it is an array. The object on the top of the
stack, according to the Inspector, is a 26-slot hash table that includes
such keys as architecture, auto-use?, bootstrap-syntax,
bootsrapping?, etc.
Now comes the part that baffles me. When I get to executing slot
(whether I try to step past it or descend into it), the Walker simply moves
me all the way to the end of the qotation (past declare) and I see the
hash-table and index from the top of the data stack replaced with a
128-element array that has the 26 key-value pairs from the former hash
table spread out through the array interspersed by tombstone objects; each
of these key-value pairs that
Re: [Factor-talk] Any way of making sense of what's in the boot image?
So then, John, does that mean that in the [ 4 slot { array} declare ],
that I'm getting the slot named array which is at offset 4 (and then
declaring that to be an array, so as to disable some of the type safety
checks)?
Yes, the hashtable code is written at a bit lower level and thus maybe a
little harder to read than one might normally write in Factor since it is
one of the building blocks that everything is built upon. It is also
possible that some of the compiler optimizations that have been written in
the last couple of years make some of those declarations unnecessary,
although I'd have to look into it more to know for sure.
Also, due to the bootstrapping mechanism, some of the higher level language
constructs like locals and fry quotations are not available yet. That is
something we hope to fix at some future point.
Here it says slot takes two incoming values: an obj and a non-negative
fixnum, which is the nth slot. In the hashtable slot-specs you list below
there are only three slots listed, but it does say that the slot named
array is at offset 4. Is it this offset number that is being specified
by the m parameter? And thus is the array I am seeing in my original
description the contents of the array slot of the hashtable that was
originally on the stack? That makes sense to me. And the fact that the
array is 128 slots long (allowing flattened representation of 64 key-value
pairs) just means that the underlying array in the hashtable has 64
buckets. Is this a correct interpretation. If it is, it makes sense that
the actual 26 values stored in the hash table would be dispersed
throught the 64 buckets, because this is what a hashtable does.
Yes, exactly! The slot-spec tuple provides a generic description of what
is to be found in this case at offset 4.
Best,
John.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Great, thanks.
Sent from my iPhone
On Aug 16, 2012, at 1:11 PM, John Benediktsson mrj...@gmail.com wrote:
So then, John, does that mean that in the [ 4 slot { array} declare ], that
I'm getting the slot named array which is at offset 4 (and then declaring
that to be an array, so as to disable some of the type safety checks)?
Yes, the hashtable code is written at a bit lower level and thus maybe a
little harder to read than one might normally write in Factor since it is one
of the building blocks that everything is built upon. It is also possible
that some of the compiler optimizations that have been written in the last
couple of years make some of those declarations unnecessary, although I'd
have to look into it more to know for sure.
Also, due to the bootstrapping mechanism, some of the higher level language
constructs like locals and fry quotations are not available yet. That is
something we hope to fix at some future point.
Here it says slot takes two incoming values: an obj and a non-negative
fixnum, which is the nth slot. In the hashtable slot-specs you list below
there are only three slots listed, but it does say that the slot named
array is at offset 4. Is it this offset number that is being specified by
the m parameter? And thus is the array I am seeing in my original
description the contents of the array slot of the hashtable that was
originally on the stack? That makes sense to me. And the fact that the
array is 128 slots long (allowing flattened representation of 64 key-value
pairs) just means that the underlying array in the hashtable has 64 buckets.
Is this a correct interpretation. If it is, it makes sense that the actual
26 values stored in the hash table would be dispersed throught the 64
buckets, because this is what a hashtable does.
Yes, exactly! The slot-spec tuple provides a generic description of what
is to be found in this case at offset 4.
Best,
John.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Quick question. Any way of having the data and retain stack panes of the Walker display values in hex? Date: Mon, 13 Aug 2012 12:21:52 -0400 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett mclag...@hotmail.com wrote: Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0 CONSTANT: rt-entry-point 1 CONSTANT: rt-entry-point-pic 2 CONSTANT: rt-entry-point-pic-tail 3 CONSTANT: rt-here 4 CONSTANT: rt-this 5 CONSTANT: rt-literal 6 CONSTANT: rt-untagged 7 CONSTANT: rt-megamorphic-cache-hits 8 CONSTANT: rt-vm 9 CONSTANT: rt-cards-offset 10 CONSTANT: rt-decks-offset 11 CONSTANT: rt-exception-handler 12 CONSTANT: rt-dlsym-toc 13 CONSTANT: rt-inline-cache-miss 14 CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Those are relocation record types. When the compiler generates code for a word, it also needs to generate relocation entries every time it references another word in a jump or call statement, much like a native C compiler needs to do for symbols in other modules. The VM uses these relocation entries to update the operands of jump and call instructions when code is written to the code heap, when the code heap is compacted, or if code is moved in memory for any reason. The different rt-* constants are used to describe what kind of object a relocation refers to, such as a foreign function in a DLL (dlsym), a word entry point (entry-point-*), the current address (here), etc. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
If you want all numbers to print in hex, the easiest way is: ``` IN: scratchpad 16 number-base set-global ``` On Wed, Aug 15, 2012 at 4:04 AM, Michael Clagett mclag...@hotmail.comwrote: Quick question. Any way of having the data and retain stack panes of the Walker display values in hex? Date: Mon, 13 Aug 2012 12:21:52 -0400 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett mclag...@hotmail.com wrote: Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0 CONSTANT: rt-entry-point 1 CONSTANT: rt-entry-point-pic 2 CONSTANT: rt-entry-point-pic-tail 3 CONSTANT: rt-here 4 CONSTANT: rt-this 5 CONSTANT: rt-literal 6 CONSTANT: rt-untagged 7 CONSTANT: rt-megamorphic-cache-hits 8 CONSTANT: rt-vm 9 CONSTANT: rt-cards-offset 10 CONSTANT: rt-decks-offset 11 CONSTANT: rt-exception-handler 12 CONSTANT: rt-dlsym-toc 13 CONSTANT: rt-inline-cache-miss 14 CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Those are relocation record types. When the compiler generates code for a word, it also needs to generate relocation entries every time it references another word in a jump or call statement, much like a native C compiler needs to do for symbols in other modules. The VM uses these relocation entries to update the operands of jump and call instructions when code is written to the code heap, when the code heap is compacted, or if code is moved in memory for any reason. The different rt-* constants are used to describe what kind of object a relocation refers to, such as a foreign function in a DLL (dlsym), a word entry point (entry-point-*), the current address (here), etc. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thanks. I knew it had to be something like that. And if I want it to be the default every time I load the Listener, I'm sure there must be a way to set that up? Sent from my iPhone On Aug 15, 2012, at 11:01 AM, John Benediktsson mrj...@gmail.com wrote: If you want all numbers to print in hex, the easiest way is: ``` IN: scratchpad 16 number-base set-global ``` On Wed, Aug 15, 2012 at 4:04 AM, Michael Clagett mclag...@hotmail.com wrote: Quick question. Any way of having the data and retain stack panes of the Walker display values in hex? Date: Mon, 13 Aug 2012 12:21:52 -0400 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett mclag...@hotmail.com wrote: Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0 CONSTANT: rt-entry-point 1 CONSTANT: rt-entry-point-pic 2 CONSTANT: rt-entry-point-pic-tail 3 CONSTANT: rt-here 4 CONSTANT: rt-this 5 CONSTANT: rt-literal 6 CONSTANT: rt-untagged 7 CONSTANT: rt-megamorphic-cache-hits 8 CONSTANT: rt-vm 9 CONSTANT: rt-cards-offset 10 CONSTANT: rt-decks-offset 11 CONSTANT: rt-exception-handler 12 CONSTANT: rt-dlsym-toc 13 CONSTANT: rt-inline-cache-miss 14 CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Those are relocation record types. When the compiler generates code for a word, it also needs to generate relocation entries every time it references another word in a jump or call statement, much like a native C compiler needs to do for symbols in other modules. The VM uses these relocation entries to update the operands of jump and call instructions when code is written to the code heap, when the code heap is compacted, or if code is moved in memory for any reason. The different rt-* constants are used to describe what kind of object a relocation refers to, such as a foreign function in a DLL (dlsym), a word entry point (entry-point-*), the current address (here), etc. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list
Re: [Factor-talk] Any way of making sense of what's in the boot image?
1) Factor loads a ~/.factor-rc file every time it starts. You can put things there: USE: tools.scaffold scaffold-factor-rc Click it, edit it and add: USING: prettyprint.config namespaces ; 16 number-base set-global 2) Alternately, there's a boot rc file that gets loaded after bootstrap: USE: tools.scaffold scaffold-factor-boot-rc Click it, edit it and add: USING: prettyprint.config namespaces ; 16 number-base set-global To load it without bootstrapping, call 'run-bootstrap-init' and then 'save' your image. Doug On Wed, Aug 15, 2012 at 8:22 AM, Michael Clagett mclag...@hotmail.com wrote: Thanks. I knew it had to be something like that. And if I want it to be the default every time I load the Listener, I'm sure there must be a way to set that up? Sent from my iPhone On Aug 15, 2012, at 11:01 AM, John Benediktsson mrj...@gmail.com wrote: If you want all numbers to print in hex, the easiest way is: ``` IN: scratchpad 16 number-base set-global ``` On Wed, Aug 15, 2012 at 4:04 AM, Michael Clagett mclag...@hotmail.com wrote: Quick question. Any way of having the data and retain stack panes of the Walker display values in hex? Date: Mon, 13 Aug 2012 12:21:52 -0400 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett mclag...@hotmail.com wrote: Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0 CONSTANT: rt-entry-point 1 CONSTANT: rt-entry-point-pic 2 CONSTANT: rt-entry-point-pic-tail 3 CONSTANT: rt-here 4 CONSTANT: rt-this 5 CONSTANT: rt-literal 6 CONSTANT: rt-untagged 7 CONSTANT: rt-megamorphic-cache-hits 8 CONSTANT: rt-vm 9 CONSTANT: rt-cards-offset 10 CONSTANT: rt-decks-offset 11 CONSTANT: rt-exception-handler 12 CONSTANT: rt-dlsym-toc 13 CONSTANT: rt-inline-cache-miss 14 CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Those are relocation record types. When the compiler generates code for a word, it also needs to generate relocation entries every time it references another word in a jump or call statement, much like a native C compiler needs to do for symbols in other modules. The VM uses these relocation entries to update the operands of jump and call instructions when code is written to the code heap, when the code heap is compacted, or if code is moved in memory for any reason. The different rt-* constants are used to describe what kind of object a relocation refers to, such as a foreign function in a DLL (dlsym), a word entry point (entry-point-*), the current address (here), etc. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Beautiful. Thanks. Sent from my iPhone On Aug 15, 2012, at 11:30 AM, Doug Coleman doug.cole...@gmail.com wrote: 1) Factor loads a ~/.factor-rc file every time it starts. You can put things there: USE: tools.scaffold scaffold-factor-rc Click it, edit it and add: USING: prettyprint.config namespaces ; 16 number-base set-global 2) Alternately, there's a boot rc file that gets loaded after bootstrap: USE: tools.scaffold scaffold-factor-boot-rc Click it, edit it and add: USING: prettyprint.config namespaces ; 16 number-base set-global To load it without bootstrapping, call 'run-bootstrap-init' and then 'save' your image. Doug On Wed, Aug 15, 2012 at 8:22 AM, Michael Clagett mclag...@hotmail.com wrote: Thanks. I knew it had to be something like that. And if I want it to be the default every time I load the Listener, I'm sure there must be a way to set that up? Sent from my iPhone On Aug 15, 2012, at 11:01 AM, John Benediktsson mrj...@gmail.com wrote: If you want all numbers to print in hex, the easiest way is: ``` IN: scratchpad 16 number-base set-global ``` On Wed, Aug 15, 2012 at 4:04 AM, Michael Clagett mclag...@hotmail.com wrote: Quick question. Any way of having the data and retain stack panes of the Walker display values in hex? Date: Mon, 13 Aug 2012 12:21:52 -0400 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett mclag...@hotmail.com wrote: Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0 CONSTANT: rt-entry-point 1 CONSTANT: rt-entry-point-pic 2 CONSTANT: rt-entry-point-pic-tail 3 CONSTANT: rt-here 4 CONSTANT: rt-this 5 CONSTANT: rt-literal 6 CONSTANT: rt-untagged 7 CONSTANT: rt-megamorphic-cache-hits 8 CONSTANT: rt-vm 9 CONSTANT: rt-cards-offset 10 CONSTANT: rt-decks-offset 11 CONSTANT: rt-exception-handler 12 CONSTANT: rt-dlsym-toc 13 CONSTANT: rt-inline-cache-miss 14 CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Those are relocation record types. When the compiler generates code for a word, it also needs to generate relocation entries every time it references another word in a jump or call statement, much like a native C compiler needs to do for symbols in other modules. The VM uses these relocation entries to update the operands of jump and call instructions when code is written to the code heap, when the code heap is compacted, or if code is moved in memory for any reason. The different rt-* constants are used to describe what kind of object a relocation refers to, such as a foreign function in a DLL (dlsym), a word entry point (entry-point-*), the current address (here), etc. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats.
Re: [Factor-talk] Any way of making sense of what's in the boot image?
One constructive criticism type comment, if you'll permit me. While what I say directly below is absolutely true, it's true on a micro level. At the broader level, the heavy use of (sometimes lengthy) quotations to feed workhorse words like define-sub-primitive make understanding what's going on quite difficult. Although I realize the bootstrapping mechanism is not a general area of interest to many, I think something on the order of about 25 well-placed comments prefacing some of the more extensive quotations would help improve readability tremendously, just in case someone needs to understand the internals of this mechanism. Just a thought, offered in a spirit of complete good will and overall general awe at the care and discipline that has gone into this work. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Subject: RE: [Factor-talk] Any way of making sense of what's in the boot image? Date: Tue, 14 Aug 2012 05:28:45 + Been looking at some of the x86 assembler code. Damn! All I can say is that I wish to hell I had had Factor when I wrote my own. Quite a bit different approach, but the clarity and succinctness is tantalizing. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Mon, 13 Aug 2012 16:46:38 + Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? Thank you, Joe, for the quick response. It was actually the information in the such as clause of your last sentence that I was looking for. I don't mean for you to take the time out to document the meaning of these different constants, but if it is documented somewhere other than in the creators' heads, I would love to be directed to it. Not a big deal, because I'm sure that when I get to seeing them used in the boot-image initialization code, all will become clear. Still, it might help me better understand what's being done at the make-image level to know. Date: Mon, 13 Aug 2012 12:21:52 -0400 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett mclag...@hotmail.com wrote: Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0 CONSTANT: rt-entry-point 1 CONSTANT: rt-entry-point-pic 2 CONSTANT: rt-entry-point-pic-tail 3 CONSTANT: rt-here 4 CONSTANT: rt-this 5 CONSTANT: rt-literal 6 CONSTANT: rt-untagged 7 CONSTANT: rt-megamorphic-cache-hits 8 CONSTANT: rt-vm 9 CONSTANT: rt-cards-offset 10 CONSTANT: rt-decks-offset 11 CONSTANT: rt-exception-handler 12 CONSTANT: rt-dlsym-toc 13 CONSTANT: rt-inline-cache-miss 14 CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Those are relocation record types. When the compiler generates code for a word, it also needs to generate relocation entries every time it references another word in a jump or call statement, much like a native C compiler needs to do for symbols in other modules. The VM uses these relocation entries to update the operands of jump and call instructions when code is written to the code heap, when the code heap is compacted, or if code is moved in memory for any reason. The different rt-* constants are used to describe what kind of object a relocation refers to, such as a foreign function in a DLL (dlsym), a word entry point (entry-point-*), the current address (here), etc. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond.
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Any documentation that you write as part of your investigation would be welcome contributions. On Tue, Aug 14, 2012 at 5:27 PM, Michael Clagett mclag...@hotmail.comwrote: One constructive criticism type comment, if you'll permit me. While what I say directly below is absolutely true, it's true on a micro level. At the broader level, the heavy use of (sometimes lengthy) quotations to feed workhorse words like define-sub-primitive make understanding what's going on quite difficult. Although I realize the bootstrapping mechanism is not a general area of interest to many, I think something on the order of about 25 well-placed comments prefacing some of the more extensive quotations would help improve readability tremendously, just in case someone needs to understand the internals of this mechanism. Just a thought, offered in a spirit of complete good will and overall general awe at the care and discipline that has gone into this work. -- From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Subject: RE: [Factor-talk] Any way of making sense of what's in the boot image? Date: Tue, 14 Aug 2012 05:28:45 + Been looking at some of the x86 assembler code. Damn! All I can say is that I wish to hell I had had Factor when I wrote my own. Quite a bit different approach, but the clarity and succinctness is tantalizing. -- From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Mon, 13 Aug 2012 16:46:38 + Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? Thank you, Joe, for the quick response. It was actually the information in the such as clause of your last sentence that I was looking for. I don't mean for you to take the time out to document the meaning of these different constants, but if it is documented somewhere other than in the creators' heads, I would love to be directed to it. Not a big deal, because I'm sure that when I get to seeing them used in the boot-image initialization code, all will become clear. Still, it might help me better understand what's being done at the make-image level to know. Date: Mon, 13 Aug 2012 12:21:52 -0400 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett mclag...@hotmail.com wrote: Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0 CONSTANT: rt-entry-point 1 CONSTANT: rt-entry-point-pic 2 CONSTANT: rt-entry-point-pic-tail 3 CONSTANT: rt-here 4 CONSTANT: rt-this 5 CONSTANT: rt-literal 6 CONSTANT: rt-untagged 7 CONSTANT: rt-megamorphic-cache-hits 8 CONSTANT: rt-vm 9 CONSTANT: rt-cards-offset 10 CONSTANT: rt-decks-offset 11 CONSTANT: rt-exception-handler 12 CONSTANT: rt-dlsym-toc 13 CONSTANT: rt-inline-cache-miss 14 CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Those are relocation record types. When the compiler generates code for a word, it also needs to generate relocation entries every time it references another word in a jump or call statement, much like a native C compiler needs to do for symbols in other modules. The VM uses these relocation entries to update the operands of jump and call instructions when code is written to the code heap, when the code heap is compacted, or if code is moved in memory for any reason. The different rt-* constants are used to describe what kind of object a relocation refers to, such as a foreign function in a DLL (dlsym), a word entry point (entry-point-*), the current address (here), etc. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Roger, that. I will definitely do it. In fact, I think you will be pleasantly surprised. From: mrj...@gmail.com Date: Tue, 14 Aug 2012 17:35:39 -0700 To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? Any documentation that you write as part of your investigation would be welcome contributions. On Tue, Aug 14, 2012 at 5:27 PM, Michael Clagett mclag...@hotmail.com wrote: One constructive criticism type comment, if you'll permit me. While what I say directly below is absolutely true, it's true on a micro level. At the broader level, the heavy use of (sometimes lengthy) quotations to feed workhorse words like define-sub-primitive make understanding what's going on quite difficult. Although I realize the bootstrapping mechanism is not a general area of interest to many, I think something on the order of about 25 well-placed comments prefacing some of the more extensive quotations would help improve readability tremendously, just in case someone needs to understand the internals of this mechanism. Just a thought, offered in a spirit of complete good will and overall general awe at the care and discipline that has gone into this work. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Subject: RE: [Factor-talk] Any way of making sense of what's in the boot image? Date: Tue, 14 Aug 2012 05:28:45 + Been looking at some of the x86 assembler code. Damn! All I can say is that I wish to hell I had had Factor when I wrote my own. Quite a bit different approach, but the clarity and succinctness is tantalizing. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Mon, 13 Aug 2012 16:46:38 + Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? Thank you, Joe, for the quick response. It was actually the information in the such as clause of your last sentence that I was looking for. I don't mean for you to take the time out to document the meaning of these different constants, but if it is documented somewhere other than in the creators' heads, I would love to be directed to it. Not a big deal, because I'm sure that when I get to seeing them used in the boot-image initialization code, all will become clear. Still, it might help me better understand what's being done at the make-image level to know. Date: Mon, 13 Aug 2012 12:21:52 -0400 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett mclag...@hotmail.com wrote: Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0 CONSTANT: rt-entry-point 1 CONSTANT: rt-entry-point-pic 2 CONSTANT: rt-entry-point-pic-tail 3 CONSTANT: rt-here 4 CONSTANT: rt-this 5 CONSTANT: rt-literal 6 CONSTANT: rt-untagged 7 CONSTANT: rt-megamorphic-cache-hits 8 CONSTANT: rt-vm 9 CONSTANT: rt-cards-offset 10 CONSTANT: rt-decks-offset 11 CONSTANT: rt-exception-handler 12 CONSTANT: rt-dlsym-toc 13 CONSTANT: rt-inline-cache-miss 14 CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Those are relocation record types. When the compiler generates code for a word, it also needs to generate relocation entries every time it references another word in a jump or call statement, much like a native C compiler needs to do for symbols in other modules. The VM uses these relocation entries to update the operands of jump and call instructions when code is written to the code heap, when the code heap is compacted, or if code is moved in memory for any reason. The different rt-* constants are used to describe what kind of object a relocation refers to, such as a foreign function in a DLL (dlsym), a word entry point (entry-point-*), the current address (here), etc. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats.
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Is this you? http://www.clarkprosecutor.org/html/death/US/clagett651.htm On Mon, Aug 13, 2012 at 9:46 AM, Michael Clagett mclag...@hotmail.com wrote: Thank you, Joe, for the quick response. It was actually the information in the such as clause of your last sentence that I was looking for. I don't mean for you to take the time out to document the meaning of these different constants, but if it is documented somewhere other than in the creators' heads, I would love to be directed to it. Not a big deal, because I'm sure that when I get to seeing them used in the boot-image initialization code, all will become clear. Still, it might help me better understand what's being done at the make-image level to know. Date: Mon, 13 Aug 2012 12:21:52 -0400 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett mclag...@hotmail.com wrote: Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0 CONSTANT: rt-entry-point 1 CONSTANT: rt-entry-point-pic 2 CONSTANT: rt-entry-point-pic-tail 3 CONSTANT: rt-here 4 CONSTANT: rt-this 5 CONSTANT: rt-literal 6 CONSTANT: rt-untagged 7 CONSTANT: rt-megamorphic-cache-hits 8 CONSTANT: rt-vm 9 CONSTANT: rt-cards-offset 10 CONSTANT: rt-decks-offset 11 CONSTANT: rt-exception-handler 12 CONSTANT: rt-dlsym-toc 13 CONSTANT: rt-inline-cache-miss 14 CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Those are relocation record types. When the compiler generates code for a word, it also needs to generate relocation entries every time it references another word in a jump or call statement, much like a native C compiler needs to do for symbols in other modules. The VM uses these relocation entries to update the operands of jump and call instructions when code is written to the code heap, when the code heap is compacted, or if code is moved in memory for any reason. The different rt-* constants are used to describe what kind of object a relocation refers to, such as a foreign function in a DLL (dlsym), a word entry point (entry-point-*), the current address (here), etc. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
(So you had better be nice to me; I don't mess around.) Date: Mon, 13 Aug 2012 09:50:04 -0700 From: doug.cole...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? Is this you? http://www.clarkprosecutor.org/html/death/US/clagett651.htm On Mon, Aug 13, 2012 at 9:46 AM, Michael Clagett mclag...@hotmail.com wrote: Thank you, Joe, for the quick response. It was actually the information in the such as clause of your last sentence that I was looking for. I don't mean for you to take the time out to document the meaning of these different constants, but if it is documented somewhere other than in the creators' heads, I would love to be directed to it. Not a big deal, because I'm sure that when I get to seeing them used in the boot-image initialization code, all will become clear. Still, it might help me better understand what's being done at the make-image level to know. Date: Mon, 13 Aug 2012 12:21:52 -0400 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett mclag...@hotmail.com wrote: Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0 CONSTANT: rt-entry-point 1 CONSTANT: rt-entry-point-pic 2 CONSTANT: rt-entry-point-pic-tail 3 CONSTANT: rt-here 4 CONSTANT: rt-this 5 CONSTANT: rt-literal 6 CONSTANT: rt-untagged 7 CONSTANT: rt-megamorphic-cache-hits 8 CONSTANT: rt-vm 9 CONSTANT: rt-cards-offset 10 CONSTANT: rt-decks-offset 11 CONSTANT: rt-exception-handler 12 CONSTANT: rt-dlsym-toc 13 CONSTANT: rt-inline-cache-miss 14 CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Those are relocation record types. When the compiler generates code for a word, it also needs to generate relocation entries every time it references another word in a jump or call statement, much like a native C compiler needs to do for symbols in other modules. The VM uses these relocation entries to update the operands of jump and call instructions when code is written to the code heap, when the code heap is compacted, or if code is moved in memory for any reason. The different rt-* constants are used to describe what kind of object a relocation refers to, such as a foreign function in a DLL (dlsym), a word entry point (entry-point-*), the current address (here), etc. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Been looking at some of the x86 assembler code. Damn! All I can say is that I wish to hell I had had Factor when I wrote my own. Quite a bit different approach, but the clarity and succinctness is tantalizing. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Mon, 13 Aug 2012 16:46:38 + Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? Thank you, Joe, for the quick response. It was actually the information in the such as clause of your last sentence that I was looking for. I don't mean for you to take the time out to document the meaning of these different constants, but if it is documented somewhere other than in the creators' heads, I would love to be directed to it. Not a big deal, because I'm sure that when I get to seeing them used in the boot-image initialization code, all will become clear. Still, it might help me better understand what's being done at the make-image level to know. Date: Mon, 13 Aug 2012 12:21:52 -0400 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett mclag...@hotmail.com wrote: Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0 CONSTANT: rt-entry-point 1 CONSTANT: rt-entry-point-pic 2 CONSTANT: rt-entry-point-pic-tail 3 CONSTANT: rt-here 4 CONSTANT: rt-this 5 CONSTANT: rt-literal 6 CONSTANT: rt-untagged 7 CONSTANT: rt-megamorphic-cache-hits 8 CONSTANT: rt-vm 9 CONSTANT: rt-cards-offset 10 CONSTANT: rt-decks-offset 11 CONSTANT: rt-exception-handler 12 CONSTANT: rt-dlsym-toc 13 CONSTANT: rt-inline-cache-miss 14 CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Those are relocation record types. When the compiler generates code for a word, it also needs to generate relocation entries every time it references another word in a jump or call statement, much like a native C compiler needs to do for symbols in other modules. The VM uses these relocation entries to update the operands of jump and call instructions when code is written to the code heap, when the code heap is compacted, or if code is moved in memory for any reason. The different rt-* constants are used to describe what kind of object a relocation refers to, such as a foreign function in a DLL (dlsym), a word entry point (entry-point-*), the current address (here), etc. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
P.S. Incidentally, while I am on the subject, I find myself able to trace through the VM startup code in Visual Studio with no problem at all, until I get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive inside of a callback stub and then invokes that function. On both a Windows 7 platform and a Windows Server 2008 platform, my Visual Studio blows up when the callback address loaded into EDX is called. Anybody ever encountered this and any idea how to get around it? Factor code doesn't follow the C calling convention so it's unlikely that a debugger will be able to walk a stack with Factor frames. In recent versions of Factor you can trigger Factor's own low-level debugger with ^C, which will let you backtrace and step through Factor frames. -Joe If I'm understanding this correctly, you are suggesting that if I'm in the Factor development environment, I can drop into Factor's own low-level debugger. But what do people do (you language maintainer, for example) when you need to debug the startup code that builds an image that needs to be in place for the development environment even to be launched? Am I correctly understanding you, that I can't use a Windows debugger to step through the init sequence, but don't have Factor's debugger available yet either? Or am I missing something? Any insights would be greatly appreciated. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Not a problem any more. WinDbg does the trick just fine. It was just Visual Studio. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Fri, 10 Aug 2012 11:51:00 + Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? P.S. Incidentally, while I am on the subject, I find myself able to trace through the VM startup code in Visual Studio with no problem at all, until I get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive inside of a callback stub and then invokes that function. On both a Windows 7 platform and a Windows Server 2008 platform, my Visual Studio blows up when the callback address loaded into EDX is called. Anybody ever encountered this and any idea how to get around it? Factor code doesn't follow the C calling convention so it's unlikely that a debugger will be able to walk a stack with Factor frames. In recent versions of Factor you can trigger Factor's own low-level debugger with ^C, which will let you backtrace and step through Factor frames. -Joe If I'm understanding this correctly, you are suggesting that if I'm in the Factor development environment, I can drop into Factor's own low-level debugger. But what do people do (you language maintainer, for example) when you need to debug the startup code that builds an image that needs to be in place for the development environment even to be launched? Am I correctly understanding you, that I can't use a Windows debugger to step through the init sequence, but don't have Factor's debugger available yet either? Or am I missing something? Any insights would be greatly appreciated. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
You might also find it useful to try the Walker which allows you to step through Factor code: http://docs.factorcode.org/content/article-ui-walker.html On Fri, Aug 10, 2012 at 10:29 AM, Michael Clagett mclag...@hotmail.comwrote: Not a problem any more. WinDbg does the trick just fine. It was just Visual Studio. -- From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Fri, 10 Aug 2012 11:51:00 + Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? P.S. Incidentally, while I am on the subject, I find myself able to trace through the VM startup code in Visual Studio with no problem at all, until I get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive inside of a callback stub and then invokes that function. On both a Windows 7 platform and a Windows Server 2008 platform, my Visual Studio blows up when the callback address loaded into EDX is called. Anybody ever encountered this and any idea how to get around it? Factor code doesn't follow the C calling convention so it's unlikely that a debugger will be able to walk a stack with Factor frames. In recent versions of Factor you can trigger Factor's own low-level debugger with ^C, which will let you backtrace and step through Factor frames. -Joe If I'm understanding this correctly, you are suggesting that if I'm in the Factor development environment, I can drop into Factor's own low-level debugger. But what do people do (you language maintainer, for example) when you need to debug the startup code that builds an image that needs to be in place for the development environment even to be launched? Am I correctly understanding you, that I can't use a Windows debugger to step through the init sequence, but don't have Factor's debugger available yet either? Or am I missing something? Any insights would be greatly appreciated. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thanks for the reference. I assume that will be helpful once I get past stepping through the bootstrapping code and am in the Listener environment.From: mrj...@gmail.com Date: Fri, 10 Aug 2012 10:40:28 -0700 To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? You might also find it useful to try the Walker which allows you to step through Factor code: http://docs.factorcode.org/content/article-ui-walker.html On Fri, Aug 10, 2012 at 10:29 AM, Michael Clagett mclag...@hotmail.com wrote: Not a problem any more. WinDbg does the trick just fine. It was just Visual Studio. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Fri, 10 Aug 2012 11:51:00 + Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? P.S. Incidentally, while I am on the subject, I find myself able to trace through the VM startup code in Visual Studio with no problem at all, until I get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive inside of a callback stub and then invokes that function. On both a Windows 7 platform and a Windows Server 2008 platform, my Visual Studio blows up when the callback address loaded into EDX is called. Anybody ever encountered this and any idea how to get around it? Factor code doesn't follow the C calling convention so it's unlikely that a debugger will be able to walk a stack with Factor frames. In recent versions of Factor you can trigger Factor's own low-level debugger with ^C, which will let you backtrace and step through Factor frames. -Joe If I'm understanding this correctly, you are suggesting that if I'm in the Factor development environment, I can drop into Factor's own low-level debugger. But what do people do (you language maintainer, for example) when you need to debug the startup code that builds an image that needs to be in place for the development environment even to be launched? Am I correctly understanding you, that I can't use a Windows debugger to step through the init sequence, but don't have Factor's debugger available yet either? Or am I missing something? Any insights would be greatly appreciated. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Hi -- I've been trying to run the make-image word from the Listener and got as
far as this trace: IN: scratchpad Command: restart
1: Note:
Added bootstrap.image vocabulary to search path
x86.32 make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
From Traceback: Data Stack: [ ~quotation~ with-compilation-unit ]Bad
architecture: x86.32 Call Stack: (U)
Quotation: [ set-namestack init-catchstack self quot call - stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip - swap [ set-datastack ] dip
]
(U)
Quotation: [ call - datastack ]
(O)
Word: make-image
(U)
Quotation: [
Bootstrap stage 1... print
flush vocab:bootstrap/primitives.factor run-file
- load-help? off { resource:core } vocab-roots set [
~quotation~ % math.integers require
math.floats require memory require
io.streams.c require vocabs.loader require
syntax require bootstrap.layouts require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
Creating primitives and basic runtime structures... print
flush H{ } clone sub-primitives set
vocab:bootstrap/syntax.factor parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ Bad architecture: prepend throw ] unless
- vocab:cpu/ /bootstrap.factor surround
parse-file vocab:bootstrap/layouts/layouts.factor
parse-file syntax lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect accessors create-vocab drop
num-types get f array builtins set [
( -- ) call-effect ~array~ ~quotation~ each
fixnum math create register-builtin
bignum math create register-builtin
tuple kernel create register-builtin
float math create register-builtin
f syntax lookup-word register-builtin
array arrays create register-builtin
wrapper kernel create register-builtin
callstack kernel create register-builtin
string strings create register-builtin
quotation quotations create register-builtin
dll alien create register-builtin
alien alien create register-builtin
word words create register-builtin
byte-array byte-arrays create register-builtin
f syntax lookup-word ~array~ define-builtin
f syntax create
~quotation~ predicate set-word-prop
f? syntax vocab-words delete-at
t syntax lookup-word define-singleton-class
c-ptr alien create ~quotation~ ~array~ make
define-union-class
array-capacity sequences.private create
fixnum math lookup-word
~quotation~ ~quotation~ make define-predicate-class
array-capacity sequences.private lookup-word
~195 more~
] with-compilation-unit
]
(O)
Method: M\ object throw
(U)
Quotation: [
OBJ-CURRENT-THREAD special-object error-thread set-global
current-continuation - error-continuation set-global
[ original-error set-global ] [ rethrow ] bi
]
Anyone have any ideas? From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 17:50:12 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thanks for the reference. I assume that will be helpful once I get past
stepping through the bootstrapping code and am in the Listener environment.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 10:40:28 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
You might also find it useful to try the Walker which allows you to step
through Factor code:
http://docs.factorcode.org/content/article-ui-walker.html
On Fri, Aug 10, 2012 at 10:29 AM, Michael Clagett mclag...@hotmail.com wrote:
Not a problem any more. WinDbg does the trick just fine. It was just Visual
Studio.
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 11:51:00 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
P.S. Incidentally, while I am on the subject, I find myself able to trace
through the VM startup code in Visual Studio with no problem at all, until I
get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive
inside of a callback stub and then invokes that function. On both a Windows
7 platform and a Windows Server 2008 platform, my Visual Studio blows up
when the callback address loaded into EDX is called. Anybody ever
encountered this and
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch .
unix-x86.64
You can use the my-arch word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett mclag...@hotmail.comwrote:
Hi --
I've been trying to run the make-image word from the Listener and got as
far as this trace:
IN: scratchpad Command: restart
1: Note:
Added bootstrap.image vocabulary to search path
x86.32 make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
Bad architecture: x86.32
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot call - stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip - swap [ set-datastack ] dip
]
(U)
Quotation: [ call - datastack ]
(O)
Word: make-image
(U)
Quotation: [
Bootstrap stage 1... print
flush vocab:bootstrap/primitives.factor run-file
- load-help? off { resource:core } vocab-roots set [
~quotation~ % math.integers require
math.floats require memory require
io.streams.c require vocabs.loader require
syntax require bootstrap.layouts require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
Creating primitives and basic runtime structures... print
flush H{ } clone sub-primitives set
vocab:bootstrap/syntax.factor parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ Bad architecture: prepend throw ] unless
- vocab:cpu/ /bootstrap.factor surround
parse-file vocab:bootstrap/layouts/layouts.factor
parse-file syntax lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect accessors create-vocab drop
num-types get f array builtins set [
( -- ) call-effect ~array~ ~quotation~ each
fixnum math create register-builtin
bignum math create register-builtin
tuple kernel create register-builtin
float math create register-builtin
f syntax lookup-word register-builtin
array arrays create register-builtin
wrapper kernel create register-builtin
callstack kernel create register-builtin
string strings create register-builtin
quotation quotations create register-builtin
dll alien create register-builtin
alien alien create register-builtin
word words create register-builtin
byte-array byte-arrays create register-builtin
f syntax lookup-word ~array~ define-builtin
f syntax create
~quotation~ predicate set-word-prop
f? syntax vocab-words delete-at
t syntax lookup-word define-singleton-class
c-ptr alien create ~quotation~ ~array~ make
define-union-class
array-capacity sequences.private create
fixnum math lookup-word
~quotation~ ~quotation~ make define-predicate-class
array-capacity sequences.private lookup-word
~195 more~
] with-compilation-unit
]
(O)
Method: M\ object throw
(U)
Quotation: [
OBJ-CURRENT-THREAD special-object error-thread set-global
current-continuation *-* error-continuation set-global
[ original-error set-global ] [ rethrow ] bi
]
Anyone have any ideas?
--
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 17:50:12 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Thanks for the reference. I assume that will be helpful once I get past
stepping through the bootstrapping code and am in the Listener environment.
--
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 10:40:28 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
You might also find it useful to try the Walker which allows you to step
through Factor code:
http://docs.factorcode.org/content/article-ui-walker.html
On Fri, Aug 10, 2012 at 10:29 AM, Michael Clagett mclag...@hotmail.comwrote:
Not a problem any more. WinDbg does the trick just fine. It was just
Visual Studio.
--
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 11:51:00 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Beautiful. Worked like a charm. Thanks.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:01:58 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch .unix-x86.64
You can use the my-arch word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett mclag...@hotmail.com wrote:
Hi --
I've been trying to run the make-image word from the Listener and got as far as
this trace:
IN: scratchpad Command: restart
1: Note:
Added bootstrap.image vocabulary to search path
x86.32 make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
Bad architecture: x86.32
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot call - stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip - swap [ set-datastack ] dip
]
(U)
Quotation: [ call - datastack ]
(O)
Word: make-image
(U)
Quotation: [
Bootstrap stage 1... print
flush vocab:bootstrap/primitives.factor run-file
- load-help? off { resource:core } vocab-roots set [
~quotation~ % math.integers require
math.floats require memory require
io.streams.c require vocabs.loader require
syntax require bootstrap.layouts require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
Creating primitives and basic runtime structures... print
flush H{ } clone sub-primitives set
vocab:bootstrap/syntax.factor parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ Bad architecture: prepend throw ] unless
- vocab:cpu/ /bootstrap.factor surround
parse-file vocab:bootstrap/layouts/layouts.factor
parse-file syntax lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect accessors create-vocab drop
num-types get f array builtins set [
( -- ) call-effect ~array~ ~quotation~ each
fixnum math create register-builtin
bignum math create register-builtin
tuple kernel create register-builtin
float math create register-builtin
f syntax lookup-word register-builtin
array arrays create register-builtin
wrapper kernel create register-builtin
callstack kernel create register-builtin
string strings create register-builtin
quotation quotations create register-builtin
dll alien create register-builtin
alien alien create register-builtin
word words create register-builtin
byte-array byte-arrays create register-builtin
f syntax lookup-word ~array~ define-builtin
f syntax create
~quotation~ predicate set-word-prop
f? syntax vocab-words delete-at
t syntax lookup-word define-singleton-class
c-ptr alien create ~quotation~ ~array~ make
define-union-class
array-capacity sequences.private create
fixnum math lookup-word
~quotation~ ~quotation~ make define-predicate-class
array-capacity sequences.private lookup-word
~195 more~
] with-compilation-unit
]
(O)
Method: M\ object throw
(U)
Quotation: [
OBJ-CURRENT-THREAD special-object error-thread set-global
current-continuation - error-continuation set-global
[ original-error set-global ] [ rethrow ] bi
]
Anyone have any ideas?
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 17:50:12 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thanks for the reference. I assume that will be helpful once I get past
stepping through the bootstrapping code and am in the Listener environment.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 10:40:28 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
You might also find it useful to try the Walker which allows you to step
through Factor code:
http://docs.factorcode.org/content/article-ui-walker.html
On Fri, Aug 10, 2012 at 10:29 AM, Michael Clagett mclag...@hotmail.com wrote:
Not a problem any more. WinDbg does the trick just fine. It was just Visual
Studio.
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Quick question, if you're still on the horn. How do I trace into myarch
make-image from the Listener. If I hit enter it just executes. I'm sure there
must be any easy way to step into it, which I'm sure I can find by searching
the documentation. But perhaps you could save me five minutes.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:01:58 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch .unix-x86.64
You can use the my-arch word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett mclag...@hotmail.com wrote:
Hi --
I've been trying to run the make-image word from the Listener and got as far as
this trace:
IN: scratchpad Command: restart
1: Note:
Added bootstrap.image vocabulary to search path
x86.32 make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
Bad architecture: x86.32
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot call - stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip - swap [ set-datastack ] dip
]
(U)
Quotation: [ call - datastack ]
(O)
Word: make-image
(U)
Quotation: [
Bootstrap stage 1... print
flush vocab:bootstrap/primitives.factor run-file
- load-help? off { resource:core } vocab-roots set [
~quotation~ % math.integers require
math.floats require memory require
io.streams.c require vocabs.loader require
syntax require bootstrap.layouts require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
Creating primitives and basic runtime structures... print
flush H{ } clone sub-primitives set
vocab:bootstrap/syntax.factor parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ Bad architecture: prepend throw ] unless
- vocab:cpu/ /bootstrap.factor surround
parse-file vocab:bootstrap/layouts/layouts.factor
parse-file syntax lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect accessors create-vocab drop
num-types get f array builtins set [
( -- ) call-effect ~array~ ~quotation~ each
fixnum math create register-builtin
bignum math create register-builtin
tuple kernel create register-builtin
float math create register-builtin
f syntax lookup-word register-builtin
array arrays create register-builtin
wrapper kernel create register-builtin
callstack kernel create register-builtin
string strings create register-builtin
quotation quotations create register-builtin
dll alien create register-builtin
alien alien create register-builtin
word words create register-builtin
byte-array byte-arrays create register-builtin
f syntax lookup-word ~array~ define-builtin
f syntax create
~quotation~ predicate set-word-prop
f? syntax vocab-words delete-at
t syntax lookup-word define-singleton-class
c-ptr alien create ~quotation~ ~array~ make
define-union-class
array-capacity sequences.private create
fixnum math lookup-word
~quotation~ ~quotation~ make define-predicate-class
array-capacity sequences.private lookup-word
~195 more~
] with-compilation-unit
]
(O)
Method: M\ object throw
(U)
Quotation: [
OBJ-CURRENT-THREAD special-object error-thread set-global
current-continuation - error-continuation set-global
[ original-error set-global ] [ rethrow ] bi
]
Anyone have any ideas?
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 17:50:12 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thanks for the reference. I assume that will be helpful once I get past
stepping through the bootstrapping code and am in the Listener environment.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 10:40:28 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
You might also find it useful to try the Walker which allows you to step
through Factor code:
http://docs.factorcode.org/content/article-ui-walker.html
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Write my-arch make-image in listener.
Then type Ctrl-W to walk it.
Step across my-arch
Into into make-image
Rinse, repeat. :)
On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett mclag...@hotmail.comwrote:
Quick question, if you're still on the horn. How do I trace into myarch
make-image from the Listener. If I hit enter it just executes. I'm sure
there must be any easy way to step into it, which I'm sure I can find by
searching the documentation. But perhaps you could save me five minutes.
--
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:01:58 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch .
unix-x86.64
You can use the my-arch word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett mclag...@hotmail.comwrote:
Hi --
I've been trying to run the make-image word from the Listener and got as
far as this trace:
IN: scratchpad Command: restart
1: Note:
Added bootstrap.image vocabulary to search path
x86.32 make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
Bad architecture: x86.32
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot call - stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip - swap [ set-datastack ] dip
]
(U)
Quotation: [ call - datastack ]
(O)
Word: make-image
(U)
Quotation: [
Bootstrap stage 1... print
flush vocab:bootstrap/primitives.factor run-file
- load-help? off { resource:core } vocab-roots set [
~quotation~ % math.integers require
math.floats require memory require
io.streams.c require vocabs.loader require
syntax require bootstrap.layouts require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
Creating primitives and basic runtime structures... print
flush H{ } clone sub-primitives set
vocab:bootstrap/syntax.factor parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ Bad architecture: prepend throw ] unless
- vocab:cpu/ /bootstrap.factor surround
parse-file vocab:bootstrap/layouts/layouts.factor
parse-file syntax lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect accessors create-vocab drop
num-types get f array builtins set [
( -- ) call-effect ~array~ ~quotation~ each
fixnum math create register-builtin
bignum math create register-builtin
tuple kernel create register-builtin
float math create register-builtin
f syntax lookup-word register-builtin
array arrays create register-builtin
wrapper kernel create register-builtin
callstack kernel create register-builtin
string strings create register-builtin
quotation quotations create register-builtin
dll alien create register-builtin
alien alien create register-builtin
word words create register-builtin
byte-array byte-arrays create register-builtin
f syntax lookup-word ~array~ define-builtin
f syntax create
~quotation~ predicate set-word-prop
f? syntax vocab-words delete-at
t syntax lookup-word define-singleton-class
c-ptr alien create ~quotation~ ~array~ make
define-union-class
array-capacity sequences.private create
fixnum math lookup-word
~quotation~ ~quotation~ make define-predicate-class
array-capacity sequences.private lookup-word
~195 more~
] with-compilation-unit
]
(O)
Method: M\ object throw
(U)
Quotation: [
OBJ-CURRENT-THREAD special-object error-thread set-global
current-continuation *-* error-continuation set-global
[ original-error set-global ] [ rethrow ] bi
]
Anyone have any ideas?
--
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 17:50:12 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Thanks for the reference. I assume that will be helpful once I get past
stepping through the bootstrapping code and am in the Listener environment.
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thanks much. This should keep me occupied and out of everyone's hair for a
while.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:10:41 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Write my-arch make-image in listener.
Then type Ctrl-W to walk it.
Step across my-arch
Into into make-image
Rinse, repeat. :)
On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett mclag...@hotmail.com wrote:
Quick question, if you're still on the horn. How do I trace into myarch
make-image from the Listener. If I hit enter it just executes. I'm sure there
must be any easy way to step into it, which I'm sure I can find by searching
the documentation. But perhaps you could save me five minutes.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:01:58 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch .unix-x86.64
You can use the my-arch word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett mclag...@hotmail.com wrote:
Hi --
I've been trying to run the make-image word from the Listener and got as far as
this trace:
IN: scratchpad Command: restart
1: Note:
Added bootstrap.image vocabulary to search path
x86.32 make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
Bad architecture: x86.32
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot call - stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip - swap [ set-datastack ] dip
]
(U)
Quotation: [ call - datastack ]
(O)
Word: make-image
(U)
Quotation: [
Bootstrap stage 1... print
flush vocab:bootstrap/primitives.factor run-file
- load-help? off { resource:core } vocab-roots set [
~quotation~ % math.integers require
math.floats require memory require
io.streams.c require vocabs.loader require
syntax require bootstrap.layouts require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
Creating primitives and basic runtime structures... print
flush H{ } clone sub-primitives set
vocab:bootstrap/syntax.factor parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ Bad architecture: prepend throw ] unless
- vocab:cpu/ /bootstrap.factor surround
parse-file vocab:bootstrap/layouts/layouts.factor
parse-file syntax lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect accessors create-vocab drop
num-types get f array builtins set [
( -- ) call-effect ~array~ ~quotation~ each
fixnum math create register-builtin
bignum math create register-builtin
tuple kernel create register-builtin
float math create register-builtin
f syntax lookup-word register-builtin
array arrays create register-builtin
wrapper kernel create register-builtin
callstack kernel create register-builtin
string strings create register-builtin
quotation quotations create register-builtin
dll alien create register-builtin
alien alien create register-builtin
word words create register-builtin
byte-array byte-arrays create register-builtin
f syntax lookup-word ~array~ define-builtin
f syntax create
~quotation~ predicate set-word-prop
f? syntax vocab-words delete-at
t syntax lookup-word define-singleton-class
c-ptr alien create ~quotation~ ~array~ make
define-union-class
array-capacity sequences.private create
fixnum math lookup-word
~quotation~ ~quotation~ make define-predicate-class
array-capacity sequences.private lookup-word
~195 more~
] with-compilation-unit
]
(O)
Method: M\ object throw
(U)
Quotation: [
OBJ-CURRENT-THREAD special-object error-thread set-global
current-continuation - error-continuation set-global
[ original-error set-global ] [ rethrow ] bi
]
Anyone have any ideas?
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 17:50:12 +
Subject: Re: [Factor-talk] Any way of making sense of
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thanks much. This should keep me occupied and out of everyone's hair for a while. No worries, keep the questions coming! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
For anyone else who might happen onto the problem I had, the solution ended up
being that my architecture was named windows-x86.32, not x86.32.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:10:41 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Write my-arch make-image in listener.
Then type Ctrl-W to walk it.
Step across my-arch
Into into make-image
Rinse, repeat. :)
On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett mclag...@hotmail.com wrote:
Quick question, if you're still on the horn. How do I trace into myarch
make-image from the Listener. If I hit enter it just executes. I'm sure there
must be any easy way to step into it, which I'm sure I can find by searching
the documentation. But perhaps you could save me five minutes.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:01:58 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch .unix-x86.64
You can use the my-arch word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett mclag...@hotmail.com wrote:
Hi --
I've been trying to run the make-image word from the Listener and got as far as
this trace:
IN: scratchpad Command: restart
1: Note:
Added bootstrap.image vocabulary to search path
x86.32 make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
Bad architecture: x86.32
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot call - stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip - swap [ set-datastack ] dip
]
(U)
Quotation: [ call - datastack ]
(O)
Word: make-image
(U)
Quotation: [
Bootstrap stage 1... print
flush vocab:bootstrap/primitives.factor run-file
- load-help? off { resource:core } vocab-roots set [
~quotation~ % math.integers require
math.floats require memory require
io.streams.c require vocabs.loader require
syntax require bootstrap.layouts require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
Creating primitives and basic runtime structures... print
flush H{ } clone sub-primitives set
vocab:bootstrap/syntax.factor parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ Bad architecture: prepend throw ] unless
- vocab:cpu/ /bootstrap.factor surround
parse-file vocab:bootstrap/layouts/layouts.factor
parse-file syntax lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect accessors create-vocab drop
num-types get f array builtins set [
( -- ) call-effect ~array~ ~quotation~ each
fixnum math create register-builtin
bignum math create register-builtin
tuple kernel create register-builtin
float math create register-builtin
f syntax lookup-word register-builtin
array arrays create register-builtin
wrapper kernel create register-builtin
callstack kernel create register-builtin
string strings create register-builtin
quotation quotations create register-builtin
dll alien create register-builtin
alien alien create register-builtin
word words create register-builtin
byte-array byte-arrays create register-builtin
f syntax lookup-word ~array~ define-builtin
f syntax create
~quotation~ predicate set-word-prop
f? syntax vocab-words delete-at
t syntax lookup-word define-singleton-class
c-ptr alien create ~quotation~ ~array~ make
define-union-class
array-capacity sequences.private create
fixnum math lookup-word
~quotation~ ~quotation~ make define-predicate-class
array-capacity sequences.private lookup-word
~195 more~
] with-compilation-unit
]
(O)
Method: M\ object throw
(U)
Quotation: [
OBJ-CURRENT-THREAD special-object error-thread set-global
current-continuation - error-continuation set-global
[ original-error set-global ] [ rethrow ] bi
]
Anyone have any ideas?
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 17:50:12
Re: [Factor-talk] Any way of making sense of what's in the boot image?
One more question before I disappear. I've been tracing through the
bootstrapping code with WinDbg and am currently in factor_vm::compile_all_words
where a loop is about to compile 4894 words. These are accessible as words,
which in turn can server up their definitions (via word-def). These are
quotations, which, like words, display in the debugger inspector as a fairly
simple structure with a value and parent_slot. I'm wondering if by some
small chance there is some way to navigate back to the symbolic name for any
words that one comes across in this fashion. Certainly one could get away with
compiling simply with the type and value and never need the symbolic name,
which I suspect is what is being done. So I don't have high hopes, but it
certainly doesn't hurt to ask.
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 21:16:40 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image?
For anyone else who might happen onto the problem I had, the solution ended up
being that my architecture was named windows-x86.32, not x86.32.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:10:41 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Write my-arch make-image in listener.
Then type Ctrl-W to walk it.
Step across my-arch
Into into make-image
Rinse, repeat. :)
On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett mclag...@hotmail.com wrote:
Quick question, if you're still on the horn. How do I trace into myarch
make-image from the Listener. If I hit enter it just executes. I'm sure there
must be any easy way to step into it, which I'm sure I can find by searching
the documentation. But perhaps you could save me five minutes.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:01:58 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch .unix-x86.64
You can use the my-arch word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett mclag...@hotmail.com wrote:
Hi --
I've been trying to run the make-image word from the Listener and got as far as
this trace:
IN: scratchpad Command: restart
1: Note:
Added bootstrap.image vocabulary to search path
x86.32 make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
Bad architecture: x86.32
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot call - stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip - swap [ set-datastack ] dip
]
(U)
Quotation: [ call - datastack ]
(O)
Word: make-image
(U)
Quotation: [
Bootstrap stage 1... print
flush vocab:bootstrap/primitives.factor run-file
- load-help? off { resource:core } vocab-roots set [
~quotation~ % math.integers require
math.floats require memory require
io.streams.c require vocabs.loader require
syntax require bootstrap.layouts require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
Creating primitives and basic runtime structures... print
flush H{ } clone sub-primitives set
vocab:bootstrap/syntax.factor parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ Bad architecture: prepend throw ] unless
- vocab:cpu/ /bootstrap.factor surround
parse-file vocab:bootstrap/layouts/layouts.factor
parse-file syntax lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect accessors create-vocab drop
num-types get f array builtins set [
( -- ) call-effect ~array~ ~quotation~ each
fixnum math create register-builtin
bignum math create register-builtin
tuple kernel create register-builtin
float math create register-builtin
f syntax lookup-word register-builtin
array arrays create register-builtin
wrapper kernel create register-builtin
callstack kernel create register-builtin
string strings create register-builtin
quotation quotations create register-builtin
dll alien create register-builtin
alien alien create register-builtin
Re: [Factor-talk] Any way of making sense of what's in the boot image?
You can do this:
./factor
in the repl: die
then in the shell:
words
It dumps a list of word addresses in Factor.
This works for words, but not quotations.
Hope this helps.
Doug
On Fri, Aug 10, 2012 at 2:55 PM, Michael Clagett mclag...@hotmail.com wrote:
One more question before I disappear. I've been tracing through the
bootstrapping code with WinDbg and am currently in
factor_vm::compile_all_words where a loop is about to compile 4894 words.
These are accessible as words, which in turn can server up their definitions
(via word-def). These are quotations, which, like words, display in the
debugger inspector as a fairly simple structure with a value and
parent_slot. I'm wondering if by some small chance there is some way to
navigate back to the symbolic name for any words that one comes across in
this fashion. Certainly one could get away with compiling simply with the
type and value and never need the symbolic name, which I suspect is what is
being done. So I don't have high hopes, but it certainly doesn't hurt to
ask.
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 21:16:40 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
For anyone else who might happen onto the problem I had, the solution ended
up being that my architecture was named windows-x86.32, not x86.32.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:10:41 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Write my-arch make-image in listener.
Then type Ctrl-W to walk it.
Step across my-arch
Into into make-image
Rinse, repeat. :)
On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett mclag...@hotmail.com
wrote:
Quick question, if you're still on the horn. How do I trace into myarch
make-image from the Listener. If I hit enter it just executes. I'm sure
there must be any easy way to step into it, which I'm sure I can find by
searching the documentation. But perhaps you could save me five minutes.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:01:58 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch .
unix-x86.64
You can use the my-arch word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett mclag...@hotmail.com
wrote:
Hi --
I've been trying to run the make-image word from the Listener and got as far
as this trace:
IN: scratchpad Command: restart
1: Note:
Added bootstrap.image vocabulary to search path
x86.32 make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
Bad architecture: x86.32
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot call - stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip - swap [ set-datastack ] dip
]
(U)
Quotation: [ call - datastack ]
(O)
Word: make-image
(U)
Quotation: [
Bootstrap stage 1... print
flush vocab:bootstrap/primitives.factor run-file
- load-help? off { resource:core } vocab-roots set [
~quotation~ % math.integers require
math.floats require memory require
io.streams.c require vocabs.loader require
syntax require bootstrap.layouts require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
Creating primitives and basic runtime structures... print
flush H{ } clone sub-primitives set
vocab:bootstrap/syntax.factor parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~ ~array~ ~array~ } ?at
[ Bad architecture: prepend throw ] unless
- vocab:cpu/ /bootstrap.factor surround
parse-file vocab:bootstrap/layouts/layouts.factor
parse-file syntax lookup-vocab vocab-words
bootstrap-syntax set H{ } clone dictionary set
H{ } clone root-cache set H{ } clone source-files set
H{ } clone update-map set H{ } clone implementors-map set
init-caches bootstrapping? on ( -- ) call-effect
( -- ) call-effect accessors create-vocab drop
num-types get f array builtins set [
( -- ) call-effect ~array~ ~quotation~ each
fixnum math create register-builtin
bignum math create register-builtin
tuple kernel create register-builtin
float math create register-builtin
f
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Doug, thank you for your help, but I'm afraid I didn't understand everything in
your response. Not sure of the context of your instructions. Not sure, for
example, what you mean by ./factor (is this something I'm supposed to type
somewhere?), what you mean by in the repl: die (not sure what the repl is --
or what die means for that matter), and then what you mean by the shell.
Other than that I understood you completely :) .
Date: Fri, 10 Aug 2012 14:57:51 -0700
From: doug.cole...@gmail.com
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
You can do this:
./factor
in the repl: die
then in the shell:
words
It dumps a list of word addresses in Factor.
This works for words, but not quotations.
Hope this helps.
Doug
On Fri, Aug 10, 2012 at 2:55 PM, Michael Clagett mclag...@hotmail.com wrote:
One more question before I disappear. I've been tracing through the
bootstrapping code with WinDbg and am currently in
factor_vm::compile_all_words where a loop is about to compile 4894 words.
These are accessible as words, which in turn can server up their definitions
(via word-def). These are quotations, which, like words, display in the
debugger inspector as a fairly simple structure with a value and
parent_slot. I'm wondering if by some small chance there is some way to
navigate back to the symbolic name for any words that one comes across in
this fashion. Certainly one could get away with compiling simply with the
type and value and never need the symbolic name, which I suspect is what is
being done. So I don't have high hopes, but it certainly doesn't hurt to
ask.
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Fri, 10 Aug 2012 21:16:40 +
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
For anyone else who might happen onto the problem I had, the solution ended
up being that my architecture was named windows-x86.32, not x86.32.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:10:41 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Write my-arch make-image in listener.
Then type Ctrl-W to walk it.
Step across my-arch
Into into make-image
Rinse, repeat. :)
On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett mclag...@hotmail.com
wrote:
Quick question, if you're still on the horn. How do I trace into myarch
make-image from the Listener. If I hit enter it just executes. I'm sure
there must be any easy way to step into it, which I'm sure I can find by
searching the documentation. But perhaps you could save me five minutes.
From: mrj...@gmail.com
Date: Fri, 10 Aug 2012 14:01:58 -0700
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Any way of making sense of what's in the boot
image?
Typically the architecture is a combination of os and arch:
IN: scratchpad my-arch .
unix-x86.64
You can use the my-arch word to make an image for your architecture:
IN: scratchpad my-arch make-image
On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett mclag...@hotmail.com
wrote:
Hi --
I've been trying to run the make-image word from the Listener and got as far
as this trace:
IN: scratchpad Command: restart
1: Note:
Added bootstrap.image vocabulary to search path
x86.32 make-image
Loading resource:/core/bootstrap/stage1.factor
Bootstrap stage 1...
Loading vocab:bootstrap/primitives.factor
Creating primitives and basic runtime structures...
Loading vocab:bootstrap/syntax.factor
From Traceback:
Data Stack:
[ ~quotation~ with-compilation-unit ]
Bad architecture: x86.32
Call Stack:
(U)
Quotation: [ set-namestack init-catchstack self quot call - stop ]
(O)
Word: listener-thread
(O)
Word: listener
(O)
Word: (listener)
(U)
Quotation: [
[ ~quotation~ dip swap ~quotation~ dip ] dip swap
[ call datastack ] dip - swap [ set-datastack ] dip
]
(U)
Quotation: [ call - datastack ]
(O)
Word: make-image
(U)
Quotation: [
Bootstrap stage 1... print
flush vocab:bootstrap/primitives.factor run-file
- load-help? off { resource:core } vocab-roots set [
~quotation~ % math.integers require
math.floats require memory require
io.streams.c require vocabs.loader require
syntax require bootstrap.layouts require
~quotation~ %
] [ ] make bootstrap-startup-quot set
]
(U)
Quotation: [
Creating primitives and basic runtime structures... print
flush H{ } clone sub-primitives set
vocab:bootstrap/syntax.factor parse-file architecture get
{ ~array~ ~array~ ~array~ ~array~
Re: [Factor-talk] Any way of making sense of what's in the boot image?
./factor starts Factor from the command-line. If you're on mac, you get a terminal listener (to start it right, you want to run it from the app: ./Factor.app/Contents/MacOS/factor); if you're on linux, you get the UI. In Windows, you run factor.com and it launches the UI. So in whatever REPL (read-eval-print loop), if you then type ``die'', then you get a FEP in the terminal you launched Factor from. A FEP is basically the error shell you get when Factor has some kind of crash, but in this case, we called it intentionally. So you can type ``help'' and get a list of options, but what we want is to find the machine addresses for all the Factor words. So we type ``words'' and you see a list of machine addresses associated with Factor words. Then you can type ``c'' and continue execution, since we didn't really crash but invoked the FEP on purpose. Doug On Fri, Aug 10, 2012 at 3:05 PM, Michael Clagett mclag...@hotmail.com wrote: Doug, thank you for your help, but I'm afraid I didn't understand everything in your response. Not sure of the context of your instructions. Not sure, for example, what you mean by ./factor (is this something I'm supposed to type somewhere?), what you mean by in the repl: die (not sure what the repl is -- or what die means for that matter), and then what you mean by the shell. Other than that I understood you completely :) . Date: Fri, 10 Aug 2012 14:57:51 -0700 From: doug.cole...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? You can do this: ./factor in the repl: die then in the shell: words It dumps a list of word addresses in Factor. This works for words, but not quotations. Hope this helps. Doug On Fri, Aug 10, 2012 at 2:55 PM, Michael Clagett mclag...@hotmail.com wrote: One more question before I disappear. I've been tracing through the bootstrapping code with WinDbg and am currently in factor_vm::compile_all_words where a loop is about to compile 4894 words. These are accessible as words, which in turn can server up their definitions (via word-def). These are quotations, which, like words, display in the debugger inspector as a fairly simple structure with a value and parent_slot. I'm wondering if by some small chance there is some way to navigate back to the symbolic name for any words that one comes across in this fashion. Certainly one could get away with compiling simply with the type and value and never need the symbolic name, which I suspect is what is being done. So I don't have high hopes, but it certainly doesn't hurt to ask. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Fri, 10 Aug 2012 21:16:40 + Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? For anyone else who might happen onto the problem I had, the solution ended up being that my architecture was named windows-x86.32, not x86.32. From: mrj...@gmail.com Date: Fri, 10 Aug 2012 14:10:41 -0700 To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? Write my-arch make-image in listener. Then type Ctrl-W to walk it. Step across my-arch Into into make-image Rinse, repeat. :) On Fri, Aug 10, 2012 at 2:08 PM, Michael Clagett mclag...@hotmail.com wrote: Quick question, if you're still on the horn. How do I trace into myarch make-image from the Listener. If I hit enter it just executes. I'm sure there must be any easy way to step into it, which I'm sure I can find by searching the documentation. But perhaps you could save me five minutes. From: mrj...@gmail.com Date: Fri, 10 Aug 2012 14:01:58 -0700 To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? Typically the architecture is a combination of os and arch: IN: scratchpad my-arch . unix-x86.64 You can use the my-arch word to make an image for your architecture: IN: scratchpad my-arch make-image On Fri, Aug 10, 2012 at 1:56 PM, Michael Clagett mclag...@hotmail.com wrote: Hi -- I've been trying to run the make-image word from the Listener and got as far as this trace: IN: scratchpad Command: restart 1: Note: Added bootstrap.image vocabulary to search path x86.32 make-image Loading resource:/core/bootstrap/stage1.factor Bootstrap stage 1... Loading vocab:bootstrap/primitives.factor Creating primitives and basic runtime structures... Loading vocab:bootstrap/syntax.factor From Traceback: Data Stack: [ ~quotation~ with-compilation-unit ] Bad architecture: x86.32 Call Stack: (U) Quotation: [ set-namestack init-catchstack self quot call - stop ] (O) Word:
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thank you, Joe, once again for your help. I have settled into a nice rythym of virtually tracing through the code by looking at the source (both vm and factor files), augmented by the Help system in the listener. That should keep me busy and out of your hair for a couple months (or couple years? :( ). Let me hold off on asking any more questions until I've had a chance to absorb some of this. Maybe one little question. Am I correct in suspecting that there is a high-level Factor word I can execute on demand and trace through the exectution of via the Factor debugger to get a more dynamic picture of how this all unfolds? Would it be make-image? Can you just call that directly or is it only called in the context of a sequence of operations that have already set other things up? Date: Wed, 8 Aug 2012 21:12:23 -0700 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Wed, Aug 8, 2012 at 8:23 PM, Joe Groff arc...@gmail.com wrote: The code in the bootstrap.image module outputs the bootstrap image as a binary blob. You can get a sense for the format of the bootstrap image and its contents by looking at that module. To clarify, by output as a binary blob I mean the code in bootstrap.image doesn't have any special help from the VM—it just generates a byte array whose contents resemble a Factor image and outputs that to a file. It could be transliterated to another language and still generate a valid boot image. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
On Wed, Aug 8, 2012 at 9:56 PM, Michael Clagett mclag...@hotmail.com wrote: Hi Joe -- Thank you so much for your guidance. I'm assuming that it is the basis\bootstrap\image\image.factor and the core\bootstrap\primitives.factor, stage1.factor and syntax.factor that you are referring to? One question just to help me get oriented before I go into heavy head-twisting mode. I notice that all these files have significant numbers of pre-existing vocabularies that they use. If this is what is used to generate the early stage1 bootstrapping stuff, then am I correct to assume that this is done from some version of factor where all this stuff has built already from scratch (that would be the implication, if all these files are able to use those vocabularies)? Or is there some other mechanism at work here that I should know about, and if so, is it written up anywhere that you know about. I have just read Slava's January 2010 post on the bootstrapping mechanism, so I understand the mechanism a bit better now, but am still thinking there has to be some Factor system somewhere that was built without a bootstrap image in order to have the vocabularies available that are used to generate the bootstrapping. Is there anything anywhere documenting that aspect of the picture. The reason I ask is that I would like to get a sense of how extensive that core fundamental set of vocabularies is that is needed to process the primitives and stage1 factor files. Here's the USING statement for primitives.factor: USING: alien alien.strings arrays byte-arrays generic hashtables hashtables.private io io.encodings.ascii kernel math math.private math.order namespaces make parser sequences strings vectors words quotations assocs layouts classes classes.private classes.builtin classes.singleton classes.tuple classes.tuple.private kernel.private vocabs vocabs.loader source-files definitions slots classes.union classes.intersection classes.predicate compiler.units bootstrap.image.private io.files accessors combinators ; IN: bootstrap.primitives It's got a lot of stuff there. Is a lot of this built in the C++ code that constitutes the VM? Or is some fundamental processing capability put into place that allows the processing of factor files to build these vocabularies? And if so, is the factor source used also included in the downloaded platform? Or was this a special primordial code base that was used once and never really needed again? Although core/bootstrap/primitives.factor is in core/, it's not actually loaded as-is into the boot image; it's really a script designed to run as part of `make-image` in the host image. All of those modules are loaded and run in the host image. While there of course had to have been a primordial Factor that could boot itself, I think it would be too different now to resemble current Factor. Factor's bootstrapping loop evolved somewhat organically. You can tell whether a word is a C++ primitive by `see`ing it in the listener. Primitive words show up as `PRIMITIVE:` when prettyprinted. At a high level, `make-image` has two stages: First, it executes `core/bootstrap/stage1.factor`, which runs 'bootstrap/syntax.factor` to transfer the basic syntax from the host image to the boot image, `bootstrap/primitives.factor` to set up primitive words corresponding to VM primitives, and a CPU-specific `basis/cpu/*/bootstrap.factor` script to assemble sub-primitives which are blobs of assembly language code composed by the VM's compiler. It also composes a startup quotation to begin the second stage of bootstrap when the boot image is started. Second, after the bootstrapping elements have been loaded, it serializes the data structures loaded by the bootstrap scripts into a boot image. Again, it does this without help from the VM, though it does borrow some knowledge of layouts from the compiler and other Factor libraries. P.S. Incidentally, while I am on the subject, I find myself able to trace through the VM startup code in Visual Studio with no problem at all, until I get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive inside of a callback stub and then invokes that function. On both a Windows 7 platform and a Windows Server 2008 platform, my Visual Studio blows up when the callback address loaded into EDX is called. Anybody ever encountered this and any idea how to get around it? Factor code doesn't follow the C calling convention so it's unlikely that a debugger will be able to walk a stack with Factor frames. In recent versions of Factor you can trigger Factor's own low-level debugger with ^C, which will let you backtrace and step through Factor frames. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Much appreciated, thanks. I had actually already discovered some significant portion of what you explain below, which is why I'm going to hold off on the baby-step questions so that I can save the limited Joe Groff bandwidth that the universe is going to provide me for more meaty important stuff. Date: Thu, 9 Aug 2012 06:26:54 -0700 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Wed, Aug 8, 2012 at 9:56 PM, Michael Clagett mclag...@hotmail.com wrote: Hi Joe -- Thank you so much for your guidance. I'm assuming that it is the basis\bootstrap\image\image.factor and the core\bootstrap\primitives.factor, stage1.factor and syntax.factor that you are referring to? One question just to help me get oriented before I go into heavy head-twisting mode. I notice that all these files have significant numbers of pre-existing vocabularies that they use. If this is what is used to generate the early stage1 bootstrapping stuff, then am I correct to assume that this is done from some version of factor where all this stuff has built already from scratch (that would be the implication, if all these files are able to use those vocabularies)? Or is there some other mechanism at work here that I should know about, and if so, is it written up anywhere that you know about. I have just read Slava's January 2010 post on the bootstrapping mechanism, so I understand the mechanism a bit better now, but am still thinking there has to be some Factor system somewhere that was built without a bootstrap image in order to have the vocabularies available that are used to generate the bootstrapping. Is there anything anywhere documenting that aspect of the picture. The reason I ask is that I would like to get a sense of how extensive that core fundamental set of vocabularies is that is needed to process the primitives and stage1 factor files. Here's the USING statement for primitives.factor: USING: alien alien.strings arrays byte-arrays generic hashtables hashtables.private io io.encodings.ascii kernel math math.private math.order namespaces make parser sequences strings vectors words quotations assocs layouts classes classes.private classes.builtin classes.singleton classes.tuple classes.tuple.private kernel.private vocabs vocabs.loader source-files definitions slots classes.union classes.intersection classes.predicate compiler.units bootstrap.image.private io.files accessors combinators ; IN: bootstrap.primitives It's got a lot of stuff there. Is a lot of this built in the C++ code that constitutes the VM? Or is some fundamental processing capability put into place that allows the processing of factor files to build these vocabularies? And if so, is the factor source used also included in the downloaded platform? Or was this a special primordial code base that was used once and never really needed again? Although core/bootstrap/primitives.factor is in core/, it's not actually loaded as-is into the boot image; it's really a script designed to run as part of `make-image` in the host image. All of those modules are loaded and run in the host image. While there of course had to have been a primordial Factor that could boot itself, I think it would be too different now to resemble current Factor. Factor's bootstrapping loop evolved somewhat organically. You can tell whether a word is a C++ primitive by `see`ing it in the listener. Primitive words show up as `PRIMITIVE:` when prettyprinted. At a high level, `make-image` has two stages: First, it executes `core/bootstrap/stage1.factor`, which runs 'bootstrap/syntax.factor` to transfer the basic syntax from the host image to the boot image, `bootstrap/primitives.factor` to set up primitive words corresponding to VM primitives, and a CPU-specific `basis/cpu/*/bootstrap.factor` script to assemble sub-primitives which are blobs of assembly language code composed by the VM's compiler. It also composes a startup quotation to begin the second stage of bootstrap when the boot image is started. Second, after the bootstrapping elements have been loaded, it serializes the data structures loaded by the bootstrap scripts into a boot image. Again, it does this without help from the VM, though it does borrow some knowledge of layouts from the compiler and other Factor libraries. P.S. Incidentally, while I am on the subject, I find myself able to trace through the VM startup code in Visual Studio with no problem at all, until I get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive inside of a callback stub and then invokes that function. On both a Windows 7 platform and a Windows Server 2008 platform, my Visual Studio blows up when the callback address loaded into EDX is called. Anybody ever encountered this and any idea how to get
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Quick question about parse-file.Is the quotation that is returned on the stack as a result of this word a parse tree, as discussed in the documentation's article on parsing? This would be a parse tree as in Tokens are appended to the parse tree, the top level of which is a quotation returned by the original parser invocation., right? There could also potentially be nested elements in the tree contributed by other parse words encountered in the course of satisfying the original parser invocation. Am I understanding this correctly? Thanks. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
On Wed, Aug 8, 2012 at 3:24 PM, Michael Clagett mclag...@hotmail.com wrote: Hi -- I've been tracing through the initial vm initialization code trying to get a picture of how Factor bootstraps itself. Does anyone know if there is a way to resolve code in the initial boot image that is being jit-compiled by factor_vm::prepare_boot_image to a set of symbolic names that can give a hint as to what functionality is included there? I'm trying to get a sense of the minimal functional set included here that allows higher-level initial code to be compiled. The comment on prepare_boot-image says /* Compile code in boot image so that we can execute the startup quotation */. It would be nice to know what this code includes. My guess is that the answer is no, there is no way and that one just has to be in possession of whatever code generated it (and there's nothing to say that this was even a Factor system that did this in the first place; could have easily been some C++ code that just knew what bits to emit). But it never hurts to ask... Presumably if I proceed past this to a point where actual Factor code is being parsed and compiled, I'll be able to get a feel for what primitives are already being depended on? Or maybe not. Maybe it's just a big bang where earlier word definitions can depend on later word definitions having been initialized before they start their execution. Is mine a hopeless effort? Would be nice to know before I suck up too much time with it. Thanks for any guidance anyone can provide. Regards, Mike The code in the bootstrap.image module outputs the bootstrap image as a binary blob. You can get a sense for the format of the bootstrap image and its contents by looking at that module. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
On Wed, Aug 8, 2012 at 8:23 PM, Joe Groff arc...@gmail.com wrote: The code in the bootstrap.image module outputs the bootstrap image as a binary blob. You can get a sense for the format of the bootstrap image and its contents by looking at that module. To clarify, by output as a binary blob I mean the code in bootstrap.image doesn't have any special help from the VM—it just generates a byte array whose contents resemble a Factor image and outputs that to a file. It could be transliterated to another language and still generate a valid boot image. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Hi Joe -- Thank you so much for your guidance. I'm assuming that it is the basis\bootstrap\image\image.factor and the core\bootstrap\primitives.factor, stage1.factor and syntax.factor that you are referring to? One question just to help me get oriented before I go into heavy head-twisting mode. I notice that all these files have significant numbers of pre-existing vocabularies that they use. If this is what is used to generate the early stage1 bootstrapping stuff, then am I correct to assume that this is done from some version of factor where all this stuff has built already from scratch (that would be the implication, if all these files are able to use those vocabularies)? Or is there some other mechanism at work here that I should know about, and if so, is it written up anywhere that you know about. I have just read Slava's January 2010 post on the bootstrapping mechanism, so I understand the mechanism a bit better now, but am still thinking there has to be some Factor system somewhere that was built without a bootstrap image in order to have the vocabularies available that are used to generate the bootstrapping. Is there anything anywhere documenting that aspect of the picture. The reason I ask is that I would like to get a sense of how extensive that core fundamental set of vocabularies is that is needed to process the primitives and stage1 factor files. Here's the USING statement for primitives.factor: USING: alien alien.strings arrays byte-arrays generic hashtables hashtables.private io io.encodings.ascii kernel math math.private math.order namespaces make parser sequences strings vectors words quotations assocs layouts classes classes.private classes.builtin classes.singleton classes.tuple classes.tuple.private kernel.private vocabs vocabs.loader source-files definitions slots classes.union classes.intersection classes.predicate compiler.units bootstrap.image.private io.files accessors combinators ; IN: bootstrap.primitives It's got a lot of stuff there. Is a lot of this built in the C++ code that constitutes the VM? Or is some fundamental processing capability put into place that allows the processing of factor files to build these vocabularies? And if so, is the factor source used also included in the downloaded platform? Or was this a special primordial code base that was used once and never really needed again? Any clarification you can provide (or better yet, any sources you can point me to that I can go and do the work to gain an understanding of this) would be greatly, greatly appreciated. I envision creating my own Inside the Factor VM and possibly inside the Factor Compiler writeup once I have accomplished what I am after. So hopefully I can give back a little after traveling up these respective learning curves. Thanks much. Mike P.S. Incidentally, while I am on the subject, I find myself able to trace through the VM startup code in Visual Studio with no problem at all, until I get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive inside of a callback stub and then invokes that function. On both a Windows 7 platform and a Windows Server 2008 platform, my Visual Studio blows up when the callback address loaded into EDX is called. Anybody ever encountered this and any idea how to get around it? Thanks. Date: Wed, 8 Aug 2012 20:23:04 -0700 From: arc...@gmail.com To: factor-talk@lists.sourceforge.net Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? On Wed, Aug 8, 2012 at 3:24 PM, Michael Clagett mclag...@hotmail.com wrote: Hi -- I've been tracing through the initial vm initialization code trying to get a picture of how Factor bootstraps itself. Does anyone know if there is a way to resolve code in the initial boot image that is being jit-compiled by factor_vm::prepare_boot_image to a set of symbolic names that can give a hint as to what functionality is included there? I'm trying to get a sense of the minimal functional set included here that allows higher-level initial code to be compiled. The comment on prepare_boot-image says /* Compile code in boot image so that we can execute the startup quotation */. It would be nice to know what this code includes. My guess is that the answer is no, there is no way and that one just has to be in possession of whatever code generated it (and there's nothing to say that this was even a Factor system that did this in the first place; could have easily been some C++ code that just knew what bits to emit). But it never hurts to ask... Presumably if I proceed past this to a point where actual Factor code is being parsed and compiled, I'll be able to get a feel for what primitives are already being depended on? Or maybe not. Maybe it's just a big bang where earlier word definitions can depend on later word definitions having been initialized before they start their execution. Is mine a
