[Factor-talk] Factor 0.95 now available
"The reports of my death are greatly exaggerated" - Mark Twain I'm very pleased to announce the release of Factor 0.95! You can find download links on the Factor website: http://factorcode.org This release is brought to you with over 2,500 commits by the following individuals: Alex Vondrak, Alfredo Beaumont, Andrew Pennebaker, Anton Gorenko, Brennan Cheung, Chris Double, Daniel Ehrenberg, Doug Coleman, Eric Charlebois, Eungju Park, Hugo Schmitt, Joe Groff, John Benediktsson, Jon Harper, Keita Haga, Maximilian Lupke, Philip Searle, Philipp Brüschweiler, Rupert Swarbrick, Sascha Matzke, Slava Pestov, @8byte-jose, @yac, @otoburb, @rien In addition to lots (and lots!) of bug fixes and improvements, I want to highlight the following features: * GTK-based UI backend * Native image loaders using Cocoa, GTK, and GDI+ * Sampling profiler replacing counting profiler * Code coverage tool to improve unit tests * VM and application-level signal handlers * ICMP support and an IPv4 "ping" implementation * DNS client and "host" implementation * Support frexp and log of "really big numbers" * Cross-platform "open URL in webbrowser" * Cross-platform "send file to trash" * Speedup bignum GCD and ratio operations * Speedup in thread yield performance on Mac OS X * CSV library is 3x faster * XML library is 2x faster * JSON library is 2-3x faster * Many documentation improvements * Many stability and performance enhancements Some possible backwards compatibility issues: * Change alien references from "" to "int " and "*int" to "int deref" * Removed Windows CE, BSD, and Solaris platform support * Natively support binary (0b), octal (0o), and hexadecimal (0x) number syntax * Unify "( -- )" and "(( -- ))" stack effect syntax * Change prepend to return type of first sequence to match append behavior * Change ".factor-rc" to be ".factor-rc" on all platforms * Cleanup specialized array syntax to be more generic and consistent * Change to quadratic probing instead of linear probing in hashtables * Allow dispatching on anonymous intersections/unions For more details, please see the full announcement at: http://re-factor.blogspot.com/2012/08/factor-095-now-available.html -- 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" 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?
> 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?
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)? slot ( obj m
-- value )
Vocabulary
slots.privateInputs and outputs
obj an object
m a non-negative fixnum
value an object Word description
Reads the object stored at the nth slot of obj.
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. So am I understanding this correctly? By the way, the words
you pointed me to are exceedingly useful, thank you very much. I hate to be so
needy, but this is foundational stuff that will help me immensely with my task
(which should produce documentation goodies for the entire community).
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 "hashtable"vocabulary"hashtables"
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 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-v
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
fixnum>slot@
! 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(tag(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 wrote:
> 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"
> vocabulary"hashtables"
> 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 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 fo
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 "hashtable"vocabulary"hashtables"
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 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-glob
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"
vocabulary"hashtables"
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 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' and then
> > 'save' your image.
> >
> >
> > Doug
> >
> >
> > On Wed, Aug 15, 2012 at 8:22 AM, Michael Clagett
> wrote:
> >
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Something just occurred to me about the message below. Could it be that this
array is some sort of underlying layout of the hash table and that the slots of
the target array that hash table contents are mapped to are the underlying
buckets that the hash function maps to? If this were the case, it still
leaves as a mystery why this gets returned from asking for slot # 4 of the hash
table. Maybe I'll go look in the cpp code for the underlying implementation
of hash table and this will all reveal itself.
From: mclag...@hotmail.com
To: factor-talk@lists.sourceforge.net
Date: Thu, 16 Aug 2012 13:01:45 +
Subject: 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 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" 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
> > 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
> >> > 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-ta
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 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" 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
> > 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
> >> > 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
> >> > > thi
