00:05:14 | fowl | var p = cast[pointer](0x1000) |
00:05:38 | fowl | what do you need that for btw |
00:06:07 | Sergio965 | Writing a little kernel. |
00:06:13 | Sergio965 | Well, just wrote it. It works! |
00:07:13 | fowl | nice |
00:08:39 | Sergio965 | How do I dereference it? |
00:08:49 | Sergio965 | I tried p[] = bla, but no go. |
00:08:58 | OrionPK | dealloc? |
00:09:13 | fowl | pointer is void* |
00:09:31 | Sergio965 | Not dealloc, dereference. |
00:09:44 | Sergio965 | Can I give it a type somehow? :\ |
00:09:53 | fowl | yeah use ptr T instead of pointer |
00:10:01 | fowl | i hate to say RTFM, but you should do it |
00:10:04 | OrionPK | lol |
00:10:05 | Sergio965 | I did. |
00:10:09 | Sergio965 | I promise! |
00:10:23 | Sergio965 | But I didn't see this anywhere... |
00:10:37 | Sergio965 | It says, "The empty [] subscript notation can be used to derefer a reference". |
00:10:44 | Sergio965 | I tried that, didn't work. |
00:11:25 | OrionPK | what happens when you do the empty [] subscript notation |
00:11:51 | Sergio965 | The empty [] subscript notation can be used to derefer a reference |
00:11:52 | Sergio965 | Er. |
00:12:03 | OrionPK | ah, a ref but not a ptr? |
00:12:04 | Sergio965 | Error: ']' expected. |
00:12:11 | fowl | paste line |
00:12:32 | fowl | example from the manual: var d = cast[ptr TData](alloc0(sizeof(TData))) |
00:12:39 | Sergio965 | Where is that? |
00:12:51 | fowl | i just ctrl+f'd for ptr |
00:13:12 | Sergio965 | Oh, the manual. |
00:13:13 | fowl | http://nimrod-code.org/manual.html#the-addr-operator |
00:13:16 | Sergio965 | I've been looking at the tutorial. |
00:14:56 | Sergio965 | Nonetheless, it doesn't say how to dereference. |
00:15:11 | Sergio965 | Does it need to have a type? |
00:15:23 | fowl | bro |
00:15:25 | fowl | RTFM |
00:15:37 | fowl | the link i just gave you shows an example of dereferencing |
00:15:41 | Sergio965 | With a type. |
00:15:52 | Sergio965 | With fields. |
00:16:03 | fowl | its in there |
00:17:17 | fowl | search for "proc divmod" |
00:18:23 | Sergio965 | That's exactly what I was doing. |
00:18:39 | Sergio965 | I see. |
00:19:15 | fowl | Sergio965, one time i talked to my aunt for 3 hours on why her tv wasn't turning on, she swore it was plugged in, guess what the problem was |
00:19:51 | Sergio965 | She had the wrong remote? :) |
00:19:56 | Sergio965 | Hehe. |
00:20:13 | Sergio965 | Sorry, you're right. I didn't realize the manual was different from the tutorials + compiler manual. |
00:22:35 | OrionPK | what the shit.. this code worked fine yesterday :S |
00:22:41 | OrionPK | Error: undeclared identifier: 'TThread' |
00:22:56 | OrionPK | nimrod hasn't even been updated since then |
00:23:37 | fowl | you have to compile with --threads:on or something like that |
00:23:43 | OrionPK | yeah, it is |
00:24:06 | OrionPK | different error than that anyway, I think |
00:24:23 | fowl | are you working on games? (: |
00:24:58 | OrionPK | hah, no.. I've got to ramp down on a "personal" project that I'm doing for work before I can do anything big in nimrod |
00:25:16 | OrionPK | and I say "personal" because really it's work work that I'm just not getting paid for. |
00:28:07 | OrionPK | ah god dammit |
00:28:18 | OrionPK | my build system got switched to something else |
00:28:35 | OrionPK | so you were right, ultimately it wasn't using --threads:on like my makefile tells it to |
00:29:12 | fowl | dont use makefile |
00:29:24 | fowl | echo "theads: on" >> nimrod.cfg |
00:30:37 | fowl | or use a nakefile (: |
00:30:44 | OrionPK | lol |
00:30:51 | OrionPK | well, it's just for a small test project |
00:31:06 | OrionPK | I'd probably use CMake or something at least for something bigger |
00:31:17 | fowl | https://github.com/fowlmouth/nake |
00:31:44 | OrionPK | ha, that's great ;) |
00:32:29 | EXetoC | neat |
00:36:57 | * | DAddYE joined #nimrod |
00:43:45 | * | DAddYE quit (Ping timeout: 248 seconds) |
00:54:57 | OrionPK | babel relies on OpenSSL? |
00:55:56 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
01:02:20 | OrionPK | i guess sockets.nim does |
01:05:11 | * | Sergio965 quit (Quit: Sergio965) |
01:07:39 | OrionPK | can openSSL be added to the dist folder? |
01:07:43 | * | fowl quit (Quit: EliteBNC free bnc service - http://elitebnc.org) |
01:15:55 | * | fowl joined #nimrod |
01:44:23 | OrionPK | proc CRYPTO_set_mem_functions(a,b,c: pointer){.cdecl, dynlib: DLLSSLName, importc.} vs. int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void *)); |
01:44:38 | OrionPK | oops, wrong one :S |
01:44:52 | OrionPK | int CRYPTO_set_mem_functions(void *(*m)(size_t),void *(*r)(void *,size_t), void (*f)(void *)); |
01:59:43 | OrionPK | yeah, babel works seamlessly on mac, not windows |
03:05:36 | * | DAddYE joined #nimrod |
03:59:54 | * | OrionPK quit (Quit: Leaving) |
04:14:57 | * | DAddYE quit (Remote host closed the connection) |
04:33:37 | * | DAddYE joined #nimrod |
04:35:20 | * | DAddYE_ joined #nimrod |
04:38:56 | * | DAddYE quit (Ping timeout: 255 seconds) |
05:22:46 | reactormonk | fowl, yeah, := looks like a good idea |
05:36:29 | * | mal`` quit (Ping timeout: 256 seconds) |
05:38:49 | * | mal`` joined #nimrod |
06:06:01 | * | DAddYE_ quit (Remote host closed the connection) |
06:06:33 | * | DAddYE joined #nimrod |
06:11:01 | * | DAddYE quit (Ping timeout: 252 seconds) |
06:16:08 | * | q66 joined #nimrod |
06:59:31 | * | DAddYE joined #nimrod |
08:28:06 | * | DAddYE quit (Remote host closed the connection) |
08:28:34 | * | DAddYE joined #nimrod |
08:32:54 | * | DAddYE quit (Ping timeout: 252 seconds) |
09:01:15 | * | Araq_ joined #nimrod |
09:45:52 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]) |
10:01:34 | * | EXetoC joined #nimrod |
10:41:46 | * | Trix[a]r_za is now known as Trixar_za |
12:30:55 | * | tumak quit (Ping timeout: 260 seconds) |
12:31:02 | * | tumak joined #nimrod |
12:57:08 | EXetoC | "newCall("invariant", firstparam)" so this gave me an ICE because the macro itself was called invariant |
13:01:25 | EXetoC | no, it's because the module has the same name |
13:02:42 | * | Trixar_za is now known as Trix[a]r_za |
13:02:45 | dom96 | hrm, something weird happened with the IRC logs yesterday. |
13:04:13 | dom96 | OrionPL: Yeah, babel requires it to connect to github. It also needs a git in your PATH. |
13:04:24 | dom96 | I haven't tested it on windows, so beware. |
13:07:51 | EXetoC | the exe name is the same as for openbabel. I don't know what openbabel is for or why it's installed though, so I can just remove it I guess, but still |
13:08:31 | dom96 | what? What is openbabel? |
13:08:33 | EXetoC | in case you didn't know |
13:09:22 | EXetoC | I don't know but I tried to install the package manager (package babel-git), but a file name collision was detected |
13:10:54 | dom96 | damn, hopefully many people won't want to perform cheminformatics and use babel at the same time. |
13:11:51 | EXetoC | :> |
13:12:26 | EXetoC | probably not in the near future. Nimrod hasn't achieved world domination just yet |
13:13:07 | dom96 | It's ok, when it does people will blame OpenBabel for the conflict. |
13:13:10 | * | dom96 crosses fingers |
13:14:47 | dom96 | Round 6 of the Framework Benchmarks (with Jester) may be out soon :D |
13:18:43 | dom96 | EXetoC: Make bug reports on github for any ICEs |
13:36:34 | * | Sergio965 joined #nimrod |
13:39:40 | * | Sergio965 quit (Client Quit) |
14:34:36 | * | Trix[a]r_za is now known as Trixar_za |
14:51:00 | * | Sergio965 joined #nimrod |
15:00:46 | dom96 | hello Sergio965 |
15:07:53 | * | Sergio965 quit (Ping timeout: 240 seconds) |
15:43:25 | * | Trixar_za is now known as Trix[a]r_za |
15:49:03 | * | Trix[a]r_za is now known as Trixar_za |
16:09:37 | * | Sergio965 joined #nimrod |
16:25:27 | * | DAddYE joined #nimrod |
16:39:05 | dom96 | awww they delayed it to the 25th. |
16:41:40 | reactormonk | gotta say, I like this source annotation: http://harrah.github.io/xsbt/latest/sxr/IO.scala.html |
16:54:18 | EXetoC | dom96: it seems pretty neat |
16:54:39 | EXetoC | is anyone working on template engines? |
16:55:13 | dom96 | EXetoC: hrm? was that directed at reactormonk? |
16:55:29 | dom96 | EXetoC: Nimrod supports templating. |
16:55:57 | reactormonk | dom96, for documentation generation |
16:59:53 | dom96 | reactormonk: https://github.com/Araq/Nimrod/blob/master/config/nimdoc.cfg ? |
17:04:45 | EXetoC | dom96: I found some html template snippet before, but I can't find it now |
17:04:50 | EXetoC | in the manual or something |
17:05:21 | EXetoC | dom96: and I meant Jester, if only for that DSL :> |
17:05:37 | * | Endy joined #nimrod |
17:06:12 | dom96 | EXetoC: http://build.nimrod-code.org/docs/filters.html |
17:06:55 | EXetoC | there it is. thanks |
17:07:40 | dom96 | And yeah, thanks. I'm excited to see the benchmark results of it in comparison to other frameworks. |
17:08:00 | dom96 | Even though it hasn't exactly been all that well optimised. |
17:19:12 | EXetoC | as long as it beats java frameworks :> |
17:19:56 | dom96 | well it doesn't use 50TB of RAM so I think it does :P |
17:20:18 | EXetoC | alright then |
18:09:31 | * | Sergio965 quit (Quit: Textual IRC Client: www.textualapp.com) |
18:11:38 | EXetoC | oh no, Serio965 was in the Rust channel as well. We must convince him that only Nimrod isn't a complete waste of time |
18:27:55 | * | Endy quit (Ping timeout: 260 seconds) |
18:36:01 | dom96 | indeed. Why stop there? Go and convince other people in #rust too :P |
18:36:48 | Araq | that's a bad idea :P |
18:37:51 | Araq | our concurrency model is still in flux... |
18:39:02 | dom96 | yeah, and we're still waiting for that blog of yours. |
18:50:53 | EXetoC | dom96: only if they're here too :> |
18:51:23 | EXetoC | Araq: yeah, not being entirely serious |
18:51:41 | EXetoC | but basic things should be doable, which is good enough for me atm |
18:53:55 | EXetoC | someone claimed that rust's message passing model isn't ideal for many tasks. do you have any thoughts regarding that? |
18:54:28 | Araq | been there done that, message passing sucks for parallelism |
18:54:43 | Araq | but for concurrency it's often preferable |
18:55:58 | EXetoC | oh ok |
19:03:45 | * | XAMPP-8 joined #nimrod |
19:18:54 | * | XAMPP-8 quit (Ping timeout: 252 seconds) |
19:29:37 | * | XAMPP-8 joined #nimrod |
19:29:42 | * | XAMPP-8 quit (Read error: Connection reset by peer) |
19:36:32 | * | Sergio965 joined #nimrod |
19:37:35 | Araq | wb Sergio965; I heard you joined the dark side |
19:37:45 | Sergio965 | The dark side? |
19:37:51 | Sergio965 | Which is that? |
19:38:05 | Araq | the rusty language |
19:38:08 | EXetoC | :-) |
19:38:09 | Sergio965 | Lol. |
19:38:17 | * | gradha joined #nimrod |
19:38:25 | Sergio965 | Sneaky. |
19:38:54 | Sergio965 | I'm doing some research on developing kernels in high level languages; Rust and Nimrod are two of the languages being surveyed, among others. |
19:39:28 | Sergio965 | Rust is neat, though. |
19:40:34 | EXetoC | yup |
19:40:47 | fowl | let mut nothx |
19:41:02 | gradha | EXetoC: the documentation you linked to, that's partially my purpose with https://github.com/gradha/the_hyperlink_vs_nimrod |
19:41:15 | EXetoC | got plenty of manpower too |
19:41:21 | gradha | EXetoC: it's not pretty now http://dl.dropboxusercontent.com/u/145894/t/weird.proc.th.html but that's because I'm not an artist |
19:42:13 | Araq | indeed I envy Rust's manpower |
19:42:29 | Sergio965 | Is there some documentation about the ideology of Nimrod? Why was the language created? |
19:43:36 | Araq | because every other PL sucks ;-) |
19:43:55 | gradha | the ideology of "taste" |
19:44:53 | Sergio965 | That's unfair. I can think of a few languages, Python, Go, Haskell, that are superb. |
19:44:54 | EXetoC | gradha: I can't remember what that was, but that seems interesting |
19:45:24 | gradha | EXetoC: the link you provided was http://harrah.github.io/xsbt/latest/sxr/IO.scala.html#31627 |
19:45:49 | gradha | I might as well bookmark it to "steal"... er... "learn" from their pretty javascript |
19:46:07 | EXetoC | *reactormonk |
19:46:55 | gradha | ah, true, misread that, indeed seems more like something reactormonk would bring up |
19:47:12 | Sergio965 | Nimrod's error messages are rather cryptic. (or is it just me?) |
19:47:31 | fowl | such as? |
19:47:34 | gradha | Sergio965: takes some time to adapt |
19:47:50 | Araq | Go: racy as hell, way less expressive than C, bad taste everywhere (itoa wtf?) |
19:48:01 | Araq | Python: dynamically typed. meh, thanks |
19:48:35 | Araq | Haskell: indeed superb but I'm not convinced of laziness per default |
19:48:43 | Sergio965 | I don't think you've given Go a chance. Goroutines are fantastic, the receiver method of OO is also fantastic. |
19:48:46 | EXetoC | Araq: yeah, the dynamic typing bit me several times |
19:49:02 | EXetoC | often after running the application for quite some time |
19:49:10 | Sergio965 | Python is great for small to medium projects. I am of the school of thought that for large projects, you need static typing. |
19:49:36 | Araq | Sergio965: I don't need to give it a chance, I studied enough languages to know how it works |
19:49:58 | EXetoC | and once at the end when it was supposed to write json data to a file |
19:50:07 | Araq | and the type system encourages races just like C encourages buffer overflows |
19:50:31 | Araq | it runs single threaded on their app service for a reason |
19:51:04 | fowl | Sergio965, once you use multiple-dispatch you will never want to go back to bound methods |
19:51:07 | Sergio965 | As for the error messages, yesterday, for example, I had that pointer declared like: var p: ptr = cast[ptr](0x1000), or the correct syntax. I then tried to do p[] = 'A' for which I got a very strange error messages about mismatched types and what it expected. |
19:51:19 | Araq | it recently got a runtime race detector for a reason |
19:52:51 | Sergio965 | How does the type system encourage races? |
19:53:39 | Araq | it's very easy to capture a variable in a closure and access it concurrently |
19:53:39 | Sergio965 | (the solution was to do ptr char instead of just ptr). |
19:54:16 | Sergio965 | How is that Go's problem? |
19:54:48 | Sergio965 | If you ever share memory, you're going to have races. |
19:55:05 | Araq | nope, static typing can prevent them |
19:55:34 | Sergio965 | Go is statically typed. |
19:55:38 | Araq | see? |
19:56:44 | Sergio965 | Sorry, perhaps I don't understand enough about type systems, but how can static typing prevent data races? |
19:57:00 | dom96 | Sergio965: In regards to the cryptic error messages. Could you give us a quoted example and then suggest how you think it can be improved? |
19:57:27 | Sergio965 | dom96: Will do. |
19:57:44 | Sergio965 | dom96: (Once I'm back in the lab.) |
19:58:03 | dom96 | Sergio965: great. |
19:58:29 | Araq | Sergio965: there is lots of literature about it, I'm working on a blog post how it will work in Nimrod |
19:58:46 | gradha | Araq: what? You have a blog? |
19:59:29 | Sergio965 | Araq: Without locking? |
20:00:09 | Araq | Sergio965: locking is mostly orthogonal to a type system |
20:00:37 | Araq | gradha: well I finished my first blog post, still working on the website ... :P |
20:00:53 | Sergio965 | I concur. What's the gist of your idea? I believe I understand what static typing is and I cannot fathom how it can be used to wholly prevent data races. |
20:01:43 | gradha | Araq: nice, I recently started playing with static blog generation at https://github.com/gradha/gradha.github.io, I tried jekyll but would refuse to install or break my other ruby stuff so ended up with python |
20:01:59 | * | fowl quit (Changing host) |
20:01:59 | * | fowl joined #nimrod |
20:02:17 | Sergio965 | gradha: Isn't Jekyll a gem? Why would it break your other stuff? |
20:02:59 | fowl | gradha, you just gem install jekyll, newb |
20:03:00 | gradha | because to use jekyll you need to install some other fancy stuff, which when installed doesn't work with previous older stuff, plus in the middle of the installation it downloaded gems which would not compile themselves |
20:03:17 | dom96 | fowl: If only it were that simple. |
20:03:26 | Sergio965 | It is with bundler. |
20:03:30 | dom96 | Funnily enough the problem for me was Python. |
20:03:31 | gradha | fowl: indeed, I did that, and if failed hard, so hard it left my local gems in an unusable state and had to recover from a backup |
20:03:56 | Sergio965 | http://gembundler.com/ |
20:04:06 | Araq | Sergio965: everything that is shared needs to be annotated as shared explicitly and read/write accesses to a shared type can only happen in a "lock" or "atomic" section |
20:04:34 | Araq | you can easily special case atomicInc etc. and also CAS |
20:04:52 | fowl | gradha, i just installed it, no problems here |
20:04:58 | fowl | maybe its that broken BSD stuff you call os x |
20:05:24 | Sergio965 | Araq: Ah, but that's augmenting the typical type system. Sure, I agree that a complex type system (when used correctly) can prevent data races. |
20:05:34 | gradha | fowl: it surely is, maybe I should install a vm to run ruby software under windows… |
20:05:57 | Sergio965 | Windows? That's your problem. |
20:06:05 | Araq | Sergio965: but you can't expect to support a hard thing like concurrency without augmenting the type system |
20:06:05 | fowl | windows is generally more reliable than os x |
20:06:11 | Sergio965 | Ruby + Windows = not so great. |
20:06:17 | Sergio965 | Say what? |
20:06:17 | gradha | Sergio965: millions use it, can't be wrong |
20:06:43 | Sergio965 | Windows is a great OS for most things, but I have found it to be terrible for most everything I do. |
20:07:06 | Sergio965 | Mostly, I love Unix. |
20:07:35 | gradha | fowl: maybe you can help me debug the ruby installation stuff? |
20:07:41 | EXetoC | here's to unix! |
20:07:47 | EXetoC | hm, where's my milk? |
20:08:04 | fowl | gradha, i can soon, but not today |
20:08:25 | fowl | gradha, i have to go out and make some $ today |
20:08:26 | gradha | still, even if I run jekyll my redmine will stop working |
20:08:41 | gradha | unless I update it too, I guess |
20:08:45 | fowl | im the guy on the side of the road with the "javascript kills" sign |
20:08:57 | fowl | redmine? the issue tracker? |
20:09:01 | gradha | yep |
20:09:28 | Sergio965 | Araq: I completely agree. But it introduces an additional level of complexity and burden to the programmer. Now, I have to remember more and more about what each variable is. Further, I have to remember to label (type) my variables correctly. Abstractions remove some of the cognitive load. In Go, for example, channels provide an easy to understand and efficient way to deal with concurrency and race conditions. |
20:10:12 | Araq | it's not an additional level of complexity really |
20:10:25 | gradha | fowl: so you are going to go and kill some javascript user? |
20:10:44 | Araq | when I develop multi threaded software in C# I have to do exactly that: keep in mind what's "shared" and what's not |
20:10:46 | fowl | gradha, no im going to fly a sign that says i need $ for a bus pass |
20:10:51 | fowl | which is true, thats what i use it for |
20:11:03 | Sergio965 | Of course it is. If I forget to mark a variable shared and I use it as if it's shared, I will very unexpected results. |
20:11:09 | Sergio965 | Perhaps it's simply two sides of the same coin. |
20:11:13 | Araq | and if it is shared, I need to "lock" it |
20:11:28 | Araq | it makes perfect sense to add it the type system |
20:11:32 | Araq | *to the |
20:11:58 | Sergio965 | Hmm, yeah. I can certainly see the argument for it. |
20:12:01 | Araq | it's much like dynamic typing in python |
20:12:37 | Araq | Ignoring types at development in a dynamically typed language does not produce code that magically works; what dynamic typing really does is: It offloads the type |
20:12:38 | Araq | checking to the poor human programmer for no good reason. |
20:12:40 | Sergio965 | Are there coroutines in Nimrod? |
20:12:53 | gradha | ok, made a copy of my gems, now let's unleash hell: gem install jekyll |
20:13:40 | Araq | Sergio965: no we only got python-like generators |
20:14:29 | Sergio965 | I found the ability to model both data synchronization and coroutines with channels in Go to be immensely useful. |
20:14:52 | EXetoC | is there a print function that prints the expression in addition to the value? |
20:15:21 | Araq | EXetoC: there is a debug macro in the manual/tutorial |
20:15:30 | EXetoC | thanks |
20:16:48 | Araq | Sergio965: conflating concurrency and control flow sucks |
20:17:40 | Araq | 'yield' is control flow, don't make me check for races just because you only got "goroutines" |
20:18:05 | Araq | these things should be kept separate |
20:19:06 | Araq | likewise don't misuse concurrency for exception handling; exception handling is deterministic; concurrency is not |
20:20:07 | Sergio965 | Where does the latter happen? |
20:21:47 | Araq | Rust tried the latter, nowadays it got a Lisp style condition system instead that apparently nobody uses |
20:22:26 | EXetoC | that macro? |
20:22:28 | Sergio965 | And are you advocating for only every using one abstraction for one thing? Channels do one thing: they synchronize the execution of two concurrently running routines. |
20:23:02 | Sergio965 | I don't think being able to use it to multiple effects is inherently poor design. |
20:23:35 | Araq | it is poor design because the abstraction is too powerful |
20:23:50 | Araq | you want Nimrod's iterators but instead you use a concurrency mechanism |
20:23:54 | Sergio965 | So then you are advocating against powerful abstractions? |
20:24:11 | Sergio965 | (Simply trying to understand your argument.) |
20:24:42 | Araq | I'm advocating against using non deterministic contructs for emulating deterministic ones |
20:24:56 | Araq | just because it "keeps the language small this way" |
20:25:23 | gradha | fowl: there you go http://pastebin.com/bPy1qy7e though I really don't care about it, just like I close websites if they load flash I uninstall software that refuses to work |
20:25:56 | fowl | gradha, it installed fine, thats rdoc or ri that failed |
20:26:00 | fowl | (documentation) |
20:26:55 | gradha | so in theory I could update redmine and live happy with half broken gems? |
20:27:13 | Sergio965 | gradha: They're not broken. What failed was the building of the documentation. |
20:27:25 | fowl | gradha, they arent broken..just the documentation |
20:27:32 | Sergio965 | Try adding --no-ri --no-rdoc to the gem command. |
20:27:33 | fowl | is missing |
20:27:56 | gradha | maybe rubyist don't need stinking docs? |
20:28:04 | Sergio965 | Araq: I think that's a fair argument. |
20:28:24 | Sergio965 | Araq: But I also believe that there are fair arguments for such constructs. |
20:28:38 | Sergio965 | Araq: Well, very specific instances of them, like channels. |
20:28:48 | Araq | Nimrod has channels btw |
20:28:58 | Araq | it's just that we don't use them for iterators |
20:29:05 | Araq | because that's brain dead |
20:29:09 | Sergio965 | Lol |
20:29:14 | Sergio965 | Go doesn't use them for iterators either. |
20:29:24 | Sergio965 | Well. |
20:29:54 | Sergio965 | I don't. I haven't seen it advocated for by anybody at Google. |
20:30:43 | Araq | I read a blog post from the developers iirc |
20:30:56 | Araq | where they show how to write an iterator using channels |
20:31:03 | Araq | but I could be wrong |
20:31:13 | Sergio965 | Yeah, I've certainly seen it too. |
20:31:21 | gradha | fowl: are the docs always generated last or could there be some other dependency left unprocessed and give problems in the future? |
20:31:41 | Sergio965 | But I saw Rob Pike's talk about GoRoutine patterns, and he didn't mention iterators as one of them. |
20:31:52 | Sergio965 | gradha: Just do --no-ri --no-rdoc. |
20:31:54 | fowl | gradha, bro i can only say this so many times, the install was fine, just the docs messed up |
20:32:06 | fowl | there's no need to do that --no-ri --no-rdoc, its already installed |
20:32:11 | fowl | use those in the future though |
20:32:26 | Sergio965 | fowl: Indeed. But I feel like he needs to see it succeed to feel comfortable. |
20:32:55 | gradha | well, when you know nothing about X, and installation throws up a screen of errors which google doesn't show anything about... you are left wondering if its safe |
20:33:39 | gradha | I've had previous cases were a debian package would not process and leave other dependencies half installed, giving subtle problems in the future |
20:34:14 | Sergio965 | Or you could just do --no-ri --no-rdoc, see it succeed, and be content. :) |
20:34:53 | gradha | Sergio965: sure, but I know about that now, not the several times I've tried to install gems and something failed like that |
20:35:08 | gradha | not precisely a newbie friendly installation process |
20:35:10 | Sergio965 | Araq: Now I'm curious. Which languages _do_ you like? |
20:39:15 | Araq | syntactically? nothing except Nimrod. Semantically? Ada and Modula 3 |
20:40:03 | Araq | and ML but that's in a class of its own |
20:40:47 | Sergio965 | Do you like OCaml? |
20:42:21 | Araq | not that much |
20:43:05 | Araq | if your type system needs to special case "array of float" for efficiency, your type system is wrong IMHO |
20:56:16 | EXetoC | seems like an odd corner case |
21:06:06 | EXetoC | two-space indentation is disorienting sometimes |
21:06:31 | EXetoC | my eyesight isn't the best though |
21:08:31 | * | Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
21:11:50 | EXetoC | I'm having a go at fixing this skModule issue, but I'll have to build the compiler with debug stuff on I guess |
21:17:44 | * | Sergio965 joined #nimrod |
21:19:08 | EXetoC | who is adding those awful windows newlines? :> |
21:19:29 | gradha | sounds like you are using vim |
21:19:49 | Sergio965 | Why wouldn't he? Vim is god's editor, if there is a god. |
21:20:07 | EXetoC | fo shizzle! |
21:24:40 | EXetoC | unix line endings seems to be the de facto standard, and this can be automated with git, which is nice |
21:25:09 | Araq | on windows windows line endings are the de facto standard ... |
21:26:46 | * | gradha remembers the first rule of the tautology club, which is the first rule of the tautology club |
21:28:14 | Araq | windows still has 80% market share ... |
21:29:20 | Sergio965 | Not when it comes to programmers. |
21:29:47 | gradha | is the market share inside the windows platform still 80% xp? |
21:30:35 | gradha | I listen to the security now podcast and they will have to pry their xp from their cold dead fingers... |
21:30:53 | EXetoC | I meant for open source code, but maybe I'm wrong. anyway, Sergio965 is probably right on that one :> |
21:31:34 | gradha | they even have a countdown of official support days for xp or something like that, still a year IIRC |
21:33:29 | gradha | http://blogs.windows.com/windows/b/springboard/archive/2013/04/08/365-days-remaining-until-xp-end-of-support-the-countdown-begins.aspx |
21:34:03 | gradha | so we still have about 284 days of xp support, phew |
21:37:21 | EXetoC | do I have to explicitly enable something in order to get a compiler stack trace (when release isn't defined of course)? |
21:38:00 | gradha | not compiling with -d:release should be enough |
21:39:00 | EXetoC | gradha: you know what? I never actually installed the package :> works now |
21:39:00 | gradha | just ./koch boot gives me stacktraces when I need to report them, maybe you are running a different binary on your $PATH? |
21:39:57 | gradha | I have a script which compiles me a nimrodd for debug and nimrod for release, so I have both at the same time on my path and can switch to one or the other any time |
21:40:34 | gradha | because you really don't want to use a debug version for idetools support |
21:42:32 | EXetoC | yeah |
21:45:53 | Araq | who uses idetools? I thought it's unusable ... |
21:47:03 | gradha | actually I've been using it less lately because zahary_ "improved" the vim integration to the point it works less than previously |
21:47:08 | EXetoC | "proc expr(p: BProc, n: PNode, d: var TLoc)" so n.kind == nkSym and n.sym.Kind == skModule, so it takes this branch: else: InternalError(n.info, "expr(" & $sym.kind & "); unknown symbol") |
21:47:56 | Araq | EXetoC: that's the easy part. the question is why the frontend didn't eliminate the skModule sym |
21:49:14 | EXetoC | Araq: I don't know, but I insert this into my ASTnewCall("invariant", firstparam) and invariant is also the name of the module which is the problem |
21:50:22 | Araq | btw you know 'assert' already exists, right? |
21:52:51 | EXetoC | Araq: yes. this is for defining type invariants |
21:55:28 | EXetoC | or rather registering a function with some invariant, which will then be called at the beginning of the function, and right before any values are returned |
21:57:35 | Araq | return x --> (let y = x; invariant(y); return y) seems to be the hardest part of it |
21:58:33 | EXetoC | I guess so |
22:03:48 | EXetoC | actually, the argument of invariant would be that of the first argument of the caller, but that doesn't change much |
22:05:32 | * | q66 quit (Remote host closed the connection) |
22:06:03 | EXetoC | no wait, maybe it's skMacro |
22:06:14 | * | OrionPK joined #nimrod |
22:09:10 | EXetoC | yup... |
22:12:12 | OrionPK | so anyone know anything about this SSL issue with windows? |
22:12:24 | OrionPK | could not import: CRYPTO_set_mem_functions |
22:12:37 | OrionPK | basically can't use httpclient, or anything depending on it |
22:13:42 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=1ZZC82dgJr8 again) |
22:14:33 | EXetoC | so I get an exception when just the macro that contains newCall("invariant", firstparam) is called invariant, but when both the macro and the module is named the same, then skMacro gets passed to ccgexprs.expr, which isn't handled |
22:14:54 | Araq | OrionPK: it shouldn't support SSL unless you passed -d:ssl to the compiler |
22:15:08 | EXetoC | I know, I should create a test case and/or report a bug |
22:15:09 | OrionPK | Araq: yep, that's there |
22:15:37 | OrionPK | without that, I just get a "Cannot connect over SSL" error |
22:15:55 | OrionPK | not "could not import CRYPTO_set_mem_functions" |
22:16:13 | Araq | yeah well ... so you need SSL support |
22:16:26 | OrionPK | babel does |
22:17:28 | Araq | do you have ssleay32.dll? |
22:17:52 | OrionPK | yeah |
22:18:16 | OrionPK | without that I would get could not load: (ssleay32|libssl32).dll |
22:18:32 | OrionPK | brb |
22:18:49 | OrionPK | LoadLibrary succeeds |
22:19:15 | Araq | open wrappers/openssl.nim |
22:19:21 | Araq | line 272 |
22:19:34 | Araq | wrap that call in an 'when not defined(windows)' |
22:20:22 | Araq | and that code looks suspicious anyway |
22:21:40 | OrionPK | k, 2 secs |
22:23:19 | OrionPK | now it's ERR_load_BIO_strings |
22:23:28 | OrionPK | instead of CRYPTO_set_mem_functions |
22:25:08 | Araq | edit line 199 |
22:25:46 | Araq | chang the dynlib to DLLUtilName |
22:27:26 | OrionPK | also had to switch OpenSSL_add_all_algorithms |
22:27:29 | OrionPK | to DLLUtilName |
22:27:33 | OrionPK | but now she works |
22:27:48 | Araq | please submit a pull request |
22:27:52 | OrionPK | mmk |
22:28:05 | Araq | oh well, never mind |
22:28:15 | OrionPK | I can test it on my mac as well... |
22:28:16 | OrionPK | hm? |
22:28:25 | Araq | that would be great |
22:30:33 | dom96 | shouldn't dead code elimination take care of these errors? |
22:30:46 | Araq | dom96: you do call these |
22:31:03 | Araq | the compiler can't eliminate code that's really used |
22:32:00 | dom96 | how does getting rid of it on Windows help then? |
22:32:25 | Araq | we only got rid of set_mem_functions |
22:32:35 | OrionPK | yeap, still works on my mac w/ the modified code |
22:32:42 | Araq | which means openssl will use its own memory allocator |
22:32:43 | OrionPK | dont have a linux comp to test on |
22:33:00 | Araq | hardly a loss |
22:46:32 | reactormonk | how do I control the eval-or-not in templates? http://sprunge.us/BOUN |
22:48:45 | Araq | why is that an interesting question for your wrong template? |
22:57:08 | reactormonk | wrong template? |
22:59:51 | reactormonk | allocate space, copy stuff into it. Problem? |
23:00:49 | Araq | var to: T # seriously? |
23:01:08 | Araq | memcpy(from, to) # seriously? no 3rd argument? |
23:01:20 | Araq | and isn't the order (dest, src)? |
23:01:28 | reactormonk | not sure, can do that |
23:01:35 | reactormonk | yup, no third argument. We have types here. |
23:01:47 | Araq | prog_ptr[T] # seriously? no need to declare T? |
23:02:11 | reactormonk | forgot that part |
23:02:58 | reactormonk | http://sprunge.us/AfbY |
23:03:02 | reactormonk | now you have three arguments |
23:04:42 | Araq | now 'to' is unused |
23:04:50 | Araq | and there are still only 2 arguments |
23:10:47 | OrionPK | hrm.. babel has further issues it looks like |
23:11:02 | OrionPK | trying to get a tempdir in downloadPkg |
23:11:17 | OrionPK | No such file or directory |
23:11:57 | reactormonk | Araq, why do I need a third argument? |
23:12:39 | Araq | reactormonk: http://www.acm.uiuc.edu/webmonkeys/book/c_guide/2.14.html#memcpy |
23:12:40 | dom96 | OrionPK: indeed. I never tested it on Windows. The code is probably very linux specific. |
23:12:51 | OrionPK | presumably other platforms will automagically create the directory |
23:12:55 | OrionPK | or something |
23:13:14 | Araq | nah, it's something else |
23:13:46 | OrionPK | or something with executing git? |
23:13:51 | OrionPK | "fatal: could not create work tree dir" |
23:16:18 | reactormonk | Araq, well, my size comes from the type |
23:16:37 | reactormonk | proc memcpy[T](dest: ptr T, pgm: prog_ptr[T]) that's the signature. I query the size via sizeof(T) |
23:17:21 | dom96 | OrionPK: Perhaps on Windows, git can't create the directory structure that babel passes to it? |
23:17:22 | Araq | reactormonk: give it a real name then, that's just confusing |
23:17:34 | Araq | good night |
23:17:55 | dom96 | OrionPK: Try running 'git clone urlhere C:/some/download/path/which/doesn't/exist', and see if it creates it |
23:17:57 | OrionPK | dom96 perhaps.. i'll try running the command from the shell |
23:17:57 | reactormonk | Araq, gimme a better name then. |
23:25:14 | OrionPK | dom96: yeah, the git clone command itself is failing |
23:25:14 | OrionPK | No such file or directory |
23:25:14 | reactormonk | OrionPK, uh-oh |
23:25:14 | dom96 | OrionPK: weird. Add a createDir(downloadDir) after babel.nim:245 I guess. |
23:25:15 | OrionPK | yeah it gets further now ;) |
23:25:25 | OrionPK | git exits abnormally though |
23:25:58 | OrionPK | The system cannot find the file specified |
23:50:29 | * | Sergio965 quit (Ping timeout: 248 seconds) |