Re: [Factor-talk] Hooking the Back End

In that scenario, you are supposed to start a new thread in which the copying proceeds. Factor's IO is implemented as a blocking facade around an asynchronous core. That's why the CopyFile call on Windows is likely a bug, it is blocking for real. See this thread:

Re: [Factor-talk] Hooking the Back End

15.06.2016, 00:20, "Doug Coleman" :Methods on object work for any object, even ``f``, but any more specific type will override and get called instead. Methods on object are default methods, but the windows-specific method is worse since it blocks.  I see, that's good to

Re: [Factor-talk] Hooking the Back End

Methods on object work for any object, even ``f``, but any more specific type will override and get called instead. Methods on object are default methods, but the windows-specific method is worse since it blocks. Is there a native windows api call that doesn't block, or should we just use the

Re: [Factor-talk] Hooking the Back End

Hello, Doug! I'm a bit confused, because I found this code: IN: io.directories.windows M: windows copy-file ( from to -- )    dup parent-directory make-directories    [ normalize-path ] bi@ 0 CopyFile win32-error=0/f ; This code defines copy-file as a method on "windows", and the code you quoted

Re: [Factor-talk] Hooking the Back End

Hey Alexander, We have a copy-file implemented with stream-copy already. It's non-blocking and it might be fast enough, or we could optimize it. I haven't looked at CopyFile for a long time, but maybe we shouldn't use that and should use the default stream-copy version instead. Then you don't

Re: [Factor-talk] Hooking the Back End

The delegate vocabulary might work. Also could initialed the Windows backend and then set yours and for all words you hart implemented just call the Windows one. > On Jun 13, 2016, at 11:28 AM, Alexander Ilin wrote: > > Hello! > > I'm having a bit of a fun problem, and