topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Tuesday March 19, 2024, 1:29 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - berwyn [ switch to compact view ]

Pages: [1]
1
Yep, as you say, atimes is indeed flaky -- as has been observed on the fabricate forum.  Also, as you say, atimes they aren't enabled by default on windows 7.  We really need somebody to implement an strace-like solution for windows.  It is quite possible using the EasyHooks library or other methods.  But it takes some work as several windows API calls need to be hooked: open/read/write, create process, and change directory.

For now, atimes fill our need, but at some point the pitfalls will probably get the better of us and we'll need to write the EasyHooks solution.  Or someone else will get there first.  It's a good, clean, hacker project.  If someone feels keen to follow this path, I'd be interested to hear from them.

2
Yep, there are no docs as thorough as the source ;)!

You're right that the shell command is handy, and probably warrants better documentation.  You can, of course, get docs on it without browsing the source with python's help command: help(shell).  But now that I look at it again, that tail doc sure is obscure.  It could do with improvement.

If you want to write up a suggested doc for me on shell(), I could see about getting it put onto the fabricate website.

3
Yes, I've tried SCons.  It looked good at first, but in the end, being so frustrated by not being able to do things with it easily, was what drove us to write fabricate.  But try it ... if you find that you are not frustrated by SCons in the end, I'd like to hear from you.

4
No, there is currently no way to parallelize the build.  There was quite a discussion on fabricate's google group on the subject, and I believe a reasonable solution was proposed.  You could ask there to see how far it got.

5
fabricate is a build tool that finds dependencies automatically for any language. It's small and just works. No hidden stuff behind your back. It was inspired by Bill McCloskey's "make" replacement, memoize, but fabricate works on Windows as well as Linux.

Features
  •     Never have to list dependencies.
  •     Never have to specify cleanup rules.
  •     The tool is a single Python file.
  •     It uses MD5 (not timestamps) to check inputs and outputs.
  •     You can learn it all in about 10 minutes.
  •     You can still read your build scripts 3 months later.

Show me an example!

Code: Python [Select]
  1. from fabricate import *
  2.  
  3. sources = ['program', 'util']
  4.  
  5. def build():
  6.     compile()
  7.     link()
  8.  
  9. def compile():
  10.     for source in sources:
  11.         run('gcc -c ' + source + '.c')
  12.  
  13. def link():
  14.     objects = ' '.join(s + '.o' for s in sources)
  15.     run('gcc -o program ' + objects)
  16.  
  17. def clean():
  18.     autoclean()
  19.  
  20. main()

Continued on google code ...

6
Yes, that is a hard one.  We already have it on our features list as "Support multiple developers for one project".

We have worked around this for now with our sub-project thing.  Essentially, you make separate projects for each sub-task and they can be pledged to individually (one developer per sub-task). See http://micropledge.c...elp/dev#sub-projects

However, for a proper solution, my thinking so far is that it requires measuring the effort of each developer - which can't be done by computer.  So the development team would need a team leader who was responsible for distributing funds.  This puts a lot of responsibility on him.  Probably too much.  maybe the sub-project way is the best after all, because it lets the users decide what effort is worth the most.

7
We do indeed have a democratic mechanism of determining when a project is done.
  • The developer releases and says "I'm, say, 85% done."  Then negotiation begins.
  • The pledgers vote if they want (a non-vote means they agree to the 85%)
  • If the pledgers' average vote is lower than 85%, say 50%, the developer can either accept payment for 50% and keep working
  • Or he can provide better evidence of 85% completion
  • Or he can put pressure back on the pledgers by stalling the project until they cave in or get more pledgers

This is described in more detail in our help at http://micropledge.com/help/dev#estimate.

8
The quote is making your head spin?  It's very simple: users need a target.  How long will a developer will take?

As for our fees, we didn't really intend them to be used as an advertising blurb like they have been here - they're more for an exhaustive reference.  Actually, the upload cap fee doesn't exist right now and we've now removed it from our help due to this post.  However, the other fees are very simple.  For most people they will come down to just one fee:
  • If you are a developer hoping to make commercial use of the software, we take a simple cut.  If you are doing open source software, it's free.

The only thing left is if you take your users' money & then quit the job, we'll take an annoyance fee and give it to the users you have annoyed.  As for the $20 Incubator, it is an optional add-on service so we don't mind charging.

Pages: [1]