Re: [Factor-talk] Defining enumerations
2009/1/21 Slava Pestov sl...@factorcode.org: Have you seen C-ENUM: in alien.syntax? No, I hadn't. Thanks for the pointer. It's nice to see that it's quite similar to mine :-) This word is in alien.syntax because we generally only use it when interfacing with C libraries. If you just need symbolic constants (without requiring them to be consecutive numbers), use SYMBOLS: or SINGLETONS:. I was looking at having an array of actions indexed by symbolic constants, so I did need consecutive numbers. Having said that, a hashtable indexed by symbols, or a generic function dispatching on singletons, would probably do the same job. I suspect I was just letting C-based coding habits (where an indexed array would be distinctly faster) rule my design. I may still try it, just to get a feel for relative performance... (Hmm, for experiments like this, in C I might well write the 3 versions of the code using #ifdefs and use -Dxxx at compile time to build the 3 variants, to test them. What would be an idiomatic way of doing something similar in factor?) Paul. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Defining enumerations
Hi Paul,
If you're looking to make instruction dispatch fast in your VM, one
thing worth trying is to use a 'case' indexed by enum elements.
You'll need to cook up some parsing words, first.
IN: lpeg
...
SYMBOL: instructions
H{ } clone instructions set-global
! INSN: word body ;
: INSN: scan-word parse-definition swap instructions get set-at ; parsing
! DISPATCHER: new-word
! Creates new-word ( insn# -- ), change effect if you need more parameters
: DISPATCHER:
CREATE-WORD instructions get alist '[ _ case ] (( insn# -- ))
define-declared ; parsing
C-ENUM: first-insn second-insn third-insn ... ;
INSN: first-insn ... ;
INSN: second-insn ... ;
INSN: third-insn ... ;
DISPATCHER: exec
As I mentioned before, make sure that all the critical words have
static stack effects. You can assert this with unit tests:
\ exec must-infer
One other thing to try: declare any words which operate on your VM
tuple 'inline', then supposing the exec word has effect ( vm insn --
vm ), put hints on it:
HINTS: exec vm instruction ;
Slava
On Wed, Jan 21, 2009 at 2:35 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/1/21 Slava Pestov sl...@factorcode.org:
Have you seen C-ENUM: in alien.syntax?
No, I hadn't. Thanks for the pointer. It's nice to see that it's quite
similar to mine :-)
This word is in alien.syntax
because we generally only use it when interfacing with C libraries. If
you just need symbolic constants (without requiring them to be
consecutive numbers), use SYMBOLS: or SINGLETONS:.
I was looking at having an array of actions indexed by symbolic
constants, so I did need consecutive numbers. Having said that, a
hashtable indexed by symbols, or a generic function dispatching on
singletons, would probably do the same job. I suspect I was just
letting C-based coding habits (where an indexed array would be
distinctly faster) rule my design. I may still try it, just to get a
feel for relative performance...
(Hmm, for experiments like this, in C I might well write the 3
versions of the code using #ifdefs and use -Dxxx at compile time to
build the 3 variants, to test them. What would be an idiomatic way of
doing something similar in factor?)
Paul.
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] Fuel bug with quotes
Hi Jose, I'd like to echo the sentiments expressed on this list about how amazing FUEL is. In many ways this is as nice as or sometimes even nicer than SLIME. I found one small bug in FUEL (from the 01/15 download from Factor website of Windows binaries) with quoting. FUEL seems to be getting confused when it encounters a string like: \\t\ In the editor it's showing everything after the quotes (all words, etc.) in the color indicating that they are inside a string. However this seems to work (in terms of highlighting): \ \t \ Thanks, Glenn V. Glenn Tarcea gtar...@umich.edu -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] multiple threads using file system monitors
Slava, Here's a simple word which uses monitors: :: show-dir-changes ( PATH -- ) [ [let | MONITOR [ PATH t monitor ] | [ MONITOR next-change drop . t ] loop ] ] with-monitors ; If I open three ui listener windows and in each one do: home show-dir-changes they don't all report the same changes. Sometimes one shows changes, sometimes two, but rarely do all three report the same changes. I tried using three listener windows in the same Factor process as well as three separate processes; the problem happens in both cases. This is on Linux 32-bit. Ed -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Fuel bug with quotes
Hi Glenn, V. Glenn Tarcea gtar...@umich.edu writes: Hi Jose, I’d like to echo the sentiments expressed on this list about how amazing FUEL is. In many ways this is as nice as or sometimes even nicer than SLIME. Thank you. I come from a lisp background, and slime is of course a source of inspiration. I found one small bug in FUEL (from the 01/15 download from Factor website of Windows binaries) with quoting. FUEL seems to be getting confused when it encounters a string like: “\”\t\”” In the editor it’s showing everything after the quotes (all words, etc…) in the color indicating that they are inside a string. However this seems to work (in terms of highlighting): “\”” “\t” “\”” I think this bug is fixed in the my current development tree, and perhaps in Slava's; at any rate, once the got in sync and new binaries are generated, string highlighting should be working. Thanks for the report! And please do not hesitate to ask for more fixes or features you'd like to see in FUEL. Cheers, jao -- I didn't do it, and I'll never do it again. -Derrik Weeks -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] updated with-slots
Hi Your with-slots word would be interesting to reimplement the loadable-values vocab I proposed a few days ago. Nevertheless I really don't understand why the slots of abc are lowercase and accessors in the scope are uppercase. It's really hard for me to switch from the one to other and keeping in mind that it's the same object behind. Jeff Le 20 janv. 09 à 20:45, Eduardo Cavazos a écrit : Hello, A new version of 'with-slots' is available. I'm hosting it in this repository intended for my experimental stuff not in the mainline Factor tree: git://github.com/dharmatech/dharmalab.git Ed -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] git-tool
Hello, There's a Git frontend written in Factor available in my dharmalab repository: git://github.com/dharmatech/dharmalab.git This is alpha software. Bug reports are not welcome. :-) I'm sharing it for folks who are curious. If you have fixes or design suggestions, they are welcome. :-) USE: git-tool You can monitor a given repository via: path to repositrory... git-tool Or if you want the special case of starting it on the repository associated with the Factor tree, do: factor-git-tool This project showcases (and stresses) some hardcore Factor features like cross-platform file system monitoring and process launching. I've been using it heavily on Linux. I've yet to work on support for the other platforms. However, I have succesfully run it on Windows. Performance there is pretty bad if you're using the cygwin git; native Win32 git resolves this. The version of 'git-tool' in the repository above is the latest (rewritten) version. Please ignore the one that's currently in the mainline Factor tree. Slava, I have some patches for mainline, some of which remove the unmaintained 'git-tool' in your repository: git://github.com/dharmatech/factor.git Ed -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] with-slots using all caps slots
Jean-François Bigot wrote: Nevertheless I really don't understand why the slots of abc are lowercase and accessors in the scope are uppercase. It's really hard for me to switch from the one to other and keeping in mind that it's the same object behind. Hi Jeff! Right now, with-slots is experimental. So I have it coded to use my personal convention of variable bindings in all caps. However, if Slava decided to have with-slots in basis, I'm sure it would be implemented with the more conservative lower-case variables. And at that point I'd have to hack together a with-SLOTS for my code... ;-) I don't like to force conventions on anybody... But I do find them useful. In Scheme and Lisp, function calls are denoted by parenthesis. So when you're reading code, you can tell if something's a procedure, just by it's position in a list. Not so with Factor code... So I like to use lot's of conventions for different kinds of objects; I definately like this part of the Perl culture. I.e. different things should look different. So far I have conventions for class names and lexically bound variables. 'with-slots' goes with the all caps, but I'm leaning towards yet another convention for the special case of variables bound by with-slots. Perhaps -xyz and xyz- for example. However, it'd be good to get alot more experience with with-slots first. Lastly, I'd like to say something about the implementation of with-slots. Factor has words, macros, and parsing words. The semantics of macros are familiar to Lispers; you expand an expression into another expression at compile time. These sorts of macros are great fun and are right at home in Factor. However, with-slots is not a macro in this sense. The with-slots expression conceptually expands into an expression involving [let and [wlet. Those are in turn parsing words. with-slots is also a parsing word. So the standard Factor mechanism for macros cannot be employed here. Alarmingly, the implementation doesn't generate expressions involving the actual [let and [wlet words! It must resort to using the backend 'let' and 'wlet' tuple datastructures. At this point, this strikes me as a weakness in locals and macros. I.e. with this kind of abstraction, traditional macros break down. Parsing words are really a whole new ball game. Ed -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] Pull request: inverse fix
Fixed the inverse definition of ^ and added a unit test. git://github.com/jwmerrill/factor.git commit 15fadbf0dd123da242cb947ecbe70f2146e91b78 tree7e7e789426b922bd1d7d727c81ef5c9625f77780 parent adc4245d8b56de05e5bbf7b93935868319732bcd Not sure if I've done this pull request correctly. If not, guidance appreciated. JM -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
