| 00:04:23 | * | superfunc quit (Quit: Lost terminal) |
| 00:04:25 | NimBot | Araq/Nimrod devel 21be7bf Araq [+0 ±3 -0]: fixes #1310 |
| 00:04:25 | NimBot | Araq/Nimrod devel f9d7e8d Araq [+0 ±2 -0]: implements #1332 |
| 00:04:25 | NimBot | Araq/Nimrod devel f16449e Araq [+1 ±4 -0]: fixes #1103; fixes #1297 |
| 00:04:46 | * | lorxu joined #nimrod |
| 00:05:43 | lorxu | Hi |
| 00:06:12 | Araq | good night |
| 00:11:11 | drs | araq: http://nimrod-lang.org/intern.html do you mean "Porting to new platforms" ? |
| 00:12:29 | * | Swammy joined #nimrod |
| 00:12:35 | def- | drs: for cross compilation i would have assumed this: http://nimrod-lang.org/nimrodc.html#cross-compilation |
| 00:15:35 | drs | ah this is good |
| 00:15:38 | drs | i'll give it a try :) |
| 00:24:21 | * | lorxu quit (Ping timeout: 248 seconds) |
| 00:25:25 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 00:31:18 | * | q66 quit (Quit: Leaving) |
| 01:15:17 | * | superfunc joined #nimrod |
| 01:23:38 | * | darkf quit (Read error: Connection reset by peer) |
| 01:24:06 | * | darkf joined #nimrod |
| 01:37:04 | * | ARCADIVS joined #nimrod |
| 01:47:12 | * | brson quit (Quit: leaving) |
| 01:49:56 | * | superfunc quit (Ping timeout: 240 seconds) |
| 02:18:12 | * | ics joined #nimrod |
| 02:20:34 | * | nande quit (Read error: Connection reset by peer) |
| 02:58:10 | * | ics quit (Ping timeout: 240 seconds) |
| 02:58:31 | * | Jesin quit (Ping timeout: 256 seconds) |
| 02:59:33 | * | Jesin joined #nimrod |
| 03:03:28 | * | Swammy left #nimrod ("Textual IRC Client: www.textualapp.com") |
| 03:18:26 | OrionPK | any native markdown libs for nimrod? |
| 03:35:18 | * | ARCADIVS quit (Ping timeout: 240 seconds) |
| 04:39:07 | * | lorxu joined #nimrod |
| 04:47:17 | * | Jesin quit (Ping timeout: 245 seconds) |
| 04:57:44 | * | Jesin joined #nimrod |
| 05:29:42 | * | kshlm joined #nimrod |
| 05:29:43 | * | kshlm quit (Changing host) |
| 05:29:44 | * | kshlm joined #nimrod |
| 05:34:44 | * | superfunc joined #nimrod |
| 05:45:33 | * | Jesin quit (Read error: Connection reset by peer) |
| 05:45:33 | * | superfunc quit (Read error: Connection reset by peer) |
| 05:46:14 | * | Jesin joined #nimrod |
| 06:09:33 | * | superfunc joined #nimrod |
| 06:12:11 | * | Varriount|Mobile quit (Read error: Connection reset by peer) |
| 06:14:45 | flyx | Araq: I guess I have a general idea about how your changes fix the issues, if that's what you mean by understanding |
| 06:19:55 | * | X-Scale quit (Ping timeout: 272 seconds) |
| 06:23:04 | Araq | flyx: well feel free to ask |
| 06:26:29 | flyx | Araq: I don't really understand why you moved the second parameter of opcWrDeref in the third slot, leaving the second slot unused |
| 06:27:28 | Araq | consistency |
| 06:27:48 | Araq | which is required by the new preventFalseAlias |
| 06:29:30 | flyx | ah, yes, I see |
| 06:30:01 | Araq | that patch took a while btw |
| 06:30:13 | flyx | I can imagine that |
| 06:30:30 | Araq | first I tried to make ldObj et al produce the additional copies |
| 06:30:47 | Araq | but that doesn't really work and when you think about it |
| 06:31:12 | Araq | you only need the copy when you write to non-temporary storage |
| 06:32:40 | Araq | the root cause of these problems is that opcLdObj was not really specified |
| 06:33:24 | Araq | but now all the opcLd* opcodes load an address |
| 06:35:24 | flyx | you use the terms "load" and "store" in the comment, what exactly do they mean? |
| 06:35:27 | * | MayurYa joined #nimrod |
| 06:35:27 | * | MayurYa quit (Changing host) |
| 06:35:27 | * | MayurYa joined #nimrod |
| 06:36:23 | Araq | a.b = x.y |
| 06:36:27 | Araq | x.y # load |
| 06:36:32 | Araq | a.b = # store |
| 06:36:57 | Araq | arrays and pointer deref are analogous |
| 06:37:24 | * | error424 joined #nimrod |
| 06:37:55 | error424 | o/ hello |
| 06:39:09 | Araq | let foo = "abc" # no store, we treat 'let' as temporary storage |
| 06:39:25 | Araq | var foo = "abc" # requires a store |
| 06:39:29 | Araq | hi error424 |
| 06:39:32 | flyx | so let is basically a reference. |
| 06:40:16 | Araq | depends on the type. for 'int' it will create a copy |
| 06:40:37 | Araq | ints and floats are special in that they can directly fit into a register |
| 06:41:25 | * | superfunc quit (Ping timeout: 248 seconds) |
| 06:42:04 | flyx | makes sense. so, coming back to the coment in the code, it says that it's wrong to generate opeAsgn for the *load* of x.y. according to what you told me, x.y is a load |
| 06:43:48 | error424 | I ran across Nimrod today after looking at D and Rust. I've gone through a bit of the tutorials and it seems very nice. I run a game development club at my college so I am also interested in using it for 2D and 3D things and am glad to see it has an SDL binding. |
| 06:44:33 | Araq | it also has the best openGL wrapper once you get over the loadExtensions gotcha |
| 06:45:09 | Araq | I made it work with nimrod's dead code elimination, I don't think D and Rust can do that ;-) |
| 06:45:32 | error424 | Very nice, what is the gotcha exactly as far as using openGL with it? |
| 06:46:02 | Araq | sometimes you need to call loadExtensions |
| 06:46:08 | Araq | and sometimes you don't |
| 06:47:27 | error424 | hmm, I will hopefully see that tomorrow in my next tutorial grinding session |
| 06:54:13 | Araq | it's really not a big deal and the docs of opengl are explicit about it |
| 06:58:07 | error424 | Ah, ok. I've only really dealt with openGL through Java wrappers which can be really irritating trying to setup a VBO. |
| 07:00:39 | NimBot | Araq/Nimrod devel 91ecae9 Araq [+0 ±1 -0]: fixes #1328 |
| 07:00:39 | NimBot | Araq/Nimrod devel d3c79ce Araq [+0 ±1 -0]: fixes #1167 |
| 07:00:58 | flyx | setting up a VBO is partly irritating by design in OpenGL, but marshaling from Java surely doesn't make it easier |
| 07:01:14 | Araq | I need to go, see you later |
| 07:01:32 | error424 | later, Araq. |
| 07:02:41 | error424 | The problem java always gave me was that it could not allocate directly a floatbuffer. I guess some sort of inconsistency between the virtual machine and the native machine. |
| 07:03:29 | error424 | I believe it was JOGL that I was using |
| 07:03:52 | error424 | Anyway, I would take native code over a VM anyday |
| 07:04:11 | flyx | especially when dealing with APIs like OpenGL |
| 07:05:17 | flyx | that wasn't even remotely a use-case Java was designed for |
| 07:06:19 | error424 | Indeed. I would have used C++ but I always have a hard time linking libraries for it. |
| 07:07:51 | error424 | Which is most likely laziness on my part but JOGL made some things much easier (everything but the VBO really) |
| 07:08:32 | flyx | C++ is a language that enables you to do a lot of things, but most end up with shooting yourself in the knee. |
| 07:09:30 | flyx | if a language is too hard to use, it's not your fault if you don't use it |
| 07:10:15 | error424 | I would love to agree with you on that, but sometimes you just have to learn :) |
| 07:11:09 | error424 | Nimrod has definitely been easy to use though. Windows install was much easier than linux just because I'm a linux noob |
| 07:11:28 | flyx | tell me about it. I program C++, Java, Perl, XSLT and some other things at my job |
| 07:12:04 | error424 | that's a pretty mixed bag of languages and runtimes to keep track of |
| 07:12:27 | flyx | it's just „use whatever the customer wants“ |
| 07:14:13 | error424 | that's unfortunate. I would expect customers to take solutions rather than specific languages |
| 07:14:43 | error424 | I guess they have a maintenance team trained in just a few languages |
| 07:16:47 | flyx | once you are required to code for a Java EE environment the selection of languages is rather limited |
| 07:17:07 | * | Matthias247 joined #nimrod |
| 07:17:19 | * | Matthias247 quit (Client Quit) |
| 07:18:38 | error424 | That's pretty gross, but you could do a lot worse in terms of languages I guess. |
| 07:20:16 | flyx | a year ago, I developed a component for a Java EE application, dealing with data transformation. it would have been easy to code in Java, but the customer said it has to be XSLT |
| 07:21:34 | flyx | the reasoning was "the data format changes quickly, so we need to deploy new versions quickly. quality assurance prevents us from deploying Java code quickly" |
| 07:21:55 | flyx | „but XSLT is just XML, so it's just data, we can deploy that much quicker!" |
| 07:22:17 | flyx | everyone from our team facepalmed. |
| 07:22:41 | error424 | That's crazy, Java is easy to begin with |
| 07:23:40 | error424 | lock down your interfaces before you buy software for it... |
| 07:24:12 | * | Trustable joined #nimrod |
| 07:24:39 | flyx | Java EE is actually quite complicated |
| 07:24:49 | flyx | and needlessly so |
| 07:25:06 | error424 | Ah, I've only encountered the regular JDK |
| 07:26:11 | flyx | considering the reqular sdk, yeah, tell be about how I need to instantiate several buffers and streams to write to stdout |
| 07:26:31 | error424 | that is gross |
| 07:27:29 | flyx | I agree that as a language, it's pretty easy to learn. |
| 07:28:31 | error424 | What is the purpose of the enterprise edition? server performance? |
| 07:29:01 | flyx | securing jobs of a quite a bunch of people. |
| 07:29:22 | flyx | more seriously, it's about having a standardized platform to run your stuff on |
| 07:30:21 | error424 | sounds like a unicorn to me, the standard compiler is a pretty decent horse to me |
| 07:30:30 | error424 | but I'm not everybody |
| 07:30:41 | flyx | take for example a database: if your code needs one, you just tell that to the platform, and the platform just gives you a handle to whatever DB connection is configured |
| 07:31:16 | flyx | it also manages load balancing and such things |
| 07:31:56 | * | kshlm quit (Quit: Konversation terminated!) |
| 07:32:58 | error424 | I haven't dealt with a lot of databases yet so I will just have to take your word on its merit in that regard |
| 07:33:42 | * | kunev joined #nimrod |
| 07:39:23 | flyx | well the merit is that the administrator gets a bunch of software from some contractor and knows exactly what he needs to do to setup the database for that software |
| 07:39:57 | flyx | because the process is standardized on the platform |
| 07:40:55 | flyx | I have to add, I think the whole platform is just terrible and the theoretical merits do not add up to the problems it causes |
| 07:43:13 | error424 | It must be pretty nice for the administrator at least, heh. I've heard of other languages like haskell being very good at dealing with SQL but for now are way over my head. |
| 07:45:55 | error424 | anyway, nice chatting to you; see you around! |
| 07:46:10 | * | error424 quit (Quit: Page closed) |
| 08:37:11 | * | MayurYa quit (Ping timeout: 240 seconds) |
| 08:39:28 | flyx | trying to build Nimrod from csources on Windows/cygwin: /usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../i686-pc-cygwin/bin/ld: c_code\1_1\stdlib_system.o: bad reloc address 0x54 in section `.rdata' |
| 09:05:30 | * | utkan joined #nimrod |
| 09:18:03 | * | atlithorn joined #nimrod |
| 09:21:01 | * | utkan quit (Ping timeout: 256 seconds) |
| 09:24:24 | * | utkan joined #nimrod |
| 10:29:33 | * | gsingh93_ quit (Quit: Connection closed for inactivity) |
| 10:35:59 | * | utkan quit (Ping timeout: 264 seconds) |
| 10:37:24 | * | kshlm joined #nimrod |
| 11:00:38 | * | utkan joined #nimrod |
| 11:00:41 | * | utkan quit (Remote host closed the connection) |
| 11:00:47 | * | utkan joined #nimrod |
| 11:06:20 | utkan | Hi, how does Rust and Nimrod compare? |
| 11:07:43 | utkan | I mean, in terms of usage |
| 11:18:46 | * | lorxu quit (Read error: No route to host) |
| 11:35:54 | * | utkan quit (Quit: Computer has gone to sleep.) |
| 12:06:58 | * | kshlm quit (Ping timeout: 240 seconds) |
| 12:27:03 | * | untitaker quit (Ping timeout: 240 seconds) |
| 12:32:21 | * | untitaker joined #nimrod |
| 12:41:37 | * | kshlm joined #nimrod |
| 12:42:08 | * | kshlm quit (Client Quit) |
| 12:59:05 | * | darkf quit (Quit: Leaving) |
| 13:11:26 | * | EXetoC joined #nimrod |
| 13:30:08 | * | X-Scale joined #nimrod |
| 13:37:45 | * | Kazimuth joined #nimrod |
| 13:37:49 | * | Kazimuth quit (Read error: Connection reset by peer) |
| 13:46:20 | * | lorxu joined #nimrod |
| 14:37:38 | * | AndChat|226100 joined #nimrod |
| 14:39:49 | * | lorxu quit (Ping timeout: 248 seconds) |
| 15:07:52 | * | lorxu joined #nimrod |
| 15:09:41 | * | AndChat|226100 quit (Ping timeout: 248 seconds) |
| 15:30:26 | * | lorxu quit (Read error: Connection reset by peer) |
| 16:35:59 | * | kunev quit (Ping timeout: 264 seconds) |
| 16:44:50 | * | utkan joined #nimrod |
| 16:49:48 | Araq | utkan: nobody uses nimrod, everybody uses Rust |
| 16:50:41 | utkan | sorry i meant "usage fields".. if that makes more sense |
| 16:50:45 | utkan | sorry for bad english :/ |
| 16:50:58 | utkan | do they both target the same audience |
| 16:51:22 | Araq | I guess they do since they both are "systems" programming languages |
| 16:54:18 | * | brson joined #nimrod |
| 16:55:40 | * | superfunc joined #nimrod |
| 16:57:17 | * | Matthias247 joined #nimrod |
| 17:00:12 | Araq | utkan: Rust pretty much targets only the low level stuff, Nimrod targets both the low level and the high level stuff |
| 17:00:35 | Araq | as it has been designed to replace the common Python+C or perhaps Lua+C++ combinations |
| 17:02:36 | * | q66 joined #nimrod |
| 17:03:01 | utkan | I see, thank you |
| 17:04:42 | Demos | utkan, nimrod does not offer the memory safety without a GC thing that rust does. Instead nimrod just has a really fast garbage collector |
| 17:05:28 | Demos | I also think nimrod is a much simpler and eaiser to use language than rust, and does not encourage complex designs as much, but that is just me |
| 17:07:35 | Demos | Araq, can you tell me what the params to sigmatch.typeRel mean? Presumably c is the candidate, What are f and aOrig? |
| 17:11:13 | utkan | Demos, thank you too. Also from as I see Nimrod's syntax is way better than Rust's |
| 17:11:58 | utkan | For my taste, at least |
| 17:12:26 | Demos | yeah, this is true. I like the balence between enforcing stuff and not getting in the way. I LOVE the way typeclasses work and how there is really no notion of methods as "members" of an object |
| 17:15:11 | * | atlithorn quit (Quit: atlithorn) |
| 17:18:55 | drs | so i'm trying to "regenerate" the csources code.. is this the right command to do that: nimrod cc -d:release -r -d:useLibzipSrc tools/niminst/niminst --var:version=0.9.8 csource compiler/nimrod.ini -d:release |
| 17:28:32 | * | gsingh93_ joined #nimrod |
| 17:32:00 | Matthias247 | Demos: I think the rust guys would argue that it also suits high level stuff ;) |
| 17:32:21 | Matthias247 | but I would currently be on your side |
| 17:33:17 | Demos | I am sure they would :D |
| 17:36:43 | Demos | gaah I really want to fix overload resultuion for static[T]s. It should just treat them the same as OR for real types, but it does not. |
| 17:37:11 | * | boydgreenfield joined #nimrod |
| 17:41:21 | * | ics joined #nimrod |
| 17:42:57 | * | Mat3 joined #nimrod |
| 17:43:01 | Mat3 | G'Day |
| 17:45:05 | * | ics_ joined #nimrod |
| 17:45:42 | * | ics quit (Ping timeout: 240 seconds) |
| 17:47:02 | * | bjz joined #nimrod |
| 17:47:22 | dom96 | hi |
| 17:48:56 | dom96 | drs: you can just execute koch csources -d:release |
| 17:49:41 | * | utkan quit (Ping timeout: 248 seconds) |
| 17:50:20 | * | ics_ quit (Ping timeout: 240 seconds) |
| 17:53:25 | Mat3 | hi dom96 |
| 17:53:29 | * | ics joined #nimrod |
| 17:53:41 | * | BitPuffin quit (Quit: See you on the dark side of the moon!) |
| 17:53:57 | dom96 | hi Mat3 |
| 17:54:01 | * | BitPuffin joined #nimrod |
| 17:57:25 | boydgreenfield | Couple of questions about union types (or whatever the right terminology is). 1) Is the right way to declare them like so?: `type TIntMap = TTable[int, int] or seq[int]`; and |
| 17:57:59 | boydgreenfield | 2) I’m getting this bizarre compiler error when I change one of my procs to take either a table or a sequence, that relates to type mismatches on the `len` proc of an unrelated `TSet` within the function. I can get rid of the errors and get it to compile by changing everything to sets.len(my_set), sets.incl(my_set, item), etc., but well… that’s a pain and i’m not sure why I should need to |
| 17:58:10 | boydgreenfield | (Trying to clean up some demo code for a gist) |
| 17:59:47 | * | utkan joined #nimrod |
| 18:02:11 | Araq | Demos: f # formal parameter |
| 18:02:30 | Araq | aOrig, a # actual argument |
| 18:02:52 | Araq | proc foo(param: int); foo(arg) |
| 18:02:57 | * | Johz joined #nimrod |
| 18:03:04 | Araq | f --> int (param) |
| 18:03:14 | Araq | a --> type(arg) |
| 18:03:33 | * | ics quit (Ping timeout: 240 seconds) |
| 18:03:51 | Demos | and c is the function we are looking at? |
| 18:04:15 | Araq | c is the candidate yes |
| 18:04:49 | Araq | keep in mind that there is no symmetry whatsoever between f and a |
| 18:05:15 | Araq | when a is compatible with f this doesn't mean f is compatible with a |
| 18:05:15 | Mat3 | bodydgreenfield: hmm, are you sure you want declaring an union ? |
| 18:06:54 | Demos | yeah, ofc. 90% of the time when a is compatible with f that means f would NOT be compatible with a |
| 18:10:09 | boydgreenfield | Mat3: Not really. I want a proc to just operate on a table or a sequence, since it’s only using `[]` operations, but I don’t want to declare the body twice. What’s the best way to do that? |
| 18:10:52 | Araq | boydgreenfield: dunno if "or" really is the best choice here |
| 18:11:01 | boydgreenfield | Mat3: What I’m confused by though, is that the compiler seems to be failing on the `set` procs, which aren’t being affected in any way (and indeed when one explicitly calls sets.len, etc. it works — so there’s some kind of dispatch issue) |
| 18:11:18 | boydgreenfield | Araq: What’s the best practice in these types of situations? I was modeling it the way I might in, e.g., Julia |
| 18:11:23 | * | ics joined #nimrod |
| 18:11:32 | boydgreenfield | (Realize they’re nothing alike, but that’s where I get any familiarity w/ type unions from) |
| 18:11:43 | Araq | usually you can simply leave out the constraints, it's checked at instantiation time anyway |
| 18:11:58 | Mat3 | boydgreenfield: ah, you want to declare a higher order function (alias map) |
| 18:12:00 | Araq | proc foo[T](x: T) = ... use x[i] here ... |
| 18:13:25 | NimBot | Araq/Nimrod devel 39ce17a Araq [+0 ±2 -0]: fixes #933 |
| 18:13:25 | NimBot | Araq/Nimrod devel d80d8aa Araq [+1 ±2 -1]: fixes #1323 |
| 18:13:26 | boydgreenfield | Araq: That fails for me too. Which is totally bizarre and I can’t figure out. But changing it to x: seq[int] or x: TTable[int, int] works fine. As does just changing all these set operations in the body of the function to sets.len() |
| 18:14:01 | Araq | boydgreenfield: ah so you triggered the symbol lookup bug in generics |
| 18:14:12 | Araq | which has nothing to do with constraints indeed |
| 18:14:34 | boydgreenfield | Ah ha. Ya it’s weird because I tried to rip out some irrelevant code and trim it down for a dummy example and, well then it just works |
| 18:14:34 | Araq | I'm afraid foo(a) has to be used instead of a.foo for now as a workaround |
| 18:14:51 | Araq | but yes |
| 18:15:07 | Araq | I suppose that's more important than fixing the remaining VM bugs |
| 18:15:16 | boydgreenfield | Araq: Not a problem. I’ll take a look at GH issues to see the background on this one. |
| 18:15:17 | boydgreenfield | Thx. |
| 18:15:29 | * | Araq changes his priorities |
| 18:15:52 | EXetoC | O_O |
| 18:15:56 | * | ics quit (Ping timeout: 240 seconds) |
| 18:16:42 | Araq | hi EXetoC wb |
| 18:16:48 | Mat3 | Araq: ehm, I think it is very important that both get debugged |
| 18:16:58 | Mat3 | hello EXetoC |
| 18:17:04 | * | ics joined #nimrod |
| 18:17:07 | * | kunev joined #nimrod |
| 18:17:43 | Araq | Mat3: well but these VM bugs are no challenge anymore |
| 18:18:31 | boydgreenfield | Araq: FYI, notably doing f(a) works fine. module.f(a) isn’t needed (e.g., sets.len(a)). |
| 18:18:33 | * | Mat3 must cirquminvent CPU related bugs, ehm sorry features (which are sadly not fixable) |
| 18:18:58 | Araq | boydgreenfield: I know |
| 18:19:10 | boydgreenfield | Araq: Haha of course. Sorry. |
| 18:19:20 | boydgreenfield | Thx for all the help. |
| 18:22:17 | * | utkan left #nimrod (#nimrod) |
| 18:22:24 | Araq | dom96: when should I merge the LL branch? |
| 18:27:12 | EXetoC | Araq: hello. thanks |
| 18:27:14 | EXetoC | Mat3: yo |
| 18:27:34 | EXetoC | Mat3: such as? |
| 18:29:06 | Mat3 | idiv triple faults dependent on the content of RDX for example |
| 18:29:33 | EXetoC | is it really a feature? |
| 18:31:11 | Mat3 | in my opinion not |
| 18:34:58 | dom96 | Araq: Does it break any tests? |
| 18:35:40 | Araq | no. |
| 18:36:56 | dom96 | merge it then |
| 18:40:36 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 18:40:50 | Araq | well I'm afraid it breaks async ... |
| 18:41:15 | Araq | but then I tested it pretty well with it |
| 18:42:29 | dom96 | it would probably be wise to wait |
| 18:42:38 | dom96 | Until I can fix this async stuff and properly test it |
| 18:42:45 | dom96 | but who knows how long that will take. |
| 18:43:36 | Araq | well it fixes like 10 bug reports |
| 18:47:48 | * | lorxu joined #nimrod |
| 18:56:26 | dom96 | Araq: Your call then |
| 18:56:55 | Araq | well I'm working on the new showstopper now |
| 18:58:02 | * | nande joined #nimrod |
| 19:02:02 | Demos | is there a name for a componentwise min operation on two vectors that returns a vector of the min of each elm |
| 19:03:03 | * | nande quit (Remote host closed the connection) |
| 19:03:47 | Araq | liftedMin :P |
| 19:13:25 | * | Jesin quit (Quit: Leaving) |
| 19:16:07 | * | Jesin joined #nimrod |
| 19:18:07 | * | AndChat|226100 joined #nimrod |
| 19:18:07 | * | lorxu quit (Read error: Connection reset by peer) |
| 19:18:59 | * | atlithorn joined #nimrod |
| 19:24:23 | * | atlithorn quit (Quit: atlithorn) |
| 19:30:26 | * | Jehan_ joined #nimrod |
| 19:48:25 | * | lorxu joined #nimrod |
| 19:48:25 | * | AndChat|226100 quit (Read error: Connection reset by peer) |
| 20:18:12 | * | lorxu quit (Read error: Connection reset by peer) |
| 20:18:28 | * | lorxu joined #nimrod |
| 20:22:41 | Varriount | Meep |
| 20:25:02 | Demos | it is going to be so painful having to program in c++ for school in the fall.... |
| 20:27:05 | Varriount | Demos: You could always program in Nimrod, and use the C++ backend to generate C++ code... |
| 20:27:17 | Demos | I kinda doubt that would pass the style linters |
| 20:27:33 | * | Mat3 quit (Ping timeout: 240 seconds) |
| 20:38:14 | Jehan_ | C++ in school? I'm sorry ... |
| 20:39:12 | EXetoC | and in introductory courses too. not good |
| 20:39:41 | Matthias247 | at least c++ is something useful |
| 20:39:46 | Matthias247 | even if you don't like it :) |
| 20:40:48 | * | nande joined #nimrod |
| 20:41:48 | Jehan_ | Matthias247: It's more that it's a less than ideal language for teaching. |
| 20:42:16 | Jehan_ | If you want to teach people low-level stuff, there are better alternatives. |
| 20:45:21 | superfunc | For teaching concepts, yeah |
| 20:46:20 | EXetoC | scheme is used to teach beginner's, right? I haven't used it |
| 20:46:27 | * | lorxu quit (Read error: Connection reset by peer) |
| 20:46:28 | Jehan_ | superfunc: It's just that in C++ your information flow gets littered with so much extraneous stuff. |
| 20:46:48 | * | lorxu joined #nimrod |
| 20:46:58 | EXetoC | yeah, it's used in that popular book IIRC |
| 20:47:03 | Jehan_ | Stuff that's totally irrelevant for what you want to teach, but which you need to know to make the compiler/libraries happy. |
| 20:47:09 | * | nande_ joined #nimrod |
| 20:47:09 | superfunc | Scheme used to be, its more python now |
| 20:47:23 | Jehan_ | EXetoC: Structure and Interpretation of Computer Programs. |
| 20:48:01 | Jehan_ | Freely available here: http://mitpress.mit.edu/sicp/ |
| 20:50:07 | Araq | 0:5 |
| 20:51:12 | * | lorxu quit (Ping timeout: 240 seconds) |
| 20:52:30 | Demos | Jehan_, the intro cources are more or less C |
| 20:52:45 | Demos | as are the really low level ones |
| 20:52:54 | Demos | it seems to work OK |
| 20:53:17 | Jehan_ | Demos: Ah, that's fine. Still not the greatest choice unless you're teaching an operating systems course, but the ANSI-Cish subset of C++ is at least not horrible. |
| 20:53:27 | Araq | dunno, c++ is fine for teaching low level stuff |
| 20:54:04 | Araq | and Ansi C *is* horrible, ymmv |
| 20:54:24 | Araq | C++'s excuse is that was built on top of C |
| 20:54:26 | Demos | yeah, in the third programming class they do a little with templates, but nothing crazy. And the OS class is C++ (or maybe C, but probably not ANSI) |
| 20:54:30 | Araq | C has no such excuse |
| 20:55:01 | Demos | we were using C++ as supported by GCC 4.7.0 when I took it |
| 20:55:07 | Jehan_ | Araq: ANSI C was built on top of K&R C. :) |
| 20:55:09 | Demos | they have GCC 4.8.2 now though |
| 20:56:11 | Araq | yes indeed. it was hacked together by some fat guys with beards that couldn't even design arrays properly |
| 20:56:50 | * | nande quit (Remote host closed the connection) |
| 20:56:55 | drs | K&R, started from the bottom, now we here.. well now we're dead.. one of us anyway. |
| 20:57:02 | * | nande_ quit (Remote host closed the connection) |
| 20:57:23 | * | nande joined #nimrod |
| 20:58:19 | * | bjz_ joined #nimrod |
| 20:58:20 | * | bjz_ quit (Client Quit) |
| 20:58:41 | * | bjz_ joined #nimrod |
| 20:59:56 | Matthias247 | Jehan_: imho you can program a lot of C++ without using very advanced stuff (templates, const, multiple-inheritance, ...) and then it's quite understandable |
| 21:00:04 | * | bjz quit (Ping timeout: 248 seconds) |
| 21:00:15 | Matthias247 | when I first learned C++ I actually found it easier than now :) |
| 21:01:08 | Jehan_ | Matthias247: Yeah, been there, done that. |
| 21:01:24 | Jehan_ | It gets even better with -lgc :) |
| 21:01:27 | Demos | Matthias247, yeah I agree, the trouble is that the language encourages you to go down really bad raods when what you want to do dose not quite fit |
| 21:01:57 | Matthias247 | I think rust would be harder for a total beginner because it requires you to understand more concepts from the beginning |
| 21:02:32 | bstrie | I wouldn't recommend rust as a language for beginners. but then I wouldn't recommend C or C++ either |
| 21:02:45 | bstrie | depends on what material you're intending to cover |
| 21:03:00 | bjz_ | Matthias247: rust is definitely not a beginner's language |
| 21:03:06 | Demos | My gut tells me that rust has the same problem c++ does with leading people toward complexity more than it could be. But time will tell |
| 21:03:42 | bjz_ | that's not to say it's an inherently complex language, it is just more chellenging in the concepts |
| 21:04:05 | Matthias247 | I think for most people it is already too complex |
| 21:04:06 | bjz_ | (it's actually quite simple at its core) |
| 21:04:20 | Matthias247 | and I probably include myself :) |
| 21:04:24 | Jehan_ | You generally can't teach everything about a modern language. The question tends to be if the language has a reasonable, self-contained subset (that includes standard libraries not exposing too much of the language outside the subset) that you can teach and that's still expressive enough. |
| 21:04:30 | Demos | the thing about c++ is that it is also quite simple at its core. Everything is implemented "correctly" and the semantics are pretty sane |
| 21:04:52 | bstrie | Demos: if you have blinders on, perhaps. you also have to be okay with teaching students worst-practices |
| 21:04:58 | Jehan_ | Demos: I'd argue about the "sane" part. |
| 21:05:13 | bjz_ | Demos: the semantics of C++ is bonkers |
| 21:05:19 | bjz_ | :P |
| 21:05:24 | Demos | well there is nothing in c++ that is just like this is wrong and it was wrong when it got standardized |
| 21:05:39 | Demos | except maybe vector<bool> |
| 21:05:44 | superfunc | I would make someone learn C before rust |
| 21:05:44 | Matthias247 | Demos: std::vector<bool> is wrong for sure :) |
| 21:05:49 | Matthias247 | hehe, same idea :) |
| 21:05:55 | Jehan_ | Demos: It's not about wrong, it's about being confusing to students. |
| 21:05:57 | superfunc | So they could appreciate and understand what rust brings to the table |
| 21:06:03 | Demos | Jehan_, that I agree with |
| 21:06:16 | Demos | it is only "right" when you understand how the code is getting generated |
| 21:06:41 | Demos | honestly ANSI C with "fat" arrays and a standardized garbage collector would be pretty good |
| 21:06:45 | Demos | and modules |
| 21:07:29 | Jehan_ | Demos: the two things I primarily miss with ANSI C is generics and automatic memory management. |
| 21:07:36 | Matthias247 | and a proper string type |
| 21:07:53 | Jehan_ | I can use the Boehm GC for the latter, but lack of generics is the killer. |
| 21:08:05 | Jehan_ | Matthias247: If you have GC, then that becomes a non-issue. |
| 21:08:06 | Demos | I could live without generics, but I would need modules and a gc |
| 21:08:17 | superfunc | Also, I really enjoy some of the stdlib in c++ |
| 21:08:22 | superfunc | especially the algorithm header |
| 21:08:32 | Demos | yeah algorithm is nice |
| 21:08:39 | Demos | we have some of that in nimrod |
| 21:08:51 | Demos | and if you find a need for a given algo you can add it |
| 21:09:18 | Demos | c++'s concept of iterators is getting a bit old |
| 21:09:29 | superfunc | I'm actually porting most of the things in algo to nimrod right now |
| 21:09:30 | superfunc | shhh |
| 21:09:40 | Demos | superfunc, most of them already exist |
| 21:09:54 | superfunc | a good amount |
| 21:09:59 | Demos | nearly all |
| 21:10:07 | Demos | the ones that do not are not usefull |
| 21:10:12 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 21:10:17 | superfunc | thats subjective |
| 21:10:20 | Demos | true |
| 21:10:22 | superfunc | do we have remove_if |
| 21:10:48 | superfunc | most of them are 1 or 2 line functions in nimrod, but putting a name to things is nice for uniformity |
| 21:11:27 | * | kunev quit (Quit: leaving) |
| 21:11:33 | Demos | filterIt could be considered similar to remove_if |
| 21:11:41 | Jehan_ | Demos: In the end, the question is becoming: Why bother? Except for existing codebases, I can get away with using either Nimrod or Scala, and for any personal project, I can always use one or the other. |
| 21:11:45 | Demos | and the c++ names and signatures are not nimrodic |
| 21:12:02 | Demos | Jehan_, libraries |
| 21:12:09 | Demos | esp closed source ones |
| 21:12:45 | Jehan_ | Demos: Yes, I know that, but I generally don't need those. |
| 21:13:07 | Demos | Yeah |
| 21:14:05 | Jehan_ | Would possibly be different if I were working on Windows. Dunno. |
| 21:14:13 | Demos | honestly I am pretty pumped that c++ is FINALLY getting modules, it makes it a pretty "modern" language save for the lack of GC |
| 21:15:59 | Demos | nimrod feels at-home on windows |
| 21:16:23 | Demos | none of the c++ frameworks from MS are any good anyways |
| 21:18:32 | Jehan_ | Hmm, the OCaml guys seem to be finally working on a multicore version. |
| 21:20:44 | * | Johz quit (Quit: Leaving) |
| 21:21:29 | Demos | is there an equivalent to high() and low() for floats? |
| 21:23:35 | Demos | never mind |
| 21:24:01 | superfunc | Well, getting it in C++17 |
| 21:24:04 | superfunc | we hope haha |
| 21:25:55 | superfunc | Demos: You're probably right btw, I shouldn't be looking to figure out how to do C++-things in Nimrod, but rather looking for an idiomadic approach that fits the language. |
| 21:26:50 | Demos | superfunc, yeah I did the same thing. my first pull request was a bad implementation of rotate |
| 21:27:15 | superfunc | Sean Parent's talk had me using rotate like crazy for a while |
| 21:48:42 | OrionPK | Demos |
| 21:48:52 | Demos | OrionPK, |
| 21:48:57 | OrionPK | you should upgrade your visualnimrod sln to vs2k13 |
| 21:49:07 | Demos | it totally is vs2k13 |
| 21:49:10 | OrionPK | NimrodVS\NimrodVS.csproj: The application which this project type is based on was not found. Please try this link for further information: http://go.microsoft.com/fwlink/?LinkID=299083&projecttype=82b43b9b-a64c-4715-b499-d71e9ca2bd60 |
| 21:49:18 | OrionPK | oh ok |
| 21:49:27 | OrionPK | im getting an "incompatible" error |
| 21:49:30 | OrionPK | cant load NimrodVS |
| 21:49:40 | Demos | yeah you need the visual studio extension sdk |
| 21:49:47 | OrionPK | thanks |
| 21:49:54 | Demos | you also need a version of VS that supports extensions, that means pro or above |
| 21:50:04 | OrionPK | think i've got taht |
| 21:50:23 | Demos | also note that I actually call the compiler for highlighting support, which is not actually a very good idea |
| 21:51:05 | Demos | this means you need to build a seperate dll that has that. Or wait for me to change it to a regex based thing |
| 21:51:24 | OrionPK | ahh yeah |
| 21:51:37 | OrionPK | that'd be a good thing to not do |
| 21:51:39 | OrionPK | :) |
| 21:51:45 | Demos | yeah.... |
| 21:53:22 | Demos | autocomplete does work! sorta |
| 21:58:52 | OrionPK | cool :) |
| 21:58:57 | OrionPK | maybe dont even use regex |
| 21:59:03 | Demos | again not ready for production use |
| 21:59:07 | OrionPK | u need a nimrod parser/AST in C# :) |
| 21:59:20 | Demos | OrionPK, I do not want to write one of those |
| 21:59:29 | OrionPK | lol |
| 21:59:38 | Demos | what we need is the compiler exposed as a library |
| 22:00:03 | OrionPK | that'd be cool |
| 22:00:20 | OrionPK | so how do I make libnimrod.dll |
| 22:00:25 | Demos | I think one can manage almost all, if not all IDE functions using regex and idetools |
| 22:01:21 | Demos | also on my github, but it is just not stable. Like it crashes the IDE a good amount of the time |
| 22:01:35 | Demos | https://github.com/barcharcraz/libnimrod/blob/master/vsgen.nim works OK though |
| 22:01:40 | Demos | that generates project files |
| 22:03:13 | OrionPK | hm |
| 22:03:44 | OrionPK | you make vsgen.exe? |
| 22:03:47 | OrionPK | or what args do u compile it w/ |
| 22:04:54 | Demos | it needs to be a dll, probably with nimrtl. You also need to use a different GC, markAndSweep works OK |
| 22:05:00 | Demos | and it needs to be 32 bit |
| 22:05:32 | OrionPK | you should make a bat or something w/ all the arguments |
| 22:06:02 | Demos | probably not going to do that, will probably abadon the libnimrod idea and just hack stuff together in c# |
| 22:06:13 | OrionPK | gotcha |
| 22:09:54 | * | utkan joined #nimrod |
| 22:10:23 | OrionPK | UintTests? :) |
| 22:13:57 | OrionPK | Demos can I set one of these to startup project and run it? |
| 22:14:18 | Demos | maybe |
| 22:14:32 | * | atlithorn joined #nimrod |
| 22:14:40 | OrionPK | or do you just install the vsix to test? |
| 22:15:00 | Demos | ummm, building the project should install it to the experimental instance of VS |
| 22:15:12 | OrionPK | which project as startup? |
| 22:15:21 | Demos | does not matter |
| 22:15:24 | Demos | just right click |
| 22:15:35 | Demos | I think the VisualNimrod project makes the visx |
| 22:15:42 | Demos | and installs to the experimental instance |
| 22:15:59 | OrionPK | NimrodVS? |
| 22:16:03 | Demos | yeah |
| 22:16:06 | OrionPK | when I tried to debug it said it lib output cannot be started |
| 22:16:28 | Demos | oh no that is the library |
| 22:16:33 | Demos | use the other non-test project |
| 22:16:50 | OrionPK | NimrodSharp? |
| 22:17:15 | Demos | yeah |
| 22:17:19 | OrionPK | same thing |
| 22:21:21 | OrionPK | is there a project templat? |
| 22:21:44 | Demos | yes |
| 22:22:25 | Demos | but the build experience is not great, to really do it properly I would need to dump the managed package framework and implement all the project interfaces myself |
| 22:22:29 | Demos | which I may do |
| 22:22:55 | OrionPK | the project template isnt included in the vsix? |
| 22:23:03 | OrionPK | I dont see it in the template chooser |
| 22:24:03 | Demos | it should be in the visx |
| 22:24:17 | OrionPK | i installed it |
| 22:25:24 | OrionPK | ah there it is |
| 22:28:00 | OrionPK | not getting syntax highlighting, but it's building and running |
| 22:28:07 | Demos | OK you have succeded in getting my focus back on visual nimrod |
| 22:28:13 | OrionPK | :D |
| 22:28:28 | superfunc | What? Are you guys trying to write nim in VS? |
| 22:28:46 | OrionPK | demo made a kind of proof of concept nimrod plugin |
| 22:28:49 | Demos | OrionPK, did you build libnimrod? |
| 22:28:52 | OrionPK | yes |
| 22:29:01 | Demos | hm I managed to crash VS with it already |
| 22:29:03 | superfunc | neat, the more the merrier |
| 22:29:20 | Demos | superfunc, you doing VS integration as well? |
| 22:29:36 | OrionPK | i think he means more plugins |
| 22:29:37 | superfunc | nope, I only use VS at work |
| 22:29:42 | Demos | yeah |
| 22:29:47 | superfunc | ^^ yeah |
| 22:30:07 | superfunc | even then, I usually get away with staying in linux |
| 22:30:44 | OrionPK | VS is just the best ide/debugging experience imo |
| 22:30:59 | superfunc | Different strokes |
| 22:31:08 | Demos | vs extensibility is a massive clusterfuck though |
| 22:31:11 | OrionPK | I wish I could use visual studio on OS X |
| 22:31:27 | OrionPK | so much better than XCode |
| 22:31:34 | Demos | I rather like XCode |
| 22:31:53 | OrionPK | ur a mad man |
| 22:31:53 | OrionPK | ;) |
| 22:34:24 | superfunc | I've been mulling the idea of lazy data structures this afternoon instead of working. One way it could work is basically a queue of lambda's that operate on the list which only get invoked when needed. By needed, it could be by someone indexing into it or something. What do you guys think? |
| 22:34:57 | superfunc | Also, this is "for" nothing, I just don't wanna work |
| 22:35:28 | * | nande quit (Read error: Connection reset by peer) |
| 22:35:45 | OrionPK | lazy data structures? |
| 22:35:49 | OrionPK | meaning what |
| 22:36:02 | superfunc | Meaning they only get constructed if needed |
| 22:36:29 | superfunc | In Haskell, I could have "l = [1,2,..]" or something |
| 22:36:53 | superfunc | and until someone calls "take 5 l" the list won't contain anything |
| 22:37:51 | OrionPK | so like linq kinda huh |
| 22:38:26 | superfunc | maybe, I don't know anything about linq |
| 22:38:47 | OrionPK | you can just use lambdas to do that |
| 22:38:59 | superfunc | yeah, that's basically what I did |
| 22:39:03 | OrionPK | ah |
| 22:40:21 | def- | superfunc: i like lazy datastructures, but i wrote a thesis about visualizing them, so I might be biased. they also lead to some nasty problems |
| 22:41:41 | superfunc | That's really cool, I'd like to pick your brain about them sometime. I just was curious how I would implement them. Once I finish a few things, I'd like to implement a few of Okasaki's persistent structures |
| 22:43:15 | * | nande joined #nimrod |
| 22:43:25 | * | utkan quit (Quit: Lingo - http://www.lingoirc.com) |
| 22:46:54 | * | atlithorn left #nimrod (#nimrod) |
| 22:48:27 | * | Jehan_ quit (Quit: Leaving) |
| 22:55:58 | * | bjz_ quit (Read error: Connection reset by peer) |
| 22:56:26 | * | bjz joined #nimrod |
| 23:00:32 | * | darkf joined #nimrod |
| 23:02:11 | * | Trustable quit (Quit: Leaving) |
| 23:06:29 | NimBot | Varriount/NimLime master 557ef78 Erik O'Leary [+0 ±2 -0]: Added support for embedded markdown |
| 23:08:35 | * | drs left #nimrod (#nimrod) |
| 23:13:42 | * | Varriount quit (Ping timeout: 240 seconds) |
| 23:14:49 | * | atlithorn joined #nimrod |
| 23:24:52 | * | ehaliewicz joined #nimrod |
| 23:29:11 | * | superfunc quit (Quit: leaving) |
| 23:55:00 | * | ics quit (Ping timeout: 248 seconds) |
| 23:55:07 | * | ics_ joined #nimrod |
| 23:56:44 | * | ehaliewicz quit (Quit: ERC Version 5.3 (IRC client for Emacs)) |