XAPI (Ximple API)

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

XAPI (Ximple API)

Juan Delgado
Hi there people : )

As recently commented, I'm planning to move part of HippoHX's API to
an independent library to be reused across projects. This would be an
API (see txt attached) on top of haxe/neko APIs, oriented to backend
targets and covering things like file management, system information,
etc. The idea is release it via standard haxelib as all other
libraries.

Just to be clear, there's nothing in this API that you cannot do with
some haxe/neko work already. So what's the point? Well, to me this one
is simpler and clearer to use. That's obviously quite a subjective
thing, so I'll let you decide. See a couple of examples on the txt.

There're also some additions that you can't do directly with the
official API, they are marked with an *. The most important are
Directory.copy and Search.search. Those 2 are completely home made in
HippoHX.

The good thing about this is that 90% of the current API is already
done for HippoHX, so this could be ready pretty quickly.

So, I'm looking for your ideas / advice regarding:

- A name. I was thinking XAPI (Ximple API, X coming from haXe,
obviously) but I don't particularly like it. Whatever we come up with,
it has to have a sort name-space so it's fast to use (xa.* or xapi.*).
- Things you miss or things you think are not needed. Keep in mind
that the idea is not wrapping the whole official API, only make those
methods that we use 80% of the time more accessible. Think of this as
a kind of handy shortcut.
- Feedback about Directory.copy() and Search.search() methods. Those 2
are more complicated than they look and precisely the 2 that I've
implemented myself in a kind of home-made approach. Specially in
Directory.copy() do we need a regexp to include files and another to
exclude them or only one of them should be enough? In both of them
"deep" means how many levels of recursion you want (-1 for all).
- I don't want to make it dependent of other libraries such as
Systools. The main reason is I want to keep it 100% cross-platform,
plus relying in other libs would make this one less... reliable : )

I'll be doing this during next week, so if you want to share any ideas
or comments during the next 2 - 3 days that would be much appreciated.

Cheers!

Juan

--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv

--
haXe - an open source web programming language
http://haxe.org

xapi.txt (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Juan Delgado
Little update: added System.isLinux and System.isUnix (true for Mac and Linux).

J

On Fri, Jan 29, 2010 at 8:53 PM, Juan Delgado <[hidden email]> wrote:

> Hi there people : )
>
> As recently commented, I'm planning to move part of HippoHX's API to
> an independent library to be reused across projects. This would be an
> API (see txt attached) on top of haxe/neko APIs, oriented to backend
> targets and covering things like file management, system information,
> etc. The idea is release it via standard haxelib as all other
> libraries.
>
> Just to be clear, there's nothing in this API that you cannot do with
> some haxe/neko work already. So what's the point? Well, to me this one
> is simpler and clearer to use. That's obviously quite a subjective
> thing, so I'll let you decide. See a couple of examples on the txt.
>
> There're also some additions that you can't do directly with the
> official API, they are marked with an *. The most important are
> Directory.copy and Search.search. Those 2 are completely home made in
> HippoHX.
>
> The good thing about this is that 90% of the current API is already
> done for HippoHX, so this could be ready pretty quickly.
>
> So, I'm looking for your ideas / advice regarding:
>
> - A name. I was thinking XAPI (Ximple API, X coming from haXe,
> obviously) but I don't particularly like it. Whatever we come up with,
> it has to have a sort name-space so it's fast to use (xa.* or xapi.*).
> - Things you miss or things you think are not needed. Keep in mind
> that the idea is not wrapping the whole official API, only make those
> methods that we use 80% of the time more accessible. Think of this as
> a kind of handy shortcut.
> - Feedback about Directory.copy() and Search.search() methods. Those 2
> are more complicated than they look and precisely the 2 that I've
> implemented myself in a kind of home-made approach. Specially in
> Directory.copy() do we need a regexp to include files and another to
> exclude them or only one of them should be enough? In both of them
> "deep" means how many levels of recursion you want (-1 for all).
> - I don't want to make it dependent of other libraries such as
> Systools. The main reason is I want to keep it 100% cross-platform,
> plus relying in other libs would make this one less... reliable : )
>
> I'll be doing this during next week, so if you want to share any ideas
> or comments during the next 2 - 3 days that would be much appreciated.
>
> Cheers!
>
> Juan
>
> --
> Juan Delgado - Zárate
> http://zarate.tv
> http://blog.zarate.tv
>


