haxed

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

haxed

MarcWeber
Hi John,

I've spent several hours reading haxed code now.

There is no documentation. Richie told me he is no longer that
interested in the project.

Somehow I feel that some parts of it are over engineered.

And some behaviour is strange. Some namings are even more strange.
Eg the behaviour of param depends on passing a validation function.
One time it reads an argument from command line args, the other time it
reads from input.

haxed installs itself into the library directory. Then it reads a list
of "servers" from that file. However those installed files are usually
never touched, are they?

I'd put this configuration into the ~/.haxelib file.

I feel that I have to find someone to talk to about it.

How much are you interested in haxelib or a replacement?

Marc Weber

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

Re: haxed

blackdog-2

> I feel that I have to find someone to talk to about it.

Guess how much of my time the over-engineering comment bought you? ;)

>Richie told me he is no longer that interested in the project.

The concept has a lot of merit, I'm not interested in maintaining
backward compatibility with php or neko and am actively investigating
other avenues.

bd




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

Re: haxed

John A. De Goes
In reply to this post by MarcWeber

I'm extremely interested in a replacement for haxelib, to include in the official Stax distribution.

In my view, the following are all related:

build, package, deployment, dependency management

All these should be handled by a single tool, which should be modeled after Cabal, the Haskell build and package management tool (Cabal demonstrates the power of  a small, well-defined, declarative package specification).

Haxed achieves most of these, but like you say, it's a work in progress. It was ported from haxelib and the original vision for it has not been fully realized.

I'm convinced that projects should be tied to specific revisions in a version control repository. So when a project is published (e.g. made available on a website like haxelib), only meta-deta is transferred, which describes what the project is, who created it, what dependencies it has, how it is built, and which repository and revision the released version is stored in. The tool will then use installed command-line clients to fetch the appropriate repository revision and all its dependencies.

This scheme allows trivial "deployment", simply by changing the repository revision in the package specification, allows you to use your own private repositories, and reflects actual practice in the HaXe community (most of the best libraries are available via public version control repository, and are not regularly updated on haxelib -- IF they are on haxelib at all).

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Sep 15, 2010, at 7:14 AM, Marc Weber wrote:

Hi John,

I've spent several hours reading haxed code now.

There is no documentation. Richie told me he is no longer that
interested in the project.

Somehow I feel that some parts of it are over engineered.

And some behaviour is strange. Some namings are even more strange.
Eg the behaviour of param depends on passing a validation function.
One time it reads an argument from command line args, the other time it
reads from input.

haxed installs itself into the library directory. Then it reads a list
of "servers" from that file. However those installed files are usually
never touched, are they?

I'd put this configuration into the ~/.haxelib file.

I feel that I have to find someone to talk to about it.

How much are you interested in haxelib or a replacement?

Marc Weber


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

Re: haxed

MarcWeber
In reply to this post by blackdog-2
Excerpts from blackdog's message of Wed Sep 15 15:53:09 +0200 2010:
> > I feel that I have to find someone to talk to about it.
> Guess how much of my time the over-engineering comment bought you? ;)

I mean: Why are you installing haxed automatically in order to get the
server connection from the haxed.haxed file?

Shouldn't haxed be powerful enough to get haxed from git or the server
which is not yet running?

So why do you do this effort of adding many resource files ?

What is the --- in the haxed.haxed file used for? Is it only a separator
to make it look better?

Why is there a global /etc config file setup as fallback? Which is the
use case? Users could easily make their .haxelib file point to a global
place (?)

