How to destroy an open source project community

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

How to destroy an open source project community

Justin Donaldson
I thought this post was interesting:
http://lwn.net/Articles/370157/

It talks about Josh Berkus's (PostgreSQL) experiences on different situations that "killed an open source community"

The haXe community I think is still in a "golden age", there's some very cool projects out there in the community, and the people behind them are very accessible and active.  However, it's helpful to think about how it might be improved.  Here's a list of some situations that Josh Berkus says will lead to a disfunctional community.  I've taken the liberty of giving an American grade (on the A+ to F- scale) for the haXe community.  Of course, I'm grading on a "postive" scale rather than the negative scale that Josh uses. I don't want anyone to take offense at this, It's just meant as my opinion of how haXe ranks against  list.

#1 is to make the project depend as much as possible on difficult tools.

A+   HaXe is the epitome of "batteries included".  It's one of the few projects that I build once a month or so from cvs, just to keep up with the recently added features.  I've never had to worry about compatibility issues or library obsolescence.  Compiling OCaml is the only tricky part, and that's only if you want to compile from cvs.


2: Encourage the presence of poisonous people and maximize the damage that they can create.

A+ People can come in and say whatever they want.  There's a few complete newbies that have tried haXe and posted to the mailing list or forum, but the majority of people here seem to be fairly-to-very experienced.  So, perhaps people here know better than to engage in arguments that go nowhere.  I know I've learned more about programming and how VM's work here than on any other mailing list.  There's a few people that criticize haXe's features or standards, but mainly they come out of an ignorance of the run-time limitations of some of the platforms

3: Provide no documentation. There should be no useful information about the code, build methods, the patch submission process, the release process, or anything else. Then, when people ask for help, tell them to RTFM.

C There's documentation, but it still has a ways to go.  There's very little information about any of the points Josh talks about above, but then again, it's still mainly one person running the whole show.  Most of the doc issues people have with haXe comes from the API documentation.  I try to write articles, blog posts, and wiki pages, but I figure even I'm not doing enough. I still think this is the one crucial area that HaXe needs to improve.

4: Project decisions should be made in closed-door meetings.

A We have open meetings, the proceedings are saved and published,  and Nicolas regularly responds to informed suggestions.  Adding additional features can be a complex process, as each change must propagate seamlessly to the targets.  Surprisingly, new features are regularly added... they're just not always the ones "you" want. :)

5: Employ large amounts of legalese.

A HaXe has very straightforward licensing for the compiler, perhaps to a fault.  There is still some confusion about licensing and copyright arrangements that occur surrounding the libraries and the targets.  This is a recent topic that is being addressed.

6: The community liaison must be chosen carefully. The optimal choice is somebody reclusive - somebody who has no friends and really doesn't like people at all.

B+ This is one of Nicolas's many hats.  I think he does a great job considering the fact that he is communicating across cultures, languages (computer and written), and developer communities.  The only drawback is that I don't think the level of discussion matches the level of innovation that is going on in the language and compiler.

7: Governance obfuscation. Community-averse corporations, Josh says, should learn from the United Nations and create lengthy, complicated processes.

A+  It's hard to have a simpler model than "Benevolent Dicator"

  8: Screw around with licensing.


B- See the above statements about legalese.  I think licensing issues are a fairly common problem with any sort of system that involves third party code, and closed source targets.
 

9: Do not allow anybody outside the company to have commit access, ever.

A There are only a few people who have commit access to the main compiler, but they probably make up the majority of the community output (if not the active community itself). 
 

10: Silence. Don't answer queries, don't say anything.

B+ Nicolas will get around to most of the relevant questions, he just does them all at once, on given days.  Once you get used to it, you know to expect updates/replies in a week or two.

That's about it.  I thought haXe seems to be avoiding most of the major pitfalls.  Feel free to criticize, I'm sure I'm far from having the "complete" picture of things.

Best,
-Justin


--
Justin Donaldson
PhD Candidate, Informatics
Indiana University
http://www.scwn.net
aim: iujjd
twitter: jjdonald

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

Re: How to destroy an open source project community

Shelby Moore
> *#1* is to make the project depend as much as possible on difficult tools.
>>
> *A+*   HaXe is the epitome of "batteries included".  It's one of the few
> projects that I build once a month or so from cvs, just to keep up with
> the
> recently added features.  I've never had to worry about compatibility
> issues
> or library obsolescence.  Compiling OCaml is the only tricky part, and
> that's only if you want to compile from cvs.

B-

If HaXe compiled from HaXe it would mean the community could contribute
and gain more experience in HaXe, without having to install, build, and
learn OCaml.  Several targets (gen*.ml) have already been written in OCaml
so there is growing inertia against bootstrapping HaXe.


>> *2:* Encourage the presence of poisonous people and maximize the damage
>> that they can create.

Given my libertarian philosophy derives from Coase Theorem (Wikipedia it,
my summary is: there is no external reference point, any such barrier will
fail), I think the rule should be changed to, "Discourage or encourage the
presence of poisonous people and maximize the damage that they can
create".

The point is that the release valve is always, "you can fork it", whether
you like it or not, there is no barrier and that option always exists
(even if you try to prevent it with a license as Sun tried to do to Java
and Google just went around it).

For example if the noise in the mailing list is getting too high to get
useful work done, everybody has their own spam filters.  If necessary,
create a tool that enables each reader to have their own personal filter
on the archives.

There is always a better algorithm solution that respects Coase's Theorem,
than the one of creating centralized barriers.  Centralized barriers can
kill a project (or significantly detract from its potential).  Diverse
barriers (i.e. individual filters) are not a barrier, but a form of
maximizing opportunity cost and entropy (diversity and opportunity).


> *A+* People can come in and say whatever they want.

C

There is no bugzilla?

Nicolas did warn (in friendly tone) he might ban me from the mailing list
last year (I think misunderstanding, but not sure).  I was reading the
post in the archives this week, and can dig it up if you don't believe me.
 I have had no problems so far this year.

>  There's a few
> complete
> newbies that have tried haXe and posted to the mailing list or forum, but

The more of them the better.  If too overwhelming, then might want to have
a mailing list for them. Without newbies, your product isn't growing
marketshare.

> the majority of people here seem to be fairly-to-very experienced.  So,
> perhaps people here know better than to engage in arguments that go
> nowhere.

Seems people here differentiate between opinion and logic.

>  I know I've learned more about programming and how VM's work
> here
> than on any other mailing list.

HaXe/Neko naturally draw those interests.  The mailing list here seems
much more knowledgeable/responsive than at Parrot or Squirrel.

>  There's a few people that criticize
> haXe's
> features or standards,

More the better.  (Is there any perfect product?)

> but mainly they come out of an ignorance of the
> run-time limitations of some of the platforms

For that to be canonical, there needs to be some official documentation to
point to on each of those allegations.   The better the documentation,
then the better everything will be.


>> *3:* Provide no documentation. There should be no useful information
>> about
>> the code, build methods, the patch submission process, the release
>> process,
>> or anything else. Then, when people ask for help, tell them to RTFM.
>>
> *C* There's documentation, but it still has a ways to go.  There's very
> little information about any of the points Josh talks about above, but
> then
> again, it's still mainly one person running the whole show.  Most of the
> doc
> issues people have with haXe comes from the *API* documentation.  I try to
> write articles, blog posts, and wiki pages, but I figure even I'm not
> doing
> enough. I still think this is the one crucial area that HaXe needs to
> improve.

D

It is almost impractical to search for some terms, as it returns a list of
just about every page in the API.  There is no index of terms (like in
WinHelp *.chm file, see PHP example)!

I jump all around the various pages of language reference (slow as
molasses on my 512 kpbs connection in Asia), and it would be better if
this was provided in a collapseable tree.  The collapseable tree of the
API doesn't respect browser Back button, and it is slow.  I want a
collapseable thing that is all client side DHTML with AJAX loading and
caching.

Also the documentation is ambigiuous in so many cases for example
'untyped' and the statement about Dynamic and unlimited fields, etc..  The
C FFI doesn't explain how to do a callback from C to HaXe, etc..

Is there is no way for us to contribute to the docs?


>> *4:* Project decisions should be made in closed-door meetings.
>>
> *A* We have open meetings, the proceedings are saved and published,  and
> Nicolas regularly responds to informed suggestions.  Adding additional
> features can be a complex process, as each change must propagate
> seamlessly
> to the targets.  Surprisingly, new features are regularly added... they're
> just not always the ones "you" want. :)


No opinion.  I did read the summary of the recent meeting.


>> *5:* Employ large amounts of legalese.

No opinion I want to share yet.


> *6:* The community liaison must be chosen carefully. The optimal choice is
>> somebody reclusive - somebody who has no friends and really doesn't like
>> people at all.
>>
>> **
>>
> *B+* This is one of Nicolas's many hats.  I think he does a great job
> considering the fact that he is communicating across cultures, languages
> (computer and written), and developer communities.  The only drawback is
> that I don't think the level of discussion matches the level of innovation
> that is going on in the language and compiler.

C

I suppose Nicolas is doing more than he should.  The product should be
able to speak for itself (it does, but not in every facet/fractal yet),
which is why I will agree that getting more people involved in the
documentation is critical.



>> *7:* Governance obfuscation. Community-averse corporations, Josh says,
>> should learn from the United Nations and create lengthy, complicated
>> processes.
>>
> *A+*  It's hard to have a simpler model than "Benevolent Dicator"

C

Everything going through one person is not the best model.  The one person
should build the foundation/trunk mechanisms so that most of the flow
never touches him/her directly.  I think Linus mostly just looks at code
with his time, not the rest of the community stuff and docs?


>   *8:* Screw around with licensing.

No opinion I want to share yet.

>> *9:* Do not allow anybody outside the company to have commit access,
>> ever.


No opinion I want to share yet.


>> *10:* Silence. Don't answer queries, don't say anything.
>>
> *B+* Nicolas will get around to most of the relevant questions, he just
> does
> them all at once, on given days.  Once you get used to it, you know to
> expect updates/replies in a week or two.

C

I don't think everything should hinge on one person.


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

Re: How to destroy an open source project community

Owen Durni-3
> Is there no way for us to contribute to the docs?

haxe.org is essentially a big wiki, so you can absolutely contribute
to the docs.

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

Re: How to destroy an open source project community

Shelby Moore
>> Is there no way for us to contribute to the docs?
>
> haxe.org is essentially a big wiki, so you can absolutely contribute
> to the docs.

Indeed, thanks.

Also I found the HaXe bug reporting database, and I filed a bug.  Also in
that bug report, I noted my first change to the haxe.org documentation
(Wiki) which shows the genre of little nuances that can lead to
misunderstanding for the novice:

http://code.google.com/p/haxe/issues/detail?id=54

Probably the experienced person (e.g. a language designer or someone who
has used iterator loops) realizes that an iterator can't be reset by
modify the copy of its output.  But the novice doesn't likely see the for(
i in 0...10 ) loop in that level of abstraction.  Instead they see it as
for( var i = 0; i < 10; ++i ).  Even the important note at bottom of the
Iterators page will not be understood by the novice to mean that loop
count can't be modified by setting i.  By giving that one hint I added,
they will realize there is a big abstractional difference between for( i
in ) and for( ; i ).  Perhaps it would help if for( in ) was renamed
foreach( in ) instead (or allow both names, but emphasize each).  Then the
confusion might not develop in first place.

I think it is desirable that HaXe is not allowing the loop variable to be
accessible outside the loop, because it can lead to silly mistakes like
the one I made today:

https://bugzilla.mozilla.org/show_bug.cgi?id=544204

If one needs a copy of the variable outside their for loop, they can save
a copy inside the loop, or use while loop.

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

Re: How to destroy an open source project community

Benjamin Dasnois
Not regarding your bug report but only your point about the doc and iterators.

People *should* get a basic understanding of the Iterators concept.
The page you link to is from the language references, which is not
supposed to be a tutorial for total newbie-developers.

Also, when you say that "the modification of the iteration variable
[is] not saved", you are untrue too... This is an example :

class Person {
   public var name : String;
   public var age : Int;
}

class Main {
   public static function main() {
      for(p in listOfPersons) {
         p.age++; //Modifications to the age are saved
      }
   }
}

With your sentence, you could be confusing the newbies too. In my
opinion (that is after having taught computer science), what was there
before was less confusing to newbies. This is only my opinion.