--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv

--
haXe - an open source web programming language
http://haxe.org

xapi.txt (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Heinz Hölzer-2
In reply to this post by Juan Delgado
Am 29.01.2010 21:53, schrieb Juan Delgado:
> - * copy(source : String, destination : String, ?exclude : EReg, ?include : EReg, ?deep : Int = 0) : Void //<--exclude hidden files by default?
>    

i would prefer:

copy (source:String, destination:String, ?exclude : String -> Bool,
?include : String -> Bool, ?recursive : Bool = false):Void

cheers
heinz

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Yanis Benson
On 01/31/2010 07:06 AM, Heinz Hölzer wrote:
> i would prefer:
>
> copy (source:String, destination:String, ?exclude : String -> Bool,
> ?include : String -> Bool, ?recursive : Bool = false):Void
>
> cheers
> heinz
>
WHat is exclude needed for then? One function can make it all.


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Heinz Hölzer-2
Am 31.01.2010 05:19, schrieb Yanis Benson:
On 01/31/2010 07:06 AM, Heinz Hölzer wrote:
i would prefer:

copy (source:String, destination:String, ?exclude : String -> Bool, ?include : String -> Bool, ?recursive : Bool = false):Void

cheers
heinz

WHat is exclude needed for then? One function can make it all.



that's true ;)

so it's

copy (source:String, destination:String, ?filter : String -> Bool, ?recursive : Bool = false):Void

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Juan Delgado
Hi there,

I like ?filter String -> Bool and leaving up to people implementing it
with a RegExp or whatever. Nice one.

2 things though:

1) Make it default to anything? As I say, maybe exclude hidden files
and folders by default. But I'm happy either way.

2) I still prefer using ?deep : Int = 0 for defining the levels of
recursion. I know this is a little bit less intuitive but much more
flexible in the long run. I got this idea from bash's command find
which you can tune with -maxdepth and -mindepth.

Find attached a new draft of the API with these changes and some other
minor adjustments I did yesterday night (mostly name simplifications
and re-arranging of some functions).

Thanks a lot!

Juan

2010/1/31 Heinz Hölzer <[hidden email]>:

> Am 31.01.2010 05:19, schrieb Yanis Benson:
>
> On 01/31/2010 07:06 AM, Heinz Hölzer wrote:
>
> i would prefer:
>
> copy (source:String, destination:String, ?exclude : String -> Bool, ?include
> : String -> Bool, ?recursive : Bool = false):Void
>
> cheers
> heinz
>
> WHat is exclude needed for then? One function can make it all.
>
>
>
> that's true ;)
>
> so it's
>
> copy (source:String, destination:String, ?filter : String -> Bool,
> ?recursive : Bool = false):Void
>
> --
> haXe - an open source web programming language
> http://haxe.org
>


--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv

--
haXe - an open source web programming language
http://haxe.org

xapi.txt (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Heinz Hölzer-2
I would add the filter to the search method, too.

how do i call copy (with depth) to copy a whole directory including all
subfolders (full recursion)?
does depth = 0 mean full recursion or flat copy?

heinz


Am 31.01.2010 10:16, schrieb Juan Delgado:

> Hi there,
>
> I like ?filter String ->  Bool and leaving up to people implementing it
> with a RegExp or whatever. Nice one.
>
> 2 things though:
>
> 1) Make it default to anything? As I say, maybe exclude hidden files
> and folders by default. But I'm happy either way.
>
> 2) I still prefer using ?deep : Int = 0 for defining the levels of
> recursion. I know this is a little bit less intuitive but much more
> flexible in the long run. I got this idea from bash's command find
> which you can tune with -maxdepth and -mindepth.
>
> Find attached a new draft of the API with these changes and some other
> minor adjustments I did yesterday night (mostly name simplifications
> and re-arranging of some functions).
>
> Thanks a lot!
>
> Juan
>
> 2010/1/31 Heinz Hölzer<[hidden email]>:
>    
>> Am 31.01.2010 05:19, schrieb Yanis Benson:
>>
>> On 01/31/2010 07:06 AM, Heinz Hölzer wrote:
>>
>> i would prefer:
>>
>> copy (source:String, destination:String, ?exclude : String ->  Bool, ?include
>> : String ->  Bool, ?recursive : Bool = false):Void
>>
>> cheers
>> heinz
>>
>> WHat is exclude needed for then? One function can make it all.
>>
>>
>>
>> that's true ;)
>>
>> so it's
>>
>> copy (source:String, destination:String, ?filter : String ->  Bool,
>> ?recursive : Bool = false):Void
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>>      
>
>
>    


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Juan Delgado
That would be with -1. And now that I think about it, it should
probably the default both for copy and search as that what people
would naturally expect.

Then if you use 0 you only copy / search on the path you pass, 1 you
go 1 level deep, and so on.

Makes sense?

2010/1/31 Heinz Hölzer <[hidden email]>:

> I would add the filter to the search method, too.
>
> how do i call copy (with depth) to copy a whole directory including all
> subfolders (full recursion)?
> does depth = 0 mean full recursion or flat copy?
>
> heinz
>
>
> Am 31.01.2010 10:16, schrieb Juan Delgado:
>>
>> Hi there,
>>
>> I like ?filter String ->  Bool and leaving up to people implementing it
>> with a RegExp or whatever. Nice one.
>>
>> 2 things though:
>>
>> 1) Make it default to anything? As I say, maybe exclude hidden files
>> and folders by default. But I'm happy either way.
>>
>> 2) I still prefer using ?deep : Int = 0 for defining the levels of
>> recursion. I know this is a little bit less intuitive but much more
>> flexible in the long run. I got this idea from bash's command find
>> which you can tune with -maxdepth and -mindepth.
>>
>> Find attached a new draft of the API with these changes and some other
>> minor adjustments I did yesterday night (mostly name simplifications
>> and re-arranging of some functions).
>>
>> Thanks a lot!
>>
>> Juan
>>
>> 2010/1/31 Heinz Hölzer<[hidden email]>:
>>
>>>
>>> Am 31.01.2010 05:19, schrieb Yanis Benson:
>>>
>>> On 01/31/2010 07:06 AM, Heinz Hölzer wrote:
>>>
>>> i would prefer:
>>>
>>> copy (source:String, destination:String, ?exclude : String ->  Bool,
>>> ?include
>>> : String ->  Bool, ?recursive : Bool = false):Void
>>>
>>> cheers
>>> heinz
>>>
>>> WHat is exclude needed for then? One function can make it all.
>>>
>>>
>>>
>>> that's true ;)
>>>
>>> so it's
>>>
>>> copy (source:String, destination:String, ?filter : String ->  Bool,
>>> ?recursive : Bool = false):Void
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>>
>>
>>
>>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

John A. De Goes
In reply to this post by Juan Delgado

This API is better organized and easier to understand than the haxe std lib, but you can do even better.

Designers generally make two errors when creating file system APIs:

1. A string or other single abstraction is used to represent everything in the file system, thus losing the benefits of strong typing.

2. The file system operations are hard coded to native file system operations, meaning if you later want your code to work with FTP, HTTP or another file system, you have to completely change all of your code. Also, it's not easy to write unit tests for some code, because it requires interacting with the real file system.

Fortunately, both errors can be solved in straightforward fashion:

