by tzz on 1/11/17, 5:46 PM with 9 comments
by zo1 on 1/11/17, 5:52 PM
I'm still hoping to find a decent "SQL flavor" interpreter and/or translator. That would be a killer feature, allowing me to define "procs" in vanilla ANSI SQL, and translate them into whatever database's SQL format I need without worrying too-much about syntax and optimizing. Because you know, it's 2016, and I still need to know that fetching N rows of results from a table has multiple syntax forms depending on your chosen database and version.
by seanwilson on 1/11/17, 7:19 PM
by Jtsummers on 1/12/17, 5:47 PM
tup only rebuilds the parts that need to be rebuilt. The build files you produce are dependency trees, it can recognize when a node in the tree hasn't changed and won't trigger further actions. Consider: You modify the comments in your .c source file, correcting a typo from "alpabetical" to "alphabetical". There has been no code change. Make will, without additional configurations, build the .o file, and then rebuild everything else down the line to the final lib or exe. tup will recognize, by default, that the .o file is unaltered, and won't trigger any further action.
tup also has a monitoring system that I intended to port to OS X but got distracted on. It will watch the filesystem for changes so it doesn't need to walk the filetree to identify the change when you issue the build command. It'll already know exactly what has changed and be ready to issue the (near-)optimal instructions.
by itamarst on 1/11/17, 9:55 PM
- Eliot, a project of mine, is a logging system for Python that actually gives you a concept of causality: http://eliot.readthedocs.io/en/0.12.0/introduction.html
by cdvonstinkpot on 1/11/17, 10:26 PM