On 2/16/07, Erick Tryzelaar <[EMAIL PROTECTED]> wrote:
> What's wrong? I've never had a connection problem. About two years ago Max failed to login or reset his passwd, or something, so it's clearly impossible. > It sure does. Migrating the mailing list isn't as important as getting > the website touched up. Of course, having the mailing list more > accessible can't hurt. You think? The mailing list is felix's doco and main source of outlandish claims! It associates the word felix with the super sexy search terms massively parallel microthreading 10000 socket connections game scripting SDL/opengl etc All these things should lead if not directly to the svn co link and a recentish tarball with decent demos, at least to an interesting looking post with Max's sig that contains the svn co cmd and a link to a recentish tarball. Phew. > de-interscripting the system would be pretty simple. All it would > require is just not running the interscript phase, and modifying "umk > cleanup" and "umk virgin" to not delete everything. Oh, but then there's > all those interscript macros we'd lose... > > That said, it does make sense for certain things, such as the tutorial. > On the other hand, scaring away potential developers is probably worse > than that is better. I think this idea is going in a catastrophic direction - let's explore the model that it assumes: Mr Potential Developer just *knows* about felix and also knows that he wants to use it. He goes to felix.sf.net and just *knows* to skip over the two ancient "red-herring" tarballs that are essentially read only anyway, and instead clicks on the wiki link, this leads to the real website. From there, using raw programmerly instinct, he knows to skip the two further outdated cvs tarballs to finally find svn co https://felix.svn.sourceforge.net/svnroot/felix/felix/trunk By now we've weeded out the non-superhuman programmers, so ours knows to change the command to svn co https://felix.svn.sourceforge.net/svnroot/felix/felix/trunk felix so he doesn't get something called "trunk". He builds felix (./autogen.sh, that was too easy) and notices that his firewall setup makes some of the socket tests fail in an unclear manner. He intuits that the faio layer is not faithfully returning socket errors so he sets about to fix it. He cds into the promising looking "src" directory but soon deduces that editing the files there is akin to editing .o files and cds into "lpsrc". He sees some strangely named files and gives up. No! He takes heart and decides to consult the mailing list for help. Googling doesn't automatically take him there, so he manually follows the mailing list link off the wiki or even off felix.sf.net. It takes him to puke coloured sourceforge "felix-language" mailing list page, the one that says "python-powered", with the unbearably smug looking "gnu". There's no search feature there, but he can subscribe to the list or check the archive. Not being a complete devotée just yet, he follows the archive link first and gets: 500 - Internal Server Error. He makes a coffee and then tries again. It works, and there's a search box! He types in "lpsrc" and gets flooded with "felix-impl" svn commits! He sadly sifts few threads by clicking on the calendar but comes up with nothing. In the meantime, he ignores netiquette and skips the faq (it doesn't exist!) and posts his "how do I change code" question directly to [EMAIL PROTECTED] At this point sourceforge tells him very clearly in several ways that he can just fuck right off and mind his own business. At this point he really gives up, never to return. The real shame is that regardless of Mr PD's timezone, Max was probably awake when he wanted to post his question and would've replied within 5 minutes. A FAQ file could've explained in a few lines how to start modifying felix. The README contains nothing and CONTENTS hints at literate programming. INSTALL is out of date. Anyway, what I'm trying to say is that only one and a bit of the obstacles that Mr PD had anything to do with interscript, and doing away with it will not help the in the above scenario. Had he understood the lpsrc dir and instead wanted to know where to start fixing up the socket errs his experience would've been pretty much the same. In any case, the number of progammer's who "just know" about felix is zero, so tearing down interscript with all its benefits for me is totally unjustified. It's a shit sandwich, even for dyed in the wool flx developers (I can't generate commit msgs for some fucked up little piece of sf triviocracy), little wonder there are no developers. The method for getting felix, and then getting help with working on it, needs to be as streamlined as its build setup (./autogen.sh). So, how does one fix the webpage? > On a slightly less radical idea, what about putting together the first > felix application? We could copy the other scripting languages and put > together another web framework. It would certainly be interesting what > one could do with our fibres, threads, and type safety. It'd give us a > series of targets to meet, which might give new comers an idea on how > they could contribute. That would be a great thing to do if there were a way for people outside of this tiny circly to actually know about it! ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