1. "FSNode" should be the base class representing a node in the file system, from which File, Folder, FileLink, FolderLink derive (FileLink derives from File, FolderLink derives from Folder). The internal representation should be URI-based (e.g.: file://foo.txt). The scheme of the URI ("file" in this case) should be used internally by any methods that interact with the file system, such as File.instream (which might return an InputStream). In particular, a method node.x(...) is just shorthand for: SchemeHandler.forScheme(scheme).x(node, ...). For example, File.instream is shorthand for SchemeHandler.forScheme(myFile.scheme).instream(myFile).

2. SchemeHandler should be defined as an abstract class with all file system-related methods (reading files, writing files, moving files, retrieving permissions, setting permissions, etc.). It should also have several static methods: SchemeHandler.forScheme, which retrieves the particular scheme handler for the specified scheme; SchemeHandler.install, which installs a new scheme handler; SchemeHandler.listAll, which lists installed scheme handlers; and SchemeHandler.resolve, which resolves a string to an FSNode, based on the currently installed scheme handlers (the act of resolving requires determining whether something is a file, folder, file link, or folder link, so it depends on whether or not a scheme handler has been installed that can provide such information).

3. SchemeHandler should come pre-initialized with a SchemeHandlerFile, which extends SchemeHandler for the "file" scheme. Over time other implementations can be written: test (for writing unit tests), FTP, HTTP, SFTP, S3, etc.

This will provide a strongly-typed file system API, which will eliminate many errors at compile time, while also being extensible to handle any number of schemes. And if you code the API correctly, it can also be easy to use (though never quite as easy to use as a dumb API, you do pay a small price for the increase in flexibility).

Regards,

John 

On Jan 31, 2010, at 2:16 AM, Juan Delgado wrote:

Hi there,

I like ?filter String -> Bool and leaving up to people implementing it
with a RegExp or whatever. Nice one.

2 things though:

1) Make it default to anything? As I say, maybe exclude hidden files
and folders by default. But I'm happy either way.

2) I still prefer using ?deep : Int = 0 for defining the levels of
recursion. I know this is a little bit less intuitive but much more
flexible in the long run. I got this idea from bash's command find
which you can tune with -maxdepth and -mindepth.

Find attached a new draft of the API with these changes and some other
minor adjustments I did yesterday night (mostly name simplifications
and re-arranging of some functions).

Thanks a lot!

Juan

2010/1/31 Heinz Hölzer <[hidden email]>:
Am 31.01.2010 05:19, schrieb Yanis Benson:

On 01/31/2010 07:06 AM, Heinz Hölzer wrote:

i would prefer:

copy (source:String, destination:String, ?exclude : String -> Bool, ?include
: String -> Bool, ?recursive : Bool = false):Void

cheers
heinz

WHat is exclude needed for then? One function can make it all.



that's true ;)

so it's

copy (source:String, destination:String, ?filter : String -> Bool,
?recursive : Bool = false):Void

--
haXe - an open source web programming language
http://haxe.org




--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv
<xapi.txt>--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Juan Delgado
"never quite as easy to use as a dumb API, you do pay a small price
for the increase in flexibility"

Well, that's the decision we need to make. Having said that, the
initial idea was creating a API with "simple" in the name... : ) Don't
get me wrong, I think it's a great idea, but I'm not sure is within
the scope initially thought for the project.

Having said that, isn't that the purpose of the neko.io.* package?
Specifically the base input / output classes:

http://haxe.org/api/haxe/io/input
http://haxe.org/api/haxe/io/output

Anyone else with views on this?

J

On Sun, Jan 31, 2010 at 5:48 PM, John A. De Goes <[hidden email]> wrote:

