IN: lisppaste
REQUIRES: libs/xml-rpc ;
USING: arrays kernel xml-rpc ;
: url "http://www.common-lisp.net:8185/RPC2" ;
: lisppaste ( channel user title contents -- response )
4array "newpaste" swap <rpc-method> url post-rpc ;
"#concatenative" "jane_doe" "Test" "Testing testing" lisppaste
demos/ directory; it is very simple and elegant:IN: rot13
USING: kernel math sequences strings ;
: rotate ( ch base -- ch ) tuck - 13 + 26 mod + ;
: rot-letter ( ch -- ch )
{
{ [ dup letter? ] [ CHAR: a rotate ] }
{ [ dup LETTER? ] [ CHAR: A rotate ] }
{ [ t ] [ ] }
} cond ;
: rot13 ( string -- string ) [ rot-letter ] map ;
Well, the SBCL web site hasn't been updated yet and there's been no official announcement; however, SBCL has been tagged 1.0 in CVS, and the 1.0 tarball has been put up on SourceForge, so I guess this is it.
./f -e='2 2 + .'./f -e='2 2 + .' -shell=none
examples/color-picker.factor. Here is a walk-through:IN: color-picker
USING: gadgets-sliders gadgets-labels gadgets models arrays
namespaces kernel math prettyprint sequences ;
: <color-slider> ( -- gadget )
<x-slider>
1 over set-slider-line
255 over set-slider-max ;
: <color-preview> ( model -- gadget )
<gadget> { 100 100 } over set-rect-dim
[ set-gadget-interior ] <control> ;
<solid> class, which can then be passed to set-gadget-interior:: <color-model> ( model -- model )
[ [ 256 /f ] map 1 add <solid> ] <filter> ;
: <color-sliders> ( -- model gadget )
[
<color-slider> dup , control-model
<color-slider> dup , control-model
<color-slider> dup , control-model
3array <compose>
] { } make make-pile 1 over set-pack-fill ;
: <color-picker> ( -- gadget )
{
{ [ <color-sliders> ] f f @top }
{ [ dup <color-model> <color-preview> ] f f @center }
{ [ [ unparse ] <filter> <label-control> ] f f @bottom }
} make-frame ;
PROVIDE: examples/color-picker ;
MAIN: examples/color-picker
<color-picker> "Color Picker" open-titled-window ;
contrib/xml-rpc. Good stuff! After I release Factor 0.87 I'm going to get back to work on the web framework, and cook something up so that web apps automatically have an XML-RPC interface. I'd also like to put together a demonstration app that uses the XML-RPC client to make pastes at Lisppaste.
"examples/mslug-talk" run-moduleC+m, and type mslug (or any other sequence until the first completion in the popup is the correct module) then press ENTER. Use the arrow keys to navigate the slides. However I don't think they will make much sense, unless you were there, since I said a lot more than what was written in the bullet points.
examples/mslug-talk when it is done.
+ Core
- Improved memory management code leads to reduced memory consumption, less frequent garbage collections and fixes a few corner cases where Factor could run out of heap even if a GC would have freed enough memory to proceed
- Improved prettyprinter low lays out code in a more pleasing manner
- Windows native I/O has been sped up (Doug Coleman)
+ UI
- Double and triple clicks are now recognized, and can be used to select text in the editor gadget
- Windows now update while being resized on Windows
+ Stack effect inference
- The new infer. word should be called instead of infer, since it presents information in a more pleasing way
- Stack effect inference now infers variables read and written by a quotation to facilitate code comprehension and debugging
+ Module system
- The syntax for PROVIDE: has changed, consult the documentation
- Modules can now provide a main entry point, see run-module and MAIN:
- Modules can now provide documentation, see Documenting modules
+ Contributed libraries
- New contrib/cpuinfo (Doug Coleman)
- Updated contrib/match (Chris Double)
- Updated contrib/parser-combinators (Chris Double)
- Updated contrib/postgresql (Doug Coleman)
- Updated contrib/process (Doug Coleman)
- Updated contrib/sqlite (Doug Coleman)
- Updated contrib/textmate (Benjamin Pollack)
- Updated contrib/tuple-db (Doug Coleman)
- Updated contrib/vim (Doug Coleman)
- Updated contrib/xml (Daniel Ehrenberg)
: averages ( seq -- seq )
[ first2 + 2 / ] map ;
: differences ( seq averages -- differences )
>r 0 <column> r> [ - ] 2map ;
: haar-step ( seq -- differences averages )
2 group dup averages [ differences ] keep ;
: haar ( seq -- seq )
dup length 1 <= [ haar-step haar swap append ] unless ;
infer word has been replaced with an infer. word which gives variable usage information obtained by statically analyzing the code. Those in the know will recognize that this is a ripoff of InterLisp's MASTERSCOPE package. Here is an example:SYMBOL: x
[ 3 * x set ] infer.
* Stack effect:
( object -- )
* Writes free variables:
x
with-scope, the assignment is lost as soon as the scope ends and there is no observable side effect:[ [ 3 * x set ] with-scope ] infer.
* Stack effect:
( object -- )
[ [ x get ] with-scope ] infer.
* Stack effect:
( -- object )
* Reads free variables:
x
[ [ 5 x set [ x get ] with-scope ] with-scope ] infer.
* Stack effect:
( -- object )
get or set.2 * to the value of x:[ x [ 2 * ] change ] infer.
* Stack effect:
( -- )
* Reads free variables:
x
* Writes free variables:
x
change is defined, it just looks at the definition of change;: change ( variable quot -- )
>r dup get r> rot slip set ; inline
[ [ 5 x set-global ] with-scope ] infer.
* Stack effect:
( -- )
* Writes global variables:
x
frame method of NSWindow returns some client-side value, which is updated when the window receives events notifying it that it has been moved or resized. Which is all very well, but it seems that if you move the window around while it is not responding, then the frame method returns the old value! This is absurd.30000000 [ ] times (or anything else which takes several seconds to run). Then move the listener window around for a few seconds, then switch to another application. When Factor is done, switch back, and it will not respond to clicks because it will think the mouse location is different than what it actually is.
contrib/xml module to support XML namespaces, with XML-RPC support coming up next. Dan used to be active in the Factor community six months or so ago, and now he's back, which is great. Unlike some open source projects, Factor contributors seem to stick around for a long time. When I was working on jEdit, a big problem was people throwing a few patches and plugins over the fence, then disappearing a week later...
end-basic-block, which boxes any floating point values stored in registers, and moves them to the data stack. It also moves all other integer values and pointers to the stack too. Within a basic block, no stack writes are performed, and stack shuffling takes place at compile time in the form of register renaming. The fix for the inline allocation GC issue was to simply leave 1kb free at the top of the heap at all times, and if any float values were boxed, compile a call to a C function which performs a GC check in end-basic-block. This smells like the old issue that the entire GC refactoring was supposed to avoid (the GC on 75% heap consumption being inadequate) however very little memory is allocated by boxing floats, much less than 1Kb.end-basic-block would be called to generate machine code in a context where certain register values are not to be clobbered. For example, conditionals worked this way: first, the value at the top of the stack would be popped (which might not generate any code at all, if it is in a register), then the basic block would end so registers would sync with the in-memory stack, and then the conditional jump was performed based on the value of this register. This would no longer work, since end-basic-block could now generate a call into C, and thus the register holding the condition would be clobbered. The fix is not to end the basic block at a conditional jump, but instead "split" the virtual register representation of the stack at both branches. So for example if r3 held some known value before a conditional, the compiler could reuse this value in either branch without reading it back in.end-basic-block was when generating fixnum intrinsics which could overflow. These open-coded intrinsics are more efficient than calls into C, since in the common case of there not being an overflow, the code path re-uses registers rather than reading from the stack, and so on. For example, fixnum+ adds two integers, and if the result overflows, it allocates a bignum. Again, the problem was that it would read two values from the stack into registers (which might not have generated any machine code at all, if the value were already in registers), then it would end the basic block, then it would add them, and if an overflow occurred, it would call into C to allocate a bignum. This worked in the past, but now that the end of a basic block can call GC, the fix here is to open-code the bignum allocation code, and therefore avoid the need to end the basic block before fixnum+ is assembled in.end-basic-block were called remain untouched; namely, before jumping to another word definition, before returning from a word definition, and before an explicit alien call into C. In these cases, no values were held on in registers so a GC is safe. The removal of calls to end-basic-block from around conditionals and overflowing fixnum primitives means the compiler can keep more values in registers, generate less code to shuffle values between registers and memory, and box less floats. And of course, it also means that certain operations won't run out of memory even if plenty is available, simply because no GC check gets done.fixnum* intrinsic on both platforms; this results in an inline allocation of a 2-cell bignum, which is trickier than 1-cell bignum like fixnum+. I'm also hunting down a compiler bug which results in some words from contrib/crypto being miscompiled. Once these two items are done, I will release 0.86.
@Native(dll=foo,function=bar)
public void bar();
INLINE void allot_barrier(CELL address)
{
F_CARD *ptr = ADDR_TO_CARD(address);
F_CARD c = *ptr;
CELL b = card_base(c);
CELL a = (address & ADDR_CARD_MASK);
*ptr = (card_marked(c) | ((b < a) ? b : a));
}
INLINE void *allot_zone(F_ZONE *z, CELL a)
{
CELL h = z->here;
z->here = h + align8(a);
allot_barrier(h);
return (void*)h;
}
INLINE void *allot(CELL a)
{
return allot_zone(&nursery,a);
}
allot() function now looks like this:INLINE void maybe_gc(CELL a)
{
if(nursery.here + a > nursery.limit)
garbage_collection(NURSERY,false);
}
INLINE void *allot(CELL a)
{
maybe_gc(a);
return allot_zone(&nursery,a);
}
<array> primitive:F_ARRAY *allot_array(CELL type, F_FIXNUM capacity, CELL fill)
{
int i;
REGISTER_ROOT(fill);
F_ARRAY* array = allot_array_internal(type, capacity);
UNREGISTER_ROOT(fill);
for(i = 0; i > capacity; i++)
set_array_nth(array,i,fill);
return array;
}
REGISTER_ROOT macro adds the object to a stack, internal to the runtime, and the UNREGISTER_ROOT macro removes the topmost object and stores it back in the given variable. The GC scans this stack for roots just like it does with the data stack, etc. This stack is not accessible from the Factor side, and if an error is thrown between calls to REGISTER_ROOT and UNREGISTER_ROOT, its contents are reset.-S command line switch; it was actually first suggested by Doug Coleman in the context of cryptography algorithms, where you don't want your private key to hang around in memory longer than needed in the event of your swap file being stolen (although this seems way too paranoid for me). Obviously the second feature will be removed before release and I don't intend to add a switch to GC on every allocation after this refactoring is done.allot() function is bypassed, and allocation of a boxed float is done manually in a compiled intrinsic; this ensures that this can be done in a "basic block" without clobbering register contents, improving the efficiency of compiled floating point code.