Now, the real thing is that language ref are definitely not a tutorial
for total beginners and that we should *maybe* get some doc for total
beginners.


Regards,

Benjamin DASNOIS

On Thu, Feb 4, 2010 at 12:03 PM, Shelby Moore <[hidden email]> wrote:

>>> Is there no way for us to contribute to the docs?
>>
>> haxe.org is essentially a big wiki, so you can absolutely contribute
>> to the docs.
>
> Indeed, thanks.
>
> Also I found the HaXe bug reporting database, and I filed a bug.  Also in
> that bug report, I noted my first change to the haxe.org documentation
> (Wiki) which shows the genre of little nuances that can lead to
> misunderstanding for the novice:
>
> http://code.google.com/p/haxe/issues/detail?id=54
>
> Probably the experienced person (e.g. a language designer or someone who
> has used iterator loops) realizes that an iterator can't be reset by
> modify the copy of its output.  But the novice doesn't likely see the for(
> i in 0...10 ) loop in that level of abstraction.  Instead they see it as
> for( var i = 0; i < 10; ++i ).  Even the important note at bottom of the
> Iterators page will not be understood by the novice to mean that loop
> count can't be modified by setting i.  By giving that one hint I added,
> they will realize there is a big abstractional difference between for( i
> in ) and for( ; i ).  Perhaps it would help if for( in ) was renamed
> foreach( in ) instead (or allow both names, but emphasize each).  Then the
> confusion might not develop in first place.
>
> I think it is desirable that HaXe is not allowing the loop variable to be
> accessible outside the loop, because it can lead to silly mistakes like
> the one I made today:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=544204
>
> If one needs a copy of the variable outside their for loop, they can save
> a copy inside the loop, or use while loop.
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
DASNOIS Benjamin
http://www.benjamindasnois.com

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

Re: How to destroy an open source project community

Heinz Hölzer-2
Am 04.02.2010 12:28, schrieb Benjamin Dasnois:
With your sentence, you could be confusing the newbies too. In my
opinion (that is after having taught computer science), what was there
before was less confusing to newbies. This is only my opinion.

  
agreed ;)

 for( i in 0...10 ) {
        i = 0; // does not infinite loop
        // ...
    }

this would totally confuse me as a newbie, and this is not what i would expect 
as a first iterator example.


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

Re: How to destroy an open source project community

Shelby Moore
In reply to this post by Benjamin Dasnois
> Not regarding your bug report but only your point about the doc and
> iterators.
>
> People *should* get a basic understanding of the Iterators concept.

And doing that in one place as concisely as possible is my forte.  There
is a reason that CoolPage was and still is very popular with beginners
(million downloads).

> The page you link to is from the language references, which is not
> supposed to be a tutorial for total newbie-developers.

One of the confusing things about the Haxe.org is stuff spread all over
the place.  For example --haxe-source is documented on the compiler
summary page for all targets, but not on the detailed page for Neko itself
"Getting Started Neko".

In documentation, you want to make sure there can be no misunderstanding
any where.  Someone should have to walk through a maze to get the whole
story.

> Also, when you say that "the modification of the iteration variable
> [is] not saved", you are untrue too... This is an example :

The variable itself is not saved.  I did not write about if you modify the
object to which the variable references.

> class Person {
>    public var name : String;
>    public var age : Int;
> }
>
> class Main {
>    public static function main() {
>       for(p in listOfPersons) {
>          p.age++; //Modifications to the age are saved
>       }
>    }
> }
>
> With your sentence, you could be confusing the newbies too.

I did not add that sentence to the documentation.  Instead I added a case
to the example code to show that modifying i will not change the loop
count.  A very friendly reminder for a beginner and in a concise one line.

> In my
> opinion (that is after having taught computer science), what was there
> before was less confusing to newbies. This is only my opinion.

In my opinion, quick references (to be digested in a few hours) are
nothing like teaching a semester course.

> Now, the real thing is that language ref are definitely not a tutorial
> for total beginners and that we should *maybe* get some doc for total
> beginners.

In my opinion, we primarily just need to first make sure we point out
potential misunderstandings in the reference, especially when they are
terse enough to do.  Note how the documentation reference for Syntax has
numerous examples of 'var', showing all the cases (inference, explicit
type, multiple initiations per 'var' keyword).

Proliferating the maze of literature is I think a step in the wrong
direction.  This is just my opinion, because I favor low complexity and
conciseness (except when I am explaining myself in a mailing list <grin>).

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

Re: How to destroy an open source project community

Shelby Moore
In reply to this post by Heinz Hölzer-2
> Am 04.02.2010 12:28, schrieb Benjamin Dasnois:
>> With your sentence, you could be confusing the newbies too. In my
>> opinion (that is after having taught computer science), what was there
>> before was less confusing to newbies. This is only my opinion.
>>
>>
> agreed ;)
>
>   for(  i in  0...10  )  {
>          i = 0;// does not infinite loop
>          // ...
>      }
>
> this would totally confuse meas a newbie, and this is not what i would
> expect
> as a first iterator example.

The intended goal is to confuse.  It forces the beginner to make sure they
really understand, before moving on.  The person who understands, is not
bothered.  All in 1 line.  Very efficient.

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

Re: How to destroy an open source project community

Shelby Moore
Apologies for triple post, but I forgot to mention that by "novice" I
meant novice to HaXe, not to programming in general.  So I did not mean an
introductory course to computing.  Iterators are fairly advanced concept
for programmers coming from self-taught realm (not formal computer science
degree) and who are "old school".  I mentioned that someone coming from a
language with for( ;; ) will think of for( in ) has just a shorthand, but
we need to jolt them a little bit so they realize setting i will not alter
the # of iterations of the loop.  Maybe you might prefer a sentence to
explain that.  Maybe you might want to change "does not infinite loop" to
"does not change loop count".  Maybe you want to delete my change, then
that is fine too.  I was just getting the ball rolling on the missing
concept not clarified in the reference, from the perspective of people
coming from popular languages such as C, JavaScript, Basic, etc..  Even
though it is mentioned at the bottom of the page that iterator values are
copies, it is a different reason and it might not quite sink in that for(
in ) is not similar to for( ;; ) in terms of being able to alter the loop
count within the loop.  In for( in ), i is a copy of the return of an
iternator.  This is more clear when the iterator is not "...".  For "...",
it is easily misunderstood to be a shorthand for for( var i = 0; i < 10;
++i ), which it is not.


>> Am 04.02.2010 12:28, schrieb Benjamin Dasnois:
>>> With your sentence, you could be confusing the newbies too. In my
>>> opinion (that is after having taught computer science), what was there
>>> before was less confusing to newbies. This is only my opinion.
>>>
>>>
>> agreed ;)
>>
>>   for(  i in  0...10  )  {
>>          i = 0;// does not infinite loop
>>          // ...
>>      }
>>
>> this would totally confuse meas a newbie, and this is not what i would
>> expect
>> as a first iterator example.
>
> The intended goal is to confuse.  It forces the beginner to make sure they
> really understand, before moving on.  The person who understands, is not
> bothered.  All in 1 line.  Very efficient.

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

Re: How to destroy an open source project community

Lee Sylvester
In reply to this post by Shelby Moore
@Shelby :- Your earlier comment about lack of documentation with Neko /
haXe confuses me. There are area's in the www.haxe.org website and the
www.nekovm.org website that explain this. The neko site shows how to
export functions in a Neko value struct and how to execute them:

http://nekovm.org/doc/ffi

while the haXe website details linking to exposed neko functions, passed
value functions and type conversion, here:

http://haxe.org/doc/neko/ffi

Did you read these sources?


On a related point, I also feel the documentation lacks, but the
reference doesn't. The API is perfect if you *know* haXe. Now, while I
(and Franco) put in lots of effort to get the former issue resolved with
the Pro haXe and Neko book, a published book just doesn't evolve quickly
enough (meaning hardly at all) to cover the updates that haXe has on a
regular basis. Again, to combat this, I have been writing lots of
articles for Flash and Flex Developer magazine, but due to the nature of
magazines, it is pretty restrictive. As a result, I have recently
started planning a series of video tutorials to cater for beginners to
intermediate developers, which will hopefully be placed on the haXe
website. This will take time, though, as I only have so many hours at my
disposal :-)  Of course, though, some help here would be appreciated.

Lee






Shelby Moore wrote:

>> Am 04.02.2010 12:28, schrieb Benjamin Dasnois:
>>    
>>> With your sentence, you could be confusing the newbies too. In my
>>> opinion (that is after having taught computer science), what was there
>>> before was less confusing to newbies. This is only my opinion.
>>>
>>>
>>>      
>> agreed ;)
>>
>>   for(  i in  0...10  )  {
>>          i = 0;// does not infinite loop
>>          // ...
>>      }
>>
>> this would totally confuse meas a newbie, and this is not what i would
>> expect
>> as a first iterator example.
>>    
>
> The intended goal is to confuse.  It forces the beginner to make sure they
> really understand, before moving on.  The person who understands, is not
> bothered.  All in 1 line.  Very efficient.
>
>  


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

Re: How to destroy an open source project community

Shelby Moore
> @Shelby :- Your earlier comment about lack of documentation with Neko /
> haXe confuses me. There are area's in the www.haxe.org website and the
> www.nekovm.org website that explain this. The neko site shows how to
> export functions in a Neko value struct and how to execute them:
>
> http://nekovm.org/doc/ffi

That is only for calling a Neko function.  No where does it say it is for
calling a HaXe function.

>
> while the haXe website details linking to exposed neko functions, passed
> value functions and type conversion, here:
>
> http://haxe.org/doc/neko/ffi


That is for HaXe calling a C function, not for C or Neko calling a HaXe
function.

We have 4 binary bits here (C<->Neko<->HaXe), so 16 cases to cover.  My
mind thinks like this.  I have to cross off all 16 cases, esle I am making
ASS-U-ME(ption).

>
> Did you read these sources?

I read both of those pages in detail (several times before I posted to the
mailing list!), but neither page mentions, specifies, or gives an example
of a callback from Neko to HaXe.  None of the examples show the passing of
a HaXe function to Neko.  The C FFI shows passing a Neko function to C.
It would be scientifically wrong for me to make the assumption that the C
FFI callback to Neko, is the way to callback to HaXe, because the
implementation of HaXe functions might be fundamentally different than
Neko functions.  So I tried to verify that the Neko functions and HaXe
functions were compatible in that way, and as I explained I got some
conflicting signals in my investigation:

http://lists.motion-twin.com/pipermail/haxe/2010-February/033337.html

" ...why does
std.Neko.nekoToHaxe() throw an exception and not convert Neko tfunction,
given that std.Neko.Lib.load() does cast and return a tfunction to a
Dynamic?  Seems nekoToHave() should be fixed to convert a tfunction?

http://code.google.com/p/haxe/source/browse/trunk/std/neko/Lib.hx "

I also wrote that at the time, I wasn't aware of --neko-source, because it
is documented on the compiler page for all targets, but not on the
"Getting Started Neko" Neko specific page.

http://haxe.org/doc/start/neko
http://haxe.org/doc/compiler


> On a related point, I also feel the documentation lacks, but the
> reference doesn't.

The reference has numerous ambiguities.  I like to cross off all the
binary bits before I can call it a reference.  A reference must not have
any holes or ambiguity.  For example I have no idea what the semantics for
'untyped' are as specified in the reference.  Ditto some of the sentences
about Dynamic ("unlimited fields" even if it is not pointed to an object
value?).  I thought the type that is held by a dynamic will still be
checked at runtime?  In other words if you try to do . access on an array,
then you will get a runtime exception?  None of this is specified in the
reference.  And so the "unlimited fields" only applies with the runtime
value is actually an object?

See my mind wants to see all the cases.  I don't like holes in the binary
bits of cases.

http://haxe.org/ref/dynamic

"A Dynamic variable has an infinite number of fields, all having the type
Dynamic, which can be used for instance as an Array for bracket syntax."

What does that mean?


"Untyped

One other way to do dynamic things is to use the untyped keyword. When an
expression is untyped, no type-check will be done so you can execute many
dynamic operations at once"

Ok I understand the it treat all variables and identifiers as dynamic.  So
does that mean if you access it like an object, it will assume the object
was a HaXe object or a Neko object?  Array [] access?

