| 00:02:25 | Araq | the main.nim file, reactormonk |
| 00:06:11 | dom96 | Araq: I've found this: http://golang.org/doc/effective_go.html and I'm thinking we should finish our little Nimrod style guide ASAP :) |
| 00:08:02 | Araq | dom96: hu? |
| 00:08:13 | Araq | what is "our little nimrod style guide"? |
| 00:08:27 | dom96 | Araq: Remember the thing that we discussed over skype a while ago? |
| 00:08:51 | Araq | er *cough* of course ... |
| 00:09:48 | dom96 | yeah, the document describing Nimrod's conventions. |
| 00:10:26 | Araq | what about it? |
| 00:10:36 | Araq | how is that related to "effective go"? |
| 00:11:14 | dom96 | The page I linked describes Go's conventions. |
| 00:11:30 | Araq | btw is there such a thing like "effective go"? :P |
| 00:14:00 | Araq | alright, well, what's still missing with our document describing nimrod's conventions? |
| 00:16:17 | dom96 | Quite a lot of things |
| 00:16:24 | dom96 | But we don't have to do this now. |
| 00:16:30 | Araq | alright |
| 00:16:43 | dom96 | I just thought I would mention it because I stumbled upon that Go doc. |
| 00:36:20 | * | apriori_ quit (Quit: Konversation terminated!) |
| 02:35:12 | * | fowl quit (Ping timeout: 265 seconds) |
| 03:06:49 | * | fowl joined #nimrod |
| 03:26:39 | * | q66 quit (Quit: Quit) |
| 04:12:09 | * | AlexLibman joined #nimrod |
| 04:48:43 | AlexLibman | I just discovered Nimrod, and I love it so far! (Except the copyleft license, but that's a whole nother discussion.) |
| 04:49:47 | AlexLibman | Installed it on FreeBSD. Trying to compile Aporia. Had to edit /etc/nimrod.cfg to make sure lib gets set to "/usr/local/lib/nimrod", but I still get a build error: |
| 04:49:51 | AlexLibman | Aporia-master/utils.nim(58, 22) Error: undeclared identifier: 'PInfoBar' |
| 04:52:20 | AlexLibman | FreeBSD 9.1-RELEASE i386; gcc v4.2.1 20070831; nimrod v0.9.0 |
| 04:52:59 | fowl | AlexLibman: aporia usually requires bleeding-edge nimrod |
| 04:54:27 | fowl | hmm i thought there were downloads for older versions but im not seeing them |
| 04:55:16 | AlexLibman | It's OK, I'll use something SciTE like while I explore Nimrod 101 (probably over the weekend). |
| 04:55:48 | AlexLibman | At first glance, it seems exactly like what I've been hoping for for years. |
| 05:27:38 | reactormonk | Nimrod 101? What did I miss? |
| 06:21:23 | AlexLibman | BAK. You've missed nothing as far as I know. |
| 06:22:32 | AlexLibman | If you're unfamiliar with the idiom I've used, see http://en.wikipedia.org/wiki/101_(term) |
| 06:32:30 | AlexLibman | Whom would I contact about Nimrod license s/GPL/BSD/ possibilities? |
| 06:37:05 | fowl | AlexLibman: Araq, he'll probably be around in a few hours |
| 06:37:44 | AlexLibman | ok |
| 06:47:17 | * | apotheon joined #nimrod |
| 07:03:25 | * | FreeArtMan joined #nimrod |
| 07:34:18 | * | fowl is now known as fowl-zzz |
| 07:36:30 | reactormonk | var NTI842 = {size: 0, kind: 17, base: null, node: null, finalizer: null}; |
| 07:36:32 | reactormonk | var NTI103 = {size: 0,kind: 31,base: null,node: null,finalizer: null}; |
| 07:36:34 | reactormonk | how come? |
| 09:44:06 | * | Araq_ joined #nimrod |
| 09:47:30 | Araq_ | reactormonk: it's runtime type information (NTI = Nimrod type information) |
| 09:47:40 | Araq_ | welcome AlexLibman, apotheon |
| 09:47:50 | Araq_ | what's wrong with the license? |
| 09:48:18 | AlexLibman | Araq_: hi. Thank you for nimrod. |
| 09:49:36 | AlexLibman | Apotheon and I are big BSD fans, in large part for philosophical reasons described on http://copyfree.org/ |
| 09:50:30 | Araq_ | ugh, I have to read the logs to see your response ... bad connection here ... ;-) |
| 09:51:32 | AlexLibman | I'm trying to build a pure-copyfree-licensed software stack, and much progress has been made toward that end in recent years with FreeBSD switching to Clang and replacing various other GPL components. |
| 09:53:00 | AlexLibman | This isn't because we want to closed-source-fork anything, but we see GPL as hypocritical, redundant, antagonistic, and contrary to the spirit of genuine freedom. |
| 09:53:55 | AlexLibman | What is the nature of your connection problem? Would pasting my log buffer of this channel (which is very short) to pastebin help? |
| 09:54:06 | Araq_ | I never got that ;-) you can use GCC to develop commercial software (same with Nimrod) |
| 09:55:08 | AlexLibman | Yes, but still there are some restrictions associated with GPL, which really shouldn't be a factor when talking about free software. Free software shouldn't require a team of lawyers to understand what you can or cannot do. |
| 09:56:14 | AlexLibman | Philosophically, GPL is based on the idea that businesses are evil and that using copyright against them is a just cause. |
| 09:57:02 | Araq_ | don't worry about my connection problem, it simply means you'll have to wait a bit longer for my answers |
| 09:57:11 | AlexLibman | The copyfree philosophy sees FLOSS software as a free market phenomenon that doesn't require forcing people to share code, and those copyleft restrictions do far more harm than good. |
| 09:57:21 | AlexLibman | ok, no problem. |
| 09:58:39 | Araq_ | well I like people to give back their changes and so I picked the GPL |
| 09:58:46 | AlexLibman | As a developer, I want to specialize on a software stack that reflects my values, which are quite different than those that Richard Stallman had in mind when he popularized GPL. |
| 09:59:22 | AlexLibman | I really like nimrod and hope more people contribute to it, but I honestly do believe that GPL will do this project more harm than good. |
| 10:00:08 | AlexLibman | Look at the recent trends in software licensing, particularly among programming languages. All hot new languages that reach any success (Node.JS, Go, Haskell, Lua, etc) are copyfree. |
| 10:00:54 | AlexLibman | Many businesses avoid GPL, though for different reasons than I do. |
| 10:03:02 | Araq_ | you can try to convince me, but then you need to convince the other core devs too, so don't have too high hopes ;-) |
| 10:03:17 | AlexLibman | A lot of people would see a copyfree license as an advantage for Nimrod - and not just in the BSD community. More attention is what brings more code contributions. |
| 10:04:35 | AlexLibman | My interest in nimrod, its technical virtues aside, is based on the line in the FAQ: "If I receive enough requests with good arguments, I may change the license of Nimrod to the BSD license." |
| 10:04:45 | * | Araq_ quit (Read error: Connection timed out) |
| 10:05:18 | * | Araq_ joined #nimrod |
| 10:05:29 | Araq_ | argh ... |
| 10:05:56 | Araq_ | well, "If I receive enough requests with good arguments, I may change the license of Nimrod to the BSD license." <-- that's still true |
| 10:06:09 | AlexLibman | In case you missed it: |
| 10:06:22 | AlexLibman | any businesses avoid GPL, though for different reasons than I do. A lot of people would see a copyfree license as an advantage for Nimrod - and not just in the BSD community. More attention is what brings more code contributions. |
| 10:06:30 | AlexLibman | My interest in nimrod, its technical virtues aside, is based on the line in the FAQ: "If I receive enough requests with good arguments, I may change the license of Nimrod to the BSD license." |
| 10:06:42 | AlexLibman | oh, I see that you didn't miss it, OK |
| 10:06:55 | Araq_ | yeah, sorry, I read it, but I read it after my answer ... |
| 10:07:11 | Araq_ | oh well we need to continue this later |
| 10:07:22 | AlexLibman | ok, thank you for your time |
| 10:07:25 | Araq_ | however, for now only one guy complained about the license |
| 10:07:38 | Araq_ | because he missed you can develop commercial software with it |
| 10:08:07 | AlexLibman | I only found out about nimrod today. |
| 10:08:29 | Araq_ | and you know, something like "look at this cool patch, I would contribute if you had a decent license" is WAY more convincing than |
| 10:08:38 | Araq_ | "all the other langs do it" ;-) |
| 10:09:10 | AlexLibman | I mean there's a reason why all the other langs do it (and why Ruby just switched its license, etc). |
| 10:09:50 | AlexLibman | All other things being equal, GPL tends to stun a project's growth. |
| 10:09:56 | Araq_ | maybe ... but then what is the reason? apart from afraid companies? |
| 10:10:48 | AlexLibman | Of course there are many large old GPL projects that never get much competition, but in the most competitive software segments a copyfree license tends to be a competitive advantage. |
| 10:11:20 | AlexLibman | My arguments against GPL are ethical in nature. |
| 10:11:31 | AlexLibman | But there's a strong pragmatic basis to them as well. |
| 10:12:15 | AlexLibman | Pragmastic meaning that copyleft projects are ignored by a significant and growing fraction of developers, and not just businesses. |
| 10:13:55 | AlexLibman | Ethical meaning you shouldn't have to hold a gun to people's heads to get their code. |
| 10:14:17 | AlexLibman | Free software should be voluntary, with no lawyers required. |
| 10:16:49 | Araq_ | what if someone comes along and sells the compiler+aporia without noticing us? nobody knows about nimrod yet, so it should be easy to hide that fact |
| 10:17:31 | Araq_ | afaict with a BDS like license I can't sue him then |
| 10:17:39 | AlexLibman | You cannot hide evidence from the open Internet. Everyone will know of their plagiarism. |
| 10:18:17 | AlexLibman | Closed-source forks are rare, and they only make economic sense if the fork adds a lot of value on top of your code. It doesn't "steal" your code, it merely copies it. |
| 10:19:08 | AlexLibman | What is more likely to happen is some company will sponsor your project, like what EnterpriseDB is doing with PostgreSQL, or Apple with LLVM, etc. |
| 10:20:25 | AlexLibman | Sites like GitHub, Google, Archive.org, etc provide indisputable evidence of who did what first. |
| 10:21:57 | AlexLibman | And, even in the unlikely event that some unfriendly company makes a closed fork of Nimrod, Nimrod itself would still get some benefits: ideas for new features (from what that company added to their fork), attention, learners (who can switch to the free version later), etc. |
| 10:22:53 | Araq_ | alright, post that to the forum please |
| 10:23:20 | AlexLibman | OK, I (or someone else from ##copyfree) will probably do that in a day or two. |
| 10:23:36 | Araq_ | ok good |
| 10:24:06 | Araq_ | I have to go, see you later |
| 10:24:16 | * | Araq_ quit (Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121128204232]) |
| 10:24:20 | AlexLibman | Again, thank you very much for developing nimrod. I'm looking forward to learning it (although I won't use it in the long-term if it remains GPL). |
| 10:24:30 | AlexLibman | ... |
| 10:45:43 | * | q66 joined #nimrod |
| 11:29:42 | * | zahary joined #nimrod |
| 12:29:42 | * | apriori_ joined #nimrod |
| 13:49:04 | q66 | lol, AlexLibman is here? |
| 13:56:07 | AlexLibman | So is ccssnet from #Mises, apparently. Great minds think alike. ::rolleyes:: |
| 13:57:16 | AlexLibman | Wait, if you knew about Nimrod before me, why didn't you tell me on ##copyfree? It's awesome! |
| 13:58:18 | q66 | AlexLibman, dunno |
| 13:58:22 | q66 | i knew about it for a long time |
| 13:58:26 | q66 | even before i knew about Clay |
| 13:58:44 | ccssnet | ... |
| 13:58:49 | q66 | http://claylabs.com/clay/ |
| 13:58:54 | ccssnet | i was here before #mises |
| 13:58:58 | * | FreeArtMan quit (Read error: Operation timed out) |
| 13:59:00 | q66 | there I found Araq, from who i found about nimrod :P |
| 13:59:46 | AlexLibman | Wow, and I'm the first to nag about a license change? :P |
| 14:00:20 | ccssnet | im not reading all that backlog right now |
| 14:00:23 | ccssnet | bye now |
| 14:00:46 | AlexLibman | ccssnet: stay gold, ponyboy |
| 14:02:04 | q66 | AlexLibman, you mean about that it's gpl? |
| 14:02:38 | AlexLibman | I think of it as GPL with an asterisk. |
| 14:03:24 | q66 | tbh i don't quite care about a license of a compiler - as long as it doesn't "infect" projects using it |
| 14:03:32 | q66 | i don't like gpl myself though |
| 14:03:40 | q66 | and i wouldn't ever license anything my own under it :P |
| 14:03:59 | AlexLibman | I normally press Ctrl-W (close tab) on a new software project 2 nanoseconds after I see the letters G, P, and L next to each-other. But that gave me enough time to see the ray of hope in the Nimrod FAQ page. |
| 14:04:11 | AlexLibman | "If I receive enough requests with good arguments, I may change the license of Nimrod to the BSD license." |
| 14:04:43 | q66 | my main issue with GPL is its viral character |
| 14:04:48 | q66 | which doesn't quite apply in this case |
| 14:05:04 | AlexLibman | Nothing with GPL goes on my resume. |
| 14:05:16 | q66 | I tend to use MIT for my own stuff |
| 14:21:44 | AlexLibman | Clay language doesn't seem very likable, not in the same universe of awesomeness as nimrod. |
| 14:33:49 | dom96 | hello AlexLibman. It's nice to hear your enthusiasm towards Nimrod :) |
| 14:34:29 | AlexLibman | hi |
| 14:51:53 | q66 | AlexLibman, how well aware are you of Rust? |
| 14:52:32 | AlexLibman | Somewhat. Doesn't run on FreeBSD i386 yet. |
| 14:54:53 | AlexLibman | Nimrod has a better syntax (coming from a Python fan), and will probably be closer to the fast-as-C ideal. |
| 14:59:21 | AlexLibman | I like the "python with types" syntax, though nimrod deviates from Python far more than it has to. Do you really need "var"? Why countup/down instead of range? Etc. |
| 15:02:03 | AlexLibman | I'm a big fan of shaving off keystrokes whenever possible. :P |
| 15:02:11 | AlexLibman | All of those are trivial nitpicks of course. |
| 15:03:56 | dom96 | You can simply use `..` instead of countup. |
| 15:04:07 | dom96 | for i in 0..10: echo i |
| 15:07:38 | AlexLibman | oh, good |
| 15:10:14 | AlexLibman | Python's "members public by default" seems better than Nimrod's "members private by default" (without *) |
| 15:13:05 | q66 | AlexLibman, what |
| 15:13:12 | q66 | it has been working on freebsd just fine for months |
| 15:13:36 | q66 | http://www.freshports.org/lang/rust/ it even has a port |
| 15:13:43 | q66 | but there is 0.5 out already |
| 15:13:57 | q66 | i guess it'll just take them some time to update |
| 15:21:52 | AlexLibman | It doesn't work on 32-bit (i386) yet. |
| 15:22:24 | AlexLibman | Plus rust's syntax is inferior. |
| 15:24:12 | AlexLibman | Maybe I'm just biased for Nimrod because I was a Python guy in "the good old days", and also because my crack fantacies about inventing my own language always had it compile to C. |
| 15:35:17 | apriori_ | AlexLibman: a freebsd fellow? :P |
| 15:37:46 | AlexLibman | Yup |
| 15:38:25 | AlexLibman | Well, a user of FreeBSD. Don't have a fellowship tattoo or anything... :P |
| 15:39:15 | apriori_ | hehe |
| 15:39:18 | AlexLibman | Hmm, a puffy tattoo would be better. But OpenBSD is behind, so I use FreeBSD for now. |
| 15:39:55 | apriori_ | well, OpenBSD seems to have another focus.. so that is to be expected. |
| 15:40:40 | AlexLibman | Yeah. I just like pufferfish. (If talking about mascot tattoos.) |
| 15:40:47 | apriori_ | and I guess.. most of us had the "c-pythonic" dream, which lead us here :) |
| 15:40:59 | apotheon | Araq: Thanks (belatedly) for the welcome. |
| 15:41:02 | AlexLibman | Does nimrod have a mascot? |
| 15:41:25 | apriori_ | ohm, I doubt that |
| 15:41:35 | AlexLibman | A funny looking ancient king holding a snake as a staff? |
| 15:41:43 | apriori_ | lol |
| 15:41:51 | AlexLibman | (snake == python syntax) |
| 15:42:50 | AlexLibman | The name/word Nimrod makes me think of Elmer Fudd. I'm a philistine... |
| 15:46:26 | AlexLibman | "Be vewwy vewwy quiet, I'm huntin' Moziwwas, bwwaahahaha" |
| 15:47:28 | AlexLibman | Or maybe just a snake with jet engines attached... |
| 15:49:04 | apotheon | AlexLibman: I'm pretty sure q66 mentioned the language Nimrod in ##copyfree, and that I looked it up and saw that it was GPLed, when we were talking about potentials for non-C system languages a while back. |
| 15:49:35 | AlexLibman | Yeah, I've put 2 and 2 together when q66 joined this channel. |
| 15:49:50 | apotheon | AlexLibman: Thanks to the fact Nimrod was GPLed, and several others were not, I basically just deprioritized Nimrod to the point where I forgot about it. I had no idea there was any potential for a license change at the time. |
| 15:49:53 | AlexLibman | I wasn't in ##copyfree when it was discussed there though. |
| 15:51:10 | AlexLibman | With both Go and Rust refusing to compile on i386, and Nimrod's Pythonic syntax, it's my fav so far. Except the current license of course. |
| 15:52:09 | q66 | rust works just fine on i386 |
| 15:52:26 | AlexLibman | q66: i386 FreeBSD? |
| 15:52:30 | q66 | sure |
| 15:52:49 | apotheon | q66: I kinda consider languages whose only implementations are copyleft dead ends. If I grow to like a language enough to learn it and use it semi-regularly, I'd like to be able to contribute to it some day, and if it has or acquires a self-hosting implementation that'd make it easier to contribute. If it's copyleft though, and I contribute to it, I feel like I'm throwing code into a black hole |
| 15:52:52 | q66 | though, why the hell would you be using i386 FreeBSD? |
| 15:52:52 | AlexLibman | (Plus Go is much slower than C. Not sure what Rust's benchmarks are.) |
| 15:52:55 | apotheon | because I can't then use what I've learned from the codebase directly to improve other projects that don't use a copyleft license. |
| 15:53:06 | AlexLibman | Because I'm a miser? |
| 15:53:26 | apotheon | q66: I guess if you don't think you'll ever contribute to a language implementation project (outside of creating your own implementation, I suppose), not caring about the license of the compiler/interpreter/whatever makes sense. |
| 15:53:28 | AlexLibman | ... and have a 32-bit pentium4 |
| 15:54:08 | AlexLibman | Oh ye of little copyfree zealotry... |
| 15:54:15 | apotheon | q66: One of my laptops is a multicore x86. I still have a use for the i386 install. |
| 15:54:28 | apotheon | q66: Obviously, it is not my primary laptop. |
| 15:54:49 | apotheon | AlexLibman: I think you're the only actual copyfree *zealot* that I know. |
| 15:55:01 | AlexLibman | Well, /usr/ports/lang/{go,rust}/Makefile have ONLY_FOR_ARCHS=amd64 |
| 15:55:14 | AlexLibman | I'm using pidgin right now. :P |
| 15:55:16 | q66 | that's odd |
| 15:55:25 | q66 | why aren't you using 64bit system anyway |
| 15:55:41 | AlexLibman | q66: because you didn't get me one for christmas? |
| 15:55:59 | AlexLibman | I'm not buying a new computer until this one turns to dust. |
| 15:56:04 | apotheon | q66: I think you missed the part where he's using an old computer because new computers cost money. |
| 15:56:24 | apriori_ | AlexLibman: if you take that literally you wont ever see i turning to dust :P |
| 15:56:26 | q66 | i thought like everyone had a 64bit cpu these days :P |
| 15:56:49 | q66 | AlexLibman, i'd donate you one, but shipping is a bitch :P |
| 15:57:10 | apotheon | AlexLibman: I'd suggest you go to LUG meetings, make friends, and join the local LUG mailing list so that when someone's giving away a newer computer than yours for free you can get an upgrade, but knowing you it's probably a bad idea to suggest you join mailing lists and show up to meetings for people who think Linux licensing is peachy. |
| 15:57:22 | q66 | i have an excess supply of useless 64bit CPUs and mobos and everything |
| 15:57:51 | AlexLibman | I had $1500 in my wallet a couple weeks ago. |
| 15:57:56 | apotheon | q66: AlexLibman is even too far from *me* to give him one of my unused computers. |
| 15:58:03 | AlexLibman | If I wasnted a new computer, I'd have one. |
| 15:58:12 | apotheon | What'd you do with all that money? |
| 15:58:25 | AlexLibman | The only difference would be that some HORRRRRABLY designed Web-sites would be a bit slower. |
| 15:58:27 | q66 | you can get a 64bit computer (used) for like $100 |
| 15:58:35 | AlexLibman | apotheon: hookers and blow. |
| 15:58:48 | apotheon | ah, fun |
| 15:58:52 | AlexLibman | Actually, I took a couple months off work. |
| 15:59:02 | apotheon | gotcha |
| 16:00:02 | AlexLibman | s/slower/faster/ |
| 16:00:27 | AlexLibman | (Any more of these crazy typos and I'll suspect I have a brain tumor.) |
| 16:00:35 | apotheon | I read something recently (by the same guy who famously wrote that PHP is a "fractal of bad design") that Rust was basically what we'd get if someone were to redesign C, today, and the developer only knew Haskell. |
| 16:00:45 | apotheon | . . . something like that, anyway. |
| 16:01:12 | q66 | lol |
| 16:01:19 | q66 | well, rust incorporates quite some type theory stuff |
| 16:01:23 | q66 | but that's what makes it awesome |
| 16:01:33 | q66 | it's memory safe, yet system level |
| 16:01:52 | AlexLibman | I'd feel weird using a language from a foundation that makes a copyleft Web browser. |
| 16:02:02 | apotheon | Yeah, I thought that description of Rust made it seem very enticing. |
| 16:02:18 | q66 | AlexLibman, it's a completely different team than the firefox one |
| 16:03:00 | AlexLibman | We need Karl Marx. |
| 16:03:04 | AlexLibman | Err, benchmarks. |
| 16:03:05 | apotheon | The Rust team ended up making it dual-licensed MIT/X11 and Apache License 2.0, I think, because some jackass at the Mozilla Foundation keeps telling everyone they should license their stuff either MPA or AL2. |
| 16:03:06 | Zor | also, uh, rust is MIT and Apache 2.0 |
| 16:03:18 | AlexLibman | definitely a brain tumor... |
| 16:03:21 | apotheon | . . . which is how Servo ended up going AL2, I think. |
| 16:03:47 | q66 | apotheon, rust is dual licensed. |
| 16:03:53 | q66 | so no problem there |
| 16:03:54 | apotheon | Zor: Yes -- the MIT/X11 part is the good part. |
| 16:04:07 | apotheon | q66: I know. It's just silly that there's this extra license tumor attached to it. |
| 16:04:15 | Zor | I really don't know what's so evil about Apache 2.0 |
| 16:04:23 | q66 | apparently they introduced it because of the patent clauses |
| 16:04:25 | AlexLibman | We need rust vs nimrod benchmarks. |
| 16:04:26 | q66 | though |
| 16:04:27 | q66 | dunno |
| 16:04:45 | q66 | AlexLibman, rust is built on llvm, so it should be rather fast |
| 16:04:52 | apotheon | Zor: Read the Apache License section of http://copyfree.org/rejected/ then check the descriptions of relevant clause types on http://copyfree.org/standard/ for illumination. |
| 16:05:16 | q66 | nimrod as far as I know emits C, which is another working approach |
| 16:05:18 | AlexLibman | Actually, Nimrod should be faster, because you can choose the compiler. |
| 16:05:27 | q66 | that means the performance of nimrod will depend on the C compiler you choose |
| 16:05:33 | Zor | apotheon: I'm aware of those and I don't particularly care / consider it an issue |
| 16:05:35 | q66 | AlexLibman, if you compile with clang it should be comparable. |
| 16:05:41 | apotheon | Zor: You could also check out http://univacc.net/?page=license_simplicity_1 for some more general information about the desirability of license simplicity (which is something AL2 lacks). |
| 16:06:05 | apotheon | Zor: Well . . . if you like overly complex bureaucratic license restrictions, that's fine -- I don't. |
| 16:06:10 | AlexLibman | Or you can compile it with a product from OurCompilerIsSoFastWeCanSellItForMoney Inc. |
| 16:06:13 | Zor | apotheon: the chances of those restrictions causing problems in the real world are practically nil |
| 16:06:16 | q66 | my problem with APL2 is that it's tl;dr |
| 16:06:30 | apotheon | q66: Promote the Tesla COIL as a way to get people off the AL2 sauce. |
| 16:07:08 | q66 | Zor, the apache license 2 is verbose as fuck to me |
| 16:07:17 | q66 | it's long, yet it says nothing |
| 16:07:24 | AlexLibman | I only accept copyfree licenes that are 256 words or less. |
| 16:07:31 | q66 | good for you |
| 16:07:40 | apotheon | q66: "tl;dr" is the complexity problem, basically |
| 16:08:01 | Zor | meh. it isn't GPL-long, so I'm not complaining |
| 16:08:06 | q66 | why not just take MIT and append a patent clause to it, if you want it. |
| 16:08:26 | apotheon | AlexLibman: I'll hold my nose and "accept" a copyfree license over 256 words, but I won't choose to *use* such a license. |
| 16:08:37 | AlexLibman | (I can only afford an 8-bit lawyer.) |
| 16:08:55 | apriori_ | AlexLibman: what about this one? http://www.wtfpl.net/about/ |
| 16:09:08 | q66 | apotheon, too long :) |
| 16:09:13 | q66 | err |
| 16:09:14 | q66 | apriori |
| 16:09:16 | q66 | _ |
| 16:09:16 | apotheon | q66: Have a look at Tesla COIL, and don't worry about attaching a patent clause to the MIT/X11 License. |
| 16:09:37 | AlexLibman | 73 words |
| 16:09:41 | apotheon | Is that supposed to be a cursor? |
| 16:09:52 | apotheon | AlexLibman: WTFPL has . . . issues. |
| 16:10:21 | apotheon | They're nowhere near as big as the issues with the GPL, of course. |
| 16:10:31 | Zor | q66: http://www.tldrlegal.com/license/apache-license-2.0-(apache-2.0) |
| 16:10:44 | q66 | most licenses are BS |
| 16:10:46 | Zor | q66: this site is neat if you can't be bothered to read a license in full |
| 16:11:01 | q66 | all this licensing bullshit |
| 16:11:02 | q66 | i hate it |
| 16:11:06 | Zor | (<insert obligatory IANAL stuff here>) |
| 16:11:13 | apotheon | If you're using the WTFPL, though, you might as well use the CTL instead: http://copyfree.org/licenses/ctl/license.txt |
| 16:11:14 | q66 | i just wanna fucking code :P |
| 16:11:16 | apotheon | seven words |
| 16:11:19 | q66 | not mess with legal problems |
| 16:11:31 | apotheon | q66: That's basically the complexity problem. |
| 16:11:50 | apotheon | There are two options to solve that -- use simple, copyfree licenses, or pirate the stuff with longer licenses. |
| 16:11:51 | AlexLibman | http://mirrors.rit.edu/gentoo/snapshots/portage-latest.tar.xz contains all known licenses for easy `wc`ing |
| 16:11:56 | apotheon | s/pirate/"pirate"/ |
| 16:12:06 | q66 | the problem is, lawyers and all the other legal fucks are doing everything against making shit simple |
| 16:12:12 | apotheon | xz? |
| 16:12:30 | apotheon | q66: Of course. It's just job security. |
| 16:12:32 | AlexLibman | (((Is this channel OK with so much offtopic chat?))) |
| 16:12:39 | apotheon | I was wondering that myself. |
| 16:12:52 | AlexLibman | apotheon: um, yes, txz is the only civilized standard these days. |
| 16:12:53 | q66 | AlexLibman, well, there is no other chat going on. |
| 16:12:55 | q66 | so I guess that's fine |
| 16:13:21 | apriori_ | AlexLibman: as long as there is nothing on topic simultaneously :P |
| 16:13:37 | apotheon | AlexLibman: Why is it the only "civilized" option? |
| 16:13:39 | AlexLibman | Well, did you see the log of my chat with Araq_? |
| 16:13:44 | apriori_ | although.. perhaps Araq might not like having to skip all that in the logs ^^ |
| 16:14:00 | q66 | apotheon, what's worse, when you make a license simple, some legaltard comes and finds 150 "holes" in your text. |
| 16:14:04 | apriori_ | AlexLibman: no |
| 16:14:06 | q66 | what a bullshit |
| 16:14:27 | apotheon | q66: There are far more holes in longer licenses. It's like software that way. |
| 16:14:51 | AlexLibman | Civilized because xz is a part of the base system, and offers tighter binary compression than the alternatives. Test is better with ppm though. |
| 16:15:06 | AlexLibman | s/Test/Text/ |
| 16:15:08 | apotheon | The number of people who don't realize CC-BY has a technology restriction clause is kinda shocking. |
| 16:15:31 | apotheon | . . . but then, CC has tended to obfuscate that fact. For years, the summary of the license didn't even mention it. |
| 16:16:04 | AlexLibman | (The "did you see the log of my chat with Araq_" question was addressed to q66 && apotheon.) |
| 16:16:30 | apotheon | I haven't yet, but I'm planning to read it in a few minutes. |
| 16:16:54 | AlexLibman | Basically he wants it brought up on the forum. |
| 16:17:07 | q66 | Zor, btw, I find the "state changes" part in APL somewhat problematic |
| 16:17:29 | Zor | q66: it's good for commercial open source projects imo |
| 16:17:31 | * | apriori_ quit (Remote host closed the connection) |
| 16:17:36 | q66 | it says "significant changes" |
| 16:17:40 | q66 | how do you define significant change? |
| 16:17:50 | Zor | changes in semantics |
| 16:17:53 | Zor | most likely |
| 16:17:57 | q66 | does that mean you have to mark every change in the sourcecode in your fork? |
| 16:18:00 | q66 | that's weird |
| 16:18:00 | apotheon | AlexLibman: Hm. Not much discussion before I signed in, I see. |
| 16:18:02 | q66 | it's vague |
| 16:18:32 | q66 | it could mean you have to keep a strictly marked line between changed parts and original parts |
| 16:18:36 | AlexLibman | http://en.wikipedia.org/wiki/Nimrod_(disambiguation)#Computing doesn't mention it |
| 16:18:37 | q66 | which is very inconvenient |
| 16:18:38 | apotheon | Zor: You define "significant" however the lawyers convince the judge to define it when they sue you. |
| 16:19:03 | q66 | Zor, see, the "most likely" word is the key |
| 16:19:07 | q66 | it's vague |
| 16:19:08 | Zor | I see significant nowhere in the license text actually |
| 16:19:14 | q66 | and a lawyer will find another 150 holes in that |
| 16:19:14 | Zor | so uh ... |
| 16:19:24 | q66 | well, the description says that. |
| 16:19:27 | q66 | the text is about as vague |
| 16:19:30 | q66 | just more wording |
| 16:19:47 | q66 | that's why i said "it's long and says nothing" |
| 16:19:54 | apotheon | q66: Actually . . I don't see "significant" either. |
| 16:20:02 | apotheon | Oh, you're talking about the tl;dr summary of the license. |
| 16:20:07 | q66 | yes |
| 16:20:13 | apotheon | Those things are useless. |
| 16:20:21 | Zor | that's just a vague (bad) term tldrlegal uses |
| 16:20:21 | apotheon | qv Creative Commons |
| 16:20:22 | q66 | the text has similar statements, but longer wording |
| 16:20:51 | Zor | You must cause any modified files to carry prominent notices stating that You changed the files |
| 16:20:55 | Zor | ok so it's pretty clear |
| 16:20:58 | apotheon | AlexLibman: I'm not a fan of web forum interfaces, by the way. |
| 16:21:30 | q66 | Zor, it says "notices" |
| 16:21:34 | q66 | which implies multiple notices |
| 16:21:47 | q66 | which implies explicit marking of the changed sourcecode parts |
| 16:21:53 | q66 | with singular "notice" it'd be clear |
| 16:22:01 | dom96 | AlexLibman: The wikipedia article we used to have got deleted due to the lack of "significant coverage" |
| 16:22:06 | q66 | oh, context |
| 16:22:07 | q66 | sorry :P |
| 16:23:09 | AlexLibman | dom96: sad to hear that. |
| 16:23:34 | dom96 | AlexLibman: Yeah, I actually found out about Nimrod through wikipedia. |
| 16:23:37 | apotheon | One problem with the bookkeeping clause in AL2 is that it implies every single person who modifies a file has to add a "prominent" notice about having changed it. After fifty people do so, it's going to have a pile of ugly-ass "prominent" notices at the top of the file. |
| 16:23:51 | apotheon | . . . unless people violate the license terms. |
| 16:25:05 | apotheon | Well . . . Nimrod would probably get mentioned more by members of the copyfree community (including a writer for TechRepublic) if it was distributed under the terms of a copyfree license. Ahem. |
| 16:25:36 | apotheon | That'd help with "significant coverage" -- right? |
| 16:27:33 | AlexLibman | Even if the article is deleted, it should probably still at least get a line in that disambig page... |
| 16:28:26 | AlexLibman | Do licenses require any code comments to be valid? |
| 16:28:46 | AlexLibman | This is why I prefer public domain. No wasted space in code files. |
| 16:29:07 | apotheon | Public Domain is broken across jurisdictions. |
| 16:29:14 | apotheon | I wish it wasn't. |
| 16:29:19 | AlexLibman | Not my problem. |
| 16:29:33 | apotheon | . . . |
| 16:29:50 | AlexLibman | Well, OK, I'd give people MIT licenses upon requires. |
| 16:30:02 | AlexLibman | s/requires/request/ |
| 16:30:12 | AlexLibman | I think my brain tumor needs sleep... |
| 16:30:43 | apotheon | AlexLibman: Go with OWL -- it's not limited to software uses. |
| 16:30:47 | dom96 | It would definitely help with "significant coverage" and an article in the TechRepublic... that would be awesome. |
| 16:31:26 | AlexLibman | OWL has one major disadvantage. |
| 16:31:47 | * | AlexLibman falls asleep. |
| 16:31:49 | apotheon | I used to write for TR too, actually, but some corporate bureaucratic shenanigans by CBS (after it bought TR's previous "parent" company) rendered me ineligible to write for TR because I wouldn't give them private information about my clients. |
| 16:31:59 | apotheon | heh |
| 16:32:08 | apotheon | I think AlexLibman is not a nightOWL. |
| 16:32:18 | apotheon | har har |
| 16:32:53 | AlexLibman | I'm too much of a night OWL. 11:32am here |
| 16:33:03 | apotheon | "Night" is whenever you sleep. |
| 16:33:05 | apotheon | g'night |
| 16:34:10 | dom96 | Don't go to sleep just yet, Araq will be back soon. |
| 16:36:23 | AlexLibman | (No problem with OWL. Just a lame attempt at a "suspenseful jab followed by ::falls asleep::" joke.) |
| 16:37:17 | apotheon | I think that whenever I get a character-tracker project of mine to a level of completion worth sharing I'll use the COIL for it. |
| 17:04:44 | NimBot_ | nimrod-code/Aporia f4bc02a Dominik Picheta [+0 ±1 -0]: Fixed #26 |
| 17:44:26 | * | FreeArtMan joined #nimrod |
| 17:57:48 | reactormonk | Araq, the point was why the formatting for the two lines is different... |
| 17:59:50 | Araq | reactormonk: I've no idea |
| 18:01:43 | Araq | AlexLibman: Nimrod's syntax is also heavily inspired by modula 3/delphi, that's why it's not that python-like |
| 18:01:56 | AlexLibman | ok |
| 18:02:05 | Araq | and IMO 'var' vs. 'let' is a nice distinction for readability |
| 18:02:34 | Araq | plus Python's scoping rules are fucked up due to the implict 'var' |
| 18:03:10 | Araq | (python had to introduce a nonlocal keyword) |
| 18:04:10 | * | FreeArtMan quit (Ping timeout: 265 seconds) |
| 18:04:50 | apotheon | Python's scoping is a little wacky in general. |
| 18:05:11 | apotheon | I seem to recall hearing they finally fixed the "lexical for some variables but not for others" thing. |
| 18:05:41 | Araq | "global" itself is annoying in scripts |
| 18:06:03 | AlexLibman | apotheon: Web forum interfaces don't require fandom. You're better than I am at saying what should be said. Lead, O fearless copyfree leader, lead! :P |
| 18:06:11 | apotheon | Araq: I read some backlog and saw that you had mentioned something about people highjacking code for closed source projects, the original developers thus not getting credit. |
| 18:07:24 | apotheon | Araq: What I've seen tends to run the opposite way. When your license says "just include the license", you tend to get credited in at least some minor way. When it demands a lot of things redistributors don't like, they sometimes just rip off the code, distribute only binaries, and refuse to give credit where it's due, because they're trying to avoid having to abide by the restrictive terms of |
| 18:07:30 | apotheon | the license. |
| 18:08:35 | apotheon | Araq: I tend to feel, for my own purposes, that getting attribution is more important than stopping people who don't want to share their improvements from using my code. If they use it and give me credit, great -- and if they don't want to contribute their changes back to the core project, they deserve the pain of having to constantly update a fork that tracks the original. |
| 18:09:33 | AlexLibman | Not giving credit is impossible. Oh look, a proprietary language that looks near-identical to this open source language, and the implementation looks similar too. |
| 18:09:34 | AlexLibman | They'd have to be braindead-stupid to expect to get away with it (and braindead stupid people probably won't be able to add much value to the free codebase anyway). |
| 18:10:01 | apotheon | In the case of a language implementation . . . yeah, there's some truth in that. |
| 18:10:40 | apotheon | I was speaking more of the general case of software licensing, where more general concepts like "plays DVDs" don't necessarily imply you're getting your ideas from another developer. |
| 18:11:43 | apotheon | I guess the upshot is that where language implementations are involved the possibility of successfully failing to give credit where it's due is even slimmer. |
| 18:11:52 | Araq | I'm not religious about the license; but it's not about "they don't give me credit", it's about the possibilty to sue them |
| 18:11:53 | apotheon | hmm, "successfully failing" |
| 18:11:59 | apotheon | I could probably have phrased that better. |
| 18:12:08 | apotheon | Araq: Why do you want to sue people? |
| 18:12:26 | Araq | because I can ;-) |
| 18:12:32 | apotheon | That's a terrible idea. |
| 18:12:37 | AlexLibman | Can Guido van Rossum sue you? :P |
| 18:12:37 | * | Araq 's family is full of lawyers |
| 18:13:04 | AlexLibman | I think he might have a patent on the tab key... |
| 18:13:12 | apotheon | har |
| 18:13:44 | apotheon | Araq: Well . . . if you want excuses to sue people, I guess I have no argument you'd like. |
| 18:14:03 | * | apotheon goes back to looking at non-litigious Rust. |
| 18:14:24 | Araq | hey, if someone manages to make money with it ... I like my share in it |
| 18:15:22 | AlexLibman | Benchmark test #1: is Rust faster at attaining i386 FreeBSD support than Nimrod is at relicensing. Ready, set, golang! |
| 18:15:49 | apotheon | Do you benefit more from widespread knowledge of your programming skills, or from the knowledge that if someone's ever stupid enough to get caught you might be able to sue someone? |
| 18:16:00 | apotheon | (har golang) |
| 18:17:03 | Araq | however, since I'm implementing 'eval' the compiler's license needs to change anyway, so you simply have to be patient |
| 18:17:23 | apotheon | ah |
| 18:17:23 | * | AlexLibman has insomnia - and counting perl camels falling off a cliff isn't helping. |
| 18:17:35 | apotheon | Araq: What license are you thinking of using? |
| 18:17:35 | * | rking quit (Quit: Upgrading weechat) |
| 18:17:53 | * | rking joined #nimrod |
| 18:18:43 | Araq | that said, I consider "make it free or we will use Rust" not exactly a good means to accomplish your goal |
| 18:18:53 | AlexLibman | I support an idea I call "time-limited copyleft" (as an alternative to all-eternity copyleft). As long as I know it will be rational and kosher in the long run, I can wait. |
| 18:19:10 | apotheon | Araq: What's my goal, then? |
| 18:19:43 | apotheon | I'm just looking for languages that suit my needs. One of those needs is it being a language to whose implementation I might eventually want to contribute. |
| 18:20:32 | apotheon | There are excellent reasons to not throw code through a one-way licensing valve, and as such I'm unlikely to contribute to a language whose sole implementation has such a licensing valve attached to it. |
| 18:20:32 | * | FreeArtMan joined #nimrod |
| 18:21:06 | apotheon | s/a licensing/a one-way licensing/ |
| 18:21:53 | apotheon | I said something more comprehensive about why I care about language implementation licenses to q66 earlier, in here, if you care enough to check the scrollback. |
| 18:23:32 | Araq | apotheon: I don't know yet which license to use; maybe BSD |
| 18:24:21 | apotheon | The two-clause Simplified BSD License is a nice one (also known as the FreeBSD License). |
| 18:25:12 | apotheon | Araq: Is there any chance I can get you to talk to me before you settle on a license if someone's trying to convince you to go with the Apache License 2.0? There are issues with that license that most people never notice, and there are alternatives to that license for the single biggest reason people tend to choose it. |
| 18:25:50 | Araq | apotheon: sure why not |
| 18:26:16 | Araq | your chance was better before you guys mentioned Karl Marx though :P |
| 18:26:29 | apotheon | I didn't mention Marx. What's this about Marx? |
| 18:26:40 | apotheon | Araq: Are you a capitalist pig? |
| 18:26:46 | q66 | :D |
| 18:26:46 | AlexLibman | I made a pun about bench-marx |
| 18:26:54 | q66 | yep, only AlexLibman mentioned |
| 18:27:02 | apotheon | (pretend I'm smiling and making joking elbow-nudges when I say "capitalist pig") |
| 18:27:04 | Araq | alright, good |
| 18:27:25 | apotheon | Araq: What's your general socioeconomic and political view on the matter? Inquiring minds want to know. |
| 18:28:07 | apotheon | (if you don't mind discussing it) |
| 18:28:09 | * | AlexLibman is an individualist / pro-capitalist / rationalist / futurist / sonofabitch. |
| 18:28:39 | * | bloouup joined #nimrod |
| 18:29:03 | apotheon | Araq: It's also worth noting that AlexLibman and I don't necessarily agree on everything, though it seems his early comments after I joined the channel might give the impression we do. |
| 18:29:33 | Araq | apotheon: I noticed |
| 18:29:51 | AlexLibman | Even I don't agree with AlexLibman on everything... |
| 18:30:01 | Araq | and no, I don't really want to discuss my political opinions here ;-) |
| 18:30:04 | apotheon | AlexLibman: That's reasonable. |
| 18:30:08 | apotheon | Araq: Okay. |
| 18:30:56 | dom96 | apotheon: AlexLibman: What kinds of projects are you guys thinking of creating using Nimrod? |
| 18:31:44 | Araq | welcome bloouup |
| 18:31:49 | AlexLibman | A few small tools at first, rewriting things like youtube-dl, etc - to clean up my "pure copyfree stack". |
| 18:31:54 | bloouup | Hi |
| 18:32:10 | apotheon | I'd like to work on binary executable utility programs in a language less plagued by dangerous fiddly detail than C; I'd like a systems language easier on me than C and C++; et cetera. |
| 18:32:15 | AlexLibman | Then server-side components for Web apps. |
| 18:32:58 | AlexLibman | A libtorrent wrapper to then make a BT client with an HTML5 interface. Stuff like that. |
| 18:33:05 | apotheon | At the moment, Rust and Nimrod look like the best contenders, considering there are areas where Haskell and OCaml are less well-suited. |
| 18:33:32 | AlexLibman | I'm too dysfunctional for functional programming. |
| 18:33:49 | apotheon | I'm not a huge fan of things like "manually" null-terminated strings and so on. |
| 18:34:02 | AlexLibman | A Web proxy server with a PostgreSQL backend and a zillion features. |
| 18:34:14 | AlexLibman | s/proxy/cache proxy/ |
| 18:34:14 | apotheon | bloouup: hi |
| 18:35:11 | AlexLibman | ... gradually evolving into a search engine |
| 18:35:38 | apotheon | One reason to use C is for the security benefits of fine detail memory management. One of the reasons to not use C is for the security detriments of the way it provides facilities for memory management. It looks like Nimrod and Rust provide the kind of "best of both worlds" I'd like for projects like that. |
| 18:35:45 | dom96 | Those projects sound quite fun. |
| 18:35:59 | AlexLibman | I'm a one-language kinda guy, or at least one language per paradigm. CoffeeScript/JavaScript for UI - little choice when it comes to that. |
| 18:36:16 | Araq | hey nimrod compiles to JS ... |
| 18:36:21 | apotheon | wow |
| 18:36:25 | AlexLibman | WOW |
| 18:36:27 | apotheon | I missed that detail. |
| 18:36:34 | AlexLibman | That would have been my dream feature! |
| 18:36:39 | apotheon | Oh, wait -- LLVM? |
| 18:36:41 | Araq | though it's still buggy ;-) |
| 18:37:09 | apotheon | I know that there's an LLVM project that provides the last step in compiling from C to JavaScript. I guess if Nimrod compiles to C, that's entirely reasonable. |
| 18:37:20 | reactormonk | apotheon, nimrod js |
| 18:37:27 | apotheon | hmm |
| 18:37:38 | Araq | yeah but we have our own code generator that generates JS |
| 18:37:47 | Araq | with much less overhead |
| 18:38:05 | apotheon | Ah, I see that now. |
| 18:38:08 | apotheon | http://nimrod-code.org/nimrodc.html |
| 18:38:12 | apotheon | There's a table. |
| 18:38:19 | AlexLibman | ... and it could also target Dart / TypeScript, since it already has types ... |
| 18:38:43 | Araq | true |
| 18:38:47 | apotheon | gah, TypeScript looks like pain |
| 18:39:17 | AlexLibman | It would be faster than JavaScript. |
| 18:39:39 | q66 | ew, dart |
| 18:40:03 | q66 | if google really proved anything, then it's that they can't make languages |
| 18:40:05 | apotheon | An interesting side-effect of ECMAScript support is that it should be kinda trivial to be able to basically create Flash animations in Nimrod. ActionScript is an ECMAScript derivative. |
| 18:40:23 | apotheon | q66: I haven't looked much at Dart. What's wrong with it? |
| 18:40:31 | AlexLibman | CoffeeScript with static typing that also compiles to C - perfection. |
| 18:40:47 | q66 | apotheon, well, considering JS is a pretty bad language, everyone expected Dart to actually fix something |
| 18:40:50 | q66 | nope - it didn't fix anything |
| 18:40:53 | apotheon | AlexLibman: If you want faster, use NativeClient. |
| 18:41:13 | AlexLibman | I've been yapping about NativeClient since it was first announced. Still not practical. |
| 18:41:16 | apotheon | It didn't . . . ? |
| 18:41:25 | q66 | apotheon, it only introduced shitty java-based oo besides other things |
| 18:41:27 | apotheon | I thought the whole point of Dart was to fix problems with JavaScript. |
| 18:41:41 | q66 | and its javascript target compiles like 20 lines of dart to 10000 lines of JS |
| 18:41:44 | apotheon | Doesn't Dart at least tidy up the type system? |
| 18:41:54 | apotheon | holy hell |
| 18:42:06 | AlexLibman | Google seems to release its languages 5 years before they're fully baked. (And that's some slow baking!) |
| 18:42:32 | q66 | apotheon, as for nacl |
| 18:42:34 | apotheon | Go developed an orthodoxy that stands in the way of it being as good a language as it could be, from what I've seen. |
| 18:42:38 | q66 | it's kinda broken by design |
| 18:42:44 | AlexLibman | You wouldn't have to compile it to JS if major browsers included it. |
| 18:42:45 | apotheon | q66: How so? |
| 18:42:46 | q66 | it assumes llvm bytecode is portable, which it isn't |
| 18:42:53 | apotheon | hmm |
| 18:43:06 | q66 | even llvm guys warned google against considering it portable |
| 18:43:10 | q66 | they didn't listen apparently |
| 18:43:34 | apotheon | I guess I'll take your word for it, where portability of LLVM bytecode is concerned. I admit I haven't done anything involving LLVM bytecode per se -- I just compile binaries through LLVM with Clang. |
| 18:44:02 | AlexLibman | Hopefully something like HTML6 will be something like NaCl, but to replace JS with the DOM, not just an isolated plugin applet... |
| 18:44:35 | q66 | apotheon, it's probably "portable enough" for them right now, because they're probably not using something really specific - but as whole, it sure isn't portable, and it might break any second if used like that |
| 18:45:04 | AlexLibman | It's better to compile to C. LLVM has its limits, but with Nimrod you can choose any compiler. |
| 18:45:24 | q66 | tbh, llvm is a kinda neat framework |
| 18:45:43 | apotheon | Compiling to C is a decent model, at least in early stages of development. |
| 18:45:44 | q66 | apotheon, this is webdev for you btw - a collection of (increasingly) crappy tech developed by amateurs |
| 18:46:03 | apotheon | q66: There's a lot of bad tech out there for webdev. I agree. |
| 18:46:05 | q66 | that is also anything but coherent |
| 18:46:17 | apotheon | ECMAScript's design failures are heartbreaking. |
| 18:46:24 | q66 | they are |
| 18:46:30 | reactormonk | coffeescript fixes some of them |
| 18:46:38 | q66 | coffeescript is just a preprocessor |
| 18:46:50 | AlexLibman | http://llvm.org/docs/GettingStarted.html#hardware - less than GCC... |
| 18:46:51 | q66 | it doesn't fix any real issues |
| 18:46:59 | reactormonk | Yes, it is. But it takes care of the syntax fails - and makes some WA easier |
| 18:47:17 | AlexLibman | So, with Rust, you're limited to those architectures. |
| 18:47:21 | reactormonk | so it does fix some issues - but you still can't define your own classes |
| 18:47:26 | q66 | AlexLibman, which is totally enough atm |
| 18:47:33 | apotheon | The type system semantics of JavaScript are atrocious. If we don't fix problems like those, we haven't fixed anything significant. |
| 18:47:50 | AlexLibman | Err, forgot about the LLVM-GCC bridge, nevermind. |
| 18:47:51 | q66 | AlexLibman, it's a young project and it'll get more platforms over time |
| 18:48:05 | q66 | apotheon, javascript does not have a type system :) |
| 18:48:18 | q66 | it only has dynamic type tag checking |
| 18:48:34 | apotheon | q66: Part of the problem is that it *does* have a type system -- you just can't actually reach it as a programmer, generally. |
| 18:48:50 | reactormonk | https://github.com/documentcloud/underscore/issues/577 short notice what's wrong with JS. |
| 18:48:54 | reactormonk | apotheon, ^ |
| 18:49:19 | q66 | apotheon, as far as i'm concerned it's as untyped as python, lua, ruby or anything else |
| 18:49:21 | apotheon | q66: ECMAScript actually makes a distinction between floating point numbers and integers, for instance, but the programmer can't access anything but the "numeric" type overlay in the general case. |
| 18:49:26 | apotheon | It's fucking well awful. |
| 18:49:38 | apotheon | It's worse than it not having a type system at all, I think. |
| 18:49:48 | q66 | apotheon, that's not a type system though |
| 18:50:05 | q66 | "A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute." |
| 18:50:32 | apotheon | It's all the convenience of unexpected integer math and IEEE floating point errors combined with all the fine control of NO YOU CAN'T TOUCH THIS. |
| 18:50:36 | apotheon | hammer time |
| 18:50:43 | AlexLibman | I was looking for a list of targets LLVM supports without GCC... |
| 18:50:54 | apotheon | q66: Oh, well, if you define it *that* way, sure. |
| 18:51:05 | q66 | apotheon, it's a definition from http://www.cis.upenn.edu/~bcpierce/tapl/index.html |
| 18:51:13 | apotheon | Of course, if you define it that way you might end up excluding languages with type inference. |
| 18:51:22 | q66 | type inference is fine |
| 18:51:38 | q66 | languages like haskell and ocaml have global inference and they have very comprehensive type systems |
| 18:51:49 | apotheon | reactormonk: PHP has that kind of equality checking problem, too. |
| 18:52:10 | apotheon | q66: By the way, Ruby is not untyped. |
| 18:52:18 | apotheon | (to just pick the one I know best from that list) |
| 18:52:19 | q66 | apotheon, how so? |
| 18:52:19 | AlexLibman | PHP has a sanity checking problem. |
| 18:52:29 | apotheon | q66: It's duck typed, which is not the same as being untyped. |
| 18:52:30 | q66 | AlexLibman, PHP has many problems :) |
| 18:53:05 | apotheon | If it was untyped, you wouldn't have type conversions and type errors for code where you assume one type but get another. |
| 18:53:24 | q66 | apotheon, but those errors and conversion are runtime, no? ;) |
| 18:54:02 | apotheon | q66: The only thing that really makes JavaScript "untyped" the way that definition applies is the "syntactic method for proving the absence of . . ." |
| 18:54:25 | apotheon | q66: . . . which could also be interpreted to exclude type inference from type systems, because type inference can operate without explicit syntactic cues. |
| 18:54:31 | q66 | apotheon, ruby, as far as I'm concerned, does not perform any sort of *static* checking |
| 18:54:55 | AlexLibman | sh is a typed language. It has two types: string and spaghetti. |
| 18:55:00 | apotheon | AlexLibman: If PHP didn't have a sanity checking problem, it would commit itself to a psychiatric hospital. |
| 18:55:15 | q66 | apotheon, type inference is, as its name states, inference - it has to infer the information from something, and it still does it statically |
| 18:55:16 | apotheon | q66: You don't have to have a compile time type system to have a type system. |
| 18:55:24 | Araq | stricly speaking, q66 is right |
| 18:55:31 | Araq | you either have types at compile time |
| 18:55:38 | Araq | or you have a "tagging" scheme |
| 18:55:38 | q66 | or tags at run time |
| 18:56:01 | Araq | but most people don't make this distinction ;-) |
| 18:56:02 | q66 | Araq, strictly speaking, languages like JS, python, etc have one type |
| 18:56:03 | q66 | a value |
| 18:56:09 | apotheon | Are you saying that cint and picoc don't have any type system, then? |
| 18:56:20 | q66 | and there are tags specifying what "type" the value is |
| 18:56:30 | apotheon | Any language that is not compiled to a static form is untyped by that perspective. |
| 18:56:55 | q66 | apotheon, it doesn't have to be static form ;) |
| 18:57:01 | apotheon | I guess OCaml doesn't have a type system when using the interpreter, then. |
| 18:57:06 | q66 | it can be online bytecode compilation |
| 18:57:20 | apotheon | Ruby uses a bytecode VM now, y'know. |
| 18:57:20 | q66 | the thing is, the compilation step happens, even when it's not offline |
| 18:57:35 | q66 | apotheon, sure, but during bytecode compilation it does not perform typechecking |
| 18:58:03 | apotheon | You just said you didn't require a static form for types. |
| 18:58:13 | q66 | it's still static :) |
| 18:58:16 | q66 | there is still compilation step |
| 18:58:23 | apotheon | 18:56 < q66> apotheon, it doesn't have to be static form ;) |
| 18:58:25 | q66 | it doesn't matter if it happens in an offline form |
| 18:58:27 | apotheon | 18:58 < q66> it's still static :) |
| 18:58:32 | apotheon | These statements look contradictory. |
| 18:58:32 | q66 | or if it happens before running it |
| 18:58:46 | q66 | apotheon, oh, disregard the former, i probably got you wrong. |
| 18:59:06 | apotheon | The thing to which you responded with the latter was only part of a response to the former. |
| 18:59:40 | apotheon | q66: Clarify for me -- are picoc and cint necessarily untyped just because they're interpreted? |
| 18:59:52 | q66 | apotheon, i was just saying, there is always a compilation step (unless you directly interpret everything) - during which you *could* typecheck |
| 19:00:04 | q66 | apotheon, i'm not too aware of picoc and cint to say |
| 19:00:11 | apotheon | They're intepreted C. |
| 19:00:29 | q66 | i don't know how they work |
| 19:00:44 | q66 | if they perform typechecking before the actual runtime happens, they have type systems |
| 19:01:04 | * | FreeArtMan quit (Quit: Out of this 3D) |
| 19:01:07 | reactormonk | dom96, oh, glorious god object ^^ |
| 19:01:38 | apotheon | q66: They don't do bytecode compilation, I'm pretty sure. |
| 19:01:54 | apotheon | q66: It's all runtime, with "real" interpreters. |
| 19:02:36 | dom96 | reactormonk: what? |
| 19:02:38 | apotheon | I guess, by your standards, Perl has a type system and Ruby does not -- because Ruby is duck typed, and Perl does multiple JIT parse tree compilation passes with some type handling in some of the early stages. |
| 19:02:46 | q66 | apotheon, then they don't have type systems, but probably only runtime-specifyable type tags and some checking |
| 19:03:20 | q66 | apotheon, i don't know perl well enough, but as far as i know, perl 6 added some "type specifiers" but they're not actual type system |
| 19:03:21 | apotheon | As far as I'm concerned, type tags with checking according to consistent rules *is* a type system. |
| 19:03:27 | q66 | same as php has "type specifiers" but they're not a type system |
| 19:03:31 | apotheon | s/type tags/a system of type tags/ |
| 19:03:41 | reactormonk | dom96, the win in Aporia |
| 19:04:03 | apotheon | If that doesn't qualify as a type system, my attitude is that I don't give a crap about a type system per se. |
| 19:04:15 | reactormonk | dom96, in asyncGetSuggest, how do you pass the file to nimrod? |
| 19:04:16 | q66 | apotheon, tbh, it doesn't quite matter :) |
| 19:04:29 | dom96 | reactormonk: I see. Yeah, gotta love those "god objects" :P |
| 19:04:34 | apotheon | I'm more concerned with the behavior of the running program specified by the language than I am with whether some esentially irrelevant technicality disqualifies it as being said to have a "type system". |
| 19:05:05 | apotheon | q66: What you describe as a "type system" is something I'd describe as a "static type checking system", though. |
| 19:05:18 | dom96 | reactormonk: It's saved in populateSuggest. |
| 19:05:29 | dom96 | reactormonk: to /tmp |
| 19:05:33 | q66 | apotheon, well, what's technically untyped is commonly defined as dynamically typed, and "static typing" is technically just "typing" |
| 19:05:44 | reactormonk | dom96, I suppose you save the whole project there? |
| 19:06:15 | q66 | apotheon, it's just that the scripting languages and stuff have something that somewhat resembles types, so people started calling it "dynamically typed" |
| 19:06:18 | q66 | that's about it |
| 19:07:02 | reactormonk | q66, except perl, which has... context-depending types? |
| 19:07:11 | apotheon | q66: You've chosen to eliminate the ability to discuss different data classification systems based solely on the order in which language parsing happens. |
| 19:07:13 | q66 | reactormonk, i don't know perl well enough |
| 19:07:20 | dom96 | reactormonk: yep. Well from what I can tell, currently it's only the tabs that are open which are in the same folder as the file which you are executing suggest in. |
| 19:07:29 | dom96 | reactormonk: I guess that's not entirely correct. |
| 19:07:43 | q66 | apotheon, "order in which the language parsing happens"? |
| 19:07:46 | q66 | the language is parsed once |
| 19:07:58 | dom96 | Araq: Possible reason why suggest isn't giving the best results ^^ lol |
| 19:07:58 | q66 | during compilation step, typically :P |
| 19:08:05 | reactormonk | dom96, I think I'll just copy over the whole dir and keep buffers synced |
| 19:08:29 | Araq | reactormonk: that's a good idea |
| 19:08:30 | q66 | anyway, it's somewhat irrelevant |
| 19:08:38 | Araq | dom96: I see ;-) |
| 19:08:43 | apotheon | reactormonk: The interesting thing about the q66 definition of type systems is that Perl has a type system while Ruby doesn't, but Perl's "official" types are far less consistent and reliable than Ruby's apparently nonexistent types. |
| 19:09:07 | reactormonk | apotheon, stop arguing and start producing some code ;-) |
| 19:09:10 | apotheon | That being the case, the q66 definition of a type system is completely useless. |
| 19:09:44 | apotheon | q66: I guess you've never heard of, for instance, a four-pass compiler. |
| 19:09:48 | AlexLibman | My endless arguing is how I got to be interested in nimrod in the first place. |
| 19:09:49 | Araq | Perl has no type system unless it produces type error messages before it tries to execute the particular code section |
| 19:10:13 | apotheon | reactormonk: You produce some code too, then. |
| 19:10:23 | apotheon | reactormonk: Do you have some specific code in mind for me to produce right now? |
| 19:10:26 | reactormonk | apotheon, that's why I was asking dom96 :-) |
| 19:10:46 | Araq | in fact, arguably "compile-time" is well-defined even for an entirely interpreted language |
| 19:11:10 | q66 | apotheon, a typical compiler has four passes in fact |
| 19:11:11 | reactormonk | apotheon, sure, write some code for kwin so echo works there - it uses print (take a look how it works with when(nodejs) and do it with when(kwin)) |
| 19:11:28 | apotheon | q66: I was being facetious. I'm sure you've heard of a four-pass compiler. |
| 19:11:35 | * | AlexLibman brainstorms super-highlevel features that Nimrod could offer... |
| 19:11:39 | reactormonk | it's a bit wierd to use JS as a birdge between two statically typed languages, but oh well :D |
| 19:11:41 | q66 | lexical pass, parsing, semantic analysis and codegen |
| 19:11:52 | apotheon | reactormonk: Screw kwin. |
| 19:11:58 | reactormonk | apotheon, too bad. |
| 19:12:06 | apotheon | I try to avoid Qt. |
| 19:12:06 | AlexLibman | Like - get data from weird places, generate C code for it. |
| 19:12:19 | reactormonk | apotheon, prefer gtk? |
| 19:12:25 | reactormonk | or tk? |
| 19:12:43 | apotheon | I'd prefer Tk over GTK. |
| 19:12:44 | AlexLibman | Most widget toolkits are marred by GPL. |
| 19:13:10 | AlexLibman | Textual interfaces being dead, one needs to bite the bullet and accept HTML5 as one's Lord and Master. |
| 19:13:18 | apotheon | GTK and Qt are *huge* and overburdened with features. There are some nice things about them, but they fail to make up for all the awful. |
| 19:13:21 | q66 | but html sucks :) |
| 19:13:27 | q66 | html5 is no exception |
| 19:13:29 | AlexLibman | Compared to Xlib? |
| 19:13:34 | apotheon | har |
| 19:13:36 | q66 | you can't compare that |
| 19:13:43 | q66 | but, at least xlib is lightweight |
| 19:13:46 | q66 | hrhrhrhrhr |
| 19:13:59 | reactormonk | Araq, any way to get the project root by asking the nimrod binary? |
| 19:13:59 | AlexLibman | Different paths originating from the same fork. |
| 19:14:32 | apotheon | Tk lacks some nice stuff, but more than makes up for it by leaving out the awful. |
| 19:14:45 | AlexLibman | (Meaning like "fork in the road" - do I make it a client-server Web browser interface, or a native app using Xlib / Athena / etc.) |
| 19:14:51 | reactormonk | anyone doesn't like git in here? Otherwise I'll take git as a lead where the project root is |
| 19:14:54 | AlexLibman | Tk is married to Tcl. |
| 19:15:02 | apotheon | "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." |
| 19:15:05 | dom96 | Isn't Tk one of the ugliest widget toolkits out there though? |
| 19:15:32 | apotheon | It's not very pretty. |
| 19:15:47 | reactormonk | dom96, I did some ffi-tk with ruby and I have to say it's rather nice |
| 19:15:59 | q66 | i'm using EFL and it's alright |
| 19:16:03 | AlexLibman | IUP is married to Lua. Ultimate++ is married to itself. |
| 19:16:18 | reactormonk | AlexLibman, incest? |
| 19:16:29 | AlexLibman | EFL is gay-married to the cast of Glee. |
| 19:16:36 | apotheon | EFL looks a little better than GTK, though I haven't actually used it. |
| 19:16:50 | q66 | apotheon, i've worked on it |
| 19:16:51 | q66 | it's nice :P |
| 19:17:07 | apotheon | cool |
| 19:17:25 | q66 | it can't be compared with gtk tbh |
| 19:17:27 | apotheon | I should run along for a bit. I need to pick up meds for the cancer cat. |
| 19:17:31 | q66 | because a widget toolkit is just one library in EFL |
| 19:17:32 | apotheon | Why not? |
| 19:17:36 | apotheon | ah |
| 19:17:51 | Araq | reactormonk: there is os.getAppDir |
| 19:17:55 | apotheon | EFL is kinda like GTK+GNOME, I guess. |
| 19:18:05 | q66 | it provides you with everything from a canvas server, theming engine, widget toolkit, multimedia library, C utilities to physics engine and weather forecasts :P |
| 19:18:14 | reactormonk | Araq, will that work as expected? Otherwise I'll call git for now |
| 19:18:30 | apotheon | q66: That's friggin' huge. |
| 19:18:32 | Araq | work for what? |
| 19:18:36 | apotheon | q66: I'll stick to something lighter. |
| 19:18:38 | AlexLibman | VCF ( http://vcf-online.org/ ) is married to Windows, but promices to bang Linux on the side someday. |
| 19:18:42 | apotheon | ta |
| 19:18:48 | q66 | apotheon, nah |
| 19:18:49 | q66 | it's modular |
| 19:18:55 | q66 | you can use only the core just fine |
| 19:18:59 | dom96 | I haven't used anything other than GTK extensively. GTK has some issues which are really irritating, like the damn text views now scrolling when you tell them to! |
| 19:19:04 | dom96 | *not |
| 19:19:20 | AlexLibman | 100x more people will use your app if it's Web-based, and doesn't require downloading and installing... |
| 19:19:29 | q66 | apotheon, and with all these libraries it won't be larger than 30MB together |
| 19:19:57 | Araq | reactormonk: work for what? |
| 19:20:02 | q66 | it also runs on everything with 200+MHz and 16MB RAM |
| 19:20:36 | reactormonk | Araq, if I shell out. How does it find it? |
| 19:21:23 | Araq | reactormonk: there is also os.findExe |
| 19:21:25 | AlexLibman | I miss textual interfaces of DOS... |
| 19:22:02 | Araq | reactormonk: os.getAppDir uses /proc/$pid on linux |
| 19:22:04 | AlexLibman | Don't think of DOS itself, think of its best applications. Living in a 80x25 character world... |
| 19:22:10 | reactormonk | Araq, given a project of arbirary size, what's the folder highest up in the hierarchy that includes all files for this project? <- that's the question |
| 19:22:22 | reactormonk | ... and what you have is the path of one file in that folder |
| 19:22:46 | Araq | reactormonk: there is no way to tell, you can do: import "../../ha" |
| 19:22:50 | q66 | AlexLibman, i was recently looking for an ui library to use in my game engine as ingame gui |
| 19:22:53 | q66 | then i was like "fuck it" |
| 19:22:56 | q66 | and i wrote my own in lua |
| 19:23:07 | AlexLibman | blit, pixels, blit! |
| 19:23:08 | reactormonk | Araq, I'll go with http://stackoverflow.com/questions/957928/is-there-a-way-to-get-the-git-root-directory-in-one-command for now |
| 19:23:31 | q66 | it's simple (under 4k lines), rather complete, integrates well, and renders purely with opengl |
| 19:23:44 | Araq | reactormonk: since I don't get what you're trying to accomplish, this indeed seems to be the way to go |
| 19:24:17 | reactormonk | Araq, I mentioned earlier to just copy over the whole project from nimrod idetools - so I need to know where the project is |
| 19:25:32 | AlexLibman | My lack of sleep is creating ValentineMichaelSmith level of consciousnesslessness, groking bitwise, brightly, brightly, and with segfault |
| 19:25:58 | Araq | reactormonk: the project is the main.nim file and you should know where it is, because, you know, you pass that filename to nimrod |
| 19:26:49 | reactormonk | Araq, I don't see a main.nim in aporia |
| 19:27:07 | Araq | reactormonk: $main is a placeholder |
| 19:27:07 | dom96 | Araq: Why does nimrod need to know what the 'main' file is? |
| 19:27:32 | dom96 | FYI I don't make a distinction. |
| 19:27:39 | Araq | dom96: because that's how compilation works, it starts with the main file and recursively compiles its dependencies |
| 19:28:45 | Araq | dom96: I know you don't make a distinction, and it shouldn't be necessary for now |
| 19:30:40 | dom96 | I see. That makes sense. |
| 19:30:57 | dom96 | Determining the 'main' file is impossible though. |
| 19:34:10 | Araq | the plan is that file.nimrod.cfg means file.nim is a main file |
| 19:34:33 | Araq | so it's not impossible to determine :P |
| 19:35:10 | Araq | but it can be ambiguous as a directory can contain more than 1 |
| 19:36:40 | dom96 | Well, some projects may not use a .cfg file :P |
| 19:37:01 | Araq | and yes, aporia should do that: compiler/ast.nim is opened, I press "compile project" and then aporia checks compiler/*.nimrod.cfg and determines that compiler/nimrod.nim is the main file |
| 19:37:55 | Araq | brb |
| 19:38:08 | * | Trix[a]r_za is now known as Trixar_za |
| 19:46:43 | Araq | back |
| 20:22:47 | * | Trixar_za is now known as Trix[a]r_za |
| 20:38:08 | dom96 | I guess that's better than nothing. |
| 20:41:57 | Araq | imho it's better than a real project file |
| 20:44:35 | dom96 | Sure, I shall implement it this way, and it will stay that way until a brave soul decides to challenge our ways. |
| 20:45:54 | Araq | good :-) |
| 20:46:11 | dom96 | Maybe we should attempt to get that Wikipedia article back? |
| 20:46:26 | Araq | hrm yeah ... |
| 20:47:17 | dom96 | You wanna do that tonight? |
| 20:47:59 | reactormonk | Araq, do you think it's evil to save stuff back and not use a tmpdir? Because setting one of those up is getting damn ugly if you do stuff like git checkouts... |
| 20:48:08 | Araq | I think I'll contact the guy who wrote it |
| 20:48:25 | Araq | reactormonk: I have no idea how git plays any role here |
| 20:48:43 | Araq | but saving things is not bad if the "undo" history is kept |
| 20:49:16 | reactormonk | Araq, well, if you change a file outside the editor - I'm not sure I want to use inotify here |
| 20:49:30 | dom96 | Araq: Who wrote it? Was it that Phil guy, "PhilHo" or whatever you call him? |
| 20:49:39 | reactormonk | but doesn't idetools bail if there are syntax errors? |
| 20:49:41 | Araq | dom96: yes |
| 20:49:56 | Araq | idetools can handle syntax errors |
| 20:50:00 | reactormonk | good |
| 20:53:06 | reactormonk | dom96, how does aporia handle that? use the local file only? |
| 20:54:17 | dom96 | Aporia saves everything to /tmp. |
| 20:54:37 | dom96 | If that's what you're asking. |
| 20:55:05 | dom96 | Aporia will use inotify in the future. |
| 20:55:20 | dom96 | (fsmonitor module is already in the stdlib) |
| 20:55:31 | dom96 | Speaking of fsmonitor: |
| 20:55:39 | reactormonk | so you have a tmpdir that you keep in sync with the project? |
| 20:56:03 | dom96 | Araq: I was reading about Window's API, and it seems I will either have to use WaitForMultipleObjects or use I/O completion ports. |
| 20:56:31 | dom96 | reactormonk: Every time suggest is invoked, everything is saved. |
| 20:56:49 | reactormonk | dom96, so why do you need fsmonitor? |
| 20:56:55 | dom96 | Araq: WaitForMultipleObjects is limited to 64 objects. |
| 20:57:06 | dom96 | Araq: And I can't use 'select' :| |
| 20:57:22 | Araq | dom96: that's hardly surprising |
| 20:57:39 | dom96 | reactormonk: To get notifications when files are edited outside of Aporia. It isn't required for proper suggest support, it's simply a nice feature. |
| 20:58:02 | reactormonk | dom96, where do you invoke the suggest? in the tmpdir? |
| 20:58:03 | dom96 | Araq: In either case I will have to add special support for it in asyncio. |
| 20:58:18 | dom96 | Araq: It looks to me like I/O completion ports are more "sustainable". |
| 20:58:26 | dom96 | reactormonk: yes |
| 20:59:04 | reactormonk | dom96, so you don't care about the other files in the project? |
| 20:59:51 | Araq | dom96: I dunno, waitForMultipleObjects sounds wrong |
| 21:00:46 | dom96 | reactormonk: they should be all saved to /tmp, currently some of them are (which is a bug). |
| 21:01:09 | reactormonk | dom96, so you need to keep the dirs in sync somehow, don't you? |
| 21:01:45 | dom96 | reactormonk: yes, they are in sync. Because they are saved before every execution of the nimrod compiler. |
| 21:02:10 | dom96 | Araq: I/O Completion ports seem to require the use of threads. |
| 21:02:27 | reactormonk | dom96, and what do you do with files that are not open in aporia? |
| 21:02:39 | dom96 | Araq: I think that's just how Window's likes to do IO. |
| 21:03:19 | dom96 | reactormonk: Currently they are not saved. But like I said: that's a bug, they should be saved. |
| 21:04:05 | reactormonk | dom96, my problem is atm how do you detect changes to these files not tracked by the editor so you can forward those changes to the tmpdir? |
| 21:04:07 | Araq | dom96: well use threads then |
| 21:04:11 | reactormonk | like a git checkout or similar |
| 21:04:48 | dom96 | reactormonk: simply copy every .nim file in the project files directory into /tmp? |
| 21:05:03 | reactormonk | dom96, you want to do that at every suggest call? |
| 21:05:35 | dom96 | I suppose you could check the modification timestamp of those files? |
| 21:06:05 | reactormonk | so shell out to rsync in the end? |
| 21:06:45 | dom96 | I guess that is the equivalent so yes. |
| 21:07:19 | dom96 | I can't see an alternative. |
| 21:08:29 | reactormonk | we could pass patches to idetools that diff between the current state of the buffer and the file on the disk and the idetools apply them |
| 21:09:13 | reactormonk | Araq, wierd idea? |
| 21:10:54 | Araq | reactormonk: well we already had that idea :P |
| 21:11:01 | Araq | but idetools doesn't support it yet |
| 21:21:28 | * | FreeArtMan joined #nimrod |
| 21:29:16 | reactormonk | Araq, how so? |
| 21:29:43 | Araq | reactormonk: you can't pass a diff to the compiler |
| 21:29:57 | Araq | you cannot even pass a buffer, but only a filename |
| 21:30:41 | reactormonk | Araq, stdin? |
| 21:31:43 | Araq | yeah well ... the compiler doesn't support it :P |
| 21:31:52 | Araq | only the REPL uses stdin |
| 21:32:19 | reactormonk | hm |
| 21:33:05 | reactormonk | how complicated would it be to add a --diff option? |
| 21:34:40 | Araq | passing a buffer wouldn't be hard, a --diff option would be useless for now |
| 21:34:57 | Araq | however idetools is about to work with sockets and will keep everything in memory |
| 21:35:42 | Araq | i.e. you start the compiler as a "web" service and interact with it via a sockets based protocol |
| 21:38:35 | Araq | but for now, just use /tmp |
| 21:43:58 | reactormonk | and rsync |
| 21:52:47 | * | FreeArtMan quit (Remote host closed the connection) |
| 22:52:25 | * | fowl-zzz is now known as fowl |