| 00:00:38 | Araq | hi freezerburnv welcome |
| 00:00:43 | OrionPK | if FD_ISSET(socketFd) is NON zero: remove from resulting set |
| 00:00:48 | OrionPK | am I crazy? |
| 00:00:51 | freezerburnv | Hey Araq, thanks :) |
| 00:01:26 | Araq | OrionPK: ask dom96 when he's around please |
| 00:01:39 | OrionPK | will do.. |
| 00:03:26 | OrionPK | araq if I invert the logic it works as expected |
| 00:03:34 | OrionPK | if select(rsocks, timeout) == 1:# and rsocks.contains == 0: |
| 00:03:34 | OrionPK | if rsocks.contains(ws.server): |
| 00:03:34 | OrionPK | new(ws.socket) |
| 00:03:34 | OrionPK | accept(ws.server, ws.socket) |
| 00:11:05 | Araq | I need to sleep now. good night |
| 00:12:12 | freezerburnv | Night! |
| 00:14:00 | freezerburnv | How do you change default indentation in nimrod.vim? It seems to indent something like 8 spaces by default, would much prefer it to be something like 2 or 4 |
| 00:19:35 | * | dymk quit (Ping timeout: 245 seconds) |
| 00:21:00 | OrionPK | freezerburnv think thats more of a vim question than a nimrod question :\ |
| 00:22:20 | freezerburnv | I changed vim's default indentation. I was wondering if nimrod.vim defined an indentation standard. If not, then I'll try to figure something out |
| 00:22:41 | freezerburnv | The documentation on the github page is pretty sparse |
| 00:24:03 | OrionPK | that sucks. |
| 00:24:08 | OrionPK | i typically use sublime |
| 00:24:20 | freezerburnv | Sublime has nimrod support? If that's the case, awesome! I love sublime |
| 00:24:31 | freezerburnv | It wasn't mentioned on the homepage, so I assumed it didn't exist yet |
| 00:24:33 | OrionPK | there's a plugin for it, but it's kinda outdated |
| 00:24:56 | OrionPK | it's in sublime package manager |
| 00:25:11 | freezerburnv | Cool, I'll go ahead and install that |
| 00:32:05 | * | wlhlm quit (Ping timeout: 245 seconds) |
| 00:42:33 | Varriount | freezerburnv, The problem is that sublime text is very... cryptic, as far as adding a new language goes. |
| 00:48:35 | freezerburnv | That's no fun. Is that why it isn't very well maintained? Or did the author just move on to other things or something? |
| 00:48:55 | Varriount | Before my time. |
| 00:49:12 | Varriount | freezerburnv, if you're good with regex's, then you could try. |
| 00:49:52 | Varriount | Or, you try integrating nimrod's idetools feature. |
| 00:49:59 | freezerburnv | I suppose I could try that at some point, in-between trying to actually learn nimrod |
| 00:50:08 | freezerburnv | I'll poke at it sometime |
| 00:50:51 | * | CptRootbeer left #nimrod (#nimrod) |
| 00:51:02 | * | DAddYE quit (Remote host closed the connection) |
| 00:51:08 | freezerburnv | is there a way to specify the type an enum is? I want to make sure it's a uint32 for an FFI call |
| 00:55:42 | Varriount | Hm. Well, you can manually specify the type by defining each enumeration |
| 00:58:36 | * | dymk joined #nimrod |
| 01:02:07 | freezerburnv | What's the syntax for that? Everywhere I tried to add something like ":Uint32" had the compiler yell at me |
| 01:04:21 | Varriount | type |
| 01:04:27 | * | yetfeo left #nimrod (#nimrod) |
| 01:04:34 | Varriount | MyEnum = Enum |
| 01:05:01 | Varriount | A = uint32(1) |
| 01:05:09 | Varriount | Something roughly like that. |
| 01:06:28 | * | dyu joined #nimrod |
| 01:07:02 | Varriount | freezerburnv, http://nimrod-code.org/manual.html#numerical-constants |
| 01:08:40 | * | dyu_ joined #nimrod |
| 01:09:43 | freezerburnv | Awesome, thanks |
| 01:12:13 | * | dyu quit (Ping timeout: 272 seconds) |
| 01:13:28 | Varriount | freezerburnv, if you're making a wrapper, you might want to check out the c2nim |
| 01:13:32 | Varriount | *c2nim tool |
| 01:14:17 | Varriount | It isn't perfect, and is a bit picky on what kind of C code is given to it, but if you're wrapping a large library, it can be great. |
| 01:14:36 | freezerburnv | I saw that. Right now I'm doing some stuff manually to learn a bit about the FFI/pragmas |
| 01:15:30 | * | dyu_ quit (Ping timeout: 252 seconds) |
| 01:18:21 | freezerburnv | They don't seem to be documented super well. I found a bunch of stuff in an existing wrapper for what I'm trying to work with that I couldn't find in any of the docs linked from the main site |
| 01:18:57 | reactormonk | freezerburnv, ask zahary about nimrod.vim, I'm handling nimrod-mode.el |
| 01:19:03 | Varriount | The wrappers? They aren't documented because their interface is nearly exactly the same as whatever library they wrap. |
| 01:19:47 | Varriount | It's assumed (by others, not me) that those who want to use the wrappers will go read the wrapped library docs. |
| 01:21:04 | freezerburnv | Er, sorry. What I meant by that was FFI pragmas weren't documented super well |
| 01:22:23 | freezerburnv | e.g.: {.push callConv: cdecl, dynlib: LibName.}, didn't find anything about a push pragma in any docs I looked at |
| 01:23:01 | Varriount | http://nimrod-code.org/manual.html#push-and-pop-pragmas |
| 01:23:19 | * | Varriount is now known as The_Manual |
| 01:23:27 | * | The_Manual is your friend |
| 01:23:36 | * | The_Manual is now known as Varriount |
| 01:24:12 | xenagi | that explains a lot |
| 01:24:22 | Varriount | ? |
| 01:24:34 | freezerburnv | Gah, I feel dumb. Thought I looked through that stuff |
| 01:24:37 | xenagi | lol i was jk |
| 01:26:13 | * | Associat0r joined #nimrod |
| 01:26:13 | * | Associat0r quit (Changing host) |
| 01:26:13 | * | Associat0r joined #nimrod |
| 01:27:08 | freezerburnv | Ok, so if I'm understanding this correctly: the push pragma I pasted will declare all following functions to be cdecl (meaning an FFI C call), and coming from the dynamic library specified by LibName |
| 01:28:04 | Varriount | Yep. |
| 01:28:51 | * | dyu_ joined #nimrod |
| 01:32:57 | * | freezerburnv quit (Quit: freezerburnv) |
| 01:49:36 | * | dyu_ quit (Ping timeout: 252 seconds) |
| 01:52:57 | * | DAddYE joined #nimrod |
| 01:57:55 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 02:02:28 | * | DAddYE joined #nimrod |
| 02:02:35 | * | dyu_ joined #nimrod |
| 02:07:25 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 02:23:31 | * | dyu__ joined #nimrod |
| 02:26:19 | * | dyu_ quit (Ping timeout: 272 seconds) |
| 02:26:30 | * | dyu_ joined #nimrod |
| 02:29:31 | * | dyu__ quit (Ping timeout: 260 seconds) |
| 02:30:37 | * | dyu_ quit (Ping timeout: 240 seconds) |
| 02:36:33 | * | dell joined #nimrod |
| 02:38:41 | * | Associ8or joined #nimrod |
| 02:38:41 | * | Associ8or quit (Changing host) |
| 02:38:41 | * | Associ8or joined #nimrod |
| 02:40:28 | dell | HI...which is the best way for calling c++ code from nimrod? is it hard? |
| 02:40:59 | * | Associat0r quit (Ping timeout: 272 seconds) |
| 02:41:43 | dom96 | dell: Here is an example: https://github.com/Araq/Nimrod/blob/master/examples/c%2B%2Biface/irrlichtex.nim |
| 02:42:05 | dom96 | c2nim now also should support C++ so you can use it to generate wrappers. |
| 02:43:51 | * | dyu joined #nimrod |
| 02:43:55 | dell | I'm not familiar with c++ (would it be a problem??) I come from python,c# :S ... |
| 02:44:25 | dom96 | What C++ code do you want to call? |
| 02:47:44 | dell | cinder...is a library for visual experiments (arts,effects,etc) |
| 02:47:46 | dell | http://libcinder.org/about/ |
| 02:50:21 | * | dyu_ joined #nimrod |
| 02:53:12 | * | XAMPP quit (Read error: Connection reset by peer) |
| 02:53:38 | * | dyu quit (Ping timeout: 264 seconds) |
| 02:53:44 | * | mah joined #nimrod |
| 02:54:33 | * | DAddYE joined #nimrod |
| 02:55:02 | * | dyu_ quit (Ping timeout: 268 seconds) |
| 02:56:53 | dom96 | dell: Does it have a C wrapper? If so it may be easier to wrap that. |
| 02:57:29 | dom96 | As for C++ knowledge, well, basic knowledge at least would be very helpful in creating a wrapper. |
| 02:58:54 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 02:59:43 | * | brson quit (Ping timeout: 245 seconds) |
| 03:01:02 | dom96 | OrionPK: The behaviour of select is in line with the behaviour of the posix select(). It is 3am so maybe i'm overlooking something, but the sockets which are ready should be removed from the sequence of sockets passed. How else would it work? |
| 03:01:14 | OrionPK | nope |
| 03:01:20 | OrionPK | sockets that are ready should be left in |
| 03:01:28 | OrionPK | everything thats NOT ready should be removed |
| 03:01:46 | * | brson joined #nimrod |
| 03:07:06 | dom96 | hrm, perhaps you're right. |
| 03:07:47 | OrionPK | fixing it will break things.. but I think it has to be done |
| 03:07:54 | * | dyu_ joined #nimrod |
| 03:08:39 | dom96 | Why are you using select directly anyway? You should use asyncio. |
| 03:08:55 | OrionPK | I'm writing two implementations, similar to http server |
| 03:09:08 | OrionPK | just a basic 'run' method will use the select |
| 03:10:28 | dom96 | Select() will be obsolete soon anyway once my selector module is ready. |
| 03:11:12 | dom96 | but maybe that will still be useful. |
| 03:11:21 | dom96 | hrm, we will see. |
| 03:11:28 | dom96 | It's too late for me to be making these decisions. |
| 03:11:36 | OrionPK | hehe |
| 03:12:04 | OrionPK | go sleep on it. I think select will still be useful going forward but having asyncio would obviously be preferred |
| 03:12:50 | dom96 | Yeah. Good night. |
| 03:12:53 | OrionPK | night |
| 03:17:51 | * | dyu__ joined #nimrod |
| 03:20:56 | * | dyu_ quit (Ping timeout: 268 seconds) |
| 03:21:54 | * | brson quit (Quit: leaving) |
| 03:27:39 | * | dyu__ quit (Ping timeout: 240 seconds) |
| 03:27:43 | * | dell left #nimrod ("Saliendo") |
| 03:31:00 | * | XAMPP joined #nimrod |
| 03:41:24 | * | dyu__ joined #nimrod |
| 03:45:22 | * | dyu_ joined #nimrod |
| 03:48:24 | * | dyu__ quit (Ping timeout: 260 seconds) |
| 03:55:58 | * | DAddYE joined #nimrod |
| 03:56:21 | * | mah quit (Quit: Page closed) |
| 03:58:46 | * | dyu_ quit (Ping timeout: 265 seconds) |
| 04:00:32 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 04:10:33 | * | dyu_ joined #nimrod |
| 04:15:03 | * | xenagi quit (Quit: Leaving) |
| 04:15:24 | * | dyu__ joined #nimrod |
| 04:16:52 | * | dyu_ quit (Ping timeout: 260 seconds) |
| 04:20:54 | * | dyu_ joined #nimrod |
| 04:24:14 | * | dyu__ quit (Ping timeout: 264 seconds) |
| 04:45:39 | * | dyu_ quit (Ping timeout: 272 seconds) |
| 04:54:14 | * | mkb quit (Ping timeout: 240 seconds) |
| 04:55:24 | * | mkb joined #nimrod |
| 04:57:25 | * | DAddYE joined #nimrod |
| 05:03:55 | * | DAddYE quit (Ping timeout: 268 seconds) |
| 05:10:31 | * | mflamer joined #nimrod |
| 05:33:43 | Varriount | How can I get the high() of an unsigned integer into an enum? |
| 05:43:52 | * | DAddYE joined #nimrod |
| 05:44:02 | * | DAddYE quit (Remote host closed the connection) |
| 05:44:08 | * | DAddYE joined #nimrod |
| 05:57:55 | * | OrionPK quit (Read error: Connection reset by peer) |
| 06:04:02 | * | mflamer_ joined #nimrod |
| 06:06:49 | * | mflamer quit (Ping timeout: 268 seconds) |
| 06:20:58 | * | DAddYE quit (Remote host closed the connection) |
| 06:21:06 | * | DAddYE joined #nimrod |
| 06:27:09 | * | mflamer_ quit (Ping timeout: 246 seconds) |
| 07:02:37 | * | Jackneill joined #nimrod |
| 07:14:38 | * | dLog_ quit (Read error: Connection reset by peer) |
| 07:58:04 | * | ics quit (Ping timeout: 264 seconds) |
| 07:59:16 | * | ics joined #nimrod |
| 08:42:07 | * | sebcrozet joined #nimrod |
| 08:58:35 | * | reactormonk quit (*.net *.split) |
| 09:05:43 | * | reactormonk joined #nimrod |
| 09:14:46 | * | sebcrozet quit (Quit: Gone) |
| 09:26:27 | * | DAddYE quit (Remote host closed the connection) |
| 09:26:54 | * | DAddYE joined #nimrod |
| 09:31:22 | * | CarpNet joined #nimrod |
| 09:31:47 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 09:33:11 | * | ics quit (Ping timeout: 272 seconds) |
| 10:14:53 | * | wlhlm joined #nimrod |
| 10:22:18 | * | EXetoC joined #nimrod |
| 10:49:18 | * | EXetoC quit (Ping timeout: 246 seconds) |
| 10:56:48 | * | musicalchair quit (Ping timeout: 272 seconds) |
| 11:06:35 | * | EXetoC joined #nimrod |
| 11:08:17 | * | musicalchair joined #nimrod |
| 11:13:40 | * | freezerburnv joined #nimrod |
| 11:54:11 | * | gour joined #nimrod |
| 12:08:59 | gour | i read in reddit comments about some recent development going on in nimrod like user-defined typeclasses (could not docs about it), some improvements/add-ons for FP programming as well as support for C++ in c2nim. now, seeing there is wxRust project (using wxhaskell's wxC), i wonder if prividing wx bindings for nimrod could be done using c2nim's C++ support or, similar to (wx)rust, by using wxC? |
| 12:10:55 | gour | besides rust, another option which i consider atm is ocaml due to some activity going on with lablqt/wxocaml projects... |
| 12:11:25 | * | gour definitely gave up on adaž |
| 12:15:03 | * | faassen joined #nimrod |
| 12:20:46 | * | qwebirc12228 joined #nimrod |
| 12:25:05 | * | qwebirc12228 quit (Ping timeout: 250 seconds) |
| 12:35:10 | * | fredmorcos joined #nimrod |
| 12:36:35 | BitPuffin | gour: Yeah I considered going with ocaml but I decided to stay with nimro |
| 12:36:36 | BitPuffin | d |
| 12:37:39 | BitPuffin | gour: you could definitely bind wxWidgets with c2nim |
| 12:39:09 | fredmorcos | Hello, I'm new here, I've been *technically* counter productive for a very long time now, some years actually... due to the lack of a sensible programming language and tooling issues... I've been through the entire spectrum between C and Haskell if you know what I mean... |
| 12:39:46 | fredmorcos | I recently read about Nimrod, and so far it seems like what I've been imagining as an ideal programming language to work with |
| 12:40:19 | fredmorcos | I'm not so sure about the tooling though, didn't have time to take a look yet, but I hope I'm here to stay :) |
| 12:41:17 | BitPuffin | fredmorcos: I've went through the same thing! What exactly do you wonder about with the tooling? |
| 12:41:25 | BitPuffin | fredmorcos: There is an IDE |
| 12:41:42 | BitPuffin | fredmorcos: nimrod comes with a debugger, and debugger |
| 12:41:52 | BitPuffin | and profiler* |
| 12:42:24 | fredmorcos | BitPuffin, well, to start off, it would be great if the compiler could already provide the framework for using it in building IDEs |
| 12:42:42 | EXetoC | it does |
| 12:42:48 | BitPuffin | fredmorcos: some info about the built in tools here. http://nimrod-code.org/tools.html and the IDE is here: https://github.com/nimrod-code/Aporia |
| 12:43:16 | fredmorcos | so that the same analyzer runs when I'm writing code and when I'm building my code |
| 12:43:17 | BitPuffin | fredmorcos: Yeah it does that like EXetoC said |
| 12:43:42 | fredmorcos | oh... sounds very reasonable... most compilers don't do that |
| 12:44:11 | fredmorcos | i built aporia on archlinux yesterday, I really like the auto completion |
| 12:44:17 | fredmorcos | but I am very stuck with emacs |
| 12:44:54 | BitPuffin | fredmorcos: You could definitely build IDE like functionality using the built in stuff in the compiler. I want to do the same for vim |
| 12:45:13 | fredmorcos | I just got used to some features of emacs and its keybindings that i can't let go anymore |
| 12:45:13 | EXetoC | what's missing in nimrod.vim? |
| 12:45:31 | BitPuffin | EXetoC: afaik it only provides syntax highlighting |
| 12:45:45 | fredmorcos | is the nimrod compiler able to provide auto-completion suggestions? |
| 12:46:44 | fredmorcos | something like nimrod suggest <file>:<line>:<column> |
| 12:46:58 | fredmorcos | then nimrod-mode or nimrod.vim could parse that output |
| 12:47:16 | EXetoC | semantical analysis and go to definition as well, but no completion yet according to the wiki |
| 12:47:44 | fredmorcos | EXetoC, fair enough, but would such a feature be welcomed? |
| 12:49:13 | EXetoC | nimrod --advanced should list the interface used by Aporia for example. look for idetools |
| 12:49:26 | EXetoC | can't see why not; especially if it's something that can be toggled |
| 12:49:54 | dom96 | The Nimrod compiler does provide auto-completion suggestions. |
| 12:49:57 | dom96 | That's what Aporia uses. |
| 12:50:11 | dom96 | I believe nimrod.vim supports that. |
| 12:50:29 | BitPuffin | dom96: not from what I have noticed |
| 12:50:36 | fredmorcos | --track:FILE,LINE,COL track a file/cursor position |
| 12:50:39 | BitPuffin | dom96: Well it provides vim normal autocompletion |
| 12:50:41 | dom96 | I think i've seen emacs support it too. Ask reactormonk when he's around. |
| 12:50:52 | BitPuffin | dom96: but it doesn't suggest based on what the compiler would think is available |
| 12:51:03 | BitPuffin | dom96: only like words in the same file |
| 12:52:37 | EXetoC | it uses --track and --trackDirty apparently |
| 12:57:35 | fredmorcos | I have question, I read about the function pragmas, things like NoSideEffects and NoWriteIO and so on... when a function is tagged with such a pragma, is it still allowed to call another function that is not tagged with such pragmas? |
| 12:58:03 | BitPuffin | EXetoC: what does? |
| 12:58:15 | BitPuffin | fredmorcos: don't think so |
| 12:58:23 | BitPuffin | fredmorcos: or well |
| 12:58:27 | BitPuffin | fredmorcos: it is allowed probably |
| 12:58:34 | BitPuffin | fredmorcos: if the proc doesn't have side effects |
| 12:58:38 | BitPuffin | that's my guess |
| 12:59:37 | * | Ricky_Ricardo joined #nimrod |
| 12:59:51 | EXetoC | after the compiler is able to deduce that implicitly, I'd assume |
| 12:59:57 | fredmorcos | okay, sounds reasonable, since it guarantees me (as a programmer) that any library function calls from my function aren't doing any IO |
| 13:00:32 | gour | BitPuffin: what were some pro/cons of ocaml vs nimrod in your case? |
| 13:00:46 | EXetoC | BitPuffin: nimrod.vim, so yes it's only for go to definition |
| 13:01:03 | BitPuffin | EXetoC: strange, I've never noticed that |
| 13:01:05 | fredmorcos | EXetoC, same for emacs-mode |
| 13:01:33 | fredmorcos | although emacs-mode requires the auto-complete package ^_^ |
| 13:02:39 | gour | i'm with vim and hope support will improve, but not sure if i desperately need IDE |
| 13:03:16 | EXetoC | BitPuffin: noticed what? I found that out by grepping, and the readme provides a go to function |
| 13:06:29 | BitPuffin | gour: nimrod has the advantages that it has amazing macros and let's you do manual memory management and inline asm (that IS possible with ocaml but doesn't come by default, you have to add it yourself). Ocaml has the advantage that it's been around for a longer time and is very stable and has some features that I miss in nimrod (pattern matching, function currying, I am working on adding that with macros though which wouldn't have worked |
| 13:06:29 | BitPuffin | in ocaml). Ocaml has the disadvantage that it has problems with paralellisation. Although I don't know how nimrod compares there, maybe both do multiprocessing with multiple processes passing messages, which is fine but maybe nimrod can do better I dont know. |
| 13:07:14 | BitPuffin | gour: also even though the GC of ocaml is pretty nice the GC in nimrod seems to be even better |
| 13:07:23 | BitPuffin | which is a huge pro for me since I do games |
| 13:08:46 | gour | thanks...i do not miss manual memora mgmt and inline asm, but i do miss pattern matching & co. |
| 13:08:59 | BitPuffin | gour: co? |
| 13:09:18 | * | freezerburnv quit (Quit: freezerburnv) |
| 13:09:21 | BitPuffin | gour: anyways the advantage nimrod has is that you can pretty much anything you miss with macros |
| 13:09:30 | gour | there is also some branch in ocaml supposed to fix parall....opam is nice and community is becoming more active |
| 13:09:40 | gour | BitPuffin: co = some other FP stuff |
| 13:10:20 | gour | BitPuffin: indeed. besides that, nimrod's syntax is really terrific, especially when looking at something like rust :-) |
| 13:10:22 | BitPuffin | gour: ah you mean like company. Well maybe you could help working on adding some FP stuff with me :D I also want some more of those things |
| 13:10:32 | BitPuffin | gour: yes I know but it's a very difficult issue |
| 13:10:39 | BitPuffin | gour: and nimrod has babel, which is also nice :D |
| 13:10:53 | BitPuffin | and the community is growing slowly but steadily :) |
| 13:11:37 | gour | BitPuffin: otoh, i'm not into games, but more for 'general' GUI bindings (gtk excluded as incapable for multi-platform work), but have to be silent about it in order not to make gods angry ;) |
| 13:11:38 | EXetoC | ok it uses --suggest and --def as well, in addition to the formerly mentioned options, and of course --server |
| 13:11:57 | * | freezerburnv joined #nimrod |
| 13:11:57 | * | freezerburnv quit (Client Quit) |
| 13:13:47 | BitPuffin | gour: well nimrod can interface with C++ with a little work :D you would be praised for binging wxWidgets or Qt I'm certain |
| 13:14:11 | * | freezerburnv joined #nimrod |
| 13:15:01 | * | freezerburnv quit (Client Quit) |
| 13:15:07 | gour | BitPuffin: someone on reddit said 'Probably not' in regard to qt |
| 13:15:34 | * | dymk quit (Ping timeout: 262 seconds) |
| 13:16:17 | BitPuffin | gour: it is possible but since Qt is extremely huge it's not exactly viable for just one guy |
| 13:16:29 | dom96 | gour: I really wish you would just get started instead of endlessly wondering what language to use. |
| 13:17:13 | dom96 | In the time since you were here last and now you probably would have been able to wrap Qt. |
| 13:17:15 | gour | dom96: me too. (un)fortunately have other things to do in the meantime |
| 13:18:25 | BitPuffin | gour: I think you would be most happy with nimrod because if there is a missing feature you can add it |
| 13:20:31 | * | dymk joined #nimrod |
| 13:24:58 | * | enurlyx joined #nimrod |
| 13:30:37 | dom96 | Looks like I missed round 7 of framework benchmarks |
| 13:31:12 | BitPuffin | dom96: damn it |
| 13:31:29 | dom96 | But they say they will do a round every month. |
| 13:31:29 | dom96 | so it's all good. |
| 13:31:35 | dom96 | Just need to get it done in a month :P |
| 13:32:22 | gour | what about http://benchmarksgame.alioth.debian.org/ |
| 13:32:27 | BitPuffin | dom96: the optimization? |
| 13:32:45 | dom96 | BitPuffin: Yes. New asyncio specifically. |
| 13:33:00 | BitPuffin | cewl! |
| 13:33:53 | dom96 | gour: For those benchmarks we would probably be within 99% of C's performance, it's not that interesting. |
| 13:35:06 | EXetoC | BitPuffin: so nimrod.vim does indeed use --def and --suggest, which implies that it doesn't just match words. it does complete some things from system.nim, but not from sequtils for example |
| 13:35:33 | EXetoC | I don't know when I'm hitting nimrod.nim and idetools limitations respectively. haven't used Aporia much so I cannot compare |
| 13:35:42 | gour | dom96: well, that's what you know (anticipate, but not others |
| 13:38:14 | EXetoC | either way, neocomplcache and syntastic pwns |
| 13:41:09 | fredmorcos | BitPuffin, gour: pattern matching, partial application, ... would be amazing |
| 13:41:22 | BitPuffin | fredmorcos: on the way :D |
| 13:43:43 | gour | fredmorcos: yes, it would be kind of super-ocaml, iow. offering lot of FP features + rest of imperative goodness in very elegant way |
| 13:44:41 | BitPuffin | gour: comiiiiing |
| 13:46:54 | fredmorcos | gour, well, with those FP features and purity/no-side-effects kinds of pragmas, you can go from assembly and C to haskell all within nimrod :) |
| 13:48:46 | gour | BitPuffin: atm, i'm trying to build wxocaml...let me see... |
| 13:49:14 | BitPuffin | gour: or bind wx to nimrod :P |
| 13:51:09 | EXetoC | I wonder if partial application macro would be practical. At least writing it should be possible |
| 13:52:38 | gour | what does Araq say about such FP plans? |
| 13:53:21 | * | gour quit (Quit: WeeChat 0.4.1) |
| 13:57:11 | * | gour joined #nimrod |
| 13:59:47 | gour | BitPuffin: considering https://github.com/Araq/Nimrod/issues/620 are you on fbsd? |
| 14:06:21 | fredmorcos | how is the nimrod bootstrap working? |
| 14:06:57 | fredmorcos | build an old version of the nimrod compiler with cc, then use that compiler to build the new version (written in nimrod)? |
| 14:07:14 | BitPuffin | gour: nah that was on a server I was considering deploying nimrod on |
| 14:07:47 | BitPuffin | fredmorcos: more or less, C sources are generated every now and then and then you build that and then you build the nimrod one |
| 14:08:41 | fredmorcos | ah cool |
| 14:08:59 | fredmorcos | just to be able to use newer nimrod features in the compiler, correct? |
| 14:09:56 | * | freezerburnv joined #nimrod |
| 14:10:13 | BitPuffin | think so yeah |
| 14:11:31 | * | gour will probably move to free/pc-bsd soon |
| 14:13:19 | fredmorcos | gour, currently on linux? |
| 14:13:35 | gour | fredmorcos: yep, debian (sid) |
| 14:13:48 | fredmorcos | gour: ok... ever given archlinux a try? |
| 14:14:32 | gour | fredmorcos: yes, before switching to debian i spent >5yrs with arch and before that same amount of time on gentoo |
| 14:16:19 | BitPuffin | gour: why are you going to freebsd? |
| 14:16:25 | BitPuffin | gour: btw netbsd is really nice |
| 14:16:35 | BitPuffin | anyways |
| 14:16:42 | BitPuffin | wayland and stuff is coming to linux now |
| 14:16:46 | BitPuffin | on bsd you are gonna miss out |
| 14:17:22 | fredmorcos | from the BSDs, for a desktop/workstation i would personally go with openbsd |
| 14:18:46 | fredmorcos | BitPuffin, wayland doesn't bring much in terms of user-facing features |
| 14:18:52 | fredmorcos | nothing X cannot do now anyways |
| 14:19:06 | fredmorcos | sure, the underlying stack will be cleaner |
| 14:19:24 | fredmorcos | but it will also come with its own set of bugs and issues, because, you know, "let's get it out the door as soon as possible" |
| 14:19:59 | gour | BitPuffin: zfs, then pc-bsd's pbis are cool, reminding me of nixos...it's rolling distro, but stable kernel+userland... |
| 14:20:02 | fredmorcos | plus, most issues on linux systems come from complex desktop environments, and the complex services that need to be running to support those desktops |
| 14:20:28 | * | gour is using i3 only |
| 14:20:34 | * | mflamer joined #nimrod |
| 14:20:56 | fredmorcos | gour, even so, you're probably running many of the u* or *kit stuff |
| 14:21:26 | BitPuffin | gour: sure but zfs works on linux too |
| 14:22:33 | gour | fredmorcos: i've pc-bsd (9.2) on my netbook and everything works. they even wrote gui app for mounting sticks etc. there is some kind of NW (i use wifi), so nothing is missing except running vuescan which i regularly need, but for it installed mint/ubuntu under vbox and everything is fine |
| 14:23:09 | gour | anyway, i'd like to see working nimrod on fbsd |
| 14:23:48 | * | faassen left #nimrod (#nimrod) |
| 14:24:30 | BitPuffin | well Araq doesn't really care about fbsd |
| 14:24:37 | fredmorcos | cool :) maybe when freebsd10 is ready i'll jump over |
| 14:25:06 | BitPuffin | freebsd 10 seems like it's gonna be pretty cool |
| 14:25:28 | gour | fredmorcos: well, that's very soon, 10.0beta2 is coming |
| 14:25:41 | gour | i also run ati card with 9.2 and it works ok |
| 14:31:14 | gour | as far as (nimrod) docs is concerned, manual is preferred over tuts? |
| 14:31:54 | mflamer | Good morning |
| 14:32:21 | * | freezerburnv quit (Quit: freezerburnv) |
| 14:33:19 | mflamer | The manual is best but tutorial is a little easier reading when your new and has a few more examples |
| 14:33:30 | * | freezerburnv joined #nimrod |
| 14:33:45 | fredmorcos | gotta bounce, bbl |
| 14:33:46 | gour | mflamer: manual is more up to date, right? |
| 14:33:49 | * | fredmorcos quit (Quit: Leaving) |
| 14:34:42 | CarpNet | oh btw, re the dynlib linking issue i was having on ubuntu, should i open an issue about that? |
| 14:35:41 | mflamer | It might be, I havent looked at the tutorials much lately |
| 14:38:06 | mflamer | anybody know why this wouldnt work? |
| 14:38:08 | mflamer | proc Foo(T: typedesc): typedesc = |
| 14:38:08 | mflamer | return TFoo[T] |
| 14:38:08 | mflamer | var x:Foo(int) |
| 14:38:42 | mflamer | I have also tried with the proc as {.compileTime.} |
| 14:50:45 | * | OrionPK joined #nimrod |
| 14:53:39 | EXetoC | should a proc be used in that case? I don't know if it makes much sense |
| 14:54:40 | EXetoC | or maybe it does, but I'd just use a template |
| 14:54:59 | mflamer | well, I was hoping to be able to still pass the proc around, although I suspect I couldd only do that at copiletime still |
| 14:59:15 | EXetoC | I think it can only be a proc if removing the pragma would allow it to be executed at runtime as well, which I think seems like a fair limitation |
| 15:06:31 | mflamer | yeah, seems fair |
| 15:07:00 | mflamer | brb |
| 15:11:27 | * | mflamer quit (Ping timeout: 246 seconds) |
| 15:11:27 | EXetoC | I guess you could pass a template around, as maybe an expr |
| 15:11:32 | EXetoC | timing |
| 15:16:37 | OrionPK | dom96 it would be nice to have recv support indefinite size on TSocket |
| 15:16:53 | OrionPK | rather than looping through/crashing if you dont receive exactly the size you input |
| 15:17:11 | OrionPK | just take what you get & return if size == -1 maybe |
| 15:18:24 | OrionPK | as it is, I have to call recv several times to figure out how much to read |
| 15:19:17 | EXetoC | is the async API on the same level? |
| 15:19:43 | OrionPK | hm? |
| 15:20:43 | dom96 | OrionPK: I don't think that's supported by the OS. |
| 15:21:14 | OrionPK | dom96 I think it is.. recv is looping right now until read == size |
| 15:21:25 | OrionPK | and then throwing an exception if timeout is reached |
| 15:22:02 | dom96 | I assume you mean something like http://build.nimrod-code.org/docs/sockets.html#151 |
| 15:22:37 | dom96 | ? |
| 15:22:37 | OrionPK | not that overload |
| 15:22:56 | OrionPK | http://build.nimrod-code.org/docs/sockets.html#143 |
| 15:23:07 | OrionPK | #1076 in sockets.nim |
| 15:23:17 | OrionPK | line 1087 you can see it looping |
| 15:24:33 | dom96 | I don't understand what you want. |
| 15:25:12 | OrionPK | if size parameter < 0, return with the buffer of data you read |
| 15:25:49 | * | noam quit (Read error: Connection timed out) |
| 15:26:04 | dom96 | Do you want the recv proc to return whatever is in the buffer if size == -1? |
| 15:26:13 | OrionPK | yes |
| 15:26:21 | * | MFlamer joined #nimrod |
| 15:26:29 | OrionPK | rather than enforce size |
| 15:26:34 | * | noam joined #nimrod |
| 15:26:50 | dom96 | The recv proc expects a pointer to a pre-allocated string though. |
| 15:26:58 | dom96 | Thus you must tell it how big you preallocated this string. |
| 15:27:14 | OrionPK | er, you're right |
| 15:27:23 | OrionPK | i thought there was another 'length' parameter somewhere |
| 15:27:59 | OrionPK | hrm.. it would be nice not to have to call recv 3 times to get a websocket message |
| 15:28:12 | dom96 | show me your code |
| 15:28:48 | OrionPK | https://gist.github.com/onionhammer/7267136 |
| 15:29:25 | OrionPK | i have to read 2 bytes to determine if I need to read 2 or 8 more bytes |
| 15:29:31 | OrionPK | to determine the length of the message to follow |
| 15:30:43 | * | Endy joined #nimrod |
| 15:30:58 | OrionPK | it works, but most implementations I've seen are just read = recv(fd, buffer, length) |
| 15:31:07 | OrionPK | where if read < length, it's fine. |
| 15:31:08 | dom96 | I'm sadly not familiar with the web sockets protocol. |
| 15:31:26 | dom96 | What languages are those? |
| 15:31:33 | OrionPK | but the way recv is written, if read < length, it crashes |
| 15:31:38 | OrionPK | no point in even having a read parameter |
| 15:31:40 | OrionPK | erm |
| 15:31:43 | OrionPK | read return result |
| 15:32:26 | OrionPK | although maybe thats my fault |
| 15:33:05 | dom96 | Can you give me an example of a sample websocket session? |
| 15:33:23 | * | gour quit (Disconnected by services) |
| 15:33:30 | * | gour_ joined #nimrod |
| 15:33:45 | OrionPK | http://stackoverflow.com/a/8125509/640301 |
| 15:34:16 | EXetoC | how's the socket API? I'll wait if it needs improvements since I don't have anything specific in mind |
| 15:34:22 | EXetoC | or not, if it needs testing |
| 15:34:45 | OrionPK | dom96 you can test it with this: https://github.com/onionhammer/onion-nimrod/tree/master/websockets |
| 15:34:53 | OrionPK | it's nowhere near finished though |
| 15:35:19 | OrionPK | exetoc it has some kinks, I would say |
| 15:35:35 | EXetoC | it's necessary to deal with a lot of platform-specific stuff in the D lib for example |
| 15:35:37 | EXetoC | ok |
| 15:37:43 | dom96 | "one byte which contains the type of data (and some additional info which is out of scope for a trivial server)" |
| 15:37:49 | dom96 | " |
| 15:37:49 | dom96 | one byte which contains the length" |
| 15:38:06 | dom96 | Doesn't it seem logical that you should read the first two bytes manually? |
| 15:38:29 | OrionPK | you should read in whatever is available, then read the 1st two bytes |
| 15:38:37 | OrionPK | or check them rather |
| 15:38:41 | dom96 | huh |
| 15:38:56 | OrionPK | then you can determine how much fo the message is length and how much is header |
| 15:39:07 | OrionPK | this works as it is for now I guess |
| 15:39:37 | * | [1]Endy joined #nimrod |
| 15:39:50 | OrionPK | although I htink there's a memory leak somewhere |
| 15:41:13 | dom96 | also maybe you should use the higher-level recv? |
| 15:41:29 | OrionPK | the deprecated ones? |
| 15:42:38 | dom96 | http://build.nimrod-code.org/docs/sockets.html#145 |
| 15:42:57 | * | Endy quit (Ping timeout: 246 seconds) |
| 15:42:57 | * | [1]Endy is now known as Endy |
| 15:43:02 | * | MFlamer quit (Remote host closed the connection) |
| 15:43:06 | OrionPK | dont think that would help really |
| 15:43:29 | OrionPK | that one modifies the input string |
| 15:43:44 | OrionPK | whereas now Im reusing the buffer |
| 15:43:57 | dom96 | yeah, that's what the low-level one does too... |
| 15:44:28 | OrionPK | no no, not what I meant |
| 15:44:41 | OrionPK | it calls 'setLen |
| 15:45:26 | OrionPK | I dont think my read proc is leaking anyway, it's the connection stuff I think |
| 15:45:31 | dom96 | the websockets protocol looks like a huge mess :P |
| 15:45:37 | OrionPK | ha |
| 15:45:40 | OrionPK | it's pretty easy |
| 15:54:22 | CarpNet | how would i convert a raw pointer array of *cuchar to an array[int8]? i do know the length |
| 15:55:25 | OrionPK | you could do copyMem |
| 15:56:37 | * | qwebirc40955 joined #nimrod |
| 15:57:11 | dom96 | OrionPK: I think that using this "give me the buffer" method would be risky. What if the buffer doesn't contain enough data? |
| 15:57:34 | OrionPK | enough data? |
| 15:57:37 | OrionPK | you mean enough space? |
| 15:57:58 | OrionPK | dom96 thats up to the reader to determine how much data is being sent from the data it receives.. this is pretty typical in socket programming |
| 15:58:11 | CarpNet | thanks OrionPK, that sounds like it may work |
| 15:58:24 | OrionPK | w/ websockets I know from the first 2 bytes how much more data in my buffer is valid |
| 15:58:30 | dom96 | No. I mean, what if all the data has not been transmitted yet? |
| 15:58:51 | dom96 | Therefore is not present in the buffer. |
| 15:59:10 | OrionPK | that means it got broken up by the kernel, i think |
| 15:59:28 | OrionPK | again, its up to the protocol to detect that and call recv again to get the rest |
| 15:59:39 | OrionPK | up to whatever reader/caller of recv that is |
| 16:00:04 | dom96 | You might as well just give it a length explicitly. |
| 16:00:16 | OrionPK | how when I wont know the length until I read it |
| 16:00:38 | dom96 | To say "this is what I expect" |
| 16:01:07 | dom96 | You know how much you need to read to find out the length. |
| 16:01:09 | OrionPK | have you read through beej's network guide? |
| 16:01:11 | dom96 | So you read that first. |
| 16:01:18 | dom96 | No. |
| 16:03:03 | * | qwebirc40955 quit (Ping timeout: 250 seconds) |
| 16:08:25 | EXetoC | risky how? specify the same buffer every time, and read what data is available, then parse |
| 16:16:12 | dom96 | IMO the code is easier to keep safe when you don't have to worry about cases where only a part of the data you are parsing has been received. |
| 16:17:54 | EXetoC | blocking in other words? |
| 16:18:29 | OrionPK | you pass in a timeout exetoc |
| 16:18:30 | EXetoC | there appears to be one such overload. what's the issue with that again? |
| 16:18:45 | OrionPK | which overload is that |
| 16:19:10 | EXetoC | if only there were clickable anchors |
| 16:19:27 | EXetoC | proc recv(socket: TSocket; data: pointer; size: int) |
| 16:19:54 | dom96 | using the timeout to get around this sounds highly inefficient. |
| 16:20:07 | OrionPK | it does |
| 16:20:24 | OrionPK | but passing 0 timeout after select is pretty standard afaik |
| 16:20:33 | OrionPK | thats what you want to do to keep things asynchronous |
| 16:21:34 | * | Demos joined #nimrod |
| 16:23:50 | EXetoC | depends on how often you want to check, I guess. I used a fairly small timeout before, which is a simple way to reduce the CPU usage |
| 16:24:25 | OrionPK | select is supposed to tell you that data is available, that's kind of its raison d'etre |
| 16:24:48 | OrionPK | so timeout shouldnt be necessary after you've ensured there is data to be read |
| 16:25:56 | EXetoC | right |
| 16:26:38 | OrionPK | pulling the stringtable into the global scope reduced memory leakage :\ |
| 16:26:53 | EXetoC | how common is the error file descriptor? I remember not using it for whatever reason |
| 16:26:59 | EXetoC | it never contained any data IIRC |
| 16:28:59 | OrionPK | dunno |
| 16:33:40 | EXetoC | http://stackoverflow.com/a/1343995 uncommon indeed |
| 16:34:35 | * | DAddYE joined #nimrod |
| 16:39:24 | * | huehuehue joined #nimrod |
| 16:53:26 | * | io2 joined #nimrod |
| 16:55:59 | BitPuffin | hmmm |
| 16:56:07 | BitPuffin | why not put nimrod on open suse build service? |
| 16:57:28 | dom96 | would they allow that? |
| 16:57:59 | BitPuffin | dom96: why would they not? |
| 16:58:17 | BitPuffin | dom96: http://en.opensuse.org/openSUSE:Build_Service |
| 17:01:13 | * | silven joined #nimrod |
| 17:01:21 | * | Demos quit (Ping timeout: 246 seconds) |
| 17:02:57 | * | shodan45 quit (Read error: Connection reset by peer) |
| 17:08:59 | * | Demos joined #nimrod |
| 17:09:35 | * | shodan45 joined #nimrod |
| 17:16:18 | * | gour_ is now known as gour |
| 17:22:33 | * | eigenlicht quit (Ping timeout: 265 seconds) |
| 17:32:35 | * | io2 quit (Ping timeout: 260 seconds) |
| 17:36:26 | * | BitPuffi1 joined #nimrod |
| 17:37:35 | * | BitPuffi1 quit (Client Quit) |
| 17:37:44 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 17:38:04 | * | BitPuffin joined #nimrod |
| 17:52:51 | * | enurlyx2 joined #nimrod |
| 17:54:10 | * | brson joined #nimrod |
| 17:55:27 | * | enurlyx quit (Ping timeout: 260 seconds) |
| 18:01:50 | * | Demos quit (Ping timeout: 240 seconds) |
| 18:02:53 | * | huehuehue left #nimrod (#nimrod) |
| 18:09:34 | * | CarpNet quit (Quit: Leaving) |
| 18:13:29 | * | delian2 joined #nimrod |
| 18:13:59 | * | delian1 quit (Quit: Terminated!) |
| 18:16:53 | * | enurlyx2 is now known as enurlyx |
| 18:17:54 | * | filwit joined #nimrod |
| 18:18:37 | filwit | hi |
| 18:18:58 | filwit | nice article, dom96 |
| 18:19:13 | * | Ricky_Ricardo quit (Quit: laptop[lid].close) |
| 18:19:27 | dom96 | filwit: thanks :) |
| 18:19:49 | * | Ricky_Ricardo joined #nimrod |
| 18:22:30 | * | Associ8or quit (Quit: Associ8or) |
| 18:28:15 | Araq | hi filwit, welcome back |
| 18:28:34 | filwit | hey, Araq |
| 18:31:10 | OrionPK | how accurate is getTotalMem? |
| 18:32:49 | OrionPK | ah nm, looks like getOccupiedMem is giving more what I'd expect.. (i.e. growing) |
| 18:35:51 | * | io2 joined #nimrod |
| 18:36:29 | OrionPK | ahh nice, now it's staying at 812k memory :) |
| 18:36:32 | OrionPK | happy day |
| 18:39:10 | * | MFlamer joined #nimrod |
| 18:43:22 | OrionPK | araq, you there? |
| 18:43:31 | Araq | yup kind of |
| 18:44:12 | OrionPK | I had a reference to a TSocket that I was basically ditching any reference to every iteration of a loop and creating a new one, but the GC wasn't cleaning up the unreferenced object |
| 18:45:16 | OrionPK | https://github.com/onionhammer/onion-nimrod/commit/8895d35f37b251d00acf4b2cd56db926862ed8a2 |
| 18:45:33 | OrionPK | if you look at that diff, basically all I cahnged was where the "client" variable is declared |
| 18:45:41 | OrionPK | and now GC is cleaning it up |
| 18:48:43 | Araq | OrionPK: the stack is marked conservatively which can have this effect but it should only keep 1-2 sockets object alive unnecessarily |
| 18:49:22 | OrionPK | it just kept growing in task manager it grew from 800k to 3,000k after a few minutes |
| 18:49:32 | OrionPK | obviously it varied on how much I was hitting it |
| 18:49:47 | OrionPK | (but now I can hit it every millisecond for minutes and it stays at 812k) |
| 18:51:01 | OrionPK | GC_fullCollect didnt seem to make a difference, not sure if it should have, but just throwing that out there |
| 18:51:44 | Araq | make a bug report, it's interesting how a fixed sized stack can produce a growing memory leak |
| 18:52:06 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 18:53:27 | OrionPK | mmk |
| 18:54:45 | Araq | and please add OS and CPU information; hopefully I can reproduce it |
| 18:54:53 | OrionPK | sure |
| 18:55:21 | OrionPK | you can test it w/ my websockets.nim from the link above too |
| 18:55:25 | OrionPK | just revert that change |
| 18:58:46 | Araq | hmm ok |
| 18:59:03 | Araq | will have time to look at it in ~3 months |
| 18:59:06 | OrionPK | :D |
| 18:59:07 | * | BitPuffin joined #nimrod |
| 18:59:38 | * | Demos joined #nimrod |
| 19:01:39 | * | Demos quit (Client Quit) |
| 19:02:15 | * | LoneTech joined #nimrod |
| 19:02:55 | Araq | filwit: I'm still curious about your argument why "HAS" means "IS" and "IS" means "HAS" ... well not really :P |
| 19:03:08 | Araq | hi LoneTech welcome |
| 19:03:25 | LoneTech | minor nitpick: I just built nimrod for the first time and ran into a pointer size fault on the first compilation. I run a 32-bit userspace on an x86_64. Replacing `uname -m` with `gcc -dumpmachine|cut -d- -f1` in build.sh solved that |
| 19:03:32 | LoneTech | hi (: |
| 19:04:20 | Araq | good but 'uname -m' is what we should use according to Posix iirc |
| 19:04:49 | filwit | Araq: ?? |
| 19:05:08 | Araq | filwit: type X: object = |
| 19:05:12 | filwit | Araq: you mean why i think "type Foo: object = ..." should be defautl? |
| 19:05:15 | LoneTech | when not using gcc, it surely works better.. but machine type and build target aren't necessarily the same |
| 19:05:46 | filwit | Araq: it's consistent with the *implied* structure of procs |
| 19:06:22 | Araq | filwit: perhaps but 'type' introduces a section and 'proc' does not, so it's different by design |
| 19:06:24 | filwit | Araq: "proc <name> : <of-type> = <body>" .. "type <name> : <of-type> = <def>" |
| 19:06:46 | filwit | Araq: oh yeah, i don't like that either, haha |
| 19:06:54 | Araq | also you're wrong again |
| 19:07:09 | Araq | it's proc <name> <params> = <body> |
| 19:07:10 | filwit | Araq: i wish either procs would define a section, or types wouldn't |
| 19:07:32 | Araq | proc foo: T doesn't mean foo has type T but that it returns a T |
| 19:07:45 | filwit | Araq: i left out <params> cause it wasn't relevant |
| 19:08:00 | Araq | ': T' is part of params |
| 19:08:21 | Araq | so it's highly relevant |
| 19:08:24 | filwit | okay, i'm not talking about the *current* way the NimrodNode tree is setup |
| 19:08:38 | * | enurlyx quit (Ping timeout: 240 seconds) |
| 19:08:49 | filwit | i'm talking about the way coders *perceive* the structure by thy symbols which are used |
| 19:09:08 | filwit | the fact is, type and proc are inconsistent |
| 19:09:17 | Araq | yes and by design |
| 19:09:36 | filwit | but why add the inconsistency when they dont need to be? |
| 19:10:00 | Araq | they need to be. |
| 19:10:19 | filwit | well i'm not talking about underlining structure |
| 19:10:30 | filwit | i understand procs and types are fundamentally different |
| 19:10:43 | Araq | for instance, mutual recursive types need to be in the same type *section* |
| 19:10:49 | filwit | (although, something like "const Foo: type = ..." might have made sense) |
| 19:11:11 | Araq | so we need the notion of a section for that. ok ok there are other ways to deal with it |
| 19:11:16 | filwit | Araq: i see. so type's need a section, sure. |
| 19:11:43 | Araq | but 'proc' section just leads to overly excessive indentation :P |
| 19:11:57 | filwit | Araq: but that was never really my point (although i still wish procs and types where consistent here, it's not a big deal at all) |
| 19:12:33 | filwit | my original point (a long time ago), was only about the placement of '=' in the type def |
| 19:12:58 | Araq | LoneTech: so what do you proprose? |
| 19:13:00 | filwit | it just doesn't make sense to me, feels out of place, even if it's "clinically" correct |
| 19:13:27 | OrionPK | I agree that type name: inheritsFrom = ... would feel more consistent |
| 19:13:31 | Araq | and yet the '=' is consistent. TYPE foo = body; proc foo = body |
| 19:13:44 | OrionPK | = object just kind of floating at the end after the = feels weird |
| 19:13:48 | filwit | Araq: but those are aliases |
| 19:14:20 | filwit | Araq: no wait, sorry |
| 19:14:38 | filwit | Araq: wait.. why is that inconsistent? that's the syntax i'm asking for, lol |
| 19:14:57 | filwit | Araq: type <name> : <of> = <body> |
| 19:15:00 | Araq | no you ask for type foo : body |
| 19:15:09 | filwit | Araq: or shorthand: type <name> = <body> |
| 19:15:13 | LoneTech | Araq: not really sure yet. Initially I just saw gcc was the default CC, and the -dumpmachine option worked there, but clang doesn't seem to have a similar switch. OTOH, the darwin target already handles ucpu specially. |
| 19:15:26 | OrionPK | he's asking for type foo : <baseType> = <body> (if I follow) |
| 19:15:37 | filwit | OrionPK: yes |
| 19:15:50 | Araq | there is no meaningfuly "basetype" involved |
| 19:15:52 | OrionPK | which I wholeheartedly support |
| 19:16:22 | Araq | well at this point I can only repeat myself |
| 19:16:32 | Araq | and yet the '=' is consistent. TYPE foo = body; PROC foo = body |
| 19:16:58 | Araq | you don't seem to get what a "body" of a type definition means |
| 19:17:02 | OrionPK | type foo = object \n _ _ body you mean :p |
| 19:17:14 | filwit | Araq: but i agree with that... i LIKE type Foo = body |
| 19:17:18 | Araq | OrionPK: yes. you don't get it |
| 19:17:34 | filwit | Araq: i just don't like: type Foo = object; body |
| 19:17:59 | Araq | because your notion of "body" is wrong :P |
| 19:18:10 | filwit | Araq: you don't do: proc foo() = int; return 0 |
| 19:18:10 | OrionPK | to you, the 'object' is part of the body |
| 19:18:12 | OrionPK | right? |
| 19:18:32 | OrionPK | why is it at the top to the right of the = ? |
| 19:18:40 | filwit | Araq: 'object' looks and feels like a keyword or type in the syntax |
| 19:18:41 | OrionPK | nothing else allows you to do that |
| 19:18:54 | * | CarpNet joined #nimrod |
| 19:18:57 | OrionPK | it would give you invalid indentation with a proc |
| 19:18:58 | filwit | Araq: even if it's technically "part of the body" it doesn't _appear_ that way |
| 19:20:02 | Araq | but it does as soon as you understand what can be done with TYPE |
| 19:20:12 | filwit | example? |
| 19:20:13 | Araq | type Foo = array [8, int] |
| 19:20:20 | Araq | type Bar = distinct int |
| 19:20:26 | filwit | type Foo: array[8, int] |
| 19:20:27 | Araq | type Baz = object |
| 19:20:31 | filwit | tpye Bar: distinct int |
| 19:20:43 | filwit | type Baz: object |
| 19:20:44 | LoneTech | looking at http://nimrod-code.org/manual.html#type-sections it appears to be that "object" itself opens up a subblock to declare the contents of the object, which makes sense as most objects have properties |
| 19:20:47 | filwit | type Boo = Bar |
| 19:20:50 | gour | is there some example of user-defined typeclass in nimrod (docs is 'to be written')? |
| 19:21:07 | Araq | gour: that feature is not finished |
| 19:21:27 | Araq | filwit: so you DO want ':' instead of '=' for "consistency" |
| 19:21:34 | Araq | which makes no sense. |
| 19:21:57 | filwit | Araq: .. yes.. i thought that's what we where arguing about this whole time :P |
| 19:22:13 | gour | Araq: i see...it's quite important feature, imho |
| 19:22:35 | * | eigenlicht joined #nimrod |
| 19:23:07 | Araq | hi eigenlicht welcome |
| 19:23:20 | filwit | Araq: and I don't see any reason it doesn't make sense. even if you concept for these symbols needs to be re-adjusted slightly, it still makes sense |
| 19:23:44 | filwit | even if **the |
| 19:24:34 | Araq | and yet the '=' is consistent. TYPE foo = body; PROC foo = body |
| 19:24:46 | Araq | you don't seem to get what a "body" of a type definition means |
| 19:24:57 | filwit | Araq: ah, i see your point now |
| 19:25:17 | Araq | lol |
| 19:25:21 | filwit | Araq: and i was wrong. aliases should be: type Foo: Bar |
| 19:25:48 | filwit | so. type Foo = <body> |
| 19:25:56 | filwit | type Bar: Foo |
| 19:26:01 | dom96 | No. Think of it this way: Foo = Bar means 'Foo equals Bar'. |
| 19:26:13 | filwit | k |
| 19:26:33 | OrionPK | Foo IsA Bar |
| 19:26:35 | OrionPK | not = |
| 19:26:39 | filwit | i understand that, dom96 |
| 19:26:55 | filwit | it's not about what the equal sign means |
| 19:26:56 | Araq | bbl |
| 19:26:59 | filwit | k |
| 19:27:16 | OrionPK | same.. time to go beef |
| 19:27:24 | filwit | dom96: it's about what the ':' means, and how consistent the type/proc syntax is to learn |
| 19:27:52 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 19:28:07 | * | BitPuffin joined #nimrod |
| 19:28:47 | LoneTech | it's not just type and proc; there's var and let too. In those, : denotes types and = assigns values |
| 19:29:10 | filwit | ^ |
| 19:29:22 | filwit | exactly |
| 19:29:55 | filwit | var x:<of-type> = <value> |
| 19:30:04 | filwit | type X:<of-type> = <body> |
| 19:30:14 | filwit | proc x:<of-type> = <body> |
| 19:30:21 | filwit | makes so much more sense to me |
| 19:30:52 | LoneTech | except type blocks *make* types. what's the difference between your of-type and body then? |
| 19:31:16 | filwit | proc blocks *make* procs |
| 19:31:28 | filwit | i don't understand your question really |
| 19:31:33 | EXetoC | the definition |
| 19:33:29 | LoneTech | filwit: could you type out an example with your proposed type syntax where of-type and body are both written out rather than placeholders? |
| 19:33:48 | filwit | LoneTech: sure.. |
| 19:37:07 | filwit | https://gist.github.com/PhilipWitte/7270768 |
| 19:37:11 | EXetoC | types are types and procs and procs |
| 19:37:27 | EXetoC | and then you have proc *types* which are defined in a type block |
| 19:37:44 | filwit | LoneTech: notice the 'vec' which is an alias of 'vec4' |
| 19:40:02 | EXetoC | they are two different concepts so I don't know if the term inconsistency applies. either way, it's really minor so I don't care either way |
| 19:41:56 | filwit | LoneTech: here's another example: https://gist.github.com/PhilipWitte/7270834 |
| 19:42:48 | filwit | LoneTech: the idea is that you can write "type Foo = ..." (shorthand), or "type Foo: object = ..." (explicit) |
| 19:42:54 | EXetoC | will that tuple syntax be unambiguous when used inline? |
| 19:43:12 | * | sebcrozet joined #nimrod |
| 19:43:26 | filwit | ExetoC: ?? |
| 19:43:54 | EXetoC | proc x(): tuple x, y, z = ... |
| 19:44:06 | filwit | ahh, right right |
| 19:44:10 | EXetoC | oops, missed a detail |
| 19:44:29 | filwit | not that it matters |
| 19:44:37 | EXetoC | tuple tuple x, y, z ... |
| 19:44:39 | filwit | try doing that with objects right now... |
| 19:44:57 | filwit | proc x(): object[x, y:float] = |
| 19:44:58 | filwit | doesn't work |
| 19:45:26 | filwit | so it depends on *which* inconsistency you want to tackle, lol |
| 19:45:50 | EXetoC | I don't know what purpose that serves though |
| 19:45:53 | Araq | yes. because 'object' introduces a nominal type so it doesn't make sense to be able to introduce anonymous object types |
| 19:45:56 | filwit | and while it's a "minor" detail, true, it's also one _everyone_ sees |
| 19:46:04 | Araq | nope |
| 19:46:10 | Araq | many people don't see it |
| 19:46:28 | filwit | programmers don't write their own types? |
| 19:46:38 | filwit | or you mean that people just don't care? |
| 19:46:48 | LoneTech | I'm really unsure what to go for in that. partly using : feels like making the blocks of let, proc, object, tuple match up with type. Partly I'm wondering if the names bound by type should be distinct as not holding a value an expression could take. |
| 19:46:49 | Araq | no they don't see the "inconsistency" |
| 19:46:57 | filwit | i do |
| 19:47:12 | filwit | and if you really want to test that theory |
| 19:47:17 | Araq | type foo: int # so foo HAS the type 'int'? NO, it doesn't |
| 19:47:19 | filwit | we could ask a large audiance |
| 19:47:32 | filwit | audience** |
| 19:47:34 | Araq | sure but then it should be unbiased |
| 19:47:39 | Araq | which means non-programmers |
| 19:47:52 | filwit | that's debatable, but sure |
| 19:48:03 | Araq | but ugh the average has no notion of formal languages |
| 19:48:03 | filwit | lol |
| 19:48:13 | Araq | so .. it's pointless |
| 19:48:17 | LoneTech | a large part of the programmer in me feels not changing it would break less |
| 19:48:47 | filwit | LoneTech: i'm more concerned with Nimrod design's longevity |
| 19:49:11 | filwit | cause of course, it's not like this is going to get written anyways.. |
| 19:49:21 | EXetoC | Araq: would "tuple x, y, z: float, w: int" be unambiguous? |
| 19:49:44 | Araq | EXetoC: depends on what you mean exactly |
| 19:49:45 | EXetoC | also, you'd need parens or something with nested tuples, right? |
| 19:50:00 | Araq | right |
| 19:50:11 | filwit | that doesn't matter, uhg... |
| 19:50:21 | filwit | it doesn't matter that it's a "non-nomial" type |
| 19:50:28 | filwit | no one knows the difference! |
| 19:50:30 | Araq | yes it does |
| 19:50:33 | Araq | it does matter |
| 19:50:43 | filwit | no, you mis-understand my meaning |
| 19:50:57 | Araq | and not everybody is the avarage john dumbass script kiddie either |
| 19:51:06 | EXetoC | what matters to me is that it can be defined on the spot; and when you do that, then you obviously don't want any kind of encapsulation |
| 19:51:10 | Araq | many people really can understand these things |
| 19:51:13 | BitPuffin | Araq: What do you think about putting nimrod on the openSUSE build service? It would give you repositories for debian, ubuntu, arch, fedora, opensuse etc etc |
| 19:51:38 | filwit | Araq: i can understand it just fine. that doesn't mean it's nice to use |
| 19:51:41 | Araq | and many also acknowledge the *history* of Nimrod's syntax |
| 19:51:51 | filwit | Araq: and i'm not a dumbass script-kiddie |
| 19:52:06 | Araq | which you completely and utterly miss since all you've ever used is C# :P |
| 19:52:21 | Araq | filwit: sorry, I never implied that |
| 19:52:27 | filwit | Araq: i've used more than just C# (i do much more Javascript than C# anyways) |
| 19:52:45 | Araq | JS doesn't count as a programming language :P |
| 19:53:00 | EXetoC | wut |
| 19:53:08 | filwit | Araq: no, no. i know you weren't calling my a script-kiddie, i'm just using myself as an example of a non-script-kiddie to doesn't like it |
| 19:53:08 | LoneTech | it's a language, though why they chose to Javaify the syntax is a sad story |
| 19:53:15 | filwit | calling me** |
| 19:53:33 | Araq | ok good |
| 19:53:49 | filwit | Araq: an i agree, JS is a horrible, horrible language |
| 19:54:05 | BitPuffin | JS is the worst of all the large programming languages |
| 19:54:31 | LoneTech | really? I'd say PHP is a competitor |
| 19:54:36 | filwit | Araq: whoever thought dynamic-typing + prototype inheritance was a good idea is either simple or played a horrible joke |
| 19:54:49 | Araq | filwit: in any case, syntax is what matters the *least* in any PL. and there have been studies about it afaik |
| 19:54:49 | EXetoC | BitPuffin loses a point |
| 19:54:59 | dom96 | It's funny that so many people think that JS is a crap language and yet node is the coolest kid on the block. |
| 19:55:22 | BitPuffin | LoneTech: forgot about that one :P |
| 19:55:24 | filwit | Araq: no, disagree completely. syntax matters the least when the language is already established |
| 19:55:47 | BitPuffin | LoneTech: PHP is so horrible that I have repressed it |
| 19:55:55 | filwit | Araq: Nimrod needs to give programmers a reason to switch from C#/Java/C++, and that's why details matter |
| 19:56:03 | EXetoC | I'm part of the minority then. bad syntax sucks |
| 19:56:09 | BitPuffin | EXetoC loses a friend |
| 19:56:30 | filwit | Araq: Nimrod can do all sorts of fancy things.. but not everyone is going to take the time to learn about them if they wont read past initial code examples |
| 19:56:36 | BitPuffin | EXetoC: kidding :P |
| 19:56:56 | LoneTech | bad syntax does suck; as does bad naming policies. that along with the state of the documentation is why I am currently interested in Nimrod over ATS |
| 19:57:02 | filwit | Araq: I'm not trying to claim the sky is falling. I'm just saying, details *DO* matter |
| 19:57:07 | BitPuffin | EXetoC, dom96: we should play something soon all three of urs |
| 19:57:45 | Araq | filwit: ok, but anything that connects "syntax" and "Nimrod design's longevity" is misguided |
| 19:58:05 | filwit | Araq: point taken. i mis-spoke |
| 19:58:13 | BitPuffin | the only naming convention of nimrod that I disagree with is that constants are written in code the same way as procs |
| 19:58:15 | LoneTech | I'd rather like to avoid O'Caml-style multiplicity of syntax, though |
| 19:58:16 | dom96 | BitPuffin: totally. What do you have in mind? |
| 19:58:17 | BitPuffin | in the compiler at least |
| 19:58:27 | BitPuffin | dom96: hmm not sure |
| 19:58:36 | BitPuffin | dom96: what do you like? |
| 19:59:00 | EXetoC | I agree with Araq; the concepts are different enough that no consistencies exist |
| 19:59:08 | EXetoC | and I'm done with the bikeshedding |
| 19:59:37 | dom96 | BitPuffin: I like pretty much everything. |
| 19:59:39 | Araq | LoneTech: ok, thanks for your interesting feedback. |
| 20:00:04 | filwit | EXetoC: i still maintain that "type <name> : <of-type> = <body" would be *the best solution*.. but i agree that it's not a huge dea |
| 20:00:05 | BitPuffin | but it's not a biggie |
| 20:00:12 | BitPuffin | It's a bikeshed thing |
| 20:00:25 | LoneTech | just don't take it as law, it's just my still forming opinions |
| 20:00:31 | BitPuffin | I just like that I know that a VARIABLE is a constant if it looks like that |
| 20:01:19 | LoneTech | filwit: but "object" or "tuple" aren't complete types; they each need that body |
| 20:01:35 | filwit | LoneTech: easy solutions to that |
| 20:01:49 | Araq | filwit: the real solution is: |
| 20:01:52 | Araq | object Foo = |
| 20:01:55 | Araq | a, b: int |
| 20:02:11 | Araq | skip the "type" completely and you have another consistent solution |
| 20:02:11 | filwit | LoneTech: and I think the fact that it makes the syntax "apparently more consistent to those who don't want to argue over the details" is a better thing |
| 20:02:21 | filwit | yes Araq: i agree |
| 20:02:30 | BitPuffin | dom96: Yeah I can enjoy more or less anything too :P |
| 20:02:57 | filwit | actually... i honestly hope you eventually do just that.. as it would free up "type" for var names |
| 20:03:15 | Araq | and I might provide that syntax if enough people want it but then we have the Perl-problem again |
| 20:03:32 | filwit | Araq: one very annoying thing about using "type" as a keyword, is that you have to use "typ" everywhere else lol |
| 20:03:34 | Araq | (too many ways to accompish the same) |
| 20:03:47 | EXetoC | or `type`, but I prefer typ |
| 20:04:15 | Araq | filwit: a fair point but I like the 'type' sections so they'll stay |
| 20:04:20 | LoneTech | I think top-level object statement risks confusion with JS-like protype; it still defined a type, right? |
| 20:04:26 | EXetoC | either syntax is fine, but keeping the old syntax would be bad, yes |
| 20:04:59 | Araq | LoneTech: yeah, it's still a type |
| 20:05:15 | BitPuffin | I think type is best |
| 20:05:24 | BitPuffin | putting everything under object is not good |
| 20:05:36 | EXetoC | filwit: type is also an operator |
| 20:05:45 | filwit | BitPuffin: you would only put a single object under 'object' |
| 20:06:04 | BitPuffin | filwit: oh |
| 20:06:15 | BitPuffin | filwit: do you put enums under type right now? can't remember |
| 20:06:21 | LoneTech | but for people from class/object languages, it isn't an object; it's a class, a type of object? |
| 20:06:31 | filwit | BitPuffin: yeah, you put enums under type |
| 20:06:53 | LoneTech | I like the type section myself |
| 20:07:10 | filwit | LoneTech: Araq said the type section wouldn't go away |
| 20:07:23 | BitPuffin | filwit: Yeah so it's very consistent |
| 20:07:26 | BitPuffin | everything under type |
| 20:07:28 | BitPuffin | easy to grok |
| 20:07:40 | * | Dispatch joined #nimrod |
| 20:07:44 | EXetoC | enum under type but not object? can't see why |
| 20:07:47 | filwit | LoneTech: so if he does eventually add "object Foo of Bar = ..." it would be an extra thing |
| 20:08:01 | BitPuffin | EXetoC: right? that would just be confusing |
| 20:08:10 | BitPuffin | newbies would come here and ask |
| 20:08:28 | EXetoC | I welcome logical explanations though, but nothing comes to mind |
| 20:08:32 | BitPuffin | why do I not need to put object in a type section when I have to put everything else under type |
| 20:08:57 | BitPuffin | and then we would say because people coming from class languages would find it more attractive |
| 20:09:00 | BitPuffin | doesn't make sense |
| 20:09:09 | filwit | Araq: also, i'm not a big fan of the "object Foo of Bar = ..." unless it's meant to completely replace the type syntax. |
| 20:09:23 | filwit | Araq: i would rather live with "type Foo = object" |
| 20:09:23 | BitPuffin | I think type sections makes things feel organized somehow |
| 20:09:37 | Araq | filwit: excellent ok |
| 20:09:47 | filwit | Araq: it will probably be more confusing to new users if you add in something special which works completely differently |
| 20:10:11 | Araq | yup plue you want a 'class' macro for your stuff anyway I guess |
| 20:10:15 | Araq | *plus |
| 20:10:23 | filwit | Araq: i still think you should switch the "=" to ":" and remove the "of" and.. etc.. but i'm done trying to get my way :P |
| 20:10:26 | BitPuffin | Araq: weren't some people working on that? |
| 20:10:52 | filwit | Araq: exactly.. i'm probably just going to write macros to wrap all this stuff anyways (i have to to make interfaces properly) |
| 20:11:03 | Araq | BitPuffin: no they exist and work but nothing has been sanctionized officially |
| 20:11:26 | BitPuffin | the only thing I have felt a bit unclean is that : is used both for type annotations and stuff like if statements |
| 20:11:30 | BitPuffin | but that's nitpicky |
| 20:12:00 | * | sebcrozet left #nimrod ("Gone") |
| 20:12:38 | Araq | that was a close call in the syntax design but I prefer 'if foo: bar else: baz' over 'if foo bar else baz' |
| 20:12:41 | EXetoC | BitPuffin: right, logical grouping. I sometimes have multiple adjacent type sections for that reason |
| 20:13:01 | filwit | yeah, gotta agree with BitPuffin.. it's one of the reason i didn't want to do things in macros originally.. cause it would be inconsistent with how to define proc/types |
| 20:13:21 | filwit | wait... |
| 20:13:43 | filwit | Araq: could you make it so the ':' where completely optional (like they are with 'case' now) ? |
| 20:13:57 | filwit | Araq: not actually asking you too, btw |
| 20:14:05 | filwit | Araq: just want to know if it's possible |
| 20:15:03 | Araq | I don't know. using INDENT instead of ':' INDENT should work everywhere |
| 20:15:32 | EXetoC | and parens would be used when spanning multiple lines? or just an additional indent (deeper than the following block) |
| 20:15:39 | BitPuffin | Araq: what do you think about having a then keyword? |
| 20:15:50 | filwit | BitPuffin: NO! |
| 20:15:53 | BitPuffin | if foo then elif bar then else |
| 20:16:00 | BitPuffin | filwit: :P |
| 20:16:00 | filwit | NO NO NO |
| 20:16:03 | filwit | lol |
| 20:16:12 | EXetoC | you forgot 'end' |
| 20:16:18 | BitPuffin | EXetoC: yeah |
| 20:16:47 | Araq | BitPuffin: pascal uses 'while x do' and 'if x then' and I find it annoying when I have to transform an 'if' into a 'while' (which is not uncommon to do) |
| 20:17:09 | BitPuffin | The thing that also feels like a clash is that with if you do : and then it executes what is in the body and with procs it has = and then what it executes |
| 20:17:26 | BitPuffin | Araq: yeah I can see why that would be annoying |
| 20:18:17 | EXetoC | should we have a 'pair' iterator for typedesc[enum] |
| 20:18:29 | filwit | okay.. well anyways, on to real problems. my SDL2 OpenGL code is rendering but not displaying my GL Vertex Array |
| 20:18:54 | EXetoC | been there, about 18 times. I always get the offsets wrong |
| 20:18:58 | filwit | gotta figure out if it's cause the matrix is messed up, or cause SDL is doing something to the GL context... |
| 20:19:24 | filwit | ExetoC: :D |
| 20:20:44 | * | mah joined #nimrod |
| 20:20:55 | Araq | hi mah welcome |
| 20:21:11 | EXetoC | and column-major coupled with the way arrays are declared does my head in |
| 20:21:29 | Araq | bbl |
| 20:21:36 | filwit | EXetoC: yeah, matrices suck sometimes |
| 20:21:39 | filwit | Araq: later |
| 20:21:54 | EXetoC | but I'm gonna specialize in web scraping rather than game development so it doesn't matter |
| 20:22:03 | EXetoC | j/k |
| 20:22:27 | filwit | EXetoC: i'm copying code from another C# code-base, so it's not a lot of head-scratching over math right now |
| 20:22:32 | filwit | LOL |
| 20:22:33 | EXetoC | it's pretty easy once the actually interface does the right thing though |
| 20:22:39 | EXetoC | right |
| 20:23:03 | filwit | well that's why we work with Quaternions and stuff more |
| 20:23:05 | EXetoC | good thing you don't copy from GLM |
| 20:23:10 | filwit | i just take setting up perspective matrices |
| 20:23:22 | filwit | yeah, i never really looked at GLM |
| 20:23:29 | EXetoC | you need an IDE to navigate through that template maze |
| 20:23:39 | filwit | it's OpenGL focused, so doesn't really work with DirectX (which uses row-major matrices) |
| 20:23:51 | EXetoC | it supports both |
| 20:23:59 | filwit | ahhh, didn't know that |
| 20:24:22 | filwit | I've always just written my own, that way i know what's going on |
| 20:24:35 | filwit | plus i'm not guessing about optimization |
| 20:32:46 | filwit | woah.. dom96: 59 users? |
| 20:32:56 | dom96 | record is 60 :P |
| 20:33:06 | filwit | damn >:| |
| 20:33:14 | filwit | well, not damn, that's a good thing |
| 20:33:23 | filwit | seems to be going up faster now though |
| 20:33:37 | filwit | 40 was the record just a few weeks ago |
| 20:34:03 | filwit | i noticed your article on reddit got good reception |
| 20:35:21 | filwit | Nimrod only really need a few more articles like that, and a "start application" (or two) and then Araq can find a Nimrod job and then the angles will sing and jesus will return |
| 20:35:35 | filwit | star** application |
| 20:37:24 | Dispatch | To whomever wrote that article; thanks! |
| 20:37:36 | Dispatch | first time I heard from nimrod and I like it a lot |
| 20:38:20 | shodan45 | oooh, new round of web framework benchmarks by that tech empower company is out: http://www.techempower.com/blog/2013/10/31/framework-benchmarks-round-7/ |
| 20:38:35 | shodan45 | and yes, nimrod is on there |
| 20:38:51 | shodan45 | (although it didn't do very well...) |
| 20:40:48 | filwit | didn't do horrible either |
| 20:40:53 | filwit | and Jester is new, right? |
| 20:41:15 | shodan45 | who wrote jester again? |
| 20:41:21 | filwit | dom96 |
| 20:41:53 | shodan45 | dom96: explain yourself ;) |
| 20:43:05 | * | Endy quit (Ping timeout: 268 seconds) |
| 20:43:27 | dom96 | shodan45: I didn't get a chance to optimise it. |
| 20:44:10 | filwit | dom96: seriously. how could you, a single young adult, not create a web-framework in a new language that completely obliterated the alternatives with their millions of dollars and IDE support |
| 20:44:45 | shodan45 | dom96: tsk tsk tsk... making Araq look bad :P |
| 20:44:53 | filwit | lol |
| 20:45:22 | shodan45 | dom96: seriously, I swear I'm going to try jester one day.... just not today :/ |
| 20:45:35 | dom96 | hah |
| 20:45:42 | * | shodan45 is stuck in php hell |
| 20:46:00 | shodan45 | aka the worst language ever made |
| 20:46:01 | * | filwit is with shodan45 in php hell |
| 20:46:16 | filwit | although i mostly do JS and Unity/C# now |
| 20:47:08 | shodan45 | I remember way way back in 1999 when I found php. It was soooo cool back then. o_o |
| 20:50:54 | EXetoC | dom96: aiming for #1 next time? |
| 20:51:39 | dom96 | Maybe if I got a million dollars in funding :P |
| 20:52:15 | EXetoC | oh |
| 20:53:09 | filwit | one day, dom96, one day |
| 20:54:39 | OrionPK | Araq it'd be nice if the import foo.bar.nim would first check to see if "foo.bar.nim" existed before "foo/bar.nim" |
| 20:55:41 | filwit | OrionPK: i could see that leading to some hard-to-find bugs |
| 20:55:57 | OrionPK | import foo.bar* rather, not foo.bar.nim |
| 20:56:03 | filwit | OrionPK: or maybe just some "why isn't this importing" bugs which are easy to find... |
| 20:56:13 | OrionPK | filwit give me a scenario |
| 20:56:58 | filwit | OrionPK: no, your right, i can't think of any (thought something would happen that doesn't) |
| 20:57:07 | filwit | gtg though, bbl |
| 20:57:09 | * | filwit quit (Quit: Leaving) |
| 20:58:08 | * | Jackneill quit (Remote host closed the connection) |
| 21:02:49 | BitPuffin | EXetoC: by the way linagl is switching to row major |
| 21:04:00 | MFlamer | good, column major matricies are bastard anyway |
| 21:04:27 | * | freezerburnv quit (Quit: freezerburnv) |
| 21:04:31 | BitPuffin | MFlamer: yeah, the column major decision was ill-informed, as with opengl 3.x and up it doesn't really care anymore |
| 21:04:56 | BitPuffin | eventually though I wanna make it a choice |
| 21:05:09 | BitPuffin | so that you can choose if it should be row major or column major |
| 21:05:13 | BitPuffin | but row major will be the default |
| 21:05:54 | MFlamer | It's just another thing to promote mistakes for me. I always think of matrices as a column of vectors etc. |
| 21:05:57 | EXetoC | I thought there were advantages with column-major as well |
| 21:06:05 | EXetoC | but if OpenGL doesn't care anymore, then I don't either |
| 21:06:47 | EXetoC | so what are the differences now? no need to transpose? |
| 21:07:26 | BitPuffin | EXetoC: well first of all since it's programmable it matters in the sense in which way your shaders are written |
| 21:07:48 | BitPuffin | EXetoC: I believe it's a flag that you set when you update matrix data iirc |
| 21:14:55 | gour | dom96: i'm not familiar at all with sinatra, but curious with which python-powered framework could jester be compared? |
| 21:15:11 | BitPuffin | gour: flask |
| 21:15:30 | gour | ahh, ok. so, micro-wave :-) |
| 21:15:35 | BitPuffin | yeah :) |
| 21:15:44 | BitPuffin | even more so than flask/sinatra :P |
| 21:15:53 | gour | lol |
| 21:16:16 | BitPuffin | but it's fun |
| 21:16:18 | BitPuffin | try it |
| 21:17:16 | EXetoC | MFlamer: some argue that column-major is more cache friendly. is that a minor point? |
| 21:19:49 | MFlamer | Yeah, I've heard that. But, isnt most of the vector-matrix operations happening on the GPU anyway? |
| 21:20:06 | BitPuffin | EXetoC: I am not really sure that's true |
| 21:23:42 | MFlamer | we keep a matrix stack and concateate it our scene graph, but the matrix gets used in the shaders on the gpu for most of the heavy work, but I'm not thinking about it much, so I could be easily missing something |
| 21:25:22 | MFlamer | just talking in general, not about any specific scene graph |
| 21:26:11 | BitPuffin | I can't really think of any way that column major would be more cache friendly |
| 21:27:29 | EXetoC | is it a tree? some guys complained about the scene tree layout, so I decided to take a different approach in my own code. it seems to work pretty well |
| 21:27:39 | BitPuffin | http://stackoverflow.com/questions/16699247/what-is-cache-friendly-code |
| 21:27:47 | EXetoC | BitPuffin: I don't know. When accessing individual vectors? |
| 21:29:55 | BitPuffin | in his example it seems like row major is the cache friendly one even |
| 21:30:18 | EXetoC | I want 1GB of Really Fast Memory (tm) |
| 21:30:22 | BitPuffin | EXetoC: well that doesn't really matter |
| 21:30:46 | BitPuffin | EXetoC: for example with a col major matrix you'd put the w vector in the last column |
| 21:30:56 | BitPuffin | but in the row major one you'd put it in the last row |
| 21:31:29 | BitPuffin | and when doing matrix matrix multiplication it will use the rows of one matrix and the columns of another |
| 21:31:33 | BitPuffin | one of them will be slower |
| 21:32:10 | EXetoC | I guess someone was wrong on the internets then |
| 21:32:24 | BitPuffin | EXetoC: it really depends on the operation |
| 21:32:27 | BitPuffin | as for the GPUs |
| 21:32:47 | BitPuffin | well they might store them different to what the API wants you to believe anyway |
| 21:33:38 | * | io2 quit () |
| 21:38:51 | * | freezerburnv joined #nimrod |
| 21:41:19 | * | Dispatch quit (Quit: Page closed) |
| 21:48:11 | * | kib2 joined #nimrod |
| 21:51:44 | * | kib2_ joined #nimrod |
| 21:52:50 | * | freezerburnv quit (Quit: freezerburnv) |
| 21:53:33 | * | kib2 quit (Ping timeout: 252 seconds) |
| 21:53:38 | * | kib2_ is now known as kib2 |
| 21:54:30 | kib2 | Hi, I'm trying to install Babel on a Windows but it fails with the following message "could not import: CRYPTO_set_mem_functions". Any idea ? Thanks. |
| 21:55:49 | dom96 | You need the latest compiler from Github. |
| 21:56:25 | dom96 | or just grab the latest openssl wrapper from github, that's really the only thing you need I think. |
| 21:58:04 | kib2 | Thanks dom96, I'll try your solution. |
| 22:08:15 | kib2 | It's even worse, I cannot produce any babel.exe now: http://pastebin.com/xkCMiY1U |
| 22:10:50 | dom96 | hrm, perhaps you should just try bootstrapping the latest compiler from github. |
| 22:11:30 | dom96 | Not sure what happened there, the errors are not in English. |
| 22:12:22 | kib2 | Yep; I'm French, but there're not French either :) |
| 22:14:31 | kib2 | In fact I just took the latest NimBuild windows version "5468d8f62bd6" then copied/pasted to the old Nimrod directory. Maybe I was a bit optimistic. |
| 22:22:25 | * | mah left #nimrod (#nimrod) |
| 22:22:45 | gour | very nice article praising nimrod (if you're not already aware of it) by some known FreeBSD-er - http://ivoras.sharanet.org/blog/tree/2013-10-05.what-i-like-about-the-nimrod-programming-language.html |
| 22:27:29 | MFlamer | That is a nice article. I had not read that one yet |
| 22:28:00 | kib2 | Ok, it's working fine now with the x86 build. |
| 22:32:05 | Scramblejams | Silly import question. I've been playing with the enet wrapper, and I notice that "import enet" seems to import a bunch of names into my file's scope. (Apologies if my nomenclature's unrigorous.) In Python, import foo means the only clutter added to my namespace is "foo," but it seems like that's not happening here, and I'm not sure by what mechanism that happens. |
| 22:36:13 | Scramblejams | For example, see this source file: https://github.com/fowlmouth/nimrod-enet/blob/master/examples/testserver.nim |
| 22:36:26 | Scramblejams | Line 10 uses some constant EnetHostAny. |
| 22:36:43 | Scramblejams | How did "import enet" put that into this file's namespace? |
| 22:37:46 | dom96 | Scramblejams: Every symbol from the module is imported. |
| 22:37:53 | dom96 | well, every public symbol. |
| 22:37:56 | Scramblejams | ick |
| 22:38:07 | * | BitPuffin wonders how he got it working on freebsd |
| 22:38:38 | gour | BitPuffin: he's expert in freebsd |
| 22:38:41 | Scramblejams | Any way to change that? It invokes tremendous feelings of insecurity in me. |
| 22:38:44 | gour | :-) |
| 22:38:57 | Scramblejams | I have no idea what I'm cluttering my namespace with without going in and looking at all the public declarations. |
| 22:40:49 | Scramblejams | And then there's two ways to get at the symbols, right? I can say EnetHostAny or enet.EnetHostAny. |
| 22:42:42 | dom96 | Scramblejams: You can get around it, but it's not the nimrod way (tm) :P |
| 22:43:41 | Scramblejams | So what's the point of the second form, enet.EnetHostAny? Is it to get at non-public symbols? |
| 22:43:48 | BitPuffin | gour: well he said that he hasn't even learned the language yet |
| 22:44:00 | BitPuffin | gour: so he couldn't have fixed whatever bugs I encountered |
| 22:44:16 | BitPuffin | unless he is using the release version |
| 22:44:38 | BitPuffin | because I'm pretty sure they worked |
| 22:44:42 | dom96 | Scramblejams: It's useful when you have to disambiguate. |
| 22:45:14 | gour | BitPuffin: maybe tried on non-fbsd, he works on university where there are plenty of machines/OS-es |
| 22:45:18 | Scramblejams | dom96: Okay, so what happens when module A and mobule B both publicly declare symbol C? Do you get a compiler warning if you don't disambiguate? |
| 22:45:37 | BitPuffin | gour: could be |
| 22:45:51 | dom96 | Scramblejams: You get a compiler error. |
| 22:46:00 | BitPuffin | gour: I think the release version works though. And most newcomers probably install that because that's what I guess is common sense in a way |
| 22:46:18 | * | gour graduated (many years ago) at the same university :-) |
| 22:46:19 | BitPuffin | Scramblejams: you can also import foo as bar |
| 22:46:30 | BitPuffin | I mean from foo import bar as baz |
| 22:46:54 | BitPuffin | gour: cool! which one? |
| 22:47:34 | gour | BitPuffin: http://www.fer.unizg.hr/en |
| 22:47:37 | BitPuffin | dom96: I wonder how it would be to write a file system in nimred :P |
| 22:47:41 | BitPuffin | nimrEd |
| 22:47:57 | dom96 | Nimred: The Halloween version of Nimrod. |
| 22:47:59 | dom96 | :D |
| 22:48:24 | BitPuffin | croatia huh gour |
| 22:48:26 | BitPuffin | :D |
| 22:48:33 | BitPuffin | dom96: nimredrum |
| 22:48:39 | Scramblejams | So my concern in this stems from my experience in Python, where this sort of behavior is considered nasty and unacceptable magic, because of the likelihood that you'll unwittingly reuse the symbol and end up with ugly bugs. With Nimrod's static type system, assuming the types aren't the same, the compiler saves you. What happens when the sames are the same? |
| 22:48:51 | dom96 | BitPuffin: The Shining reference, nice. |
| 22:48:58 | BitPuffin | dom96: I think so |
| 22:49:04 | Scramblejams | Err, when the types are the same? Oops. :-) |
| 22:49:25 | dom96 | BitPuffin: Funny, I only watched The Shining a couple days ago. |
| 22:49:31 | BitPuffin | when sames are the same the same one will same with the saming sames |
| 22:49:51 | BitPuffin | dom96: right! I think you mentioned that |
| 22:50:27 | BitPuffin | dom96: but you are only 18, did you dare watch to watch it? :O :O :O |
| 22:50:30 | Scramblejams | It's also unfortunate because you can have a perfectly working source file, and then you decide, hey I wanna add a little functionality, let me start by importing something, oops, just stepped on a bunch of my own symbols. |
| 22:50:51 | Scramblejams | Now I've got to go and fix a bunch of code that was fine a minute ago. |
| 22:51:06 | BitPuffin | Scramblejams: not really |
| 22:51:21 | BitPuffin | Scramblejams: then you just name the imports or refer to them with full path |
| 22:51:55 | Scramblejams | True, but naming imports is generally frowned upon for readability. |
| 22:52:29 | BitPuffin | Scramblejams: I guess, so use full path |
| 22:52:41 | BitPuffin | Scramblejams: there isn't really a way to solve this as far as I know |
| 22:53:06 | Scramblejams | There is: Just make "import foo" add only "foo" to the namespace and it's solved. |
| 22:53:31 | dom96 | BitPuffin: what now? lol |
| 22:53:33 | Scramblejams | Of course that'd break lots of code but the edits could be automated. |
| 22:53:55 | BitPuffin | dom96: huh? :P |
| 22:54:19 | BitPuffin | Scramblejams: I'm not sure that is a solution |
| 22:55:15 | dom96 | Scramblejams: It's really not that big of a problem. Ambiguity errors happen rarely. |
| 22:55:37 | dom96 | You would waste more time writing the module name everywhere than you would fixing the ambiguities :P |
| 22:56:04 | * | wlhlm left #nimrod ("weechat 0.4.2") |
| 22:57:15 | BitPuffin | Scramblejams: the solution you described is a tool requiring solution, not a language based solution |
| 22:59:18 | gour | 'night |
| 22:59:29 | BitPuffin | I think even think full paths make it a bit more readable |
| 22:59:41 | * | gour quit (Quit: WeeChat 0.4.1) |
| 22:59:46 | BitPuffin | because then you know what something comes from |
| 23:00:10 | BitPuffin | just that it is kind of tedious to type the path all the time |
| 23:00:32 | Scramblejams | BitPuffin: Well, sure! I'd love to do that. I'd prefer to do that. But that's not the nimrod way, so when I'm reading source with a bunch of imports at the top, now I'm guessing at where a symbol comes from. |
| 23:00:42 | dom96 | Scramblejams: Also if you really want you can force yourself to write the module name everywhere :P |
| 23:01:12 | Scramblejams | dom96: I'll probably do that so I know where it comes from, but as I said, others aren't doing that, and it makes reading source harder. |
| 23:01:21 | BitPuffin | Scramblejams: well nimrod *can* do it that way |
| 23:01:35 | Scramblejams | Sure, but it's not enforced. The enet module isn't doing it that way. |
| 23:01:38 | BitPuffin | Scramblejams: if you import A then you can do A.foo() |
| 23:01:56 | BitPuffin | Scramblejams: there is barely a single language that enforces it |
| 23:02:04 | BitPuffin | and doing so wouldn't really be all too practical I think |
| 23:02:11 | Scramblejams | What? Python enforces it. |
| 23:02:11 | EXetoC | hopefully people will be explicit when it's not clear |
| 23:02:18 | BitPuffin | it does? |
| 23:02:28 | BitPuffin | didn't know |
| 23:02:36 | Scramblejams | Yes. You do "import foo", if you want something in foo, "foo.whatever" is the only way to get at it. |
| 23:02:37 | BitPuffin | well actually now that you say it |
| 23:02:43 | Scramblejams | Lots of languages work that way. |
| 23:02:57 | Scramblejams | This kind of behavior I associated with "include", not "import." |
| 23:03:01 | BitPuffin | well I still think they are definitely a minority |
| 23:03:09 | Scramblejams | Erlang works that way. |
| 23:03:15 | BitPuffin | Scramblejams: well try looking at D for example |
| 23:03:15 | Scramblejams | Ruby too, IIRC. |
| 23:03:21 | BitPuffin | Scramblejams: no not ruby |
| 23:03:23 | Scramblejams | Nobody uses D. :-D |
| 23:03:37 | Scramblejams | Ruby's full of monkeypatching though, so it wouldn't surprise me. |
| 23:04:00 | EXetoC | it's one or the other in python, yes |
| 23:04:29 | EXetoC | also, you can import only a specific selection, so that might help |
| 23:04:33 | Scramblejams | In Python you can do "from foo import *", but (a) that's frowned upon, and (b) it requires the author to choose to clutter their own namespace. |
| 23:04:45 | * | ics joined #nimrod |
| 23:05:06 | Scramblejams | I'd even argue that C and C++ don't work that way, because they use include, not import. |
| 23:05:22 | Scramblejams | With include, I expect a concatenation of source files. |
| 23:05:23 | BitPuffin | Scramblejams: well the good thing about nimrod is that it doesn't force anything upon you |
| 23:05:44 | Scramblejams | Again, the problem is in reading source: I have no idea where symbols are coming from. A large source file could have a dozen imports at the top. |
| 23:05:46 | BitPuffin | Scramblejams: nimrod has include too, and it works just like include it C |
| 23:05:53 | Scramblejams | BitPuffin: Right, and that's fine. |
| 23:06:00 | BitPuffin | Scramblejams: yes it is frustrating for me too I hear you |
| 23:06:10 | BitPuffin | so it's best to refer with full path |
| 23:07:25 | BitPuffin | Scramblejams: I think it could be that you and me are just too damn focused on details, I tend to look up which module every proc comes from etc because otherwise I feel like my knowledge is incomplete. While in general you can probably get by with just inferring what happens from the proc names |
| 23:07:29 | EXetoC | "123\n456".splitLines. I wouldn't bother in that case, but it'd be nice to have a style guide that stresses these points |
| 23:07:55 | BitPuffin | EXetoC: indeed |
| 23:08:41 | BitPuffin | Scramblejams: however in the case of python it can also be slightly confusing because the syntax is the same as when accessing object fields etc |
| 23:08:43 | BitPuffin | well in nimrod too |
| 23:08:51 | BitPuffin | but I mean since they force it |
| 23:08:59 | Scramblejams | I guess I found it so strange because the nimrod syntax is explicitly influenced by Python, but the behavior of the import keyword is very very different. |
| 23:09:04 | EXetoC | those should really be distinct sentences, but anyway |
| 23:10:00 | Scramblejams | BitPuffin: I guess I look at it as a form of the uniform access principal -- dots for most things. |
| 23:10:01 | EXetoC | syntax yes, but also syntax and other things from pascal and what have you |
| 23:10:30 | Scramblejams | Yeah, it's been 20 years since I played with Pascal, maybe I'd feel more at home if my P-skillz were more up to date. |
| 23:10:32 | BitPuffin | Scramblejams: sure but there can be some confused as of where things are accessed from |
| 23:10:47 | Scramblejams | BitPuffin: how so? Like, you're not sure whether you're hitting a module or an object? |
| 23:11:00 | BitPuffin | Scramblejams: yeah |
| 23:11:43 | EXetoC | '/'? |
| 23:11:51 | BitPuffin | Scramblejams: anyways Python takes the approach of there is one right way and you all should write the same style. Whereas nimrod is powerful for doing that, it doesn't stop you from doing anything, if your style is to refer to proc foo as f_O_o nimrod won't stop you |
| 23:12:11 | Scramblejams | I can't remember ever having that problem, just because methods/functions almost never return a module. So if I'm hitting a module, I know because I imported it at the top of my source file. If I'm hitting an object I know because I either instantiated it or got it from a function. |
| 23:12:23 | Scramblejams | BitPuffin: Yes, I think Perl lost that war. :-) |
| 23:12:51 | BitPuffin | Scramblejams: perl is still alive and well :P |
| 23:13:15 | BitPuffin | but perl has some other less pleasing things about its syntax that probably made it the lesser one |
| 23:13:21 | Scramblejams | Nobody in their right mind starts a big new project in it. |
| 23:13:42 | BitPuffin | interestingly enough ruby borrowed some of that and ended up being pretty |
| 23:14:07 | Scramblejams | Yes, I saw a post from Matz regretting how unnecessarily diverse he'd made the syntax. I guess they cleaned some of that up but I wasn't paying close attention. |
| 23:14:16 | EXetoC | some modules inevitably grow very large though, but visual cue's powered by idetools could remedy this somewhat |
| 23:14:32 | Scramblejams | If I need an IDE to show me where I'm at and what's what, I'm already in trouble. :-) |
| 23:14:49 | BitPuffin | Scramblejams: I agree |
| 23:14:50 | Scramblejams | I hate using IDEs because their editors usually suck. |
| 23:15:10 | Scramblejams | If I can get an emacs mode for my language, I'm happy. |
| 23:15:13 | BitPuffin | Scramblejams: good thing nobody will stop you from writing code where you do A.x |
| 23:15:52 | Scramblejams | EXetoC: Forget a style guide, Nimrod needs its own answer to gofmt. |
| 23:16:01 | * | ics quit (Ping timeout: 245 seconds) |
| 23:16:27 | Scramblejams | That has silenced the format wars which would no doubt still be carrying on to this day in the Go community. |
| 23:17:02 | EXetoC | idetools is used in nimrod.vim too |
| 23:17:06 | dom96 | Araq is/was thinking of making the compiler enforce a style :P |
| 23:17:14 | Scramblejams | And then if Araq decides the right way is to spell out the full symbol path, problem solved. |
| 23:17:20 | Scramblejams | Yeah that'd be awesome actually. |
| 23:17:30 | dom96 | I think many people would protest. |
| 23:17:32 | BitPuffin | I don't think anything should be enforced |
| 23:17:39 | Scramblejams | yes, they would, and then they would continue to get their work done. |
| 23:17:51 | BitPuffin | Scramblejams: without a compiler? |
| 23:17:56 | BitPuffin | oh |
| 23:17:58 | BitPuffin | misread |
| 23:18:11 | BitPuffin | no but seriously |
| 23:18:16 | BitPuffin | nothing should be enforced |
| 23:18:19 | BitPuffin | there is nothing worse |
| 23:18:20 | Scramblejams | We'd all disagree on certain points, but everyone's code would look the same, and that's hugely valuable. |
| 23:18:45 | BitPuffin | Scramblejams: Well I think most nimrod code already looks the same |
| 23:18:54 | BitPuffin | people all name their types like TFooBar etc |
| 23:19:02 | BitPuffin | more or less at least |
| 23:19:15 | BitPuffin | I try to stay faithful to the common conventions |
| 23:19:27 | BitPuffin | even if I don't like to write constantsLikeThis |
| 23:19:30 | Scramblejams | When you've spent a lot of time reading horribly formatted code in diverse languages, the value of one style becomes clear. And that's how it is most of the time -- as a project gets bigger, people usually spend way more time reading code than writing. |
| 23:19:39 | EXetoC | I have nothing against pep8 for example, and I don't hear much hate towards it, so I guess people just get on with it |
| 23:20:22 | * | ics joined #nimrod |
| 23:20:33 | EXetoC | I don't think I'd mind, as long as things like "123\n456".splitLines wouldn't turn into strutils.splitLines("123\n456"), but I highly doubt that :> |
| 23:20:34 | BitPuffin | EXetoC: like most of us already do with nimrod even if we don't have a style guide |
| 23:20:40 | Scramblejams | EXetoC: Yeah, the whole spaces/tabs thing is enough to keep the community busy. :-) Actually, Python's syntax hugely constrains style choices so there's less to argue about there. |
| 23:20:50 | * | freezerburnv joined #nimrod |
| 23:21:11 | EXetoC | yeah |
| 23:21:53 | dom96 | Yeah, we have had at least 2 people already complaining about the enforcement of no tabs. |
| 23:21:54 | Scramblejams | BitPuffin: Your syntax style is already enforced -- indentation, yo! Many people bitterly complained about that for years in Python. |
| 23:22:13 | Scramblejams | People still bring it up as a reason to reject the language outright. |
| 23:22:17 | dom96 | If we enforce style... it will get ugly :P |
| 23:22:31 | Scramblejams | No, the community is still small and Araq is the BDFL. |
| 23:23:02 | BitPuffin | Scramblejams: yes but I don't really think that naming things and syntax is the same thing |
| 23:23:23 | Scramblejams | One day there will be (hopefully) many millions of lines of Nimrod out there. A consistent style is a gigantic benefit to a huge code base and programmers can't be expected to do it consistently, as history shows. |
| 23:23:45 | BitPuffin | yes |
| 23:23:54 | BitPuffin | and that's why you have style guides for your projects |
| 23:24:10 | BitPuffin | either pick the one that most of the community uses |
| 23:24:12 | BitPuffin | or your own |
| 23:24:17 | Scramblejams | There are style guides for C++. And PHP. And every other horribly mangled code you've ever looked at. :-) |
| 23:24:30 | dom96 | There is a lot of disagreements on style though. If we enforce a certain style we may be cutting off a large percentage of the programmer population. |
| 23:24:37 | BitPuffin | yeah and those style guides work |
| 23:24:51 | BitPuffin | within their projects |
| 23:25:00 | Scramblejams | dom96: Yes. The Go inventors were wise to impose gofmt right out of the gate. |
| 23:25:41 | Scramblejams | dom96: But what Nimrod offers is pretty unique, actually. They can't just go somewhere else and get what they're getting from Nimrod. There would be arguments and some anger, but it would subside and people would move on. |
| 23:27:05 | dom96 | Scramblejams: Yeah, but we have a harder time getting users than languages like Go which has Google behind it. |
| 23:27:29 | dom96 | They can afford to do crazy things like not providing any exceptions. |
| 23:27:42 | dom96 | Because people will use it only because Google uses it. |
| 23:27:59 | BitPuffin | good point |
| 23:28:20 | dom96 | If we do that... people simply won't use it. |
| 23:28:20 | Scramblejams | I say that significant whitespace isn't just some magic exception to The Right Way where style is an anything-goes mishmash of craziness. It's just a sliver of a greater principle. |
| 23:29:07 | Scramblejams | dom96: (a) You don't know how many you'll lose and (b) a change like that only gets harder with time. |
| 23:30:30 | dom96 | True. I can predict the numbers though, most programmers are pretty stubborn I think :P |
| 23:33:27 | Scramblejams | Another issue with this import thing is that it gives outsized power to library authors to screw with you. Some guy will have the bright idea to use public symbols named things like person, amount, x, y, z, r, i, j, etc. And then the library users will either have to spend mental energy choosing different variable names than they would have, or will change the names at import time, which is bad for readability. |
| 23:34:33 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 23:34:43 | BitPuffin | Scramblejams: well then making them spend more time on all variables doesn't really solve the time thing. And if they do that you simply don't use their lib P: |
| 23:34:46 | Scramblejams | Of course everybody lived with that in C and C++, but I'd thought we'd all decided that was a bad idea. |
| 23:34:52 | dom96 | In that case you can use "from module import nil" |
| 23:35:40 | Scramblejams | dom96: Nice tip, so I can still do module.foo and module.bar after that? |
| 23:36:07 | dom96 | yes, you can only do that. |
| 23:36:47 | Scramblejams | Cool, that will help me from accidentally departing from my chosen style. As mentioned before, I'm still screwed when I'm reading everybody else's source. :-) |
| 23:38:09 | freezerburnv | Evening all |
| 23:38:16 | EXetoC | complain away |
| 23:38:21 | * | Varriount here |
| 23:38:22 | BitPuffin | we should write plugins for different editors that let's you view source in your own style :P |
| 23:38:36 | BitPuffin | ahoy Varriount |
| 23:38:46 | * | Varriount has been in bed all day |
| 23:39:13 | EXetoC | that's it! |
| 23:39:18 | EXetoC | brilliant |
| 23:39:38 | dom96 | hi Varriount and freezerburnv |
| 23:39:49 | freezerburnv | Hey dom96 |
| 23:42:04 | * | kib2 quit (Quit: ChatZilla 0.9.90.1 [Firefox 25.0/20131025151332]) |
| 23:57:37 | * | freezerburnv quit (Quit: freezerburnv) |