How does that get translated to native code?  For example look in the
loader code in the API and see the useage of untyped.  It is doing some
kind of magic with the Neko structures apparently?  Maybe I just need to
look at more examples, in any case the reference seems to be ambigious
enough.


Also I feel the reference is not cross-indexed and you can't see the
sub-heading for each page quickly in one TOC so you can quickly click down
and keep the structure of all the items covered.


> The API is perfect if you *know* haXe. Now, while I
> (and Franco) put in lots of effort to get the former issue resolved with
> the Pro haXe and Neko book, a published book just doesn't evolve quickly
> enough (meaning hardly at all) to cover the updates that haXe has on a
> regular basis. Again, to combat this, I have been writing lots of
> articles for Flash and Flex Developer magazine, but due to the nature of
> magazines, it is pretty restrictive. As a result, I have recently
> started planning a series of video tutorials to cater for beginners to
> intermediate developers, which will hopefully be placed on the haXe
> website. This will take time, though, as I only have so many hours at my
> disposal :-)  Of course, though, some help here would be appreciated.

I am not discouraging you, but I will say I think I would never have time
to read or watch those outlying types of media.  I need something concise
and 100% unambigious.

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

Re: How to destroy an open source project community

Cauê W.
I am not discouraging you, but I will say I think I would never have time
to read or watch those outlying types of media.  I need something concise
and 100% unambigious.


Sorry, but you say you would never have time, but you do haev time to write so many emails talking about this issue? Maybe you should try not battling and resisting the docs and the language, but actually try reading and understanding what it's about. We are here to help, if there's any doubts you have.

cheers
caue

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

Re: How to destroy an open source project community

Lee Sylvester
In reply to this post by Shelby Moore
Shelby Moore wrote:

>> @Shelby :- Your earlier comment about lack of documentation with Neko /
>> haXe confuses me. There are area's in the www.haxe.org website and the
>> www.nekovm.org website that explain this. The neko site shows how to
>> export functions in a Neko value struct and how to execute them:
>>
>> http://nekovm.org/doc/ffi
>>    
>
> That is only for calling a Neko function.  No where does it say it is for
> calling a HaXe function.
>
>  
Without sounding like a pantomime Dame, "Oh, yes it does!" ;-)

<snip>

val_call0(value f) : call the function f with 0 arguments.
val_call1(value f, value arg) : call the function f with 1 argument.
val_call2(value f, value arg1, value arg2) : call the function f with 2
arguments.
val_call3(value f, value arg1, value arg2, value arg3)
val_callN(value f, value *args, int nargs)

</snip>

if I pass in a closure from haXe into a C method, it gets passed as a
value struct. I can pass this struct to a val_call$ method as its first
argument. This page also describes how to check the number of args it
requires etc.

>> while the haXe website details linking to exposed neko functions, passed
>> value functions and type conversion, here:
>>
>> http://haxe.org/doc/neko/ffi
>>    
>
>
> That is for HaXe calling a C function, not for C or Neko calling a HaXe
> function.
>
> We have 4 binary bits here (C<->Neko<->HaXe), so 16 cases to cover.  My
> mind thinks like this.  I have to cross off all 16 cases, esle I am making
> ASS-U-ME(ption).
>  

For the most part, you can consider C and Neko as being the same entity
on the C code tier, while haXe and Neko are the same entity in the haXe
language tier. Other than the Neko API you use for converting data types
in C, you can forget Neko even exists. For example, I can take a C
function and pass it to haXe like this:

value add( value a, value b )
{
    return alloc_int( val_int( a ), val_int( b ) );
}

value get_c_function()
{
    return alloc_function( add, 2, "add" );
}

DEFINE_PRIM( get_c_function, 0 )


Then, in haXe, I can do this:

private static var add = neko.Lib.load("mylib","get_c_function", 0 );

static function main()
{
    trace( add( 1, 2 ) ); // outputs 3
}


So, that's exactly what you wanted, without worrying about Neko, and all
documented in those two pages :-)

>  
>> Did you read these sources?
>>    
>
> I read both of those pages in detail (several times before I posted to the
> mailing list!), but neither page mentions, specifies, or gives an example
> of a callback from Neko to HaXe.  None of the examples show the passing of
> a HaXe function to Neko.  The C FFI shows passing a Neko function to C.
> It would be scientifically wrong for me to make the assumption that the C
> FFI callback to Neko, is the way to callback to HaXe, because the
> implementation of HaXe functions might be fundamentally different than
> Neko functions.  So I tried to verify that the Neko functions and HaXe
> functions were compatible in that way, and as I explained I got some
> conflicting signals in my investigation:
>  
Ahhh, you're saying you want to pass a haXe "language" function to the
Neko layer? ie, take a function written in haXe and pass that to the
Neko executing code? Well, in that case, you're missing the picture of
the relationship between haXe and Neko. haXe, when used with Neko, is
merely the syntactical sugar used when writing, abstractly, the Neko
code. Ergo, there is no haXe->Neko transition once compilation has
occurred. Simply Neko->Neko.

> http://lists.motion-twin.com/pipermail/haxe/2010-February/033337.html
>
> " ...why does
> std.Neko.nekoToHaxe() throw an exception and not convert Neko tfunction,
> given that std.Neko.Lib.load() does cast and return a tfunction to a
> Dynamic?  Seems nekoToHave() should be fixed to convert a tfunction?
>
> http://code.google.com/p/haxe/source/browse/trunk/std/neko/Lib.hx "
>
> I also wrote that at the time, I wasn't aware of --neko-source, because it
> is documented on the compiler page for all targets, but not on the
> "Getting Started Neko" Neko specific page.
>
> http://haxe.org/doc/start/neko
> http://haxe.org/doc/compiler
>  

Yeah, I did read that, but as I never deal with type checks using those
particular constants, I can't help you. I learned early on that checks
are best made in each layer before data transfer, not after. It's easier
to read, easier to manage and makes for smaller code. :-)

>
>  
>> On a related point, I also feel the documentation lacks, but the
>> reference doesn't.
>>    
>
> The reference has numerous ambiguities.  I like to cross off all the
> binary bits before I can call it a reference.  A reference must not have
> any holes or ambiguity.  For example I have no idea what the semantics for
> 'untyped' are as specified in the reference.  Ditto some of the sentences
> about Dynamic ("unlimited fields" even if it is not pointed to an object
> value?).  I thought the type that is held by a dynamic will still be
> checked at runtime?  In other words if you try to do . access on an array,
> then you will get a runtime exception?  None of this is specified in the
> reference.  And so the "unlimited fields" only applies with the runtime
> value is actually an object?
>  
No. An array is an object, so you can add fields to it. You can dot
access the push method, for example, too. Using reflection, you can add
as many fields as you like. Likewise, you can extend Array and do it
that way, too. It's much the same as in AS3.

> See my mind wants to see all the cases.  I don't like holes in the binary
> bits of cases.
>
> http://haxe.org/ref/dynamic
>
> "A Dynamic variable has an infinite number of fields, all having the type
> Dynamic, which can be used for instance as an Array for bracket syntax."
>
> What does that mean?
>
>
> "Untyped
>
> One other way to do dynamic things is to use the untyped keyword. When an
> expression is untyped, no type-check will be done so you can execute many
> dynamic operations at once"
>
> Ok I understand the it treat all variables and identifiers as dynamic.  So
> does that mean if you access it like an object, it will assume the object
> was a HaXe object or a Neko object?  Array [] access?
>  
It won't care. It might at runtime, but the compiler will make no
assumptions.
> How does that get translated to native code?  For example look in the
> loader code in the API and see the useage of untyped.  It is doing some
> kind of magic with the Neko structures apparently?  Maybe I just need to
> look at more examples, in any case the reference seems to be ambigious
> enough.
>  
It's probably best to look at existing sources. These things do start to
make more sense once you see it in action. Sometimes, it can
overcomplicate by trying to explain in words.

>
> Also I feel the reference is not cross-indexed and you can't see the
> sub-heading for each page quickly in one TOC so you can quickly click down
> and keep the structure of all the items covered.
>
>
>  
>> The API is perfect if you *know* haXe. Now, while I
>> (and Franco) put in lots of effort to get the former issue resolved with
>> the Pro haXe and Neko book, a published book just doesn't evolve quickly
>> enough (meaning hardly at all) to cover the updates that haXe has on a
>> regular basis. Again, to combat this, I have been writing lots of
>> articles for Flash and Flex Developer magazine, but due to the nature of
>> magazines, it is pretty restrictive. As a result, I have recently
>> started planning a series of video tutorials to cater for beginners to
>> intermediate developers, which will hopefully be placed on the haXe
>> website. This will take time, though, as I only have so many hours at my
>> disposal :-)  Of course, though, some help here would be appreciated.
>>    
>
> I am not discouraging you, but I will say I think I would never have time
> to read or watch those outlying types of media.  I need something concise
> and 100% unambigious.
>
>  
True, but many people like video's and it's the only way to produce
something that is as up-to-date as possible without working on it
full-time ;-)

Lee




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

Re: How to destroy an open source project community

Benjamin Dasnois
I'm sorry, but you should definitely have another look at the
references Shelby...
Dynamic & Untyped are two well-explained things...

You are basically saying that some sentences about Dynamic do not mean
anything... Sorry, English is not my mother tongue but I did & do
understand them. Why? Because instead of saying "hey this is shitty, I
don't understand", I read again, and have a look at the examples that
are quite self-explanatory.

Also, I've not been doing courses over a semester, I was teaching the
courses in one or two weeks, 4 days a week, 8 hours per day. This is
quite different from doing two hours each two or three days and you
certainly don't know what kind of materials I have had to write...
Else-what, you wouldn't infer that I don't know about concise
documents...

As far as I'm concerned, being disruptive isn't a good thing when it
comes to concise docs. Also, sorry (mhm indeed, no), but Iterators
definitely *aren't* an advanced topic. Iterators are there in Java,
C#, PHP, and even BASH (and more...). Honestly, if you're not aware of
what iterators are as a developer, then, you should google it, or go
back to a training session.

At least, you've raised a question in my mind : is the time to protect
the documentation arrived?

Also please, do *not* compare the audience of Coolpage and haXe. It's
pretty obvious that haXe does target people who know about development
and have some kind of (at least) basic knowledge about computing.

Also, not to sound arrogant, but this page :
http://www.coolpage.com/cpg.html is the perfect example of what not to
do when trying to teach something (particularly the first picture)...

On Thu, Feb 4, 2010 at 3:02 PM, Lee McColl Sylvester
<[hidden email]> wrote:

