Re: [Factor-talk] Indentation in Emacs with factor-mode
Hi, You can fix the tabs on indent by putting the following in your .emacs (I also do this for my lisp code): (setq-default indent-tabs-mode nil) V. Glenn Tarcea [EMAIL PROTECTED] On Nov 15, 2008, at 9:22 PM, Eduardo Cavazos wrote: On Saturday 15 November 2008 19:35:53 Jose A. Ortega Ruiz wrote: Nope, i didn't touch the indentation code in factor.el (yet). But sounds like an easy fix. Ah... sorry about that. :-) Didn't mean to point the finger at ya. Those changes must have come in before yours; I just hadn't tested them thoroughly yet... OK. I can fix that (no tabs for indentation), and make the tab width customizable: does that sound good? Oh man... that would be so awesome. Getting the indentation style wrong is a source of conflict so we might have to nominate you for the Nobel Peace prize. :-) Ed - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Safe parsing
On Saturday 15 November 2008 22:49:17 Slava Pestov wrote:
But, if syntax is split up into two vocabularies, you'd be out of luck
for library data types. Eg, parsing a float array (using F{ in
float-arrays) is safe.
Yeah, words that provide literal syntax for library data would have to go in a
separate library. But that actually sounds good for use with words
like 'parse-with-vocabs'. It seems desirable to say:
... FACTOR DATA ...
{ syntax.literal syntax.literal.library }
parse-with-vocabs
and have control over what syntax is available.
Instead we could have a flag on parsing words, specifying if they're
safe or not. [ is safe, F{ is safe, but : is not safe and neither is
. USING: is safe, but IN: is not.
Well that's one way to do it.
I was actually thinking of categorizing 'syntax' even further:
syntax.defining Defining words like ':' and 'GENERIC:'
syntax.literal Literal syntax for data
syntax.parser Stuff that affects 'use' and 'in'
It would be nice to categorize parsing words by various properties. For
example, I think there's a notion of a functional parsing word. I.e. a
parsing word which has no side effects besides pushing onto the 'accum'.
Perhaps another category of parsing word is one which removes elements from
the 'accum' (an odd kind of word...) Finally, a non-functional parsing word
is one which has side effects, such as 'TUPLE:'.
So, you can organize them into vocabularies, tag them individually as you
mention above, or do the *really* elite thing and have a word which analyzes a
word for you and tells you if it's functional, defining, side-effecting, etc.
As far as safe code goes, I think defining words isn't so bad, it's changing
the using list which is dangerous. So now you're getting into
labeling vocabularies as safe or unsafe. So what's unsafe? To start with,
stuff like:
Launching external processes
Initiating network connections
Monkey patching existing vocabularies
(i.e. set 'in' to an existing system vocabulary and begin scribbling on
stuff)
To achieve sandboxed listeners, it would be nice to have a set of capabilities
and restrictions which can be composed. For example:
Only allow literal syntax for data structures in core
Cannot add things to 'use'
Cannot change 'in'
May add to use, but only from this specific list: ...
May add to use, any vocabulary marked as safe
May create new vocabularies
May not set 'in' to an existing vocabulary which you did not create
(i.e. cannot monkey patch a system vocabulary)
May define new words
May *not* define new words
etc...
How these are enforced is up for design.
I think breaking down 'syntax' into the 'literal', 'defining', and 'parser'
sub-vocabularies might be a step towards composing those capabilities in
limited listeners. However, it may not be as simple as that. For example,
even if you deny access to 'IN:', code might still be able to set 'in'
using 'set'. (but would it be possible at parse time?) Since 'use' and 'in'
affect things in such a powerful way, and since they are involved via
the 'namespaces' subsystem, controlling the ability to change variables
generally should also to be considered.
Ed
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Safe parsing
On Sun, Nov 16, 2008 at 9:29 AM, Eduardo Cavazos [EMAIL PROTECTED] wrote:
Yeah, words that provide literal syntax for library data would have to go in a
separate library. But that actually sounds good for use with words
like 'parse-with-vocabs'. It seems desirable to say:
... FACTOR DATA ...
{ syntax.literal syntax.literal.library }
parse-with-vocabs
and have control over what syntax is available.
If float-arrays defines F{ in syntax.literal.library, then the
following won't work in a new image:
USE: syntax.literal.library F{ 1 2 3 }
I was actually thinking of categorizing 'syntax' even further:
syntax.defining Defining words like ':' and 'GENERIC:'
syntax.literal Literal syntax for data
syntax.parser Stuff that affects 'use' and 'in'
This categorization would only apply to core syntax. Library syntax
never goes in the syntax vocab. For example, the MEMO: word is a
'defining word' however it is not in the syntax vocabulary, it is in
the memoize vocabulary.
It would be nice to categorize parsing words by various properties. For
example, I think there's a notion of a functional parsing word. I.e. a
parsing word which has no side effects besides pushing onto the 'accum'.
These are exactly the 'safe' words I am proposing. If they simply
parse a literal, you can use it without worrying about undesired side
effects.
As far as safe code goes, I think defining words isn't so bad, it's changing
the using list which is dangerous.
Actually, you can change the using list all you want and still get a
safe parser. I'm talking about making a safe 'parse', not a safe
'eval'. The latter is much more difficult.
I think breaking down 'syntax' into the 'literal', 'defining', and 'parser'
sub-vocabularies might be a step towards composing those capabilities in
limited listeners. However, it may not be as simple as that. For example,
even if you deny access to 'IN:', code might still be able to set 'in'
using 'set'. (but would it be possible at parse time?) Since 'use' and 'in'
affect things in such a powerful way, and since they are involved via
the 'namespaces' subsystem, controlling the ability to change variables
generally should also to be considered.
A safe parser would not allow IN: or , hence you'd never be able to
change 'in' at parse time.
A safe parser would still be able to parse code which is unsafe if
executed; for example,
USE: io.launcher
[ rm -rf / run-process ]
involves only safe parsing words.
So safe eval is harder problem and one I'm not interested in having
for Factor 1.0. But safe parsing seems pretty easy if you flag parsing
words as 'safe' and don't actually call the resulting quotation.
Slava
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Safe parsing
Hi Ed,
I just realized that the whole safe parsing words idea is subtly
flawed. For example, T{ is a safe parsing word but we can use it to
construct an object that crashes the Factor VM:
( scratchpad ) T{ vector f { } 100 } .
Memory protection fault at address 303038
Now that I think about it, I guess we could have a validate-literal
generic with methods on various types that is called by T{ to ensure
the constructed literal is valid. It could check invariants, and it
would address this particular problem. But I wonder if there's
anything else like this.
Slava
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Pull request: more emacs font lock goodies
On Sunday 16 November 2008 09:42:52 Jose A. Ortega Ruiz wrote: I'm very glad to help. I've sent another pull request with the indentation stuff in a separate email. I'll come up with more little improvements and cleanups to factor.el, but before i'd like to ask if you'd be comfortable with a couple of cosmetic changes: - I've been using the convention of using 'factor--foo' instead of 'factor-foo' for internal names. I'd like to homogenize factor.el naming: what convention do you prefer? I'm fine with either so you pick. - factor.el uses banners like this: ;; ;; section ;; to separate sections. I find it more useful (and aesthetically pleasant) using ^L (that's C-qC-l) for quick navigation: ^L ;;; section No big deal, but if you don't feel strongly about it, i'd change that. Not a problem, change away! I'm interested in any ideas you have for Emacs integration, minor and major. As you know, Factor is highly reflective so the skys the limit for cool integration tricks. We could totally give SLIME a run for it's money. ;-) Let me know if you need any help on the Factor side of things. Ed - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] springies demos not working ?
Hi all,
I noticed that none of the springies demos seem to be working.
I see the same problem on a G5 Powermac and Intel iMac running
OS 10.5.5.
All of the springies demos worked in the past on both my machines.
I first noticed the problem when I installed the latest Factor
about a week ago. Still not working with this version:
x86-64-2008-11-16-08-59
Here's the sort of error message I see -
An error occurred while drawing the world
T{ world f ~array~ ~array~ f f ~vector~ ~array~ ~slate~ t t f f
This world has been deactivated to prevent cascading errors.
Generic word parent does not define a method for the array class.
Dispatching on object: { 341.207804 48.561279 }
Thanks very much,
Dave F.
Eugene, Oregon, USA
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] springies demos not working ?
Hi,
Thanks for reporting the problem. The stack effect of gl-rect had
changed and I forgot to update springies. I pushed a patch fixing the
problem.
Incidentally, the compiler did catch the problem; when loading
springies, a message was printed reporting that there were compiler
errors. I guess this is a good time as any to extend our builder
program to check for compiler errors after doing load-everything, and
have it refuse to release binaries of there are any.
Slava
On Sun, Nov 16, 2008 at 12:47 PM, Dave Fashena [EMAIL PROTECTED] wrote:
Hi all,
I noticed that none of the springies demos seem to be working.
I see the same problem on a G5 Powermac and Intel iMac running
OS 10.5.5.
All of the springies demos worked in the past on both my machines.
I first noticed the problem when I installed the latest Factor
about a week ago. Still not working with this version:
x86-64-2008-11-16-08-59
Here's the sort of error message I see -
An error occurred while drawing the world
T{ world f ~array~ ~array~ f f ~vector~ ~array~ ~slate~ t t f f
This world has been deactivated to prevent cascading errors.
Generic word parent does not define a method for the array class.
Dispatching on object: { 341.207804 48.561279 }
Thanks very much,
Dave F.
Eugene, Oregon, USA
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Pull request: more emacs font lock goodies
Eduardo Cavazos [EMAIL PROTECTED] writes: Not a problem, change away! Thanks... i'll submit a new pull request shortly with the cosmetic changes. I'm interested in any ideas you have for Emacs integration, minor and major. As you know, Factor is highly reflective so the skys the limit for cool integration tricks. We could totally give SLIME a run for it's money. ;-) Well, yes, my idea, now that factor-mode is in better shape, is to implement something like slime, which is the most fun environment i've ever used. I know little about Factor yet, but i've already realized its potential in this (and many others) respect, and to me implementing the equivalent of the swank protocol will also be a good way of learning more about Factor. So, first thing i was thinking is to hack a 'superior factor interaction' mode which talks via a socket with a running factor listener. From there, adding slimy features should be a breeze. If you have suggestions for features beyond those present in slime, i'm all ears! Let me know if you need any help on the Factor side of things. I'll sure need lots of help on this side :) For starters, i've noticed there's already a 'factor-telnet' function in factor.el that, i presume, can connect to a running listener. Is that correct? What does the factor listener side need to do? Thanks! jao PS. BTW, Ed, i messed things up and lost a message with subject 'factor.el credit' that you sent me earlier today: could you please resend it to my gnu.org address? - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] Windows startup files heads-up
Hi all, On Windows, Factor now looks for files named factor-boot-rc and factor-rc in your home directory, without the leading period. Windows Explorer won't let you create files whose names start with a (.), and only on Unix does it make the files hidden anyway. So you will need to rename your startup files, if you use this feature. Slava - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] Small 'bug' in factor.el
The changes in the factor.el are great! One small 'problem' I found is that when highlighting keywords, a keyword like MIXIN: has the IN: highlighted, rather than the whole word. I haven't looked very hard at the regular expression matching, but one coughhackcough that fixes it is to move the MIXIN: keyword before the the IN: keyword in the factor--parsing-words defconst. Along the lines of a SLIME environment for Factor, you could call it Facture: The (Fac)tor (U)ltimate Edito(r) for (E)macs Facture: An artist's characteristic handling of paint. In this case the Paint is the Factor code. Thanks, Glenn V. Glenn Tarcea [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] tty-server
On Sunday 16 November 2008 13:55:15 Jose A. Ortega Ruiz wrote: I'll sure need lots of help on this side :) For starters, i've noticed there's already a 'factor-telnet' function in factor.el that, i presume, can connect to a running listener. Is that correct? What does the factor listener side need to do? Jose, Try this in Factor: USE: tty-server tty-server Then from a terminal: telnet 127.0.0.1 You should receive a listener prompt. Ed - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] springes are slow on OS X
On Sunday 16 November 2008 12:47:10 Dave Fashena wrote: I noticed that none of the springies demos seem to be working. I see the same problem on a G5 Powermac and Intel iMac running OS 10.5.5. Hi Dave, Besides that bug, there's also a bug which causes the springes demos to run much slower than they should on OS X (well, last time I checked). If you ever want to see how fast it's *supposed* to go, try out the springies demos on Linux if you get a chance. Ed - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Small 'bug' in factor.el
It looks like factor.el didn't get recompiled on my system until I made a change. Never mind this bug report. Glenn V. Glenn Tarcea [EMAIL PROTECTED] On Nov 16, 2008, at 8:27 PM, Glenn Tarcea wrote: The changes in the factor.el are great! One small 'problem' I found is that when highlighting keywords, a keyword like MIXIN: has the IN: highlighted, rather than the whole word. I haven't looked very hard at the regular expression matching, but one coughhackcough that fixes it is to move the MIXIN: keyword before the the IN: keyword in the factor--parsing-words defconst. Along the lines of a SLIME environment for Factor, you could call it Facture: The (Fac)tor (U)ltimate Edito(r) for (E)macs Facture: An artist's characteristic handling of paint. In this case the Paint is the Factor code. Thanks, Glenn V. Glenn Tarcea [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