>
> This API is better organized and easier to understand than the haxe std lib,
> but you can do even better.
> Designers generally make two errors when creating file system APIs:
>
> 1. A string or other single abstraction is used to represent everything in
> the file system, thus losing the benefits of strong typing.
>
> 2. The file system operations are hard coded to native file system
> operations, meaning if you later want your code to work with FTP, HTTP or
> another file system, you have to completely change all of your code. Also,
> it's not easy to write unit tests for some code, because it requires
> interacting with the real file system.
>
> Fortunately, both errors can be solved in straightforward fashion:
>
> 1. "FSNode" should be the base class representing a node in the file system,
> from which File, Folder, FileLink, FolderLink derive (FileLink derives from
> File, FolderLink derives from Folder). The internal representation should be
> URI-based (e.g.: file://foo.txt). The scheme of the URI ("file" in this
> case) should be used internally by any methods that interact with the file
> system, such as File.instream (which might return an InputStream). In
> particular, a method node.x(...) is just shorthand for:
> SchemeHandler.forScheme(scheme).x(node, ...). For example, File.instream is
> shorthand for SchemeHandler.forScheme(myFile.scheme).instream(myFile).
>
> 2. SchemeHandler should be defined as an abstract class with all file
> system-related methods (reading files, writing files, moving files,
> retrieving permissions, setting permissions, etc.). It should also have
> several static methods: SchemeHandler.forScheme, which retrieves the
> particular scheme handler for the specified scheme; SchemeHandler.install,
> which installs a new scheme handler; SchemeHandler.listAll, which lists
> installed scheme handlers; and SchemeHandler.resolve, which resolves a
> string to an FSNode, based on the currently installed scheme handlers (the
> act of resolving requires determining whether something is a file, folder,
> file link, or folder link, so it depends on whether or not a scheme handler
> has been installed that can provide such information).
>
> 3. SchemeHandler should come pre-initialized with a SchemeHandlerFile, which
> extends SchemeHandler for the "file" scheme. Over time other implementations
> can be written: test (for writing unit tests), FTP, HTTP, SFTP, S3, etc.
>
> This will provide a strongly-typed file system API, which will eliminate
> many errors at compile time, while also being extensible to handle any
> number of schemes. And if you code the API correctly, it can also be easy to
> use (though never quite as easy to use as a dumb API, you do pay a small
> price for the increase in flexibility).
> Regards,
> John
> On Jan 31, 2010, at 2:16 AM, Juan Delgado wrote:
>
> Hi there,
>
> I like ?filter String -> Bool and leaving up to people implementing it
> with a RegExp or whatever. Nice one.
>
> 2 things though:
>
> 1) Make it default to anything? As I say, maybe exclude hidden files
> and folders by default. But I'm happy either way.
>
> 2) I still prefer using ?deep : Int = 0 for defining the levels of
> recursion. I know this is a little bit less intuitive but much more
> flexible in the long run. I got this idea from bash's command find
> which you can tune with -maxdepth and -mindepth.
>
> Find attached a new draft of the API with these changes and some other
> minor adjustments I did yesterday night (mostly name simplifications
> and re-arranging of some functions).
>
> Thanks a lot!
>
> Juan
>
> 2010/1/31 Heinz Hölzer <[hidden email]>:
>
> Am 31.01.2010 05:19, schrieb Yanis Benson:
>
> On 01/31/2010 07:06 AM, Heinz Hölzer wrote:
>
> i would prefer:
>
> copy (source:String, destination:String, ?exclude : String -> Bool, ?include
>
> : String -> Bool, ?recursive : Bool = false):Void
>
> cheers
>
> heinz
>
> WHat is exclude needed for then? One function can make it all.
>
>
>
> that's true ;)
>
> so it's
>
> copy (source:String, destination:String, ?filter : String -> Bool,
>
> ?recursive : Bool = false):Void
>
> --
>
> haXe - an open source web programming language
>
> http://haxe.org
>
>
>
>
> --
> Juan Delgado - Zárate
> http://zarate.tv
> http://blog.zarate.tv
> <xapi.txt>--
> haXe - an open source web programming language
> http://haxe.org
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Yanis Benson
In reply to this post by Juan Delgado
On 01/31/2010 12:16 PM, Juan Delgado wrote:
> Hi there...
>    
> 1) Make it default to anything? As I say, maybe exclude hidden files
> and folders by default. But I'm happy either way.
>    
I think default excludes can make a problem, cause it's not intuitive.
(And it's not crossplatform in the case of hidden files exclusion, since
Windows uses different hiding mechanism.)
The best approach will be to make few frequently used exclude functions
and put them in a private class.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Yanis Benson
In reply to this post by Juan Delgado
On 01/31/2010 12:16 PM, Juan Delgado wrote:
> Hi there...
>    

