| 00:00:02 | filwit | either is 'customMacro foo, bar: ...' |
| 00:00:54 | filwit | i will publish my code once it's working, and then you can pull the shake things up yourself and see what works ;) |
| 00:01:05 | renesac | ok, I will post on the forum anyway |
| 00:02:35 | filwit | please do ;) it's good to get as much feedback as possible, but ultimately we need more concrete working code to go any further, and it's pointless to debate over every detail until it's more fleshed out really. |
| 00:03:35 | filwit | but i made the forum post specifically so y'all can find flaws with my proposal or come to better solutions, so i do appreciate the input. |
| 00:06:48 | renesac | filwit, do you already have working nimrod code highlighting on kate? |
| 00:06:58 | renesac | it is missing from this page: https://github.com/Araq/Nimrod/wiki/Editor-Support |
| 00:07:46 | filwit | renesac: yes, but it's got some of my custom game-engine keywords mixed into the syntax as keywords. Once sec i'll make a Gist for you |
| 00:08:40 | renesac | can you add directly to the wiki? |
| 00:08:58 | filwit | not until it's finished |
| 00:09:06 | filwit | but i probably should soon |
| 00:09:27 | filwit | i'm still playing around with some highlighting regex that i hope to move to Aporia as well. |
| 00:11:05 | Demos | I could use it as well. Right now I am just using the docgen's highlight module to highlight stuff in VS, I am thinking of using idetools to add some more info as well |
| 00:13:31 | * | io2 quit () |
| 00:13:41 | renesac | hum, D guys have implemented a code completion plugin for Kate |
| 00:14:37 | filwit | Kate nimrod.xml: https://gist.github.com/PhilipWitte/9379498 |
| 00:14:48 | filwit | Screenshot: http://reign-studios.net/philipwitte/screenshots/kate-nimrod.png |
| 00:14:49 | dom96 | Kelet: Yeah, what the others said: you need the latest Nimrod compiler from git usually (git master may work) |
| 00:15:17 | renesac | hum, kate don't have a listing for functions, types, etc declared in a file, aparently |
| 00:15:22 | filwit | renesac, Demos: place the 'nimrod.xml' in ~/.kde4/share/apps/katepart/syntax/ |
| 00:15:58 | renesac | (its a long time since I last used kate, as I'm not using kde destkop anymore) |
| 00:16:17 | Demos | what is with the ugly windows-7 wanna-be theme? |
| 00:16:48 | filwit | shut up Demos, it's beautiful |
| 00:16:53 | filwit | :P |
| 00:17:11 | Demos | I really like kate though. kile is my favorite latex editor |
| 00:17:33 | filwit | my KDE is like what Win 8 should have been.. |
| 00:18:02 | renesac | I'm using code::blocks for C now, and AFAIK no nimrod support there |
| 00:18:09 | filwit | really love KDE these days, and it keeps getting better without breaking everything, unlike Gnome which kills every useful extension off ever 6 months.. |
| 00:18:21 | dom96 | I've never liked KDE. |
| 00:18:45 | renesac | I liked kde... before the 4.0 where they've broken everything |
| 00:18:59 | renesac | and made it 5 times heavier |
| 00:19:01 | filwit | dom96: i used to hate it too, but after using 4.12 it's got every feature i liked about Gnome but is much more performant and feature rich |
| 00:19:33 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:19:38 | renesac | now I'm on lxde, that is a bit too immature and lacking features |
| 00:19:47 | renesac | but at least works well and don't get in the way |
| 00:20:07 | Demos | is KDE really heaver than GNOME these days, I suspect not |
| 00:20:13 | filwit | dom96: i always thought KDE themes looked ugly compared to Gnome ones, and in a ways Gnome still has some of the best ones. But I really like my current KDE desktop and don't think i would ever want to switch again. |
| 00:20:41 | filwit | renesac: you should try Mate |
| 00:21:05 | filwit | renesac: heard they're even migrating to Gtk3 and will support Wayland by the time that's actually ready |
| 00:21:13 | flaviu | All these window managers are huge, mine is only 800KiB ;) |
| 00:21:49 | filwit | Demos: KDE's heavy if you don't disable the file-index stuff. But after that it actually uses less ram than Gnome on my system and runs much smoother (granted i'm using Catalyst) |
| 00:22:18 | renesac | hum.. fork of gnome2... I was not the biggest fan of gnome |
| 00:22:51 | renesac | it is probably better than gnome3 |
| 00:22:52 | Demos | yeah the file-index stuff is pretty bad |
| 00:23:00 | filwit | flaviu: yeah but yours probably does practically nothing compared to the big ones. I would much rather 1 of my 8 gigs dedicated to the system and actually have usable features than save all that ram and gimp myself |
| 00:23:28 | renesac | too bad that Trinity/TDE came too late, and don't really have a sufficiently big team behind it |
| 00:23:34 | filwit | renesac: it's configurable. Check out Linux Mint Mate addition |
| 00:23:53 | filwit | edition** |
| 00:23:59 | filwit | addition.. come on brain.. |
| 00:24:07 | flaviu | filwit: I can definitely see your point of view, but I'm not sure what else I might want |
| 00:24:26 | Demos | I just avoid GObject and gtk |
| 00:25:01 | filwit | flaviu: yeah well if you're JUST comparing WMs it's not entirely realistic. Both Gnome and KDE come with a lot of tools which i use (granted they also come with tons i don't use) |
| 00:25:01 | flaviu | Honestly, I wouldn't go back to gnome, even though it looks quite nice and works great out of the box |
| 00:25:02 | renesac | filwit, one could boot in KDE 3.5.10 using only 22mb of ram |
| 00:25:33 | renesac | (extremely stripped down, along with the base linux enviroment, but a kde destkop nonetheless) |
| 00:26:17 | filwit | i really don't see the point of trying to run a DM on less RAM than any of todays smartphones |
| 00:26:33 | filwit | i can understand for old computers, but there are DE's for those already |
| 00:27:11 | * | flaviu quit (Remote host closed the connection) |
| 00:27:25 | * | flaviu joined #nimrod |
| 00:27:35 | renesac | well, a black box WM would use only 7mb less memory than kde, and wouldn't load kdelibs on the memory |
| 00:27:45 | filwit | don't get me wrong, you should always optimize. But i prefer a fully functioning desktop. If i want to FTP from my file-browser, I don't want to hunt some random FTP package down first, i just want it to work. |
| 00:27:55 | renesac | right |
| 00:28:29 | renesac | well, I'm only saying what could be done in the past, before the move to kde4 |
| 00:28:55 | renesac | kde3 had more functionality than kde4.x for a long time |
| 00:28:57 | renesac | :P |
| 00:29:24 | renesac | everybody wanted to rewrite things from scratch... |
| 00:29:34 | filwit | renesac, Demos: oh btw, that Kate syntax highlight will highlight things according to caps (also by function). And you'll want to strip out the <!-- hymn --> xml attributes cause i forgot to do that before i made the gist |
| 00:29:56 | renesac | you can make a new revision of the gist btw |
| 00:30:05 | filwit | yeah was just doing that.. |
| 00:30:12 | renesac | right |
| 00:31:05 | filwit | renesac, Demos: crap.. i need to export the colors for you folks as well.. |
| 00:32:33 | filwit | also, unfortunately right now multi-line type declarations aren't color correctly (bright blue) like they are if you put type names directly after the keyword. |
| 00:32:34 | Demos | I am not going to use it tonight, I am using VS right now |
| 00:33:06 | filwit | i can make it work like that, just haven't gotten around to doing it cause it requires reshifting stuff around |
| 00:33:10 | renesac | yeah, and I'm using aporia |
| 00:33:11 | filwit | Demos: okay |
| 00:33:18 | filwit | renesac: okay |
| 00:33:25 | renesac | though kate features might sway me away again |
| 00:33:35 | renesac | but no hurry |
| 00:35:48 | filwit | renesac: see the horizontal list and mini-map in my screenshot, plus the vertical lines for separation. Those are what sold me on Kate over Aporia (your project's great tho, dom96!). It would be great to eventually have an IDE with those feature and also intellisense. I know it's possible with Kate/KEdit and that's what I plan on eventually supporting (or building one into my game engine editor). |
| 00:36:40 | Demos | filwit, you could just embed kate as your editor |
| 00:36:42 | renesac | yeah, those indentation guides are very usefull |
| 00:37:00 | filwit | renesac: the horizontal source-tree though and mini-map are just really, really nice for working on large code files. If you double-click to highlight a word, you can see it in the mini-map, and the source-tree is awesome for navigating lots of files (like Visual Studios does) |
| 00:37:38 | renesac | oh, I moved away from kate before they added this feature |
| 00:37:58 | renesac | (mini-map) |
| 00:38:09 | filwit | Demos: that's a posibility, but I'm setting up to have my own GUI (it's the same "game object" system), so not sure i want a bunch of Qt stuff just for text. Will probably just promote using Kate until i have something better built-in |
| 00:38:29 | renesac | I would still like a list of function definitions as a tab together with the source-tree navigation |
| 00:38:51 | filwit | renesac: yeah that would be very nice. |
| 00:39:30 | renesac | but I see how the mini-map helps a bit with the things I would use the list of functions for |
| 00:39:44 | renesac | aporia has neither of course... |
| 00:40:02 | filwit | renesac, Demos: removed the 'hymn' stuff from the gist |
| 00:41:19 | filwit | renesac: the minimap makes finding a symbol's uses cases without actually source analysis actually possible (cause it shows the symbols though the whole file). In fact, because it's so much faster than VS's highlighter, it's actually *almost* nicer most of the time. |
| 00:44:25 | Skrylar | still just usin' vim here :> |
| 00:44:42 | flaviu | Wow, I can make Qt use my gtk theme by adding one line to my configs |
| 00:44:54 | renesac | kate has a vim mode IIRC |
| 00:45:05 | Skrylar | i use enough vim that 'vim modes' tend not to work well |
| 00:45:12 | renesac | right |
| 00:45:30 | Demos | yeah, although it is nice to not have to keep removing :w:q from my files :D |
| 00:45:46 | flaviu | Demos: :wq is one char shorter |
| 00:46:03 | Demos | holy shit, I did not know :wq was a thing |
| 00:47:25 | renesac | and Qt4 QTextEngine::format() still can't handle very long lines... |
| 00:47:26 | filwit | renesac, Demos: updated Gist with colors and install directions |
| 00:47:37 | renesac | apparently the bug was fixed only for Qt5.. |
| 00:48:01 | filwit | renesac, Demos: you have to enable the mini-map and documentation-nav yourselves though :P |
| 00:48:34 | renesac | long lines = a 1+ kbyte long line will probably leave your Kate unresponsive |
| 00:48:37 | renesac | :P |
| 00:50:00 | filwit | nope |
| 00:50:26 | filwit | Kate's been amazing on performance, even with huge one-line files (i've opened them, compressed JS mostly) |
| 00:51:00 | renesac | hum |
| 00:51:22 | flaviu | filwit: What colorset are you using in kate? |
| 00:51:26 | filwit | then again my machine is pretty fast.. |
| 00:51:39 | filwit | flaviu: my own, i put it in the Gist |
| 00:51:55 | filwit | flaviu: in case you missed it: https://gist.github.com/PhilipWitte/9379498 |
| 00:52:10 | renesac | well, the algorithm it used was quadratic on line size, so it didn't really mattered the speed of your computer |
| 00:52:11 | renesac | :P |
| 00:52:27 | flaviu | Thanks, I haven't gotten as far as looking at the gist. |
| 00:52:38 | renesac | so it is fixed now... |
| 00:54:05 | filwit | flaviu: well both the syntax highlighting and the color definitions (plus their install directions) are in the Gist if you try it |
| 00:54:16 | filwit | renesac: probably |
| 00:54:38 | filwit | renesac: i never really had a problem with it, but i've only been using KDE for 6-8months now. |
| 00:55:03 | filwit | possibly a full year, can't remember |
| 00:55:53 | renesac | https://bugs.kde.org/show_bug.cgi?id=225228 <-- have you tried to use line wrapping? |
| 00:56:20 | renesac | I think that it was it that triggered this unresponsive behaviour |
| 00:56:30 | OrionPK | time for my daily call with comcast |
| 00:56:35 | OrionPK | daily scrum |
| 00:56:39 | filwit | renesac: quote "Version: (using KDE 4.3.4)" |
| 00:56:42 | OrionPK | "how come this bill is wrong" |
| 00:56:46 | OrionPK | "how come I dnt have service" |
| 00:56:53 | OrionPK | "what happened to this channel?" |
| 00:56:58 | OrionPK | "why are you fucking retarded?" |
| 00:57:15 | filwit | OrionPK i would never pay for cable TV.. |
| 00:57:20 | renesac | the bug was basically closed as 'wont fix on Qt4' on 2013-11 |
| 00:57:58 | Varriount | OrionPK: "Because we can be" |
| 00:58:01 | filwit | OrionPK, didn't grow up with TV, so never really missed it. But I remember Comcast internet wasn't that bad. |
| 00:58:09 | renesac | though that 2012 patch may have made the situation better |
| 00:58:13 | OrionPK | i tried to cancel my tv |
| 00:58:22 | OrionPK | they offered me hbo for a reduced price, so I said yes |
| 00:58:30 | filwit | OrionPK: I'm on the East now though, no Comcast here (Brighhouse & Verizon instead) |
| 00:58:33 | OrionPK | then I moved house, and the hbo disappeared, and now im trying to get it back |
| 00:58:42 | filwit | lol |
| 00:59:31 | * | darkf joined #nimrod |
| 00:59:31 | OrionPK | my girlfriend wants to watch true detective |
| 00:59:37 | OrionPK | cannot deny her |
| 01:00:00 | renesac | OrionPK, look at the bright side, you at least have some basic service in your new home |
| 01:00:09 | filwit | meh, I just watch the shows i like online anyways to avoid commercials |
| 01:00:18 | OrionPK | aaaand they hung up on me |
| 01:00:22 | filwit | i would happily pay for such a service, but none exist |
| 01:00:34 | renesac | here when we moved they failed to install in the new adress for a full month |
| 01:00:36 | filwit | OrionPK: LOL |
| 01:00:36 | OrionPK | typical |
| 01:01:29 | renesac | till we canceled the service on the other address... |
| 01:01:38 | renesac | and signed a new contract |
| 01:01:39 | renesac | :P |
| 01:07:47 | Varriount | The only thing I have to complain about my internet provider (Verizon) is that they have a stupid backup battery system and tend to charge for inconsequential things. |
| 01:08:28 | Varriount | If the backup battery fails, even if we still have main power, our internet goes out. :/ |
| 01:10:58 | flaviu | Is the router yours? Try taking it apart and replace the battery with main power |
| 01:11:17 | Varriount | flaviu: Depends on what you call the router. |
| 01:11:33 | flaviu | The box with the battery |
| 01:11:40 | Varriount | No. |
| 01:11:53 | Varriount | flaviu: That's more of a signal translater than a router. |
| 01:12:08 | flaviu | They sometimes combine them |
| 01:12:12 | Varriount | It translates the fiber optic signals into something that can be sent through copper. |
| 01:12:50 | Varriount | then we have a router that connects to the copper wiring and send out wireless and such. |
| 01:13:58 | Varriount | When the battery fails, the cable that sends power to the signal translator is broken (it routes through the battery, not my design) |
| 01:14:46 | Varriount | flaviu: Thankfully, the battery only failed once, when the charging mechanism it sits in broke. |
| 01:15:04 | Varriount | That was.. about 4 months ago? Near thanksgiving |
| 01:15:33 | flaviu | I guess it isn't too bad then, if you have a replacement ready |
| 01:20:20 | Demos | does nimrod have variadic generics? |
| 01:31:36 | Varriount | variadic? |
| 01:31:46 | flaviu | like varargs, but for types |
| 01:32:05 | flaviu | ? |
| 01:32:10 | Varriount | You could use typedesc parameters |
| 01:32:35 | Varriount | proc foo(x: seq[typedesc]) |
| 01:32:42 | Demos | yeah that is the plan |
| 01:33:05 | Demos | but typedesc is a kinda a wierd thing, it is sometimes like a typeclass and sometimes like a type |
| 01:33:59 | Demos | like is typedesc[int] a concrete type? who knows! does the compiler know the size of all typedescs, probably but seq[typedesc] still feels like you may get a concrete version that is just seq[typedesc[T]] which is not what I want |
| 01:34:24 | Demos | have not tried yet though, since I need to do some housework |
| 01:36:16 | * | q66 quit (Quit: Leaving) |
| 01:39:51 | Varriount | Demos: I thought a typeclass *was* a type? |
| 01:40:00 | Demos | it is .... wierd |
| 01:40:41 | Demos | a typeclass is not a concrete type though, you do not know the size of a typeclass |
| 01:41:28 | Demos | they feel kinda like types but I am fairly sure that is sugar |
| 01:44:01 | * | Varriount quit (Ping timeout: 240 seconds) |
| 01:52:51 | renesac | they need better documentation |
| 01:53:26 | renesac | with examples of what you can and can't do with it |
| 01:54:01 | filwit | they're brand new |
| 01:54:15 | filwit | and probably still pretty buggy |
| 01:54:29 | filwit | haven't actually tried them at all yet though |
| 01:54:36 | EXetoC | *user-defined* type classes are |
| 01:54:46 | filwit | ^ |
| 01:55:03 | filwit | ^ |
| 01:55:05 | filwit | ^ |
| 01:55:07 | filwit | ^ |
| 01:55:16 | filwit | ^ |
| 01:55:18 | filwit | ^ |
| 01:55:19 | filwit | ^ |
| 01:55:23 | EXetoC | and as I've said before, the terminology is confusing |
| 01:55:31 | filwit | i agree |
| 01:55:40 | filwit | should be called 'traits' |
| 01:55:53 | filwit | or something like that |
| 01:56:11 | fowl | the most important aspect of a feature is always the name |
| 01:56:24 | filwit | then again, i think 'seq' should be called 'list' and (todays) 'list' should be called 'chain' and... that's about it actually |
| 01:57:18 | filwit | fowl: lol, points fired! But then, the name isn't entirely irrelevant either, and should be discussed |
| 01:57:49 | EXetoC | it's not, but don't we have both type classes and *user-defined* type classes? |
| 01:58:12 | EXetoC | both seem user-defined to me |
| 01:58:14 | * | carum joined #nimrod |
| 01:58:20 | filwit | advertising is about public perception, and in that implies the words we use to describe things *is* in fact important to popularity |
| 02:00:34 | * | filwit quit (Quit: Leaving) |
| 02:01:47 | * | filwit joined #nimrod |
| 02:03:12 | * | brson quit (Ping timeout: 264 seconds) |
| 02:04:48 | * | DAddYE quit (Remote host closed the connection) |
| 02:10:58 | * | brson joined #nimrod |
| 02:11:31 | Demos | for us advertising should be about making ourselves known |
| 02:13:27 | Skrylar | advertising is having neat screenies and going on about how easy it is to do awesome stuff |
| 02:13:30 | Skrylar | :> |
| 02:15:37 | * | brson quit (Ping timeout: 240 seconds) |
| 02:16:11 | * | carum quit (Remote host closed the connection) |
| 02:18:01 | * | carum joined #nimrod |
| 02:22:22 | * | carum quit (Ping timeout: 244 seconds) |
| 02:22:39 | * | brson joined #nimrod |
| 02:30:00 | * | Varriount joined #nimrod |
| 02:32:01 | * | brson quit (Ping timeout: 240 seconds) |
| 02:33:26 | * | carum joined #nimrod |
| 02:38:25 | * | Varriount quit (Ping timeout: 240 seconds) |
| 02:41:49 | Kelet | bah |
| 02:41:59 | filwit | humbug |
| 02:42:06 | Kelet | To use the latest Aporia I need a nightly build of nimrod |
| 02:42:23 | Kelet | Babel does not compile with the nightly build of nimrod and I need Babel to easily build Aporia |
| 02:42:24 | reactormonk | at least nimrod got better error messages than LaTeX. Well, it's not much, but there's that. |
| 02:43:40 | filwit | Kelet: Babel should build with devel, so you should report the bug |
| 02:44:52 | fowl | Kelet, what nightly build? |
| 02:45:52 | filwit | Kelet: in the meantime, use an alternative text-editor. There's a list on the website and I recently posted a stylesheet for Kate here (https://gist.github.com/PhilipWitte/9379498) if you're using Linux. It's also easy to setup a custom language in Notepad++ if you're on Windows. |
| 02:46:23 | Demos | yeah varargs[typedesc] does not work, maybe if all the types are the same but not if they are different |
| 02:47:11 | filwit | Demos: varargs[expr] should work though (unless it's buggy) and then you can throw compiler errors if they're not typedesc |
| 02:47:42 | filwit | Demos: varargs[typedesc] sounds like it *should* work, but I'm just guessing |
| 02:49:31 | Kelet | Anyone know of a serialization library for Nimrod like protobuf, msgpack, etc. and if not is anyone interested in creating one? (Efficient binary serialization, not JSON) |
| 02:49:50 | Demos | hm what I want to do is not totally compile time though. So I can not just use varargs expr. I must think about my problem more |
| 02:50:39 | filwit | Demos: i was under the impression varargs[] was a compile-time construct |
| 02:50:50 | filwit | like tuples |
| 02:51:29 | Kelet | Do most people use stable nimrod or is it like Rust where 90% of people are using nightlies or master? |
| 02:51:29 | Demos | I thought it converted stuff into an array, you can do varargs[expr] at compile time because those are all just AST nodes |
| 02:52:34 | filwit | Kalet: I would say most of us here use 'devel' (if that's what you're calling nightlies, which is probably is). But there's probably unspoken people out there that are sticking to master/0.9.2 as well |
| 02:53:24 | fowl | i am using master |
| 02:54:10 | filwit | Kalet: devel's VM is completely different from master/0.9.2's VM, so sometimes the compile-time stuff is buggy, though it seems many of the VM problems that existed a few weeks ago have been fixed and the new VM is not that unstable. |
| 02:54:45 | flaviu | filwit: Are the changes documented anywere but the commit log? |
| 02:55:30 | filwit | flaviu: it hasn't really changed in functionality. It's just much faster, and fixes some of the bugs with the old VM (so i'm told) |
| 03:12:10 | * | carum quit (Remote host closed the connection) |
| 03:12:46 | Demos | does the standard lib have a find proc that takes a comparison function? |
| 03:17:04 | * | DAddYE joined #nimrod |
| 03:42:14 | renesac | Kelet, the 0.9.4 release should happen soon |
| 03:42:52 | renesac | but yeah, the latest stable release is not really supported anymore... you should be on master or devel |
| 03:43:44 | renesac | we hope that this don't repeats in the next development cycle... |
| 03:43:54 | renesac | but nimrod isn't 1.0 yet |
| 03:45:05 | renesac | @all: how I'm supposed to use outputStream() from osproc? |
| 03:45:58 | renesac | I cannot see a way to get a PProcess w/o starting it at the same time |
| 04:17:37 | * | flaviu quit (Remote host closed the connection) |
| 04:22:22 | filwit | bbl |
| 04:22:24 | * | filwit quit (Quit: Leaving) |
| 04:25:03 | * | xenagi quit (Quit: Leaving) |
| 04:30:49 | * | r0b4 quit (Ping timeout: 240 seconds) |
| 04:38:07 | * | Varriount joined #nimrod |
| 04:42:55 | * | nande quit (Read error: Connection reset by peer) |
| 05:04:14 | * | brson joined #nimrod |
| 05:57:41 | * | DAddYE quit (Remote host closed the connection) |
| 05:58:14 | * | DAddYE joined #nimrod |
| 06:03:11 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 06:10:28 | * | DAddYE joined #nimrod |
| 06:27:51 | * | Demos_ joined #nimrod |
| 06:40:49 | * | ddl_smurf joined #nimrod |
| 06:41:52 | * | r0b4 joined #nimrod |
| 06:44:41 | * | domain joined #nimrod |
| 06:46:53 | domain | can opencl and cuda code be embedded into nimrod? |
| 06:48:19 | Demos_ | well you can use emit |
| 06:49:01 | Demos_ | araq has been pondering an {.gpu.} proc that would compile a nimrod function into openCL code |
| 06:55:14 | domain | thanks Demos_ I think Nimrod is the best overall programming language. Though I do like the way pascal shows pointers with the ^pointervar pointervar^ rather than the *pointervar c way. Not sure if that is in nimrod because I just discovered it yesterady. |
| 06:55:53 | Demos_ | yeah pointeres in nimrod are ptr Type or ref Type (for traced refs) |
| 06:56:16 | Demos_ | addr x does what it says on the tin |
| 07:01:42 | * | carum joined #nimrod |
| 07:05:55 | * | xtagon quit (Quit: Leaving) |
| 07:18:47 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 07:32:45 | Skrylar | dom96: i've rounded up references for making the (potentially GL) GUI |
| 07:33:42 | Skrylar | On the fence about whether to use CEGUI style "unified coordinates" or the delphi/osx style size anchors |
| 07:49:52 | * | Demos quit (Read error: Connection reset by peer) |
| 07:53:29 | * | cark quit (Ping timeout: 240 seconds) |
| 07:54:52 | * | carum quit (Read error: Connection reset by peer) |
| 07:55:10 | * | carum joined #nimrod |
| 07:57:56 | * | cark joined #nimrod |
| 08:01:59 | * | cark quit (Ping timeout: 240 seconds) |
| 08:03:01 | Araq | Skrylar: I vote for anchors, I love them :-) |
| 08:05:38 | Demos_ | hey Araq: how is proc foo(t: varargs[typedesc]) supposed to work? is there any way to define a variadic generic? |
| 08:06:02 | Demos_ | right now that gives you a bunch of typedesc[none]s |
| 08:06:35 | Demos_ | and proc foo(t: static[varargs[typedesc]]) gives you a type mismatch when called with more than one arg |
| 08:06:39 | * | cark joined #nimrod |
| 08:13:29 | Skrylar | Araq: I'm about 50/50. Having used the unified coordinates system, they're almost interchangeable. |
| 08:15:34 | Skrylar | i'll have to look over my notes again to see how anchors work; i know with the 'unified' setup if you want a flex layout where this object is 25% of the left side, you can easily do that by just sayinsg (0.25, 0) as a width, which means "(parent.width * 0.25) + 0" |
| 08:15:53 | * | DAddYE quit (Remote host closed the connection) |
| 08:16:05 | domain | is there any reason why there is an = sign after a proc? proc tempfunction() = why not just proc tempfunction() ? |
| 08:16:19 | * | DAddYE joined #nimrod |
| 08:16:30 | Skrylar | Araq: doesn't an anchor system have to do basically the same math but recalculating the relative points for each widget when it does the layout? |
| 08:21:06 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 08:29:18 | Skrylar | interesting. methods added by template (like in the manual's example) don't get picked up by the doc command |
| 08:30:14 | * | DAddYE joined #nimrod |
| 08:34:32 | Skrylar | alright i have an interface for hash algorithms now; not quite the same as the 'hashes' module |
| 08:34:42 | Skrylar | tomorrow i'll port over siphash |
| 08:34:58 | * | Demos_ quit (Ping timeout: 252 seconds) |
| 08:35:22 | * | filwit joined #nimrod |
| 08:36:00 | Skrylar | main difference is 'hashes' appears to use ints specifically, while some of these hashers use other types; so i used some generics so the same interface does CRC-32 as does siphash as would SHA etc |
| 08:36:06 | Skrylar | now i must nap |
| 08:43:40 | Araq | hi domain welcome |
| 08:44:05 | Araq | after the '=' the body follows, if there is no '=' it's a forward declaration |
| 08:45:09 | domain | Araq, thanks. I thought there was a reason! |
| 08:45:53 | Araq | but yes, even I sometimes forget the '='. We could make it optional... |
| 08:58:59 | domain | I think it's useful when there are lots of variables in a proc and they go onto the second line and the = sign makes it easy to spot that it's still part of a proc definition, and the whole proc defintion is one line, but I think generally in normal proc definitions with a newline it might not be needed? Making it optional in that case would be good if possible, because ending a line with an = sign just distracts my eyes a bit because |
| 08:58:59 | domain | it seems as if it's incomplete some how :) Maybe it takes some time getting used to I guess. But I guess that's also a unique programming style in Nimrod? |
| 09:06:34 | * | brson quit (Quit: leaving) |
| 09:14:51 | Skrylar | domain: it certainly has its own style |
| 09:15:05 | Skrylar | kind of a pascal-ish python |
| 09:19:25 | * | skyfex joined #nimrod |
| 09:23:56 | * | skyfex quit (Ping timeout: 265 seconds) |
| 09:24:13 | domain | one thing python made easy is typind def for function definition those chars are right next to each other on the keyboard. |
| 09:24:42 | Araq | ha, I never thought about this |
| 09:25:09 | Araq | I thought "wtf *def*ine function and define *class* " |
| 09:25:21 | Araq | "makes no sense" |
| 09:25:54 | Araq | but ofc it doesn't matter after a minute |
| 09:28:27 | domain | what basic made easy is writing a one line comment with ' |
| 09:28:39 | domain | no shift key involved there |
| 09:29:59 | Araq | on my keyboard ' requires a shift ... |
| 09:30:06 | Araq | but # does not |
| 09:30:57 | domain | I guess that's another issue depends where the keyboard is made and now that makes sense to me why python uses # |
| 09:33:02 | filwit | i think making '=' optional for procs is a step in the right direction, but ultimately it only solve a portion of the problems brought up in the rather lengthy discussion last night about syntax. |
| 09:35:20 | * | carum quit (Remote host closed the connection) |
| 09:38:01 | * | carum joined #nimrod |
| 09:43:16 | * | carum quit () |
| 09:53:17 | * | carum joined #nimrod |
| 09:53:25 | * | DAddYE quit (Remote host closed the connection) |
| 09:53:52 | * | DAddYE joined #nimrod |
| 09:58:44 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 10:08:59 | * | faassen joined #nimrod |
| 10:24:24 | * | DAddYE joined #nimrod |
| 10:28:51 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 10:42:15 | * | brihat left #nimrod (#nimrod) |
| 10:58:42 | * | carum quit (Remote host closed the connection) |
| 11:20:15 | * | skyfex joined #nimrod |
| 11:24:18 | * | skyfex quit (Ping timeout: 240 seconds) |
| 11:25:11 | * | DAddYE joined #nimrod |
| 11:30:05 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 11:30:26 | * | DAddYE joined #nimrod |
| 11:30:42 | domain | just an idea maybe typing res = var1 instead or result = var1 or ret var1 and return var1, because ret and res you can do very easily without looking at the keyboard very quickly since they are in close range. like def. |
| 11:33:28 | * | io2 joined #nimrod |
| 11:34:55 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 12:12:59 | * | BitPuffin joined #nimrod |
| 12:31:11 | * | DAddYE joined #nimrod |
| 12:35:29 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 12:39:42 | * | filwit quit (Remote host closed the connection) |
| 13:00:38 | * | darkf quit (Quit: Leaving) |
| 13:18:33 | domain | I'm thinking something like this |
| 13:18:34 | domain | def median(x): int |
| 13:18:36 | domain | If x == 0: |
| 13:18:36 | domain | res 10 |
| 13:18:36 | domain | elif x == 22: |
| 13:18:36 | domain | res calculating(x) |
| 13:18:55 | domain | short and simple is good I think in all things programming but still cleare enough to understand it |
| 13:21:08 | * | skyfex joined #nimrod |
| 13:23:02 | domain | honestly if you want to make nimrod more popular I think it's important to make it the compiled python type because pascal isn't so popular :) |
| 13:23:15 | domain | but that's only what I think |
| 13:25:15 | EXetoC | I don't know if that's a good example, since you can do this: "def median(x): int = if x == 0: 10 elif x == 22: calculating(x) else: 0" |
| 13:25:26 | * | Mordecai joined #nimrod |
| 13:25:29 | * | skyfex quit (Ping timeout: 240 seconds) |
| 13:25:38 | EXetoC | if res is indeed the implicit return variable, in which case omitting the = seems overkill |
| 13:25:46 | * | Mordecai is now known as Guest60770 |
| 13:26:16 | domain | it doesn't look good with the - |
| 13:26:33 | domain | = |
| 13:26:35 | * | psquid quit (Ping timeout: 264 seconds) |
| 13:26:38 | domain | it's a simple example |
| 13:27:12 | domain | def median(x): int |
| 13:27:13 | domain | If x == 0: |
| 13:27:13 | domain | res = 10 |
| 13:27:13 | domain | elif x == 22: |
| 13:27:13 | domain | res = calculating(x) |
| 13:27:16 | domain | too much = 's now |
| 13:28:10 | Araq | so use 'return' instead |
| 13:28:27 | EXetoC | you already have the statement-as-expression shortcut that I showed you |
| 13:28:46 | Araq | conflates control flow with setting the return value, but who cares when "popularity" is all that matters |
| 13:29:06 | domain | the more popular the more code |
| 13:29:16 | domain | that's why python is easy to use everyone has done things with it |
| 13:29:23 | domain | lots of libs |
| 13:29:25 | domain | easy to read |
| 13:29:30 | domain | that's why it's a winner |
| 13:30:21 | NimBot | Araq/Nimrod devel 9ba7ea0 EXetoC [+0 ±1 -0]: Add type-specific allocation procs. |
| 13:30:21 | NimBot | Araq/Nimrod devel 243babc EXetoC [+0 ±1 -0]: Add missing cast. |
| 13:30:21 | NimBot | Araq/Nimrod devel 2369c42 EXetoC [+1 ±0 -0]: Add allocation unit tests. |
| 13:30:21 | NimBot | Araq/Nimrod devel ffdf96a EXetoC [+31 ±130 -4]: Merge branch 'devel' into alloc-overloads |
| 13:30:21 | NimBot | 1 more commits. |
| 13:30:29 | domain | more coders = faster progress |
| 13:31:00 | EXetoC | well, I'll do my best to avoid languages like PHP and Java, no matter how popular they might be |
| 13:31:57 | domain | I don't like {} languages and ((()))) languages |
| 13:31:57 | domain | :) |
| 13:31:58 | * | DAddYE joined #nimrod |
| 13:32:10 | Araq | domain: self.self.self.self :P |
| 13:32:19 | EXetoC | see, it's not only about popularity :p |
| 13:32:42 | Araq | it's always easy to criticize a language's syntax |
| 13:34:04 | Araq | bbl |
| 13:34:12 | EXetoC | Araq: great. ok so what about that XML patch? do XML and HTML parsers deal with that differently? |
| 13:34:48 | EXetoC | I mean with regards to escaping vs not escaping at all in values (x="stuff") |
| 13:34:51 | EXetoC | alright |
| 13:36:44 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 14:04:46 | BitPuffin | ((())) languages <3 |
| 14:05:05 | BitPuffin | in nimrod we have () AND {} |
| 14:05:09 | BitPuffin | :D |
| 14:07:34 | * | Endy joined #nimrod |
| 14:08:20 | domain | a bit is ok but I'd hate to program in lisp all day long. |
| 14:09:20 | renesac | we found someone to argue with filwit \o/ |
| 14:09:59 | renesac | domain, he thinks that nimrod needs to be more like C/C#/Java to gain popularity |
| 14:10:21 | domain | nope just one change proc to def :) |
| 14:10:37 | domain | def, ret, res are all in the exact same region on the keyboard |
| 14:10:43 | domain | easy to access without looking at all. |
| 14:10:53 | renesac | if you use qwerty |
| 14:10:58 | domain | it's just speed and you don't want to loose ideas by being distracted. |
| 14:11:04 | domain | lose |
| 14:11:07 | renesac | ;) |
| 14:13:03 | renesac | but yeah, when I first encountered nimrod I also wondered "why proc?" (there is a FAQ entry about that), and I would prefer 'res' instead of 'result' for the implicit result variable |
| 14:13:10 | renesac | but in the end, those are really minor things |
| 14:14:31 | domain | sure but minor things add up. You have to type those often. You don't want to be typing twice the necessary amount of chars if you can avoid it. :) |
| 14:15:33 | domain | i think the most commonly used programming keywords should be shortest. |
| 14:15:52 | renesac | rust started out with 'ret' instead of 'return' |
| 14:16:07 | renesac | let's see if I find why they changed it |
| 14:17:20 | * | r0b4 quit (Ping timeout: 265 seconds) |
| 14:19:16 | renesac | https://github.com/mozilla/rust/issues/3063 |
| 14:19:25 | renesac | no better explanation in the changelogs either |
| 14:22:42 | domain | probably keep return but just change res because return is in c and python and people are brain washed by it |
| 14:22:45 | domain | :) |
| 14:25:16 | domain | also when people want to port python code to compiled nimrod hint hint!! they'll prefer the return then |
| 14:25:17 | domain | :P |
| 14:28:27 | renesac | yeah |
| 14:29:57 | renesac | one thing is that 'result' usually has no syntax highlighting, and it being longer helps in that regard |
| 14:32:24 | domain | i prefer result 10 to result = 10 though. i think the = is not important |
| 14:32:36 | EXetoC | surely that's an implementation issue |
| 14:32:48 | * | DAddYE joined #nimrod |
| 14:32:48 | BitPuffin | ret? res? |
| 14:32:52 | BitPuffin | oh |
| 14:32:54 | BitPuffin | return and result |
| 14:33:02 | EXetoC | var x = 3; x 5 |
| 14:33:06 | BitPuffin | domain: you are ignoring dvorak |
| 14:33:10 | renesac | domain, result is a normal variable |
| 14:33:16 | EXetoC | it's too ambiguous |
| 14:33:25 | renesac | ahem, almost normal |
| 14:33:32 | EXetoC | and why result of all things? it's just an implicitly declared variable |
| 14:33:58 | renesac | you want assigment to work normally |
| 14:34:10 | renesac | result += 1 |
| 14:34:13 | renesac | etc |
| 14:34:14 | domain | then = has to stay if it is a variable. |
| 14:34:20 | BitPuffin | domain: it wouldn't mean the same thing |
| 14:34:30 | BitPuffin | result = 3 != return 3 |
| 14:34:35 | renesac | domain, yes, that is the difference between it and return |
| 14:34:39 | BitPuffin | return exits out of the procedure |
| 14:34:44 | BitPuffin | wheras result keeps going |
| 14:34:49 | BitPuffin | whereas |
| 14:35:44 | * | r0b4 joined #nimrod |
| 14:36:19 | BitPuffin | is r0b4 new? |
| 14:37:03 | BitPuffin | if so: welcome! :D |
| 14:37:11 | renesac | so, asking again, how I'm supposed to use outputStream() from osproc? |
| 14:37:16 | renesac | I cannot see a way to get a PProcess w/o starting it at the same time |
| 14:37:23 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 14:38:36 | BitPuffin | dom96?!?!?!?!?! |
| 14:38:41 | BitPuffin | EXetoC!!?!?!?!? |
| 14:39:13 | EXetoC | domain: now read the sections about result and return and you should be able to understand what's going on |
| 14:39:40 | renesac | I think we need a better example in that section |
| 14:40:09 | BitPuffin | dom96, EXetoC: why do none of you own cs:go |
| 14:40:18 | renesac | when I read it I didn't understand the point of having an implicitly return variable |
| 14:40:33 | renesac | 'only to save one return keyword?" |
| 14:40:42 | renesac | but in the end, it helps way more than that |
| 14:42:59 | EXetoC | BitPuffin: I don't have Windows |
| 14:43:18 | BitPuffin | EXetoC: ah right |
| 14:43:22 | BitPuffin | doesn't run on linUx yet |
| 14:43:28 | BitPuffin | :/ |
| 14:44:36 | BitPuffin | it's being worked on though |
| 14:44:36 | EXetoC | renesac: enter searchable database of snippets |
| 14:44:46 | EXetoC | yeah, but who knows how long it'll take |
| 14:45:00 | renesac | EXetoC, where? |
| 14:45:15 | EXetoC | renesac: nowhere, yet |
| 14:46:31 | BitPuffin | EXetoC: well portal 2 runs on linux now |
| 14:46:40 | BitPuffin | at least |
| 14:47:55 | EXetoC | the "official" source engine game does as well as other games using that engine, so yeah |
| 14:48:17 | BitPuffin | yeah but you know |
| 14:48:33 | BitPuffin | they do custom low level stuff for each game |
| 15:07:37 | bstrie | renesac: rust changed `ret` to `return` because originally there was a policy of restricting keywords to five characters or fewer, but a lot of people in the community felt that that particular instance was a bridge too far |
| 15:08:59 | renesac | because other languages used 'return'? |
| 15:09:12 | renesac | or for other reasons too? |
| 15:10:22 | bstrie | renesac: despite the fact that rust has implicit returns, one way or the other it was going to have a return keyword if only to facilitate early returns (and for familiarity with C programmers who aren't accustomed to ruby-style implicit return values) |
| 15:11:24 | bstrie | but in early rust we got a lot of flak for what was perceived as excessively abbreviated keywords |
| 15:11:46 | bstrie | it was decided that `return` was sufficiently rare enough that it wasn't a big deal to violate the five-character keyword length guideline |
| 15:12:47 | bstrie | amusingly, complaints about excessively short keywords stopped after that change |
| 15:13:11 | bstrie | seems that nobody really cares to complain about the length of `fn` or `pub` or `priv` or `impl` |
| 15:13:27 | EXetoC | BitPuffin: dude, #nimrod-offtopic |
| 15:14:15 | EXetoC | bstrie: silly people :> |
| 15:22:00 | * | skyfex joined #nimrod |
| 15:23:06 | * | XAMPP joined #nimrod |
| 15:23:08 | * | XAMPP quit (Changing host) |
| 15:23:08 | * | XAMPP joined #nimrod |
| 15:25:14 | bstrie | EXetoC: well, while making changes to appease the silly people might violate your aesthetic principles, it saves you time and productivity in the long run by freeing you from dealing with spurious complaints :) |
| 15:26:04 | bstrie | for instance, I found a message on the python developer mailing list where guido admitted that if he were writing python today he'd have forgone whitespace in favor of braces, just because of how much of his time people have wasted by arguing about whitespace |
| 15:26:30 | * | skyfex quit (Ping timeout: 252 seconds) |
| 15:26:59 | BitPuffin | EXetoC: lol wtf |
| 15:27:08 | BitPuffin | we don't seriously have that do we? |
| 15:27:36 | EXetoC | bstrie: right |
| 15:27:39 | EXetoC | BitPuffin: yeah why not? |
| 15:29:11 | bstrie | to use another example, think of how much net time would have been saved by the Go devs had they just bit the bullet and added in generics at the beginning |
| 15:29:56 | bstrie | the cost of implementation has surely been dwarfed by the inevitable raging generics flamewars that pop up in very nearly every single Go thread |
| 15:31:03 | bstrie | which isn't to say that *every* feature that someone demands must be shoehorned into your language (hello, C++), but you do need to listen to the complaints of your audience |
| 15:33:25 | * | DAddYE joined #nimrod |
| 15:36:21 | * | Guest60770 quit (Quit: work) |
| 15:38:03 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 15:56:38 | * | [1]Endy joined #nimrod |
| 15:59:44 | * | Endy quit (Ping timeout: 244 seconds) |
| 15:59:45 | * | [1]Endy is now known as Endy |
| 16:19:01 | * | filwit joined #nimrod |
| 16:19:29 | filwit | read logs, couldn't agree more with what bstrie said |
| 16:20:29 | filwit | really though 'fn' is too short for a keyword of that magnitude! but that's different conversation ;P |
| 16:22:56 | filwit | it seems every time i've brought up "argument from popularity" i get response about successful "obscure language X" is and how bizarre it is. I'm surprised you haven't gotten the same, bstrie ;) but perhaps it's too early in the day. lol |
| 16:24:50 | filwit | either way, Nimrod has a rather sane "proof it yourself first" approach to these things, by allowing others to build their own parsers, which does make a lot of sense in terms of grammar evolution |
| 16:29:24 | filwit | it's also interesting to read other's argue over 'return' as I was just arguing with my brother (diehard C# guy) about that very thing, and somewhat had to concede that because 'return' was required sometimes, it makes sense to require it all of the time for consistency and popularity. |
| 16:31:33 | filwit | sometimes I think those who understand the full-spectrum of language idioms forgot how far they've come, and what it was like to only understand a few of the rules, and how that can effect your own attraction to similar, consistent designs where the rules are learned once and applied everywhere. |
| 16:31:56 | bstrie | filwit: the reason that we originally chose to have both explicit and implicit returns in rust was because we wanted there to be contexts where a `return` keyword would signal a nonlocal return, but the implicit return would signal a local return |
| 16:32:33 | bstrie | we've since done away with that notion, but you can't deny that it makes lambdas a lot nicer: `|x| x+2` rather than requiring `|x| { return x+2; }` |
| 16:33:20 | filwit | i can actually. i would much prefer the more verbose (is typing that so difficult) approach with the less confusing rules ;) |
| 16:34:01 | filwit | but then, i don't see much problem with implicit return in general, it really is one of the easier rules to learn |
| 16:34:11 | * | DAddYE joined #nimrod |
| 16:34:46 | filwit | it's just, these things can stack up, and if you let them you can't also wonder why "simpler language X" is getting all the new users. |
| 16:36:04 | filwit | bstrie: are you new to #nimrod? I find your voice very rational, and hope you stick around ;) |
| 16:37:01 | dom96 | hello everyone |
| 16:37:08 | filwit | hi dom96 |
| 16:37:12 | dom96 | domain: Welcome to #nimrod :) |
| 16:38:51 | bstrie | filwit: I'm a rust guy, I lurk in lots of programming language channels on freenode waiting for people to talk about rust :P |
| 16:38:57 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 16:40:20 | bstrie | but if I can help other languages learn from our mistakes, all the better |
| 16:40:23 | filwit | dom96: sorry i haven't responded to your forum post yet. Araq did a good job of convincing me that the only way to consider a new grammar would be to implement one first, and then argue over the details. I hope you don't mind terribly if I leave you hanging for a bit, and eventually respond with working code we can pick through. I do appreciate your input. |
| 16:44:02 | dom96 | filwit: No worries. I profoundly agree with Araq. |
| 16:44:36 | filwit | dom96: as do i actually, about the approach at least. |
| 16:56:58 | renesac | bstrie, you remembered me of one more thing, allowing brackets in nimrod would bring the endless discussions about brackets positioning here |
| 16:57:11 | renesac | AND of indentation styles |
| 16:57:12 | renesac | http://en.wikipedia.org/wiki/Indent_style |
| 16:58:57 | filwit | renesac: that has a very simply and easy solution. For example, if ':' starts a indent-sensitive block (vs {} which encapsulates indent insensitive block), then you always consider the whitespace of the line in which the ':' is found on.. eg.. |
| 16:59:01 | renesac | and the 'from __future__ import braces' is the current python answer for inserting brackets in the langauge |
| 16:59:02 | filwit | proc foo: |
| 16:59:04 | filwit | bar |
| 16:59:07 | filwit | proc foo |
| 16:59:08 | filwit | : |
| 16:59:09 | filwit | bar |
| 16:59:28 | renesac | filwit, ? |
| 16:59:44 | filwit | renesac: er.. maybe i misunderstood your post |
| 17:00:39 | bstrie | hey, I'm not arguing for braces in nimrod, I'm just saying that guido doesn't actually care one way or the other about significant whitespace :P |
| 17:01:12 | renesac | well, actually he cares |
| 17:01:20 | renesac | he was just exausted from the endless discussions |
| 17:02:04 | renesac | and I wonder who wrote 'from __future__ import braces' |
| 17:02:31 | bstrie | nah, he doesn't care. he chose significant whitespace in the first place because python was based on the ABC language, and ABC had significant whitespace |
| 17:03:41 | renesac | *significant indentation |
| 17:05:50 | * | brihat joined #nimrod |
| 17:10:44 | renesac | "ABC: The Good Stuff" [...] "Indentation for grouping (Knuth, occam)" |
| 17:11:06 | renesac | it was one of the things he most liked about ABC |
| 17:13:33 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 17:22:50 | * | skyfex joined #nimrod |
| 17:27:32 | * | skyfex quit (Ping timeout: 252 seconds) |
| 17:28:44 | * | domain quit (Ping timeout: 265 seconds) |
| 17:33:54 | * | carum joined #nimrod |
| 17:37:13 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 17:41:50 | * | skyfex joined #nimrod |
| 17:44:56 | * | brson joined #nimrod |
| 17:51:44 | * | shodan45 joined #nimrod |
| 17:52:50 | * | r0b4 quit (Ping timeout: 252 seconds) |
| 17:54:20 | * | DAddYE joined #nimrod |
| 17:56:14 | * | jbe joined #nimrod |
| 17:56:23 | Araq | bstrie: I like rust's abbrevs, I like abbrevs in general. english is simply too verbose with all its latin words |
| 17:56:40 | jbe | is it possible to have a seq in shared memory? |
| 17:57:09 | Araq | jbe: not really |
| 17:57:53 | jbe | hmm ok then |
| 17:58:19 | * | q66 joined #nimrod |
| 18:05:24 | OrionPK | distnct |
| 18:07:04 | bstrie | Araq: I would think that non-native speakers would actually be *against* abbreviations, since an abbreviation that might be trivial for a native speaker to decipher might be totally opaque to a non-native speaker |
| 18:10:26 | Araq | bbl |
| 18:15:36 | * | Matthias247 joined #nimrod |
| 18:17:05 | shodan45 | so, anyone working on a "nimrod OS" yet? :) |
| 18:17:27 | shodan45 | or even just a replacement for gnutls? ;) |
| 18:31:00 | * | Endy quit (Ping timeout: 241 seconds) |
| 18:37:49 | * | nande joined #nimrod |
| 18:37:59 | * | r0b4 joined #nimrod |
| 18:42:35 | reactormonk | Varriount, only the first letter is case-sensitive |
| 18:43:30 | filwit | shodan45: new benchmark for c2nim: convert Linux to Nimrod ;P |
| 18:46:14 | shodan45 | filwit: o_O |
| 18:49:09 | * | carum quit (Remote host closed the connection) |
| 18:50:59 | reactormonk | filwit, will probably crash on the first header file ;> |
| 18:51:04 | reactormonk | filwit, I'd settle for the glibc |
| 18:51:17 | reactormonk | or dietlibc, if you are so inclined |
| 18:53:25 | filwit | bbl |
| 18:55:06 | Araq | reactormonk: did you pull the new alloc stuff? |
| 18:57:09 | Araq | bstrie: IMHO if you're against abbrevs you have no idea how natural language works |
| 18:59:50 | reactormonk | Araq, huh? nope. |
| 19:00:07 | bstrie | Araq: I can see merits to both sides, but I take issue with the idea that programming languages are analogous to natural languages :P |
| 19:00:11 | reactormonk | Araq, https://github.com/Araq/Nimrod/pull/977 |
| 19:01:34 | skyfex | Hmm, Nimrod works alright on the Raspberry PI :) |
| 19:01:49 | skyfex | Compilation time is loooong though.. |
| 19:01:49 | * | carum joined #nimrod |
| 19:02:07 | skyfex | but that's mostly the c compilation |
| 19:02:09 | Araq | bstrie: I used to think the same but recent research results show that brain activity during programming is not like brain activity dealing with maths |
| 19:02:32 | bstrie | Araq: I ESPECIALLY take issue with the idea that programming is analogous to math :) |
| 19:02:33 | * | carum quit (Read error: Connection reset by peer) |
| 19:02:45 | Araq | instead the regions responsible for language are active |
| 19:02:47 | * | carum joined #nimrod |
| 19:02:59 | reactormonk | bstrie, to a certain degree, depending on your approach |
| 19:03:33 | OrionPK | skyfex try a cubox |
| 19:03:39 | OrionPK | compilation time is much faster |
| 19:03:50 | reactormonk | I'd like to see if there's any differences between FP/stateful |
| 19:03:51 | OrionPK | I've got nimrod on a RBPI and a cubox |
| 19:04:20 | skyfex | OrionPK: Thanks for the tip, don't think I'll buy something new for this project though.. th RBPi is fine for my purpose |
| 19:04:57 | skyfex | Besides.. doesn't look like it has GPIO? |
| 19:05:10 | Araq | reallocType? seriously? |
| 19:05:27 | Araq | it doesn't realloc a *type* ... |
| 19:05:41 | EXetoC | I didn't merge :p |
| 19:05:52 | Araq | EXetoC: you should have deprecated 'realloc' instead |
| 19:06:08 | Araq | and introduce 'rawRealloc' or something |
| 19:06:12 | skyfex | OrionPK: eSata is nice though.. really wish RPi had SATA.. or a built in Flash chip.. I/O performance is what's really holding it back |
| 19:06:21 | Araq | and then we an remove it and add the proper realloc |
| 19:06:28 | OrionPK | yeah |
| 19:06:36 | OrionPK | cubox has bluetooth and wifi as well |
| 19:06:50 | Matthias247 | skyfex: you could use a cubieboard. Or the more widespread beaglebone |
| 19:06:59 | OrionPK | skyfex basically i just need to give it power and it's on my network hosting websites :) |
| 19:07:20 | Araq | skyfex: are you up for another challenge? |
| 19:07:34 | skyfex | Araq: Hmmm, might have time this weekend, but no promises :P |
| 19:07:37 | Araq | lambda lifting has long standing and annoying issues |
| 19:07:46 | renesac | Araq, maybe you can answer: |
| 19:07:47 | renesac | [11:37:11] <renesac> so, asking again, how I'm supposed to use outputStream() from osproc? |
| 19:07:47 | renesac | [11:37:16] <renesac> I cannot see a way to get a PProcess w/o starting it at the same time |
| 19:08:05 | reactormonk | renesac, I suppose it buffers |
| 19:08:05 | Araq | renesac: call it after starting it? |
| 19:08:08 | skyfex | Araq: Can you point to some specific issues on Github? |
| 19:08:20 | renesac | Araq, but then I will miss the start of the output? |
| 19:08:26 | reactormonk | renesac, nope. |
| 19:08:44 | renesac | strange |
| 19:08:54 | reactormonk | renesac, why. the OS buffers that for you until you call it IIRC |
| 19:09:00 | reactormonk | just don't overdo it |
| 19:09:05 | skyfex | Matthias247: More good tips, but I'm kind of stuck with RPi now ;) Cubieboard looks like it could be good for future projects |
| 19:09:48 | EXetoC | Araq: deprecated realloc? so what name should be used then? |
| 19:09:55 | renesac | and is input automatically sanitized? |
| 19:09:58 | Matthias247 | skyfex: I also wanted to get one for quite some time, because my RPI is so unreliable. But forget about ordering it all the time :) |
| 19:10:05 | Araq | rawRealloc for the 'pointer' version, EXetoC |
| 19:10:16 | Araq | actually no ... |
| 19:10:57 | renesac | on osproc startProcess for example? |
| 19:10:59 | nequitans | Hi all! I noticed if I pass a global variable into a function and spawn threads off into that function, the values in the variable seem to be copied onto the threadsafe heap (but it is not if use the variable outside of the function). Is there a way around this? |
| 19:11:05 | EXetoC | rewrite realloc and you'll silently over-allocate |
| 19:11:08 | nequitans | *in that function |
| 19:11:13 | Matthias247 | skyfex: but I think for good linux driver support TI and Freescale are currently the best |
| 19:11:18 | EXetoC | Araq: reallocObj or something? |
| 19:11:20 | Araq | you can call the typesafe proc growMem or something |
| 19:11:27 | EXetoC | ok |
| 19:11:34 | Araq | nah that's bad too |
| 19:11:43 | renesac | I preffer rawRealloc() |
| 19:11:44 | Araq | copyMem uses pointers |
| 19:11:58 | renesac | why change completly the name if it does the same thing? |
| 19:12:03 | dom96 | nequitans: Can you make the corrections Araq asked for on your article about Nimrod? It would be great if we could reddit it. |
| 19:12:32 | nequitans | Hi dom96, I Araq had some suggestions? I must have missed them on the IRC logs |
| 19:12:57 | EXetoC | renesac: almost the same thing |
| 19:13:56 | EXetoC | and the implicit ptr -> pointer conversion will result in a sneaky over-allocation for some people, although I don't think it's the end of the world |
| 19:13:58 | renesac | the non-raw only adds a cast |
| 19:14:31 | nequitans | (searching through logs) |
| 19:14:32 | EXetoC | renesac: and then there's T.sizeof * size rather than just size |
| 19:14:37 | dom96 | nequitans: "Araq | nequitans: you should mention that the multithreading you're using is low level and soon there will available be a much better one" |
| 19:14:44 | renesac | hum, right |
| 19:14:52 | dom96 | I think that's it. Araq, is there anything else? |
| 19:15:08 | renesac | anyway, I think it is confusing to put an non-related name |
| 19:15:15 | Araq | nequitans: remove the T/P prefixes in your examples, we'll only get flames for it |
| 19:15:31 | Araq | renesac: very well, so it's rawRealloc and realloc |
| 19:15:57 | * | nequitans quit (Remote host closed the connection) |
| 19:17:09 | * | BitPuffin joined #nimrod |
| 19:17:18 | * | nequitans joined #nimrod |
| 19:17:30 | nequitans | ack : my IRC client just crashed. sorry |
| 19:17:45 | Araq | nequitans: you need to ensure you don't share Gc'ed memory via globals |
| 19:17:50 | nequitans | Last thing I saw was the T and P removal |
| 19:18:16 | EXetoC | Araq: that doesn't prevent any sneaky over-allocations, so why not just overload then? and maybe we can remove the implicit ptr/pointer relationship eventually |
| 19:18:33 | EXetoC | either way, it's not a common operation, right? |
| 19:18:47 | dom96 | nequitans: http://build.nimrod-lang.org/irclogs/ |
| 19:19:10 | Araq | EXetoC: I can't follow sorry |
| 19:20:30 | EXetoC | Araq: sneaky as in existing instances of alloc(ptr) invocations might or might not over-allocate |
| 19:21:12 | EXetoC | I'm focusing too much on overloading. it's not terribly important |
| 19:21:49 | Araq | renaming low level stuff is dangerous though. maybe use create/grow/free instead? |
| 19:24:07 | nequitans | Araq, I see. Basically what I have is a large ensemble of seqs that I want to read from in parallel, since heaps are GCed, i suspect that is my problem. Is the best way around this to not use seqs but to use my own 'non-gced' seq? |
| 19:25:03 | reactormonk | nequitans, maybe allocate your own space? |
| 19:25:17 | Araq | that's the obvious solution but usually you can do it completely differently, nequitans |
| 19:25:49 | reactormonk | Araq, couldn't you just GC_unref stuff? |
| 19:26:12 | Araq | reactormonk: that's racy |
| 19:26:21 | reactormonk | muh |
| 19:26:28 | reactormonk | even in the same proc? |
| 19:26:41 | Araq | no |
| 19:27:18 | reactormonk | is there a shared pragma for stuff that's accessed by multiple threads? |
| 19:27:28 | reactormonk | ... also, non-var. |
| 19:27:35 | Araq | there is a 'shared' keyword for that |
| 19:27:48 | reactormonk | will the GC respect that? |
| 19:27:55 | Araq | but currently it does not do anything |
| 19:28:01 | reactormonk | :-/ |
| 19:28:37 | Araq | hey, 0.9.6 will get good threading support, the design exists |
| 19:29:04 | renesac | create/grow/free for the new 'non-raw' allocs? |
| 19:29:12 | Araq | renesac: yes |
| 19:29:38 | reactormonk | Araq, wanna announce the removal of the c-source in the forum? |
| 19:29:39 | renesac | instead of grow, maybe resize... |
| 19:29:44 | renesac | as you are not aways growing |
| 19:29:55 | renesac | unless if it will not shrink by default |
| 19:29:59 | nequitans | Re: doing it differently are you suggesting maybe not using a shared memory approach somehow? |
| 19:29:59 | EXetoC | I thought only realloc was the issue |
| 19:31:00 | Araq | nequitans: yes. for instance usually each thread can gets its own data set directly from some IO operation |
| 19:31:01 | EXetoC | disregard that. I'll deal with this in a couple of hours |
| 19:35:16 | nequitans | Araq, ic. e.g. mmap? |
| 19:36:01 | * | olahol joined #nimrod |
| 19:36:55 | Araq | nequitans: for instance |
| 19:37:10 | * | Demos joined #nimrod |
| 19:37:27 | nequitans | Re: the blog post. Thanks for the suggestions (to everyone). I'll make them and add Araq's removal of P-T suggestion and the comment about the threading |
| 19:37:46 | Araq | nequitans: oh one more thing |
| 19:37:49 | Araq | instead of |
| 19:38:04 | Araq | proc foo[T](m: Matrix[T]) you can do |
| 19:38:17 | Araq | proc foo(m: Matrix) |
| 19:38:28 | Araq | that's an implicit generic then |
| 19:38:55 | nequitans | Araq, interesting |
| 19:39:04 | nequitans | I can mention that in the post |
| 19:39:16 | Araq | nah, make use of it |
| 19:39:18 | EXetoC | Araq: so alloc(x) and alloc(T, x) would be too confusing? |
| 19:39:28 | Araq | the examples need to be as shiny as possible |
| 19:40:12 | Araq | otherwise you'll get comments like "waa waa waa, it uses * for export, I'll never use this language" |
| 19:40:32 | * | carum quit (Remote host closed the connection) |
| 19:40:42 | * | skyfex quit (Remote host closed the connection) |
| 19:40:51 | * | carum joined #nimrod |
| 19:41:39 | nequitans | Yea, and I'm completely open to better examples: initially, the motivation for the post was why to use nimrod over other options. in particular i like the design decisions to reduce the complexity of keeping the lang in the head (which I think Nimrod excels at). i therefore didn't focus too much on examples :) |
| 19:41:59 | Demos | I like that we have both result= and return, useful in different situations. |
| 19:42:30 | * | skyfex joined #nimrod |
| 19:42:33 | Demos | anyway.... variadic generics |
| 19:42:36 | nequitans | Araq, yea, I notice that when it comes to languages, arguments often rely on random syntax gripes, and that would be good to avoid in the post |
| 19:45:52 | skyfex | Ugh.. why are so many hardware developers so stingy with their source code and documentation? Now I have to reverse engineer the USB protocol of this RFID card reader :( |
| 19:48:06 | filwit | market advantage |
| 19:48:12 | filwit | profit |
| 19:48:13 | filwit | money |
| 19:48:17 | filwit | root of all evil |
| 19:48:24 | filwit | (jk.. mostly) |
| 19:50:14 | * | skyfex quit (Remote host closed the connection) |
| 19:50:57 | Araq | nequitans: I use multiple processes and a database for these things fwiw |
| 19:51:03 | filwit | nequitans: you're writing a blog article about nimrod? Did i miss the link or is it not done yet? |
| 19:51:50 | * | skyfex joined #nimrod |
| 19:54:16 | Araq | Demos: not sure why somebody needs varargs[typeDesc] |
| 19:55:05 | Demos | you want a generic that uses an arbitrary number of types |
| 19:55:29 | Araq | perfect forwarding? |
| 19:56:17 | * | skyfex quit (Remote host closed the connection) |
| 19:56:17 | Demos | varargs[typedesc] is problematic since you don't really want to be looping through them, in fact you can not loop through. And no not quite. My use case is searching through several global containers each associated with a type |
| 19:56:39 | Demos | I may be able to do it with a template though |
| 19:56:58 | Araq | just pass a tuple instead? |
| 19:57:14 | Demos | a tuple of typedescs? |
| 19:57:15 | nequitans | filwit, here it is: http://geetduggal.wordpress.com/2014/03/03/consider-nimrod/. it's currently a 'living' document so i'm open to suggestions, and esp if i have some wrong statement/inaccuracy anywhere |
| 19:57:57 | * | skyfex joined #nimrod |
| 19:58:26 | * | Mat3 joined #nimrod |
| 19:58:34 | Mat3 | hi all |
| 19:58:42 | filwit | nequitans: thanks. Love how the title read "Consider the Nimrod.... Programming Language" lol |
| 19:58:53 | nequitans | i also would rather use github gists to show nimrod code, so i have syntax highlighting, but i haven't figured out how to embed the <script> in wordpress.com |
| 19:59:16 | filwit | dunno, never used wordpress |
| 19:59:23 | nequitans | lol, i never saw that before |
| 19:59:25 | Araq | nequitans: use ipsum genera |
| 19:59:54 | * | makcode joined #nimrod |
| 20:00:11 | filwit | nequitans: also, not that i dislike it (cause i think it looks pretty good in white), but why change the logo colors? |
| 20:01:32 | Araq | hi makcode welcome |
| 20:01:36 | filwit | nequitans: and if you want a logo on white I can make you a better image. |
| 20:02:11 | nequitans | ipsum genera looks so clean! filwit, no preference on the logo color, but if you have a high quality logo, do send and i'll replace |
| 20:02:33 | Demos | wowah module names are case sensitive on linux, that is annoying |
| 20:02:58 | Araq | Demos: not quite, they are normalized to all lower on linux |
| 20:03:19 | Araq | though maybe that is buggy |
| 20:03:23 | Demos | so if I have all lower names on import my files can be names however? |
| 20:03:25 | * | makcode is now known as 92AAAEQGN |
| 20:03:40 | Araq | no the other way round |
| 20:03:45 | filwit | nequitans: just wondering why you choose to make it white as all. I've never seen anyone use the crown on white, but if it's needed/wanted i can render a clean version of it real quick. |
| 20:03:48 | Demos | oh |
| 20:03:51 | Araq | you can import strUtils and it imports strutils.nim |
| 20:03:56 | filwit | is** all |
| 20:04:50 | nequitans | filwit, i think i just got it from a google image search and it was of nimrod-lang.org |
| 20:05:07 | filwit | interesting.. |
| 20:05:25 | Araq | skyfex: https://github.com/Araq/Nimrod/issues/581 the tests are in closure/ and also in iter/ as first class iterators have closures too |
| 20:05:55 | nequitans | (so i'm def open to logo mods) |
| 20:07:04 | NimBot | Araq/Nimrod devel e47887a Michał Zieliński [+0 ±1 -0]: zmq: remove unnecessary 'var' decls from high-level procs |
| 20:07:04 | NimBot | Araq/Nimrod devel e8a2e1e Andreas Rumpf [+0 ±1 -0]: Merge pull request #975 from zielmicha/zmq-fix... 2 more lines |
| 20:07:06 | filwit | it's bazaar how someone's inverted copy of the logo is the first image on google search, lol |
| 20:08:49 | * | carum quit (Remote host closed the connection) |
| 20:09:59 | * | carum joined #nimrod |
| 20:10:29 | reactormonk | Araq, Got a few days of free time, which issue should I resolve, one of those? https://github.com/Araq/Nimrod/issues/assigned/reactormonk?state=open |
| 20:10:41 | dom96 | I love how there is a pic of me and Araq when searching 'nimrod-lang' on google images |
| 20:11:08 | reactormonk | dom96, there's araq's github image |
| 20:11:17 | EXetoC | success |
| 20:11:28 | filwit | this looks promising: http://www.google.com/trends/explore#q=nimrod%20language |
| 20:11:33 | Demos | it would be a good idea to make some high quality logos avalible in different formats, I was searching for one when testing my libpng wrapper, I ended up just using some owl from the png site |
| 20:12:48 | * | carum quit (Remote host closed the connection) |
| 20:12:49 | nequitans | i think a t-shirt and mug with just the crown on it would be cool too |
| 20:12:50 | reactormonk | filwit, but not enough interest for global search pattern :-/ |
| 20:13:03 | Araq | reactormonk: well no. Let me see what you can do instead. |
| 20:13:16 | Araq | there are much more pressing and interesting things to do |
| 20:13:17 | reactormonk | Araq, https://github.com/Araq/Nimrod/issues/347 ? |
| 20:13:30 | reactormonk | might be a bit too big |
| 20:13:44 | dom96 | http://www.google.com/trends/explore#q=nimrod%20language%2C%20rust%20language&cmpt=q |
| 20:14:05 | reactormonk | dom96, mozilla helps. |
| 20:15:09 | Araq | reactormonk: if you want to work on JS related stuff make it work with emscripten |
| 20:15:27 | reactormonk | emscripten? |
| 20:15:43 | Araq | or whatever it's called |
| 20:16:07 | reactormonk | Araq, so nimrod -> C -> LLVM -> JS? |
| 20:18:42 | Araq | yeah, seems to be better than our current way with nimrod -> JS |
| 20:19:03 | reactormonk | Araq, let's see, I'll compare some not-so-complex and some complex code |
| 20:19:30 | reactormonk | Araq, the advantage with nimrod -> JS is that you actually get some somewhat debuggable JS, while I doubt that for the long way |
| 20:20:35 | Araq | reactormonk: emscripten is hype compatible though. Script kiddies love it. |
| 20:20:42 | filwit | bbl |
| 20:20:48 | Mat3 | oh no |
| 20:20:59 | Matthias247 | asm.js is a thing nobody needs ;) |
| 20:21:10 | Araq | having a shitty debugging experience is part of any script kiddie technology |
| 20:21:27 | Araq | extra points for slow compile times |
| 20:21:33 | Araq | and random explosions |
| 20:21:47 | reactormonk | Araq, can you give me some pointers for how to add my own nimrod command? aka nimrod ems |
| 20:21:48 | Demos | yeah asm.js is pretty fucked. Actually having browsers just run LLVM code could be good |
| 20:22:19 | Demos | sorta like how WP8 does the last stage of compilation as part of app installation |
| 20:22:30 | Matthias247 | google is pushing pnacl instead. You could probably aslo use nimrod with that |
| 20:24:46 | Demos | it does not look like anyone but google is using pnacl though |
| 20:25:03 | Matthias247 | yep |
| 20:25:17 | Matthias247 | and noone but mozilla is pushing asm.js ;) |
| 20:25:28 | Demos | anyway I hate the internet and think that people should just write apps that run on real computers |
| 20:25:47 | Demos | so you should probably ignore much of what I think about the "web" |
| 20:25:48 | reactormonk | Demos, installing stuff is kind of a big barrier |
| 20:26:06 | Demos | seriously? |
| 20:26:15 | reactormonk | if you don't have a package manager |
| 20:26:33 | Demos | make the apps self-contained |
| 20:26:36 | Araq | installing stuff on windows works much better than on linux, reactormonk |
| 20:26:38 | Demos | unzip and go |
| 20:27:08 | Demos | Araq: uninstalling stuff you mean |
| 20:27:18 | Araq | no installing. |
| 20:27:38 | * | 92AAAEQGN quit (Ping timeout: 240 seconds) |
| 20:27:38 | Araq | go to the website if it has a windows version, it's some nice installer that simply works |
| 20:27:50 | Araq | in like 99% of all cases |
| 20:28:14 | Araq | linux? yeah right, install from source, find deps, recurse |
| 20:28:27 | Araq | or use an outdated version via your package manager |
| 20:28:39 | Araq | if it is in the repository, that is |
| 20:28:43 | Mat3 | Araq: I think the U*ix flavour is prefering compilation from sources |
| 20:28:54 | Demos | compilation from sources is dumb |
| 20:29:03 | reactormonk | Araq, aur ftw. |
| 20:29:30 | Araq | the U*ix flavour doesn't work. There is a reason commercial software has a very hard time on Unix. |
| 20:29:37 | Demos | it is just asking for support issues when some idiot compiles with -fdont-even-bother |
| 20:30:48 | Mat3 | Demos: If you think so. Anyhow it is a common Unix tradition (beside kernel patching) |
| 20:31:07 | Araq | it wouldn't be that bad if not for the fact that there are like 6 different package managers with different formats |
| 20:31:41 | Demos | Araq: well that is also the case on windows, there is like ClickOnce, InstallShield, MSI, WSIX, and so on |
| 20:32:02 | Araq | Demos: they are all self-contained though |
| 20:32:08 | Mat3 | Araq: not to forget two incompatible build systems (I am sure to forget some) |
| 20:33:00 | Demos | Actually I think that aside from some settings problems MacOS has the right idea for app installation |
| 20:33:57 | Mat3 | hmm, do you mean the classic MacOS or Mac OS X ? |
| 20:34:14 | Araq | Mat3: nobody even remembers classic MacOS |
| 20:34:24 | Araq | ;-) |
| 20:34:27 | OrionPK | dom96 jester really needs more options / switches around logging.. |
| 20:34:36 | dom96 | OrionPK: indeed |
| 20:34:37 | Demos | OSX |
| 20:35:05 | * | Endy joined #nimrod |
| 20:36:06 | Mat3 | Mac OS X share these idea with Risc OS by the way. Anyhow, it is an elegenat solution |
| 20:36:11 | Mat3 | ^elegant |
| 20:36:34 | Araq | say I have python 2.7 installed on windows. I can install python 3 and deinstall 2.7 and the software using python keeps working as it included its own python version. |
| 20:36:51 | Araq | now try the same on unix. |
| 20:37:44 | reactormonk | Araq, works fine here, python2.7 and python3.3. |
| 20:38:03 | Araq | reactormonk: what does 'python' point to? |
| 20:38:21 | Demos | static linking: DO YOU HAVE IT :D |
| 20:38:57 | Demos | it is kinda a problem how in windows and OSX everyone uses dynamic libs and then distributes them with their app |
| 20:39:25 | Araq | Demos: it's weird but understandable |
| 20:40:09 | Demos | even on OSX? I mean on windows you have that whole problem with 4 versions of the standard lib |
| 20:40:55 | Araq | dunno I stopped using OSX years ago. have never been happier. |
| 20:41:45 | Demos | anyway this is how it is. The systems we use all suck. |
| 20:41:56 | Demos | Speaking of which I wonder if nimrod compiles on Plan9 |
| 20:42:08 | Mat3 | of course not |
| 20:42:10 | reactormonk | Araq, python3 |
| 20:42:12 | reactormonk | Araq, Nimrod/lib/nimbase.h:376:28: error: 'assert_numbits' declared as an array with a negative size |
| 20:42:14 | reactormonk | typedef int assert_numbits[sizeof(NI) == sizeof(void*) && NIM_INTBITS == sizeof(NI)*8 ? 1 : -1]; |
| 20:42:32 | Demos | reactormonk: nimrod and your C compiler disagree on the size of a pointer |
| 20:42:55 | Araq | this assert_numbits was a brilliant idea |
| 20:43:02 | Araq | saved us so much trouble |
| 20:43:15 | Araq | the error message could be better though lol |
| 20:43:38 | renesac | an even more brilliant idea would be to put an error message saying " nimrod and your C compiler disagree on the size of a pointer" instead of having people asking here on IRC |
| 20:43:40 | renesac | yeah |
| 20:44:02 | Araq | renesac: so submit a patch to do that |
| 20:44:20 | Araq | (I don't think there is a way) |
| 20:44:30 | renesac | I have no idea where to start |
| 20:44:35 | reactormonk | Araq, that's what emscripten gives me |
| 20:44:36 | renesac | hey, that was mean |
| 20:44:37 | renesac | XD |
| 20:44:51 | OrionPK | dom96 i'm going to add scgi support into irc familiar and release it, probably going to be a couple weeks before I have time though |
| 20:45:05 | dom96 | OrionPK: cool |
| 20:45:13 | renesac | but yeah, so we indeed need one more brilliant idea to put that error message there |
| 20:45:17 | renesac | XD |
| 20:45:29 | Araq | reactormonk: --cpu:i386 |
| 20:45:29 | OrionPK | then hopefully we can get some volunteers to enhance it |
| 20:45:35 | OrionPK | maybe switch from typescript to nimrod ;) |
| 20:45:53 | reactormonk | clang: error: unsupported option '--cpu:i386' |
| 20:46:41 | reactormonk | renesac, I think a comment on top of that statement what it is for would help |
| 20:46:52 | reactormonk | so if you look at the source, the problem is explained |
| 20:47:08 | reactormonk | Araq, oh, nimrod. |
| 20:48:12 | reactormonk | Araq, my hello world is 5k LoC :-/ |
| 20:48:49 | Demos | reactormonk: I thought C hello world was 5kloc in general. If you include the size of headers |
| 20:49:05 | reactormonk | Demos, sounds reasonable |
| 20:49:07 | reactormonk | warning: unresolved symbol: systemDatInit |
| 20:49:42 | renesac | reactormonk, good idea, I was thinking about using "assert(compiles(), error)" |
| 20:50:06 | renesac | not sure if it would work |
| 20:50:18 | Mat3 | ciao |
| 20:50:21 | * | Mat3 quit (Quit: Verlassend) |
| 20:51:23 | reactormonk | renesac, just add a comment there for starters |
| 20:51:33 | reactormonk | renesac, and compiles() only asks nimrod if it compiles, not the C behind it |
| 20:51:57 | reactormonk | Araq, sounds a bit more interesting, I'll take a look at emc |
| 20:52:00 | renesac | :/ |
| 20:52:01 | reactormonk | *ems |
| 20:52:09 | renesac | yeah, a comment is a good start |
| 20:52:25 | Demos | so I want to write a template that generates a proc, but I want to immediately call that proc as well. Kinda like the javascript function foo(){}() thing |
| 20:52:36 | renesac | should I do it? |
| 20:52:46 | Demos | reactormonk: if nimrod compiles something and the C code is invalid than it is a compiler bug |
| 20:52:47 | renesac | I need to update my compiler version anyway |
| 20:52:49 | Araq | reactormonk: editcompiler/main.nim to add a new command |
| 20:53:33 | Araq | Demos: not quite. if nimrod thinks int is 64 bits and GCC disagrees how should system.compiles know about that? |
| 20:54:03 | reactormonk | Araq, kk |
| 20:54:06 | Araq | system.compiles performs a semantic check in nimrod land |
| 20:54:13 | reactormonk | renesac, sure |
| 20:54:19 | Demos | true, but the C code is not invalid for some definition of invlaid |
| 20:55:03 | Araq | ping fowl |
| 21:03:20 | Demos | why is the unittest module not in the docs |
| 21:03:54 | Araq | because we never added it and iirc it lacks documentation anyway |
| 21:05:26 | Demos | yeah it kinda does, but at least listing the procs would be good |
| 21:05:52 | Demos | I have almost rewritten it multiple times since I did not know about it |
| 21:08:20 | Araq | unittest unfortunately still misses an essentia feature |
| 21:09:35 | Araq | if a == b is expected and the test fails, it doesn't tell where a and b differ |
| 21:10:00 | Araq | that would instantly make it much more useful than doAssert |
| 21:10:41 | Araq | but it doesn't so IMHO all it does is to provide more ceremony |
| 21:11:15 | Demos | well I am going to use it in case someone ever adds that feature |
| 21:11:25 | reactormonk | Araq, so you want an object diff? |
| 21:11:43 | reactormonk | Araq, sounds more interesting to me than ems |
| 21:12:01 | Araq | reactormonk: yeah, well diff for strings suffices |
| 21:12:10 | reactormonk | Araq, nah, gotta do it real |
| 21:12:15 | Araq | you can $ on objects |
| 21:12:43 | reactormonk | how do I get all the fields of an object on compile-time? |
| 21:13:05 | Araq | fieldPairs iterator |
| 21:13:11 | Demos | the fields iterator, you also probably want to use `$` by default and fall back on repr() |
| 21:13:35 | reactormonk | can I overload templates with procs now? |
| 21:13:43 | Araq | yes |
| 21:13:57 | reactormonk | cool, then I can define my own `$` instead of using repr |
| 21:14:02 | * | carum joined #nimrod |
| 21:14:09 | Araq | uh oh |
| 21:14:24 | Araq | well you can try |
| 21:14:31 | reactormonk | we'll see |
| 21:15:03 | reactormonk | anything fancy to produce a tree? |
| 21:15:55 | * | flaviu joined #nimrod |
| 21:15:56 | Araq | use the builtin triple star operator *** |
| 21:16:17 | Araq | also called the "read my mind operator" |
| 21:16:33 | Demos | docs for that? |
| 21:16:35 | Araq | it does the right thing (TM) |
| 21:16:56 | Demos | oh wait |
| 21:19:36 | Araq | it uses a laplace transformation to produce a fibonacci tree as the left subtree, then produce the root and then creates a splay tree as the rigth subtree |
| 21:20:12 | Araq | and it uses O(1) temporary storage and O(log log log N) time |
| 21:20:23 | Araq | fancy enough? :P |
| 21:21:59 | EXetoC | almost |
| 21:24:06 | renesac | https://github.com/Araq/Nimrod/pull/978 |
| 21:24:10 | renesac | sent pull request |
| 21:24:54 | NimBot | Araq/Nimrod devel 69e53f7 ReneSac [+0 ±1 -0]: Added comment explaining 'assert_numbits' error. |
| 21:24:54 | NimBot | Araq/Nimrod devel 53ebe76 Andreas Rumpf [+0 ±1 -0]: Merge pull request #978 from ReneSac/devel... 2 more lines |
| 21:25:23 | Araq | you made a typo btw |
| 21:25:36 | Araq | but a comment with a typo is better than no comment |
| 21:26:13 | renesac | ouch, I should have used an editor with error highlighting |
| 21:26:40 | NimBot | Araq/Nimrod devel b3c1755 Zahary Karadjov [+0 ±6 -0]: iterators now return tyIter(T);... 6 more lines |
| 21:26:40 | NimBot | Araq/Nimrod devel 5d711ab Zahary Karadjov [+0 ±26 -0]: split the inline and closure iterators into different symbol kinds for easier discrimination between them |
| 21:26:40 | NimBot | Araq/Nimrod devel 68470ba Zahary Karadjov [+0 ±3 -0]: test cases for the new handling of iterators by the `is` operator |
| 21:26:40 | NimBot | Araq/Nimrod devel 528ccce Zahary Karadjov [+1 ±3 -0]: fix #587 |
| 21:26:40 | NimBot | 1 more commits. |
| 21:28:13 | renesac | agree vs agrees? |
| 21:28:20 | * | Endy quit (Ping timeout: 244 seconds) |
| 21:28:23 | Araq | yes |
| 21:34:54 | renesac | :/ I never know when to use one or another |
| 21:43:45 | * | carum quit (Remote host closed the connection) |
| 21:43:49 | Demos | if I have a string of len 4 called foo, foo.cstring[4] == '\0'? |
| 21:44:06 | Demos | actually that is obvious |
| 21:44:17 | Demos | and I can write to the string using that cstring? |
| 21:44:24 | Araq | yes |
| 21:50:58 | * | carum joined #nimrod |
| 22:01:23 | * | Demos quit (Ping timeout: 264 seconds) |
| 22:03:33 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 22:04:06 | * | skyfex joined #nimrod |
| 22:08:18 | * | skyfex quit (Ping timeout: 240 seconds) |
| 22:18:04 | * | DAddYE__ joined #nimrod |
| 22:20:25 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 22:24:17 | * | DAddYE__ quit (Remote host closed the connection) |
| 22:24:48 | filwit | on Linux (rolling release), software is much easier to keep up-to-date than Windows. All my Windows software is behind my Linux version because Arch has made me lazy |
| 22:24:53 | * | DAddYE joined #nimrod |
| 22:25:23 | filwit | also, I started on MacOS prior to the X ;) ahh... good old MacOS 8/9 sure had it's appeal |
| 22:25:58 | renesac | filwit, only if your distribution packages are up to date |
| 22:26:05 | filwit | you had to set pre-defined ram-allocation amount in the exe's info box |
| 22:26:45 | filwit | I remember there being problems where Photoshop or some game would recommend going in and raising the predefined limit if you had more memory, lol |
| 22:26:58 | renesac | and on some projects that have large hiatus between official stable releases, that is usually not true |
| 22:27:00 | filwit | renesac: note the 'Arch' ;) |
| 22:27:13 | renesac | what is the latest nimrod package on arch? |
| 22:27:24 | filwit | renesac: these days though, Manjaro is just as up-to-date as Arch and very stable/easy-to-use |
| 22:27:37 | filwit | renesac: 0.9.2 is in arch community |
| 22:27:55 | renesac | see, old |
| 22:27:56 | renesac | xD |
| 22:27:56 | filwit | it's even in Manjaro |
| 22:27:59 | filwit | lol |
| 22:28:08 | filwit | technically that's "stable" so not old |
| 22:28:31 | renesac | ubuntu used to ship 3 year old libav |
| 22:28:40 | renesac | because they didn't do point releases |
| 22:28:44 | flaviu | renesac: master |
| 22:28:53 | flaviu | yaourt -S nimrod-git |
| 22:28:59 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 22:29:12 | renesac | in windows, you had weekly ffdshow builds |
| 22:29:17 | filwit | yeah, i don't see how anyone uses Debian or Ubuntu. Not only are they very outdated, they're also not rolling... that's a really silly system. Would rather use Windows where it's all on you. |
| 22:29:30 | * | jbe quit (Quit: Leaving) |
| 22:29:47 | filwit | well, Debian Unstable does roll.. |
| 22:29:48 | * | DAddYE joined #nimrod |
| 22:29:55 | filwit | to be fair. still, too old |
| 22:30:05 | Kelet | Anyone know about something like protobuf or msgpack for Nimrod or know someone working on something like this? |
| 22:30:09 | renesac | I've aways used apt-based distros |
| 22:30:21 | renesac | and ubuntu is generally more supported than other distros |
| 22:30:59 | renesac | I've tried chakra linux once and didn't liked it... |
| 22:31:05 | renesac | based on arch |
| 22:31:17 | flaviu | renesac: Widen your horizons. Arch has been awesome for me because I had to learn everything that goes into my system |
| 22:31:50 | renesac | I've also tried opensuse, came back to ubuntu again |
| 22:32:01 | filwit | i went to arch and never looked back. never felt the need to. Though Manjaro i've put on other systems cause it's got an installer |
| 22:32:03 | filwit | brb |
| 22:33:12 | flaviu | Have you seen https://nixos.org/nixos/? It looks really awesome for placing on multiple systems. |
| 22:33:22 | Araq | Kelet: adapt marshal.nim to use a binary protocol |
| 22:33:45 | renesac | flaviu, yes |
| 22:34:13 | renesac | I like 0install, as the upstream that should build packages |
| 22:34:32 | renesac | but alas, linux people don't like it so it never really got traction.. |
| 22:34:51 | renesac | the author continues to push strong though, I respect him |
| 22:35:21 | renesac | recently he migrated the code base from python to OCalm |
| 22:35:40 | renesac | too bad he didn't chose nimrod |
| 22:35:44 | flaviu | It looks like it might be gui-only |
| 22:35:55 | renesac | no |
| 22:36:09 | renesac | it has many command line aplications |
| 22:36:11 | Kelet | Araq: I guess I'll take a stab at it this weekend |
| 22:36:13 | renesac | and 0launch |
| 22:41:16 | * | ddl_smurf joined #nimrod |
| 22:42:42 | * | ddl_smurf quit (Client Quit) |
| 22:46:28 | Varriount | Hm. Does marshal.nim do function pointers? |
| 22:52:37 | * | Demos joined #nimrod |
| 22:53:31 | * | ddl_smurf joined #nimrod |
| 22:58:47 | Araq | Varriount: -------i dont know |
| 23:01:37 | filwit | nequitans: i'm going through your article slowly. Good job so far. Looks like you've spent some time on this. |
| 23:04:29 | * | DAddYE quit (Remote host closed the connection) |
| 23:04:29 | filwit | nequitans: one thing that might be nice to add to the conclusion or the article is, instead of "parallelFor(s, i, n): ..." you showed how to use {.immediate.} and overloads to end up with "parallelFor i in n: ..." & "parallelFor s, i in n: ..." so they feel right at home alongside the builtin 'for' |
| 23:05:05 | filwit | of** the article.. |
| 23:06:34 | * | DAddYE joined #nimrod |
| 23:06:51 | * | meguli joined #nimrod |
| 23:10:15 | filwit | Araq: ever consider making a "Strictness Level" where, at it's peak, things like () and CaseStyle where enforced at call-site (when/how they appear at definition), and then having things like {.strictUse:[keyword,anycase].} for fine-tuning. |
| 23:10:34 | Araq | yes |
| 23:10:38 | filwit | Araq: not making a feature request or anything, just wondering if you've had a similar idea |
| 23:10:45 | filwit | okay, thought you might have |
| 23:11:02 | filwit | any additional opinions on it you care to share? |
| 23:11:25 | Araq | I tnd to e |
| 23:11:36 | filwit | er... |
| 23:12:02 | Araq | I tend to enumerate every possibility before picking what feature to do |
| 23:12:22 | filwit | that's statistically impossible ;P |
| 23:12:31 | filwit | improbable** |
| 23:13:29 | filwit | but is this an eventual direction you see Nimrod going in? I ask cause you've done work on the -cs:partial stuff recently, which is similar |
| 23:13:46 | filwit | or do you have other goals/better-ideas? |
| 23:14:48 | Araq | --enforceStyle surely is on the table |
| 23:14:49 | EXetoC | Araq: so create, createShared, create0, resize and resizeShared? |
| 23:15:44 | Araq | EXetoC: almost good, create0 should be 'create' and the uninit create should be createDEADAFFE |
| 23:17:07 | Araq | or perhaps createU |
| 23:17:08 | nequitans | hi filwit, just reading your comments now |
| 23:20:11 | * | psquid joined #nimrod |
| 23:20:33 | Araq | hi meguli welcome (are you new?) |
| 23:22:37 | * | faassen quit (Remote host closed the connection) |
| 23:23:03 | meguli | Yes I am. |
| 23:28:37 | nequitans | filwit, interesting -- thanks for the suggestion. i haven't looked into using in, but i like the idea, so i'll try it out |
| 23:29:26 | Araq | parallelFor is '||' |
| 23:29:59 | Araq | (yes I know it's currently mapped to OpenMP) |
| 23:32:26 | EXetoC | Araq: that sure is short, but ok. changing now |
| 23:33:11 | renesac | Araq, or create(x, initialize=false) |
| 23:34:33 | renesac | though you will be adding things to the compiler optimizer inline and constant-fold |
| 23:35:24 | renesac | but I like optional arguments as an interface |
| 23:36:08 | renesac | (first programming languages sure influence your tastes) |
| 23:36:13 | NimBot | nimrod-code/Aporia master 5f8eb60 Dominik Picheta [+0 ±3 -0]: Line endings are now detected and kept consistent. |
| 23:36:13 | NimBot | nimrod-code/Aporia master 1ff250f Dominik Picheta [+0 ±3 -0]: Extra newline at EOF will now be added when saving files. |
| 23:37:12 | renesac | *ones taste |
| 23:41:10 | * | xenagi joined #nimrod |
| 23:42:49 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 23:51:19 | * | io2 quit () |
| 23:52:35 | xenagi | hi guys |
| 23:57:03 | Araq | hi xenagi |
| 23:58:08 | Araq | good night |
| 23:59:47 | Demos | I am pretty sure I am writing the slowest GL code to ever see the light of day |