> Shelby Moore wrote:
>>>
>>> @Shelby :- Your earlier comment about lack of documentation with Neko /
>>> haXe confuses me. There are area's in the www.haxe.org website and the
>>> www.nekovm.org website that explain this. The neko site shows how to
>>> export functions in a Neko value struct and how to execute them:
>>>
>>> http://nekovm.org/doc/ffi
>>>
>>
>> That is only for calling a Neko function.  No where does it say it is for
>> calling a HaXe function.
>>
>>
>
> Without sounding like a pantomime Dame, "Oh, yes it does!" ;-)
> <snip>
>
> val_call0(value f) : call the function f with 0 arguments.
> val_call1(value f, value arg) : call the function f with 1 argument.
> val_call2(value f, value arg1, value arg2) : call the function f with 2
> arguments.
> val_call3(value f, value arg1, value arg2, value arg3)
> val_callN(value f, value *args, int nargs)
>
> </snip>
>
> if I pass in a closure from haXe into a C method, it gets passed as a value
> struct. I can pass this struct to a val_call$ method as its first argument.
> This page also describes how to check the number of args it requires etc.
>>>
>>> while the haXe website details linking to exposed neko functions, passed
>>> value functions and type conversion, here:
>>>
>>> http://haxe.org/doc/neko/ffi
>>>
>>
>>
>> That is for HaXe calling a C function, not for C or Neko calling a HaXe
>> function.
>>
>> We have 4 binary bits here (C<->Neko<->HaXe), so 16 cases to cover.  My
>> mind thinks like this.  I have to cross off all 16 cases, esle I am making
>> ASS-U-ME(ption).
>>
>
> For the most part, you can consider C and Neko as being the same entity on
> the C code tier, while haXe and Neko are the same entity in the haXe
> language tier. Other than the Neko API you use for converting data types in
> C, you can forget Neko even exists. For example, I can take a C function and
> pass it to haXe like this:
>
> value add( value a, value b )
> {
>   return alloc_int( val_int( a ), val_int( b ) );
> }
>
> value get_c_function()
> {
>   return alloc_function( add, 2, "add" );
> }
>
> DEFINE_PRIM( get_c_function, 0 )
>
>
> Then, in haXe, I can do this:
>
> private static var add = neko.Lib.load("mylib","get_c_function", 0 );
>
> static function main()
> {
>   trace( add( 1, 2 ) ); // outputs 3
> }
>
>
> So, that's exactly what you wanted, without worrying about Neko, and all
> documented in those two pages :-)
>
>>
>>>
>>> Did you read these sources?
>>>
>>
>> I read both of those pages in detail (several times before I posted to the
>> mailing list!), but neither page mentions, specifies, or gives an example
>> of a callback from Neko to HaXe.  None of the examples show the passing of
>> a HaXe function to Neko.  The C FFI shows passing a Neko function to C. It
>> would be scientifically wrong for me to make the assumption that the C
>> FFI callback to Neko, is the way to callback to HaXe, because the
>> implementation of HaXe functions might be fundamentally different than
>> Neko functions.  So I tried to verify that the Neko functions and HaXe
>> functions were compatible in that way, and as I explained I got some
>> conflicting signals in my investigation:
>>
>
> Ahhh, you're saying you want to pass a haXe "language" function to the Neko
> layer? ie, take a function written in haXe and pass that to the Neko
> executing code? Well, in that case, you're missing the picture of the
> relationship between haXe and Neko. haXe, when used with Neko, is merely the
> syntactical sugar used when writing, abstractly, the Neko code. Ergo, there
> is no haXe->Neko transition once compilation has occurred. Simply
> Neko->Neko.
>
>> http://lists.motion-twin.com/pipermail/haxe/2010-February/033337.html
>>
>> " ...why does
>> std.Neko.nekoToHaxe() throw an exception and not convert Neko tfunction,
>> given that std.Neko.Lib.load() does cast and return a tfunction to a
>> Dynamic?  Seems nekoToHave() should be fixed to convert a tfunction?
>>
>> http://code.google.com/p/haxe/source/browse/trunk/std/neko/Lib.hx "
>>
>> I also wrote that at the time, I wasn't aware of --neko-source, because it
>> is documented on the compiler page for all targets, but not on the
>> "Getting Started Neko" Neko specific page.
>>
>> http://haxe.org/doc/start/neko
>> http://haxe.org/doc/compiler
>>
>
> Yeah, I did read that, but as I never deal with type checks using those
> particular constants, I can't help you. I learned early on that checks are
> best made in each layer before data transfer, not after. It's easier to
> read, easier to manage and makes for smaller code. :-)
>>
>>
>>>
>>> On a related point, I also feel the documentation lacks, but the
>>> reference doesn't.
>>>
>>
>> The reference has numerous ambiguities.  I like to cross off all the
>> binary bits before I can call it a reference.  A reference must not have
>> any holes or ambiguity.  For example I have no idea what the semantics for
>> 'untyped' are as specified in the reference.  Ditto some of the sentences
>> about Dynamic ("unlimited fields" even if it is not pointed to an object
>> value?).  I thought the type that is held by a dynamic will still be
>> checked at runtime?  In other words if you try to do . access on an array,
>> then you will get a runtime exception?  None of this is specified in the
>> reference.  And so the "unlimited fields" only applies with the runtime
>> value is actually an object?
>>
>
> No. An array is an object, so you can add fields to it. You can dot access
> the push method, for example, too. Using reflection, you can add as many
> fields as you like. Likewise, you can extend Array and do it that way, too.
> It's much the same as in AS3.
>>
>> See my mind wants to see all the cases.  I don't like holes in the binary
>> bits of cases.
>>
>> http://haxe.org/ref/dynamic
>>
>> "A Dynamic variable has an infinite number of fields, all having the type
>> Dynamic, which can be used for instance as an Array for bracket syntax."
>>
>> What does that mean?
>>
>>
>> "Untyped
>>
>> One other way to do dynamic things is to use the untyped keyword. When an
>> expression is untyped, no type-check will be done so you can execute many
>> dynamic operations at once"
>>
>> Ok I understand the it treat all variables and identifiers as dynamic.  So
>> does that mean if you access it like an object, it will assume the object
>> was a HaXe object or a Neko object?  Array [] access?
>>
>
> It won't care. It might at runtime, but the compiler will make no
> assumptions.
>>
>> How does that get translated to native code?  For example look in the
>> loader code in the API and see the useage of untyped.  It is doing some
>> kind of magic with the Neko structures apparently?  Maybe I just need to
>> look at more examples, in any case the reference seems to be ambigious
>> enough.
>>
>
> It's probably best to look at existing sources. These things do start to
> make more sense once you see it in action. Sometimes, it can overcomplicate
> by trying to explain in words.
>>
>> Also I feel the reference is not cross-indexed and you can't see the
>> sub-heading for each page quickly in one TOC so you can quickly click down
>> and keep the structure of all the items covered.
>>
>>
>>
>>>
>>> The API is perfect if you *know* haXe. Now, while I
>>> (and Franco) put in lots of effort to get the former issue resolved with
>>> the Pro haXe and Neko book, a published book just doesn't evolve quickly
>>> enough (meaning hardly at all) to cover the updates that haXe has on a
>>> regular basis. Again, to combat this, I have been writing lots of
>>> articles for Flash and Flex Developer magazine, but due to the nature of
>>> magazines, it is pretty restrictive. As a result, I have recently
>>> started planning a series of video tutorials to cater for beginners to
>>> intermediate developers, which will hopefully be placed on the haXe
>>> website. This will take time, though, as I only have so many hours at my
>>> disposal :-)  Of course, though, some help here would be appreciated.
>>>
>>
>> I am not discouraging you, but I will say I think I would never have time
>> to read or watch those outlying types of media.  I need something concise
>> and 100% unambigious.
>>
>>
>
> True, but many people like video's and it's the only way to produce
> something that is as up-to-date as possible without working on it full-time
> ;-)
>
> Lee
>
>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
DASNOIS Benjamin
http://www.benjamindasnois.com

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

Re: How to destroy an open source project community

Shelby Moore
In reply to this post by Lee Sylvester
> Shelby Moore wrote:
>>> @Shelby :- Your earlier comment about lack of documentation with Neko /
>>> haXe confuses me. There are area's in the www.haxe.org website and the
>>> www.nekovm.org website that explain this. The neko site shows how to
>>> export functions in a Neko value struct and how to execute them:
>>>
>>> http://nekovm.org/doc/ffi
>>>
>>
>> That is only for calling a Neko function.  No where does it say it is
>> for
>> calling a HaXe function.
>>
>>
> Without sounding like a pantomime Dame, "Oh, yes it does!" ;-)
>
> <snip>
>
> val_call0(value f) : call the function f with 0 arguments.
> val_call1(value f, value arg) : call the function f with 1 argument.
> val_call2(value f, value arg1, value arg2) : call the function f with 2
> arguments.
> val_call3(value f, value arg1, value arg2, value arg3)
> val_callN(value f, value *args, int nargs)
>
> </snip>
>
> if I pass in a closure from haXe into a C method, it gets passed as a
> value struct. I can pass this struct to a val_call$ method as its first
> argument. This page also describes how to check the number of args it
> requires etc.

I will repeat my same point again.  I hope you listen this time please.
The above code is explaining how to call a Neko function from a C code.
It is not saying that calling a HaXe function is done in the same way.
Until one learns that Haxe functions and Neko functions are 100%
interoperable, then one can not make that assumption.

In the nekoToHaxe() and haxeToNeko() source code, the indication was they
were not interoperable.  I now understand from you (and from my digging
around in the Lib API sources, which you confirmed) that HaXe and Neko
functions are equivalent.


>>> while the haXe website details linking to exposed neko functions,
>>> passed
>>> value functions and type conversion, here:
>>>
>>> http://haxe.org/doc/neko/ffi
>>>
>>
>>
>> That is for HaXe calling a C function, not for C or Neko calling a HaXe
>> function.
>>
>> We have 4 binary bits here (C<->Neko<->HaXe), so 16 cases to cover.  My
>> mind thinks like this.  I have to cross off all 16 cases, esle I am
>> making
>> ASS-U-ME(ption).
>>
>
> For the most part, you can consider C and Neko as being the same entity
> on the C code tier, while haXe and Neko are the same entity in the haXe
> language tier.


Where does it specify that in the documentation?

Please note this discussion is/was about the fact that documentation does
not make that unambiguous.  Just because that information is in your head,
doesn't impart it to my head, if I am not reading your mind.  I need the
statements to be in the documentation, so I don't have to come to the
mailing list to learn what should already be in the documentation.


> Other than the Neko API you use for converting data types
> in C, you can forget Neko even exists. For example, I can take a C
> function and pass it to haXe like this:

I am not talking about passing a C function to a HaXe function.  I said
the missing documentation is about passing a HaXe function to C.  You are
making the assumption that because the documentation says you can pass a C
function to HaXe, that it implies you can pass a HaXe function to C.  It
is in theory possible that the loader was doing some patching up, that
wouldn't be the case going the other direction.

>
> value add( value a, value b )
> {
>     return alloc_int( val_int( a ), val_int( b ) );
> }
>
> value get_c_function()
> {
>     return alloc_function( add, 2, "add" );
> }
>
> DEFINE_PRIM( get_c_function, 0 )
>
>
> Then, in haXe, I can do this:
>
> private static var add = neko.Lib.load("mylib","get_c_function", 0 );
>
> static function main()
> {
>     trace( add( 1, 2 ) ); // outputs 3
> }
>
>
> So, that's exactly what you wanted, without worrying about Neko, and all
> documented in those two pages :-)


No it is not, and I hope this time I explained my point well?

If you are a mathematician, you will understand that not all operations
have an inverse.  For example, just because you see someone on the
opposite side of a canyon, then he disappears and emerges on your side,
does not mean that you can make it to the other side.  He may have had a
proxy (help) that you will not be privy to.