> 1) Make it default to anything? As I say, maybe exclude hidden files
> and folders by default. But I'm happy either way.
>    
or maybe:
enum Filter{
     ereg(er:EReg),
     func(f:String->Bool),
     hidden,
     notHidden,
     ...
     }

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Juan Delgado
Hi again,

Find attached the latest version of the proposed API. Finally:

- both search and copy are fully recursive by default, You guys were
right, that's what people are going to expect.
- search gets a filter function that works pretty much like in copy. I
thought that why restrict to a regular expression when the filter
would provide much more flexibility.

The whole thing is implemented now (bulk of the work was done for
HippoHX) so I'll try to add some documentation and push it both to
github and haxleib.

As for what to do next, we can take a look to more advanced stuff like
John's proposal (although to me that looks like a project on itself)
and I also would like to add things like:

Folder.copyAsync(source, destination, filter, deep, callback)

So your app doesn't freeze if you need to move big folders.

I'll let you know.

If anyone has a last minute request, go for it!

J

On Sun, Jan 31, 2010 at 8:54 PM, Yanis Benson <[hidden email]> wrote:

> On 01/31/2010 12:16 PM, Juan Delgado wrote:
>>
>> Hi there...
>>
>
>> 1) Make it default to anything? As I say, maybe exclude hidden files
>> and folders by default. But I'm happy either way.
>>
>
> or maybe:
> enum Filter{
>    ereg(er:EReg),
>    func(f:String->Bool),
>    hidden,
>    notHidden,
>    ...
>    }
>
> --
> haXe - an open source web programming language
> http://haxe.org
>


--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv

--
haXe - an open source web programming language
http://haxe.org

