<< 11-02-2014 >>
00:03:42*vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
00:14:42*carum joined #nimrod
00:28:39dom96good night
00:33:11xenaginight
00:53:44*Icefoz_ joined #nimrod
00:56:14*Icefoz quit (Ping timeout: 265 seconds)
00:56:15*Zuchto quit (Ping timeout: 240 seconds)
00:56:55*Zuchto joined #nimrod
01:14:24*OrionPK quit (Remote host closed the connection)
01:17:14*OrionPK joined #nimrod
01:27:50*Araq quit (Ping timeout: 264 seconds)
01:28:26*Amrykid quit (Ping timeout: 264 seconds)
01:30:00*Araq_bnc joined #nimrod
01:30:14*dom96 quit (Ping timeout: 264 seconds)
01:34:31*Amrykid joined #nimrod
01:36:30*dom96 joined #nimrod
01:42:07*CarpNet quit (Ping timeout: 250 seconds)
01:42:33*CarpNet joined #nimrod
01:42:47*DAddYE quit (Remote host closed the connection)
01:54:26*carum quit (Remote host closed the connection)
02:06:58*carum joined #nimrod
02:07:44*Vix joined #nimrod
02:25:12*brson quit (Quit: leaving)
02:25:38*brson joined #nimrod
02:27:16*brson_ joined #nimrod
02:28:38*Vix quit (Quit: Page closed)
02:30:54*brson quit (Ping timeout: 245 seconds)
02:45:54*brson_ quit (Ping timeout: 245 seconds)
03:01:42*Ycros quit (Quit: No Ping reply in 180 seconds.)
03:02:00*Ycros joined #nimrod
03:05:32*DAddYE joined #nimrod
03:31:58VarriountAraq_bnc: Could you use the fiber api on windows, and the get/set context api on linux, to implement coroutines?
03:36:55*ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
03:38:13*ics joined #nimrod
03:40:19*aftersha_ joined #nimrod
03:44:02skrylari think you're meant to do coroutines with iterators
03:48:14*carum quit (Remote host closed the connection)
03:54:11*aftersha_ quit (Quit: Computer has gone to sleep.)
03:57:31*carum joined #nimrod
03:59:40*carum quit (Read error: Connection reset by peer)
04:00:01*carum joined #nimrod
04:11:00DemosC programmers use sjlj, and fibres seems kinda like that
04:15:29*psquid quit (Quit: WeeChat 0.4.2)
04:18:55*DAddYE quit (Remote host closed the connection)
04:23:02*carum quit (Remote host closed the connection)
04:23:10*carum joined #nimrod
04:27:23skrylarlol
04:27:30skrylarI fixed a bug, just not the one I wanted to fix. xD
04:27:38xenagilol
04:33:08*xenagi quit (Quit: Leaving)
04:33:58skrylarfml
04:34:10skrylarI seem to have more bugs in my testing harness than I ever do the main code
04:45:57*BitPuffin quit (Ping timeout: 248 seconds)
05:11:29Demoslol :D I wrote my first ray tracer yesterday. I got the intersection check and lighting calculations right the first try and screwed up lerping between the screen edges
05:19:06*carum quit (Remote host closed the connection)
05:22:45*carum joined #nimrod
05:26:57*carum quit (Remote host closed the connection)
05:49:45*xtagon quit (Quit: Leaving)
05:49:49skrylarits probably a colossal waste of time, but i still kinda want a Fountain parser
05:50:15skrylarso it converts a movie script in to lua
06:10:24*Demos quit (Read error: Connection reset by peer)
06:19:46*dmac joined #nimrod
06:20:40*DAddYE joined #nimrod
06:23:57skrylarhrm
06:24:18skrylari've noticed that some of the stdlib operations are missing for uints
06:24:33filwitimport unsigned
06:25:08*skrylar ponders why that isn't done by default
06:25:19*DAddYE quit (Ping timeout: 260 seconds)
06:25:21skrylaralso, no. importing unsigned doesn't fix inc()
06:25:25*filwit wonders the same thing
06:25:43filwitnot sure about inc for uint, never tried
06:25:49skrylarit just errors
06:25:53filwiti don't use inc, i just += 1
06:26:19skrylari should probably poke in to the compiler at some point, those issues are minor enough i can probably fix them
06:26:38filwityeah it's probably just a missing proc in the unused lib
06:28:25*demizer left #nimrod ("WeeChat 0.4.2")
06:28:41*DAddYE joined #nimrod
06:48:34*filwit quit (Quit: Leaving)
07:05:19*Araq_bnc is now known as Araq
07:09:13AraqVarriount: yes you can use setcontext et al that
09:45:55*DAddYE quit (Remote host closed the connection)
10:21:29*BitPuffin joined #nimrod
10:54:33BitPuffinhow do I set a socket to be non blocking with the sockets module
10:55:27BitPuffinlike fcntl(socket, F_SETF, O_NONBLOCK, 1);
10:59:46BitPuffinoh
10:59:52BitPuffinis it setting buffered to false?
11:00:49skrylaro_o
11:00:54skrylarthat code looks disgusting
11:01:02skrylarwhy is it not more nimrod-y :)
11:01:42BitPuffinskrylar: that's C code
11:01:52BitPuffinskrylar: I'm wondering what the nimrod equivalent is
11:02:02BitPuffinI assume it is setting up the socket something like this:
11:03:47BitPuffinvar sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP, false)
11:04:10BitPuffinthen you'll hopefully have an async socket that uses udp
11:09:40*dom96_and joined #nimrod
11:09:47dom96_andBitPuffin: no
11:10:14dom96_andUse PAsyncSocket or sockets.setBlocking
11:10:47skrylarhmm.. I haven't touched any of the IO modules sadly
11:11:21skrylarI remember rust sockets were embarassing. Couldn't send/recv because they decided you don't need nonblock, you should just use tasklets. Which basically means two OS threads per socket.
11:11:35skrylarYay using the *actual* nonblock command
11:13:24BitPuffindom96_and: which one is preferred?
11:13:29BitPuffinI guess PAsyncSocket?
11:13:47dom96_andYes.
11:14:04BitPuffindom96_and: lol I like how I start using it while you are messing with it
11:14:06dom96_andUse it with the dispatcher
11:14:10BitPuffindom96_and: you better get done ;)
11:14:19BitPuffindispatcher?
11:14:38dom96_andGSoC takes priority
11:17:08BitPuffindom96_and: uh, GSoC is quite a bit away
11:17:36dom96_andUhh. The deadline is this Friday.
11:17:46BitPuffinoh you mean submisison
11:17:53BitPuffinI thouhght you meant the whole thing
11:18:50*epsylon quit (Ping timeout: 252 seconds)
11:23:18*epsylon joined #nimrod
11:36:29Araqskrylar: were you the guy telling me how unicode works? :P
11:37:05AraqI argue for years utf-32 is a variable length encoding much like utf-8 is ...
11:45:22skrylarAraq: nah, i was mentioning that runes don't account for the combining marks
11:45:34skrylarin terminology
11:48:36AraqI know
11:48:51Araqbut the unicode module is old :P
11:51:31skrylar:P
11:51:37skrylarI should see if I still have my old C code for that around
11:51:45skrylarI think I do, somewhere
12:01:29skrylaryay line wrapping code :|
12:04:52Araqzahary: taking the address of a generic proc should require 'procvar' just like non-generics do
12:05:30Araqotherwise some fool passes stdlib.foo to 'map' and we can never add default arguments to stdlib.foo without breaking code
12:06:05*Araq still thinks taking the address of a routine you don't own is offensive
12:06:17skrylarAraq: compiler warning?
12:06:55Araqskrylar: I'm not against warnings, but what does this solve here? it should simply be forbidden
12:07:59skrylardifferent modules in the same package by the same developer?
12:08:43Araqskrylar: we have that in the compiler. we annotate with 'procvar' and it really helps readability anyway IMO
12:09:11skrylari was just trying to think of a use case with that, since i'm normally for letting people shoot themselves in the foot if they want to
12:09:17Araqit's nice to see it's called indirectly
12:09:33AraqI also love the .thread annotation
12:09:36skrylar"smarter than you" compilers get really annoying if they accrue too many "you can't do that because i said so"'s
12:10:10*ddl_smurf quit (Quit: ddl_smurf)
12:10:25Araqit's not about the compiler being "smarter"
12:10:35Araqit's about being explicit about contracts
12:11:10Araqyou have to say "yes, you are allowed to take the address of this proc as I never change its interface"
12:12:01Araq"it won't become a template in the fturue. nor will the types differ slightly (int -> int32), nor will it ever get additional default parameters"
12:12:20Araqit's a strong commitment really
12:30:19*dom96_and quit (Quit: Bye)
12:34:52*OrionPK quit (Remote host closed the connection)
13:28:08*darkf quit (Quit: Leaving)
13:33:43*dmac quit (Ping timeout: 260 seconds)
13:47:55*[1]Endy joined #nimrod
13:48:14*OrionPK joined #nimrod
13:57:21*aftersha_ joined #nimrod
14:05:16*[1]Endy quit (Ping timeout: 245 seconds)
14:18:23*aftersha_ quit (Quit: Computer has gone to sleep.)
15:35:00OrionPKaraq you figure out the reported memory use vs. task manager's memory use?
15:35:55*ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
15:37:30*noam_ joined #nimrod
15:40:21*noam quit (Ping timeout: 260 seconds)
15:40:38*ics joined #nimrod
15:44:31*[1]Endy joined #nimrod
16:21:33*tdc joined #nimrod
16:27:14*aftersha_ joined #nimrod
16:38:09*[2]Endy joined #nimrod
16:38:58*aftersha_ quit (Quit: Computer has gone to sleep.)
16:42:05*[1]Endy quit (Ping timeout: 272 seconds)
16:55:31*ddl_smurf joined #nimrod
16:56:46*tdc quit (Quit: Leaving)
17:13:41*tdc joined #nimrod
17:28:20*io2 joined #nimrod
17:38:32AraqOrionPK: sorry, haven't looked at it again
17:53:04*carum joined #nimrod
17:54:23*DAddYE joined #nimrod
17:57:35*brson joined #nimrod
18:00:03*aftersha_ joined #nimrod
18:03:22EXetoCSo you want MongoDB in nimrod-code then?
18:03:28Araqyes
18:03:37BitPuffinwhat
18:03:41Araqor somewhere else, it doesn't matter
18:03:46Araqjust make it a babel package
18:03:57BitPuffinoh you mean database adapter?
18:04:27EXetoCthe modules in the std lib will be moved
18:05:02BitPuffinyeah they should
18:05:13EXetoCI can add it there. Either make me a member or create the repository and I'll make a PR some time this week
18:06:47BitPuffinEXetoC: so you have access to it?
18:06:51BitPuffinI feel so discriminated
18:06:57BitPuffinI came here around the same time as EXetoC
18:07:38EXetoCno I've only been submitting pull requests
18:08:01Araqbbl
18:10:37*EXetoC quit (Quit: WeeChat 0.4.2)
18:11:05VarriountBitPuffin: I found you a friend -> http://www.tapirback.com/tapirgal/gifts/friends/birds/puffin-stuffed-audubon-bird-f1878.jpg
18:12:24BitPuffinVarriount: buy it and ship it to me
18:13:04*EXetoC joined #nimrod
18:14:11*aftersha_ quit (Quit: Computer has gone to sleep.)
18:18:11Araqping zahary
18:22:55*micklat joined #nimrod
18:26:43*xtagon joined #nimrod
18:37:07micklatis there some equivalent to: from a.b.c import d as qux?
18:37:14micklator any plans to provide such a facility?
18:37:25*BitPuffin quit (Ping timeout: 250 seconds)
18:37:57Araqno, you can only alias module names with 'as'
18:38:29Araqand people fought long and hard with me to get even that :P
18:40:30AraqI consider 'as' a code smell tbh, it's like saying "ooh you should use foo.bar.baz.fu to respect some hierarchy but of course that's verbose and childish so you should introduce your own abbrevs"
18:40:49micklatwell, what's wrong with that?
18:41:03micklatis there some example for "as"? didn't see it in the manual
18:41:15Araqcheck the manual for 0.9.3
18:41:29micklatthanks
18:42:08AraqSystem.Text.RegularExpressions.Regex # .NET
18:42:56AraqSystem.Configuration.ConfigurationManager.AppSettings iirc
18:43:21micklatyou mean those are module names?
18:43:22Araq'as' is a patch for names like these
18:43:33micklatyeah, but I like hierarchies
18:43:39Araqyeah but I don't
18:43:42micklatit's a good patch
18:45:36Araqthis whole notion of avoiding abbrevs for readability is wrong and misguided and shows a great ignorance of how human language works
18:45:48reactormonkI get a nil here: https://gist.github.com/reactormonk/a3e943ce2a9235b4c1be but I can't find out where the porblem is. The two .csv are the sqlite tables used. Any ideas?
18:46:05reactormonkplanetary_interaction.nim(168) planetary_interaction
18:46:07reactormonksets.nim(40) produceItem
18:46:43*BitPuffin joined #nimrod
18:46:46micklatAraq: care to elaborate your thesis?
18:46:52Varriountdom96, Araq: I'm working on formatting and cleaning up the GSoC ideas list
18:47:19micklatI'm leaving the abbreviation to the user
18:47:19reactormonkdom96, you signed up for GSoC?
18:48:00Araqmicklat: the common words tend to be short, common programming terms should be short too and shortened if too long
18:48:32micklatwell, we don't all get to write the common words
18:48:39micklatmost of us, in fact, write the uncommon ones
18:48:56micklatshort names are good for a standard lib, so I see where you're coming from
18:49:35Varriountmicklat: Have you seen the GSoC Ideas list yet?
18:49:49micklatno, I've only been here for, like, 3 days
18:50:26Varriountmicklat: Never too early to learn -> https://github.com/Araq/Nimrod/wiki/GSoC-2014-Ideas
18:50:44Araqreactormonk: sorry, I have no idea
18:51:19*Mat3 joined #nimrod
18:51:27Mat3hi all
18:51:42micklatI kinda like what I'm doing now (bindings to python and lua)
18:51:55reactormonkAraq, the stacktrace is kinda off
18:51:57reactormonksets.nim(40) produceItem
18:53:44Varriountmicklat: Good!
18:54:03VarriountHaving bindings for scripting languages is quite useful.
18:54:06reactormonkthere's one missing.
18:54:39VarriountI know Araq would rather have us believe that Nimrod is perfect for everything, but dynamic scripting languages do excel at certain tasks.
18:55:10Mat3can you please precise your statement ?
18:55:58reactormonkwasn't there an option to help gdb a bit?
18:56:31Mat3(not, that I would disagree, only curious)
18:56:42*aftersha_ joined #nimrod
18:57:11micklatreactormonk: you mean beside --debuginfo --lineDir:on --threads:on ?
18:57:58tdchi. can someone tell me if it's possible to use nested tables; i.e. similar to TTable[string, TTable[string, string]] ?
18:58:08reactormonknice
18:58:22reactormonk#0 0x00000000004381de in produceitem_133597 (reactions=..., item=0x7fffffffe160)
18:58:24reactormonk at /home/tass/dev/nimrod/Nimrod/lib/pure/collections/sets.nim:40
18:58:26reactormonk^ what.
18:58:58reactormonktdc, what speaks against it?
18:59:34tdcIt compiles but doesn't do what I want... Given a var t of the aforementioned type....
18:59:44reactormonktdc, you want mget
18:59:48tdct["one"] returns a copy
19:00:00tdcAah - thanks!
19:00:41reactormonkany way to explicitly print the backtrace? seems to be a bug there.
19:01:13Araquse gdb and invoke 'bt' in there
19:02:22VarriountAraq: Was it hard, getting the nimrod compiler to generate information that GDB could use?
19:03:22VarriountI mean, I know that nimrod support for gdb isn't advanced as, say, C++ (which is to be expected) but GDB handles nimrod code surprisingly well.
19:03:33EXetoCVarriount: The only thing that's missing is the unimplemented VM features IMO. I can't stand dynamic typing
19:03:49VarriountEXetoC: To each his own. :3
19:04:25EXetoCyeah
19:04:30*Varriount uses 'x = 3, x = "foo"' on EXetoC
19:05:27micklatI'd appreciate some early feedback on my little project https://github.com/micklat/NimBorg
19:05:38micklatif you hate the name, or the directory structure, or the general approach
19:05:41micklatgo ahead and say so
19:05:54Varriountmicklat: Documentation is my best friend.
19:06:21micklatgood point
19:06:26*BitPuffin quit (Ping timeout: 265 seconds)
19:06:51micklatthere's almost something worth documenting already
19:06:58Varriountmicklat: Except internals.
19:07:10micklat?
19:07:24*brson quit (Ping timeout: 265 seconds)
19:09:15micklatVarriount: I don't understand the bit about internals. What do you mean?
19:09:35dom96reactormonk: not uet
19:09:35Araqmicklat: only skimmed it but it looks superb
19:09:38dom96*yet
19:09:46micklatwow, thanks
19:10:23Mat3micklat: I think your general approach is fine. I am only a bit sceptical about the usefulness of phyton bindings
19:10:49micklathow so, Mat3?
19:11:09Mat3I mean, what applications have you in mind ?
19:11:37micklatWell, I have no particular application in mind, but I come from scientific computing, where nimrod is currently rather weak, and python is very strong
19:11:48EXetoCthere are so many reasons why you'd want a bridge
19:12:25*Varriount|Mobile joined #nimrod
19:12:51Varriount|MobileSorry, laptop baty
19:13:02Varriount|Mobilebattery died
19:13:16Araqmicklat: ELuaTypeError is somewhat of a misnomer, since the 'E' stands for exception already; it should be EInvalidLuaType
19:13:37micklatAraq: not sure about that.
19:13:44micklatIt's not that the object has an invalid type
19:13:47Varriount|MobileUnfortunately, not many stop to consider that internal documentation is important
19:13:50micklata table is a fine type to have
19:14:12micklatVarriount: Ah, I see
19:14:12Araqhowever we'll get rid of the type prefixes and then it should be LuaTypeError ... oh well
19:14:22Varriount|Mobilewithout internal documentation, contributers have a very hard time improving code
19:14:46micklatI see
19:14:56Mat3Can someone tell me a specific reason for Phyton bindings (would be nice, because I see none) ?
19:15:05micklatAraq: you want to get rid of all prefix?
19:15:06EXetoChe told you
19:15:07Varriount|MobilePlugins
19:15:20micklatI mean, T is silly, but P and E do have a meaning
19:15:20Mat3ah ok, makes sense
19:15:25Varriount|MobileDynamic loading of plugins, like for games
19:15:28Araqmicklat: after 0.9.4 is out, yeah
19:16:06AraqT is not that silly, is stands for "value Type" ;-)
19:18:40reactormonkthis is a key in the table: 0x7f68351c9820"2389". This is the value I'm asking with hasKey() for: 0x7f68351adfc8"2389" - returns false.
19:19:41reactormonkapparently it doesn't like strings. Use ints instead?
19:20:55reactormonknope, doesn't help.
19:21:37*askatasuna quit (Quit: WeeChat 0.4.2)
19:21:39reactormonkhm, does.
19:22:01EXetoCmicklat: we'll migrate to Foo/FooPtr/FooRef/FooError or something like that
19:22:05EXetoCErr?
19:22:23micklathow is this an improvement?
19:22:23reactormonkhum.
19:23:16*Varriount|Mobile quit (Remote host closed the connection)
19:23:48VarriountSorry, back
19:24:04EXetoCmicklat: some people strongly dislike what we have now apparently
19:24:17VarriountMy laptop battery ran out near theend of class, and I wasn't able to plug in my charger.
19:24:49micklatbut nobody's complaining about c's case and underscore handling
19:25:14micklatare the prefixes the problem? I thought it was the case-and-underscore insensitivity
19:25:25micklatwhich I don't like, BTW
19:26:22Mat3Araq: What are the reasons for that change again ?
19:26:34dom96micklat: Why do you dislike it?
19:26:53EXetoCI can never remember exactly, but I don't see a problem with keeping those other prefixes, but I think some people also dislike not specifying 'ref' and 'ptr'
19:27:18AraqMat3: we're growing too slowly, can't be bad to care more about popularity
19:27:38micklatIn my extremely short experience, it's easy to get namespace pollution in nimrod.
19:27:57micklatwith underscore sensitivity, you have a bigger namespace
19:28:00micklatso fewer collisions
19:28:09micklatsame for case
19:28:23Araqmicklat: that's a weak argument
19:28:49micklatyou like brevity, right?
19:28:56Araqso you have fooBar and foo_bar and _foo_bar, in the same scope, yay
19:29:12Araqthat's just another desaster
19:29:21micklatyes, I only care about one of them, the other two are defined by other modules that I'd actually rather not know about
19:29:36micklatI always spell it foo_bar, no problem for me
19:29:39Araqthat's wishful thinking
19:29:52Araqin fact, foo_bar shouldn't exist in the first place
19:29:57reactormonkhow come there's no `$` for seq?
19:30:08Araqconsistency means it's fooBar everywhere
19:30:18micklatugh, camelCase is ugly!
19:30:25micklatok, enough with the bikeshedding
19:30:28AraqcamelCase is MORE readable
19:30:31micklatI'm going to shut up
19:30:54*vbtt joined #nimrod
19:30:59reactormonkAraq, that's a matter of habit.
19:31:00VarriountI don't care what style is chosen, as long as it's consistant throughtout the stdlib
19:31:16VarriountOr else we get PHP
19:31:28reactormonkAraq, unless you wanna bring up some science.
19:31:56dom96micklat: With style insensitivity you can choose not to use camelCase :P
19:32:22Araqreactormonk: the studies I know are worthless, but note that F# went from foo_bar to fooBar because foo_bar looks too much like foo bar
19:32:27EXetoCit doesn't make much sense otherwise imo
19:33:01micklatthe real problem is that it's too easy to get namespace collisions, I suppose
19:33:13micklator maybe I'm using import the wrong way
19:33:18vbttheh - camelcase makes me want underscore/case insensitivity so I can write snake_case
19:33:25Mat3I think the fight for naming conventions is fundamentally a psychological problem of human nature (limitations)
19:33:41vbttbut, i'm trying to look beyond the style.
19:33:44EXetoCmicklat: symbols can be fully qualified, so that's not a big issue imo
19:34:14vbtti find underscores more readable than cameCase, btw. also prettier :)
19:34:14micklatI'd rather not get stopped by the mysterious compiler error in the first place
19:34:18Mat3let's overcome it
19:34:41EXetoCmicklat: also, you can force module qualifications if you want
19:34:48AraqI argue fooBar is objectively easier to read :P
19:35:02vbttif you're going to have space sensitivity, just allow hyphenated-names
19:35:04vbtt;)
19:35:14Araqbecause it makes the *structure* of the code much clearer
19:36:06Araqthe different words within an identifier should not be emphasized, so foo_bar is wrong
19:36:13reactormonkvbtt, I'm in for hyphens ;-)
19:36:21EXetoCI prefer the shortest possible names that make sense :-)
19:36:29dom96let's allow ? and ! in proc names while we're at it.,
19:36:42reactormonk^ I approve.
19:37:01micklatdom96: makes sense, but I think we want Nimrod to be popular, no?
19:37:02reactormonkAnd # for fuck's sake.
19:37:07vbttif request.is-pending?: ...
19:37:16micklatvbtt: looks great
19:37:16reactormonkvbtt, either is- or ?
19:37:32vbtti've seen a language with spaces allowed in identifiers.
19:37:39dom96I thought people loved that crap? :P
19:37:49vbttan it was space/underscore/case insensitive
19:37:52dom96Ruby allows ? in proc names right?
19:37:53vbtt*and
19:37:53micklatum, actually, an if is not a question
19:37:56reactormonkdom96, yup
19:38:09VarriountHm. Is it 'API' or 'api', and are multiple prefixed with simply an 's', or an " 's "?
19:38:15vbttwell the ? usually implies boolean result.
19:38:18vbttanyway, i'm just j/k.
19:38:30vbtt.. about all of this.
19:38:49dom96yes, same here :P
19:39:04reactormonkdom96, actually, only at the end of a method name
19:39:27vbttAraq:if you want to be more popular, yes, case+underscore sensitivity will help.
19:39:58Mat3why should 'this_is_a_special_identifier' be more readable than 'thisIsASpecialIdentifier' ?
19:40:01vbttAlso, more blogs and docs about internals of nimrod's implementation. interesting projects implemented in it, etc.
19:40:20Mat3and why are prefixes for types a bad idea ?
19:40:21vbttpeople don't want to spend time digging too deep into code.
19:40:38dom96If we want Nimrod to be more popular we need corporate backing.
19:41:02Varriountdom96: Or at least apply for grants
19:41:17vbttMat3:because i can break it up easily by visible space.
19:41:23Araqdom96: if I change the tester to produce a diff in the JSON how fast can you adapt the builder?
19:42:19vbtttype prefixes are annoying. I don't remember when I was last confused about whether a Foo was a type or a value - it's usually obvious given the context.
19:42:33vbttso i'm not sure what the purpose of type prefixes are.
19:42:40vbtt*is.
19:42:50micklatvbtt: a short way to write both Foo and PFoo
19:42:53micklatbrevity
19:42:59dom96The point is to know whether a type is a pointer or a value type.
19:43:10vbttmicklat:oh, I meant TFoo
19:43:15vbttyeah PFoo is fine.
19:43:27vbttor FooPtr, i don't care about that.
19:43:36vbttbut the core type doesn't need T.
19:43:42micklatsame here
19:44:11dom96Araq: argh. Hard to say. I've got a deadline in school on Thursday. But I am off school on Friday.
19:44:19dom96GSoC needs to be sorted though.
19:44:45Araqdom96: wrong answer
19:44:51EXetoCvbtt: case-insensitivity
19:45:06Araqright answer would have been "takes me half an hour"
19:45:17Araq"and I will do it right now"
19:45:19EXetoCthat's all. actually, I do like the symmetry
19:45:34vbttEXetoC:ah i see, another reason to not have case-insensitivity :)
19:46:08vbttso with snake_case you'll attrace C and Python folks. with CapitalizedNames you'll attract Java and C# folks. Not sure who you attract with camelCase ;)
19:46:35*brson joined #nimrod
19:47:20Araqsnake_case is barbaric and even python calls it startswith, not starts_with
19:47:32vbttAraq:Python makes an exception for stdlib only.
19:48:06Araqvbtt: why?
19:48:07vbttsee pep 8
19:48:26micklatI've been coding python for a decade and I still hate camelCase
19:48:41dom96Araq: Oh, in that case that'll be 1 BTC.
19:48:45VarriountCould you guys stop arguing about things that you'll never change your minds about, and be productive?
19:49:05Varriountdom96: https://github.com/Araq/Nimrod/wiki/GSoC-2014-Ideas
19:49:30VarriountShould I add horizontal lines after each item?
19:51:10dom96Varriount: hrm, if it looks good. The bold already emphasises that it's a different item I think.
19:51:28xtagonVarriount, no, it looks fine
19:51:53EXetoCVarriount: I can't remember if there were any good arguments in favor of PFoo -> FooPtr etc, that's all
19:52:02EXetoCAraq: did I even get that right? ^
19:52:29Varriountdom96, Araq: You'll have to put the required/preferred skills for some of the ideas (like coroutines) as I have no idea what is needed for those.
19:53:15vbttmicklat:but python doesn't use camelCase?
19:53:41Araqpython does use CapitalizedNames for classes iirc
19:53:56vbttAraq:correct.
19:54:36Araqthe argument usually is "foo_bar is more readable unless it's some other entity which we happen to encode with CapitalizedNames"
19:54:52vbttAraq: ClassName. function_name, method_name, module_name, local_var_name, MODULE_CONSTANT_NAME, _private_method, _private_instance_var
19:54:55Mat3Varriount: thanks
19:55:17Araqin other words the argument really argues for a form of hungarian notation, not for "underscores are more readable"
19:55:30micklatvbtt: it seems like I mistook the convention at my first workplace for the standard
19:55:46micklatAraq: those are two separate issues
19:55:54Araqif they were more readable, they would be used regardless of the identifier's entity
19:56:07Araqbut they are not, so the argument makes no sense
19:56:18micklatAren't you elevating PEP8 to a godlike status?
19:57:18micklatI mean, the fact that some convention became PEP8 doesn't prove anything about readability
19:57:24vbttAraq: but ClassName helps readability in this case. it is a form of hungarian notation (or, name style determining kind of object) but you still choose the more readable styles.
19:57:43Mat3Araq: I decided to write a simple coroutine library beside my work (to be precise I port an old Pascal library)
19:57:53vbttmicklat:yeah i'm not saying adopt python's style.
19:58:15vbttbut just that python uses underscore_names often (methods, variables etc.)
19:58:50Araqvbtt: it's very well to do what Python does, but it's important to get your logic right
19:58:52vbttnimrod can keep camelCase, you'll probably still use another style for user defined types, right?
19:59:09Araqif you want to encode the entity in the identifier, just say so
19:59:27Araqdon't pretend "underscores are more readable" when you in fact picked any style there is
19:59:39Araqto encode the entity with it
20:00:11Mat3I have a finite solution: We just use symbols for everything ;)
20:00:11micklatbut what about acronyms?
20:00:27micklatIsn't TcpSocket terrible?
20:00:35VarriountAraq: Is there anything special about "newWideCString" proc that I should be careful with? When I use it, I get a runtime crash in gc.nim, in assgnRefNoCycle
20:01:12Araqmicklat: TCPSocket is worse imho
20:01:23vbttAraq: uderscore_case is what I find more readable. Python uses it extensively. I didn't make any logical connection between those two.
20:01:35micklatTCP_socket!
20:01:42Araqand acronyms are just as case insensitive as anything else
20:02:01Araqjust look at any URL, it starts with "http" not with "HTTP"
20:02:17micklatI think you're being very selective in your observation
20:03:40Araq*shrug* I know people remember a word's sound and not its spelling
20:03:58micklatthat's true
20:04:23AraqVarriount: newWideCString is not special
20:04:34Araqyou have some other problem
20:05:53reactormonkAraq, are the acronyms offending your case-based feelings?
20:06:23VarriountAraq: Oh. It appears that newWideCString fails if used in the top level. Odd
20:07:29Araqreactormonk: not at all, I like them
20:08:13reactormonktl;dr: case insensitivity will stay because we can't agree on snake_case vs. camelCase anyway
20:08:21vbttwill it?
20:08:30vbttI thought it's going away?
20:08:33reactormonkvbtt, I'm pretty sure Araq wants to kick it.
20:08:39reactormonkI however doubt it's gonna happen
20:09:02vbtteven camelCase is better than case-insensitivity, IMO (until we are all using the magical IDEs that fix the style for us)
20:09:46reactormonkis there a `$` for seqs somewhere or should I open an issue?
20:09:56vbttbeing able to use standard search tools and editors is a big win for popularity.
20:10:06Araqreactormonk: make a PR
20:10:30Araqvbtt: standard search tools and editors are all awful :P
20:10:39reactormonkAraq, sequtils or system?
20:10:45vbttAraq:agree, but point about popularity still stands.
20:10:48Araqreactormonk: system
20:10:58Araqvbtt: yeah, you can't argue against that one
20:11:39EXetoC"proc `$`*[T](a: openArray[T]): string" so what was up with that?
20:12:02vbttso you can disallow both fooBar and FooBar in the same code (i.e force ppl to use the style used at defintion)
20:12:25vbttanyway, bbl.
20:12:28Araqvbtt: that's exactly what I wanted to avoid
20:12:34*foodoo joined #nimrod
20:12:53Araqbecause the guy who wrote the definition is often foolish
20:13:04Araqand doesn't adhere to my style :P
20:13:28Araqjust look at micklat's code for proof
20:13:58Araqit's very nice code and I like to use it, but I want to write fooBar and he wrote foo_bar in his definitions
20:14:28foodooI don't know why, but I'm a fan of the snake_case convention ;)
20:14:50EXetoCreactormonk: I think the block at line 1675 needs to be removed then
20:15:00EXetoCand instead have overloads for all relevant types or something like that
20:15:20AraqEXetoC: dunno if we want to distinguish between @[] and [] for $
20:15:29Araq*for $'s output
20:15:43EXetoCno I don't think so
20:17:03EXetoCIncluding @ is trivial anyway
20:18:14EXetoCok so what about equality?
20:18:31reactormonkAraq, done.
20:18:46reactormonkEXetoC, maybe. It's commented out.
20:19:00reactormonkAraq, hmm, wait.
20:19:15VarriountHello foodoo
20:19:30foodoohello Varriount
20:20:00EXetoCreactormonk: it has been for ages, but you're right it doesn't matter
20:21:20*AndChat|206976 joined #nimrod
20:22:08AndChat|206976Araq: then why not have the compiler enforce a style?
20:22:19AndChat|206976Oops
20:22:33*AndChat|206976 is now known as vbtt_
20:23:01*carum quit (Remote host closed the connection)
20:23:11reactormonkAraq, updated.
20:23:31Araqvbtt_: I considered it, but found it too annoying
20:23:50*aftersha_ quit (Quit: Computer has gone to sleep.)
20:24:18vbtt_Annoying for who? Did you want to break the rule occasionally?
20:25:00Araqyes I do. Plus enforcing the one and only true style upon people is fascism
20:25:09vbtt_imagine the time saved by teams not arguing over their style guide.
20:25:34Araqlol
20:25:45vbtt_No I'm serious
20:25:54Araqnimrod's style insensitivity accomplishes the same
20:25:58vbtt_It's a practical choice
20:26:08foodooEven Google says that the coding conventions that they have should be broken if it makes sense
20:26:37vbtt_Why not add begin/end while you r giving everybody their freedom?
20:27:15Araqactually the original idea was to support indendation, {} and 'end X' ....
20:27:29reactormonkAraq, how come you didn't? Too complicated of a parser?
20:27:31Araqit's just that indentation based parsing is the hardest to get right, so I started with that ...
20:27:51reactormonklol.
20:28:23foodoovbtt_: The two programming languages Vala and Genie are somewhat the same. But the first one uses a C#-like syntax and Genie uses a Python-like syntax. They use the same compiler.
20:28:32EXetoCwe'll still have formatting tools
20:28:34vbtt_You can have an ugly workaround for those wanting to break the rules .
20:29:15vbtt_yeah I understand the semantic.. syntactic decoupling.
20:29:29foodooI haven't looked but into Nimrod's macro and template system, but isn't Nimrod powerful enough to support something like begin ... end?
20:29:47foodoobut->yet
20:30:04vbtt_but unfortunately we live on a world with text editors.. not semantic editors.
20:30:43reactormonkfoodoo, might actually work.
20:30:55Araqvbtt_ what you propose is reasonable though and we'll get that
20:31:32Araqcause I'm tired of arguing against the masses who can't even imagine tools that are not stuck in the 60ies
20:33:06vbtt_If nimrod is strict now it can always get lenient later.
20:33:51foodooAraq: What kind of modern tools do you have in mind?
20:35:13Araqfoodoo: Delphi 5 was pretty good; slim IDE for today's standards but supported most important stuff
20:35:41foodooNever looked into the Pascal family or the tools from that family
20:35:50Araqmany people live in extremes, either Eclipse or Vim
20:36:26foodooWell, I'm mostly a Vim user, but I'm also fine with LightTable
20:37:11vbtt_Smalltalk ides stored code as graph data and only transient converted to text for editing afaik.
20:37:17*tdc quit (Quit: Leaving)
20:37:58reactormonkAraq, I actually like ensime + emacs for scala
20:38:21reactormonkas soon as #804 is fixed, I might get somewhere similar for nimrod
20:38:27OrionPKlighttable for nimrod plz
20:39:23reactormonkOrionPK, what happened to that btw?
20:39:30OrionPKwhat happened to what?
20:39:50foodooOrionPK: But Nimrod would need to support JIT compilation, wouldn't it?
20:39:52reactormonkhttps://github.com/LightTable/ ah.
20:40:19OrionPKfoodoo only to make use of some of the zanier features
20:40:23OrionPKit's still a good general purpose editor
20:40:31OrionPKand it can pop in documentation panes and such
20:41:15*AndChat|206976 joined #nimrod
20:41:16*vbtt_ quit (Read error: Connection reset by peer)
20:41:17foodooOrionPK: Inline documentation is currently not one of LT's strong points (Tried it with Clojure something like 2 months ago)
20:41:19*AndChat|206976 quit (Client Quit)
20:41:35*AndChat|206976 joined #nimrod
20:41:36foodooBut maybe I just don't know how to use the features properly
20:42:25*BitPuffin joined #nimrod
20:47:08vbttthere's no easy escape from the text based word - consider source repositories, editors, search tools. in a better word the would work with semantic structure instead of flat text and and could be much more useful.
20:47:42vbttis nimrod's philosophy that "surface syntax shouldn't matter" ?
20:48:12vbttor rather - choose your own syntax..
20:48:58Araqvbtt: the philosphy was "one AST, multiple representations"
20:49:11foodoovbtt: nah, that would be Scala's philosophy ;)
20:49:24vbtthehe @foodoo
20:50:12vbttAraq: why 'was'?
20:50:26vbttis nimrod not that principled anymore?
20:50:31VarriountHm. Interesting. CPython C conventions seems to be that long argument declarations shouldn't be broken up into lines
20:51:13foodooIndeed interesting. Could this have something to do with documentation generator parsers?
20:51:29foodoobecause otherwise I don't see a point in that convention
20:51:29VarriountI don't know
20:51:58Araqvbtt: no, we'll get 1 syntax plus enforced naming scheme
20:52:07vbttoh nice!
20:52:08Varriountfoodoo: I'm currently experimenting with code styles in winlean.nim (the wrapper the stdlib uses to wrap needed windows api procedures)
20:52:29VarriountThere must be some better style than the current hodgepodge
20:52:39reactormonkAny way to get https://github.com/ruby/ruby/blob/trunk/numeric.c#L656 to floats in nimrod?
20:53:25vbttAraq: I fully support one AST, multiple representations in principle.
20:53:29foodooVarriount: The version of winlean.nim on Github?
20:53:43Varriountfoodoo: Well, yes, however I'm editing my local copy
20:54:21*[2]Endy quit (Ping timeout: 250 seconds)
20:54:27foodooAnd you don't like the inconsistent line breaks in argument lists?
20:54:30vbttIf it is *easy* to define new syntaxes for the AST, people will do it and you can have easy conversion from syntax1 -> AST -> syntax2.
20:54:49Varriountfoodoo: No. At least, not with veryLongArgumentNames
20:55:18VarriountAnd I also *gasp* prefer long pragma's on separate lines.
20:55:39VarriountEscpecially for procedure *declarations*
20:57:11*carum joined #nimrod
20:57:24Varriountfoodoo: I have a strong belief in this -> http://naildrivin5.com/blog/2013/05/17/source-code-typography.html
20:57:59foodoothanks. Looks interesting
20:59:13Varriountfoodoo: Also, the style conventions that work for one language, like say, python, won't neccesarily work well for another language, like nimrod.
20:59:26reactormonkAraq, will setLen for a string set the trailing zero?
20:59:59VarriountTake procedure parameters - in python, the parameters have no set type, so there is arguably less information for the reader to process per parameter
21:00:00vbttyeah nimrod differs from python in one core principle: there should be one obvious way to do it.
21:00:13*awestroke joined #nimrod
21:00:23vbtti suppose it's somewhat true in nimrod semantically, but you have multiple syntax choices.
21:00:34Mat3ciao
21:00:40VarriountBut in nimrod, procedure have double the amount of information - the name, and the type (which can be a complex declaration in some cases)
21:00:45foodooVarriount: Well, but you still have to understand what kind of types you can use with a function
21:00:51*Mat3 quit ()
21:01:12foodooSo there's implicit information
21:01:23Araqreactormonk: yes
21:01:28Varriountfoodoo: True
21:02:04VarriountMaybe I'm wasting time - Araq will probably shoot down style changes to winlean - but at least it gives me something to do.
21:02:54AraqVarriount: if you want something to do, wrap the winapi with c2nim ...
21:03:08Araqthis enormous windows.nim module has to die
21:03:15VarriountAraq: I could have sworn that was already done by windows.nim
21:03:24*awestroke quit (Remote host closed the connection)
21:03:52reactormonkAraq, can we use "%#.f" instead of "%#.16e" for floats?
21:04:20AraqVarriount: windows.nim has been translated from pascal, has way too many loc, has too many type aliases and might contain bugs
21:04:31reactormonkdoesn't add a trailing zero, but at least it doesn't shit all over the place
21:04:31Araqno make that *does* contain bugs
21:04:35VarriountAraq: What kind of style do you prefer, when it comes to procedure that have many long-named parameters?
21:04:53AraqWin API has its own style
21:05:05Araqa classic problem
21:05:18Araqshould we use win api's style or our own?
21:05:29VarriountWell, maybe winlean should be an exception.
21:05:38reactormonkVarriount, no exceptions please.
21:05:48foodooOrionPK: How do I look up documentation in LT?
21:05:49Varriountreactormonk: Why not?
21:06:01dom96When you're working with the WinAPI you're likely looking at the official MS docs.
21:06:07OrionPKfoodoo for nimrod?
21:06:11reactormonkVarriount, because they are annoying
21:06:14foodooOrionPK: no, Clojure
21:06:15dom96It's easier to use the wrapper if its style is consistent with the docs
21:06:23OrionPKfoodoo i have no idea, sorry
21:06:34OrionPKim a sublimetext user, not a LT user.. but I would love to try LT if someone made a nimrod plugin
21:06:35Varriountdom96: Or you're looking in winlean.nim to see how the winapi types match up to nimrod types.
21:06:52foodooOrionPK: ah okay. I know some videos that show off how LT will one day show documentation but seems like it's not there yet
21:07:15dom96Varriount: IMO the compiler needs a switch to tell you what these type aliases expand to.
21:07:17OrionPKfoodoo i wouldnt be surprised if it is there for some languages, but not others
21:07:18foodooOrionPK: oh, it's ctrl+d
21:07:20vbttif you want to see impressive editors, look up bret victor
21:07:29Varriountdom96: winlean doesn't follow the MS Docs style
21:07:34foodooOrionPK: when your cursor is at a documented entity
21:08:48AraqVarriount, dom96 IMO winlean should use *our* style
21:08:57VarriountAraq: Which is...?
21:09:17VarriountI would gladly follow the style, if it was written down somewhere.
21:09:34AraqTypesLikeThis, ConstantsLikeThis, everythingElseLikeThis
21:09:35VarriountWe have naming conventions, but no style conventions.
21:09:48vbttthe pretty tool should fixup the style too
21:09:56reactormonkAraq, TTypesLikeThis
21:10:11Araqreactormonk: well that's the old style ...
21:10:22Araq:P
21:10:35VarriountYes, but what about things like where line breaks should be, how should long argument lists be split, etc.
21:10:43reactormonkAraq, as you say
21:11:00reactormonkAraq, so you want to be case-sensitive on the first character?
21:11:14Araqreactormonk: we already are with --cs:partial
21:11:25reactormonkAraq, by default.
21:11:38Araqit will be the default after 0.9.4 is out
21:11:43reactormonkperfect.
21:11:54reactormonkAraq, mind glancing over my PRs?
21:12:44OrionPKi dont like procsLikeThis
21:13:21AraqOrionPK: --cs.partial means you can still write procs_like_this :P
21:13:41OrionPKi'd prefer procs_like_this or ProcsLikeThis :P
21:13:43renesacAraq, what was the convention defined for constants?
21:14:04reactormonkOrionPK, well, we can still have ProcsLikeThis if they're initializers and go down JS hell ,-)
21:14:19renesacbtw, I preffer TypesLikeThis, procsLikeThis, local_variables_like_this
21:14:25renesac?P
21:14:27reactormonkrenesac, you can still have that
21:15:11renesacand I dont like TypePtr...
21:15:34renesacI've grown to like TType, PType... thought they still look a bit ugly
21:15:49Araqrenesac: ;-)
21:15:50renesacat least they are consistent
21:15:59renesacand short
21:17:27renesacwhy the caller can't define "let x = ref Type" if he wants "let x = PType"?
21:17:40renesacthis way we don't need type specifiers
21:18:03reactormonkdom96, nice wiki page
21:18:08renesacif you want a value type, you don't put the "ref"/"ptr", if you want a reference type, you use it
21:18:19dom96reactormonk: Mostly Varriount's work :)
21:19:06*Varriount likes formatting things
21:19:26*renesac thinks some of that code typography to be excessive
21:19:42renesacthe link, not the wiki
21:19:54Varriountrenesac: Some, perhaps (like the spacing), however it's still something to keep in mind
21:20:02Araqrenesac: I'm working on this for other reasons, but it's not easy
21:20:21Araqptr Foo() is parsed as (ptr)(Foo())
21:20:29Araqand not as (ptr Foo)()
21:20:44renesachum
21:21:34renesacbecause this would be much nicer than having to know if a type is by default value or reference
21:21:44Araqand parsing ptr Foo() as (ptr Foo)() is disgusting
21:21:45renesacin the new naming scheme
21:22:05Araqrenesac: I disagree slightly
21:22:32Araqoften you do know what it is, or you know it has "handle like" semantics anyway (TFile, TSocket)
21:22:52Araqit's a problem for many wrappers though
21:22:59vbttalso you might need to refer to a type without knowing if it's a ref or ptr - in that case you need aliases anyway, no?
21:23:32Araqvbtt: that never happens IME
21:23:44vbttok
21:23:58vbttI was thinking seq[T] but that will still work, I guess.
21:24:06renesacI would like the compiler tell me it is a "ref Foo"
21:24:44renesacnot need to append Ptr to the name, or not append because it is the default
21:25:31renesacI need to rebase my fork of ParticleBench
21:25:44renesacour case inconsistency will cost some bytes on bzip compression
21:25:55Araqlol ok great
21:26:07renesacso, what is the new convention for constants again?
21:26:14AraqLikeThis
21:26:18renesaclike types?
21:26:23Araqyeah
21:26:30renesachum, ok..
21:26:33Araqit's a typical compromise :P
21:26:48Araqeverybody wants it LIKE_THIS except me
21:26:50renesacI like types to be more uniquely identifiable... but I guess it isn't easy to mix those two
21:26:56vbttI don't LIKE_THIS
21:27:02Araqyay
21:27:10renesacI also don't like LIKE_THIS that much
21:27:12vbttThisIsMuchBetter
21:27:38renesacbut when I don't want ALL_CAPS I want it to look like a normal variable
21:27:47vbttamusing how much time we can spend on trivial things.
21:27:55renesaclet is also kinda constant
21:28:11renesacvbtt, indeed
21:29:08renesacso we have "const Foo", "let bar", "var boo"
21:29:11renesac?
21:29:31renesacor "let Bar"?
21:30:06*micklat quit (Remote host closed the connection)
21:30:29Araqrenesac: "let bar"
21:30:36renesacok
21:30:44AraqI was torn about constants for a long time
21:31:05Araqbut OpenGl has some annoying conflicts when you don't distinguish between const and proc
21:31:19renesachumm
21:31:37Araqso that was what made the decision
21:32:08Araq"nimrod pretty" doesn't change constants btw
21:32:10renesacno chance we see conflicts again, but that time in a C++ library for example?
21:32:19Araqit doesn't matter
21:32:25renesacwhere THIS and This may clash?
21:32:34AraqOpenGL is important, some other C++ library is not
21:33:40renesacwhat could be other options for avoiding name clashes...?
21:33:49renesacanother hungarian notation?
21:41:46*micklat joined #nimrod
21:44:06Araqrenesac: you can put it in different modules and use module.foo
21:44:50renesachum, right
21:45:24Araqmicklat: I need to tell you that I find your project really good and it's what I have wanted to do for a long time. Do you expose the same API for both Lua and Python?
21:45:48micklatNot at the moment
21:45:53micklatgreat to hear
21:46:04micklatI could try harder to unify the APIs
21:46:14micklatbut getting something working at all is a higher priority
21:46:17AraqI dunno if it's feasable
21:46:29Araqyou can't switch "backends" easily anyway
21:46:39micklatand why would you want to?
21:46:41renesacI was going to suggest that instead of "init_list" it would be "py_list()"
21:46:44Araqthey have different syntaxes and semantics and stdlibs
21:47:25renesacto be more explicit it is a foreign data structure, and not clash with possible nimrod things..
21:47:33renesacbut that is more like bike sheding
21:47:39AraqI thought "import scripting" would be nice and then your nimrod program can support plugins written in Lua or Python
21:47:47micklatrenesac: I see your point
21:47:49renesacI haven't tried it yet, but I concur that it is a great project
21:48:02micklatthanks
21:48:17*carum quit (Remote host closed the connection)
21:48:26micklatAraq: not sure what you mean about "import scripting"
21:48:38Araqit's the sort of project that helps nimrod grow, we need to write articles about it and spam reddit ;-)
21:49:07renesacAraq, I think a separate python and lua scripting would be better
21:49:10dom96I made some modifications to https://github.com/Araq/Nimrod/wiki/GSoC-2014-Ideas
21:49:23renesacyou usually won't use both at the same time
21:49:40Araqmicklat: I mean a common API for both, but it's not important and as I said, might not be feasable
21:49:56Araqrenesac: oh you would
21:50:16vbttfwiw, i think nimrod get's lumped with other new languages but in fact nimrod has a lot more in it to be usable (large stdlib, very full featured, large third party libs)
21:50:23dom96Araq: Please expand the compiler section
21:50:27Araqthink about plugins, let your users decide which scripting language they prefer ...
21:50:47vbttyes we need more docs and blogs.
21:51:14renesacAraq, then all sorts of scripting languages would be imported by that import scripting?
21:51:44Araqrenesac: you can do that, you can also do better than that
21:51:51renesacor 'import scripting.python"
21:52:09EXetoCreactormonk: Araq and I agreed that it would be best not to include @ in the output. I don't know if you missed that
21:52:25EXetoCbut my reasoning was that it's both easier and cheaper to add it rather than removing it manually
21:52:38*foodoo quit (Quit: leaving)
21:52:39renesacI concour, the @ can be left to repr()
21:55:52Araqvbtt: any experience with kernel development?
21:56:27Araqothers: same question
21:56:57micklatlong ago, a bit in linux
21:58:06vbttAraq:no, why?
21:59:07reactormonkEXetoC, I'd prefer a distinction between seq and array
21:59:38Araqvbtt: well I'm designing "regions" for pointers
21:59:43vbttI mostly write servers in python
21:59:49Araqin fact, the design is pretty much complete
22:00:05Araqand even better the implementation is trivial :P
22:00:17vbttthat's nice.
22:00:31vbttnotwithstanding zero experience in kernels, I'm sure i'll have something to say :D
22:01:01Araqwell ok, you can "tag" pointers with user-definable tags like "kernel" and "userspace"
22:01:13Araqand the type system ensures you can't mix these pointesr
22:01:17Araq*pointers
22:01:34Araqso that kernel memory can't be exposed easily to the userspace
22:02:23Araqthe existing alternatives with 'distinct' etc. are all awful so a new mechanism is required
22:02:42EXetoCreactormonk: ok
22:02:46vbttok. what about user_pointer + delta_to_kernel_space
22:03:31Araqvbtt: you create your own `+` for that that performs the 'cast'
22:03:55Araqor do you mean you want to prevent that?
22:04:33*carum joined #nimrod
22:05:12vbttyes, pointer math is still unsafe right? and nothing helps me from making that mistake?
22:05:30vbttthe only thing is they are two distinct pointer types?
22:05:52Araqpointer math is not builtin in nimrod
22:06:02vbttp:UserPointer = f_returns_kernel_ptr() is a compile time error?
22:06:12Araqyup
22:06:15vbttah ok.
22:06:30vbttfunny i just assumed you could do pointer math.
22:06:51Araqwell you can with 'cast'ing to int
22:07:11Araqbut that's unsafe and very rare
22:07:33*brson quit (Ping timeout: 248 seconds)
22:08:11vbttwell the idea seems sound.
22:08:23vbttcan i add more pointer types for my user space only?
22:08:35vbttso i dont want to mix pointers into mmap region with other pointers?
22:08:35Araqalso 'ptr' will become a binary "operator", so foo ptr bar is ptr[foo, bar]
22:08:50Araqyou're free in what tags you define, yes
22:09:02Araqalso you can create subtype relations for them
22:09:04vbttand can i tag strings as well? or just pointers?
22:09:11Araqjust pointers for now
22:09:14vbttok
22:09:38vbtti like free form tags like this to distinguish pointers.
22:09:41*skyfex joined #nimrod
22:09:51AraqI need the mechanism for "shared ptr" anyway
22:10:01Araqso I generalized it a bit
22:10:23vbtti dont like shared ptr, btw.
22:10:34Araqwhat's wrong with it?
22:11:06Araqhi skyfex welcome
22:12:07vbttfor concurrency and parallelism, i find the ways that work best are messaging (copying), stm data structures or segmented data structures.
22:12:23vbttshared ptr seems too low level, but perhaps we can implement better data structures on top?
22:12:34skyfexhi Araq, thanks!
22:13:13vbttiow, i dont like passing an object ownership around. there should be exactly one owner throughout and other threads can possibly mutate the object with cleaner techniques (e.g. stm)
22:13:20skyfexbeen a while since I used IRC, but it's always a good time to get back into it
22:13:50vbttyeah, great start with this channel too!
22:14:18Araqvbtt: shared memory is just our last resort but it's necessary for systems programming
22:14:46Araqbtw we already have channels for thread communication
22:16:20vbttAraq:ok, if it's necessary.
22:16:27skyfexI'm snooping around in the compiler source.. (it's a pleasure btw) .. why does it seem "treeToYaml" is used for anything?
22:18:04skyfex*isn't
22:18:23skyfexCan't find it beeing called from anywhere, thought it'd be interesting to try to use it
22:19:18Araqskyfex: I don't know
22:19:40*Discoloda joined #nimrod
22:20:32Araqdoesn't "debug" end up using it?
22:23:22Araqskyfex: you're the first guy who thinks the compiler is a pleasure to read :-)
22:23:36*brson joined #nimrod
22:23:51EXetoC4 overloads and 4 invocations apparently
22:26:37skyfexWell, could use some more comments some places ;) but the proc names are usually quite descriptive and are usually not too big
22:27:33Araqyou can't be serious, most people think it's from hell because it uses "sem" instead of "semantic checking of"
22:27:57Araq:-)
22:30:29skyfexIs there a way of dumping the AST before the semantic check?
22:31:05Araqsure, just call renderTree or debug after the parser
22:32:04Araqmain.nim, line 409
22:32:06dom96npm got a $2.6M investment? what.
22:33:09Araqvbtt: I'll also add 'lent' and 'unique' pointers to shut up the reddit crowd
22:34:10vbttAraq:are unique pointers enforced?
22:34:18Araqyeah
22:34:27Araqbut I think I got them wrong :P
22:34:32vbttok, what does lent do?
22:34:37Araqbecause I see no need for lifetimes
22:35:29Araqyou can pass a unique pointer to a lent pointer but must not access the unique pointer for as long as the lent pointer lives
22:36:14vbttah i see, and this is enforceable?
22:36:20Araqsure
22:36:37Araqgot all the technology for "not nil" already
22:36:58Araqin other words we have control flow dependent typing
22:37:33vbttthat i understand. i just thought lifetime was a harder problem.
22:37:44Araqyeah we won't get that
22:37:47vbttbut i guess lent pointers cant be stored in other objects..
22:38:07Araqbut as I said, I don't really understand this stuff ;-)
22:38:36vbttheh ok. don't borrow too much from rust, btw.
22:38:38vbtt;)
22:39:42Araqwell we'll see, I plan to implement all the new pointer related stuff in one go
22:39:47vbttok
22:39:56vbtti just like to see good use cases beforehand.
22:40:06vbttspecially for stuff i dont see myself using :/
22:40:29Araqfor now I see it as a marketing feature
22:41:20vbttnimrod is already quite marketable.
22:41:43Araqno, the "rust is memory safe without a gc" is a killer argument
22:42:01Araqwe need to do something about that
22:42:13vbttunproven that the trade off is worth it.
22:42:23Araqyeah but nobody cares
22:42:24vbttis rust as easy to program in?
22:42:32vbttactual users care.
22:42:44Araqit doesn't matter, tbh
22:43:05vbttgolang isn't even safe and has a slow GC.
22:43:23vbttthere are plenty of awesome production apps that can be built with nimrod today.
22:43:52vbttiow, i'd rather see nimrod do fewer things well.
22:44:07vbttthan be a jack of all trades.
22:44:57skyfex"./koch boot" seems to take some time to compile the compiler.. is there a way to make it faster?
22:45:25vbttbut i personally like gc based automatic memory management so perhaps i'm biased.
22:46:05AraqI am also thinking about a "hypersafe" pragma
22:46:19Araqit doesn't allow anything, so it can't take up CPU or memory
22:46:36Araqthe only valid implementation is an empty "discard" statement for that
22:46:38vbttso basically, an empty program?
22:46:44Araqyup.
22:46:53AraqIt's very useful when you have no CPU
22:47:39*carum_ joined #nimrod
22:48:07*carum quit (Read error: Connection reset by peer)
22:48:53*carum joined #nimrod
22:49:10renesacI assume all this talk for pointers is post 0.9.4 stuff, right?
22:49:28skyfexyay, I was just saved by the "discard" feature for the first time
22:49:40Araqrenesac: right
22:50:08skyfexor that is, requiring the return value to be used
22:50:12renesaca half-assed unique ptr implementation can also be a target for critics
22:50:19Araqwell the hypersafe pragma is for april 1st
22:50:44renesacAraq, did't you like my idea about "Rod"?
22:50:52renesac^^"
22:51:17Araq:D there are many april 1sts
22:51:33renesacsure
22:51:40renesac:D
22:51:45Araqskyfex: "koch temp" is faster and produces a nimrod_temp you can use for testing
22:52:21*carum_ quit (Ping timeout: 248 seconds)
22:54:59Discolodabah, humbug on April 1st, cripples the usefullness of the internet
23:02:09vbttsorry was away.
23:02:27vbtt"Araq: It's very useful when you have no CPU"
23:02:40vbtt^ sounds like a perfect feature scheduled for apr 1
23:02:53vbttseriously, announce it on apr 1.
23:04:12vbttagree that a half-assed unique ptr is more negative marketing than positive.
23:04:49vbttAraq:you cant be everything to everybody - pick a story.
23:04:50*Demos joined #nimrod
23:05:11vbttif nimrod is a 'near realtime gc language' with optional manual memory mgmt - that's a good story.
23:06:40vbttwhen you also add yet another way to manage memory - it makes the story confusing. what memory management do you recommend? which should i use in my lib? will it inter-operate with all other libs? will i understand the other code out there?
23:07:03Demoswhy is the unique_ptr half-assed?
23:07:03vbttor are you trying to be c++? (everybody uses 10% of the language, but a different 10%)
23:07:41vbttDemos: it might not be. but *if* it is half-assed (it's possible there are some holes because such a unique/lent system can get quite complex to get right)
23:08:04*skyfex quit (Quit: Computer has gone to sleep.)
23:09:57Demosand imo a unique_ptr is a good candidate for some 3rd party library. Also, unique_ptrs having holes is not nessassarly a bad thing, c++'s unique_ptr has holes. All you need is a way to tell the type system that you want to give up ownership of something and I suspect that that is possible in nimrod. Rust's borrowed pointer ... thing ... strikes me as strange because I suspect (based on zero evedence) that the places where it really helps yo
23:09:57Demosu are places where a GC's pointer could be faster
23:11:23Araqvbtt: well it's nothing the stdlib should use, imho, it's just that the type system needs to support it as a library implementation doesn't cut it. but whatever
23:11:48Demoswhat is our definition of "cuts it" here?
23:12:38AraqDemos: be reasonably safe.
23:12:49Araqbut perhaps c++ already is that, I don't know
23:12:57Demosso like c++'s unique_ptr as opposed to c++'s auto_ptr
23:13:01vbttmove semantics of the unique ptr may need language support.
23:13:27Araqno. why? overloading of '=' lets you set the source to nil
23:13:37vbttah ok.
23:13:51vbttthats great.
23:14:03Araqok, you get some shitty runtime check instead of a nice compile time check
23:14:13Araqbut still not too bad
23:14:55DemosAraq, c++'s unique_ptr has no check. if you move ownership from one unique_ptr to another a dref of the first one is likely to segfault
23:14:55vbttbtw, pointer tagging is good and just unique-ptr is okay with me too. it's just lent pointer that's confusing because if it's lent why make it unique at all?
23:15:48vbttun_ptr1 = un_ptr0; un_ptr0.x = y; <-- this doesn't error at compile time?
23:16:40Demosin c++ un_ptr1 = un_ptr0 would not compile since unique_ptr's copy constructor and copy assignment have both been deleted
23:16:52Demosyou need to say un_ptr1 = std::move(un_ptr0)
23:17:53Demosstd::move is usually implemented as something like static_cast<typename std::remove_reference<T>::type&&>(t)
23:18:50Demosand actually, dispite having no checks these unique_ptrs are very, very useful. In many situations the owning pointer has a much longer lifetime than any accessing pointers
23:19:43vbttDemos:is the benefit over generational GC worth the extra complexity cost?
23:20:31Demosyes. esp since a GC that worked with c++ would probably be really slow
23:21:04vbttso if the GC was fast would it still be useful?
23:21:15Demosmaybe sometimes
23:22:41vbtti get that a unique pointer is useful when you want to move ownership from one heap to another. but i can't think of cases where it's that useful within the same heap. it it just that it wont be gced and since refcount can at most be 1, it's easy to cleanup when the last ref is gone?
23:23:01Demosthe unique ptr is not going to help you move memory around from heap to heap
23:23:21Araqyeah that's true
23:23:32Araqmoving from heap to heap is *hard*
23:23:46Araqreally *hard*, I thought about it for years now
23:24:02Araqfyi Rust doesn't solve it at all
23:24:03vbttgood. cos i don't want to do it anyway :)
23:24:24vbttbut going back to use case for unique ptr... Demos: can you give me a brief example?
23:24:32Araqit uses a shared heap for allocations
23:24:51Araqwell ok, maybe they can optimize most allocations to a thread local allocator
23:25:59Demossure. Lets say you have a long lived resource, maybe like some texture data in a game. When you load that up you want to allocate some memory, do somethign with it, then add it to some resource management structure. unique_ptr can handle all this, and when the resource management structure goes out of scope the memory for the texture will be deleted
23:26:11vbtti was thinking of something like erlang binaries - allocated outside all heaps and the pointer can be passed by messaging.
23:27:27vbttDemos:what you describe works very well without unique_ptr as well. if the resource management struct is the only reference to the object, it will be deleted when the struct is deleted.
23:27:48vbttDemos:are you saying the advantage is avoid gc traversal for objects with well known lifetimes?
23:27:51Demosright, but that is only if you have some kind of garbage collector
23:28:04vbttnimrod has a good gc.
23:28:11Demosright
23:28:29Demoswhich is why I think that the unique_ptr is not a good thing to be in nimrod's standard library
23:28:47*micklat quit (Remote host closed the connection)
23:29:34Demosthat said the unique_ptr could be good in some situations where the GC is hard to deal with, interop and such
23:29:35vbtteven a refcounted ptr is probably more useful. if i want deterministic destruction and avoiding gc traversal for some objects, i want immediate refcount semantics. this is specially useful for resources (file handles)
23:30:06Araqwell I'm more interested in enumerating the underlying type system mechanisms, not in unique_ptr in particular
23:30:15Demosfile handles could be done with a unique_ptrish thing, usually you don't hold on to them long anyways
23:30:22Demosright
23:30:35Araqunique_ptr is only a side effect of the features I'm after
23:30:41Demoswell I think the parameter constraints that are for term rewriting macros may actually be able to handle them
23:30:43dom96Araq: Should macros.len crash when the PNimrodNode has no sons field?
23:31:09Araqdom96: no idea. what does it currenly do?
23:31:11vbttAraq: can i / will i be able to do have immediate refcounted objects in nimrod?
23:31:27dom96ast.nim(924) len
23:31:27dom96Error: unhandled exception: sons is not accessible [EInvalidField]
23:31:51Demosvbtt, sure. But GC'd references are likely to almost always be faster
23:32:01Araqwell ast's len surely should crash, dom96
23:32:24dom96Araq: It seems that the vm calls that directly.
23:32:57Araqvbtt: can't see why not. overloading of '=' and destructors enable that
23:32:59dom96Araq: Does that mean that macros.len should crash also?
23:33:32Araqdom96: it should crash in a different way. Or produce 0.
23:33:44Araqin the compiler we have safeLen for when len is too annoying
23:33:45dom96Araq: I think it should produce 0
23:33:54Araqok
23:34:09vbttDemos: why would gced references be faster? immediate refcount releases the object immediately after the last ref is gone but gc will not.
23:34:22Demosright, you can batch up work better
23:35:02Demosalso, if you want to share the pointer across threads you need the count to be atomic
23:35:47dom96Araq: For now I can manually check the kind. Don't think a user should be expected to look up the kinds which have sons and which don't though.
23:36:19Demosfor example if you have a large tree you probably don't want everything freed right when the root goes out of scope since that is a long operation
23:37:38Araqdom96: ok, I agree
23:38:08Demosit really annoys me that c++ programmers think that shared_ptr is somehow a good alternitive to a gc
23:38:43dom96Araq: Want a bug report?
23:39:04vbttDemos: i agree in general the gc is probably more efficient cpu and latency wise. but if i want immediate release of some object, i might want a refcounted objects.
23:39:19Araqdom96: please simply fix it
23:39:27Araqthe vm should call safeLen, not len
23:39:27Demosvbtt, right, this is true
23:39:44dom96Araq: ok. Is it ok if I do it in my newasync branch?
23:39:49Araqno
23:39:51Araqit's not
23:40:12dom96ok
23:43:57*XAMPP_ joined #nimrod
23:44:25Araqbtw nimprof is really excellent for finding memory leaks
23:44:37AraqI bet nobody uses it :P
23:45:00dom96The last time I tried to it wasn't working.
23:45:00Araqit's a superb tool once you know it
23:45:56AraqI will add it to the list of things you must not criticize
23:47:23*XAMPP quit (Ping timeout: 260 seconds)
23:49:06NimBotAraq/Nimrod devel fa8bea6 Dominik Picheta [+0 ±1 -0]: Fixes macros.len crashing on nodes which lack the sons field.
23:53:31dom96damn. It seems iterators aren't capturing vars properly.
23:53:48dom96Getting a c gen error.
23:54:27Araqyay