RE: [Caml-list] Cross-compiling OCaml

["Brandon J. Van Every" <vanevery@indiegamedesign.com>]

james woodyatt wrote:
> Brandon J. Van Every wrote:
> > The Caml Trade wrote:
> >
> > Ok, I suppose you're confident in the longevity of OCaml
> > then.  I think
> > market mindshare has to be fought for, if one wants to continue to
> > enjoy good contracts.
>
> You're trying to recruit the wrong people to join the fight.

Yes, actually, I've realized that mailing lists such as this are filled
with early adopters who are nevertheless 100% satisfied with their
personal situation.  It's not everybody, but it's always somebody.  If I
talk about improvement, they're always vocal about how satisfied they
are.  I encountered a similar phenom on comp.lang.python and this
confirms the archetype.  My main purpose is to have a presence and
provide a channel for people who are *NOT* satisfied.  In other words, I
seek recruits for ocaml-biz, COCAN, and ocamlgames.

> > My stereotype of a UNIX guy is someone who likes to play with text
> > editors all day long.
>
> Thank you for sharing your stereotype.

You're welcome.  There's a lot of truth in stereotypes.  One of the
reasons I gave up on Seattle's local Python user groups, is I'd keep
going to meetings, and they'd talk about all sorts of text processing
scripting database stuff.  Never about 3D graphics, AI, or games.  I
conclude that there's this entire world of text processual data that a
lot of people are into, that they think is really really kewl, but that
I've just never been involved in.  I suppose text has a compelling
tractability, it seems to fit the UNIX scripter hacker meme.  Contrast
this to Windows which doesn't even have a decent OS shell by default.
Instead one has abundant GUI eye candy.  Between the UNIX and Windows
world, there is clearly a split between textual and graphical
orientation.  It's not an exclusive split, I did say it was a
stereotype, but in terms of dominant trends it's quite true.

OCaml's UNIX-centric community doesn't strike me as an exception to this
rule.  My plans are mainly about graphics technologies I need to build,
not graphics technologies that are readily available.  OCaml is mainly
proven in the realm of language transformation.  So, is its
UNIX-oriented community an accident?  I think not.

> I'm sure it must be helpful to vent.

'Twas a stereotype, not a vent.

> Your project on the caml-list is clearly to harp on Unix
> developers to
> switch to developing for Windows until they can't bear to
> listen to it anymore

You sure make a big deal out of out of 1 initial statement that was
framed with the caveat, "I know you Linux / mingw guys aren't into
this."  I was just being honest about what native Windows developers
actually consider useful.  If one thinks one's solving some kind of
Windows deployment goal, well, cross-compilation from Linux ain't it.
It's an avoidance goal, not a deployment goal.

> and either 1) killfile your entire mail domain, or 2)
> switch to
> developing for Windows just to make you happy.
>
> Guess which one I'm thinking is more likely to happen.

I think that's your point of view, not my project.  Discussions of what
may or may not be my projects are best left to ocamlgames and ocaml-biz.


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  Bigarray!
Unboxed overhead group!  Wondering!  chant chant chant...

Is my technical content showing?

// return an array of 100 packed tuples
temps
  int $[tvar0][2*100]; // what the c function needs
  value $[tvar1]; // one int
  value $[tvar2]; // one tuple
  int $[tvar3] // loop control var
oncePre
eachPre
  $[cvar0]=&($[tvar0][0]);
eachPost
  $[lvar0] = alloc(2*100, 0 /*NB: zero-tagged block*/ );
  for(int $[tvar3]=0;$[tvar3]<100;$[tvar3]++) {
    $[tvar2] = alloc_tuple(2);
    $[tvar1] = Val_int($[cvar0][0+2*$[tvar3]]);
    Store_field($[tvar2],0,$[tvar1]);
    $[tvar1] = Val_int($[cvar0][1]);
    Store_field($[tvar2],1,$[tvar1+2*$[tvar3]]);
    Array_store($[lvar0],$[tvar3],$[tvar0]);
  }
oncePost

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners