| 00:03:08 | * | ltbarcly joined #nimrod |
| 00:06:43 | * | ltbarcly quit (Client Quit) |
| 00:09:41 | * | xilo joined #nimrod |
| 00:34:18 | * | filwit joined #nimrod |
| 00:34:27 | filwit | hi folks |
| 00:34:44 | filwit | i'm looking for a way to do this: https://gist.github.com/PhilipWitte/6772348 |
| 00:35:31 | filwit | i can easily make a macro to add the extra parameter to the procs, but I can't figure out how to manipulate the return type |
| 00:35:54 | filwit | Araq mentioned before that the return type is deduced, and there's no direct way to set it |
| 00:35:56 | fowl | filwit, return type is the first thing in formalparams |
| 00:36:08 | filwit | ahhh, awesome |
| 00:36:14 | fowl | dumptree: proc x: int = 0 |
| 00:36:29 | filwit | let me try that real quick |
| 00:45:02 | * | zahary1 quit (Ping timeout: 240 seconds) |
| 00:48:13 | filwit | thanks fowl, not done yet but i think that did it |
| 00:53:48 | fowl | np |
| 00:54:49 | * | Yeri joined #nimrod |
| 00:55:11 | * | Yeri left #nimrod (#nimrod) |
| 01:05:36 | filwit | fowl: can you tell me how to convert a typedesc to a NimNode? |
| 01:06:05 | filwit | aka: var node = Foo.toAst() # Foo is a typedesc |
| 01:06:35 | fowl | make it take an expression |
| 01:06:50 | filwit | yeah, i know |
| 01:07:04 | filwit | but i need it as a typedesc, or rather, i have the same problem i need both |
| 01:07:13 | fowl | why do you need that |
| 01:07:16 | filwit | so i have to convert from one to the other |
| 01:07:26 | filwit | nevermind, i just do |
| 01:07:32 | fowl | i dont think you do |
| 01:07:48 | fowl | not for the return type |
| 01:07:49 | filwit | but i just noticed that there's a getAst() in Macros |
| 01:07:57 | filwit | it's not for the return type |
| 01:08:20 | filwit | it's for the first param |
| 01:08:31 | fowl | that can be an identifier.. |
| 01:08:46 | filwit | well, i tried, it failed... |
| 01:09:04 | fowl | paste |
| 01:09:15 | filwit | what i need is: proc new(desc:typedesc[Foo], ...): Foo = ... |
| 01:09:25 | filwit | so i can use it as: Foo.new(...) |
| 01:09:26 | fowl | oh |
| 01:09:37 | fowl | dumptree that then |
| 01:09:45 | filwit | ahh. ofc |
| 01:09:51 | filwit | i always forget to do that |
| 01:12:07 | fowl | you should be able to use macros.insert to inject the first param |
| 01:12:17 | fowl | btw did you see my class macro |
| 01:12:24 | filwit | yeah, i'm already injecting things and it's working |
| 01:12:35 | filwit | no, i don't think i saw your class macro |
| 01:12:40 | filwit | but i saw Adrians |
| 01:12:47 | filwit | i would like to see yours too though |
| 01:13:09 | fowl | https://github.com/fowlmouth/nimlibs/blob/master/fowltek/classlib.nim |
| 01:13:10 | filwit | but i'm making something pretty specific, so I probably can't use other's solutions |
| 01:13:12 | filwit | thanks |
| 01:13:33 | fowl | it does some similar stuff to what you're doing |
| 01:19:47 | * | q66 quit (Quit: Leaving) |
| 01:20:21 | filwit | got it to work with Macros.parseExpr(T) |
| 01:20:31 | * | zahary joined #nimrod |
| 01:26:15 | * | zahary quit (Read error: Connection reset by peer) |
| 01:26:25 | * | zahary joined #nimrod |
| 01:31:17 | * | DAddYE quit (Remote host closed the connection) |
| 01:31:52 | * | DAddYE joined #nimrod |
| 01:36:01 | * | filwit quit (Quit: Leaving) |
| 01:36:27 | * | DAddYE quit (Ping timeout: 248 seconds) |
| 01:41:41 | * | filwit joined #nimrod |
| 01:41:58 | filwit | hey fowl, one last thing |
| 01:42:00 | filwit | https://gist.github.com/PhilipWitte/6772348 |
| 01:42:10 | filwit | on lines 41 - 61 |
| 01:42:18 | filwit | is my benchmark |
| 01:42:25 | filwit | but the result is very inconsistent |
| 01:43:20 | * | MFlamer quit (Quit: Page closed) |
| 01:43:30 | filwit | aka, if i run it at a repeat count of 1.. the result is sometimes like 2... and if i run it @100000, you can tell it takes longer, but the result is never more than say 5.8 |
| 01:44:30 | filwit | i would think it was epochTime() vs cpuTime().. but the results seem just as inconsistent with epochTime() |
| 01:45:49 | filwit | whoops, typo on line 57 |
| 01:46:27 | fowl | ? |
| 01:46:29 | fowl | whats the q |
| 01:46:52 | filwit | why aren't the cpuTime/epochTime working? |
| 01:46:58 | filwit | they seem to roll over or something |
| 01:47:29 | filwit | it reports the same result if i run it at 1,000,000 or 10,000,000 even though i can tell it takes longer to run |
| 01:48:08 | filwit | any idea why that is? |
| 01:48:16 | fowl | no |
| 01:48:23 | filwit | okay.. |
| 01:48:29 | filwit | well thanks anyways |
| 01:48:29 | fowl | i thought there was a benchmark template or something |
| 01:48:33 | fowl | like benchmark: code |
| 01:48:43 | filwit | yeah i was asking about that before |
| 01:48:47 | filwit | but no one responded |
| 01:48:56 | filwit | and my searches came up short |
| 01:50:38 | fowl | im pretty sure you want epochtime that will measure real time |
| 01:50:48 | fowl | the alternative of course is just use `time` |
| 01:51:15 | filwit | yeah i've tried with epochTime, but it's the same thing.. idk why |
| 02:01:50 | * | filwit quit (Quit: Leaving) |
| 02:23:49 | * | ltbarcly joined #nimrod |
| 02:32:19 | * | DAddYE joined #nimrod |
| 02:38:45 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 02:59:11 | * | fowl quit (Quit: Leaving) |
| 03:30:39 | * | MFlamer joined #nimrod |
| 03:35:18 | * | DAddYE joined #nimrod |
| 03:41:41 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 03:46:26 | * | OrionPK quit (Read error: Connection reset by peer) |
| 04:18:11 | * | MFlamer quit (Ping timeout: 250 seconds) |
| 04:38:29 | * | DAddYE joined #nimrod |
| 04:45:15 | * | DAddYE quit (Ping timeout: 248 seconds) |
| 04:51:31 | * | Associat0r quit (Quit: Associat0r) |
| 05:10:39 | * | xilo quit (Read error: Operation timed out) |
| 05:24:53 | * | ltbarcly quit (Quit: Computer has gone to sleep.) |
| 05:28:59 | * | brson quit (Quit: leaving) |
| 05:30:54 | * | ltbarcly joined #nimrod |
| 05:40:52 | * | dyu joined #nimrod |
| 05:41:35 | * | DAddYE joined #nimrod |
| 05:47:26 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 06:24:04 | * | DAddYE joined #nimrod |
| 06:35:19 | * | dyu quit (Disconnected by services) |
| 06:35:44 | * | dyu_ joined #nimrod |
| 07:26:01 | * | DAddYE quit (Remote host closed the connection) |
| 07:26:32 | * | DAddYE joined #nimrod |
| 07:30:57 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 08:05:16 | * | filwit joined #nimrod |
| 08:27:08 | * | DAddYE joined #nimrod |
| 08:31:16 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 08:47:19 | * | filwit quit (Quit: Leaving) |
| 09:28:00 | * | DAddYE joined #nimrod |
| 09:28:16 | * | Associat0r joined #nimrod |
| 09:28:16 | * | Associat0r quit (Changing host) |
| 09:28:16 | * | Associat0r joined #nimrod |
| 09:34:10 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 09:59:02 | * | q66 joined #nimrod |
| 10:06:03 | * | Araq_ joined #nimrod |
| 10:06:16 | * | Araq_ quit (Client Quit) |
| 10:37:20 | * | EXetoC quit (Ping timeout: 260 seconds) |
| 10:56:43 | * | EXetoC joined #nimrod |
| 10:59:03 | * | ltbarcly quit (Quit: Computer has gone to sleep.) |
| 11:05:14 | * | ltbarcly joined #nimrod |
| 11:31:16 | * | Associat0r quit (Quit: Associat0r) |
| 11:31:58 | * | DAddYE joined #nimrod |
| 11:37:50 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 11:55:12 | * | faassen joined #nimrod |
| 11:56:35 | * | ltbarcly quit (Quit: Computer has gone to sleep.) |
| 12:04:01 | dyu_ | https://news.ycombinator.com/item?id=6464127 - "When I looked at Nimrod it seemed very raw to me: REPL malfunctions and crashes, the whole language seems to be more an enthusiast effort than a production-quality tool. Rust is very raw too, but it already looks pretty solid." |
| 12:09:40 | profmakx | O.o |
| 12:09:43 | profmakx | wat? |
| 12:11:36 | dyu_ | yep |
| 12:12:50 | profmakx | oh well. someone is wrong on the internet |
| 12:13:14 | dyu_ | "enthusiast effort" - probably because there is no known production app using nimrod |
| 12:15:18 | profmakx | well, people use words |
| 12:15:35 | profmakx | that sounds like an academic or something being full of themselves |
| 12:15:43 | profmakx | this is the kind of phrase some people use in peer review |
| 12:20:39 | dyu_ | I do believe nimrod is really close to 1.0 though its the fact that the language has so much features and too few developers (and part-time) working on the compiler which kinda drags it a bit |
| 12:27:35 | profmakx | hands down nimrod, in my opinion, is one of the most exciting "niche" langauges i have seen in heck of a long time. and it compiled straight away on dragonflybsd |
| 12:27:46 | profmakx | something I can't say about haskell or any other more involved piece of software |
| 12:27:55 | profmakx | s/haskell/ghc/ |
| 12:29:16 | dyu_ | nimrod definitely has all the power, especially with metaprogramming ... |
| 12:30:09 | dyu_ | For me though, I only want the speed of nimrod + elegance of its syntax but the simplicity of golang |
| 12:31:03 | profmakx | we are looking into nimrod for re-writing (parts of) a computer algebra system |
| 12:33:07 | dyu_ | profmakx: what was the language of the original codebase? |
| 12:33:30 | profmakx | C |
| 12:33:42 | profmakx | most code is mid 90ies |
| 12:34:06 | dyu_ | yep. nimrod is a perfect fit since you don't lose any of the runtime speed, yet gain development speed |
| 12:34:54 | dyu_ | what other language did you consider before nimrod? |
| 12:40:33 | profmakx | rust is on the list |
| 12:40:35 | profmakx | and go |
| 12:45:00 | * | EXetoC quit (Ping timeout: 252 seconds) |
| 12:45:09 | dyu_ | if you have lots of c ffi, you might not wanna choose go |
| 12:45:40 | profmakx | if the whole system is ported then there'll be zero ffi |
| 12:47:55 | dyu_ | yea ofc, if its trivial to port eveything to c |
| 12:48:09 | dyu_ | to go* |
| 12:56:25 | * | wlhlm joined #nimrod |
| 13:05:03 | * | EXetoC joined #nimrod |
| 13:13:36 | * | OrionPK joined #nimrod |
| 13:35:07 | * | DAddYE joined #nimrod |
| 13:41:40 | * | DAddYE quit (Ping timeout: 246 seconds) |
| 14:00:36 | * | faassen left #nimrod (#nimrod) |
| 14:12:26 | * | Associat0r joined #nimrod |
| 14:12:26 | * | Associat0r quit (Changing host) |
| 14:12:26 | * | Associat0r joined #nimrod |
| 14:33:46 | * | shevy quit (Ping timeout: 245 seconds) |
| 14:46:22 | * | shevy joined #nimrod |
| 15:15:57 | dom96 | dyu_: Why don't you correct the guy? |
| 15:16:09 | dyu_ | no hn account :-) |
| 15:17:35 | dom96 | huh, I could have sworn that I suggested Nimrod to that 0install guyy |
| 15:18:06 | dom96 | yep, I have in his previous post: http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ |
| 15:18:24 | dom96 | and someone else has too |
| 15:20:09 | dyu_ | yep |
| 15:20:11 | dyu_ | "Maybe Nimrod is an alternative. It's a bit more mature than Rust and a bit more high level. It also has Python-like syntax." |
| 15:20:35 | dom96 | Tell the guy again someone :P |
| 15:20:38 | dyu_ | though i'm not entirely sure about nimrod being more mature |
| 15:20:55 | dyu_ | the core is definitely mature |
| 15:21:13 | dyu_ | but there are lots of unmaintained modules in nimrod's repo |
| 15:21:42 | dom96 | I think Rust is still very much in flux but it's becoming stable very quickly. No wonder since they have a couple of full time paid developers working on it. |
| 15:21:58 | dyu_ | yep. They hired the regular contributors |
| 15:23:54 | dyu_ | i just benchmarked rust's c ffi a minute ago ... its right up there with nimrod with the zero-overhead ffi |
| 15:24:46 | dom96 | You should submit your benchmarks to reddit or HN |
| 15:27:59 | dyu_ | perhaps |
| 15:30:19 | dom96 | well, I replied to that guy on HN |
| 15:31:16 | * | fowl joined #nimrod |
| 15:34:21 | dyu_ | hehe, you gave him the whole nine yards |
| 15:34:32 | dom96 | yep :P |
| 15:34:45 | fowl | hi there |
| 15:36:03 | dom96 | hey fowl |
| 15:36:32 | fowl | slightly on topic, the repl is kinda annoying |
| 15:36:40 | fowl | one error and you're out of the game |
| 15:36:45 | dom96 | damn, gradha is really doing some extreme testing of ipsum genera. My repo now has 16 issues. |
| 15:36:54 | dom96 | fowl: Indeed. I agree. |
| 15:37:12 | fowl | whats ipsum genera? on your github or nimrod-code |
| 15:37:23 | dom96 | I never use it though because it doesn't support the FFI |
| 15:37:28 | dom96 | on my github |
| 15:37:32 | dyu_ | dom96: do you know a way to emulate duck typing similar to rust/go (using interfaces) in nimrod? |
| 15:37:34 | dom96 | it's a static blog generator |
| 15:37:56 | dom96 | dyu_: Macros maybe |
| 15:38:10 | dom96 | dyu_: I would need an example. Not familiar with Go/Rust much. |
| 15:38:36 | * | DAddYE joined #nimrod |
| 15:38:54 | dyu_ | dom96: nimrod already has the method but its a dynamic dispatch |
| 15:38:56 | fowl | dyu_, you could say type ISomething = TBlah or TFoo |
| 15:39:00 | dyu_ | 'method' |
| 15:39:16 | dyu_ | the interface would be basically a compile-time constraint |
| 15:39:30 | fowl | dyu_, i used this method to get around multiple inheritance for a C++ wrapper |
| 15:39:32 | dyu_ | that a struct/object should have these methods |
| 15:39:48 | dom96 | dyu_: I think you want type classes. |
| 15:39:59 | dom96 | Which zahary implemented, or is in the process of implementing. |
| 15:40:24 | dyu_ | oh ok. traits and stuff |
| 15:40:28 | dyu_ | like scala |
| 15:40:56 | dom96 | Take a look at this thread: http://forum.nimrod-code.org/t/208 |
| 15:42:19 | fowl | cool |
| 15:42:52 | dyu_ | it seems the syntax is not yet set in stone as araq and zahary have different views on it |
| 15:43:05 | dyu_ | based from that thread |
| 15:43:45 | dyu_ | but yea, it is indeed a good solution |
| 15:44:52 | dom96 | yeah. But I have a suspicion that it may be unstable for quite some time. |
| 15:45:00 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 15:52:50 | dyu_ | it looks pretty complicated |
| 15:54:37 | dyu_ | we could simply copy scala's way of doing it (http://danielwestheide.com/blog/2013/02/06/the-neophytes-guide-to-scala-part-12-type-classes.html) |
| 15:55:12 | dyu_ | and if you look at it, scala's syntax is really similar to nimrod's except the braces |
| 15:57:20 | dyu_ | http://pastebin.com/Qsd34BZ6 |
| 15:58:38 | dom96 | Aren't they pretty much the same thing as the ones described in the thread? |
| 15:59:09 | * | q66_ joined #nimrod |
| 15:59:43 | dom96 | I guess the ones zahary has in mind are even more complicated |
| 16:00:07 | dyu_ | yep, that's what I meant |
| 16:00:23 | * | q66 quit (Disconnected by services) |
| 16:00:27 | * | q66_ is now known as q66 |
| 16:11:56 | * | dyu_ quit (Quit: Leaving) |
| 16:23:04 | * | DAddYE joined #nimrod |
| 16:36:33 | * | io2 joined #nimrod |
| 17:01:45 | * | brson joined #nimrod |
| 17:04:28 | * | EXetoC quit (Ping timeout: 240 seconds) |
| 17:20:07 | Araq | in fact, I think we simply should disable the REPL |
| 17:20:19 | Araq | it's unstable and sucks |
| 17:23:00 | Araq | on the other hand ... if you use it and take it as a measure of the stability of the language that's your problem |
| 17:23:30 | Araq | everybody with half a brain can see that it uses a whole different backend ... |
| 17:27:03 | * | EXetoC joined #nimrod |
| 17:30:00 | fowl | perhaps a warning would suffice |
| 17:30:29 | Araq | meh then people will find the next show stopper |
| 17:30:54 | Araq | it doesn't really matter |
| 17:31:10 | Araq | it's always much easier to complain about forward decls than learning a new language I guess |
| 17:41:30 | * | ltbarcly joined #nimrod |
| 17:43:03 | EXetoC | is compilation faster when not using noforward? I'm guessing there's a practical difference since we have a choice |
| 17:43:04 | * | fowl quit (Read error: Connection reset by peer) |
| 17:43:25 | EXetoC | anyway, I never thought about forward declaring symbols explicitly. I might start doing that |
| 17:43:31 | EXetoC | proc foo() |
| 17:43:47 | Araq | do |
| 17:43:48 | Araq | not |
| 17:43:53 | Araq | use .noforward |
| 17:44:04 | Araq | I'll remove it from the docs soon |
| 17:44:09 | EXetoC | I haven't |
| 17:44:16 | EXetoC | right |
| 17:44:36 | Araq | also good luck to forward declare a template or an iterator |
| 17:49:34 | EXetoC | oh well |
| 17:51:58 | EXetoC | symboling re-ordering is a minor annoyance, but maybe it doesn't get progressively worse as the module grows |
| 17:53:01 | * | ltbarcly quit (Quit: Computer has gone to sleep.) |
| 17:54:21 | EXetoC | Araq: what about cyclic template deps then? |
| 17:55:57 | Araq | they don't make too much sense giving their inline semantics |
| 17:56:54 | * | ltbarcly joined #nimrod |
| 17:56:59 | * | MFlamer joined #nimrod |
| 17:59:07 | * | ltbarcly quit (Client Quit) |
| 17:59:44 | EXetoC | not possible then? ok |
| 17:59:45 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 18:00:43 | * | EXetoC joined #nimrod |
| 18:01:25 | Araq | hi MFlamer; how's progress? |
| 18:02:35 | MFlamer | Good. I'm setting the table up to use hashes.nim now and support any key type |
| 18:02:54 | Araq | ok nice |
| 18:02:58 | Araq | https://github.com/Araq/Nimrod/issues/612 -.- |
| 18:03:14 | Araq | zlib has not a single documentation comment and is a raw wrapper |
| 18:03:31 | Araq | why should it have a comment about adler32 being dangerous? |
| 18:04:05 | MFlamer | And then I'm going to create a version that encodes a version# in the value pointer using a double word CAS and see how I can get your transaction idea going |
| 18:04:11 | EXetoC | I've noticed that people are using the term "user-defined type classes" for the upcoming stuff. are there two different types of type classes or are some people using the term incorrectly? |
| 18:04:56 | Araq | I'm not aware of 2 different types of type classes |
| 18:05:28 | Araq | but they are great, they seem to solve things that they clearly cannot solve |
| 18:05:42 | MFlamer | I was thinking maybe we can get away with only verifying the "z" (the new put value) version in some cases |
| 18:06:11 | Araq | well I was thinking it should be enough to only verify the 2 inputs ;-) |
| 18:06:23 | EXetoC | there's "int|int8|int16|int32|int64", and the features zahary is developing, but I guess they share some similarities |
| 18:06:51 | MFlamer | funny |
| 18:07:06 | Araq | '|' is only a shorthand for a more elaborate 'generic', EXetoC |
| 18:07:35 | * | fowl joined #nimrod |
| 18:07:50 | EXetoC | I guess |
| 18:08:29 | MFlamer | I'm looking forward to the user defined type classes working.....when is zahary going to be done? ;-) |
| 18:10:41 | EXetoC | zahary: will you finish it before the end of the week for $100? |
| 18:14:46 | MFlamer | I'll throw in a $20 |
| 18:15:40 | EXetoC | let's see if he wants to do it for less in case he says yes. it'd be foolish to waste more money than necessary! |
| 18:16:02 | MFlamer | Araq: what is the new macro system you are working on? |
| 18:16:03 | * | ltbarcly joined #nimrod |
| 18:16:06 | reactormonk | I'll throw in 0.1฿ |
| 18:16:25 | MFlamer | That's alot in US$ |
| 18:16:30 | EXetoC | 0.1 coffee percolators? |
| 18:17:43 | Araq | MFlamer: it's only a new VM for evaluating macros fixing lots of bugs |
| 18:17:48 | Araq | no syntax changes |
| 18:17:58 | MFlamer | ok |
| 18:18:19 | reactormonk | MFlamer, somewhat around 13$ |
| 18:22:34 | Araq | bbl |
| 18:22:49 | * | fowl quit (Read error: Connection reset by peer) |
| 18:25:57 | * | ltbarcly quit (Quit: Computer has gone to sleep.) |
| 18:37:46 | wlhlm | Hi, I'm trying to compile the nimrod levelgen benchmark (https://github.com/logicchains/Levgen-Parallel-Benchmarks/blob/master/PN.nim#L18-L21), but I get an error: "PN.nim(19, 18) Error: type expected". What is wrong with that code? |
| 18:42:59 | * | fowl joined #nimrod |
| 19:17:22 | NimBot | Araq/Nimrod master f6d6e24 Araq [+0 ±5 -0]: first version of the debug GC; doesn't work yet |
| 19:17:22 | NimBot | Araq/Nimrod master bee6293 Araq [+0 ±1 -0]: debug GC works now |
| 19:17:22 | NimBot | Araq/Nimrod master 537f5ec Araq [+0 ±1 -0]: fixes #609 |
| 19:22:02 | * | Amrykid_ joined #nimrod |
| 19:22:18 | * | Zor_ joined #nimrod |
| 19:22:47 | * | eco_ joined #nimrod |
| 19:23:32 | * | Arcanum_za joined #nimrod |
| 19:24:07 | * | rndbit` joined #nimrod |
| 19:27:18 | * | Zor quit (*.net *.split) |
| 19:27:20 | * | Amrykid quit (*.net *.split) |
| 19:27:21 | * | d34th quit (*.net *.split) |
| 19:27:22 | * | rndbit quit (*.net *.split) |
| 19:27:22 | * | Trixar_za quit (*.net *.split) |
| 19:27:23 | * | Araq quit (*.net *.split) |
| 19:27:24 | * | eco quit (*.net *.split) |
| 19:27:24 | * | dom96 quit (*.net *.split) |
| 19:28:28 | * | Araq_bnc joined #nimrod |
| 19:28:32 | * | dom96 joined #nimrod |
| 19:28:33 | * | Araq_bnc is now known as Araq |
| 19:30:07 | * | d34th joined #nimrod |
| 19:37:37 | * | ltbarcly joined #nimrod |
| 19:38:54 | reactormonk | wlhlm, try array[0..2500, TTile] etc. |
| 19:39:29 | Araq | reactormonk: I already answered :P |
| 19:40:09 | reactormonk | Araq, really? don't see anything |
| 19:41:41 | Araq | wlhlm: it only compiles with the github version as 'array[N, type]" is new |
| 19:41:46 | Araq | you can easily replace the 2500 by 0..2499 though |
| 19:41:53 | Araq | and then it should compile with 0.9.2 |
| 19:42:16 | fowl | lets do 0.9.2.1 release! |
| 19:42:43 | fowl | "lets" as in "araq should" |
| 19:43:11 | Araq | I'm already working day and night to get a reasonably stable next version |
| 19:43:46 | wlhlm | reactormonk: thanks, that worked! |
| 19:44:24 | Araq | gah but it's wrong |
| 19:44:29 | fowl | Araq, sry, keep up the good work |
| 19:44:42 | Araq | 2500 becomes 0..2499 why is that so hard? |
| 19:51:51 | wlhlm | how can I enable a nimrod programm to run on more than one core? Using the parrallel levelgen benchmark I only get 100% cpu usage… |
| 19:51:53 | * | eco_ is now known as eco |
| 19:55:53 | Araq | dunno what version of the benchmark you're using, if it has the || for loop iterator, use GCC |
| 19:56:23 | wlhlm | I found it: using `--threads:on` when compiling |
| 19:59:09 | wlhlm | Araq: I'm using the git HEAD version, but it doesn't use this notation by default - that might be the problem ;-) |
| 19:59:44 | * | ltbarcly quit (Read error: Operation timed out) |
| 20:01:39 | wlhlm | Araq: apparently it's used on line 122, but I still can only get 100% out of it |
| 20:03:10 | Araq | this doesn't make sense, if you missed --threads:on it shouldn't even compile |
| 20:04:27 | wlhlm | Araq: it compiled fine without using `--threads:on`. I'm using version 0.9.2 from Archlinux |
| 20:05:16 | Araq | do you have any *.nimrod.cfg file? |
| 20:07:13 | wlhlm | Araq: I have `/etc/nimrod.cfg` and `/usr/lib/nimrod/nimrtl.nimrod.cfg`. |
| 20:11:53 | Araq | well there is PNllvm.nim and PN.nim |
| 20:12:05 | Araq | the llvm needs --threads:on the other one GCC |
| 20:15:58 | wlhlm | I used PN.nim and gcc, but I haven't seen the *.nimrod.cfg. Using the options specified in that file, it works on multiple cores. |
| 20:16:29 | Araq | yeah and it does use the || for loop iterator |
| 20:16:40 | Araq | in line 121 |
| 20:18:18 | * | fowl quit (Read error: Connection reset by peer) |
| 20:31:32 | MFlamer | what would be the advantage to switching the compiler back end to LLVM as opposed to the current compile to C then use gcc or clang? |
| 20:32:27 | MFlamer | The current system seems so fast and works so well it seems hard to justify the work to switch to LLVM, |
| 20:34:28 | * | fowl joined #nimrod |
| 20:34:44 | MFlamer | C seems like a great IR, unless there is something I'm misiing |
| 20:37:00 | * | fowl quit (Read error: Connection reset by peer) |
| 20:37:21 | Araq | the current system works yeah |
| 20:38:01 | Araq | but llvm is a much nicer IR as it has a type system created by people who actually know what the purpose of a type system is |
| 20:38:33 | * | shodan45 joined #nimrod |
| 20:38:58 | Araq | however as I said the C backend is here to stay |
| 20:40:20 | MFlamer | thanks, for the info |
| 20:41:28 | * | wlhlm quit (Ping timeout: 240 seconds) |
| 20:43:20 | * | shodan45 wants a nimrod backend |
| 20:45:44 | Araq | shodan45: mat2 is working on a native backend but I don't know how far that is away |
| 20:47:02 | * | EXetoC quit (Ping timeout: 240 seconds) |
| 20:47:24 | shodan45 | Araq: o_O I was joking... to me a "nimrod backend" would just be "cat" ;) |
| 20:47:44 | Araq | I see |
| 20:55:29 | shodan45 | Araq: so you meant a straight compiler from nimrod to binary? |
| 20:55:52 | shodan45 | using LLVM, I assume? |
| 21:10:20 | Araq | no straight from nimrod to binary, no llvm |
| 21:13:28 | shevy | oh |
| 21:13:38 | shevy | nimrod can be compiled via llvm/clang? |
| 21:19:30 | Araq | sure it can, shevy |
| 21:21:11 | * | fowl joined #nimrod |
| 21:25:58 | * | io2 quit (Read error: Connection reset by peer) |
| 21:26:11 | fowl | where are the extra grammar modules |
| 21:27:20 | * | ltbarcly joined #nimrod |
| 21:27:49 | * | ltbarcly quit (Client Quit) |
| 21:29:07 | Araq | fowl: compiler/pbraces, compiler/syntaxes contains the dispatcher |
| 21:29:19 | fowl | thanks |
| 21:45:28 | * | ltbarcly joined #nimrod |
| 21:48:59 | * | ltbarcly quit (Client Quit) |
| 21:56:56 | * | ltbarcly joined #nimrod |
| 22:00:31 | * | ltbarcly quit (Client Quit) |
| 22:04:08 | * | zahary quit (Ping timeout: 240 seconds) |
| 22:07:18 | * | ltbarcly joined #nimrod |
| 22:13:33 | * | ltbarcly quit (Quit: Computer has gone to sleep.) |
| 22:17:15 | * | ltbarcly joined #nimrod |
| 22:20:21 | fowl | Araq, and how do you activate a new syntax again |
| 22:21:09 | * | ltbarcly quit (Client Quit) |
| 22:21:49 | * | Amrykid_ quit (Excess Flood) |
| 22:22:02 | * | Amrykid joined #nimrod |
| 22:24:59 | * | ltbarcly joined #nimrod |
| 22:26:08 | * | ltbarcly quit (Client Quit) |
| 22:27:09 | * | ltbarcly joined #nimrod |
| 22:29:49 | * | ltbarcly quit (Client Quit) |
| 22:47:59 | * | shodan45 quit (Quit: Konversation terminated!) |
| 23:06:28 | * | ltbarcly joined #nimrod |
| 23:45:31 | * | ltbarcly quit (Ping timeout: 248 seconds) |
| 23:52:43 | * | DAddYE quit (Remote host closed the connection) |
| 23:59:14 | * | DAddYE joined #nimrod |