>
>>
>>> Did you read these sources?
>>>
>>
>> I read both of those pages in detail (several times before I posted to
>> the
>> mailing list!), but neither page mentions, specifies, or gives an
>> example
>> of a callback from Neko to HaXe.  None of the examples show the passing
>> of
>> a HaXe function to Neko.  The C FFI shows passing a Neko function to C.
>> It would be scientifically wrong for me to make the assumption that the
>> C
>> FFI callback to Neko, is the way to callback to HaXe, because the
>> implementation of HaXe functions might be fundamentally different than
>> Neko functions.  So I tried to verify that the Neko functions and HaXe
>> functions were compatible in that way, and as I explained I got some
>> conflicting signals in my investigation:
>>
> Ahhh, you're saying you want to pass a haXe "language" function to the
> Neko layer? ie, take a function written in haXe and pass that to the
> Neko executing code? Well, in that case, you're missing the picture of
> the relationship between haXe and Neko. haXe, when used with Neko, is
> merely the syntactical sugar used when writing, abstractly, the Neko
> code. Ergo, there is no haXe->Neko transition once compilation has
> occurred. Simply Neko->Neko.
>
>> http://lists.motion-twin.com/pipermail/haxe/2010-February/033337.html
>>
>> " ...why does
>> std.Neko.nekoToHaxe() throw an exception and not convert Neko tfunction,
>> given that std.Neko.Lib.load() does cast and return a tfunction to a
>> Dynamic?  Seems nekoToHave() should be fixed to convert a tfunction?
>>
>> http://code.google.com/p/haxe/source/browse/trunk/std/neko/Lib.hx "
>>
>> I also wrote that at the time, I wasn't aware of --neko-source, because
>> it
>> is documented on the compiler page for all targets, but not on the
>> "Getting Started Neko" Neko specific page.
>>
>> http://haxe.org/doc/start/neko
>> http://haxe.org/doc/compiler
>>
>
> Yeah, I did read that, but as I never deal with type checks using those
> particular constants, I can't help you. I learned early on that checks
> are best made in each layer before data transfer, not after. It's easier
> to read, easier to manage and makes for smaller code. :-)
>>
>>
>>> On a related point, I also feel the documentation lacks, but the
>>> reference doesn't.
>>>
>>
>> The reference has numerous ambiguities.  I like to cross off all the
>> binary bits before I can call it a reference.  A reference must not have
>> any holes or ambiguity.  For example I have no idea what the semantics
>> for
>> 'untyped' are as specified in the reference.  Ditto some of the
>> sentences
>> about Dynamic ("unlimited fields" even if it is not pointed to an object
>> value?).  I thought the type that is held by a dynamic will still be
>> checked at runtime?  In other words if you try to do . access on an
>> array,
>> then you will get a runtime exception?  None of this is specified in the
>> reference.  And so the "unlimited fields" only applies with the runtime
>> value is actually an object?
>>
> No. An array is an object, so you can add fields to it. You can dot
> access the push method, for example, too. Using reflection, you can add
> as many fields as you like. Likewise, you can extend Array and do it
> that way, too. It's much the same as in AS3.
>> See my mind wants to see all the cases.  I don't like holes in the
>> binary
>> bits of cases.
>>
>> http://haxe.org/ref/dynamic
>>
>> "A Dynamic variable has an infinite number of fields, all having the
>> type
>> Dynamic, which can be used for instance as an Array for bracket syntax."
>>
>> What does that mean?
>>
>>
>> "Untyped
>>
>> One other way to do dynamic things is to use the untyped keyword. When
>> an
>> expression is untyped, no type-check will be done so you can execute
>> many
>> dynamic operations at once"
>>
>> Ok I understand the it treat all variables and identifiers as dynamic.
>> So
>> does that mean if you access it like an object, it will assume the
>> object
>> was a HaXe object or a Neko object?  Array [] access?
>>
> It won't care. It might at runtime, but the compiler will make no
> assumptions.
>> How does that get translated to native code?  For example look in the
>> loader code in the API and see the useage of untyped.  It is doing some
>> kind of magic with the Neko structures apparently?  Maybe I just need to
>> look at more examples, in any case the reference seems to be ambigious
>> enough.
>>
> It's probably best to look at existing sources. These things do start to
> make more sense once you see it in action. Sometimes, it can
> overcomplicate by trying to explain in words.
>>
>> Also I feel the reference is not cross-indexed and you can't see the
>> sub-heading for each page quickly in one TOC so you can quickly click
>> down
>> and keep the structure of all the items covered.
>>
>>
>>
>>> The API is perfect if you *know* haXe. Now, while I
>>> (and Franco) put in lots of effort to get the former issue resolved
>>> with
>>> the Pro haXe and Neko book, a published book just doesn't evolve
>>> quickly
>>> enough (meaning hardly at all) to cover the updates that haXe has on a
>>> regular basis. Again, to combat this, I have been writing lots of
>>> articles for Flash and Flex Developer magazine, but due to the nature
>>> of
>>> magazines, it is pretty restrictive. As a result, I have recently
>>> started planning a series of video tutorials to cater for beginners to
>>> intermediate developers, which will hopefully be placed on the haXe
>>> website. This will take time, though, as I only have so many hours at
>>> my
>>> disposal :-)  Of course, though, some help here would be appreciated.
>>>
>>
>> I am not discouraging you, but I will say I think I would never have
>> time
>> to read or watch those outlying types of media.  I need something
>> concise
>> and 100% unambigious.
>>
>>
> True, but many people like video's and it's the only way to produce
> something that is as up-to-date as possible without working on it
> full-time ;-)
>
> Lee
>
>
>
>


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

Re: How to destroy an open source project community

Tony Polinelli
wwwwooooooooooooooooow!

So let me get this straight - i can set ANY image on fire with the
ART-o-matic software! ill take 2!

http://www.coolpage.com/aom.html ;P

best thing i've seen all day! hahah.

is there any way it can set webpages on fire?



On Fri, Feb 5, 2010 at 1:52 AM, Shelby Moore <[hidden email]> wrote:

>> Shelby Moore wrote:
>>>> @Shelby :- Your earlier comment about lack of documentation with Neko /
>>>> haXe confuses me. There are area's in the www.haxe.org website and the
>>>> www.nekovm.org website that explain this. The neko site shows how to
>>>> export functions in a Neko value struct and how to execute them:
>>>>
>>>> http://nekovm.org/doc/ffi
>>>>
>>>
>>> That is only for calling a Neko function.  No where does it say it is
>>> for
>>> calling a HaXe function.
>>>
>>>
>> Without sounding like a pantomime Dame, "Oh, yes it does!" ;-)
>>
>> <snip>
>>
>> val_call0(value f) : call the function f with 0 arguments.
>> val_call1(value f, value arg) : call the function f with 1 argument.
>> val_call2(value f, value arg1, value arg2) : call the function f with 2
>> arguments.
>> val_call3(value f, value arg1, value arg2, value arg3)
>> val_callN(value f, value *args, int nargs)
>>
>> </snip>
>>
>> if I pass in a closure from haXe into a C method, it gets passed as a
>> value struct. I can pass this struct to a val_call$ method as its first
>> argument. This page also describes how to check the number of args it
>> requires etc.
>
> I will repeat my same point again.  I hope you listen this time please.
> The above code is explaining how to call a Neko function from a C code.
> It is not saying that calling a HaXe function is done in the same way.
> Until one learns that Haxe functions and Neko functions are 100%
> interoperable, then one can not make that assumption.
>
> In the nekoToHaxe() and haxeToNeko() source code, the indication was they
> were not interoperable.  I now understand from you (and from my digging
> around in the Lib API sources, which you confirmed) that HaXe and Neko
> functions are equivalent.
>
>
>>>> while the haXe website details linking to exposed neko functions,
>>>> passed
>>>> value functions and type conversion, here:
>>>>
>>>> http://haxe.org/doc/neko/ffi
>>>>
>>>
>>>
>>> That is for HaXe calling a C function, not for C or Neko calling a HaXe
>>> function.
>>>
>>> We have 4 binary bits here (C<->Neko<->HaXe), so 16 cases to cover.  My
>>> mind thinks like this.  I have to cross off all 16 cases, esle I am
>>> making
>>> ASS-U-ME(ption).
>>>
>>
>> For the most part, you can consider C and Neko as being the same entity
>> on the C code tier, while haXe and Neko are the same entity in the haXe
>> language tier.
>
>
> Where does it specify that in the documentation?
>
> Please note this discussion is/was about the fact that documentation does
> not make that unambiguous.  Just because that information is in your head,
> doesn't impart it to my head, if I am not reading your mind.  I need the
> statements to be in the documentation, so I don't have to come to the
> mailing list to learn what should already be in the documentation.
>
>
>> Other than the Neko API you use for converting data types
>> in C, you can forget Neko even exists. For example, I can take a C
>> function and pass it to haXe like this:
>
> I am not talking about passing a C function to a HaXe function.  I said
> the missing documentation is about passing a HaXe function to C.  You are
> making the assumption that because the documentation says you can pass a C
> function to HaXe, that it implies you can pass a HaXe function to C.  It
> is in theory possible that the loader was doing some patching up, that
> wouldn't be the case going the other direction.
>
>>
>> value add( value a, value b )
>> {
>>     return alloc_int( val_int( a ), val_int( b ) );
>> }
>>
>> value get_c_function()
>> {
>>     return alloc_function( add, 2, "add" );
>> }
>>
>> DEFINE_PRIM( get_c_function, 0 )
>>
>>
>> Then, in haXe, I can do this:
>>
>> private static var add = neko.Lib.load("mylib","get_c_function", 0 );
>>
>> static function main()
>> {
>>     trace( add( 1, 2 ) ); // outputs 3
>> }
>>
>>
>> So, that's exactly what you wanted, without worrying about Neko, and all
>> documented in those two pages :-)
>
>
> No it is not, and I hope this time I explained my point well?
>
> If you are a mathematician, you will understand that not all operations
> have an inverse.  For example, just because you see someone on the
> opposite side of a canyon, then he disappears and emerges on your side,
> does not mean that you can make it to the other side.  He may have had a
> proxy (help) that you will not be privy to.
>
>
>
>>
>>>
>>>> Did you read these sources?
>>>>
>>>
>>> I read both of those pages in detail (several times before I posted to
>>> the
>>> mailing list!), but neither page mentions, specifies, or gives an
>>> example
>>> of a callback from Neko to HaXe.  None of the examples show the passing
>>> of
>>> a HaXe function to Neko.  The C FFI shows passing a Neko function to C.
>>> It would be scientifically wrong for me to make the assumption that the
>>> C
>>> FFI callback to Neko, is the way to callback to HaXe, because the
>>> implementation of HaXe functions might be fundamentally different than
>>> Neko functions.  So I tried to verify that the Neko functions and HaXe
>>> functions were compatible in that way, and as I explained I got some
>>> conflicting signals in my investigation:
>>>
>> Ahhh, you're saying you want to pass a haXe "language" function to the
>> Neko layer? ie, take a function written in haXe and pass that to the
>> Neko executing code? Well, in that case, you're missing the picture of
>> the relationship between haXe and Neko. haXe, when used with Neko, is
>> merely the syntactical sugar used when writing, abstractly, the Neko
>> code. Ergo, there is no haXe->Neko transition once compilation has
>> occurred. Simply Neko->Neko.
>>
>>> http://lists.motion-twin.com/pipermail/haxe/2010-February/033337.html
>>>
>>> " ...why does
>>> std.Neko.nekoToHaxe() throw an exception and not convert Neko tfunction,
>>> given that std.Neko.Lib.load() does cast and return a tfunction to a
>>> Dynamic?  Seems nekoToHave() should be fixed to convert a tfunction?
>>>
>>> http://code.google.com/p/haxe/source/browse/trunk/std/neko/Lib.hx "
>>>
>>> I also wrote that at the time, I wasn't aware of --neko-source, because
>>> it
>>> is documented on the compiler page for all targets, but not on the
>>> "Getting Started Neko" Neko specific page.
>>>
>>> http://haxe.org/doc/start/neko
>>> http://haxe.org/doc/compiler
>>>
>>
>> Yeah, I did read that, but as I never deal with type checks using those
>> particular constants, I can't help you. I learned early on that checks
>> are best made in each layer before data transfer, not after. It's easier
>> to read, easier to manage and makes for smaller code. :-)
>>>
>>>
>>>> On a related point, I also feel the documentation lacks, but the
>>>> reference doesn't.
>>>>
>>>
>>> The reference has numerous ambiguities.  I like to cross off all the
>>> binary bits before I can call it a reference.  A reference must not have
>>> any holes or ambiguity.  For example I have no idea what the semantics
>>> for
>>> 'untyped' are as specified in the reference.  Ditto some of the
>>> sentences
>>> about Dynamic ("unlimited fields" even if it is not pointed to an object
>>> value?).  I thought the type that is held by a dynamic will still be
>>> checked at runtime?  In other words if you try to do . access on an
>>> array,
>>> then you will get a runtime exception?  None of this is specified in the
>>> reference.  And so the "unlimited fields" only applies with the runtime
>>> value is actually an object?
>>>
>> No. An array is an object, so you can add fields to it. You can dot
>> access the push method, for example, too. Using reflection, you can add
>> as many fields as you like. Likewise, you can extend Array and do it
>> that way, too. It's much the same as in AS3.
>>> See my mind wants to see all the cases.  I don't like holes in the
>>> binary
>>> bits of cases.
>>>
>>> http://haxe.org/ref/dynamic
>>>
>>> "A Dynamic variable has an infinite number of fields, all having the
>>> type
>>> Dynamic, which can be used for instance as an Array for bracket syntax."
>>>
>>> What does that mean?
>>>
>>>
>>> "Untyped
>>>
>>> One other way to do dynamic things is to use the untyped keyword. When
>>> an
>>> expression is untyped, no type-check will be done so you can execute
>>> many
>>> dynamic operations at once"
>>>
>>> Ok I understand the it treat all variables and identifiers as dynamic.
>>> So
>>> does that mean if you access it like an object, it will assume the
>>> object
>>> was a HaXe object or a Neko object?  Array [] access?
>>>
>> It won't care. It might at runtime, but the compiler will make no
>> assumptions.
>>> How does that get translated to native code?  For example look in the
>>> loader code in the API and see the useage of untyped.  It is doing some
>>> kind of magic with the Neko structures apparently?  Maybe I just need to
>>> look at more examples, in any case the reference seems to be ambigious
>>> enough.
>>>
>> It's probably best to look at existing sources. These things do start to
>> make more sense once you see it in action. Sometimes, it can
>> overcomplicate by trying to explain in words.
>>>
>>> Also I feel the reference is not cross-indexed and you can't see the
>>> sub-heading for each page quickly in one TOC so you can quickly click
>>> down
>>> and keep the structure of all the items covered.
>>>
>>>
>>>
>>>> The API is perfect if you *know* haXe. Now, while I
>>>> (and Franco) put in lots of effort to get the former issue resolved
>>>> with
>>>> the Pro haXe and Neko book, a published book just doesn't evolve
>>>> quickly
>>>> enough (meaning hardly at all) to cover the updates that haXe has on a
>>>> regular basis. Again, to combat this, I have been writing lots of
>>>> articles for Flash and Flex Developer magazine, but due to the nature
>>>> of
>>>> magazines, it is pretty restrictive. As a result, I have recently
>>>> started planning a series of video tutorials to cater for beginners to
>>>> intermediate developers, which will hopefully be placed on the haXe
>>>> website. This will take time, though, as I only have so many hours at
>>>> my
>>>> disposal :-)  Of course, though, some help here would be appreciated.
>>>>
>>>
>>> I am not discouraging you, but I will say I think I would never have
>>> time
>>> to read or watch those outlying types of media.  I need something
>>> concise
>>> and 100% unambigious.
>>>
>>>
>> True, but many people like video's and it's the only way to produce
>> something that is as up-to-date as possible without working on it
>> full-time ;-)
>>
>> Lee
>>
>>
>>
>>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
Tony Polinelli
http://touchmypixel.com

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