Why do you have 3 locations describing the simple setup command
(which in fact should be run automatically as needed. Eg the first time
you run any haxed action) and get out of the way? (I know haxelib does
it the same way - I don't like it either)

Following your README:

cd haxed-server
haxed pack haxed-server
haxed test haxed-server

The last line fails. Probably you meant:
haxed test .haxed/haxed-server.zip

cause the .zip file is created by pack.

After running that command I do have a haxed-server/www directory.
But I don't have repo.php which seems to be used by the server.

It should have been created by the haxed-server.haxed file (target
build?)

Trying to compile it copy pasting the pieces into a .hxml files yeilds:

./haxed/server/ServerMain.hx|32 col 38| : bdog.#Os has no field fileIn

Yes, I know you have a github repo..  I could start digging for that
function now.

At this point I just don't know whether I should try to continue making
haxed work for me - or whether I should stop. Why? Because the README
doesn't even tell me about all the implemented features. It does not
tell me about how haxed differs from haxelib etc.

Why implement a complicated parser if a 15 line function maybe could get
the job done as well?

Then time is left to add some valuable comments..

Maybe there are reasons - I just don't see them yet.

> >Richie told me he is no longer that interested in the project.
> The concept has a lot of merit, I'm not interested in maintaining
> backward compatibility with php or neko
HaXe does neither depend on PHP nor odes it depend on Neko ..

Probably I'm kind of frustrated. I should give up and write my own
library.

Marc Weber

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

Re: haxed

MarcWeber
In reply to this post by John A. De Goes
Excerpts from John A. De Goes's message of Wed Sep 15 17:12:15 +0200 2010:

>
> I'm extremely interested in a replacement for haxelib, to include in the official Stax distribution.
>
> In my view, the following are all related:
>
> build, package, deployment, dependency management
>
> All these should be handled by a single tool, which should be modeled after Cabal, the Haskell build and package management tool (
>
> Haxed achieves most of these, but like you say, it's a work in progress. It was ported from haxelib and the original vision for it

So the metadata could look like this:

  author: Marc Weber
  name-version: my-lib 1.0
  description: toy library (demo only)
  depends: xpath, parser > 1.0, json = 2.0
  license: GPL

  source: http://foo/file.tar.gz
  or
  source: git url  hash
  or
  source: svn path rev


That should be enough, should'nt it?

Now what does it give us?
installing the library could pull parser and json automatically (given
that they don't provide binaries we need which is the common case)

A parser looks like this:

// parse lines which represent key value pairs such as:
// key:value
// key2:value2
parseLines(s:String){
  var map = new Map();
  for (l in s.split("\n")){
    var kv = l.split(":");
    map.add(kv[0],kv[1]);
  }
  return map;
}

If I had to extend this that it supports nesting keys I bet I can do so
by adding less than 7 lines.

Do we need the flags cabal has?
Maybe it is fun to add -D flags or such ? Or use php on linux and neko
on Windows only?

But this all is getting complicated - as setting -D flag will affect all
dependencies.

Yes, cabal does a lot more, it abstracts over 3 different compilers at
least ...

But at this point I don't have the power to write what dcoutts did over
several years (that's the time slice we talk about looking at the
evolution of cabal)

If you start about how and when to update binaries - so that no errors
can occur - you can write a full blown storage system with dependency
analysis.

Warnings like dependency X depends on foo-7.0 while dependency Y depends
on foo-8.0 is what I'm interested in at maximum right now.

Marc Weber

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

Re: haxed

John A. De Goes

The parser should be a full YAML-compliant parser, to avoid introducing yet another proprietary format into the world. Stax needs a YAML parser, anyway, and some weeks ago someone said they were in the middle of porting one from ActionScript (http://code.google.com/p/as3yaml/). If they succeed, parsing the config file could be a 1 liner.

But yes, aside from that, such a tool could start out quite simply, by only pulling data recursively from repositories and generating a hxml file for the HaXe compiler.

By the way, your example parseLines function can be written more simply and without mutation using Stax. :-)

var keyValues = s.split('\n').foldl(Map.create(), function(map, line) {
  var keyValue = line.split(':');
  
  return map.set(keyValue[0].trim(), keyValue[1].trim());
});

But you probably know that. :-)

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Sep 15, 2010, at 9:36 AM, Marc Weber wrote:

Excerpts from John A. De Goes's message of Wed Sep 15 17:12:15 +0200 2010:

I'm extremely interested in a replacement for haxelib, to include in the official Stax distribution.

In my view, the following are all related:

build, package, deployment, dependency management

All these should be handled by a single tool, which should be modeled after Cabal, the Haskell build and package management tool (

Haxed achieves most of these, but like you say, it's a work in progress. It was ported from haxelib and the original vision for it

So the metadata could look like this:

 author: Marc Weber
 name-version: my-lib 1.0
 description: toy library (demo only)
 depends: xpath, parser > 1.0, json = 2.0
 license: GPL

 source: http://foo/file.tar.gz
 or
 source: git url  hash
 or
 source: svn path rev


That should be enough, should'nt it?

Now what does it give us?
installing the library could pull parser and json automatically (given
that they don't provide binaries we need which is the common case)

A parser looks like this:

// parse lines which represent key value pairs such as:
// key:value
// key2:value2
parseLines(s:String){
 var map = new Map();
 for (l in s.split("\n")){
   var kv = l.split(":");
   map.add(kv[0],kv[1]);
 }
 return map;
}

If I had to extend this that it supports nesting keys I bet I can do so
by adding less than 7 lines.

Do we need the flags cabal has?
Maybe it is fun to add -D flags or such ? Or use php on linux and neko
on Windows only?

But this all is getting complicated - as setting -D flag will affect all
dependencies.

Yes, cabal does a lot more, it abstracts over 3 different compilers at
least ...

But at this point I don't have the power to write what dcoutts did over
several years (that's the time slice we talk about looking at the
evolution of cabal)

If you start about how and when to update binaries - so that no errors
can occur - you can write a full blown storage system with dependency
analysis.

Warnings like dependency X depends on foo-7.0 while dependency Y depends
on foo-8.0 is what I'm interested in at maximum right now.

Marc Weber


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