[Factor-talk] More consistent word names

2009-10-28 Thread Doug Coleman
We've talked about renaming the destructive versions of words to be more consistent with the non-destructive versions for quite some time, but until now, little has been done in this direction. First off, I renamed change-each to map! and made map! return the sequence so the stack effect is

Re: [Factor-talk] More consistent word names

2009-10-28 Thread Chris Double
On Thu, Oct 29, 2009 at 9:35 AM, Doug Coleman doug.cole...@gmail.com wrote: I removed a couple of unused words: remove-all and substitute-here. How do you know they're unused? Chris. -- http://www.bluishcoder.co.nz

Re: [Factor-talk] More consistent word names

2009-10-28 Thread Doug Coleman
I used grep. I can add substitute-here as substitute! if you'd like. Remove-all, if it's useful at all, should be renamed to something else since sequences:remove is something quite different, and the name was confusing. In general, if there are no usages of a word in the Factor git

[Factor-talk] windows pipe race condition?

2009-10-28 Thread Phil Dawes
Hi Slava, Hi everyone, I've got the native thread message passing working really well on Linux, you can just do a '[ blah ] spawn-vm'. Unfortunately I'm having problems doing the same thing with io.pipes on windows. Here's a boiled down test case 'pipe-race.factor', which blows up with the error

[Factor-talk] Simplified locals: [let ] for scoping, : for binding (NEW! with multiple bindings)

2009-10-28 Thread Joe Groff
As I threatened to a few days ago, I've gone ahead and streamlined the locals vocabulary. Instead of having three different binding forms ([let | x [ y ] | ], [let* | x [ y ] | ], and y : x), we now only have : . [let ] remains as a way to establish a lexical scope in a : definition or

Re: [Factor-talk] More consistent word names

2009-10-28 Thread Chris Double
On Thu, Oct 29, 2009 at 10:32 AM, Doug Coleman doug.cole...@gmail.com wrote: I used grep.  I can add substitute-here as substitute! if you'd like. Remove-all, if it's useful at all, should be renamed to something else since sequences:remove is something quite different, and the name was

[Factor-talk] A couple more changes

2009-10-28 Thread Doug Coleman
I went ahead and added a new in-place accumulate word. accumulate! ( seq identity quot -- final seq ) Some more words have been renamed: (normalize-path) - absolute-path canonicalize-path - resolve-symlinks The difference between normalize-path and absolute-path is that normalize-path

Re: [Factor-talk] windows pipe race condition?

2009-10-28 Thread Paul Moore
2009/10/28 Paul Moore p.f.mo...@gmail.com: 2009/10/28 Phil Dawes p...@phildawes.net: Hi Slava, Hi everyone, I've got the native thread message passing working really well on Linux, you can just do a '[ blah ] spawn-vm'. Unfortunately I'm having problems doing the same thing with io.pipes on

Re: [Factor-talk] windows pipe race condition?

2009-10-28 Thread Paul Moore
2009/10/28 Paul Moore p.f.mo...@gmail.com: Yes, the default pipe creation in io.pipes.windows.nt makes the pipe handles non-inheritable. Rather than hacking the security attributes, you could use DuplicateHandle (from windows.kernel32) to create an inheritable copy of the handle. That should

Re: [Factor-talk] Simplified locals: [let ] for scoping, : for binding (NEW! with multiple bindings)

2009-10-28 Thread Adam
Reading the older docs for [let and [let* I see that the [let* form evaluates the bindings sequentially rather than in parallel. What order are the : bindings evaluated? I'm just curious as I haven't used the : form yet. On Wed, Oct 28, 2009 at 2:34 PM, Joe Groff arc...@gmail.com wrote: As I

Re: [Factor-talk] Simplified locals: [let ] for scoping, : for binding (NEW! with multiple bindings)

2009-10-28 Thread Jon Harper
There is no evaluation at all with :. All values have to be on the stack and : does the binding only. In some sense, you decide the evaluation order in the word generate-x-y-z. On Thu, Oct 29, 2009 at 11:20 AM, Adam hiat...@gmail.com wrote: Reading the older docs for [let and [let* I see that

Re: [Factor-talk] Simplified locals: [let ] for scoping, : for binding (NEW! with multiple bindings)

2009-10-28 Thread Joe Groff
On Oct 28, 2009, at 9:20 PM, Adam wrote: Reading the older docs for [let and [let* I see that the [let* form evaluates the bindings sequentially rather than in parallel. What order are the : bindings evaluated? I'm just curious as I haven't used the : form yet. As Jon said, : binds the

Re: [Factor-talk] Simplified locals: [let ] for scoping, : for binding (NEW! with multiple bindings)

2009-10-28 Thread Adam
This makes perfect sense. What do you think of : or : rather than : to align with the way accessors/converters have the convention of? The current : just seems jarring but that's just my opinion. Thanks again for the clarification. -Adam On Wed, Oct 28, 2009 at 8:09 PM, Joe Groff