Re: How to destroy an open source project community

Lee Sylvester
In reply to this post by Shelby Moore
I think the gulf in understanding here isn't with regard to reasoning
what the sites / documentation are explaining, but is more basic than
this. I think what you are failing to understand is the relationship
between C, Neko and haXe, so I'll try to do that here, as it is
imperative in order to understand working with Neko on a C and haXe level.

* When using Neko, you can consider using it and not using C and haXe.
Until hxcpp came along, the same could not be said of C and haXe working
together without Neko.

* Neko is a virtual machine written in C. As it is written in C, it can
be communicated with using C.

* haXe is NOT a compiler to C code. What it can do is compile to Neko
bytecode which can be consumed by the Neko VM and executed as C
functions. Remember, Neko is written in C, so any Neko apps are really
executed C code as interpreted by the Neko bytecodes. As haXe can
compile to Neko bytecodes, you can therefore assume that the
instructions you write in haXe (it's code) converts to executed C code.

* haXe is merely sugar. You can remove it out of the equation if you prefer.

* The Neko CFFI is an API that allows for converion of Neko types to C
types and vice versa. As Neko executions are C executions, you could
consider this C -> C executions or C -> C data type conversion.

* Again, as haXe is merely sugar and thus results in Neko bytecode when
compiled, using the above info, you can further normalise this as haXe
-> Neko -> C == C <-> C.


In a nutshell, then; haXe is merely a nice interface to a powerful VM
that is Neko. Neko is merely a convenient collection of C functions that
execute based on passed instructions. Ergo, haXe is a nice interface to
executing C functions. As an interface, you can call those C functions.
You do not therefore pass C back to haXe, but allow haXe to see that the
C functions exist and interact with them in a haXe like manner.

Sorry if anyone feels they could more scientifically explain this ;-) I
simply wanted it to be concise but understandable :-D

So, my feelings, therefore, are that you need to understand the
relationships before tackling the implementation. I had the same issues
when learning C/C++ all those years ago and not fully understanding
pointers. It was, therefore, quite counter-productive using them until I
had this knowledge not just onboard, but fully disected, analysed and
understood on a per-chip / memory stack -esque basis.

Best,
Lee







Shelby Moore wrote:

>> Shelby Moore wrote:
>>    
>>>> @Shelby :- Your earlier comment about lack of documentation with Neko /
>>>> haXe confuses me. There are area's in the www.haxe.org website and the
>>>> www.nekovm.org website that explain this. The neko site shows how to
>>>> export functions in a Neko value struct and how to execute them:
>>>>
>>>> http://nekovm.org/doc/ffi
>>>>
>>>>        
>>> That is only for calling a Neko function.  No where does it say it is
>>> for
>>> calling a HaXe function.
>>>
>>>
>>>      
>> Without sounding like a pantomime Dame, "Oh, yes it does!" ;-)
>>
>> <snip>
>>
>> val_call0(value f) : call the function f with 0 arguments.
>> val_call1(value f, value arg) : call the function f with 1 argument.
>> val_call2(value f, value arg1, value arg2) : call the function f with 2
>> arguments.
>> val_call3(value f, value arg1, value arg2, value arg3)
>> val_callN(value f, value *args, int nargs)
>>
>> </snip>
>>
>> if I pass in a closure from haXe into a C method, it gets passed as a
>> value struct. I can pass this struct to a val_call$ method as its first
>> argument. This page also describes how to check the number of args it
>> requires etc.
>>    
>
> I will repeat my same point again.  I hope you listen this time please.
> The above code is explaining how to call a Neko function from a C code.
> It is not saying that calling a HaXe function is done in the same way.
> Until one learns that Haxe functions and Neko functions are 100%
> interoperable, then one can not make that assumption.
>
> In the nekoToHaxe() and haxeToNeko() source code, the indication was they
> were not interoperable.  I now understand from you (and from my digging
> around in the Lib API sources, which you confirmed) that HaXe and Neko
> functions are equivalent.
>
>
>  
>>>> while the haXe website details linking to exposed neko functions,
>>>> passed
>>>> value functions and type conversion, here:
>>>>
>>>> http://haxe.org/doc/neko/ffi
>>>>
>>>>        
>>> That is for HaXe calling a C function, not for C or Neko calling a HaXe
>>> function.
>>>
>>> We have 4 binary bits here (C<->Neko<->HaXe), so 16 cases to cover.  My
>>> mind thinks like this.  I have to cross off all 16 cases, esle I am
>>> making
>>> ASS-U-ME(ption).
>>>
>>>      
>> For the most part, you can consider C and Neko as being the same entity
>> on the C code tier, while haXe and Neko are the same entity in the haXe
>> language tier.
>>    
>
>
> Where does it specify that in the documentation?
>
> Please note this discussion is/was about the fact that documentation does
> not make that unambiguous.  Just because that information is in your head,
> doesn't impart it to my head, if I am not reading your mind.  I need the
> statements to be in the documentation, so I don't have to come to the
> mailing list to learn what should already be in the documentation.
>
>
>  
>> Other than the Neko API you use for converting data types
>> in C, you can forget Neko even exists. For example, I can take a C
>> function and pass it to haXe like this:
>>    
>
> I am not talking about passing a C function to a HaXe function.  I said
> the missing documentation is about passing a HaXe function to C.  You are
> making the assumption that because the documentation says you can pass a C
> function to HaXe, that it implies you can pass a HaXe function to C.  It
> is in theory possible that the loader was doing some patching up, that
> wouldn't be the case going the other direction.
>
>  
>> value add( value a, value b )
>> {
>>     return alloc_int( val_int( a ), val_int( b ) );
>> }
>>
>> value get_c_function()
>> {
>>     return alloc_function( add, 2, "add" );
>> }
>>
>> DEFINE_PRIM( get_c_function, 0 )
>>
>>
>> Then, in haXe, I can do this:
>>
>> private static var add = neko.Lib.load("mylib","get_c_function", 0 );
>>
>> static function main()
>> {
>>     trace( add( 1, 2 ) ); // outputs 3
>> }
>>
>>
>> So, that's exactly what you wanted, without worrying about Neko, and all
>> documented in those two pages :-)
>>    
>
>
> No it is not, and I hope this time I explained my point well?
>
> If you are a mathematician, you will understand that not all operations
> have an inverse.  For example, just because you see someone on the
> opposite side of a canyon, then he disappears and emerges on your side,
> does not mean that you can make it to the other side.  He may have had a
> proxy (help) that you will not be privy to.
>
>
>
>  
>>>> Did you read these sources?
>>>>
>>>>        
>>> I read both of those pages in detail (several times before I posted to
>>> the
>>> mailing list!), but neither page mentions, specifies, or gives an
>>> example
>>> of a callback from Neko to HaXe.  None of the examples show the passing
>>> of
>>> a HaXe function to Neko.  The C FFI shows passing a Neko function to C.
>>> It would be scientifically wrong for me to make the assumption that the
>>> C
>>> FFI callback to Neko, is the way to callback to HaXe, because the
>>> implementation of HaXe functions might be fundamentally different than
>>> Neko functions.  So I tried to verify that the Neko functions and HaXe
>>> functions were compatible in that way, and as I explained I got some
>>> conflicting signals in my investigation:
>>>
>>>      
>> Ahhh, you're saying you want to pass a haXe "language" function to the
>> Neko layer? ie, take a function written in haXe and pass that to the
>> Neko executing code? Well, in that case, you're missing the picture of
>> the relationship between haXe and Neko. haXe, when used with Neko, is
>> merely the syntactical sugar used when writing, abstractly, the Neko
>> code. Ergo, there is no haXe->Neko transition once compilation has
>> occurred. Simply Neko->Neko.
>>
>>    
>>> http://lists.motion-twin.com/pipermail/haxe/2010-February/033337.html
>>>
>>> " ...why does
>>> std.Neko.nekoToHaxe() throw an exception and not convert Neko tfunction,
>>> given that std.Neko.Lib.load() does cast and return a tfunction to a
>>> Dynamic?  Seems nekoToHave() should be fixed to convert a tfunction?
>>>
>>> http://code.google.com/p/haxe/source/browse/trunk/std/neko/Lib.hx "
>>>
>>> I also wrote that at the time, I wasn't aware of --neko-source, because
>>> it
>>> is documented on the compiler page for all targets, but not on the
>>> "Getting Started Neko" Neko specific page.
>>>
>>> http://haxe.org/doc/start/neko
>>> http://haxe.org/doc/compiler
>>>
>>>      
>> Yeah, I did read that, but as I never deal with type checks using those
>> particular constants, I can't help you. I learned early on that checks
>> are best made in each layer before data transfer, not after. It's easier
>> to read, easier to manage and makes for smaller code. :-)
>>    
>>>      
>>>> On a related point, I also feel the documentation lacks, but the
>>>> reference doesn't.
>>>>
>>>>        
>>> The reference has numerous ambiguities.  I like to cross off all the
>>> binary bits before I can call it a reference.  A reference must not have
>>> any holes or ambiguity.  For example I have no idea what the semantics
>>> for
>>> 'untyped' are as specified in the reference.  Ditto some of the
>>> sentences
>>> about Dynamic ("unlimited fields" even if it is not pointed to an object
>>> value?).  I thought the type that is held by a dynamic will still be
>>> checked at runtime?  In other words if you try to do . access on an
>>> array,
>>> then you will get a runtime exception?  None of this is specified in the
>>> reference.  And so the "unlimited fields" only applies with the runtime
>>> value is actually an object?
>>>
>>>      
>> No. An array is an object, so you can add fields to it. You can dot
>> access the push method, for example, too. Using reflection, you can add
>> as many fields as you like. Likewise, you can extend Array and do it
>> that way, too. It's much the same as in AS3.
>>    
>>> See my mind wants to see all the cases.  I don't like holes in the
>>> binary
>>> bits of cases.
>>>
>>> http://haxe.org/ref/dynamic
>>>
>>> "A Dynamic variable has an infinite number of fields, all having the
>>> type
>>> Dynamic, which can be used for instance as an Array for bracket syntax."
>>>
>>> What does that mean?
>>>
>>>
>>> "Untyped
>>>
>>> One other way to do dynamic things is to use the untyped keyword. When
>>> an
>>> expression is untyped, no type-check will be done so you can execute
>>> many
>>> dynamic operations at once"
>>>
>>> Ok I understand the it treat all variables and identifiers as dynamic.
>>> So
>>> does that mean if you access it like an object, it will assume the
>>> object
>>> was a HaXe object or a Neko object?  Array [] access?
>>>
>>>      
>> It won't care. It might at runtime, but the compiler will make no
>> assumptions.
>>    
>>> How does that get translated to native code?  For example look in the
>>> loader code in the API and see the useage of untyped.  It is doing some
>>> kind of magic with the Neko structures apparently?  Maybe I just need to
>>> look at more examples, in any case the reference seems to be ambigious
>>> enough.
>>>
>>>      
>> It's probably best to look at existing sources. These things do start to
>> make more sense once you see it in action. Sometimes, it can
>> overcomplicate by trying to explain in words.
>>    
>>> Also I feel the reference is not cross-indexed and you can't see the
>>> sub-heading for each page quickly in one TOC so you can quickly click
>>> down
>>> and keep the structure of all the items covered.
>>>
>>>
>>>
>>>      
>>>> The API is perfect if you *know* haXe. Now, while I
>>>> (and Franco) put in lots of effort to get the former issue resolved
>>>> with
>>>> the Pro haXe and Neko book, a published book just doesn't evolve
>>>> quickly
>>>> enough (meaning hardly at all) to cover the updates that haXe has on a
>>>> regular basis. Again, to combat this, I have been writing lots of
>>>> articles for Flash and Flex Developer magazine, but due to the nature
>>>> of
>>>> magazines, it is pretty restrictive. As a result, I have recently
>>>> started planning a series of video tutorials to cater for beginners to
>>>> intermediate developers, which will hopefully be placed on the haXe
>>>> website. This will take time, though, as I only have so many hours at
>>>> my
>>>> disposal :-)  Of course, though, some help here would be appreciated.
>>>>
>>>>        
>>> I am not discouraging you, but I will say I think I would never have
>>> time
>>> to read or watch those outlying types of media.  I need something
>>> concise
>>> and 100% unambigious.
>>>
>>>
>>>      
>> True, but many people like video's and it's the only way to produce
>> something that is as up-to-date as possible without working on it
>> full-time ;-)
>>
>> Lee
>>
>>
>>
>>
>>    
>
>
>  


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