xapi.txt (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Heinz Hölzer-2
sounds great,

is the filter function executed on folders and files?

i'm currently missing in the std-lib a function to run a command and
access the output and the return code of the command.

i'm currently using this hack to get the command-output:

public static function runCommandWithOutput( cmd : String, ?args :
Array<String> ) : String {
         var tmpFile = "____tmp_____" + Date.now().toString().split("
").join("").split(":").join("_"); // just a temp name

         args.push(">" + tmpFile);
         Sys.command(cmd, args);
         var content = File.getContent(tmpFile);
         FileSystem.deleteFile(tmpFile);
         return content;
     }

does anyone know if there is a better way without creating a temp-file?

heinz


Am 02.02.2010 16:01, schrieb Juan Delgado:

> Hi again,
>
> Find attached the latest version of the proposed API. Finally:
>
> - both search and copy are fully recursive by default, You guys were
> right, that's what people are going to expect.
> - search gets a filter function that works pretty much like in copy. I
> thought that why restrict to a regular expression when the filter
> would provide much more flexibility.
>
> The whole thing is implemented now (bulk of the work was done for
> HippoHX) so I'll try to add some documentation and push it both to
> github and haxleib.
>
> As for what to do next, we can take a look to more advanced stuff like
> John's proposal (although to me that looks like a project on itself)
> and I also would like to add things like:
>
> Folder.copyAsync(source, destination, filter, deep, callback)
>
> So your app doesn't freeze if you need to move big folders.
>
> I'll let you know.
>
> If anyone has a last minute request, go for it!
>
> J
>
> On Sun, Jan 31, 2010 at 8:54 PM, Yanis Benson<[hidden email]>  wrote:
>    
>> On 01/31/2010 12:16 PM, Juan Delgado wrote:
>>      
>>> Hi there...
>>>
>>>        
>>      
>>> 1) Make it default to anything? As I say, maybe exclude hidden files
>>> and folders by default. But I'm happy either way.
>>>
>>>        
>> or maybe:
>> enum Filter{
>>     ereg(er:EReg),
>>     func(f:String->Bool),
>>     hidden,
>>     notHidden,
>>     ...
>>     }
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>>      
>
>
>    


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Juan Delgado
Hi!

2010/2/2 Heinz Hölzer <[hidden email]>:
> sounds great,
>
> is the filter function executed on folders and files?

Yes. The filter function receives a call per item (either file or
folder) and has to return a boolean to approve (true) or deny (false).
Both search and copy default to a filter that returns true (everything
copied, everything returned in the search).

BTW, just committed the raw source code (no docs, test or samples yet)
to github:

http://github.com/zarate/xapi

>
> i'm currently missing in the std-lib a function to run a command and access
> the output and the return code of the command.
>
> i'm currently using this hack to get the command-output:
>
> public static function runCommandWithOutput( cmd : String, ?args :
> Array<String> ) : String {
>        var tmpFile = "____tmp_____" + Date.now().toString().split("
> ").join("").split(":").join("_"); // just a temp name
>
>        args.push(">" + tmpFile);
>        Sys.command(cmd, args);
>        var content = File.getContent(tmpFile);
>        FileSystem.deleteFile(tmpFile);
>        return content;
>    }
>
> does anyone know if there is a better way without creating a temp-file?
>

Yep, you can do this with Process:

var p = new Process(command, args);
               
var output = p.stdout.readAll().toString();
var error = p.stderr.readAll().toString();

Cheers!

J

> heinz
>
>
> Am 02.02.2010 16:01, schrieb Juan Delgado:
>>
>> Hi again,
>>
>> Find attached the latest version of the proposed API. Finally:
>>
>> - both search and copy are fully recursive by default, You guys were
>> right, that's what people are going to expect.
>> - search gets a filter function that works pretty much like in copy. I
>> thought that why restrict to a regular expression when the filter
>> would provide much more flexibility.
>>
>> The whole thing is implemented now (bulk of the work was done for
>> HippoHX) so I'll try to add some documentation and push it both to
>> github and haxleib.
>>
>> As for what to do next, we can take a look to more advanced stuff like
>> John's proposal (although to me that looks like a project on itself)
>> and I also would like to add things like:
>>
>> Folder.copyAsync(source, destination, filter, deep, callback)
>>
>> So your app doesn't freeze if you need to move big folders.
>>
>> I'll let you know.
>>
>> If anyone has a last minute request, go for it!
>>
>> J
>>
>> On Sun, Jan 31, 2010 at 8:54 PM, Yanis Benson<[hidden email]>
>>  wrote:
>>
>>>
>>> On 01/31/2010 12:16 PM, Juan Delgado wrote:
>>>
>>>>
>>>> Hi there...
>>>>
>>>>
>>>
>>>
>>>>
>>>> 1) Make it default to anything? As I say, maybe exclude hidden files
>>>> and folders by default. But I'm happy either way.
>>>>
>>>>
>>>
>>> or maybe:
>>> enum Filter{
>>>    ereg(er:EReg),
>>>    func(f:String->Bool),
>>>    hidden,
>>>    notHidden,
>>>    ...
>>>    }
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>>
>>
>>
>>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: XAPI (Ximple API)

Heinz Hölzer-2
Am 02.02.2010 16:53, schrieb Juan Delgado:
Yep, you can do this with Process:

var p = new Process(command, args);
		
var output = p.stdout.readAll().toString();
var error = p.stderr.readAll().toString();
  

good to know, thx!



--
haXe - an open source web programming language
http://haxe.org