Re: How to destroy an open source project community

Tarwin Stroh-Spijer
In reply to this post by Tony Polinelli
Best way to kill an open source community: let someone troll your list, which until now have been a nice place to hang out, for more than 24 hours!


Tarwin Stroh-Spijer


On Fri, Feb 5, 2010 at 2:10 AM, Tony Polinelli <[hidden email]> wrote:
wwwwooooooooooooooooow!

So let me get this straight - i can set ANY image on fire with the
ART-o-matic software! ill take 2!

http://www.coolpage.com/aom.html ;P

best thing i've seen all day! hahah.

is there any way it can set webpages on fire?



On Fri, Feb 5, 2010 at 1:52 AM, Shelby Moore <[hidden email]> wrote:
>> Shelby Moore wrote:
>>>> @Shelby :- Your earlier comment about lack of documentation with Neko /
>>>> haXe confuses me. There are area's in the www.haxe.org website and the
>>>> www.nekovm.org website that explain this. The neko site shows how to
>>>> export functions in a Neko value struct and how to execute them:
>>>>
>>>> http://nekovm.org/doc/ffi
>>>>
>>>
>>> That is only for calling a Neko function.  No where does it say it is
>>> for
>>> calling a HaXe function.
>>>
>>>
>> Without sounding like a pantomime Dame, "Oh, yes it does!" ;-)
>>
>> <snip>
>>
>> val_call0(value f) : call the function f with 0 arguments.
>> val_call1(value f, value arg) : call the function f with 1 argument.
>> val_call2(value f, value arg1, value arg2) : call the function f with 2
>> arguments.
>> val_call3(value f, value arg1, value arg2, value arg3)
>> val_callN(value f, value *args, int nargs)
>>
>> </snip>
>>
>> if I pass in a closure from haXe into a C method, it gets passed as a
>> value struct. I can pass this struct to a val_call$ method as its first
>> argument. This page also describes how to check the number of args it
>> requires etc.
>
> I will repeat my same point again.  I hope you listen this time please.
> The above code is explaining how to call a Neko function from a C code.
> It is not saying that calling a HaXe function is done in the same way.
> Until one learns that Haxe functions and Neko functions are 100%
> interoperable, then one can not make that assumption.
>
> In the nekoToHaxe() and haxeToNeko() source code, the indication was they
> were not interoperable.  I now understand from you (and from my digging
> around in the Lib API sources, which you confirmed) that HaXe and Neko
> functions are equivalent.
>
>
>>>> while the haXe website details linking to exposed neko functions,
>>>> passed
>>>> value functions and type conversion, here:
>>>>
>>>> http://haxe.org/doc/neko/ffi
>>>>
>>>
>>>
>>> That is for HaXe calling a C function, not for C or Neko calling a HaXe
>>> function.
>>>
>>> We have 4 binary bits here (C<->Neko<->HaXe), so 16 cases to cover.  My
>>> mind thinks like this.  I have to cross off all 16 cases, esle I am
>>> making
>>> ASS-U-ME(ption).
>>>
>>
>> For the most part, you can consider C and Neko as being the same entity
>> on the C code tier, while haXe and Neko are the same entity in the haXe
>> language tier.
>
>
> Where does it specify that in the documentation?
>
> Please note this discussion is/was about the fact that documentation does
> not make that unambiguous.  Just because that information is in your head,
> doesn't impart it to my head, if I am not reading your mind.  I need the
> statements to be in the documentation, so I don't have to come to the
> mailing list to learn what should already be in the documentation.
>
>
>> Other than the Neko API you use for converting data types
>> in C, you can forget Neko even exists. For example, I can take a C
>> function and pass it to haXe like this:
>
> I am not talking about passing a C function to a HaXe function.  I said
> the missing documentation is about passing a HaXe function to C.  You are
> making the assumption that because the documentation says you can pass a C
> function to HaXe, that it implies you can pass a HaXe function to C.  It
> is in theory possible that the loader was doing some patching up, that
> wouldn't be the case going the other direction.
>
>>
>> value add( value a, value b )
>> {
>>     return alloc_int( val_int( a ), val_int( b ) );
>> }
>>
>> value get_c_function()
>> {
>>     return alloc_function( add, 2, "add" );
>> }
>>
>> DEFINE_PRIM( get_c_function, 0 )
>>
>>
>> Then, in haXe, I can do this:
>>
>> private static var add = neko.Lib.load("mylib","get_c_function", 0 );
>>
>> static function main()
>> {
>>     trace( add( 1, 2 ) ); // outputs 3
>> }
>>
>>
>> So, that's exactly what you wanted, without worrying about Neko, and all
>> documented in those two pages :-)
>
>
> No it is not, and I hope this time I explained my point well?
>
> If you are a mathematician, you will understand that not all operations
> have an inverse.  For example, just because you see someone on the
> opposite side of a canyon, then he disappears and emerges on your side,
> does not mean that you can make it to the other side.  He may have had a
> proxy (help) that you will not be privy to.
>
>
>
>>
>>>
>>>> Did you read these sources?
>>>>
>>>
>>> I read both of those pages in detail (several times before I posted to
>>> the
>>> mailing list!), but neither page mentions, specifies, or gives an
>>> example
>>> of a callback from Neko to HaXe.  None of the examples show the passing
>>> of
>>> a HaXe function to Neko.  The C FFI shows passing a Neko function to C.
>>> It would be scientifically wrong for me to make the assumption that the
>>> C
>>> FFI callback to Neko, is the way to callback to HaXe, because the
>>> implementation of HaXe functions might be fundamentally different than
>>> Neko functions.  So I tried to verify that the Neko functions and HaXe
>>> functions were compatible in that way, and as I explained I got some
>>> conflicting signals in my investigation:
>>>
>> Ahhh, you're saying you want to pass a haXe "language" function to the
>> Neko layer? ie, take a function written in haXe and pass that to the
>> Neko executing code? Well, in that case, you're missing the picture of
>> the relationship between haXe and Neko. haXe, when used with Neko, is
>> merely the syntactical sugar used when writing, abstractly, the Neko
>> code. Ergo, there is no haXe->Neko transition once compilation has
>> occurred. Simply Neko->Neko.
>>
>>> http://lists.motion-twin.com/pipermail/haxe/2010-February/033337.html
>>>
>>> " ...why does
>>> std.Neko.nekoToHaxe() throw an exception and not convert Neko tfunction,
>>> given that std.Neko.Lib.load() does cast and return a tfunction to a
>>> Dynamic?  Seems nekoToHave() should be fixed to convert a tfunction?
>>>
>>> http://code.google.com/p/haxe/source/browse/trunk/std/neko/Lib.hx "
>>>
>>> I also wrote that at the time, I wasn't aware of --neko-source, because
>>> it
>>> is documented on the compiler page for all targets, but not on the
>>> "Getting Started Neko" Neko specific page.
>>>
>>> http://haxe.org/doc/start/neko
>>> http://haxe.org/doc/compiler
>>>
>>
>> Yeah, I did read that, but as I never deal with type checks using those
>> particular constants, I can't help you. I learned early on that checks
>> are best made in each layer before data transfer, not after. It's easier
>> to read, easier to manage and makes for smaller code. :-)
>>>
>>>
>>>> On a related point, I also feel the documentation lacks, but the
>>>> reference doesn't.
>>>>
>>>
>>> The reference has numerous ambiguities.  I like to cross off all the
>>> binary bits before I can call it a reference.  A reference must not have
>>> any holes or ambiguity.  For example I have no idea what the semantics
>>> for
>>> 'untyped' are as specified in the reference.  Ditto some of the
>>> sentences
>>> about Dynamic ("unlimited fields" even if it is not pointed to an object
>>> value?).  I thought the type that is held by a dynamic will still be
>>> checked at runtime?  In other words if you try to do . access on an
>>> array,
>>> then you will get a runtime exception?  None of this is specified in the
>>> reference.  And so the "unlimited fields" only applies with the runtime
>>> value is actually an object?
>>>
>> No. An array is an object, so you can add fields to it. You can dot
>> access the push method, for example, too. Using reflection, you can add
>> as many fields as you like. Likewise, you can extend Array and do it
>> that way, too. It's much the same as in AS3.
>>> See my mind wants to see all the cases.  I don't like holes in the
>>> binary
>>> bits of cases.
>>>
>>> http://haxe.org/ref/dynamic
>>>
>>> "A Dynamic variable has an infinite number of fields, all having the
>>> type
>>> Dynamic, which can be used for instance as an Array for bracket syntax."
>>>
>>> What does that mean?
>>>
>>>
>>> "Untyped
>>>
>>> One other way to do dynamic things is to use the untyped keyword. When
>>> an
>>> expression is untyped, no type-check will be done so you can execute
>>> many
>>> dynamic operations at once"
>>>
>>> Ok I understand the it treat all variables and identifiers as dynamic.
>>> So
>>> does that mean if you access it like an object, it will assume the
>>> object
>>> was a HaXe object or a Neko object?  Array [] access?
>>>
>> It won't care. It might at runtime, but the compiler will make no
>> assumptions.
>>> How does that get translated to native code?  For example look in the
>>> loader code in the API and see the useage of untyped.  It is doing some
>>> kind of magic with the Neko structures apparently?  Maybe I just need to
>>> look at more examples, in any case the reference seems to be ambigious
>>> enough.
>>>
>> It's probably best to look at existing sources. These things do start to
>> make more sense once you see it in action. Sometimes, it can
>> overcomplicate by trying to explain in words.
>>>
>>> Also I feel the reference is not cross-indexed and you can't see the
>>> sub-heading for each page quickly in one TOC so you can quickly click
>>> down
>>> and keep the structure of all the items covered.
>>>
>>>
>>>
>>>> The API is perfect if you *know* haXe. Now, while I
>>>> (and Franco) put in lots of effort to get the former issue resolved
>>>> with
>>>> the Pro haXe and Neko book, a published book just doesn't evolve
>>>> quickly
>>>> enough (meaning hardly at all) to cover the updates that haXe has on a
>>>> regular basis. Again, to combat this, I have been writing lots of
>>>> articles for Flash and Flex Developer magazine, but due to the nature
>>>> of
>>>> magazines, it is pretty restrictive. As a result, I have recently
>>>> started planning a series of video tutorials to cater for beginners to
>>>> intermediate developers, which will hopefully be placed on the haXe
>>>> website. This will take time, though, as I only have so many hours at
>>>> my
>>>> disposal :-)  Of course, though, some help here would be appreciated.
>>>>
>>>
>>> I am not discouraging you, but I will say I think I would never have
>>> time
>>> to read or watch those outlying types of media.  I need something
>>> concise
>>> and 100% unambigious.
>>>
>>>
>> True, but many people like video's and it's the only way to produce
>> something that is as up-to-date as possible without working on it
>> full-time ;-)
>>
>> Lee
>>
>>
>>
>>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
Tony Polinelli
http://touchmypixel.com

--
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: How to destroy an open source project community

Philipp Klose-2
+1 :-)

Tarwin Stroh-Spijer wrote:
> Best way to kill an open source community: let someone troll your
> list, which until now have been a nice place to hang out, for more
> than 24 hours!


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

Re: How to destroy an open source project community

Martijn Loots
In reply to this post by Shelby Moore
I tried following this for a while, but it seems that your trying to
prove you're right, gathering new arguments as it goes on...

I may not have as much theoretical background in IT as you, but 30+
years of experience has gotten me to the point where I can make an
educated guess...

haXe unifies a number of very different languages with one syntax.
That's a very big advantage for any developer touching the haXe
targets in his/her daily life. It comes with one big disadvantage
though: as haXe progresses, it has to keep in sync with its targets.

I have great respect for Nicolas walking this very tight rope juggling
these targets as he goes. I have not seen any proof of anyone so far
understanding all these same aspects while developing and extending
haXe. It's by nature a compromising language: you can't do it right on
all aspects without losing out on some other thing...

Painstakingly pointing out every weakness does not help haXe progress
as much as making the effort and doing something about it. Most of us
do that by using haXe, stumbling over real life bugs and reporting on
it. And the more active haXers add to the wiki, the library or their
blogs.

Few people flood the mailing list for sake of argument. And I was
glad about that until now...

I won't feed you anymore on this now.

Just my 2 cents.
--
-Martijn

On Thu, 4 Feb 2010, Shelby Moore wrote:

>> Shelby Moore wrote:
>>>> @Shelby :- Your earlier comment about lack of documentation with Neko /
>>>> haXe confuses me. There are area's in the www.haxe.org website and the
>>>> www.nekovm.org website that explain this. The neko site shows how to
>>>> export functions in a Neko value struct and how to execute them:
>>>>
>>>> http://nekovm.org/doc/ffi
>>>>
>>>
>>> That is only for calling a Neko function.  No where does it say it is
>>> for
>>> calling a HaXe function.
>>>
>>>
>> Without sounding like a pantomime Dame, "Oh, yes it does!" ;-)
>>
>> <snip>
>>
>> val_call0(value f) : call the function f with 0 arguments.
>> val_call1(value f, value arg) : call the function f with 1 argument.
>> val_call2(value f, value arg1, value arg2) : call the function f with 2
>> arguments.
>> val_call3(value f, value arg1, value arg2, value arg3)
>> val_callN(value f, value *args, int nargs)
>>
>> </snip>
>>
>> if I pass in a closure from haXe into a C method, it gets passed as a
>> value struct. I can pass this struct to a val_call$ method as its first
>> argument. This page also describes how to check the number of args it
>> requires etc.
>
> I will repeat my same point again.  I hope you listen this time please.
> The above code is explaining how to call a Neko function from a C code.
> It is not saying that calling a HaXe function is done in the same way.
> Until one learns that Haxe functions and Neko functions are 100%
> interoperable, then one can not make that assumption.
>
> In the nekoToHaxe() and haxeToNeko() source code, the indication was they
> were not interoperable.  I now understand from you (and from my digging
> around in the Lib API sources, which you confirmed) that HaXe and Neko
> functions are equivalent.
>
>
>>>> while the haXe website details linking to exposed neko functions,
>>>> passed
>>>> value functions and type conversion, here:
>>>>
>>>> http://haxe.org/doc/neko/ffi
>>>>
>>>
>>>
>>> That is for HaXe calling a C function, not for C or Neko calling a HaXe
>>> function.
>>>
>>> We have 4 binary bits here (C<->Neko<->HaXe), so 16 cases to cover.  My
>>> mind thinks like this.  I have to cross off all 16 cases, esle I am
>>> making
>>> ASS-U-ME(ption).
>>>
>>
>> For the most part, you can consider C and Neko as being the same entity
>> on the C code tier, while haXe and Neko are the same entity in the haXe
>> language tier.
>
>
> Where does it specify that in the documentation?
>
> Please note this discussion is/was about the fact that documentation does
> not make that unambiguous.  Just because that information is in your head,
> doesn't impart it to my head, if I am not reading your mind.  I need the
> statements to be in the documentation, so I don't have to come to the
> mailing list to learn what should already be in the documentation.
>
>
>> Other than the Neko API you use for converting data types
>> in C, you can forget Neko even exists. For example, I can take a C
>> function and pass it to haXe like this:
>
> I am not talking about passing a C function to a HaXe function.  I said
> the missing documentation is about passing a HaXe function to C.  You are
> making the assumption that because the documentation says you can pass a C
> function to HaXe, that it implies you can pass a HaXe function to C.  It
> is in theory possible that the loader was doing some patching up, that
> wouldn't be the case going the other direction.
>
>>
>> value add( value a, value b )
>> {
>>     return alloc_int( val_int( a ), val_int( b ) );
>> }
>>
>> value get_c_function()
>> {
>>     return alloc_function( add, 2, "add" );
>> }
>>
>> DEFINE_PRIM( get_c_function, 0 )
>>
>>
>> Then, in haXe, I can do this:
>>
>> private static var add = neko.Lib.load("mylib","get_c_function", 0 );
>>
>> static function main()
>> {
>>     trace( add( 1, 2 ) ); // outputs 3
>> }
>>
>>
>> So, that's exactly what you wanted, without worrying about Neko, and all
>> documented in those two pages :-)
>
>
> No it is not, and I hope this time I explained my point well?
>
> If you are a mathematician, you will understand that not all operations
> have an inverse.  For example, just because you see someone on the
> opposite side of a canyon, then he disappears and emerges on your side,
> does not mean that you can make it to the other side.  He may have had a
> proxy (help) that you will not be privy to.
>
>
>
>>
>>>
>>>> Did you read these sources?
>>>>
>>>
>>> I read both of those pages in detail (several times before I posted to
>>> the
>>> mailing list!), but neither page mentions, specifies, or gives an
>>> example
>>> of a callback from Neko to HaXe.  None of the examples show the passing
>>> of
>>> a HaXe function to Neko.  The C FFI shows passing a Neko function to C.
>>> It would be scientifically wrong for me to make the assumption that the
>>> C
>>> FFI callback to Neko, is the way to callback to HaXe, because the
>>> implementation of HaXe functions might be fundamentally different than
>>> Neko functions.  So I tried to verify that the Neko functions and HaXe
>>> functions were compatible in that way, and as I explained I got some
>>> conflicting signals in my investigation:
>>>
>> Ahhh, you're saying you want to pass a haXe "language" function to the
>> Neko layer? ie, take a function written in haXe and pass that to the
>> Neko executing code? Well, in that case, you're missing the picture of
>> the relationship between haXe and Neko. haXe, when used with Neko, is
>> merely the syntactical sugar used when writing, abstractly, the Neko
>> code. Ergo, there is no haXe->Neko transition once compilation has
>> occurred. Simply Neko->Neko.
>>
>>> http://lists.motion-twin.com/pipermail/haxe/2010-February/033337.html
>>>
>>> " ...why does
>>> std.Neko.nekoToHaxe() throw an exception and not convert Neko tfunction,
>>> given that std.Neko.Lib.load() does cast and return a tfunction to a
>>> Dynamic?  Seems nekoToHave() should be fixed to convert a tfunction?
>>>
>>> http://code.google.com/p/haxe/source/browse/trunk/std/neko/Lib.hx "
>>>
>>> I also wrote that at the time, I wasn't aware of --neko-source, because
>>> it
>>> is documented on the compiler page for all targets, but not on the
>>> "Getting Started Neko" Neko specific page.
>>>
>>> http://haxe.org/doc/start/neko
>>> http://haxe.org/doc/compiler
>>>
>>
>> Yeah, I did read that, but as I never deal with type checks using those
>> particular constants, I can't help you. I learned early on that checks
>> are best made in each layer before data transfer, not after. It's easier
>> to read, easier to manage and makes for smaller code. :-)
>>>
>>>
>>>> On a related point, I also feel the documentation lacks, but the
>>>> reference doesn't.
>>>>
>>>
>>> The reference has numerous ambiguities.  I like to cross off all the
>>> binary bits before I can call it a reference.  A reference must not have
>>> any holes or ambiguity.  For example I have no idea what the semantics
>>> for
>>> 'untyped' are as specified in the reference.  Ditto some of the
>>> sentences
>>> about Dynamic ("unlimited fields" even if it is not pointed to an object
>>> value?).  I thought the type that is held by a dynamic will still be
>>> checked at runtime?  In other words if you try to do . access on an
>>> array,
>>> then you will get a runtime exception?  None of this is specified in the
>>> reference.  And so the "unlimited fields" only applies with the runtime
>>> value is actually an object?
>>>
>> No. An array is an object, so you can add fields to it. You can dot
>> access the push method, for example, too. Using reflection, you can add
>> as many fields as you like. Likewise, you can extend Array and do it
>> that way, too. It's much the same as in AS3.
>>> See my mind wants to see all the cases.  I don't like holes in the
>>> binary
>>> bits of cases.
>>>
>>> http://haxe.org/ref/dynamic
>>>
>>> "A Dynamic variable has an infinite number of fields, all having the
>>> type
>>> Dynamic, which can be used for instance as an Array for bracket syntax."
>>>
>>> What does that mean?
>>>
>>>
>>> "Untyped
>>>
>>> One other way to do dynamic things is to use the untyped keyword. When
>>> an
>>> expression is untyped, no type-check will be done so you can execute
>>> many
>>> dynamic operations at once"
>>>
>>> Ok I understand the it treat all variables and identifiers as dynamic.
>>> So
>>> does that mean if you access it like an object, it will assume the
>>> object
>>> was a HaXe object or a Neko object?  Array [] access?
>>>
>> It won't care. It might at runtime, but the compiler will make no
>> assumptions.
>>> How does that get translated to native code?  For example look in the
>>> loader code in the API and see the useage of untyped.  It is doing some
>>> kind of magic with the Neko structures apparently?  Maybe I just need to
>>> look at more examples, in any case the reference seems to be ambigious
>>> enough.
>>>
>> It's probably best to look at existing sources. These things do start to
>> make more sense once you see it in action. Sometimes, it can
>> overcomplicate by trying to explain in words.
>>>
>>> Also I feel the reference is not cross-indexed and you can't see the
>>> sub-heading for each page quickly in one TOC so you can quickly click
>>> down
>>> and keep the structure of all the items covered.
>>>
>>>
>>>
>>>> The API is perfect if you *know* haXe. Now, while I
>>>> (and Franco) put in lots of effort to get the former issue resolved
>>>> with
>>>> the Pro haXe and Neko book, a published book just doesn't evolve
>>>> quickly
>>>> enough (meaning hardly at all) to cover the updates that haXe has on a
>>>> regular basis. Again, to combat this, I have been writing lots of
>>>> articles for Flash and Flex Developer magazine, but due to the nature
>>>> of
>>>> magazines, it is pretty restrictive. As a result, I have recently
>>>> started planning a series of video tutorials to cater for beginners to
>>>> intermediate developers, which will hopefully be placed on the haXe
>>>> website. This will take time, though, as I only have so many hours at
>>>> my
>>>> disposal :-)  Of course, though, some help here would be appreciated.
>>>>
>>>
>>> I am not discouraging you, but I will say I think I would never have
>>> time
>>> to read or watch those outlying types of media.  I need something
>>> concise
>>> and 100% unambigious.
>>>
>>>
>> True, but many people like video's and it's the only way to produce
>> something that is as up-to-date as possible without working on it
>> full-time ;-)
>>
>> Lee
>>
>>
>>
>>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
-Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
-          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
-         ( >__< )  ----------------------------------------
-         ^^^  ^^^  (   Netwerken, Security, Open Source   )

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